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