dur.ch/

So als Versöhnung zu gestern kann ich heute ein Lob an die Sun-Techniker aussprechen. Der Memorytauch bei unserer E6900 lief äusserst effizient ab. Bevor wir begannen glaubte niemand daran, dass wir das einstündige Wartungsfenster einhalten könnten. Doch wir waren bereits nach 35 Minuten fertig: 7 Minuten Applikationsstopp, 1 Minute Verifikation und Poweroff des betroffenen Systemboards, 5 Minuten Memorywechsel, 15 Minuten POST, 2 Minuten Boot, 3 Minuten Applikationsstart. Damit waren wir wohl sogar schneller als wir mit DR gewesen wären. Und einen Produktionsunterbruch hätten wir auch dann nicht vermeiden können, da unser Oracle nicht mit DISM läuft... Die Planung für den Systemupgrade (inkl. Firmware) ist bereits erfolgt, jetzt muss ich noch schauen, dass wir Oracle auf DISM umkonfigurieren und dann werden wir sehen, ob's beim nächsten mal mit DR klappt.

Da es gerade in ist, über Sun zu ranten will ich mal in den Gesang einstimmen... Zumal ich heute ein eher unschönes Erlebnis mit Sun hatte. Da hat man eine schöne (und ziemlich teure) E6900 im RZ stehen, die so nette Features bietet wie u. a. Dynamic Reconfiguration: Damit kann man im laufenden Betrieb ganze Systemboards drainen, rauskonfigurieren und entfernen, Memoryupgrades/-ersatz durchführen, Board wieder einbauen, einkonfigurieren und die Kiste rennt unbeeindruckt weiter.

Wirklich eine tolle Sache. Natürlich müssen gewisse Rahmenbedingungen erfüllt sein, damit das auch wirklick klappt. Die sind eigentlich klar definiert und man kann sich gut darauf vorbereiten (Oracle z.B. muss mit DISM statt ISM konfiguriert sein). In der Praxis sieht es dann anders aus, heute hiess es: "Realtime-Prozess läuft". "Firmware nicht DR-fähig". "Patch XYZ fehlt". "Oracle!". Die Tatsache, dass DR auf der gleichen Maschine bereits mehrfach problemlos durchgeführt wurde, wird nicht kommentiert. Auf unseren Vorschlag, die DR bei gestoppter Applikation durchzuführen wird genausowenig eingegangen wie die weiteren Alternativen init S + DR oder ok-Prompt + DR um wenigstens Boot und/oder Memory-Checks (dauert bei 64 GB relativ lange...) zu vermeiden. Und bei alledem werd ich das Gefühl nicht los, dass es nur darum geht, dass man keine Verantwortung übernehmen will. Hallo Sun: Wenn ihr uns die Features verkauft, dann sorgt auch dafür, dass eure Leute sie verwenden oder dann wenigstens stichhaltig begründen, weshalb es nicht geht (was kann im ok-Prompt noch schiefgehen?).

Heute bin ich über eine recht seltsame Eigenheit von /usr/bin/grep unter Solaris (9 und 10, Sparc) gestolpert: Wenn sich in einem Unterverzeichnis bla Dateien mit zehn Zeichen langen Dateinamen befinden (z.B. blubbblubb) und man nach Teilen eines dieser Namen grept dann passiert folgendes:

$ grep lubb bla
blubbblubb
$ 

Und ausserdem zermatscht es einem das Terminal, da noch Binärmüll mit ausgegeben wird.

Dass die Linux-Treiber von Ati schlecht sind ist ja hinreichend bekannt, dass sie aber im Grunde unbrauchbar sind, war mir bis letzten Monat nicht bewusst. Ich hab die Ati 9250 nun durch eine Nvidia 6200 ersetzt. Damit laufen nun XVideo, DRI und alle anderen Features, die man erst vermisst wenn sie eben nicht mehr tun, wieder problemlos und ohne stundenlange Herumkonfiguriererei und -googlerei.