Von phantasielos am Mi, 30. Oktober 2019 um 22:15 #
Wenn jedes Programm, das eine Funktionalität doppelt aus Debian verbannt würde, dann würde die Gesamtpaketzahl um 99,5% abnehmen. Ist das dein Vorschlag? Oder willst Du ein neues Problem konstruieren, indem Du unterstellst, es will jemand mehrere Init-Systeme parallel starten?
Es geht mir darum, zu demonstrieren, dass es sehr schwierig bis unmöglich ist, bei einem Betriebssystem zentrale Komponenten auswechselbar zu machen. Debian hat das sogar beim Kernel mal probiert, als es alternativ zu Linux einen BSD- und einen Hurd-Kernel gab, allerdings war nur ein Teil aller Pakete jemals auf kFreeBSD oder Hurd lauffähig, da fast alle Entwickler und Anwender weiterhin mit Linux arbeiteten und sich für die anderen Kernel nicht groß interessierten.
Das gleiche passiert jetzt bei den Init-Systemen. systemd ist der Default, daher nutzen alle systemd, und kaum ein Entwickler hat Lust, dafür Zeit aufzuwenden, dass sein Paket auch mit allen möglichen anderen Init-Systemen funktioniert. Es macht also für eine Distribution durchaus Sinn, sich auf einen Kernel, ein Init-System, einen Paketmanager, eine libc usw. festzulegen.
Das mag schon Sinn ergeben, aber dann hätte die Frage damals auch so diskutiert werden sollen. Es ging damals ja "nur" um den Default-Init-Manager.
Solche Salami-Taktiken (scheibchenweise) sind heute leider fast schon üblich (da spielt wohl auch bei Debian viel Zeitgeist mit), nur ob dabei was (basisdemokratisches) Gescheites rauskommt, das wäre/ist eine andere Frage.
Wieso "Salamitaktik"? Es liegt doch in der Natur der Sache, wenn das Neue einmal an Fahrt/Momentum/Mindshare gewinnt, weitere Entwickler darauf setzen und Abhängigkeiten produzieren, die sie teils nicht einmal realisieren, weil sie distributionsagnostisch die Plattform Linux+systemd annehmen. Und das finde ich nicht automatisch verwerflich - jedenfalls kommt es hier auf den expliziten Kontext an.
Ich sage nicht, es ist automatisch verwerflich, ich sage nur, dass es für mich nicht passt und dass ich persönlich es besser fände, wenn Systeme schlank und rank sind. Denn, alles muss gewartet werden und ich möchte doch, dass am Ende dieser Job von möglichst vielen Menschen machbar ist.
P.S: Alle 50 Zeilen Code gibt es statistisch gesehen "Fehler", siehe dazu:
Deckt sich im übrigen mit eigenen Erfahrungen -- sehr leidvoll zudem. Darum sind mir Systeme mit weniger Code lieber als Systeme, die möglichst gross sind/werden (das gilt nun für alle Software, nicht "nur" für SystemD).
Ich (und vermutlich die meisten Entwickler) sehen das ähnlich und wollen auch schlanke, wartbare Systeme mit wenig Code.
Aber was sollen die Entwickler Ihrer Meinung nach tun, wenn die Anforderungen an die Software stetig steigen, und alte Annahmen und Konzepte einfach nicht mir stimmig oder zeitgemäß sind?
Sehen Sie es auch mal so: Nur weil systemd gewisse Features implementiert, die unter sysvinit kein Analogon besitzen, erfüllt es Anfoderungen, die darauf aufbauende Funktionen möglich macht, die vorher nicht möglich waren, oder reduziert die nötigen Zeilen an Quelltext in Anwendungen (vollständige Prozess- und Ressourcenüberwachung/-verwaltung usw.). Also führt systemd auch zu einer Reduktion an Code - vielleicht nicht netto, aber man muss das ja auch im Verhältnis zum Gewinn neuer Funktionalität im Anwendungsbreich sehen. Und der zusätzlich Code liegt dann zentral in systemd, und wird von viel mehr Nutzern verwendet, von viel mehr Entwicklern begutachtet und verbessert. Außerdem unterliegt der Code dann der Infrastruktur des sytemd-Projekts und durchläuft entsprechende Tests wie CI und Fuzzing. Der Ökosystem-Overhead sinkt. Ist das kein erstrebenswerter Vorteil im Sinne der OSS-Community?
systemd ist nicht der heilige Gral und teils stark verbesserungswürdig - keine Frage. Man muss immer bewerten, ob systemd im konkreten Anwendungsfall tatsächlich Sinn ergibt, als z.B. kein "overkill" wäre.
Wenn jedes Programm, das eine Funktionalität doppelt aus Debian verbannt würde, dann würde die Gesamtpaketzahl um 99,5% abnehmen. Ist das dein Vorschlag?
Oder willst Du ein neues Problem konstruieren, indem Du unterstellst, es will jemand mehrere Init-Systeme parallel starten?
Es geht mir darum, zu demonstrieren, dass es sehr schwierig bis unmöglich ist, bei einem Betriebssystem zentrale Komponenten auswechselbar zu machen. Debian hat das sogar beim Kernel mal probiert, als es alternativ zu Linux einen BSD- und einen Hurd-Kernel gab, allerdings war nur ein Teil aller Pakete jemals auf kFreeBSD oder Hurd lauffähig, da fast alle Entwickler und Anwender weiterhin mit Linux arbeiteten und sich für die anderen Kernel nicht groß interessierten.
Das gleiche passiert jetzt bei den Init-Systemen. systemd ist der Default, daher nutzen alle systemd, und kaum ein Entwickler hat Lust, dafür Zeit aufzuwenden, dass sein Paket auch mit allen möglichen anderen Init-Systemen funktioniert. Es macht also für eine Distribution durchaus Sinn, sich auf einen Kernel, ein Init-System, einen Paketmanager, eine libc usw. festzulegen.
Das mag schon Sinn ergeben, aber dann hätte die Frage damals auch so diskutiert werden sollen. Es ging damals ja "nur" um den Default-Init-Manager.
Solche Salami-Taktiken (scheibchenweise) sind heute leider fast schon üblich (da spielt wohl auch bei Debian viel Zeitgeist mit), nur ob dabei was (basisdemokratisches) Gescheites rauskommt, das wäre/ist eine andere Frage.
Wieso "Salamitaktik"? Es liegt doch in der Natur der Sache, wenn das Neue einmal an Fahrt/Momentum/Mindshare gewinnt, weitere Entwickler darauf setzen und Abhängigkeiten produzieren, die sie teils nicht einmal realisieren, weil sie distributionsagnostisch die Plattform Linux+systemd annehmen. Und das finde ich nicht automatisch verwerflich - jedenfalls kommt es hier auf den expliziten Kontext an.
Ich sage nicht, es ist automatisch verwerflich, ich sage nur, dass es für mich nicht passt und dass ich persönlich es besser fände, wenn Systeme schlank und rank sind. Denn, alles muss gewartet werden und ich möchte doch, dass am Ende dieser Job von möglichst vielen Menschen machbar ist.
P.S: Alle 50 Zeilen Code gibt es statistisch gesehen "Fehler", siehe dazu:
https://www.quora.com/What-is-the-average-ratio-of-bugs-to-a-line-of-code
Deckt sich im übrigen mit eigenen Erfahrungen -- sehr leidvoll zudem. Darum sind mir Systeme mit weniger Code lieber als Systeme, die möglichst gross sind/werden (das gilt nun für alle Software, nicht "nur" für SystemD).
Ich (und vermutlich die meisten Entwickler) sehen das ähnlich und wollen auch schlanke, wartbare Systeme mit wenig Code.
Aber was sollen die Entwickler Ihrer Meinung nach tun, wenn die Anforderungen an die Software stetig steigen, und alte Annahmen und Konzepte einfach nicht mir stimmig oder zeitgemäß sind?
Sehen Sie es auch mal so: Nur weil systemd gewisse Features implementiert, die unter sysvinit kein Analogon besitzen, erfüllt es Anfoderungen, die darauf aufbauende Funktionen möglich macht, die vorher nicht möglich waren, oder reduziert die nötigen Zeilen an Quelltext in Anwendungen (vollständige Prozess- und Ressourcenüberwachung/-verwaltung usw.).
Also führt systemd auch zu einer Reduktion an Code - vielleicht nicht netto, aber man muss das ja auch im Verhältnis zum Gewinn neuer Funktionalität im Anwendungsbreich sehen. Und der zusätzlich Code liegt dann zentral in systemd, und wird von viel mehr Nutzern verwendet, von viel mehr Entwicklern begutachtet und verbessert. Außerdem unterliegt der Code dann der Infrastruktur des sytemd-Projekts und durchläuft entsprechende Tests wie CI und Fuzzing. Der Ökosystem-Overhead sinkt.
Ist das kein erstrebenswerter Vorteil im Sinne der OSS-Community?
systemd ist nicht der heilige Gral und teils stark verbesserungswürdig - keine Frage. Man muss immer bewerten, ob systemd im konkreten Anwendungsfall tatsächlich Sinn ergibt, als z.B. kein "overkill" wäre.