[geteilt] Init-System Flamewar

[mrshadowtux]

Na, wofür steht das sysv wohl? http://de.wikipedia.org/wiki/System_V

[winfreak]

(14.02.2014 17:10)mrshadowtux schrieb:  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.

[gandro]

(14.02.2014 22:05)mrshadowtux schrieb:  Na, wofür steht das sysv wohl? http://de.wikipedia.org/wiki/System_V

Du verwechselst da was. sysvinit ist ein GNU-Projekt und lief nie unter System V, ist ja GPL. Es wurde explizit für Linux entwickelt.

Es ist vom System V Init-System inspiriert (im Gegensatz zu den BSD Style-Inits), ist aber Linux-only weil es procfs benötigt. Siehe: https://www.winhistory-forum.net/showthr...#pid375029

[mrshadowtux]

(14.02.2014 22:05)winfreak schrieb:  

(14.02.2014 17:10)mrshadowtux schrieb:  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.

Es entspricht also den 70er Jahren, jedem Programm nur eine Aufgabe zuzuweisen und nicht so bloatdinger mit tausneden Funktionen zu entwickeln? Dann will ich in die 70er.

(14.02.2014 22:05)winfreak schrieb:  Leute wie du sind der Grund, dass der Linux Desktop lange Zeit keine Fortschritte gemacht hat

Ich dachte wir reden hier über Init-Systeme? Was haben die mit dem Desktop zu tun?

(14.02.2014 22:05)winfreak schrieb:  Am besten schmeißt du deine Macs auch gleich weg (oder installierst Debian Etch, ist ja schön alt)

Ich hab irgendwie die Stelle meines Beitrags vergessen, wo ich schreibe dass ein System alt sein muss. Magst du sie mir nochmal zeigen?

(14.02.2014 22:05)winfreak schrieb:  denn systemd wurde von launchd inspiriert, soweit ich weiß.

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. Mal eben nen Dienst-Startscript hinzufügen ist da nicht, unnötig kompliziert.

(14.02.2014 22:05)winfreak schrieb:  Ich verstehe nicht, wie man in deinem Alter schon so verklemmt sein kann, echt mal.

Was hat das mit Verklemmtheit zu tun, wenn ich der Meinung bin, dass jedes Systemtool nur EINE Aufgabe haben soll? (Aus genau dem Grund bin ich auch gegen Emacs btw)

[winfreak]

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

[oreissig]

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.

[DosAmp]

(14.02.2014 22:24)winfreak schrieb:  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:

Code:

# /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:

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

Code:

# /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

(14.02.2014 22:20)mrshadowtux schrieb:  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.

[winfreak]

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

[thosch97]

(15.02.2014 11:14)DosAmp schrieb:  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

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.

[winfreak]

Soweit ich weiß ja