Zeit: "Linux ist zu komplex geworden!"

lilium

New Member
Meine Absicht ist es nicht einen Hater-Thread zu erstellen.

Letztens bin ich auf diesen mittlerweile etwas älteren Artikel gestoßen und habe Fragen dazu. Geht es bei der Entwicklung des Linux-Kernels wirklich so chaotisch und unübersichtlich vor wie es Linus Torvalds beschreibt? Aussagen wie "Es gibt einige Teile im Programmcode von Linux, die nur wenige Leute wirklich gut kennen. Vergangene Woche diskutierten die drei Leute, die sich am allerbesten mit einem bestimmten Subsystem von Linux auskennen, einen Fehler. Wir brauchten Tage, um uns zu einigen, wie dieser Fehler überhaupt auftreten konnte. Er ist unwahrscheinlich, dass er je wirkliche Probleme macht, weil man schon exotische Dinge tun muss, damit er überhaupt auftritt. Und das Lustige daran war, dass er bereits seit fünf Jahren existiert. Aber es ist ein Beispiel für ein Subsystem, für das es nur eine Handvoll Leute gibt." und "Ich sehe mit Bangen dem Tag entgegen, an dem wir einen Fehler haben, den niemand mehr nachvollziehen kann." sprechen schließlich nicht gerade für die Organisation des Projekts. Ist das bei derartig großen Projekten mehr oder wenig gesehen unvermeidbar oder könnte man es auch durchaus besser machen?

MfG
lilium
 
Ich denke, es geht bei fast allen großen Softwareprojekten so zu. Hier und da mag es besser laufen aber auch bei Microsoft, Apple und Google wird es diverse Teile geben, bei denen jeder hofft, dass man sie einfach nie wieder anfassen muss.

Jeder Programmierer hat sicherlich schon mal spät in der Nacht einen Höllencode hingezaubert, der einwandfrei funktioniert, keinen Ärger bereitet aber fast nicht mehr nachvollziehbar ist. Wenn dann noch einige Zeit vergeht und nicht exzellent dokumentiert wird, muss man diesen Code später komplett neu schreiben. In dem Fall könnte man den Code dann einfach ein bisschen weniger effizient und ausführlicher gestalten und das Problem ist erledigt ;)
 
Linux ist gewachsen, nicht gestaltet.
Ob "gestaltet" oder "gewachsen" das bessere Konzept ist, dürfte kaum entscheidbar sein. Wie auch immer: "An den Früchten werdet ihr sie erkennen!" :)

Die genannten Punkte treffen heute wohl auf alle Mainstream-Betriebssystem zu, also einschließlich BSD und Linux: Eine ausufernde Komplexität die kaum noch zu bewältigen ist. Auf der einen Seite werden Löcher gestopft, auf der anderen reißen andere wieder auf. Und durch neu entstehende Anforderungen wächst die Komplexität ständig weiter. Sisyphos...
 
Ob "gestaltet" oder "gewachsen" das bessere Konzept ist, dürfte kaum entscheidbar sein.

Doch, natürlich.

Linux war von Anfang an als "Hobbyprojekt" gedacht, anfangs ja nicht mal als Kernel, und wurde immer weiter mit Funktionen vollgeflanscht.
Bei BSD hat sich jemand vor der Implementierung Gedanken gemacht.
 
Linux war von Anfang an als "Hobbyprojekt" gedacht, anfangs ja nicht mal als Kernel, ...
Klar, aber das war noch in der Pränatalen Phase. Bei Unix sah es Anfangs nicht viel besser aus, eher schlechter denn Linus hatte immerhin Minix und die Geschichte von UNIX vor Augen, während Thomson und Ritchie bei ihrem Projekt nur an das gescheiterte Multix-Projekt anschließen konnten. Und erzähle mir doch bitte niemand dass die beiden damals - immerhin in den 70er Jahren - auch nur im entferntesten ahnen konnten was daraus einmal werden wird, - genauso wenig wie Linus in den frühen 90ern.

Entscheident waren allein einige zukunftweisende Ideen: Verwendung von C, hirarchisches Dateisystem, Fork etc pp.
...und wurde immer weiter mit Funktionen vollgeflanscht.
Ist das bei BSD wesentlich anders? Ich denke nicht, oder nur geringfügig.
Bei BSD hat sich jemand vor der Implementierung Gedanken gemacht.
Das halte ich für einen Mythos der nur dazu dient die Vergangenheit zu verklären um daher eigene Legitimation zu gewinnen. Von BSD in heutigen Sinne kann man ja eigentlich erst seit BSD 4.3/4.4 reden und auch At&T hat wohl einige Spuren hinterlassen. Und prompt hat es sich aufgesplittet in (zumindest) 5 unterschiedliche Betriebssysteme. Und konzeptionell sind das alles riesige, monolitische Kerne, - genau so wie Linux.

Klar, das Entwicklungsmodell ist bei BSD ein anderes, ein Stück konservativer, ein besseres wie ich meine. Aber ganz so groß sind die Unterschiede nun wirklich nicht. Und Gedanken macht man sich auch bei Linux vor der Implementierung, - nur eben andere...:rolleyes:
 
Doch, natürlich.

Linux war von Anfang an als "Hobbyprojekt" gedacht, anfangs ja nicht mal als Kernel, und wurde immer weiter mit Funktionen vollgeflanscht.
Bei BSD hat sich jemand vor der Implementierung Gedanken gemacht.
Das mag ja schon sein, aber 30 Jahre technische Entwicklung kann man nicht vorhersehen, also war es damals gut desingt, muss es aber heute nicht mehr sein.
 
Da geht der Trend ja zur Modularisierung, cf. DragonFly BSD.
Das ist sicherlich notwendig. Andererseits hat es das schon sehr lange gegeben: Subsysteme des Kernels, Treiber, System- und Userprogramme usw.usf. Natürlich kann man das weiter differenzieren, eindeutigere Schnittstellen implementieren etc. So lange man aber an der Vorstellung eines universellen, für alles und jeden nutzbaren Betriebssystemes festhält wird die Komplexität weiter zunehmen und irgendwann wird es unter deren Last zusammenbrechen. Android ist ein Beispiel - nicht notwendigerweise ein gelungenes - für ein OS mit begrenztem Anwendungsbereich. Andere werden folgen. Quo Vadis BSD?

Ich denke das im Prinzip Tannenbaum auf lange Sicht recht behalten wird. Aber diese Diskussion ginge hier zu weit.
 
Auch in den BSDs gibt es gewachsenes.. viel sogar.
Es wird aber eher mal wieder "ausgemistet" statt einfach nur einfach den naechsten Busch zu pflanzen :)
 
Das ist ein ungelöstes Problem und das kann man dem Linux-Projekt nicht ankreiden.

Andere Ingenieurs-Disziplinen sind in ihrer Komplexität durch die Endlichkeit des Raumes in die eine Konstruktion passen soll begrenzt.

Bei Code gibt es keine natürlichen Grenzen, entsprechend sind Maßnahmen zur Wahrung der Übersicht aus anderen Disziplinen ungenügend. Und eine Lösung ist nicht in Sicht.
 
Andere Ingenieurs-Disziplinen sind in ihrer Komplexität durch die Endlichkeit des Raumes in die eine Konstruktion passen soll begrenzt.

Bei Code gibt es keine natürlichen Grenzen, entsprechend sind Maßnahmen zur Wahrung der Übersicht aus anderen Disziplinen ungenügend. Und eine Lösung ist nicht in Sicht.
Von den Sozial- und Geisteswissenschaften bis hin zu Politik und Philosophie haben wir das gleiche Problem, nämlich dass das die Motivation und das Wollen der Subjekte unhintergehbar in die Sache und ihre möglichen Grenzen eingeht. Solche Grenzen sind z.B. ethischer Art, pragmatischer wie Risikobereitschaft oder auch Verfügung über Resourcen, Wertschätzung bestimmter Dinge u.Ä. mehr. Und da das so ist und der Horizont unbegrenzt gibt es immer eine begrenzte Zahl von Perspektiven über die man nicht sinnvoll sprechen und sich verständigen kann ohne sich vorab darauf zu einigen was wir eigentlich wollen. Kurz und gut: Der Streit ist vorprogrammiert! :rolleyes:

Insofern trifft vielleicht das (eher kritische gemeinte) Wort von Linux als (ernsthaftes) Hobby-Projekt die Differenzen zu BSD doch recht gut. Linus betont ja nicht umsonst den Spass an der Sache und sicherlich werden dem viele oder sogar die überwiegende Zahl von Entwicklern zustimmen, - zweifellos eine starke Motivation. Die Wurzeln von BSD liegen dagegen eher im Bereich einer Ingenieurs-Disziplin wobei die Übergänge - mit unerschiedlichen Akzenten in die eine oder andere Richtung - fließend sein dürften.

Wie immer bei solchen Differenzen geht es zunächst darum die jeweils andere Position zu verstehen um sich dann mit guten Gründen für die eine oder andere, oder auch eine dritte, zu entscheiden. Ansonsten produziert man nur fruchtlosen und überflüssigen Streit.

Ergänzend fällt mir noch der alte Streit zwischen Unix und den Lispern ein. Wir haben es also mit einem Trio zu tun das sich auf dem gleichen Spielfeld tummelt: Ingenieure, Wissenschaftler und Hobbisten, - in der Tat eine heikle Konstellation! :)
 
Die BSD-Wurzeln liegen nach meinem Geschichtsverständnis eher im akademischen Bereich und Spaß an der Sache spielte damals auch eine große Rolle.

Den Code-Raum als unbegrenzt zu sehen ist natürlich auch eine theoretische Idealisierung. In Wirklichkeit werden wir durch die Verfügbarkeit von Speicher eingeschränkt. Nur sind Massenspeicher halt so groß, dass die halt nie etwas tatsächlich begrenzen.
 
Die BSD-Wurzeln liegen nach meinem Geschichtsverständnis eher im akademischen Bereich...
Das ist so nicht ganz richtig. Ich finde leider im Moment die Quelle nicht. Zu der Zeit als sich das frühe Unix im akademischen Bereich verbreitet hat, gab es einen prinzipiellen Dissenz zwischen den MIT-Leuten, die überwiegend mit Lisp arbeiteten und aus denen dann die Lisp-Maschine hervorgegangen ist, und Berkely und eingen anderen Unis. Es ging im Kern um mögliche Fehler und deren Behandlung. Wärend die MIT- Leute auf Perfektion bestanden, also einen eher mathematisch-theoretischen Standpunkt bezogen, waren die anderen bereit gewisse Unzulänglichkeiten in Kauf zu nehmen, bezogen also einen eher ingeniösen Standpunkt. Natürlich war das zunächst eine nur akademische Diskussion aber damals waren Unis und die praktische Entwicklung von Soft- und Hardware eng miteinander verquickt und beeinflußten sich in hohem Maße gegenseitig.

Tannenbaum, von dem ich kürzlich ein Buch gelesen habe, hat das sehr schön deutlich gemacht: Er sagt dass ein Ingenieur danach fragt wie oft ein Fehler auftritt und wie relevant der ist. Wenn er höchst selten und nur wenig relevant ist interessiert ihn das nicht weiter und er ist nicht bereit daran viele Resourcen zu verschwenden. Hier kommt also ein ökonomisches Motiv ins Spiel. Ein Theoretiker wird - und muss - dagegen auf Perfektion bestehen. Dieser Dissenz setzt sich bis heute fort, z.B. in der Diskussion um funktionale oder imperative Sprachen. Wir kennen die Geschichte: Am Ende habe sich dann C und Unix gegen Lisp und Lisp-Maschines durchgesetzt.
...und Spaß an der Sache spielte damals auch eine große Rolle.
Klar doch, die haben damals bei BellLabs heftig gespielt. Was gibt es besseres als sich in einer Forschungseinrichtung auszutoben? Viele Möglichkeiten durchzuspielen ist die Mutter des Fortschritts :)
Den Code-Raum als unbegrenzt zu sehen ist natürlich auch eine theoretische Idealisierung. In Wirklichkeit werden wir durch die Verfügbarkeit von Speicher eingeschränkt. Nur sind Massenspeicher halt so groß, dass die halt nie etwas tatsächlich begrenzen.
Vor diesem Hintergrund bekommen die alten Fragen neue Relevanz. Es stellt sich dann die Frage ob die Techniken die bei einem OS von vielleicht 10 000 Zeilen gut funtionieren bei der Komplexität eines OS von 15 Millionen Zeilen noch angemessen sind. Es geht dabei nicht nur um Code, sondern auch um solche Dinge wie Dokumentation, Arbeitsorganisation, Werkzeuge, Ausbildung von Mitarbeitern u.Ä. mehr.
 
Vor diesem Hintergrund bekommen die alten Fragen neue Relevanz. Es stellt sich dann die Frage ob die Techniken die bei einem OS von vielleicht 10 000 Zeilen gut funtionieren bei der Komplexität eines OS von 15 Millionen Zeilen noch angemessen sind. Es geht dabei nicht nur um Code, sondern auch um solche Dinge wie Dokumentation, Arbeitsorganisation, Werkzeuge, Ausbildung von Mitarbeitern u.Ä. mehr.
Ich denke das findet man nur durch Ausprobieren raus. :(
 
Ich denke das findet man nur durch Ausprobieren raus. :(
Für das ausprobieren fehlen uns allen die Resourcen, also bleibt alles wie es ist, - nur ein bißchen mehr von allem, immer mehr! :(

Ich vermute der nächste wirkliche Inovationsschritt kommt aus dem embedded Bereich, da gibt es durchaus interessante Entwicklungen...
 
Ja, Ausmisten ist extrem wichtig. Immer mal wieder den alten Krempel raushauen, um einigermaßen Durchblick zu behalten. Das geht je nach Anwenderzahl (um die man sich kümmert) einfacher oder ist schwieriger. Siehe OpenSSL/LibreSSL. Die haben viel Stuss rausgehauen, aber auch vieles, wo es noch Leute gibt die da produktiv drauf bauen.

Aber selbst das hilft nicht. Wenn man ein Subsystem hat, das super geplant wurde und dann auch perfekt implementiert wurde, mit dem alles absolut in Ordnung ist, sogar so gut, dass es lange nichts zum Maintainen gibt, weil das Stück Code einfach seine Arbeit tut und dann gibt es da in den nächsten Jahren immer nur so kleine Anpassungen, die das ganze eben mit dem drum rum kompatibel halten, dann passieren zwei Dinge: Zum einen wird dieses "kompatibel halten" den Code mitunter ein wenig verschlechtern, aber vor allem wir nach X Jahren, wo die originalen Entwickler entweder andere Dinge im Kopf haben, nicht mehr mitentwickeln oder gar verstorben sind keiner mehr so den großen Durchblick haben.

Und ja, auch wenn es Doku gibt, der Code gut kommentiert ist, etc. Jetzt stellt euch mal vor das Subsystem wird so gebaut, funktioniert ein Jahrzehnt ohne Macken und dann gibt's da einen Bug, so ein krasser Edge-Case. Da muss sich trotzdem jemand mal die Mühe machen Doku zu lesen, Code zu lesen, verstehen, was da im Detail abgeht, damit man den Bug versteht und ihn dann so fixen kann, dass man keinen Unsinn macht. Ist doch gut, dass der Code gut war, dass da die letzten zehn Jahre dran rumfrickeln musste. Wäre der Code so mies gewesen, dass ständig jemand Bugs fixen muss gäbe es wohl eher jemand, der auch den Bug einfach schnell fixen kann. Will man deshalb schlechten Code? Natürlich nicht. Nur wenn dein Code mal groß genug ist, nicht weil du ein schlechter Programmierer bist, der nicht weiß, wie er den Code simpel hält, sondern weil das Problem entsprechend komplex ist, dann entstehen solche Probleme quasi von selbst, egal wie gut da gearbeitet wird.

Vieles von dem kann man sich ersparen, wenn man Code entfernt, nur muss es eben auch Sinn machen Code zu entfernen und guter Code, der noch verwendet wird wird auch nicht entfernt. Was man da braucht sind Leute, die Code reviewen, verstehen lernen und zwar auf die total langweilige Tour. Also so Code, von dem man zum einen annimmt, dass er eh keine Bugs hat, von dem man weiß, dass er auf wenig Einfluss hat, etc. Und mal ehrlich, wer tut sich das an, stundenlang, tagelang, ohne Bezahlung solchen Code zu lesen? Ja, ohne Bezahlung, weil auch wenn viele bezahlt am Kernel arbeiten, auch reviewen, dann ist die Chance, dass das derartigen Code betrifft sehr gering.

Der einzige Ort wo das dann doch passiert ist, wenn der Code Potential für Sicherheitslücken hat (also auf Grund von dem was er macht, mehr Potential, als andere Teile), aber der ist ja schon wieder verhältnismäßig spannend.

Wo Code ist gibt es auch Bugs. Alte teile Löschen hilft, aber wer da bei größeren Projekten so an das perfekte Maß glaubt, der ist da häufig im Irrglauben. Klar, man übertreiben, aber was perfekt ist ist eben unterschiedlich. Um OpenSSL als Beispiel zu nehmen. So Zeug wie VMS-Support interessiert wahrscheinlich niemanden hier. Weg mit dem Zeug, nur wenn du dann mit VMS arbeitest (das btw. auch ein sicheres und gut designtes OS sein soll), das kannst du wohl eher damit leben, wenn x86 gedroppt wird.

Alles nicht so einfach und Support für Architekturen ist da noch das simpelste Beispiel. Häufig ist das Thema was für Code man haben will und was nicht viel schwieriger. Und bei Programmierern, gerade bei nicht so erfahrenen will man natürlich auch noch, weil es einfach geht und cool wäre eher ein wenig mehr machen und selbst wenn man erfahrener ist, dann denkt man oft "ach, die paar Zeilen Code". Das summiert sich dann bei einem Projekt wie Linux, aber auch bei den BSDs. Vielleicht ist BSD ja auch nur besser, weil es weniger Entwickler gibt?
 
Das ist so nicht ganz richtig. Ich finde leider im Moment die Quelle nicht. Zu der Zeit als sich das frühe Unix im akademischen Bereich verbreitet hat, gab es einen prinzipiellen Dissenz zwischen den MIT-Leuten, die überwiegend mit Lisp arbeiteten und aus denen dann die Lisp-Maschine hervorgegangen ist, und Berkely und eingen anderen Unis. Es ging im Kern um mögliche Fehler und deren Behandlung. Wärend die MIT- Leute auf Perfektion bestanden, also einen eher mathematisch-theoretischen Standpunkt bezogen, waren die anderen bereit gewisse Unzulänglichkeiten in Kauf zu nehmen, bezogen also einen eher ingeniösen Standpunkt. Natürlich war das zunächst eine nur akademische Diskussion aber damals waren Unis und die praktische Entwicklung von Soft- und Hardware eng miteinander verquickt und beeinflußten sich in hohem Maße gegenseitig.
Wenn ich mich nicht völlig irre, spielte auch die Zugehörigkeit zu wissenschaftlichen Disziplinen eine gewisse Rolle. Am MIT entwickelte sich die Informatik eher aus der theoretisch-mathematischen Ecke heraus, während in Berkeley damals eher die Astronomen tonangebend waren (und das Geld für teure Rechnertechnik hatten). Am MIT ging es also noch am ehesten um etwas, das der heutigen Informatik (als wissenschaftlicher Disziplin) einigermaßen nahekommt, während in Berkeley die Astronomen und Astro-Physiker Systeme brauchten, mit denen sie Simulationen erstellen und Massendaten auswerten konnten. Und zwar mit den Gegebenheiten der damals verfügbaren Hardware, was für theoretischen Überbau und "schöne" Lösungen nur wenig Raum ließ.
 
Jetzt generalisiere ich mal und denke, das nicht nur Linux komplexer geworden ist, sondern das Leben an sich, die Gesellschaft, die Arbeitswelt und Vieles mehr. Hier scheint sich einmal mehr das sogenannte Peter Prinzip durchzusetzen.

Guckst Du hier: https://de.wikipedia.org/wiki/Peter-Prinzip

Was sich ursprünglich auf eine einzelne Person bezog, läßt sich auch insgesammt auf den sich entwickelnden Gesellschaftscharakter übertragen. Das aber ist kein Automatismus oder unentrinnbares Schicksal, denn wir dürfen nicht vergessen, das hier Menschen am Werke sind, die Ihr Lebensziel daran verwirklicht sehen, wenn alles komplex geworden ist. Immer höher, weiter, größer! Es ist der reinste Wahnsinn, was hier passiert. Dabei gilt einfach = genial. Dieses Phänomen läßt sich (fast) überall beobachten, nicht nur bei Linux. Wenn ich heute eine Debian Minimalinstallation vornehme, wandern wenigsten doppelt so viele Pakete auf die HD als in der Vorgängergeneration. Und deshalb liebe ich auch Unix oder FreeBSD. Das ist nämlich trotz mancher Behauptungen überhaupt nicht komplex, sondern besticht durch seine Einfachheit und die innerer Logik. Das gilt auch für die Installation. Über dieses Thema ließe sich vortrefflich ein ganzes Buch oder eine Doktorarbeit schreiben ....

Die Toleranzgrenzen sind bei Weitem überschritten und wir nähern uns den Eingriffsgrenzen, denn so kann und darf es nicht weiter gehen. Natürlich ist es gut und richtig, das Prozesse optimiert und verbessert werden. Aber nur dort, wo tatsächlich ein echter Mehrwert entsteht. Ein kleines Beispiel ist das neue Libreoffice 5. Ein bißchen Facelifting, die Buttons ein wenig aufgehübscht und schon wird es als Innovation vermarktet. Das es beim Firefox noch keine monatliches Update gibt, wundert mich sehr. Nachhaltigkeit sieht für mich anders aus.
 
Wir kennen die Geschichte: Am Ende habe sich dann C und Unix gegen Lisp und Lisp-Maschines durchgesetzt.

Das hatte aber nichts damit zu tun, dass die Herangehensweise am MIT falsch gewesen wäre. Die Hardware ist nur irgendwann "überholt" worden. Letztlich hat also nicht das bessere Konzept gewonnen, sondern die Geschwindigkeit. Man konnte Lisp-Maschinen irgendwann preiswerter und schneller auf einem dieser neumodischen "PCs" emulieren, da brauchte man Symbolics nicht mehr.
 
Was ist denn dass "bessere" Konzept? ...

Kommt wie immer auf den Anwendungsfall an bzw. auf den eigenen persönlichen Standpunkt.
 
Das "bessere" Konzept ist das technisch überlegene. Ich wage zu behaupten: Gäbe es heute noch Lispmaschinen, hätten PCs ihnen nur wenig voraus. Die einzige nennenswerte "Einschränkung" ist ja, dass man Lisp nutzen muss.
 
Ich wage zu behaupten: Gäbe es heute noch Lispmaschinen, hätten PCs ihnen nur wenig voraus.
Wenn überhaupt! Klar, damals waren die Lisp-Maschinen vergleichsweise langsam da Lisp z.T wie blöd Listen-Elemente konstruiert die dann bald wieder verworfen werden. Außerdem war die Kompiler-Technologie damals noch nicht so weit fortgeschritten wie heute. Dann muss man bedenken dass die heutigen Prozessoren eben primär universelle Stack-Maschinen sind während Lisp wie einige andere Sprachen primär einen effektiven Heap benötigt.
Die einzige nennenswerte "Einschränkung" ist ja, dass man Lisp nutzen muss.
Selbst das ist kein ernsthafte Einschränkung denn in Lisp läßt sich vergleichweise leicht jede andere Sprache implementieren.

Dennoch: Wer zu spät kommt, den bestraft bekanntlicherwiese die Geschichte. Außerdem sind die heutigen Prozessoren sicherlich vielseitiger und vielleicht auch weniger anspruchsvoll. Es gibt einige Wege in der Geschichte der Computer-Techik die nicht weiter beschritten worden sind was heißt nicht das sie nicht wegen ihrer technischen Meriten irgendwann wieder herausgekramt werden wie z.B. Forth-Maschinen, Transputer u.Ä.m. Allerdings wird die technische Entwicklung nicht allein von technischen Aspekten vorangetrieben sondern genau so von wirtschaftlichen und politschen, - nicht immer zu deren Vorteil.
 
Zurück
Oben