Auch hier werden wohl wieder Shell-Scripte für das starten der Dienste benutzt und wie jedem klar sein sollte ist professionelles Shellscripting welches sich auf möglichst allen Interpreter gleich verhält alles andere als ein Kinderspiel. Damit ist das Fehlerpotenzial, genau wie bei sysvinit, dermaßen hoch das auch hier wieder genau die gleichen Probleme bezüglich Verlässlichkeit und Portabilität entstehen. Auch das Problem mit den völlig unnötigen Redundanzen wird hier wohl erneut nicht wirklich beachtet.
Ich sehe nicht in wie fern sich der Aufwand bei einem Wechsel von sysvinit zu dem hier lohnen soll.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Aug 2017 um 13:03.
Die meisten Shells unterstützen POSIX relativ gut. Mit checkbashism gibt es von Debian außerdem ein Tool, das Skripte auf POSIX-Kompatibilität prüfen kann. Das macht es eigentlich relativ einfach standardkonform zu entwickeln.
Im Gegensatz zu sysvinit sind die run Scripte von runit selten länger als drei Zeilen und benötigen nicht mehr Logik, als systemd in dem Exec=-Feld. Generell ist das einer der größten Vorteile von runit: Die Scripte sind sehr kompakt.
> Auch hier werden wohl wieder Shell-Scripte > für das starten der Dienste benutzt und wie > jedem klar sein sollte ist professionelles > Shellscripting welches sich auf möglichst > allen Interpreter gleich verhält alles andere > als ein Kinderspiel.
Du Schlauberger! Die gleiche Argumentation gab es damals mit systemd auch... Da wurde auch groß argumentiert, dass der Vorteil von systemd der sei, dass man auf Shell Skripte verzichtet - die ja so fehleranfällig sind...
... und was ist ? Mit systemd werden die verhassten Shell Skripte von Distributionen einfach weiter verwendet ...
Der vermarktete Vorteil ist ad-absurdum geführt...
Mit systemd werden die verhassten Shell Skripte von Distributionen einfach weiter verwendet ...
Von welchen Distributionen?
Soweit mir bekannt ist, haben die Distributionen, die systemd von Anfang an unterstützt haben, auch entsprechende systemd-Units geschrieben und verwenden keine Shellskripte, um Services zu starten, überwachen und stoppen.
Auch hier werden wohl wieder Shell-Scripte für das starten der Dienste benutzt und wie jedem klar sein sollte ist professionelles Shellscripting welches sich auf möglichst allen Interpreter gleich verhält alles andere als ein Kinderspiel. Damit ist das Fehlerpotenzial, genau wie bei sysvinit, dermaßen hoch das auch hier wieder genau die gleichen Probleme bezüglich Verlässlichkeit und Portabilität entstehen. Auch das Problem mit den völlig unnötigen Redundanzen wird hier wohl erneut nicht wirklich beachtet.
Ich sehe nicht in wie fern sich der Aufwand bei einem Wechsel von sysvinit zu dem hier lohnen soll.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Aug 2017 um 13:03.Die meisten Shells unterstützen POSIX relativ gut. Mit checkbashism gibt es von Debian außerdem ein Tool, das Skripte auf POSIX-Kompatibilität prüfen kann. Das macht es eigentlich relativ einfach standardkonform zu entwickeln.
Im Gegensatz zu sysvinit sind die run Scripte von runit selten länger als drei Zeilen und benötigen nicht mehr Logik, als systemd in dem Exec=-Feld. Generell ist das einer der größten Vorteile von runit: Die Scripte sind sehr kompakt.
Bei runit muss es kein Shell-Script sein, nur eine ausfürbare Datei run, wenn die dann ein Script ist, was ist daran ein Problem?
Schau mal:
https://twitter.com/VoidLinux/status/524311181440188416
> Auch hier werden wohl wieder Shell-Scripte
> für das starten der Dienste benutzt und wie
> jedem klar sein sollte ist professionelles
> Shellscripting welches sich auf möglichst
> allen Interpreter gleich verhält alles andere
> als ein Kinderspiel.
Du Schlauberger! Die gleiche Argumentation gab es damals mit systemd auch... Da wurde auch groß argumentiert, dass der Vorteil von systemd der sei, dass man auf Shell Skripte verzichtet - die ja so fehleranfällig sind...
... und was ist ? Mit systemd werden die verhassten Shell Skripte von Distributionen einfach weiter verwendet ...
Der vermarktete Vorteil ist ad-absurdum geführt...
Soweit mir bekannt ist, haben die Distributionen, die systemd von Anfang an unterstützt haben, auch entsprechende systemd-Units geschrieben und verwenden keine Shellskripte, um Services zu starten, überwachen und stoppen.
Glaube kaum, dass Fakten ausreichen seine Meinung zu ändern.
Ich überlegte noch ihm mehrheitlich die selbe Antwort zu geben, aber wie "ano" schon erwähnte bringt das nix.
Ubuntu schreibt sehr oft einfach Wrapper-Units für SysVInit-Services. (zB autofs, glusterfsd)
RedHat/CentOS machts besser.