1. Ich stimme Ihnen grundsätzlich zu. Ich denke, dass Fragmentierung insbesondere im OSS-Ökosystem einen Preis hat. Und genau dieser Preis schlägt hier zu. Debian schleppt inzwischen so viele Altlasten mit, die sich mit neu integrierten Lösungen teils stark überschneiden oder/und unerwünschte Nebeneffekte generieren. (z.B.: Wozu gibt es parallel zu systemd noch das statische ifupdown? An wie vielen Stellen kann man inzwischen die umask konfigurieren und keine macht das, was man eigentlich möchte, siehe hier?)
2. Ich bin gespannt, wie das Enden wird. Werden wir wieder ein nicht enden wollendes Debakel erleben, sodass weitere wichtige Entwickler Debian den Rücken kehren, weil sie von der Debatte und ihrer Debattenkultur vergrätzt werden? Jedenfalls halte ich dieses Wagnis im Bezug auf das Weiterbestehen Debians in seiner bisherigen Form für äußerst riskant. Wahrscheinlich ist der Schritt aber nötig und sogar wohl möglich der Richtige™ um Debian die Chance einer langfristigen Perspektive zu eröffnen, denn ewig kann Debian den ganzen Ballast nicht mitschleppen, weil das Projekt sonst darunter zusammenbrechen würde. Leider ist das nicht ohne Risiko. Debian steht an einem Scheideweg.
3. Ganz unabhängig von der Debatte über Initsysteme oder systemd im Speziellen: Ich finde, dass Debian schon lange kein "universales Betriebssystem" mehr ist, falls es das überhaupt jemals gewesen ist. Das liegt allein schon daran, dass Linux selbst nicht universal ist. (GNU Hurd und kFreeBSD lasse ich mal außen vor, aber auf die trifft das auch nicht wirklich zu, es sind mit Ausnahmen eher wenigermächtige Alternativen zu Linux.) Man denke also bspw. an Systeme ohne MMU, mit harten Real-Time-Voraussetzungen oder Anforderungen einer stabilerer und besserer (User-Space-)Treiberinfrastruktur. Ich bezweifle sogar, dass es so ein "universelles" Betriebssystem überhaupt geben kann, denn es wäre sozusagen perfekt.
Ich möchte nicht falsch verstanden werden, denn ich mag das Debian als Betriebssystem und setze es auch ein, aber dieses Motto "the universal OS" ist mir schon immer sauer aufgestoßen. Was zur Hölle soll das eigentlich bedeuten? Und warum sollte das eine Priorität der meisten Anwender sein ? Use the right tool for the right job - Nicht alles ist ein Nagel!
Falls der Hammer aber so groß und mächtig sein sollte, dass jedes Problem so wie ein Nagel anmutet, dann kann auch etwas mit dem Hammer nicht stimmen. Er wäre zu groß, schwer und komplex. Ihn zu führen/verwenden, zu pflegen, zu reparieren und zu "verwalten" wird in diesem Fall nicht trivial sein.
Ergo: Man muss Debian auch wartbar halten und Altlasten (technical debt) rechtzeitig konsolidieren, wenn es neue Aufgabenfelder erreichen und Probleme lösen können soll. Dabei muss alte Funktionalität nicht unbedingt flöten gehen. Die Umsetzung muss ggf. nur angepasst werden.
Zum Glück existieren gute Alternativen. Daher heißt es für mich nun: Erstmal Abwarten und Teetrinken!
So so, es gibt zu viele "Altlasten". Gut, dann werden diese bereinigt, aber doch nicht um den Preis, dass das, was danach kommt, deutlich grösser ist/wird?
Genau das aber passiert aktuell. Software wird aufgeblasen, bis sie platzt. Dumm nur, dass mit SystemD dann auch PID 1 platzt.
Was meinst Du eingentlich mit "Alternativen", wenn ich Deine Kommentare lese, meinte ich doch, dass Du sehr an "Debian" hängst, oder welches Linux würdest Du denn empfehlen wollen?
systemd ist nicht der heilige Gral und an diversen Stellen stark verbesserungswürdig. Ich kann Ihre Haltung trotzdem nicht nachvollziehen/teilen.
So so, es gibt zu viele "Altlasten".
Ja, und das fängt beim Linux-Kernel an, geht bei der glibc weiter und akkumuliert sich dann ggf. in den darauf aufbauenden Schichten. Da wird nur aus Legacy-Kompatibilitätsgründen alter, verrottender, nicht standardkonformer und teils kaputter Code behalten. Man denke bspw. an die verschiedenen WiFi-Stacks im Kernel, an die ganzen syscalls, an deren Namen Nummern angehängt werden, weil die anderen sich als unreparierbar kaputt erwiesen haben, oder an die ganzen ioctls-Tricksereien, sowie an die Inkonsistenzen und Kompatibilitätseinträge bezüglich /proc und /sys. Auch die heute quasi irrelevanten und überholten glibc-Features tragen ihren Teil dazu bei (ineffiziente Handhabung von Byte-Kodierungen via gconv, Sun RPC, Fehlen von Openwall-style TCB shadow, das Verhalten einiger Funktionen unter Systemressourcenmangel inkl. sperriger/unpraktikabler Fehlercodes). Und das ist bestenfalls die Spitze des Eisbergs, denn das zieht sich hoch bis in die Distro-spezifischen Codes à la SysV-Init-Skripte, initrd/initramfs/dracut-Implementierungen, ifupdown-Skripte etc. pp.
Das ist teils gammliger, ungewarteter Code, der ggf. Distro-spezifisch ist - unnötigerweise. Das ist keine Softwarediversität, sondern größtenteils sinnlose Fragmentierung.
Gut, dann werden diese bereinigt, aber doch nicht um den Preis, dass das, was danach kommt, deutlich grösser ist/wird?
Ich weiß nicht, ob man das so pauschalisieren kann. Die Entwickler streben in der Regel eigentlich danach, möglichst schlanken und wartbaren Code zu entwickeln und zu pflegen.
Haben Sie die "Größe" der verschiedenen Alternativen mal verglichen? Auf der Grundlage welcher Metrik? Oder gibt es da fertige und fundierte Analysen?
Auf systemd mag das zutreffen. Ich denke aber, dass es darauf ankommt, wie man zählt. Und so direkt kann man das meiner Ansicht in diesem Fall gar nicht, denn: i) Was ersetzt systemd denn? Laut den Kritikern offensichtlich nicht nur sysvinit. Man müsste also alle optionalen Teile systemds von so einem Vergleich ausschließen. ii) Selbst falls man Punkt i) respektiert, glaube ich, dass der Kernanteil systemds für init funktionell mächtiger ist als sysvinit je sein könnte, weshalb es de-facto auch ersetzt worden ist und nur noch wenig Pflege benötigt und erhält. Wer mehr kann, was offensichtlich vielerorts gefragt war und ist, braucht dafür in der Regel auch mehr Code. Wie berücksichtigt man das in einem direkten Vergleich der beiden? iii) Wie sieht das aus, wenn man danach noch die Abhängigkeiten hinzuzählt? In vielen Distros setzt sysvinit neben den Initskripten auf Bash auf. Bash besteht derzeit aus circa 225k Quelltextzeilen und wird von einer einzigen Person ohne richtiges Versionsverwaltungssystem gepflegt.
Genau das aber passiert aktuell. Software wird aufgeblasen, bis sie platzt. Dumm nur, dass mit SystemD dann auch PID 1 platzt.
Was heißt "platzt"? Schmiert PID1 bei Ihnen dauernd ab? Benötigt es zu viele Ressourcen?
Ja, es kann und tut einfach mehr, weil die Anforderungen über die Jahre gestiegen sind. SysV ist für IT-Verhältnisse steinalt. Zu der Zeit als SysV bzw. deren Vorläufer entworfen worden sind, hatte niemand diese Anforderungen auf dem Schirm.
Wenn man systemd auf dem kleinen embedded-Gerät, auf dem Mikrocontroller oder im minimalen Container ausführt, falls das überhaupt möglich wäre, hat man sich für das falsche Werkzeug entschieden. Viele Distributionen und Android setzen systemd aus gutem Grund nicht ein. systemd ist für Mainframes, Server und leistungsfähige Workstations und Desktops/Laptops mit Plug&Play-Hardware oder anderen ereignis-/abhängigkeitsbasierten Anforderungen geeignet.
Meinen Sie an dieser Stelle vielleicht, dass mit systemd Abhängigkeiten auf der Ebene des sogenannten "tight coupling" entstehen?
Was meinst Du eingentlich mit "Alternativen", [...]
Im meinte Alternativen im Sinne des Angebots anderer OSS-Distributionen ohne systemd.
[...] wenn ich Deine Kommentare lese, meinte ich doch, dass Du sehr an "Debian" hängst, [...]
Ich finde Debian spitze, vor Allem das Projekt als Entwicklergemeinde und die Entwicklerkultur und die dahinterstehende Philosophie. Das Produkt hat ebenfalls wirklich vorbildliche und tolle Seiten. Ich setze es gerne ein. Allerdings ist es bei weitem nicht perfekt und an vielen Stellen verbesserungswürdig - technisch, aber vor Allem bzgl. der internen und externen Kommunikation und der Infrastruktur.
[...] oder welches Linux würdest Du denn empfehlen wollen?
Empfehlen wofür lautet hier die Frage, d.h. für welchen Anwendungsfall/Einsatzzweck?
1. Ich stimme Ihnen grundsätzlich zu. Ich denke, dass Fragmentierung insbesondere im OSS-Ökosystem einen Preis hat. Und genau dieser Preis schlägt hier zu. Debian schleppt inzwischen so viele Altlasten mit, die sich mit neu integrierten Lösungen teils stark überschneiden oder/und unerwünschte Nebeneffekte generieren. (z.B.: Wozu gibt es parallel zu systemd noch das statische ifupdown? An wie vielen Stellen kann man inzwischen die umask konfigurieren und keine macht das, was man eigentlich möchte, siehe hier?)
2. Ich bin gespannt, wie das Enden wird. Werden wir wieder ein nicht enden wollendes Debakel erleben, sodass weitere wichtige Entwickler Debian den Rücken kehren, weil sie von der Debatte und ihrer Debattenkultur vergrätzt werden?
Jedenfalls halte ich dieses Wagnis im Bezug auf das Weiterbestehen Debians in seiner bisherigen Form für äußerst riskant. Wahrscheinlich ist der Schritt aber nötig und sogar wohl möglich der Richtige™ um Debian die Chance einer langfristigen Perspektive zu eröffnen, denn ewig kann Debian den ganzen Ballast nicht mitschleppen, weil das Projekt sonst darunter zusammenbrechen würde. Leider ist das nicht ohne Risiko. Debian steht an einem Scheideweg.
3. Ganz unabhängig von der Debatte über Initsysteme oder systemd im Speziellen:
Ich finde, dass Debian schon lange kein "universales Betriebssystem" mehr ist, falls es das überhaupt jemals gewesen ist. Das liegt allein schon daran, dass Linux selbst nicht universal ist. (GNU Hurd und kFreeBSD lasse ich mal außen vor, aber auf die trifft das auch nicht wirklich zu, es sind mit Ausnahmen eher wenigermächtige Alternativen zu Linux.) Man denke also bspw. an Systeme ohne MMU, mit harten Real-Time-Voraussetzungen oder Anforderungen einer stabilerer und besserer (User-Space-)Treiberinfrastruktur. Ich bezweifle sogar, dass es so ein "universelles" Betriebssystem überhaupt geben kann, denn es wäre sozusagen perfekt.
Ich möchte nicht falsch verstanden werden, denn ich mag das Debian als Betriebssystem und setze es auch ein, aber dieses Motto "the universal OS" ist mir schon immer sauer aufgestoßen. Was zur Hölle soll das eigentlich bedeuten? Und warum sollte das eine Priorität der meisten Anwender sein ? Use the right tool for the right job - Nicht alles ist ein Nagel!
Falls der Hammer aber so groß und mächtig sein sollte, dass jedes Problem so wie ein Nagel anmutet, dann kann auch etwas mit dem Hammer nicht stimmen. Er wäre zu groß, schwer und komplex. Ihn zu führen/verwenden, zu pflegen, zu reparieren und zu "verwalten" wird in diesem Fall nicht trivial sein.
Ergo: Man muss Debian auch wartbar halten und Altlasten (technical debt) rechtzeitig konsolidieren, wenn es neue Aufgabenfelder erreichen und Probleme lösen können soll. Dabei muss alte Funktionalität nicht unbedingt flöten gehen. Die Umsetzung muss ggf. nur angepasst werden.
Zum Glück existieren gute Alternativen. Daher heißt es für mich nun: Erstmal Abwarten und Teetrinken!
So so, es gibt zu viele "Altlasten". Gut, dann werden diese bereinigt, aber doch nicht um den Preis, dass das, was danach kommt, deutlich grösser ist/wird?
Genau das aber passiert aktuell. Software wird aufgeblasen, bis sie platzt. Dumm nur, dass mit SystemD dann auch PID 1 platzt.
Was meinst Du eingentlich mit "Alternativen", wenn ich Deine Kommentare lese, meinte ich doch, dass Du sehr an "Debian" hängst, oder welches Linux würdest Du denn empfehlen wollen?
systemd ist nicht der heilige Gral und an diversen Stellen stark verbesserungswürdig. Ich kann Ihre Haltung trotzdem nicht nachvollziehen/teilen.
Ja, und das fängt beim Linux-Kernel an, geht bei der glibc weiter und akkumuliert sich dann ggf. in den darauf aufbauenden Schichten. Da wird nur aus Legacy-Kompatibilitätsgründen alter, verrottender, nicht standardkonformer und teils kaputter Code behalten. Man denke bspw. an die verschiedenen WiFi-Stacks im Kernel, an die ganzen syscalls, an deren Namen Nummern angehängt werden, weil die anderen sich als unreparierbar kaputt erwiesen haben, oder an die ganzen ioctls-Tricksereien, sowie an die Inkonsistenzen und Kompatibilitätseinträge bezüglich/proc
und/sys
. Auch die heute quasi irrelevanten und überholten glibc-Features tragen ihren Teil dazu bei (ineffiziente Handhabung von Byte-Kodierungen via gconv, Sun RPC, Fehlen von Openwall-style TCB shadow, das Verhalten einiger Funktionen unter Systemressourcenmangel inkl. sperriger/unpraktikabler Fehlercodes).Und das ist bestenfalls die Spitze des Eisbergs, denn das zieht sich hoch bis in die Distro-spezifischen Codes à la SysV-Init-Skripte, initrd/initramfs/dracut-Implementierungen, ifupdown-Skripte etc. pp.
Das ist teils gammliger, ungewarteter Code, der ggf. Distro-spezifisch ist - unnötigerweise. Das ist keine Softwarediversität, sondern größtenteils sinnlose Fragmentierung.
Ich weiß nicht, ob man das so pauschalisieren kann. Die Entwickler streben in der Regel eigentlich danach, möglichst schlanken und wartbaren Code zu entwickeln und zu pflegen.Haben Sie die "Größe" der verschiedenen Alternativen mal verglichen? Auf der Grundlage welcher Metrik? Oder gibt es da fertige und fundierte Analysen?
Auf systemd mag das zutreffen. Ich denke aber, dass es darauf ankommt, wie man zählt. Und so direkt kann man das meiner Ansicht in diesem Fall gar nicht, denn:
Was heißt "platzt"? Schmiert PID1 bei Ihnen dauernd ab? Benötigt es zu viele Ressourcen?i) Was ersetzt systemd denn? Laut den Kritikern offensichtlich nicht nur sysvinit. Man müsste also alle optionalen Teile systemds von so einem Vergleich ausschließen.
ii) Selbst falls man Punkt i) respektiert, glaube ich, dass der Kernanteil systemds für init funktionell mächtiger ist als sysvinit je sein könnte, weshalb es de-facto auch ersetzt worden ist und nur noch wenig Pflege benötigt und erhält. Wer mehr kann, was offensichtlich vielerorts gefragt war und ist, braucht dafür in der Regel auch mehr Code. Wie berücksichtigt man das in einem direkten Vergleich der beiden?
iii) Wie sieht das aus, wenn man danach noch die Abhängigkeiten hinzuzählt? In vielen Distros setzt sysvinit neben den Initskripten auf Bash auf. Bash besteht derzeit aus circa 225k Quelltextzeilen und wird von einer einzigen Person ohne richtiges Versionsverwaltungssystem gepflegt.
Ja, es kann und tut einfach mehr, weil die Anforderungen über die Jahre gestiegen sind. SysV ist für IT-Verhältnisse steinalt. Zu der Zeit als SysV bzw. deren Vorläufer entworfen worden sind, hatte niemand diese Anforderungen auf dem Schirm.
Wenn man systemd auf dem kleinen embedded-Gerät, auf dem Mikrocontroller oder im minimalen Container ausführt, falls das überhaupt möglich wäre, hat man sich für das falsche Werkzeug entschieden. Viele Distributionen und Android setzen systemd aus gutem Grund nicht ein. systemd ist für Mainframes, Server und leistungsfähige Workstations und Desktops/Laptops mit Plug&Play-Hardware oder anderen ereignis-/abhängigkeitsbasierten Anforderungen geeignet.
Meinen Sie an dieser Stelle vielleicht, dass mit systemd Abhängigkeiten auf der Ebene des sogenannten "tight coupling" entstehen?
Im meinte Alternativen im Sinne des Angebots anderer OSS-Distributionen ohne systemd. Ich finde Debian spitze, vor Allem das Projekt als Entwicklergemeinde und die Entwicklerkultur und die dahinterstehende Philosophie. Das Produkt hat ebenfalls wirklich vorbildliche und tolle Seiten. Ich setze es gerne ein. Allerdings ist es bei weitem nicht perfekt und an vielen Stellen verbesserungswürdig - technisch, aber vor Allem bzgl. der internen und externen Kommunikation und der Infrastruktur. Empfehlen wofür lautet hier die Frage, d.h. für welchen Anwendungsfall/Einsatzzweck?