[geteilt] Init-System Flamewar

Zitat von gandro

Nach der Debian-Abstimmung wechselt Ubuntu jetzt auch auf systemd: http://www.heise.de/open/meldung/U…sm.feed.tw.open

Finde ich persönlich ziemlich überraschend, war Canonical Politik bei Mir oder Unity ja dann doch eher auf Alleingang hin. Damit ist systemd wohl der Quasi-Standard geworden, ausser Gentoo gibt es meines Wissens keine grössere Distribution mehr, die nicht standardmässig mit systemd daherkommt.

Interessant zu sehen. Wobei Ich gestehen muss, dass Ich etwas unschlüssig bin, ob systemd so ne tolle Idee ist. Es soll wohl viele Leute geben, die systemd eher negativ beurteilen, weil es wohl ein ziemlicher Klumpen Software sein soll. (Im Sinner von es macht so viel, was man eigentlich auf mehrere kleine Daemons aufteilen könnte.)

Leute, die systemd SystemD schreiben...

Das ist nicht die D-Variante von SystemC

Also ich hab mir ja heute auch mal speziell OpenRC vs. systemd reingezogen, und irgendwie schien alles nur aus Flamewar zu bestehen. Speziell jetzt mal https://wiki.debian.org/Debate/initsys…enRC_vs_Systemd und http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems (letzteres sieht so aus wie „systemd kann foo und bar und baz und qux und OpenRC und Upstart können das natürlich nicht, aber dafür ist OpenRC eine GANZ TOLLE BSD-LIZENZ”

Zitat von gandro

Nach der Debian-Abstimmung wechselt Ubuntu jetzt auch auf systemd: http://www.heise.de/open/meldung/U…sm.feed.tw.open

Finde ich persönlich ziemlich überraschend, war Canonical Politik bei Mir oder Unity ja dann doch eher auf Alleingang hin. Damit ist systemd wohl der Quasi-Standard geworden, ausser Gentoo gibt es meines Wissens keine grössere Distribution mehr, die nicht standardmässig mit systemd daherkommt.

Slackware?

@Diskussion: Ja klar funktionieren Init und Upstart. Zu Upstart will ich nichts sagen, weil ich da keine Ahnung von hab, aber Init ist unparallelisiert und dadurch auf modernen Systemen unnötig lahm.
Auch der Umgang mit den systemd-services erschließt sich mir als durchschnitts-User viel eher als die alte Init-Konfiguration.

Zitat von mrshadowtux

Da systemd viel mehr macht als reines init, widerspricht es ja auch total der Unix-Philosophie "Jedes Tool nur für eine spezifische Aufgabe" und ist dementsprechend unnötig komplex. Verstehe auch nicht, warum man ständig alles ändern muss. Init und upstart funktionierten doch.

Weil wir nicht mehr in den 70ern leben. Leute wie du sind der Grund, dass der Linux Desktop lange Zeit keine Fortschritte gemacht hat und immer noch gebremst scheint, obwohl gerade ne Menge am Laufen ist. Am besten schmeißt du deine Macs auch gleich weg (oder installierst Debian Etch, ist ja schön alt), denn systemd wurde von launchd inspiriert, soweit ich weiß.

Ich verstehe nicht, wie man in deinem Alter schon so verklemmt sein kann, echt mal.

Wow, man muss lesen können! Das ultra Gegenargument.

Ich konnte mich nie mit System V-artigen inits anfreunden, schon allein dieses bekloppte Runlevelkonzept funktioniert vorne und hinten nicht.

• Warum haben die Runlevels eine Zahl, die erstmal überhaupt nix darüber verrät, was darin passiert?
• Warum suggerieren sie eine Ordnung, die nicht existiert?
  
  
  • wenn ich im Konsolenmodus bin, muss ich nicht erst meine GUI starten, um zu rebooten, auch wenn 5 zwischen 3 und 6 liegt
  • warum sind 0 und 6 an verschiedenen Enden des Spektrums, auch wenn sie bis auf eine kleinigkeit vom Ablauf bis zum völligen Erliegen des OSes völlig identisch sind?
• und warum gibt es neben all den Zahlen doch noch sowas wie runlevel "S"?

Dazu noch der ganze Scheiß, dass man den Skripten pro Runlevel eine Reihenfolge basierend auf der Nummer im Dateinamen geben muss. Da ist BASIC-Programmierung aufm C64 strukturierter.

Nur weil es genau eine Aufgabe macht und ziemlich einfach aufgebaut ist heißt es nicht, dass es nicht trotzdem völlig hirnverbrannte Konzepte enthält.

Zitat von winfreak

Wow, man muss lesen können! Das ultra Gegenargument.

In der Tat. Moderne Init-Systeme kümmern sich selber um den Zustand der Dienste, anstatt wie bei sysvinit einem Satz Shell-Skripte mit gemeinsamer API zu verwenden, die sich bei jeder Ausführung diesen erst einmal selber zusammenklauben müssen. Dadurch fällt wiederum eine Menge Boilerplate-Code weg, der auf längere Sicht die Konfiguration vereinfacht.

Beispiel Upstart, ein eventbasiertes Init-System:

# /etc/init/teamspeak.conf


description     "TeamSpeak server"
author          "DosAmp"


# okay, das könnte man auch ohne Legacy-Runlevel lösen
# es gibt auch Events für "lokale Dateisysteme gemountet" und "System-Boot/Shutdown"
start on (net-device-up and runlevel [2345])
stop on runlevel [!2345]


respawn


env DIR=/opt/teamspeak/teamspeak3-server_linux-amd64


script
# bräuchen wir diese Umgebungsvariable nicht, könnte man das ganze auf eine "exec ..." Zeile zusammensteichen
export LD_LIBRARY_PATH="$DIR:$LD_LIBRARY_PATH"
start-stop-daemon --start --pidfile $DIR/ts3server.pid --chuid teamspeak --chdir $DIR --exec $DIR/ts3server_linux_amd64
end script

Beispiel systemd mit Socket Activation:

# /usr/lib/systemd/system/sshd.socket
[Unit]
Conflicts=sshd.service
Wants=sshdgenkeys.service


# systemd hört selber auf Port 22 und startet ähnlich inetd sshd bei Bedarf
[Socket]
ListenStream=22
Accept=yes


[Install]
WantedBy=sockets.target

# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH Daemon
# Pseudo-Dienst, der sich um die einmalige Generierung der Host-Keys kümmert
Wants=sshdgenkeys.service
After=sshdgenkeys.service
After=network.target


# alternativ kann sshd auch als klassischer, forkender Hintergrund-Dämon benutzt werden
[Service]
ExecStart=/usr/bin/sshd -D
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always


[Install]
WantedBy=multi-user.target

Zitat von mrshadowtux

Hör mir auf mit launchd. Ich wollte mir einen Eintrag für einen einzigen Dienst (uptimed) erstellen und musste dann dafür massig Doku lesen.

Zugegeben, dass launchd mit .plist-Dateien ein XML-basierendes Konfigurations-Format benutzt, macht es ein wenig anwenderabstoßend, aber das ist vor allem ein Problem des Gesamt-Frameworks und nicht des Init-Systems.

Ich find das Beispiel mit systemd persönlich ja einfacher/überschaubarer....

Zitat von DosAmp

Beispiel systemd mit Socket Activation:

Code

# /usr/lib/systemd/system/sshd.socket
[Unit]
Conflicts=sshd.service
Wants=sshdgenkeys.service


# systemd hört selber auf Port 22 und startet ähnlich inetd sshd bei Bedarf
[Socket]
ListenStream=22
Accept=yes


[Install]
WantedBy=sockets.target

Alles anzeigen

Merkt systemd selbst, dass dann sshd.service gestartet werden soll oder wo steht das?
Übrigens, hab mir grad mal das OpenRC-Initskript für sshd angeschaut. Meine Güte.

Soweit ich weiß ja