Flutschkopfblubber

Den rund 6000 Beschäftigten der Technikzentren wurde bei dieser Gelegenheit auch offenbart, dass sie künftig länger arbeiten müssen und weniger verdienen. Sie erwartet eine Wochenarbeitszeit von 38 Stunden und ein "moderater Gehaltsverzicht" [...] Die Deutsche Telekom AG, die in den ersten sechs Monaten 2008 ein Betriebsergebnis von 4,166 Milliarden Euro und einen Überschuss von 1,607 Milliarden Euro (plus 22,2 Prozent gegenüber dem Vorjahreszeitraum) erwirtschaftete, begründet die Überführung der Technikbereiche von T-Home in die Deutsche Telekom Netzproduktion GmbH mit einem "anhaltend starken Wettbewerb und dem damit einhergehenden Preisdruck".(heise newsticker)

Wenn ich mal die 1,607 Milliarden Überschuß durch die 6.000 Geknechteten teile erhalte ich 267.833,33 Euro pro Kopf. Das ist natürlich eine völlig unsinnige Rechnung. Die beiden Zahlen haben nichts miteinander zu tun. Aber mal ganz ehrlich: Die Einsparungen bei den 6.000 Stellen sind doch Ackermannsche Peanuts, oder?

Betriebswirtschaftlich kann die erzielbare Summe gegenüber anderen Maßnahmen also kein Grund sein. Aber weitere 6.000 Arbeitnehmer per Dekret in ihre Schranken zu weisen ist ein weiterer Schritt in Richtung furchtsamer, willfähriger Sklaven.

Wir streiken - Ton Steine Scherben

...und Sláinte! an alle Lohnsklaven, die sich trauen, aufzustehen.

Wenn man in einer nx-Session ein VMWare Diskimage in einem TrueCrypt-Volume anlegt, kann man den nx-Server sehr gründlich gegen die Wand fahren. 

Die NX-Technologie von nomachine.com kommt meiner Vorstellung eines transzendenten Desktops schon sehr nahe.

Es gibt Code, für dessen Übernahme und Wartung man gar nicht genug verlangen kann. 

Wenn man den Start der daemons unter openSuSE 10.3 auf "nicht parallel abarbeiten" stellt passiert was? Genau. Nichts. Diese Einstellung wird ignoriert. Bis auf: powersave. Der powersave daemon ignoriert dann nämlich alle vorher mühsam händisch eingestrickten Einstellungen und läuft mit den Standard-Settings. Danke Novell.

Meine Checkliste für die Migration von openSuSE 10.2/32bit auf openSuSE 10.3/64bit umfasst grob geschätzt 50 Punkte. Bis jetzt (ungefähr 5 vor Schluß) hat die 10.3 mir bei JEDEM Punkt ein Bein gestellt. usbmount braucht 20 Sekunden auf einer 2x2GHz Maschine mit 2GB RAM und USB 2 (sind vielleicht die vielen Zweien schuld?). Das die ffmpeg-Entwickler einen Sockenschuß haben, war mir vorher klar. Über die rege ich mich ja gar nicht auf. Jedenfalls nicht mehr, nachdem ich zwei Tage mit API-Anpassungen und Bugfixing verbracht habe. Warum müssen aber Pakete, die seit geschätzt SuSE 7.3 stabil laufen, plötzlich Kernel-Paniken und ähnlich erfreuliche Fehler auslösen? Es gab mal so eine Redewendung: Traue niemals einer ungeraden Nachpunkt-Version von SuSE. Das hat Novell wohl übernommen.

Nach etlichen Tagen rumgeprokel in den Eingeweiden des Systems kann ich nur zum Schluß kommen:
openSuSE 10.3 ist nicht mal beta.
Dinge, die in 10.2 problemlos, in 10.3 nicht ohne Hacks funktionieren:

• KDE-Sitzungen speichern und wieder aufrufen
• Bttv-Treiber beim Systemstart laden
• Nicht mehr vorhandene Netzwerkinterfaces entfernen
• ungefähr alles, was ffmpeg nutzt dank API-Veränderungen
• dem powersave-daemon verbieten, den Monitor zu blanken
• Etliche Einstellungen im KDE-Kontrollzentrum werden ignoriert

Und ich bin gerade mal zur Hälfte mit meiner To-Do-Liste durch. Welcher halbgare Vollpfosten hat dieses Release freigegeben?

Das der Umstieg von openSuSE 10.2 x86 auf 10.3 x86_64 nicht ganz stolperfrei laufen würde, war eigentlich vorrauszusehen. Das sich dabei aber etliche Bugs in der verwendeten Software manifestieren, nicht. Nicht mal die Treiberkonfiguration unter openSuSE 10.3 funktioniert fehlerfrei. Besonders hilfreich ist hier, das nicht mal ein Fehler geloggt wird. Noch bin ich zuversichtlich, die 10.3 zum Spielen überreden zu können...

Der Leistungsvorsprung bei Mehrkern- oder -prozessorsystemen gegenüber Einzelprozessormaschinen ist bemerkenswert.