Pinguinscheisse der gesammelte Tux-Dreck dieser Welt

/dev/* war gar nicht schlecht. Drum habe ich es lange behalten. Die Idee hinter devfs war ja nicht verkehrt, den Kernel Devices selber anlegen zu lassen.  Schon damals ging das Elend los, bestehende Konventionen einfach über den Haufen zu werfen. So wurden z.B. MD-Devices wie /dev/md0 zu „langen“ Devices wie /dev/md/0, und andere Hierarchien zwangen den glücklichen Admin zum Editieren von jeder Menge Konfiguration, bis alle Systemteile ihre Geräte wiederfanden.

Nun war devfs wohl architektonisch irgendwie Grütze und etwas Neues musste her. Es wurde das Gespann daraus, das wir als  udev kennen: Ein mit Kernel-Events versorger Daemon tobt sich auf einem RAM-FS aus.  Von mir aus gerne, nur war devfs zwar nicht mehr ganz toll, aber auf einmal flog es ganz aus dem Kernel raus, ohne daß udev auch nur halbwegs fertig oder zuverlässig war. Dumm z.B. daß es ein Henne-Ei-Problem beim Systemstart gab: Was tut man denn zum Start in die Ramdisk, so daß die Filesysteme auch gecheckt werden können und eine Konsole zur Verfügung steht? Muß der Admin sich halt was ausdenken…

Das ist ein ganz typischer Fall von Pinguinscheisse: Ein Kern-Projekt läuft nicht so gut, weil Fehler gemacht wurden, und auf einmal hat keiner mehr richtig Lust, es weiterzuführen. Das Neue Zeug ist noch nicht annähernd fertig, aber man zwingt die Welt dazu, diesen überhasteten Schritt mitzugehen. Unprofessioneller geht es nimmer.

OK, nun hängen wir also an udev. Da können sich Distributoren auch mit Rule-Files so richtig austoben, um den User von Inkonsistenzen fernzuhalten. Nur der „Selbstmacher“ schaut wieder mal in die Röhre, wenn „mal eben“ Sachen verändert werden, wie dies irgendwann vor udev-164 geschehen sein muss:

• Konfigurationsfiles/Rules wurden verschoben. Vor „make install“ sollte man also in /etc/udev und /lib/udev aufräumen.
• Die langen Devices wurden wieder verkürzt. /dev ist also wieder voll mit Special Files wie ganz früher. Schade nur, daß man sich das nicht aussuchen kann (ohne Rules selber zu fixen).
• Der Kernel darf nicht zu alt sein. 2.6.32 ist offenbar schon zu alt und wird z.B. MD-Devices nicht anlegen lassen.

Der geneigte Admin darf also wieder mal eine „Big-Bang“-Aktualisierung durchführen, bei der kein Schritt zurückführt.

Wenigstens ist der Weg beim Systemstart nun einfacher geworden, weil der 2.6.36-Kernel ein devtmpfs kennt, was wie damals das devfs aus dem Kernel heraus die Sicht der Welt zeigt. Schade nur, daß die dabei verwendeten Dateinamen nicht immer mit denen aus den udev-Rules übereinstimmen.

Aber eine der Maximen aus der Welt der Pinguinscheisse lautet ja, daß die Distrubutoren sich um solche Nickeligkeiten schon kümmern. Warum sollte man sowas auch in den Quellen pflegen…