Captains Log

Das war schon eine lange Zeit, die ich jetzt mit Linux gearbeitet habe, es müssen so über zehn Jahre sein. Als ich damit anfing war noch keine Rede von, sich ganze CD- oder DVD-Images aus dem Netz zu laden und zu brennen, damals gab es noch Distributionen auf Diskette, wenn auch nicht unbedingt aus dem Linux-Lager.
SuSE kam noch in einer schlichten Mehrfach CD-Box daher, "Linux aktuell" genannt, und YaST war noch ein einfaches Admintool, mit dem die grundlegenden Dinge eingestellt wurden.
WindowManager konnte man noch von grundauf konfigurieren, ich benutzte damals CTWM und hatte eine über 35KB große ctwmrc. Da mehrere User auf meinem System arbeiten konnten, hieß sie sinnigerweise system.ctwmrc, so dass auch alle was davon hatten.
Nach einem Update kam YaST dann auf die Idee, diese Datei selbst zu überzeugen, mein erstes größeres Desaster, denn natürlich hatte ich kein aktuelles Backup gehabt.
Kurz Zeit später wechselte ich auf Debian, SuSE wurde einfach zu fett, machte alles alleine, worauf ich keinen Nerv hatte.
Irgendwann wechselte ich von PCs auf Macs, und fing auch dort mit Debian Linux an. War anfangs noch alles in Ordnung, gab es dann später, und die Situation besteht bis heute, eine Uneinigkeit zwischen den x86- und PPC-Entwicklern.
Der Linux-Kernel ist so dermaßen fett und unflexibel, das Änderungen im PPC-Teil den x86-Baum beeinflußen können. Das Ende vom Lied war, das die PPC-Architektur teilweise über ganze Kernel-Releases hinweg nicht ohne weiteres nutzbar war, weil Patches und Updates nicht in den Hauptbaum integriert wurden.
Das machte mich schon arg unzufrieden... Und dann kam Linus in der Diskussion um die Art und Weise, wie Kernel und Treiber entwickelt werden und meinte, die Linux-Treiber würden auf den Level "Gut genug" gehoben.
Was bitteschön heißt denn das? Gut genug bedeutet, dass ein Treiber in 80% der Fälle funktioniert, bei einigen weiteren Prozenten muß irgendwie gepatcht und gehackt werden, weil es ansonsten zu vielfältigen Problemen kommen kann. Und in allen anderen Kombinationen funktioniert ein Treiber nicht.
Danke Linus, Du bist mein Held! Es ist nicht ehrenvoll für Kernel-Entwickler, immer mehr Treiber zu integrieren, wenn sich Linux-User, auch oder vor allem die im Business-Umfeld, nicht drauf verlassen können, dass ein Treiber für die von ihnen gekaufte Hardware auch läuft.
Bei BSD ist das anders: Hier werden Treiber eher ruhen gelassen oder nicht eingebaut, solange klar ist, dass irgendwas nicht funktioniert. Wenn ich ein Stück Hardware brauche, das eine bestimmte Funktionalität erfüllt (Bluetooth-Stick, WLAN und Co.) schaue ich einfach in die Kompatibilitätsliste, und kaufe mir dann ein Modul oder eine Karte, die einen unterstützten Chipsatz enthält.
Einbauen, Kernelmodul laden, fertig.
Unter Linux? Kaufen, Treiber laden, und beten. Und nicht genug gibt es genug Konfigurationen, in denen Hardware nicht funktioniert, wenn z.B. Karte A nicht mit B zusammen arbeiten. Es gibt genug schlechte "Designed for Windows Schlagmichtot"-Hardware da draußen, bei denen die mitglieferten Treiber Unzulänglichkeiten der Hardware ausbügeln müssen. Sowas kann man unterstützen, muß man aber nicht, vor allem wenn sowieso nicht sichergestellt ist, dass es funktioniert.
Jetzt, wo ich durch meine Abteilung einen tieferen Einblick in klassische Unixe bekommen haben, attestiere ich Linux auch gerne eine Konzeptlosigkeit: Es wird programmiert, ohne viel vorher drüber nachzudenken, Hauptsache ein Problem ist behoben oder eine Funktionalität ist implementiert. Ob dabei neue Kernelfunktionen eingeführt werden, die vielleicht unnötig sind, weil man vielleicht vorhandene hätte ausbauen können, spielt dabei keine Rolle, und auch nicht der Gedanke, ob man sich in der Zukunft dadurch etwas verkompliziert.
Eigentlich ist es schon Schizophren: Auf der einen Seite freuen sich viele Leute, das Linux auf allen möglichen Geräten läuft, angefangen vom kleinen PDA bis hin zum großeren Server, aber umgekehrt bekommt dieses so hoch gelobte Feature nicht die Aufmerksamkeit, die es braucht. Ganz im Gegenteil überlegen doch einige Kernelentwickler, die Entwicklung von x86 zu forcieren und die Kompatibilität mit den anderen Plattformen zu brechen.

Auch auf Anwendungsebene gibt es viel Gemurkse und gegenseitige Beeinflußung, ich erinnere mich mit Grausen an die Zeit, wo gpm nicht laufen durfte, wenn man X hochfuhr. BSD kommt mit einem default moused, der auch von X genutzt werden. Herzlichen Glückwunsch...

Wenn man sich im Gegensatz dazu mal BSD anschaut, so sieht man hier schnell andere Konzepte, die sich wie ein roter Faden durchs ganze System ziehen, und die Arbeit zur Freude machen, wie z.B. die generischen Compilereinstellungen in /etc/make.conf, die Daemon-Konfiguration in /etc/rc.conf und dem Bootloader kann ich in seiner Konfiguration mitteilen, welche Kernelmodule ich gerne automatisch geladen hätte.
Um PCMCIA/Cardbus-Karten oder USB-Devices wie Bluetooth-Sticks zu konfigurieren, brauche ich kein großartiges Cold- und Hotplugging-Gedöhnse, wie das unter Linux gelöst wurde, und ich kann, man höre und staune, meine Anwendungen unabhängig vom Basissystem updaten, oder auch umgekehrt.
Ja, die ganzen Sourcen, die das Basissystem ausmachen liegen zentral unter /usr/src und können dort mit einem make buildworld neu übersetzt werden, z.B. nach einer Aktualisierung via CVS Checkout.
Technisch sind die BSDs auch allesamt ausgereifter, es gibt z.B. eine neue Funktionalität namens "GJournaling" im FreeBSD, die es praktisch erlaubt, ein Journal auf jedes beliebige Filesystem zu schreiben, und wenn es sich dabei um eine 3,5" DOS-Diskette handelt.

Nachdem FreeBSD 6.1 seit einigen Wochen stabil auf meinem Laptop läuft, habe ich vorgestern mal ausprobiert, was mein Server davon hält, und selbst die IT-RAID Karte, an der meine 200GB-Platte hängt, wurde anstandslos erkannt (unter Linux mußte ich dafür einen eigenen Kernel bauen).
Es gibt für mich keinen Grund mehr bei Linux zu bleiben, Donnerstag werden die Daten vom Server ausgelagert, dann wird neu installiert.
In meinem Urlaub kommt dann eine OpenBSD-betriebene Firewall ins Haus.