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?
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/procund/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?