Linux

Nun ist es endlich soweit: Der Monolith Linux bekommt seine Grafikkartentreiber endlich in den Kernelspace. Zwar bin ich grundsätzlich ein Freund von Microkernelstrukturen und der Verschiebung von Features in den Userspace (Filesysteme, Netzwerkprotokolle), aber die Krücke XFree86 (oder Xorg) mit ihrem eingebauten Root-Hole, um an die Grafikhardware zu kommen, ist doch etwas arg schmerzhaft.

KGI hatte das Problem schon 1998 angegangen, aber damals wollte Linus Grafiktreiber nur "über seine Leiche" (oder so) im Kernel sehen - er fürchtete wohl die Komplexität. Das Design wurde vereinfacht, aber leider weiterhin nicht integriert.

Aber nun kommt ein prinzipiell identischer Ansatz aus der Xorg-Ecke, und wird von Torvalds Brötchengeber gestützt, so dass das endlich mal was wird.

Fehlt nur noch der nächste Schritt: Entkoppelung der Userspace-Teile der Treiber vom X11-Protokoll. Aber da werden vermutlich einige andere Entwickler ihre Leiche als Hindernis anbieten wollen..

Nachdem www.coreboot.org heute nachmittag unter Last zusammengebrochen ist (Sekundäres Slashdotting, 3 Webcrawler), habe ich mich mal daran gemacht, die Konfiguration zu optimieren.

Auf dem System läuft (neben diversem anderen) ein Apache2, der unter anderem ein Mediawiki, trac, viewvc und das mailman-Webinterface bereitstellt. Auffällig waren die sehr großen, zahlreichen und ständig neuen apache2-prefork-Prozesse. Wie sich herausstellt, wurde prefork gewählt, weil php5 weiterhin nicht thread-safe ist (bzw. die eine oder andere Library, die eingesetzt wird). Für trac und viewvc wurde mod_python verwendet.

Leider habe einige mod_python-Versionen das Problem, dass sie leaken - und so wirklich gut scheint man das nicht im Griff zu haben. Von daher war die Planung, php5 "irgendwie" threadsafe zu bekommen und mod_python zu eliminieren.

Trac lässt sich per fastcgi einsetzen, php5 ebenso. Also wurde beides auf mod_fcgid portiert, so dass PHP5-Threadsafety nun kein Problem des Apachen mehr ist, und statt prefork nun worker verwendet werden kann. Weniger Forks, weniger Stress für den Server.

Viewvc hat kein Fastcgi-Interface, daher läuft es momentan als normales CGI, also ein neuer Prozess pro Request, aber es ist relativ klein und schnell, daher macht das nicht so sehr viel aus.

Mal schauen, wie sich der Server nun weiter benimmt.

Nachtrag 24.4.: Heute Nacht haben auch die Apache2-worker angefangen zu leaken - ein Restart vom Apachen gab 1GB freies RAM. Squid war auch total lahmgelegt. Es geht also weiter mit der Fehlersuche...

Zebuntu heißt nun zeVenOS, aus irgendwelchen rechtlichen Gründen. Bernd Korz (der Mensch hinter Zeta) ist auch nicht mehr dabei, und irgendwie ist das Ding eh etwas seltsam: "yet another Ubuntu distro", mit "BeOS touch".. Hmm..

Naja, scheint, als ob der Hauptentwickler von dem System einfach eine nette Zusammenstellung neuer Defaults und Tools in ein ISO-Image presst. Zu Open Source-Entwicklung hat er jedenfalls folgendes zu erzählen:

Als Schlusswort, Vielfalt, ist je wie man es sieht ein Vorteil oder Nachteil von freier und offener Software. Ich sehe Vielfalt eher als einen Vorteil, solange man sich an Standards hält. Sprich man entwickelt sich z.B. nicht seinen eigenen Kernel oder Treiber.
Dies wurde nämlich bereits einmal gemacht. Damals hieß das System Unix. Dies war der Untergang des Systems. Es setzte sich gerade auf dem Desktop überhaupt nicht durch. Die Inkompatibilitäten unterseits führen auch gerade jetzt dazu, dass immer mehr Firmen weg von Unix Servern hinzu Linux Servern wechseln.
Meiner Meinung nach sollte es nicht daraufhin herauslaufen, dass man nur einen Linux Desktop und damit eine Distribution anbietet, denn dann hat man eine ähnliche Situation wie mit Microsoft Windows heutzutage. Aus der Lizenz zu schließen, wird es auch nie zu so etwas kommen können.

Von der historischen Verzerrung (die Unix-Systeme unterschieden sich nicht primär duch einen "eigenen Kernel oder Treiber", sondern in aller Regel durch unterschiedliche Architekturen, auf denen sie liefen, und - schmerzhafter - inkompatiblen APIs für Anwendungsentwickler) mal abgesehen frage ich mich, was dieser Seitenhieb gegen nicht-Linuxsysteme (etwa Haiku, Syllable, ...) denn soll. Und dabei lasse ich mal außen vor, dass Linux selbst nur ein "me too"-Projekt ist (BSD in seiner Gesamtheit ist älter).

Unixoide Kernel sind trivialer Kleinkram (der dann beliebig aufwändig optimiert und verbessert werden kann), der zu Dutzenden in irgendwelchen Uni-Kursen von Studenten zusammengefrickelt wird. Treiber sind (dank Linux, FreeBSD und OpenBSD) auch kein Problem mehr - man kann sie bei Bedarf relativ schnell portieren (außer Grafikkartentreibern, da besteht Vendor-Lockin - im OSS-Bereich).

Es ist ein überschaubares Problem, einen Kernel mit einer handvoll Treibern zusammenzustellen (Beweis durch Aufzählung: Syllable, Haiku, SkyOS, Linux - und die hunderte von "Spielzeugkernels", denen "lediglich" der Überbau fehlt - also Userspace, lasse ich mal weg).

Einen wirklich guten Desktop gibts irgendwie noch nicht.

Wenn ich mir die Freedesktop.org-Spezifikationen so ansehe, wird ein guter Desktop "kompatibel" auch kaum möglich sein (nun, alles abhängig davon, was "gut" nun eigentlich bedeutet).

Diese Spezifikationen bauen einen immer größeren Stack auf, um Probleme relativ weit "oben" zu bearbeiten, die "unten" eventuell besser gelöst wären: Message Passing? Klar, Userspace Daemon ("D-BUS"). BeOS macht sowas mit per-Thread Message Queues (Kernel-Support). Aber das wäre ja nicht "Unix" (was auch immer das dann heißt).

Man muss also, um "kompatibel" zu sein (ein Erfolgskriterium, nach obigem Quote) 150MB Bloat im RAM rumschleppen, und hunderte von APIs implementieren und nutzen, um so grundlegende Geschichten wie Interprozesskommunikation abzuwickeln. Oder einem Window Manager Support für die ca. 700 Hints mitgeben, mit denen man X11 soweit aufbohrt, dass es doch wieder halbwegs state of the art ist. Oder einen Composition Manager implementieren, damit die modernen Grafikeffekte umgesetzt werden können (der kann - realistisch gesehen - eh nur lokal laufen, aber wo man ja schon so einen tollen Kommunikationskanal, eben das X11-Protokoll, hat, muss man den ja auch nutzen - also: noch mehr Komplexität, um diese Gigabytes an Bitmaps irgendwie durch ein Netzwerkprotokoll zu schieben).

Man kann sich das Problem aussuchen: Kompatibel sein, was bedeutet, dass man jede Menge Zeugs übernimmt oder neu implementiert, das man vielleicht gar nicht haben wollte, wodurch man am Ende auch nicht wirklich vom Rest zu unterscheiden ist (und wenn man eh nur "noch eins" macht, warum dann eigentlich - außer zu Lehrzwecken?).

Oder etwas neues schaffen - mit allen Problemen, die sich dadurch auftun: neue Schnittstellen, wenig Software, Fragmentierung des "Marktes" - eben den Problemen, mit denen sich die UNIX Systeme rumgeschlagen haben. Linux "löste" diese Probleme durch - Monokultur (womit wir bei Windows wären, was im Quote ja auch schon besprochen wurde).

Gemäß meiner Theorie, dass Kompatibilität gute Entwicklungen zu sehr einschränkt: Wird zeVenOS nun kompatibel, oder wird es gut?

"Some attributes in sysfs need a terminating newline, some don't, so try both." - heißt es in einem Changelog eines Ubuntu-Packages. Das bedarf keines weiteren Kommentars von meiner Seite.

Ich habe mich ja häufiger, auch recht lautstark darüber aufgeregt, dass Qualitätskontrolle bei Linux nicht gerade das populärste Thema ist. Nun sieht es leider so aus, dass mein Favorit der letzten Jahre, Solaris, diese Eigenschaft von Linux durch Sun übergebraten bekommt - man will ja schließlich bei den Linux-Entwicklern fischen gehen. Dazu noch eine sehr intransparente Art, interne Projekte in OpenSolaris zu integrieren (Plötzlich ist was da, was die eine oder andere offene Entwicklung unnötig, oder inkompatibel macht. Vorher nie gehört, dass jemand daran arbeitet. Andere Alternative: "Oh, das Projekt brauchst du gar nicht erst anzufangen, wir releasen da demnächst was".. Das war vor 2 Jahren), und man kommt bei einem System (samt "Open Source" Projekt) an, das nicht wirklich attraktiv wirkt. Also war ich für meinen Laptop auf der Suche nach einer Alternative. Nachdem ich gute Erfahrungen mit OpenBSD auf meinem Server gemacht habe, wollte ich es auch dort probieren, allerdings ist es für den Desktop - für meinen Geschmack - ein bissel viel Frickelei. Also OpenSuse 10.3 probiert, aber es kam mir arg groß und unnötig intransparent vor (welches Tool schraubt jetzt wo an welcher Konfiguration, und wo kann ich zur Not manuell nachschrauben? Zugegeben: Diese Fragestellung interessiert Otto-Normal-Benutzer nicht, von daher will ich den OpenSuse-Leuten da keinen Vorwurf machen). Mal skeptischerweise Ubuntu angetestet - und was soll ich sagen, es funktioniert. Alle Hardware wird unterstützt, er fragt sogar nach, welche Treiber ich denn gerne hätte, wenn es "non-free" Zeugs gibt und beschafft diese dann auch ohne große Probleme, und hat sogar versucht, meinen Bluetooth-Stick zu integrieren. Der hat wohl leider nicht genug Saft am USB - oder generell einen Hau, aber da kann Ubuntu ja nix für (Unter Windows an einem anderen Rechner benimmt er sich genauso)