Da kommt dann systemd natürlich sehr gut weg, trägt aber nicht der Tatsache Rechnung, das es auch noch andere Init-Systeme gibt und auch andere Möglichkeiten das umzusetzen, was systemd umsetzt.
Die anderen Init System könntest du ja mal genauer erläutern.
Es gab noch upstart, hat sich aber nicht durchgesetzt.
Die anderen Init System könntest du ja mal genauer erläutern.
Naja. Da gibts genug Internetseiten zu, die sich dem Thema schon ausführlich gewidmet haben. Ob man das unbedingt im begrenzten Rahmen eines Diskussionsforums machen sollte, da hab ich so meine Zweifel. Da lassen sich dann allenfalls spezifische Fragen klären.
Als groben Überblick verweise ich mal an der Stelle auf: https://wiki.gentoo.org/wiki/Comparison_of_init_systems
Mich hätte jetzt aber interessiert, was du speziell bei den anderen besser findest, das den Aufwand rechtfertigt da sein eigenes Ding zu machen. Und letzteres muss man ja praktisch, wenn fast alle Distris mit systemd kommen und die wenigen, die das nicht tun, wieder bezüglich der Distri speziell sind, also eine nehmen, die man selbst vielleicht nicht mag.
Also bei der Debatte innerhalb Debians damals, wurde auch Upstart als eine Option in die engere Auswahl gezogen - zumal es ja mit Ubuntu bereits ein gewisses Momentum gab, das auch zur Homogenisierung zwischen Debian und Ubuntu und damit auch einen Beitrag zur Minimierung des benötigten Entwicklungs- & Pflegeaufwands gesorgt hätte. Selbst Red Hat setzte in Fedora zwischenzeitlich auf Upstart, was zur Veröffentlichung von RHEL 6 (und Derivaten wie CentOS) mit Upstart führte, welche nun fast 10 Jahre Unterstützung bekamen und noch bekommen. Und Nokia benutzte Upstart in seiner Maemo-Plattform, Google für Chromium OS bzw. Chrome OS.
Dass sich Upstart letztlich nicht durchgesetzt hat, liegt vor allem an der für Canonical typischerweise nötigen CLA, wie etwa hier vermerkt ist. Und auch technisch ist es eher eine Krücke im Vergleich zu ereignisbasierten Alternativen mit wie systemd/launchd/SMF, und somit eher als Zwischenschritt statt dauerhafter Lösung anzusehen, sie etwa hier (unter "On Upstart") oder hier. Wenn ich das korrekt in Erinnerung habe, hat einer der Hauptentwickler von Upstart das größtenteils auch bestätigt. Leider finde ich keinen passenden Verweis mehr dazu.
Zu der Tabelle: Welche der Alternativen zu systemd kommt denn ohne sysvinit aus? - OpenRC setzt auf ein kompatibles /sbin/init auf, sysv oder BSD-rc (à la TrueOS/GhostBSD). - UpStart ist auch ein Überbau für sysvinit (und anderen Komponenten wie udev/dbus etc.), erweitert diesen lediglich. - Wieesaussieht, setzt SMF auch auf das klassische init und erledigt die erweiterte Prozessverwaltung. - Zu launchd weiß ich nichts, aber es läuft bisher nicht unter Linux oder BSD. - finit kenne ich nicht. - runit scheint hier am kompatibelsten zu sein. Es bietet ein eigenes init, kann aber auch in Kombination mit sysvinit, openrc oder systemd verwendet werden. Es kümmert sich eigentlich nur um die reine Prozessverwaltung.
Mir wären dann noch s6, nosh und Shepherd bekannt. s6 kann init ersetzen, aber nur unvollständig. Es ist dafür gedacht darauf aufzubauen. Es macht eigentlich nur low-level Prozessverwaltung/-überwachung. Nosh kann offenbar auch beides, siehe hier (unter "system management"). Shepherd ist laut Doku als Ersatz für init entworfen worden.
In diesem Sinne halte ich Vergleiche zwischen systemd und sysvinit schon für prinzipiell gerechtfertigt, da viele der Alternativen darauf aufsetzen. Ich denke, dass systemd für Brot-und-Butter-General-Purpose-Systeme ohne spezielle Anforderung wie Sicherheit/Embedded relativ viele Anwendungsfälle abdeckt. Es kann Linux-spezifische Funktionen nutzen, um damit wartbare und saubere Implementierungen von komplizierten Features bieten. Daher hat es unter Linux vermutlich auch die anderen verdrängt, soweit es nicht um General-Purpose-Systeme geht. (Die komplexeren inits à la SMF oder launchd sind meines Wissens nach auch nicht besonders portierbar. Was nutzt eigentlich Microsoft Windows?)
Von Nosh habe ich gefühlt ewig nix gehört. Und das das irgendwann mal ins FreeBSD-System einzieht, ist derzeit nicht absehbar. Erstens, weil die FreeBSDler relativ konservativ sind und zweitens weil auch nicht wirklich Leidensdruck da ist. rc-init ist jetzt nicht wirklich modern, aber gegenüber dem Sys-IV-Init doch ein Fortschritt.
In diesem Sinne halte ich Vergleiche zwischen systemd und sysvinit schon für prinzipiell gerechtfertigt
Kann man machen. Aber man sollte nicht so tun als ob systemd alternativlos wäre und sich Distributionen zwischen systemd und sys-iv entscheiden müssten. Zumindest vom rein technischen Standpunkt aus gesehen.
ohne spezielle Anforderung wie Sicherheit/Embedded relativ viele Anwendungsfälle abdeckt.
Da hast Du die Rechnung ohne Redhat gemacht. Die positionieren systemd u.a. auch für die Anwendung im embedded-Bereich.
Was nutzt eigentlich Microsoft Windows?
Die machen natürlich ihr eigenes Ding und haben auch für jede Aufgabe ein eigenes System. Für Dienste gibts den Service-Control-Manager. Für Sessions halt den Session-Managment-Service. usw.
Wenn Du einen direkten Eindruck von runit bekommen möchtest, dann kannst Du ja mal auf den Seiten zu Void Linux herum stöbern und bei Neugier diese Distribution parallel installieren. Das geht schnell und ist ziemlich einfach, auch wenn der void-Installer eher überschaubar und einfach gehalten ist.
Ganz ehrlich, mir wäre das zu viel Aufwand. Ich nehme einfach Debian und lebe mit systemd. Selbst Devuan würde ich nicht nutzen, da zu erwarten ist, dass hier die Manpower fehlt und es dann an anderer Stelle Baustellen gibt die Debian so nicht hat.
Das ist so wie wenn Pinguine fischen gehen. Eine Chance haben sie nur, wenn sie als Schwarm ins Wasser springen. Springen sie alleine, dann werden sie von Seelöwen und Co gefressen.
Die anderen Init System könntest du ja mal genauer erläutern.
Es gab noch upstart, hat sich aber nicht durchgesetzt.
Da lassen sich dann allenfalls spezifische Fragen klären.
Als groben Überblick verweise ich mal an der Stelle auf:
https://wiki.gentoo.org/wiki/Comparison_of_init_systems
Ja, den Link kenne ich schon.
Mich hätte jetzt aber interessiert, was du speziell bei den anderen besser findest, das den Aufwand rechtfertigt da sein eigenes Ding zu machen.
Und letzteres muss man ja praktisch, wenn fast alle Distris mit systemd kommen und die wenigen, die das nicht tun, wieder bezüglich der Distri speziell sind, also eine nehmen, die man selbst vielleicht nicht mag.
Mir gings um einen technischen Vergleich.Für die meisten Endanwender dürfte es in der Tat egal sein. Die interessiert nur: Läuft es oder nicht. Und das ist auch völlig legitim.
Also bei der Debatte innerhalb Debians damals, wurde auch Upstart als eine Option in die engere Auswahl gezogen - zumal es ja mit Ubuntu bereits ein gewisses Momentum gab, das auch zur Homogenisierung zwischen Debian und Ubuntu und damit auch einen Beitrag zur Minimierung des benötigten Entwicklungs- & Pflegeaufwands gesorgt hätte.
Selbst Red Hat setzte in Fedora zwischenzeitlich auf Upstart, was zur Veröffentlichung von RHEL 6 (und Derivaten wie CentOS) mit Upstart führte, welche nun fast 10 Jahre Unterstützung bekamen und noch bekommen. Und Nokia benutzte Upstart in seiner Maemo-Plattform, Google für Chromium OS bzw. Chrome OS.
Dass sich Upstart letztlich nicht durchgesetzt hat, liegt vor allem an der für Canonical typischerweise nötigen CLA, wie etwa hier vermerkt ist. Und auch technisch ist es eher eine Krücke im Vergleich zu ereignisbasierten Alternativen mit wie systemd/launchd/SMF, und somit eher als Zwischenschritt statt dauerhafter Lösung anzusehen, sie etwa hier (unter "On Upstart") oder hier. Wenn ich das korrekt in Erinnerung habe, hat einer der Hauptentwickler von Upstart das größtenteils auch bestätigt. Leider finde ich keinen passenden Verweis mehr dazu.
Zu der Tabelle: Welche der Alternativen zu systemd kommt denn ohne sysvinit aus?
- OpenRC setzt auf ein kompatibles
/sbin/initauf, sysv oder BSD-rc (à la TrueOS/GhostBSD).- UpStart ist auch ein Überbau für sysvinit (und anderen Komponenten wie udev/dbus etc.), erweitert diesen lediglich.
- Wie es aussieht, setzt SMF auch auf das klassische init und erledigt die erweiterte Prozessverwaltung.
- Zu launchd weiß ich nichts, aber es läuft bisher nicht unter Linux oder BSD.
- finit kenne ich nicht.
- runit scheint hier am kompatibelsten zu sein. Es bietet ein eigenes init, kann aber auch in Kombination mit sysvinit, openrc oder systemd verwendet werden. Es kümmert sich eigentlich nur um die reine Prozessverwaltung.
Mir wären dann noch s6, nosh und Shepherd bekannt. s6 kann init ersetzen, aber nur unvollständig. Es ist dafür gedacht darauf aufzubauen. Es macht eigentlich nur low-level Prozessverwaltung/-überwachung. Nosh kann offenbar auch beides, siehe hier (unter "system management"). Shepherd ist laut Doku als Ersatz für init entworfen worden.
In diesem Sinne halte ich Vergleiche zwischen systemd und sysvinit schon für prinzipiell gerechtfertigt, da viele der Alternativen darauf aufsetzen.
Ich denke, dass systemd für Brot-und-Butter-General-Purpose-Systeme ohne spezielle Anforderung wie Sicherheit/Embedded relativ viele Anwendungsfälle abdeckt. Es kann Linux-spezifische Funktionen nutzen, um damit wartbare und saubere Implementierungen von komplizierten Features bieten. Daher hat es unter Linux vermutlich auch die anderen verdrängt, soweit es nicht um General-Purpose-Systeme geht. (Die komplexeren inits à la SMF oder launchd sind meines Wissens nach auch nicht besonders portierbar. Was nutzt eigentlich Microsoft Windows?)
rc-init ist jetzt nicht wirklich modern, aber gegenüber dem Sys-IV-Init doch ein Fortschritt.Kann man machen. Aber man sollte nicht so tun als ob systemd alternativlos wäre und sich Distributionen zwischen systemd und sys-iv entscheiden müssten.
Zumindest vom rein technischen Standpunkt aus gesehen.Da hast Du die Rechnung ohne Redhat gemacht. Die positionieren systemd u.a. auch für die Anwendung im embedded-Bereich.Die machen natürlich ihr eigenes Ding und haben auch für jede Aufgabe ein eigenes System.
Für Dienste gibts den Service-Control-Manager.
Für Sessions halt den Session-Managment-Service.
usw.
Wenn Du einen direkten Eindruck von runit bekommen möchtest, dann kannst Du ja mal auf den Seiten zu Void Linux herum stöbern und bei Neugier diese Distribution parallel installieren. Das geht schnell und ist ziemlich einfach, auch wenn der void-Installer eher überschaubar und einfach gehalten ist.
Ist natürlich eine Zeit- und Interessensfrage
Ganz ehrlich, mir wäre das zu viel Aufwand.
Ich nehme einfach Debian und lebe mit systemd.
Selbst Devuan würde ich nicht nutzen, da zu erwarten ist, dass hier die Manpower fehlt und es dann an anderer Stelle Baustellen gibt die Debian so nicht hat.
Das ist so wie wenn Pinguine fischen gehen. Eine Chance haben sie nur, wenn sie als Schwarm ins Wasser springen.
Springen sie alleine, dann werden sie von Seelöwen und Co gefressen.