Eine Demokratie ist krank, wenn es eine absolute Mehrheit gibt. Eine gesunde Demokratie hat mehrere starke Parteien und schwache Parteien (ohne übermäßig zu zersplittern), die nur zusammen eine Regierung bilden können. Nur so ist ein Pluralismus gewährleistet, und dass der Normalbürger mit seinem Wahlverhalten noch Einfluss üben kann, und nicht die "Parteioberen" alleine entscheiden was passiert.

Sein Wahlverhalten sollte man an diese Situation anpassen, und mit beispielsweise den Freien Wählern steht ja inzwischen eine sehr ähnlich orientierte Partei flächendeckend als Alternative zur Union zu verfügung. Wer etwas offener für neue Ansätze und Reformen ist, der ist aber nach wie vor besser bei den Grünen aufgehoben.

Kleine Parteien wie die ÖDP - so sympathisch sie auch sein mögen - werden bei dieser Wahl vermutlich keine Chance haben, diesen eine Stimme zu geben ist eher kontraproduktiv, und erreicht eigentlich nur das nominelle Ergebniss der anderen Parteien zu reduzieren und die Wahlbeteiligung zu verbessern. Solange aber eine andere Partei nicht gerade eben unter die 5 %-Marke rutscht ändert sich nichts am Ergebnis (d.h. das wäre eine Stimme für "Hauptsache nicht Die Linke")

Für die Demokratie in Bayern wäre ein Ergebnis wie CSU 40%, SPD 20%, Grüne 12%, Freie Wähler 11%, FDP 10%, Sonstige zusammen 7% ganz realistisch und wünschenswert.

Dazu brächten wir nur ein paar mehr Wähler für die kleinen Parteien. Sucht euch eine aus, es ist für jeden etwas dabei!

[Disclaimer: Ich bin Mitglied bei den Grünen in Bayern.]

Mal wieder typisch, die kleinen Wahl-Fast-Lügen der Parteien.

z.B. die CSU, die "verspricht" in Bildung und Forschung zu investieren.

Nur dass das überhaupt nicht der CSU-Politik entspricht:

Statt ein Studium attraktiver zu machen wurden Studiengebühren eingeführt und Mittel gekürzt. Und das obwohl wir vor einem enormen Defizit an Hochqualifizierten Arbeitskräften stehen!

Dann währe da noch die Schulreform, bekannt als G8. Statt hier in den dringend benötigten technischen Fächern wie Physik auszubauen wird dort gekürzt, einiges gar zu "ferner liefen" degradiert. Nicht sehr zukunftsträchtig für das Ingenieursland Deutschland.

Der Trick der CSU ist ganz einfach:

Sie versprechen über 1000 neue Stellen - mit dem Wissen dass sie diese nicht besetzen können. So kann man leicht "investieren", ohne das Geld konkret ausgeben zu müssen.

Angeblich hat das Kultusministerium schon jetzt Finanzmittel eingeplant für 2000 neue Lehrerstellen, es gibt nur keine Lehrer um diese Stellen zu besetzen. Und nach Berechnungen der Grünen wurden übrigens seit 2004 über 320 Lehrer-Stellen gestrichen.

Update: ich habe noch einen Trick der CSU gelernt: die Stellen sind alle befristet auf 1 Jahr. Dadurch kann man jedes Jahr wieder 1000 "neue" Lehrer einstellen ... ohne dass sich wirklich irgend etwas ändert, außer dem Verwaltungsaufwand und dass es halt technisch gesehen keine "Lüge" ist.

If you are working with Eclipse on a Java project, make sure to try a regular (ant) build from time to time. The eclipse compiler sometimes differs quite a lot in what it accepts (especially when it comes to generics it seems to be a bit more clever) or considers a warning.

No, I did not just disable a warning. Eclipse did report some "serialVersionUID" warnings, but it missed lots of them, too. I have the vague impression that the Eclipse java compiler didn't recognize that a class implementing the "Externalizable" interface also should have a serial version UID.

And unfortunately I didn't find a way to reach the serial UID generation quickfix without having an eclipse warning... Well, after all there is not much wrong with starting the serial version at 1L.

Due to their implementation by erasure, they face certain limitations.

For example, the following constructor for a class with both compile time and runtime type checking:

class BagOf<T> {
  BagOf(Class<T> restrictionClass);
}

class BagOf<T> {
  BagOf(Class<?> restrictionClass);
}

The cost is low (obviously no difference at runtime) - you just don't assert that the developer using your class specifies a restriction class derived from the class T used in the generics. That won't prevent certain programming errors such as this anymore

BagOf<Integer> bar = BagOf<Integer>(Double.class)

Before submitting too clever suggestions, please make sure you've tested them. For example "if (obj instanceof T)" is not valid java code: since generics are implemented by erasure, T cannot be referenced in runtime statements.

P.S. It would obviously be nice if the Java syntax would allow Foo<Bar>.class (which at runtime would be the same as Foo.class, and at complie time would have the result type Class<Foo<Bar>>), but currently it does not for all I know.

P.P.S. I'm not looking for "Class<? extends T>", that is a different situation. The difficult case is when T is a Generic itself, not a subclass.

Update: JM Ibanez pointed me to Neal Gafter's Super Type Tokens, which apparently are the same as TypeLiteral in Google Guice. Thanks!

... might be due to a bug in Sun Java 6. Try upgrading to Java 6 Update 10 release candidate (also known as 'beta') or using a different Java VM such as IBMs or GNU. Worked for me.

Bug reported in Feb 2008 and Bug reported in Oct 2008 at Sun (note: they are marked as 'fix delivered' but that includes beta releases such as the 6u10RC linked above.

As some might know, I've been working at the university for a few weeks now. I'm very happy how it all worked out, because of the people there and the subjects to work on. It's just great to think through some mind-bending index structure to improve reverse-k-nearest-neighbor queries. And the professor (who is very well known for his work on R*-Trees, the X-Tree, and the DBSCAN and OPTICS algorithms) really manages to aggregate excellent people.

(rkNN is the problem of finding those points for which a Nearest Neighbor Search [Wikipedia] would return the given point. There are many use cases for example in location based services.)

A lot of my work involves a framework which has been published recently on the SSDBM 2008 conference: ELKI - Environment for DeveLoping KDD-Applications Supported by Index-Structures

The goal of ELKI is to become what WEKA is for machine learning. And it's well on it's way for that.

ELKI aims at the data mining researcher, it's not designed to squeeze out the last bit of performance. Instead it allows you to compare different algorithms, try different index structures (including various spatial and metrical trees) and offers all kinds of functionality you can reuse. If you are planning to do some real world applications, it likely is still useful for prototyping.

In the last weeks I've already put quite some effort in ELKI, so expect the next version to be released with significant changes and new functionality. In fact some working functionality was just left out of the release because we hadn't cleaned up the code yet.

Currently, getting started with ELKI can be a bit tricky. It's not hard to use, but you just need to find out where to start. The next release will therefore include a "dummy algorithm" that mostly serves as being a template for implementing custom algorithms (it can also be used for benchmarking an index structure, though).

Many people are already aware of the amount of data Google can (and does) collect on them. Some people therefore refuse to use certain google applications altogether. Others just like them too much.

There are some services that won't work with heavy ad blocking and anonymizing services - others will work just fine. A prime example everybody uses is Google search.

Google search will work just fine if you use anonymizers. Google Mail won't.

Privoxy and TOR is a great combination for anonymizing, however you won't want to use them for bandwidth-heavy web surfing, and there is little benefit of using them for web sites where you authenticate anyway.

Here's a way to do a compromise:

1. Install and configure Privoxy and TOR. Make sure they work.
2. Setup a proxy.pac file (proxy autoconfiguration) for your browser like this:

   function FindProxyForURL(url, host) {
       var google = /https?:\/\/([^/]*\.)?google\.[a-z]*($|\/)/;
       var tor = /https?:\/\/([^/]*)\.(exit|onion)($|\/)/;
       if (google.test(url)) {
           if (shExpMatch(url, "*.google.com/mail*")) {
               return "DIRECT";
           }
           return "PROXY 127.0.0.1:8118";
       }
       if (tor.test(url)) {
           return "PROXY 127.0.0.1:8118";
       }
       if (shExpMatch(host, "config.privoxy.org")) {
           return "PROXY 127.0.0.1:8118";
       }
       return "DIRECT";
   }
   

   and point your browser to it.
3. Add the following to your privoxy/user.action file:

   { +client-header-filter{hide-tor-exit-notation} }
   .exit
   { +filter{js-events} +crunch-all-cookies }
   .google./(search|blogsearch|scholar|images)
   

   And don't forget to reload privoxy.

When using Google Search (including image, blog and scholar search, feel free to add additional services) you should be seeing a login button, while you could be accessing Google Mail at the same time in another tab.

This list is of course not exhaustive. You might want to actually use privoxy and TOR by default, and only disable it for certain sites (or configure privoxy accordingly). You get the idea: this is just a very minimal approach to disable tracking exactly by the Google search site. It all depends on how serious you are about privacy and how important data throughput is for you.

Also it will allow you to access certain TOR functionality (such as hidden services) without running TOR all the time (after all, it is and will always be slower than direct access).

[Update: apparently some TOR exit nodes trigger a spam protection on Google, and without cookies you can't solve the captcha. So the use of TOR doesn't work well with Google. All the privoxy cookie blocking however is still recommended.]