Entries by Patrick Georgi

Mal wieder Netzeitung: "Die Linkspartei, derzeit ein Mix aus Realisten, Nostalgikern und Polemikern, müsse sich entscheiden zwischen Demagogie und Konstruktivität, referierte [Gesine Schwan]". Prompt gab es Widerspruch von Seiten der Linken - aber warum?

Diese Beschreibung passt doch auf so ziemlich jede Partei - die SPD hat auch ihre "Realisten", "Nostalgiker" und "Polemiker" an Bord, die CDU ebenso. Und eine Entscheidung zwischen Demagogie und Konstruktivität wird auch in der SPD und der CDU nur ungern getroffen (beispielsweise in der Frage, wie man eben mit der Linken umgeht).

... oder wenigstens in der politischen Berichterstattung.

In der letzten Zeit lese ich immer häufiger, dass es ein Widerspruch wäre, wenn die SPD bei bestimmten Wahlen die Stimmen der "Linke" einkalkuliert, aber eine Koalition ablehnt. Als Beispiel ein aktueller Artikel der Netzeitung:

Kurt Beck müsste erklären, warum er denn die eigene Kandidatin für das höchste Amt im Staate auch mit Links-Stimmen wählen lassen will, aber die Partei vier Monate später zur Bundestagswahl als Koalitionspartner ablehnt.

Es gibt also anscheinend - in der Welt der Politik - nur zwei Zustände: der eine, bei dem die Linke nur noch der "linke Flügel" der SPD ist; der andere, in dem die SPD sich so weit es nur geht von der Linken distanziert.

Dass es möglich ist, dass die SPD bei einzelnen Fragen (etwa "Köhler oder Schwan", "Koch oder Ypsilanti", etc) mit der Linken kooperiert, und sich auf deren Stimmenanteil verlässt (und dafür gegebenenfalls auch klar definierte Zugeständnisse in Kauf nimmt, bei bestimmten Positionen Zurückhaltung zu üben, etwa bei der Abstimmung über den Europa-Vertrag), aber "im Großen und Ganzen" keine ausreichende Überschneidung bei "wichtigen" Fragen sieht, so dass eine Koalition problematisch wäre, scheint in so manchen politischen Dickschädel nicht reinzugehen.

Natürlich lässt sich dieselbe Frage auch mit jeder anderen Konstellation zweier Parteien stellen, beim CDU/FDP-Gespann kommen dann auch spannende Fragen und mögliche Antworten heraus - nicht zu vergessen, wie unterscheidbar das Profil von Parteien noch ist, die sich auf quasi-Augenhöhe in einer Koalition treffen. (Nachtrag: die TAZ berichtet über die Überlegungen der Grünen Jugend zur Grüne/CDU-Kombination)

Heute: Logorrhoe, nicht umsonst verbal verwandt mit der Diarrhoe. Das Konzept war mit bekannt, dass dazu einen (derart tollen) Begriff gibt, bisher nicht.

Ich rege mich ja gern über Apple und deren Produkte auf. Eins bekommt man dort aber gut hin: Integration - sowohl APIs, als auch Services.

Bei Services ist Netzwerk wohl das eindrücklichste Beispiel (wobei, das bekommt sogar Windows halbwegs hin - bloß das "Netzwerk-Betriebssystem" UNIX, von dem der ganze Kram stammt, nicht): Auf Solaris gibts "Network Autoconfig Magic" und klassische Konfiguration. Das fällt auch jedem Nutzer von OpenSolaris 2008.05 (alias "Indiana") auf, es ist eins der häufigsten genannten Probleme im #opensolaris Chat in der letzten Zeit.

Auf Linux gibt es neuerdings den "NetworkManager", eine mehrteilige Architektur mit Backenddaemon und Frontend-Tools (GUI und CLI). Soweit, so gut. Es gibt aber auch weiterhin den Direktzugriff auf, beispielweise wpa_supplicant/wpa_cli - oder Konfigurationsdateien in /etc, die unabhängig am Netzwerk rumkonfigurieren. Und die Frontends werden unabhängig vom Backend entwickelt. Es könnte also passieren, dass das GNOME-Frontend andere Funktionen bietet, als das KDE-Frontend. Und wer will, kann sich via D-BUS direkt am Backend austoben.

Bei Apple werden alle Tools am Stück entwickelt. Zwar auch mehrteilig, aber "aus einem Guss". Irgendwelche Daemons, die im Hintergrund die Arbeit leisten (auf Linux etwa wpa_supplicant) werden dabei so gut es geht mit einem Frontend im Backend versehen.

Mit APIs ist es ähnlich: die String-Klasse hat direkt Möglichkeiten, mit der URL-Klasse ("Highlevel Networking") zu interagieren. Bei vielen Linux/UNIX-APIs muss man sich dann erst einmal die Typen in das jeweilige Äquivalent der anderen Library (separat zu beziehen, separater Entwicklungszyklus, andere Handhabung von so nervigen Geschichten wie API-Stabilität, ...) konvertieren.

Linux (oder Solaris, oder *BSD), gut und schön. Apple hats begriffen: Das System basiert auf einem UNIX-artigen Unterbau, und bietet den auch an, wenn man ihn haben will (etwa im Terminal, wo er gute Dienste leistet). Desktop-Anwendungen kommen aber fast ohne UNIX aus, und müssen sich dementsprechend nicht damit rumschlagen, dass man es 1970 sinnvoll fand, Zeichenketten mit "0" abzuschließen.

Diese Freiheit, "UNIX" auch mal links liegen zu lassen, und "UNIX-Prinzipien" auch mal zu hinterfragen (ach übrigens: "Everything is a file" stimmt seit der Einführung von BSD Sockets nicht mehr - oder wie öffnet man einen Socket per fopen?), fehlt mir im Linux/UNIX-Umfeld..

In manchen christlichen Kreisen wird ja unbedingte Solidarität mit Israel gefordert. Bei Berichten wie diesem fällt mir das doch schwer:

Victor Kalisher [director of the Bible Society in Israel], the son of Holocaust survivors, spoke to the [Jerusalem] Post about his shock and dismay at the burnings.

“As Jews we were raised and taught that were books are burned, worse things can happen. That’s what I think when I see the pictures of what happened in Or Yehuda. What worries me is that nobody has stood up against this. It seems there is a war against messianic Jews in Israel. Nobody cares about many, what I believe to be cults, in Israel. These cults, which are not based on the Bible, don’t pose a threat to the establishment. But God forbid a Jew learns about the messiah from the [Christian] Bible,”

He said he did not know who paid for and distributed the New Testaments that were distributed in Or Yehuda, but that there was demand for the books from many quarters. “The Bibles are not forced on anybody and are not forced into any homes. The book has never harmed anyone, you can choose to read it or choose not to read it. If this happened to Jewish books overseas we would be screaming anti-Semitism.

Kalisher noted a recent increase in tension between the messianic community and their opponents. “Bombs have been sent [in Ariel] and now books have been burned. This cannot be allowed to happen here,” he said.

Ich hab die "Gratissoftware" zum Focus Money Heft "Steuersparen" installiert und wollte mal schauen, ob es Updates gibt. Fehlanzeige: "Versionsinformation fehlt. Bitte neu installieren" oder sowas..

Scheint ein bekanntes Problem zu sein, mit "Lösung" auf der eurowin Webseite (bzw dem Google Cache, das Original wurde wohl schon wieder beseitigt). Und falls der Cache das bald auch nicht mehr hat, hier die Lösung in ebenso kurzer Form, wie auf der eurowin-Seite: Patch herunterladen und installieren.

Update: Damit auch alles funktionierte, waren einige Extraschritte notwendig: Software installieren, Patch ausführen, Software deinstallieren und neu installieren. Dann funktionierte alles. Eventuell ist der Patch auch ohne Installation ausführbar, womit man sich eine Installation und Deinstallation sparen würde... Die Installation nach Patch-Anwendung war jedenfalls arg fehlerhaft, da sie anscheinend von anderen Datenbanken ausging als denen in der Focus-Version.

Ich bin heute auf Todd Bentley aufmerksam gemacht worden (siehe zB bei IDEA, oder Wikipedia), der momentan mit "pfingstlicher" Erweckung in Florida (in gewissen Kreisen, zumindest) von sich reden macht. Mit Wunderheilungen, gelegentliche Prophetien, und alles, was sonst noch dazugehört.

Natürlich - wie bei allem, was nach Wundern aussieht - gibt es auch hier verschiedene Meinungen. Argumente der Kritiker sind unter Anderem:

• "Ausrichtung auf das Wirken von Bentley und seine Mitarbeiter, statt auf Gott"
• "Cold Reading Techniken bei Prophetien"
• "Fixierung auf Engel"
• Während Engel, und auch Interaktionen mit Menschen, biblisch dokumentiert sind, gibt es doch einige Unterschiede:
• Üblicherweise sind Engel nicht namentlich genannt (mit Ausnahme von Gabriel und Michael)
• In der Bibel sind Engel männlich attributiert
• Üblicherweise sind Engel recht bodenständig (statt 30cm über dem Boden zu schweben)
• Biblische Engel verweisen auf Gott, als ihren "Auftraggeber" - ihm gehört die Ehre, durch ihn geschieht ihr Wirken (siehe auch Hebr. 1,13.14)
• Bei einigen Verhasplern sprach Bentley von "Emma-O". Das mag eine kanadische Eigenart sein, oder auch "auf einen japanischen Dämon hinweisen", der ähnliche Hobbies wie Satan ("Ankläger der Menschen") zu haben scheint
• "Astralreisen" - Bentley und Freunde nennen es "Third Heaven", und berichten von persönlichen Gesprächen mit Jesus oder Paulus (Bentley: Der Hebräerbrief war übrigens eine Gemeinschaftsproduktion mit Abraham)
• "Viele falsche Prophetien", die an dem Projekt beteiligt sind - die "amerikanische Prophetenszene" setzt angeblich "geringere Standards" an als die Bibel
• "Kommerzielle Interessen" - besonderes Öl, das einem bei Visionen helfen soll, "Clubmitgliedschaft", ...

Ebenso natürlich gibt es direkt Reaktionen von Bentley-Verfechtern auf die Kritiker:

• "Und was habt ihr für das Reich Gottes getan?" - Ein argumentum ad hominem
• "Wer heilt, hat Recht" - Siehe dazu, zum Beispiel: Mark 13,22; Apg. 8,18-24; Apg. 19,13-17
• "Der Teufel heilt nicht, und kann nicht schöpferisch tätig sein" - In dem Fall wäre Sai Baba wohl auch göttlich

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..

Heute habe ich zum ersten Mal einen Sektor eines in QEmu emulierten USB Mass Storage Devices in GRUB2 gelesen, Yay!

Leider hat QEmu von einigem eine andere Meinung als die USB Specs, so dass der Treiber momentan vermutlich nur in QEmu funktioniert. Aber gut, als nächstes wird der Treiber an GRUB2 angebunden, so dass man auch Dateisysteme lesen kann und überhaupt was sinnvolles mit so nem Gerät anstellen kann.

Mal schauen, vielleicht korrigiere ich den Kram in QEmu mal und versuche, ob ich diesmal einen Patch reinbekomme - es wird allemal leichter sein als bei den GNU-Projekten.

Ich frage mich ja, ob sich der Aufwand lohnt... OS X zu patchen, damit es auf Nicht-Apple Rechnern läuft, bei jedem Apple-Update befürchten müssen, dass es irgendwas kaputt macht, Treiber irgendwoher zaubern für die Hardware..

Wäre es da nicht ziemlich bald effektiver, den Kram einfach nachzubauen? Klar, das "Artwork" 1:1 übernehmen ist damit nicht möglich, und es ist auch einiger Aufwand (siehe Haiku oder ReactOS) - aber im Gegensatz zu den beiden Systemen wäre das Basissystem (Darwin) ja schon vorhanden, für den Highlevelkram könnte man bei GNUstep oder Cocotron abkupfern und sich die Sachen dann zurechtbiegen, dass sie ihren Gegenstücken in OS X entsprechen...

Und vielleicht könnte so ein Projekt dann auch eine einheitliche GUI bereitstellen (wieviele Themes hat Apple momentan im aktiven Gebrauch? Mindestens drei: Aqua, Brushed Metal und das farbneutrale Profi-Theme)

Textkritik wird eine Serie, in der ich Pro und Contra diverser Programmiersprachen (aus meiner Sicht) beleuchte. Und damit das auch nur ein wenig glaubwürdig bleibt, fange ich am besten mit meinem "dokumentierten Favoriten" an, Forth. Da es nicht bloß eine C-Variation ist, ist eine Beschreibung der Eigenschaften wohl gerechtfertigt.

Forth ist eine Sprache, die sich in den frühen 70ern entwickelt hat, und zur Klasse der "Concatenative Languages" gehört (die erst später definiert wurde). Das bedeutet, man kann den Programmfluss an (fast) jeder Stelle aufteilen in neue Funktionen ("Worte" in Forthterminologie), die man dann zusammensetzt, ohne dass sich das Verhalten ändert - eine sehr schöne Eigenschaft für Refactoring. (Zum Vergleich: "int a; a=5*rand();" einfach aufzuteilen würde scheitern: "int a;" "a=5*rand();" verliert die Deklaration im zweiten Teil, "int a; a=5" "*rand()" ist kompletter Murks)

Die Sprache ist entstanden zu einer Zeit, als es noch keine riesige Betriebssystem- und Bibliotheksinfrastruktur gab. Entsprechend bietet Forth seine eigene Systemabstraktion, auch wenn diese sehr dünn ausfällt. Darauf aufbauend besitzt ein typisches Forth ein Interpreter/Compiler-Gespann, dass sich die Bälle zuspielt: Es startet üblicherweise im Interpreter (sofern man nicht direkt in ein anderes Programm springen will), der bei Bedarf den Compiler aktiviert. Entwicklung ist dadurch "live", die meisten Befehlssequenzen lassen sich erst am Interpreter testen und bei Erfolg zu Worten (=Funktionen) compilen, die in der weiteren Entwicklung verwendet werden können. Auf diese Weise kann gerade Hardwarezugriff sehr schön experimentell getestet werden.

Die Übergabe von Argumenten findet über einen Stack statt - ein Wort hat also keine Definition "soviele Argumente nehme ich (vom Typ X), und soviel gebe ich zurück", es wird stattdessen eine globale Datenstruktur eingesetzt.

Womit ich bei den Problemen wäre:

• (zur Syntax: ": foo ( n -- n | n n) bar baz ;" definiert ein Wort "foo", dass der Ausführung von "bar" und "baz" entspricht. "( n -- n n)" ist ein optionaler Kommentar, der üblicherweise angibt, dass foo ein Element auf dem Stack verbraucht und eins oder zwei zurückgibt.)
• Die Anzahl der Rückgabe-Elemente ist also nicht eindeutig festgelegt, ebensowenig wie die Eingabemenge, was sehr sinnvoll genutzt werden kann (und wird!), wodurch die Einarbeitung in fremden Code aber recht spannend sein kann.
• : send-packet ( len data -- result true | false )
0 0 2 PKT_DATA send-phy-packet ;
  Was bedeutet das? So wirklich überschaubar ist der Datenfluss nicht (in diesem Fall sieht es wohl so aus, dass send-packet im Prinzip ein Wrapper um send-phy-packet ist, der einige konstante Parameter hinzufügt, und dessen Ergebnis einfach durchreicht). Was zum zweiten Problem führt:
• Datenstrukturen sind bei Forth nicht sonderlich üblich. Daten werden auf dem Stack übergeben. Und wenn 6 Elemente benötigt werden, um eine Situation zu beschreiben, liegen halt 6 (anonyme) Elemente auf dem Stack. Und das ist manchmal eine ziemlich aufwendige Datenschieberei, um an die einzelnen Elemente zu kommen (idealerweise arbeitet man die von hinten nach vorn ab, bzw. ordnet die Daten so an, dass das möglich ist).
  In anderen Sprachen wäre hier vermutlich schon eine Datenstruktur zum Einsatz gekommen, die dem ganzen die richtigen Namen gibt.

Natürlich lässt sich das auch in Forth namentlich erledigen, etwa indem Worte konstruiert werden, die einem einen "sinnvollen" Zugriff auf Stackelemente geben (": pkt.len 5 pick ;" - also "wähle das 5-letzte Element vom Stack und kopiere es oben auf den Stack"), was allerdings zu Lasten der Effizienz gehen kann - also eine Abwägung zwischen Effizienz und Lesbarkeit.

Eine andere Möglichkeit wäre, derartige Datenstrukturen außerhalb des Stacks vorzuhalten. Das wiederum bedeutet, jedes Element explizit anzufordern, auf dem Stack zu bearbeiten und in die Datenstruktur zurückzuschreiben, was weder die Effizienz, noch die Lesbarkeit fördert.

Möglichkeit Nummer 3 ist schließlich, solche Datenkolosse gar nicht erst aufkommen zu lassen - was nicht immer möglich ist, zum Beispiel wenn man vorhandene Hardware ansteuern soll (das obige Beispiel ist eine Adaption aus einem USB-Treiber).

In schöner Regelmäßigkeit wird in Deutschland (wie anscheinend überall sonst in der Welt) das Urheberrechtssystem als "zu schwach" oder "nicht zeitgemäß" angeprangert, wobei solchen Statements stets eine Wunschliste mit Änderungen beigelegt wird.

Der Think Tank "World Economic Forum" (Wikipedia über WEF) hat eine Managerumfrage durchgeführt, mit folgendem Ergebnis:

The rankings come from the World Economic Forum's Executive Opinion Survey, which ranks the G8 countries in the following order:

1. Germany (1 overall)
2. UK (8)
3. France (9)
4. Canada (15)
5. Japan (17)
6. United States (22)
7. Italy (42)
8. Russia (113)

Die Zahlen in Klammern entsprechen der allgemeinen (nicht G8-spezifischen) Rangliste. (Quelle: Michael Geist via Excess Copyright Blog)

So schlecht kann es ja nicht sein...

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?

Nur ein kleiner Nachtrag: ich habe GCC nicht beibringen können, __udivdi3 andere Aufrufsemantik zu geben, als den Default, von daher bleibt -mregparm=3 bei meiner GRUB2-Variante deaktiviert.

Es geht aber, theoretisch: __attribute__ ((regparm(1))). Den kleinen Kniff habe ich gefunden, als ich die handvoll Assemblerfunktionen verarzten musste, die auf regparm(3) basierten.