oreissig's Unix-Rant
Häufiger werd ich gefragt, warum ich eigentlich auf Windows rumhocke, obwohl das doch weder besonders cool, noch besonders mächtig ist, und auch nicht gerade von einer besonders sympathischen Firma hergestellt wird (siehe Kooperation MS und NSA). Warum setze ich denn nicht wie die meisten Nerds mit vergleichbarer Nerdigkeit auf Linux (oder ein anderes Unix-artiges System)?
Tja, gute Frage eigentlich. Etwas Faulheit ist dabei, aber das ist es nicht. Ich kann schon grundlegend Linux, das ist nicht das Ding. Auch meine Apps unter Windows gibts praktisch durch die Bank auch für Linux, das ist es auch nicht. Es ist eine tiefergehendere Unzufriedenheit mit dem Unix-Ökosystem, die ich gern mal detailliert darlegen will, um zu schauen, ob ich mich einfach nur in einer One-Man-Filterbubble befinde, oder vll wirklich nen validen Punkt habe. Ich fang daher mal an mit den von mir erlebten Symptomen und versuche dann darzulegen, warum ich glaube da ein viel fundamentaleres Problem zu haben.
Symptom
Natürlich hab ich schonmal Linux gemacht, nicht nur einmal. Meistens zwar nur in der VM, weil bequem, aber ich hatte schon etliche Linuxe. Bei manchen hab ich verrückte Dinge getan, irgendwelche krassen configs zerwurstet, krasse Kernels gebacken, aber in den allermeisten Fällen wars einfach nur ne default installation ohne viel customization und dann noch ne kleine Hand voll Allerweltstools über den Paketmanager nachgeladen. So weit, so gut. Dann geht Zeit ins Land und es gibt neuere Versionen. Also Paketmanager fuck yeah, dazu gibts das Ding ja, schön geapt-get upgradet oder gepacman -Syut. Dann gibts zwei Fälle:
1.a) es ist eine Release Distro, dann bekomm ich das Update von foo 2.3.0.21 auf 2.3.0.22, obwohl der Rest der Welt ungefähr bei 2.5.1 oder 3.0 ist.
1.b) beim Update des Releases geht mir das Scheißding kaputt. Paketmanager sagt "update erfolgreich", neustart, kernel panic. Bin da etwas deb-lastig unterwegs, aber konkret ist mir das exakt so schon bei Debian, Ubuntu und Mint passiert.
2. es ist eine rolling release Distro, bei der einfach ständig immer mehr Kleinigkeiten kaputtgehen. Ich will jetzt gar nicht mit der Diskussion anfangen, ob das von Arch eine gute Idee ist oder nicht, dass der Paketmanager keine automatischen Migrationen macht, sondern mich lieber auf das zugrundeliegende Problem vertiefen:
Warum gehen mir alle meine Linuxe kaputt, obwohl ich nichts außergewöhnliches mit ihnen mache, obwohl ich unter Windows oder auch Android immer bleeding edge bin? Aktualität (deren Mangel auch immer gern als "Stabilität" bezeichnet wird, wobei ich da eher ne andere Definition hätte) kann es nicht sein. Ich hab unter Windows immer den neusten Firefox, die neusten Windows-Updates, etc. und nie nen Kernel Panic. Selbiges am Handy unter Android.
Hypothese
Ich behaupte, dass das Problem ganz fundamental in der Struktur klassischer Unixsysteme begründet liegt. Unix ist gedacht als eine integrierte Umgebung, in der alles total super aufeinander abgestimmt ist, sodass sich der Entwickler dabei voll austoben kann. Das ist toll für den Nutzer (der dem Urgedanken nach praktisch immer Softwareentwickler war). Er hatte einen tollen Baukasten und jede Menge Flexibilität, aus den Bausteinen Sachen zusammenzustecken.
Das Dateisystem sieht genau so aus: ein integrierter Baukasten. Alles ist perfekt miteinander verwoben. Alles liegt an seinem Ort: Konfigs in /etc, binaries in /usr/bin (oder einem der anderen bins), Programmdaten unter /var, Nutzerdaten im /home und temporärer Krams im /tmp. Toll, alle temporären Dateien liegen unter /tmp, alle binaries in (einem der vielen) .../bin. Zwischen Programmen muss man ja nicht trennen, ist ja schließlich alles ein integriertes System. Da ists egal, ob man sh, grep oder firefox hat, liegt alles in den selben Verzeichnissen. Gut integriert also.
Oder andersgesagt: der reinste Alptraum, der Paketmanager unter Linux managt alles mögliche, aber keine Pakete, weil Pakete sowas wie nen Karton haben, der sie abgrenzt. Das ist eher eine Gemüsesuppe, es gibt überhaupt keine Komponentisierung, alles hängt mit allem zusammen, alles ist ein globaler Namensraum. Um es nochmal mit der Analogie des Programmierens zu bringen: Angenommen man macht prinzipiell alle Variablen public, greift zünftig zum GOTO, und fängt dann an seine 10 Mio Lines of Code-App zu schreiben. Kann man machen, vll klappts sogar, aber nach all den Jahren der Computerei hat sich halt herausgestellt, dass ein sowas wie Abstraktion und Information Hiding durchaus ganz hilfreich sein können. Dass man Komponenten entwickelt, die man größtmöglich voneinander abgrenzt. Warum sollte das bei der Betriebssystemstruktur nicht auch so sein?
Ist bisschen wie LISP: klassische LISP-Systeme hatten als unheimlichen Vorteil ihre Integriertheit und die Flexibilität des Entwicklers. Da gab es auch keine störende Trennung zwischen App und OS, jeder Entwickler konnte Basisroutinen nach seinen Belieben verändern optimieren, wodurch man schnell Dinge programmiert bekommen konnte. Genau darum gings, schnell Dinge tun, deswegen waren LISP-Machines so unglaublich beliebt bei den großen Hackern der Zeit (Stallman). Der Nachteil ist natürlich, dass man die App nicht einzeln irgendwie weitergeben kann, sondern nur die sog. World, d.h. quasi einen gesamten Plattendump. Aus dem General Purpose Computer wurde damit quasi ein Single Function Device...
Die Offenheit
Linux-Systeme sind ja offen und so. Und kompatibel, weil POSIX. Und überhaupt. Tja, finde ich irgendwie nicht so. Eigentlich ist man seinem Distributor ziemlich ausgeliefert, weil man standardmäßig alle seine Software ausschließlich von ihm bekommt.
Pakete anderer Distros installieren? nope
Selbst wenn sie den selben Paketmanager verwenden? hell no
Klar kann man sich alternative Repos in seinen Paketmanager reinladen, und dann? Tendenziell ist das ja kein völlig isoliertes Ökosystem, bei dem man unabhängige Komponenten zusammenstecken kann, wie man will. Der große Vorteil von Paketmanagern unter Linux ist ja, dass er Abhängigkeiten auflöst, die die Komponenten in dem perfekt integrierten System Unix untereinander haben. Nur leider ist die Deklaration nur die halbe Wahrheit. Die Abhängigkeit heißt vll "libsqlite, Version >=3.8 <4.0", aber mehr als ein String ist das nicht. Wenn der Krams doch nicht zusammenpasst (z.B. weil in zwei Paketquellen das selbe Paket doppelt drin liegt, nur mit anderen Flags compiliert wurde), dann rumpelt der Karton. Jede zusätzliche Paketquelle im Paketmanager ist eine zusätzliche Gefahr, sich sein Basissystem (und damit insbesondere auch alle Apps, die man gar nicht aus dem neuen Repo geladen hat) zu zerschießen.
Mal kurz ein Blick zu Windows:
Man könnte wahrheitsgemäß sagen, dass Windows kacke ist, weils keinen Paketmanager hat. Man könnte aber auch sagen, dass Windows das dezentralisierteste Softwaremanagement überhaupt hat. Wenn ich nen Firefox will, dann geh ich dafür nich zu Microsoft. Natürlich nich, MS kann vll Betriebssysteme bauen, aber beim Browser traue ich denen nicht, erst Recht traue ich denen nicht zu die Mozilla-Codebasis zu warten. Deswegen hol ich mir den Firefox von Mozilla direkt. Das finde ich ehrlichgesagt sehr vernünftig.
Warum sollte das woanders jetzt anders sein, nur weil da vll nen anderer Kernel druntersteckt? Ändert an dem Grundprinzip überhaupt nichts, trotzdem pflegen alle klassischen Linuxdistributionen ihren größtenwahnsinnigen Allmachtsanspruch, dass sie das Software-Ökosystem bereitstellen.
Die Konzequenzen
Abgesehen davon, dass mit die Linuxe wie Fliegen bei der Bruzzellampe weggestorben sind, waren die meisten Probleme, die ich beschrieben habe bisher eher konzepzioneller Art. Schauen wir doch mal, was das wirklich bedeutet:
Die Pakete werden beim Distributor betreut. Erstmal ganz unabhängig davon, wie gut der seinen Job macht, selbst wenn da die brilliantesten Brainiacs sitzen, ist es immer ein weiteres Glied in der Kette von der Tastatur des (eigentlichen) Entwicklers zu meinem Bildschirm, und damit eine weitere potenzielle Fehlerquelle. Das mit den brillianten Brainiacs ist natürlich geschönt, die wirklich guten Leute entwickeln natürlich selbst Software oder betreuen zumindest die lustigen Sachen wie den Kernel, und machen nicht so was langweiliges wie Commits einer mäßig verbreiteten Software zwischen zwei Repositories zu mergen. Das ist die langweiligste Aufgabe, die ich mir überhaupt nur vorstellen. Und diese Langeweile schlägt sich natürlich auch auf die Qualität nieder. Bei Monotonem trott rutschen nunmal schnell Flüchtigkeitsfehler durch, und plötzlich ist Debians OpenSSL ein offenes Scheunentor. Das war kein versehen, das Problem hat systematische Ursachen.
Viel besser als langweilige, sinnlose und repetitive Tätigenkeiten von einer Heerschaar an Freiwilligen machen zu lassen wäre einfach, den Krams nicht zu machen. Krams zwischen Repos mergen ist so aufwändig, und das macht man für jedes Scheiß Paket in jeder Scheiß Version, und exakt das selbe macht jede Scheiß Distro. Diese unfassbare Verschwendung menschlicher Energie macht mich einfach fassungslos. Stellt euch nur mal vor, diese Leute würden was richtiges machen? Das entsprechende Projekt wirklich mal nach vorn statt mit der n+1ten Rückportierung immer nur zurück zu bringen. Was könnte man da alles machen...
Aber stattdessen versucht man weiterhin, dem Abhängigkeitswirrwar des integrierten Systems Unix Herr zu werden, indem man 50000 Pakete zueinander kompatibel hält, und hofft, dass der Nutzer keine weitere Paketquelle nachlädt, weil eine einzige anders compilierte glibc den gesamten Turm sofort einstürzen lassen könnte. Das Unix-Paradigma hat gut funktioniert, als der Entwickler sich einmal sein eines Unix-System installiert hat, und dann angefangen hat, seine eigenen Sachen drauf zu entwickeln. So viele Änderungen hat er nicht geschafft, und sie waren auch immer aus seiner Hand. Diese Illusion, dass man eine so große Softwarelandschaft wie die von heute nach wie vor mit der hemdsärmeligen Einstellung bewältigen kann, hält sich jedoch hartnäckig.
Das treibt dann solche Blüten wie die o.g. Definition von "Stabilität". Stabilität heißt "kein Ärger für den Distributor", und nicht etwa "keine Probleme für den Nutzer". Systeme wie Debian mit sowas wie 50k Paketen können garnicht anders, als nie irgendwas signifikant zu Updaten, weil das wollknäulartige Netz der Abhängigkeiten eine unüberschaubare Kaskade weiterer Updates nach sich ziehen würde. Genau dies: Dass man nicht mal Änderungen an einer Stelle macht und dabei ausschließen kann, dass komplett andere Teile des Systems nicht in Flammen aufgehen, das ist ein charakteristisches Merkmal von schlechter Architektur. Von Legacy-Software mit viel GOTO.
Und dabei ist es so unnötig...
Eigentlich gibt es zwei Probleme. Das eine ist wie schon erwähnt die Unordnung im Dateisystem. Klar, ist Kacke, aber das kann man vll sogar irgendwie noch gemanagt bekommen.
Das größere Problem sind die Abhängigkeiten der Pakete untereinander, vor allem dieses gesamte Konzept der shared library. Anfangs gabs das ja in Unix gar nicht, da waren alle binaries static. Als Unix dann populärer wurde und zunehmend dafür eingesetzt wurde, eine große Anzahl von Leuten auf völlig unterdimensionierten Kisten arbeiten zu lassen, musste man Zwangsweise optimierungen vornehmen, so weit, so klar. Wenn man 20MB Plattenplatz hat, will man seine libs mit nicht für jedes Programm neu rumliegen haben, da nutzt man Synergien.
Heute ist das ein Relikt aus einer längst vergangenen Zeit. Ich hab ne 500GB-Platte in meinem Notebook, das ist mir so egal ob libjpeg 1x oder 500x rumliegt, wenn das Ding nur paar k groß ist. Letztens für mein T61 ne SSD gekauft und hab üppige 256 dieser verflucht schnellen GBs für deutlich unter 100€ bekommen. Wozu das rumgeknauser bei den libs? Die Platzfresser sind eh andere Sachen auf dem System...
Vor allem: die Unix-Familie ist das einzige fucking OS auf dem gesamten Erdball, bei dem Abhängigkeiten zwischen jeder Art von Komponenten auftreten können. Bei allen anderen gibts 1x das OS und X-fach die Apps. Die Apps dürfen alle das OS nutzen und dagegen linken und whatnot, aber nicht untereinander. Wenn sie was brauchen, was nicht vom OS kommt, dann bringen sie das i.a.R. selbst mit (von paar Frameworks wie der JVM oder so mal abgesehen).
Windows macht das so.
MacOS macht das so.
MacOS X macht das so.
iOS macht das so.
Android macht das so.
Windows Phone macht das so.
WebOS macht das so.
Fucking OpenVMS macht das so.
Nur Linux bildet sich ein, dass der Linuxkernel, die glibc, xeyes und Firefox alles uniform behandelt werden kann. Kann man machen, ja, genauso wie man auch alle Variablen in einem 10 Mio LOC-Prog uniform public machen kann und alle Kontrollflüsse uniform mit GOTO machen kann. Kann man machen, ja. Die daraus resultierende Komplexität beherrscht keiner.
Meine Utopie
Stellt euch mal vor, es würde anders gehen. Sowas wie die PBIs bei PC-BSD (von denen es viel zu wenige gibt, als dass das ne ernstzunehmende alternative wäre): Ein Paket, bei dem das Programm alle seine Libs selbst mitbringt. Firefox 31 nutzt libjpeg-08.15? fein. GIMP hingegen die libjpeg-08.15 mit 1337-hacks? okay. und KDE braucht libjpeg-47.11? ist mir soo egal. wenn einfach jede App nen eigenes root hat, in dem es sich austoben kann wie es will, is mir das alles rille. dann kann ich mir auch bei einem Ökosystem aus 50k Paketen mal eben ne neue Major Version glibc bauen, weil ich weiß, dass ich keine 49999 anderen Pakete überprüfen muss.
Man käme mal aus der Schockstarre raus, wenn man die panische Angst vor unkontrollierbaren Seiteneffekten überwunden hätte, und könnte anfangen aktuelle Software auszuliefern, so schwierig ist das nämlich gar nicht. Stellt sich raus: Mozilla macht auch Qualitätssicherung, und wenn man den neuen Firefox 2h nach dem Release zieht, wird er nicht die ganze Zeit wild rumcrashen.
Noch ein kleiner Nebeneffekt: Pakete zwischen Distros zu portieren wäre deutlich einfacher. Ggf. nicht völlig ohne Arbeit, aber mit ein paar Verzweigungen dürfte es ein leichtes sein, ein Paket zu bauen, welches sowohl auf den debian-artigen, als auch den Redhatigen und SUSigen läuft. Dann wäre es vll auch für Mozilla mal möglich, selbst den Firefox zu machen, weils nur noch ein Paket und keine 9001 mehr wären. Und dann könnten die tausenden Paketmaintainer der großen Distros entweder Eier schaukeln (was ich ihnen gönnen würde) oder vll sogar sinnvolle Dinge tun, und nich nur um die hausgemachten Probleme schlecht komponentisierter Legacy-Software workarounden...
(Dieser Beitrag wurde zuletzt bearbeitet: 26.08.2014 21:05 von oreissig.)
|
