Man muß systemd nicht mögen. Auf privaten oder "einfachen" Systemen mag es funktionieren, aber so bald man in größeren Dimensionen denken muß (Serverfarmen etc.) wird es anstrengend. Die Mär über die Geschwindigkeit beim Start ist ja schon aufgeführt worden. Die wenigsten starten ihren Rechner mehrmals am Tag neu, wo dieses Argument ziehen würde .. der Großteil wird suspend nutzen und gut ist.
Wenn die Macher von systemd sich darauf beschränkt hätten, das init System zu überarbeiten und zu vereinheitlichen, wäre das ganze auch kein Problem. Aber dieses ständige Erweitern, aufbohren und so weiter macht das ganze mehr oder weniger kaputt. Wenn ich in einem Firmennetzwerk arbeite, dann betreibe ich meinen eigenen resolver, ich benötige keinen systemd-resolvd, der ungefragt installiert und aktiviert wird. Das gleiche geht dann weiter mit systemd-timesyncd, systemd-networkd, systemd-hostnamed etc. Klar, ich kann sie ersetzen und abklemmen ... aber das muß ich jetzt zusätzlich in meiner Automatisierung berücksichtigen und ggf. auch Probleme einkalkulieren, weil systemd-A auf systemd-B eine harte dependency hat.
Die Entscheidung der debian Macher jetzt zusätzlich auf rsyslog zu verzichten und komplett auf journald zu setzen ist genau so ein Hirnschiss (sorry). Oder kann journald einen zentralen Logginservice befüllen? Nein, kann er nicht! Und das ist auch nicht geplant das jemals zu implementieren .. Für eine große Serverfarm ist aber genau das was gewünscht und gefordert ist.
Man hat mit dem aufbohren des init Systemes den UNIX Weg (KISS) verlassen und ignoriert weitestgehende best-practice Regeln, die im professionellem Umfeld erforderlich sind.
Und das ein Großteil der Distributionen auf systemd setzt mag für viele eine Erleichterung sein, aber genau so viel stöhnen wieder über die kruden Ideen, die aus dieser Richtung kommen.
Zusammenfassend noch einmal: für private Systeme mag systemd die Lösung für viele Probleme sein, für Serverfarmen ist es die Ursache vieler Probleme.
Wenn ich in einem Firmennetzwerk arbeite, dann betreibe ich meinen eigenen resolver, ich benötige keinen systemd-resolvd, der ungefragt installiert und aktiviert wird. Das gleiche geht dann weiter mit systemd-timesyncd, systemd-networkd, systemd-hostnamed etc.
Das ist aber kein Problem von systemd, sondern der jeweiligen Distribution!
Ich bin ja auch kein systemd-Fan. Aber denen vorzuwerfen, was Dritte damit machen ist dann auch irgendwie seltsam.
Wenn ich in einem Firmennetzwerk arbeite, dann betreibe ich meinen eigenen resolver, ich benötige keinen systemd-resolvd, der ungefragt installiert und aktiviert wird. Das gleiche geht dann weiter mit systemd-timesyncd, systemd-networkd, systemd-hostnamed etc.
Gerade dann installiert man aber auch nicht jedes einzelne Gerät. Sondern man installiert sich das einmal. Konfiguriert so wie man das braucht und nimmt das System als Master, den man nur noch kopiert und dann ggf. noch ein bisschen anpasst.
Und gerade Linux-Systeme lassen sich super kopieren. Ist ja kein Windows welches ohne Installationsroutine praktisch gar nicht auf nem Rechner zu bekommen ist.
Man muß systemd nicht mögen.
Auf privaten oder "einfachen" Systemen mag es funktionieren, aber so bald man in größeren Dimensionen denken muß (Serverfarmen etc.) wird es anstrengend.
Die Mär über die Geschwindigkeit beim Start ist ja schon aufgeführt worden.
Die wenigsten starten ihren Rechner mehrmals am Tag neu, wo dieses Argument ziehen würde .. der Großteil wird suspend nutzen und gut ist.
Wenn die Macher von systemd sich darauf beschränkt hätten, das init System zu überarbeiten und zu vereinheitlichen, wäre das ganze auch kein Problem. Aber dieses ständige Erweitern, aufbohren und so weiter macht das ganze mehr oder weniger kaputt.
Wenn ich in einem Firmennetzwerk arbeite, dann betreibe ich meinen eigenen resolver, ich benötige keinen systemd-resolvd, der ungefragt installiert und aktiviert wird.
Das gleiche geht dann weiter mit systemd-timesyncd, systemd-networkd, systemd-hostnamed etc.
Klar, ich kann sie ersetzen und abklemmen ... aber das muß ich jetzt zusätzlich in meiner Automatisierung berücksichtigen und ggf. auch Probleme einkalkulieren, weil systemd-A auf systemd-B eine harte dependency hat.
Die Entscheidung der debian Macher jetzt zusätzlich auf rsyslog zu verzichten und komplett auf journald zu setzen ist genau so ein Hirnschiss (sorry).
Oder kann journald einen zentralen Logginservice befüllen? Nein, kann er nicht! Und das ist auch nicht geplant das jemals zu implementieren ..
Für eine große Serverfarm ist aber genau das was gewünscht und gefordert ist.
Man hat mit dem aufbohren des init Systemes den UNIX Weg (KISS) verlassen und ignoriert weitestgehende best-practice Regeln, die im professionellem Umfeld erforderlich sind.
Und das ein Großteil der Distributionen auf systemd setzt mag für viele eine Erleichterung sein, aber genau so viel stöhnen wieder über die kruden Ideen, die aus dieser Richtung kommen.
Zusammenfassend noch einmal: für private Systeme mag systemd die Lösung für viele Probleme sein, für Serverfarmen ist es die Ursache vieler Probleme.
grüße ...
Ich bin ja auch kein systemd-Fan. Aber denen vorzuwerfen, was Dritte damit machen ist dann auch irgendwie seltsam.
Gerade dann installiert man aber auch nicht jedes einzelne Gerät. Sondern man installiert sich das einmal. Konfiguriert so wie man das braucht und nimmt das System als Master, den man nur noch kopiert und dann ggf. noch ein bisschen anpasst.Und gerade Linux-Systeme lassen sich super kopieren. Ist ja kein Windows welches ohne Installationsroutine praktisch gar nicht auf nem Rechner zu bekommen ist.