From me@wt.xpilot.org Sun Feb 17 21:32:54 2002 Date: Mon, 4 Feb 2002 02:30:05 +0100 (CET) From: Winfried Truemper To: guug-members@guug.de Subject: Re: Öffentliche Petition soll Linux in den Bundestag bringen [..] Ich halte es schon für wichtig, dass man die Welt der Freien Software versteht, so weit das überhaupt möglich ist. Populäre Mystifikationen, wie zum Beispiel sogenannte Open-Source-Geschäftsmodelle, helfen uns auf die Dauer nicht weiter. Wenn wir Linuxer in bestimmten Situationen Linux bevorzugen - die Bundestux-Debatte ist ja ein solches Beispiel - dann nicht wegen einer grundlegenden Ablehnung von BSD und auch nicht wegen imperialistischer Bestrebungen. Das sind allzu schnelle Vorurteile und führen zu leicht genervten Reaktionen von Linuxern, was von den BSDlern als Bestätigung ihrer Vorurteile angesehen wird. Aber ich erkläre es diesmal technisch, muss dazu aber etwas ausholen. Der Begriff Computer beinhaltet heutzutage stillschweigend das Versprechen einer höheren Produktivität der ihn bedienenden Menschen. Das war zwar in den Anfangstagen der rein wissenschaftlich genutzten Zahlenfresser auch schon so, hat sich aber heute auf alle Bereiche des Lebens fortgesetzt. Keine neue Waschmaschine ohne Mikro-Computer. Zumindest in unserem Teil der Welt. Höhere Produktivität bedeutet, die Kombination aus Mensch und Computer kann komplexere Geschäftsvorgänge und Arbeitsabläufe schneller erledigen (als der Mensch alleine). Habe ich da gerade jemanden lachen gehört? Ich bitte doch um den nötigen Ernst. Die Arbeitsteilung ist meist so geregelt, dass der Mensch die kreativen Teile übernimmt, während der Computer die monotonen Teile durchführt. Voraussetzung ist natürlich, dass sowohl Mensch als auch Computer über gegenseitige Schnittstellen verfügen, um die jeweils erzeugten Teile aneinanderzufügen. Nun müssen wir an dieser Stelle erklären, wie der Computer als Anordnung von ein paar speziell dotierten Silizum-Kristallen überhaupt mit einem Menschen zusammenarbeiten kann. Die physikalischen Schnittstellen möchte ich dabei außer Acht lassen. Woher erhält der Computer seine Handlungsanweisung? Klar, die hat vorher ein anderer Mensch in den Computer eingegeben. Das heisst, der Mensch ist sich der Arbeitsaufgabe bewusst geworden, hat sie formuliert und sie dann in eine für die Ausführung als Handlungsanweisung auf dem Computer geeignete Sprache übersetzt. Der bediendende Mensch wählt zwischen den vorgefertigten Handlungsanweisungen, zum Beispiel über Menüs. Allerdings ist das eine sehr idealistische Sicht, weil in der Realität der Computer auch den Menschen programmiert. Das ist eine Folge der digitalen Arbeitsweise des Computers, die nämlich unsere analoge Welt unter Auslassung von Details nachbilden muss. Dadurch entsteht eine Parallel-Welt. Beispiel: Ein Web-Meister muss ständig die Beschränkungen der Web-Browser bedenken. Auf der gewobenen Seite ausgerichtete Objekte? Klar, da muss eine Tabelle her. Der Computer übernimmt also nicht nur die Gedanken des Menschen, sondern auch der Mensch übernimmt umgekehrt auch einige der Gedanken des Computers (die ihrerseits von Menschen stammen, aber mittlerweile der Parallel-Welt angehören). Bezogen auf die gedanklichen Tätigkeiten kann man sagen, dass aus Sicht des Menschen der Computer ein Teil von ihm ist und aus Sicht des Computers ist der Mensch teil von ihm. Letzteres ist die Grund-Annahme eines jeden Anwendungs-Entwicklers. Wenn nun die Aufgabe eines Unix-Kernels darin besteht, die Ressourcen eines Computers zu verwalten, und wenn man die Bandbreite zum Benutzer (Aufnahmebereitschaft) und dessen Aufnahmekapazität (Merkfähigkeit) als Ressourcen des Computers betrachtet, dann muss der Unix-Kernel eben auch diese verwalten. Der Mensch ist ein Host-Controller, indem nämlich bestimmte Aufgaben (die Kreativen) an ihn delegiert werden. Eine direkte digitale elektrische Kopplung wie bei ISA, PCI, USB und wie sie alle heissen besteht natürlich nicht. Aber nach Linux-Denke ist nicht erst eine körpereigene Anschlussbuchse erforderlich, um die Verbindung von Mensch und Computer als solche zu behandeln. Der Linux-Denke zufolge gehören die Verwaltung des Anwenders einfach zum Kernel dazu. Daher sind Leute wie ich, die keinen Buchstaben zum Hardware-technischen Teil des Linux-Kernel-Quelltextes beigetragen haben, trotzdem in der CREDITS-Datei des Linux-Kernels erwähnt. (In dem Sinne habe ich dann doch etwas beigesteuert: meinen Eintrag in den CREDITS geschrieben. :) Wohlgemerkt, die tatsächliche Steuerung und Wahl der Handlungsanweisungen ist auch aus Linux-Sicht nicht mehr Teil des Kernels, sondern wird von den Anwendungen vorgenommen. Natürlich achtet auch eine gute Anwendung auf den effizienten Einsatz von Ressourcen. Der Linux-Treiber für den Host-Controller Mensch (HCM) liegt natürlich nicht (oder nur für Spezialfälle) als C-Quelltext vor. Sondern das Hochladen des "Sequencer-Codes" und anderen komplexen Vorgänge passieren über menschen-verträgliche Einrichtungen wie den Linux-Kongress, den LinuxTag, lokale Veranstaltungen oder auch in fixierter Form über gedruckte Werke. Dabei verwischt der Unterschied zwischen Programmierern und Programmierten vollkommen. Die Linux-Gemeinde hat gigantische Anstrengungen in die komplexe Entwicklung dieses HCM-Treibers gesteckt, es ist eine ganze Treiber-Familie entstanden. Dass darunter die Qualität anderer Treiber leidet, ist vollkommen klar. Es ist halt ein Unterschied, ob 20-100 Leute vier Monate lang einen LinuxTag vorbereiten oder ob sie während dieser Zeit am Kernel werkeln. Irgendwann hat sich Linus auch mal beschwert, dass er - Reisezeit hinzugerechnet - zuviel Zeit auf Konferenzen verbrächte und kaum zum C-Programmieren käme. Natürlich hätten wir uns statt dessen auch einfach die vergangenen 10 Jahre auf die Optimierung des SCSI-Treibers konzentrieren können. Vermutlich wäre der so hochoptimiert, dass FreeBSD schon alleine wegen dieses tollen Treibers irgendwann geschlossen zu Linux übergewechselt wäre. ;) Aber das war nicht unser Ziel. Die Erklärung für die Entstehung von Linux liegt also in dem einen speziellen Treiber für den Host-Controller Mensch (HCM) begründet. Der wäre unter BSD nämlich so nicht akzeptiert worden, wie Du bestätigst. Diese ganze Klasse von Argumenten "die Linuxer hätten auch einen BSD-Kernel nehmen können" ist daher nicht zutreffend. Die Linuxer wollten also eben nicht nocheinmal das hochziehen, was es schon gab. Dabei war nicht die Ablehnung des schon Existierenden ("Aversion gegen Technik") die Motivation, sondern die nicht-so-technischen Löcher im Existierenden. Wenn aus heutiger Sicht vor Linux galt, dass Unix gekennzeichnet wird durch das Fehlen des HCM-Treibers, dann ist die Zeit seit Linux gekennzeichnet durch die weitgehende Vorkonfiguration der Host-Controller durch den verbreiteten Betrieb von Linux. Als Konsequenz kommen die Brüder und Schwestern von Linux mit einfacheren Treibern aus. Und akzeptiert ist es auch, wie die Kombinationen Unix/Linux und Linux/Unix in Zeitschriftenartikeln gelegentlich andeuten. Zu der zahlenmässigen Übermacht: Der Treiber gab und gibt Linux einen erheblichen Marktvorteil. Teile mussten unlängst ausgegliedert oder von vorne herein als eigenständig ausgelegt werden. Beispiele: KDE und Gnome. Die Verquickung lässt sich aber nicht ganz auflösen bzw. ist wegen der Synergie-Effekte erwünscht. Linux ist daher nicht der Inbegriff für "Open Sourced Unix", sondern "Open Sourced Unix" ist ein Phänomen der Linux-Bewegung (in dem Sinne, dass der Ausdruck "Open Source" aus Linux heraus geboren wurde). Glücklicherweise war die Übermacht bisher für alle von Vorteil. Linux hat (nach Linux-Denke) längst mehr Mehrwert für Unix, BSD und Gnu geschaffen, als es je aus diesen Bereichen genommen hat. Linux hat Schaaren von Entwicklern, Anwendern, Ideen und Werkzeugen gebracht. Wenn Du von "freien Wettbewerb der Systeme" sprichst: Daran hat Linux in den vergangenen zehn Jahren teilgenommen. Es erfolgt durch Linux doch sogar eine Förderung der anderen Systeme durch die vorkonfigurierten HCM. Und das zu erreichen war mehr, als immer nur "nimm Linux" zu flüstern. Indem Du die Unterschiede zwischen Linux und BSD auf Kernel, C-Library und Distributionen beschränken willst, bekräftigst Du mein überspitzt formuliertes Technokraten-Vorurteil nur. Ich nehme mal an, Du hast einen Vergleich wie den der Anzahl, Umfang und Verfügbarkeit von Dokumentation ausgelassen, weil er Dir einfach nicht wichtig scheint. Man könnte noch andere Beispiele auf der "human domain" betrachten: Und das ist der Unterschied. Also nicht der eigentliche Unterschied, sondern die kulturell unterschiedliche Wahrnehmung. Auch die von Dir vorgegebenen Kriterien Zuverlässigkeit, Sicherheit und Interoperabilität hängen vom HCM ab. Das kennt man ja auch von den klassischen Hardware-Treibern: Wenn das MS-DOS-Dateisystem den Kernel abschiesst, hilft der stabilste Ethernetkarten-Treiber nichts. Die Annahme, der BSD-Treiber für den vor Ort verwendeten HCM erfülle die Kriterien der Zuverlässigkeit, Sicherheit und Interoperabilität halte ich trotz meiner flüchtigen Kenntnis der BSD-Welt für gewagt. Beispiel: Vergleich mal freebsd.de und linux.de miteinander. Oder gehst Du davon aus, dass man stets der perfekte Mensch die perfekte BSD-Installation bedient? Ich erwarte nicht, dass irgendjemand gut findet, was ich schreibe. Das kann ja nur meine mit wenigen Leuten erarbeitete Meinung sein. Es geht auch nicht um eine Umerziehung der BSDler. (Das würde Veranstaltungen wie den LinuxTag einer gehörigen Portion Exotik und Folklore berauben). Aber wenn jemand in diesem Spiel mitspielen will, sollte er wenigstens einmal die Regeln hören, nach denen angeblich bei den Linuxern gespielt wird. Bzw. nach welchen Regeln BSD aus umgekehrter Sicht spielt. Das hilft Missverständnisse vorzubeugen. Es auf einen ach so verhinderungswürdigen "Linux- vs. BSD-Flame" reduzieren zu wollen wird der Sache nicht gerecht. BTW, irgendjemand muss die unbequemen Sachen ja mal sagen. :) Gruß -Winfried