Hallo zusammen,
ich starte die Skripte beim Raspberry Pi immer automatisch durch einen
Eintrag in die /etc/rc.local.
Diese werden ja dann als root ausgeführt.
Ist es möglich das auch als Benutzer "pi" zu machen ?
man su
man sudo
Beispiel: Ich bin root und rufe beispielhaft den Befehl whoami auf.
Zunächst ganz normal als root:
1
# whoami
2
root
Wie man an der Ausgabe sieht wurde whoami als root ausgeführt denn das
ist was whoami tut: ausgeben wie der Nutzer heißt der es ausgeführt hat,
hilfreiches Kommando für Diagnosezwecke und steht hier stellvertretend
für den eigentlichen Befehl den Du später als anderer Nutzer aufrufen
willst.
Jetzt (ich bin immer noch root) will ich dass dieses Kommando als
Benutzer "bernd" ausgeführt wird.
Mindestens zwei beliebte Möglichkeiten gibt es dafür:
1
# su --command="whoami" bernd
2
bernd
3
4
# sudo --user=bernd whoami
5
bernd
Es gibt noch ein paar Feinheiten zu beachten bzgl der Umgebung in der
das Kommando ausgeführt wird (Umgebungsvariablen, shell, etc), siehe
dazu die man pages mit zusätzlichen Informationen.
Für das Ausführen des Kommandos in einer Login-shell des jeweiligen
Nutzers mit allen seinen Umgebungsvariablen schlag ich mal vor:
Hallo Bernd,
vielen Dank für Deine Erklärung.
Leider bekomme ich das nicht so ganz auf meinen Anwendungsfall
umgedacht.
Ich möchte in der rc.local das Skript "/home/pi/Desktop/./process.sh"
als Benutzer "pi" mit Passwort "raspberry" aufrufen
Wie muss ich das in der rc.local angeben ?
ETechniker schrieb:> Ich möchte in der rc.local das Skript "/home/pi/Desktop/./process.sh"> als Benutzer "pi" mit Passwort "raspberry" aufrufen
Vorausgesetzt die .sh Datei ist als ausführbar markiert:
Passwort von pi brauchst Du nicht denn der Benutzer root darf sich auch
so jederzeit in jeden anderen Benutzer verwandeln denn root hat
gottgleiche Rechte.
Du musst aber natürlich dafür sorgen daß Dein Script sich wieder beendet
so daß der Bootvorgang ordentlich beendet werden kann. Sonst hängt es
ewig in der rc.local und das kann/wird komische Effekte haben.
Da hilft dann vielleicht ein & an der richtigen Stelle oder auch die
--background Option von sudo: Wenn Dein process.sh normalerweise
blockiert und nie zurückkehrt willst Du es im Hintergrund starten:
>Du musst aber natürlich dafür sorgen daß Dein Script sich wieder beendet
ich habe eine while true Schleife, da ich auf Tastatureingabe warte und
entsprechend reagiere
ETechniker schrieb:> ich habe eine while true Schleife, da ich auf Tastatureingabe warte und> entsprechend reagiere
Ähm wie stellst Du Dir das vor? Wenn das beim Bootvorgang automatisch
ablaufen soll, wo soll da ein Nutzer herkommen der die Tastatur
betätigt?
Aber vielen Dank für
>sudo --background --set-home --login --user=pi /home/pi/Desktop/process.sh
das funktioniert nämlich erst enmal wie gewünscht
Ich hatte mich noch an der Übergabe des Passwortes festgebissen aber das
braucht er tatsächlich nicht
>Ähm wie stellst Du Dir das vor? Wenn das beim Bootvorgang automatisch>ablaufen soll, wo soll da ein Nutzer herkommen der die Tastatur>betätigt?
ich lese in dem Skript mit "read" die Tastatur ein
ETechniker schrieb:>>Ähm wie stellst Du Dir das vor? Wenn das beim Bootvorgang> automatisch>>ablaufen soll, wo soll da ein Nutzer herkommen der die Tastatur>>betätigt?>> ich lese in dem Skript mit "read" die Tastatur ein
Aber die Ausgaben des Scripts gehen jetzt ins Leere, es ist unsichtbar.
Willst Du vielleicht lieber beim Einschalten eine graphische Sitzung für
den Nutzer pi automatisch starten, darin dann per ~/.config/autostart/
ein Textkonsolenfenster automatisch aufpoppen lassen und darin Dein
Script ausführen?
>Willst Du vielleicht lieber beim Einschalten eine graphische Sitzung für>den Nutzer pi automatisch starten, darin dann per ~/.config/autostart/>ein Textkonsolenfenster automatisch aufpoppen lassen und darin Dein>Script ausführen?
Gib mir mal ein Stichwort zum Suchen oder eine Beschreibung wie sowas
funktioniert, komme nicht aus der Linux Welt
Erstmal ist die grundlegenden Frage: soll das ding innder grafischen
Oberfläche (lxce o.ä.) in einem virtuellen terminal laufen oder ohne
oberfläche ?
Abhängig davon gibt es dann jeweils andere Lösungsansätze. Deswegen
beschreib bitte einmal ganz genau was du wie vorhast und was dein
programm macht!
Wenn das Script den read Befehl benutzt will er es eventuell auf einem
TTY anzeigen lassen, evtl. auch als alternative zum Login. In dem fall
müsste man es dort angeben, wo getty verwendet wird. Früher war das
glaub ich in /etc/inittab, bei systemd war es in irgendeinem service
file, einfach mal mit "grep -r getty /" danach suchen. Falls das script
vor dem login aufgerufen werden soll, hängt es vom init system ab. Bei
Systemd Systemen würde es wohl auf ein .service file mit agetty befehl
hinaus laufen. Falls das script nur Benutzername & Passwort beim login
braucht, würde man es per pam_exec mit pam machen.
Also, das RaspberryPi soll starten und über die angeschlossene Tastatur
immer ein Zeichen einlesen. In Abhängigkeit dieses Zeichens sollen
verschiedene Dinge getan werden, z.B. ein Bild auf dem angeschlossenem
HDMI Bildschirm anzeigen.
Zur Vereinfachung habe ich das grobe Skript unten als Beispiel.
Starte ich es mit der Tastatur mit ./process.sh funktioniert alles wie
gewünscht, lege ich es mit
sudo --background --set-home --login --user=pi
/home/pi/Desktop/./process.sh
in die rc.local dann nicht mehr.
Es fängt schon damit an dass read nicht mehr blockiert ??
#!/bin/bash
while true; do
echo "STARTbildschirm"
remote="o"
while [ "$remote" != "q" ]
do
echo "Lese"
read -n 1 remote
case $remote in
"a")
echo "Test A"
;;
"s")
echo "Test S"
;;
esac
done
done
Das Problem ist, dass das script im Hintergrund lauft und kein
verbundenes TTY/Console hat. Die Console/das TTY ist wo die Zeichen
ausgegeben und Eingelesen werden. Selbst wenn noch Zeichen auf ein TTY
ausgegeben werden können, wenn stdout auf das TTY zeigt, wenn der
Prozess im Hintergrund ist, können keine mehr davon eingelesen werden.
Die sinnvollste Vorgehensweise für diesen Anwendungsfall erscheint mir
zu sein, mittels vtopen auf dem nächsten freien TTY den Prozess im
Fordergrund auszuführen, und zu diesem TTY wechseln:
@Daniel Abrecht
Viele Dank für die Erklärung und das Beispiel.
Funktioniert genau wie gewünscht.
Einen kleinen Seiteneffekt habe ich allerdings noch.
Wie schon erwähnt zeige ich am Bildschirm Bilder mit "fbi" an.
Diese Anzeige wird allerdings auch durch das Einlesen mit read
beeinflusst.
Folgendes Beispiel soll z.B. das Bild test.jpg so lange anzeigen bis die
Taste q gedrückt wird. Funktioniert auch im Prinzip, allerdings wird das
Bild auch sporadisch durch Drücken jeder anderen Taste gelöscht obwohl
sie laut "man fbi" nicht belegt ist.
#!/bin/bash
sudo fbi -T 1 -noedit -noverbose -a --once test.jpg
remote="o"
while [ "$remote" != "q" ]
do
read -n 1 remote
done
Kleiner Nachtrag
Dieses Phänomen habe ich nur wenn es durch den Eintrag in der rc.local
automatisch gestartet wird.
Beim manuellen starten funktioniert es :-(
Das Problem wird das Argument "-T 1" sein, welches du fbi mitgibst. fbi
sollte das richtige TTY selbst erkennen können.
Das Bild auf dem Bildschirm wird durch ein Framebuffer Device
repräsentiert. Häufig wird die framebuffer console (fbcon) verwendet, um
virtuelle Consolen (die TTYs) auf Framebuffer zu mappen/anzuzeigen. Es
ist immer nur eines dieser TTY pro Framebuffer aktiv. Wenn man chvt
verwendet, oder ALT+F[nummer] drückt, wird ein TTY aktiv gesetzt und
angezeigt. Wenn beim Starten auf TTY1-6 mit getty geöffnet werden, um
den Login Prozess zu starten, sind diese in Verwendung.
Anfangs dachte ich, wenn du dich auf TTY1 anmeldest, und dann dein
Script ausführst, stimmen das momentan aktive TTY, namlich TTY1, und
deine Angabe bei fbi, "-T 1", überein. Auf diesem TTY wartet fbi dann
auf eingaben. Wenn du jedoch das Script über openvt aufrufst, sucht
dieses nach dem nächsten unbenutzten TTY. Wenn TTY1-6 in Verwendung
sind, ist dies TTY7. Wenn dann fbi aufgerufen wird, aber diesem mit "-T
1" sagst, es solle TTY1 nehmen, kommt dieses durcheinander. fbi würde
versuchen von TTY1 zu lesen und bei dieser Konsole den Cursor & co.
deaktivieren, womit jeder Tastendruck auf TTY7 dazu führen würde, dass
die Konsole neu gezeichnet wird und das Bild überschreibt.
Dies war aber nicht der fall. Wie sich herausgestellt hat, als ich mir
fbi genauer angesehen habe, sucht fbi per default wie openvt das nachste
noch nicht verwendete TTY, und liest von dort die eingaben ein. Wenn man
aber "-T 1" angibt, mappt fbi TTY1 mit dem ioctl FBIOGET_CON2FBMAP nach
fb0 und setzt dieses Aktiv. Dies wäre kein Problem, wenn das TTY nicht
bereits in Verwendung wäre. Was dann genau zum beenden von fbi führt,
habe ich nicht herausgefunden, aber es scheint als ob fbi und getty
einander in die quere kommen, weil beide das TTY für sich haben wollen.
Das ganze erklärt aber nicht, warum es funktioniert hat, als du das
Script selbst auf der Konsole ausgeführt hast.
ETechniker schrieb:> ich starte die Skripte beim Raspberry Pi immer automatisch durch einen> Eintrag in die /etc/rc.local.
Das kann man so machen, aber dann isses halt Kacke.
> Diese werden ja dann als root ausgeführt.> Ist es möglich das auch als Benutzer "pi" zu machen ?
systemd ist Dein Freund.
Daniel A. schrieb:> Wenn das Script den read Befehl benutzt will er es eventuell auf einem> TTY anzeigen lassen, evtl. auch als alternative zum Login. In dem fall> müsste man es dort angeben, wo getty verwendet wird. Früher war das> glaub ich in /etc/inittab, bei systemd war es in irgendeinem service> file, einfach mal mit "grep -r getty /" danach suchen.
Nicht grep, sondern find(1) oder locate(1). Und selbst dann...:
1
sheeva@ap1:~ $ systemctl status getty@tty1.service
Guckstu: /lib/systemd/system/getty@.service ;-)
> Falls das script vor dem login aufgerufen werden soll, hängt es vom> init system ab.
Raspbian ist ein halbwegs aktuelles Debian und deswegen
erfreulicherweise nahezu komplett auf systemd gepolt.
ETechniker schrieb:> Also, das RaspberryPi soll starten und über die angeschlossene Tastatur> immer ein Zeichen einlesen. In Abhängigkeit dieses Zeichens sollen> verschiedene Dinge getan werden, z.B. ein Bild auf dem angeschlossenem> HDMI Bildschirm anzeigen.
Laß' das Gefumsel in rc.local. Echt jetzt. Es gibt wenige Wege, sich auf
einem UNIX-System gleichzeitig in beide Füße, Knie, und beide Hände zu
schießen. Was Du praktizierst, ist nicht der schlechteste. ;-)
Was Du brauchst, ist zunächst ein User, der beim Systemstart automatisch
und ohne Paßworteingabe eingeloggt wird. Wie das geht, wird hier erklärt
[1], funktioniert auch unter anderen Distributionen. Unter Raspbian gibt
es sogar eine Auswahl in raspi-config "Boot Options" -> "Desktop / CLI"
Dann soll der automatisch eingeloggte User Dein Skript aufrufen. Das
kann ein Shellskript wie das von Dir gezeigte sein, aber auch ein
X-Server mit einem Windowmanager. Gelegenheiten, die sich dazu anbieten,
sind systemd user services oder die dot-Dateien im Homedirectory Deines
Users. ;-)
[1]
https://wiki.archlinux.org/index.php/Getty#Automatic_login_to_virtual_console
Sheeva P. schrieb:> Nicht grep, sondern find(1) oder locate(1). Und selbst dann...:> sheeva@ap1:~ $ systemctl status getty@tty1.service> ● getty@tty1.service - Getty on tty1> Loaded: loaded (/lib/systemd/system/getty@.service; enabled)>> Guckstu: /lib/systemd/system/getty@.service ;-)
Wenn ich nur weiss, dass im service file einer der *getty befehle
genutzt wird, aber nicht weiss wie das service file heist, ist es schon
grep.
Ein beliebter Fehler, der mir früher immer passiert ist, als ich noch
systemd nutzte, war die Service files der Packete direckt zu editieren,
statt ein Override anzulegen. Ein Konzept welches vor Systemd komplett
überflüssig war... Wie auch immer, mit overrides und getty:
http://askubuntu.com/questions/659267/how-do-i-override-or-configure-systemd-services
Natürlich hat es vorteile einen Service dafür zu verwenden, wie dass man
diese neu starten kann, etc. Ein Eintrag in rc.local ist doch nun aber
wirklich nichts schlimmes. Man vergleiche dass mit systemd services, wo
man overrides umd die service file syntax kennen muss, und dann noch
alle Optionen die man braucht. Früher, als services noch durch Scripts
gestartet wurden, war alles einfacher. Zum glück gibt es devuan.
Sheeva P. schrieb:> Was Du brauchst, ist zunächst ein User, der beim Systemstart automatisch> und ohne Paßworteingabe eingeloggt wird. Wie das geht, wird hier erklärt> [1], funktioniert auch unter anderen Distributionen. Unter Raspbian gibt> es sogar eine Auswahl in raspi-config "Boot Options" -> "Desktop / CLI"
da ein shell-script aufgerufen wird (schaut zumindest oben danach aus)
kann das script auch als "login-shell" für den user in /etc/passwd
angegeben werden
Daniel A. schrieb:> Ein beliebter Fehler, der mir früher immer passiert ist, als ich noch> systemd nutzte, war die Service files der Packete direckt zu editieren,> statt ein Override anzulegen. Ein Konzept welches vor Systemd komplett> überflüssig war...
Ich hab' oft genug Startskripte der Distributionen editieren und
natürlich auch eigene entwickeln müssen, deshalb empfinde ich Overrides
und Unitfile Templates als wunderbare Erleichterung. Aber ich weiß, im
Gegensatz zu mir magst Du systemd nicht so gerne. ;-)
> Natürlich hat es vorteile einen Service dafür zu verwenden, wie dass man> diese neu starten kann, etc. Ein Eintrag in rc.local ist doch nun aber> wirklich nichts schlimmes.
Wenn rc.local hängt, kommt das System nicht hoch. Services in rc.local
lassen sich nicht ordentlich stoppen oder restarten, tauchen nicht in
den einschlägigen Servicemanagern auf, und wenn man es richtig machen
wollte, müßte man die in rc.local gestarteten Daemons sauber
daemon(1,7)izen. Von denen, die rc.local nur benutzen, um sich die
Entwicklung eines korrekten SysV-Startskripts oder systemd-Unitfile
(oder meinetwegen eines eigenen Supervisors wie supervisord, monit,
daemontools etc.) zu ersparen, macht das aber keiner, soll ja alles
schön einfach sein... und über Logging und Monitoring und Backup und all
die anderen Dinge habe ich noch gar nicht geredet. rc.local gilt daher
sogar unter SysV-Init, zu dem es gehört, als deprecated und existiert
nur noch aus Gründen der Abwärtskompatibilität.
> Man vergleiche dass mit systemd services, wo> man overrides umd die service file syntax kennen muss, und dann noch> alle Optionen die man braucht. Früher, als services noch durch Scripts> gestartet wurden, war alles einfacher.
Entschuldige, aber das war es ganz sicher nicht. Früher mußte man für
jede verdammte Linux-Distribution, AIX, Solaris etc je ein eigenes
Start-Skript schreiben und pflegen und mußte die werkssseitig dazu
nötigen Funktionen nebst all ihrer Optionen kennen. Das erscheint nur
Leuten einfacher, die es seit Jahren kennen und -- vornehmlich als
Benutzer -- nutzen. Aus der Perspektive von Softwareentwicklern war das
jedoch immer schon ein übler, völlig überflüssiger Unfug.
Ein Unitfile wie
1
[Unit]
2
Description=Apache Storm Nimbus
3
After=network.target
4
5
[Service]
6
User=storm
7
WorkingDirectory=/opt/apache-storm
8
ExecStart=./bin/storm nimbus
9
10
[Install]
11
WantedBy=multi-user.target
reicht meistens völlig aus, funktioniert perfekt unter Debian, Ubuntu,
RedHat, SuSE und diversen anderen Linux-Distributionen, hat Logging,
Privilegienseparation, LSB-kompatible Funktionalität (start, stop,
restart, force-reload, status) quasi eingebaut, ...
Vergleich das mal mit einem (nicht einmal LSB-konformen)
SysV-Startscript, hier ein Beispiel für DeadR^WRedHat und Derivate:
1
#!/bin/bash
2
#
3
# /etc/init.d/storm-nimbus
4
#
5
# Startup script for storm-nimbus
6
#
7
# chkconfig: 2345 20 80
8
# description: Starts and stops storm-nimbus
9
#. /etc/init.d/functions
10
stormBin=/home/user/storm/storm-0.8.1/bin/storm
11
stormSvc=$(echo$0 | cut-d'-'-f2)
12
desc="Storm $stormSvc daemon"
13
outFile="/var/log/storm/storm-$stormSvc.out"
14
stormUser=user
15
pidFile=/var/run/storm/storm-$stormSvc.pid
16
17
if![-f$stormBin];then
18
echo"storm binary not found."
19
exit 5
20
fi
21
22
if[-f /etc/sysconfig/storm ];then
23
. /etc/sysconfig/storm
24
fi
25
26
start(){
27
echo"Starting $desc (storm-$stormSvc): "
28
su $stormUser-c"nohup $stormBin$stormSvc >>$outFile 2>&1 &"
29
RETVAL=$?
30
31
return$RETVAL
32
}
33
34
stop(){
35
echo"Shutting down $desc (storm-$stormSvc): "
36
if[$stormSvc=="ui"];then
37
pkill -f backtype.storm.ui.core
38
else
39
pkill -f backtype.storm.daemon.$stormSvc
40
fi
41
[-e$pidFile]&&rm$pidFile
42
}
43
44
restart(){
45
stop
46
start
47
}
48
49
status(){
50
if[$stormSvc=="ui"];then
51
pid=$(pgrep -f backtype.storm.ui.core)
52
else
53
pid=$(pgrep -f backtype.storm.daemon.$stormSvc)
54
fi
55
56
if[-z$pid];then
57
echo"storm-$stormSvc is NOT running."
58
RETVAL=1
59
else
60
echo"storm-$stormSvc is running (pid is $pid)."
61
RETVAL=0
62
fi
63
64
}
65
66
case"$1"in
67
start) start;;
68
stop) stop;;
69
restart) restart;;
70
status) status;;
71
*)echo"Usage: $0 {start|stop|restart}"
72
RETVAL=2;;
73
esac
74
exit$RETVAL
(Quelle: https://gist.github.com/johnptoohey/4360179 )
Nee, echt jetzt, ich weine SysV-Init keine Träne hinterher.
PS: Ich wollte nicht die SysV-Skripte für Wildfly als Beispiel benutzen.
Die RedHat-Version hat 208, die Debian-Variante sogar 298 Zeilen. ;-)
Daniel F. schrieb:> Sheeva P. schrieb:>> Was Du brauchst, ist zunächst ein User, der beim Systemstart automatisch>> und ohne Paßworteingabe eingeloggt wird. Wie das geht, wird hier erklärt>> [1], funktioniert auch unter anderen Distributionen. Unter Raspbian gibt>> es sogar eine Auswahl in raspi-config "Boot Options" -> "Desktop / CLI">> da ein shell-script aufgerufen wird (schaut zumindest oben danach aus)> kann das script auch als "login-shell" für den user in /etc/passwd> angegeben werden
Dann muß die neue "Login-Shell" in /etc/shells aufgeführt sein. Klar,
das ist ein lösbares Problem, aber dann können alle anderen Benutzer
dasselbe Skript als Login-Shell benutzen, was, je nachdem was das Skript
macht, zu Problemen führt. Außerdem werden die normalen Loginskripte wie
.profile, .bash_profile, .bash_login und .bashrc nicht abgearbeitet.
Lieber Dein Skript als letztes in $HOME/.profile oder $HOME/.bashrc des
betreffenden Benutzers aufrufen und direkt danach ein "exit".
Hallo,
warum nicht ganz einfach über crontab mit einem @reboot Eintrag (für den
entsprechenden User)?
Oder habe ich da etwas nicht verstanden?
Gruß
der Ahnungslose
Sheeva P. schrieb:> Ein Unitfile wie> [Unit]> Description=Apache Storm Nimbus> After=network.target>> [Service]> User=storm> WorkingDirectory=/opt/apache-storm> ExecStart=./bin/storm nimbus>> [Install]> WantedBy=multi-user.target>> reicht meistens völlig aus, funktioniert perfekt unter Debian, Ubuntu,> RedHat, SuSE und diversen anderen Linux-Distributionen, hat Logging,> Privilegienseparation, LSB-kompatible Funktionalität (start, stop,> restart, force-reload, status) quasi eingebaut, ...
Sieht einfach aus, jaja. Aber nun stelle dir vor, du willst es z.B. nur
auf einer bestimmten von mehreren IPs auf verbindungen warten lassen.
Man beachte das After=network.target, das schon fertig sein kann, bevor
die Interfaces überhaupt da sind:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Um diese simple änderung zu machen, müsste man also ein service override
erstellen, und ein After=network-online.target hinein schreiben.
Vergisst man dies, startet der service beim Start manchmal, und manchmal
nicht. Aber das erfordert ja nur etwas vorwissen zu Systemd, das mann ja
magisch bekommen hat.
Ausserdem ist gerade das mit den TTYs ohne Systemd einfacher. Bei
Sysvinit, OpenRC, etc. kann man einfach in /etc/inittab die Zeile
1
1:2345:respawn:/sbin/getty 38400 tty1 linux
ersetzen durch sowas: (Ist bei meinem Server so in verwendung)
Das ist ja wohl um einiges einfacher, als ein Service file erstellen zu
müssen, und auchnoch ordentlich Dokumentiert!
Zugegeben, das Format und Konzept von Systemd Unit files ist nicht
schlecht, es ist auch nicht neu, aber muss es wirklich jede
Konfigurationsdatei und jedes altbewährte Konzept ersetzen? (als
nächstes werden resolv.conf und pid files daran glauben müssen, die
/etc/hosts wurde bereits durch hostnamectl ersetzt, Google DNS ist als
fallback in resolved hartcodiert, etc.)
Sysvinit ist wirklich nicht Perfekt, aber es gibt ja einige Alernativen.
z.B. OpenRC oder Shepard, jenachdem was man will. Upstart war eigentlich
ganz gut, schade das Canonical wegen Debian auf Systemd wechseln
musste...
Daniel A. schrieb:> Sieht einfach aus, jaja.
Neinnein, es sieht nicht nur einfach aus. Es ist einfach.
> Aber nun stelle dir vor, du willst es z.B. nur auf einer bestimmten von> mehreren IPs auf verbindungen warten lassen.
Das wäre natürlich eine Sache der Applikation und nicht des
Init-Systems. Mir ist keine auch nur halbwegs brauchbare Software
bekannt, bei der so etwas nicht in der Applikation konfiguriert wird.
Obendrein kommt hinzu, daß es keinen besonderen Unterschied gibt, ob Du
ein distributionseigenes SysV-Startskript oder ein distributionseigenes
systemd-Unitfile editierst -- außer, daß es für systemd -- anders als
für SysV-Init -- einen eigens dafür vorgesehenen, dokumentierten,
sauberen Weg für solche Sonderfälle gibt, nämlich Overrides. Bei den
Startskripten von SysV hingegen prokelst Du direkt in Dateien herum,
welche vom Distributor ausgeliefert und vom Paketmanagementsystem
verwaltet werden.
Davon abgesehen brauche ich so etwas in maximal zwei Prozent aller
Setups und glaube daher nicht, daß solche seltenen Ausnahmefälle dazu
geeignet sind, als Argument für oder wider ein Init-System zu dienen.
Wenn man das nicht in der Applikation konfigurieren kann, dann ist das
bestenfalls ein Argument gegen die Applikation -- IMHO sogar ein
ziemlich starkes.
> Man beachte das After=network.target, das schon fertig sein kann, bevor> die Interfaces überhaupt da sind:> https://www.freedesktop.org/wiki/Software/systemd/...> Um diese simple änderung zu machen, müsste man also ein service override> erstellen, und ein After=network-online.target hinein schreiben.
In diesem Fall ist das komplette systemd-Unitfile unter meiner eigenen
Kontrolle, und wenn ich will, kann ich da jederzeit statt network.target
auch network-online.target hineinschreiben. Dasselbe dürfte auch für den
TO mit seinen selbstentwickelten Skripten gelten -- und ansonsten sind,
natürlich, auch Overrides möglich.
Eine alternative Möglichkeit ist, systemd-networkd-wait-online.service
(oder für Systeme mit NetworkManager:
NetworkManager-wait-online.service) zu aktivieren. Dann wird
network.target erst ausgelöst, nachdem network-online.target erreicht
worden ist.
>
>> Das ist ja wohl um einiges einfacher, als ein Service file erstellen zu> müssen, und auchnoch ordentlich Dokumentiert!
Es bietet zunächst bei Weitem nicht die Funktionalität, die systemd an
dieser Stelle anbietet. Da kannst Du Dein Programm nicht stoppen, nicht
temporär deaktivieren, Abhängigkeiten werden nicht berücksichtigt, Du
mußt Dich manuell ums Logging, Logrotation etc. kümmern, ... daß das
einfacher ist, halte ich ehrlich gesagt für Unfug.
> Zugegeben, das Format und Konzept von Systemd Unit files ist nicht> schlecht, es ist auch nicht neu, aber muss es wirklich jede> Konfigurationsdatei und jedes altbewährte Konzept ersetzen?
Wenn es logische Zusammenhänge zwischen diesen Komponenten gibt, die
sich besser abbilden lassen als mit den alten -- dabei jedoch keineswegs
immer bewährten -- Konzepten? Ja, unbedingt! Die "altbewährten Konzepte"
sind bei näherer Betrachtung oft nur eine Sammlung von Lösungen, die
mangels besserer Alternativen erdacht und benutzt wurden, und über die
Jahre zwar einen bemerkenswert hohen Grad an Stabilität und Reife
erreicht haben, aber dennoch eine unelegante, unzusammenhängende
Sammlung von Behelfen bleiben. Daß etwas alt und lange benutzt worden
ist, heißt weder, daß es gut ist, noch, daß es nicht durch etwas
Besseres ersetzbar wäre.
Mittlerweile gibt es allerdings eine bessere Alternative, nämlich
systemd, das viele Dinge sehr viel einfacher, eleganter, und zentral an
der Stelle löst: Starten, Stoppen, Statusabfrage von Daemons,
Privilegienseparation, Logging, Daemonization, Dependencies, und so
weiter -- alles unter einem "Dach", zentral an einer Stelle, und mit
einer einheitlichen Syntax und Sprache für alle Daemons und über alle
verbreiteten Distributionen.
> (als> nächstes werden resolv.conf und pid files daran glauben müssen, die> /etc/hosts wurde bereits durch hostnamectl ersetzt, Google DNS ist als> fallback in resolved hartcodiert, etc.)
Was an resolv.conf und Pidfiles so gut sein soll, daß man es unbedingt
behalten will, erschließt sich mir nicht. Zumal die resolv.conf ohnehin
von resolvconf(8) oder dem NetworkManager verwaltet wird und Pidfiles
nur eine Krücke sind, damit das Init-System seine Prozesse wiederfindet.
Dank kann man sich den ganzen Zinnober mit dem Daemonizing,
Logkonfiguration, Pidfile-Gefumsel und so weiter komplett sparen.
> Sysvinit ist wirklich nicht Perfekt, aber es gibt ja einige Alernativen.
Ja, genau, und systemd ist eine davon -- und, meiner Meinung nach, auch
eine ziemlich gut gelungene. Die Tatsache, daß auch Debian und Derivate
sowie RedHat nebst Derivaten allesamt auf systemd setzen, ist ein Indiz
dafür, daß systemd nicht nur mich, sondern auch die gemeinhin ziemlich
fähigen Verantwortlichen der betreffenden Distributionen überzeugt hat.
> z.B. OpenRC oder Shepard, jenachdem was man will. Upstart war eigentlich> ganz gut, schade das Canonical wegen Debian auf Systemd wechseln> musste...
Tja, systemd ist einheitlich, stabil und produktionsreif, und wird von
den meisten verbreiteten Distributionen verwendet. Upstart war zwar ganz
nett, dann aber doch nur eine weitere Insellösung wie die
SysV-Startskripte. Als Entwickler und als Admin habe ich aber keinen
Bock, mich ständig auf immer wieder neue Insellösungen einzustellen,
zumal keines der von Dir genannten Init-Systeme irgendeinen
signifikanten Vorteil gegenüber systemd für sich reklamieren oder auch
nur eine ähnliche Funktionalität anbieten kann.
Sheeva P. schrieb:>> Aber nun stelle dir vor, du willst es z.B. nur auf einer bestimmten von>> mehreren IPs auf verbindungen warten lassen.>> Das wäre natürlich eine Sache der Applikation und nicht des> Init-Systems
...
>> Um diese simple änderung zu machen, müsste man also ein service override>> erstellen, und ein After=network-online.target hinein schreiben.>> In diesem Fall ist das komplette systemd-Unitfile unter meiner eigenen> Kontrolle, und wenn ich will, kann ich da jederzeit statt network.target> auch network-online.target hineinschreiben.
Das weiss ich alles bereits, darauf wollte ich auch gar nicht hinaus. Es
geht darum, dass man eine Triviale Änderung an der Konfiguration des
Programms macht, und es indeterministisch beim Booten nichtmehr startet,
und man Hintergrundwissen über Systemd benötigt, um das Problem zu
lösen. Dieses Wissen bekommt man dann bei Systemd auf die harte Tour,
nämlich wenn dann plötzlich mal etwas nicht Funktioniert.
> Eine alternative Möglichkeit ist, systemd-networkd-wait-online.service> (oder für Systeme mit NetworkManager:> NetworkManager-wait-online.service) zu aktivieren. Dann wird> network.target erst ausgelöst, nachdem network-online.target erreicht> worden ist.
Perfekt, weil zu viele nicht wissen wie man die Unit Files entsprechend
anpasst, wird einfach ein Workarround eingeführt. Das macht die
Situation natürlich besser.
Sheeva P. schrieb:>> Zugegeben, das Format und Konzept von Systemd Unit files ist nicht>> schlecht, es ist auch nicht neu, aber muss es wirklich jede>> Konfigurationsdatei und jedes altbewährte Konzept ersetzen?>> Wenn es logische Zusammenhänge zwischen diesen Komponenten gibt, die> sich besser abbilden lassen als mit den alten -- dabei jedoch keineswegs> immer bewährten -- Konzepten? Ja, unbedingt! Die "altbewährten Konzepte"> sind bei näherer Betrachtung oft nur eine Sammlung von Lösungen, die> mangels besserer Alternativen erdacht und benutzt wurden, und über die> Jahre zwar einen bemerkenswert hohen Grad an Stabilität und Reife> erreicht haben, aber dennoch eine unelegante, unzusammenhängende> Sammlung von Behelfen bleiben. Daß etwas alt und lange benutzt worden> ist, heißt weder, daß es gut ist, noch, daß es nicht durch etwas> Besseres ersetzbar wäre.
Ich stimme hier nur teilweise überein:
* Ja, es gab für unterschiedliche Aufgaben unterschiedliche und
unzusammenhängende Befehle. In anderen Worten, es gab viele Programme
die nur eine Aufgabe gut machten und keine konkrete Funktionsweise, kein
konkretes UI, etc. anderer Programme oder Packete voraussetzten.
* Nein, diese wurden nicht nur mangels besserer Alternativen benutzt,
sie wurden benutzt, weil diese die Beste mögliche Lösung für ein
spezifisches Problem waren, und kein Allgemeiner Lösungsversuch für
alles. Wenn man andere Anforderungen hatte, konnte man einfach einen
anderen Service schreiben. Als Beispiel: Auf meiner Firewall läuft
unbound, in meinen Subnets nutze ich dnsmasq, und mein Authoritativer
DNS Server verwendet bind9. Nur weil das alles DNS Server sind, kann ich
diese nicht einfach durch systemd-resolved ersetzen. Ich verwende exakt
den Service, welcher den jeweiligen Job am besten macht.
* Ja, nur weil etwas alt und lange benutzt wurde heisst nicht das es
gut ist oder nicht durch etwas besseres Ersetzbar wäre.
Das heisst aber nicht, das ich einen neuen Hut will, wenn ich mir neue
Schuhe kaufe. Das wäre out of scope.
> Mittlerweile gibt es allerdings eine bessere Alternative, nämlich> systemd, das viele Dinge sehr viel einfacher, eleganter, und zentral an> der Stelle löst: Starten, Stoppen, Statusabfrage von Daemons,> Privilegienseparation, Logging, Daemonization, Dependencies,
Ja die Service files sind besser als was Sysvinit hatte, aber die
Konzepte von OpenRC und Shepard finde ich mindestens genauso gut.
Insgesamt finde ich Systemd aber schlechter als die Alternativen. Hast
du schon mal versucht, auf Debian Systemd zu deinstallieren und z.B.
OpenRC zu installieren? Nur mit apt-get install und apt-get remove kommt
man da nicht besonders weit, weil einfach alles davon abhängt. Eine
Anwendung braucht hostnamectl, weil Änderungen in "/etc/hostname" jetzt
überschrieben werden und "hostname" nichtsmer bringt? Das gibts nur im
Komplettpacket mit Systemd! Meine anwendung verwendet dbus? Oh, Systemd
hat es übernommen und ein proprietäres Protokoll eingeführt? Klarer
fall, ich muss Systemd in die Anwendung für IPC einbauen und fordere von
jedem, der sie Installiert, Systemd zu installieren! Warum sollte man
etwas anderes wollen? Ich könnte das hier endlos fortführen. Systemd
müsste nicht derart invasiv sein, das ist beabsichtigt.
> und so weiter -- alles unter einem "Dach", zentral an einer Stelle, und mit> einer einheitlichen Syntax und Sprache für alle Daemons und über alle> verbreiteten Distributionen.
Alles schön und gut, aber ich will nicht dazu gezwungen sein es
verwenden zu müssen. Wenn es sich auf das Init System beschränken würde,
und seine Alternativen Services nicht gegenseitig voneinander abhängig
wären, hätte ich überhaubt kein Problem mit Systemd.
Sheeva P. schrieb:> Was an resolv.conf und Pidfiles so gut sein soll, daß man es unbedingt> behalten will, erschließt sich mir nicht. Zumal die resolv.conf ohnehin> von resolvconf(8) oder dem NetworkManager verwaltet wird und Pidfiles> nur eine Krücke sind, damit das Init-System seine Prozesse wiederfindet.> Dank kann man sich den ganzen Zinnober mit dem Daemonizing,> Logkonfiguration, Pidfile-Gefumsel und so weiter komplett sparen.
Gut, auf Pidfiles kann ich noch verzichten. Aber die /etc/resolve.conf
will ich nicht missen. Auf meinem Server mit einer statischen IP
bearbeite ich diese manuell, ohne NetworkManager, resolvconf oder
dhclient. Auf meinem Arbeitsplatzrechner lasse ich diese zusammensetzen,
damit ich sowohl die DHCP search domains und die VPN Search domains
habe, und trotzdem meinen lokalen DNS Server nutzen kann um den Traffic
auf die richtigen DNS Server je nach Domain aufzuteilen. Auf meinem
Laptop wird die Datei von dhclient geupdated. Es gibt damit keine
Probleme, alles funktioniert einwandfrei, und es ist echt einfach zu
verwenden. Wieso sollte ich das ersetzen wollen. Und als Bonus: Was
passiert mit Systemd-resolved wenn man keine DNS Konfiguriert? Genau,
Google DNS ist als Default hardcodiert, keine DNS verwenden nicht
möglich! Was könnte man denn schon anderes erwarten, ist doch jedem
sofort klar auch ohne Dokumentation? It's not a bug, it's a feaure:
Won't Fix! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658Sheeva P. schrieb:> Es bietet zunächst bei Weitem nicht die Funktionalität, die systemd an> dieser Stelle anbietet. Da kannst Du Dein Programm nicht stoppen, nicht temporär
deaktivieren
Doch, ich nehme einfach den Eintrag raus und mache init q oder telinit
q.
> Abhängigkeiten werden nicht berücksichtigt,
Weisst du, da gab es doch mal dieses total veraltete konzept von
runlevels, die ja sprichwörtlich in inittab angegeben sind. Sobald die
Services im entsprechenden Runlevel gestartet sind, kann man sich
einloggen, ohne Überraschungen zu erleben. Man vergleiche das mit
Systemd: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1650634https://bugzilla.redhat.com/show_bug.cgi?id=1043212https://lists.fedoraproject.org/pipermail/users/2014-January/444923.html> Du mußt Dich manuell ums Logging, Logrotation etc. kümmern, ... daß das> einfacher ist, halte ich ehrlich gesagt für Unfug.
Nein, darum kümmert sich der Logging service. Man konnte vorher syslog,
rsyslog, etc. installieren, ohne in systemd-logger etwas zu verstellen.
Wenn die Anwendung nach stdout schreibt, geht auch eine pipe nach
logger. Einfacher geht es nicht, Anwendungen ohne gutes Logging sind
sowieso misst, oder derart Simpel das es nicht nötig ist. Ausserdm, Was
soll ich den beim Login Programm überhaupt loggen? Authentifizierung
macht ja sowieso PAM (pam gibt es noch oder?).
Sheeva P. schrieb:>> Sysvinit ist wirklich nicht Perfekt, aber es gibt ja einige Alernativen.>> Ja, genau, und systemd ist eine davon -- und, meiner Meinung nach, auch> eine ziemlich gut gelungene. Die Tatsache, daß auch Debian und Derivate> sowie RedHat nebst Derivaten allesamt auf systemd setzen, ist ein Indiz> dafür, daß systemd nicht nur mich, sondern auch die gemeinhin ziemlich> fähigen Verantwortlichen der betreffenden Distributionen überzeugt hat.
Da bin ich anderer Meinung. Lennart Poettering, der typ hinter der
Systemd Geschichte, arbeitet bei RedHat. Bei der Umstellung bei Debian
gab es viele Gegner, viele haben sich für ihr init System nicht
interressiert, und es wurde hauptsächlich genommen, weil Sysvinit als
nicht gut befunden wurde. Debian Derivete hatten keine andere wahl mehr,
als zu Systemd zu wechseln. Canonical war am entwickeln von upstart,
aber Systemd nicht zu übernehmen war einfach nicht machbar.
Und hören wir mal, was Lennart Poettering so sagt:
https://www.youtube.com/watch?v=DUUbFGNZ1vI&feature=youtu.be&t=16m56s
Ich Zitiere:
> Systemd of course came over the last year to this point where we> basically won. All the major distributions have adopted it and it's> now in the commercial distributions and yeah, we won. Which of course> raises the questions where to go next. We always had this element of> fighting in systemd that we actually needed to make sure that people> actually use our stuff and that we get the broader linux ecosystem to> actually adopt this stuffSheeva P. schrieb:>> z.B. OpenRC oder Shepard, jenachdem was man will. Upstart war eigentlich>> ganz gut, schade das Canonical wegen Debian auf Systemd wechseln>> musste...>> Tja, systemd ist einheitlich, stabil und produktionsreif, und wird von> den meisten verbreiteten Distributionen verwendet.
Bisher ist mir noch fast jede nicht ganz standard Konfiguration mit
Systemd bei einem Update kaputt gegangen. Bei Nicht Systemen systemen
hatte ich soetwas noch nicht, oder nur sehr selten.
> Upstart war zwar ganz> nett, dann aber doch nur eine weitere Insellösung wie die> SysV-Startskripte.
Es hat Getan was es sollte, und nicht noch 100 andere Dinge, ohne alles
von sich abhängig zu machen.
> Als Entwickler und als Admin habe ich aber keinen> Bock, mich ständig auf immer wieder neue Insellösungen einzustellen,> zumal keines der von Dir genannten Init-Systeme irgendeinen> signifikanten Vorteil gegenüber systemd für sich reklamieren oder auch> nur eine ähnliche Funktionalität anbieten kann.
Du meinst im gegensatz zu Systemd erledigen sie ihre eigentliche
Aufgabe? Prozesse überwchen & neu starten, Dependencies, Asynchroner
Boot vorgang,
Jenachdem was man will gibt es ein init system dafür. Glaub es oder
nicht, auch die ganzen features wie cgroups wurden nicht von systemd
erfunden. Und zu guter letzt weiss ich von jedem Service genau was er
tut, und dass er nichts tut das ich nicht so eingestellt habe. Kannst du
das auch von deinen Systemd Systemen behaupten? Als Entwickler und als
Admin will ich von allem auf meinem System ganz ganau wissen, was es
tut. Ausserdem kann ich ohne Systemd einen deterministischen Bootvorgang
ohne Überraschungen sicherstellen. Natürlich Informiere ich mich
trotzdem über alles was sich bei Systemd ändert. Sei deinen Freunden
nah, doch deinen Feinden noch näher. Für dich mag Systemd alles sein was
du willst, aber für mich ist es nichts.
Daniel A. schrieb:> Das weiss ich alles bereits,
Es hätte mich auch sehr gewundert, wenn Du das nicht gewußt hättest,
aber ich hatte den Eindruck, daß es Dir temporär entfallen sei. ;-)
> geht darum, dass man eine Triviale Änderung an der Konfiguration des> Programms macht, und es indeterministisch beim Booten nichtmehr startet,> und man Hintergrundwissen über Systemd benötigt, um das Problem zu> lösen. Dieses Wissen bekommt man dann bei Systemd auf die harte Tour,> nämlich wenn dann plötzlich mal etwas nicht Funktioniert.
Dann fragt man systemd nach den Logs:
1
systemctl status <unit>
Obendrein kann man auch mit journalctl ins systemd-Journal schauen, und
muß dabei nicht einmal wissen, wo die konkrete Syslog-Konfiguration die
betreffenden Daten hinloggt (war's jetzt /var/log/messages oder
/var/log/syslog?). Das ist keine harte Tour, sondern nur anders.
>> Eine alternative Möglichkeit ist, systemd-networkd-wait-online.service>> (oder für Systeme mit NetworkManager:>> NetworkManager-wait-online.service) zu aktivieren. Dann wird>> network.target erst ausgelöst, nachdem network-online.target erreicht>> worden ist.>> Perfekt, weil zu viele nicht wissen wie man die Unit Files entsprechend> anpasst, wird einfach ein Workarround eingeführt. Das macht die> Situation natürlich besser.
Ja, das macht die Situation besser, weil network.target und
network-online.target eindeutig definierte Ziele sind, was das $network
von SysV-Init nie war. Das ist deswegen auch kein Workaround, sondern
eine Erweiterung für Leute mit speziellen Bedürfnissen. Und,
entschuldige, aber es ist kein Argument für oder wider ein beliebiges
Init-System, daß man dazu umlernen und sich an die verwendeten Werkzeuge
und Konfigurationen gewöhnen muß -- das gilt für die verschiedenen
Geschmacksrichtungen von SysV-Init ebenso wie für OpenRC, Shepherd,
Upstart und alle anderen.
> Ich stimme hier nur teilweise überein:> * Ja, es gab für unterschiedliche Aufgaben unterschiedliche und> unzusammenhängende Befehle. In anderen Worten, es gab viele Programme> die nur eine Aufgabe gut machten und keine konkrete Funktionsweise, kein> konkretes UI, etc. anderer Programme oder Packete voraussetzten.
Es gab vor vor allem, distributionsübergreifend betrachtet, ein
heilloses Durcheinander, weil jede Distribution ihre eigenen
SysV-Init-Kommandos mit ihren eigenen Kommandos und Funktionen benutzt
hat.
> * Nein, diese wurden nicht nur mangels besserer Alternativen benutzt,> sie wurden benutzt, weil diese die Beste mögliche Lösung für ein> spezifisches Problem waren, und kein Allgemeiner Lösungsversuch für> alles.
Ja, genau: jedes dieser Werkzeuge hat nur sein eigenes kleines
Problemchen gelöst. Ein "System" im Sinne einer sauberen, konsistenten
und aufeinander abgestimmten Lösung für die vielen Dinge, die es beim
Systemstart, beim Servicemanagement, beim Logging und beim Monitoring
gibt, gab es nicht. Und um das Chaos perfekt zu machen, hat jeder
Distributor eigene Versionen und Geschmäcker der betreffenden Werkzeuge
entwickelt.
> Wenn man andere Anforderungen hatte, konnte man einfach einen> anderen Service schreiben.
Ja, und heute schreibt man ein anderes Unitfile oder, wo bereits eines
vorhanden ist, eben ein Override.
> Als Beispiel: Auf meiner Firewall läuft> unbound, in meinen Subnets nutze ich dnsmasq, und mein Authoritativer> DNS Server verwendet bind9. Nur weil das alles DNS Server sind, kann ich> diese nicht einfach durch systemd-resolved ersetzen.
Natürlich, denn systemd-resolved ist ja auch kein DNS-Server, sondern
vor allem ein lokaler Cache wie weiland der nscd.
>> Ja, nur weil etwas alt und lange benutzt wurde heisst nicht das es>> gut ist oder nicht durch etwas besseres Ersetzbar wäre.>> Das heisst aber nicht, das ich einen neuen Hut will, wenn ich mir neue> Schuhe kaufe. Das wäre out of scope.
Das solltest Du lieber nicht mit meiner Ehefrau, meiner besten Freundin
oder Deiner Liebsten diskutieren. There be dragons! ;-)
>> Mittlerweile gibt es allerdings eine bessere Alternative, nämlich>> systemd, das viele Dinge sehr viel einfacher, eleganter, und zentral an>> der Stelle löst: Starten, Stoppen, Statusabfrage von Daemons,>> Privilegienseparation, Logging, Daemonization, Dependencies,>> Ja die Service files sind besser als was Sysvinit hatte, aber die> Konzepte von OpenRC und Shepard finde ich mindestens genauso gut.
Mag sein, aber die großen Distributoren haben sich -- nicht zuletzt
auch, weil andere Alternativen damals noch in den Kinderschuhen steckten
-- nun einmal für systemd entschieden.
> Insgesamt finde ich Systemd aber schlechter als die Alternativen. Hast> du schon mal versucht, auf Debian Systemd zu deinstallieren und z.B.> OpenRC zu installieren?
Nein. Ich habe auch noch nicht versucht, die glibc zu deinstallieren und
durch die Dietlibc zu ersetzen.
> Nur mit apt-get install und apt-get remove kommt> man da nicht besonders weit, weil einfach alles davon abhängt. Eine> Anwendung braucht hostnamectl, weil Änderungen in "/etc/hostname" jetzt> überschrieben werden und "hostname" nichtsmer bringt? Das gibts nur im> Komplettpacket mit Systemd! Meine anwendung verwendet dbus? Oh, Systemd> hat es übernommen und ein proprietäres Protokoll eingeführt? Klarer> fall, ich muss Systemd in die Anwendung für IPC einbauen und fordere von> jedem, der sie Installiert, Systemd zu installieren! Warum sollte man> etwas anderes wollen? Ich könnte das hier endlos fortführen.
Natürlich könntest Du ewig darüber fortführen, daß systemd ein ziemlich
umfassendes und umfangreiches System ist, für dessen profitable Nutzung
man viele Dinge neu und altbekannte umlernen muß.
> Systemd müsste nicht derart invasiv sein, das ist beabsichtigt.
Systemd versucht, eine Vielzahl von Dingen konsistent, korrekt, und ein
für alle Male endgültig zu lösen, und das ist dann auch der Grund dafür,
daß es so invasiv ist. Ja, natürlich ist es beabsichtigt, das frühere
Chaos durch eine einheitliche Lösung zu ersetzen.
> Alles schön und gut, aber ich will nicht dazu gezwungen sein es> verwenden zu müssen.
Dann laß' es doch, zwingt Dich ja keiner dazu. Devuan existiert, Gentoo
und Alpine benutzen OpenRC und Guix den GNU Shepherd. Das Schöne an der
Vielfalt der Linux-Distributionen ist ja, daß man eine Wahl hat. Mir hat
SuSEs zypper nicht gefallen, deswegen bin ich zu Ubuntu gewechselt, und
wenn mir APT oder systemd irgendwann nicht mehr gefallen, dann suche ich
mir einfach eine andere Distribution -- oder folge dem formidablen Jörg
Wunsch und gehe zu Free-, Net- oder OpenBSD.
> Wenn es sich auf das Init System beschränken würde,> und seine Alternativen Services nicht gegenseitig voneinander abhängig> wären, hätte ich überhaubt kein Problem mit Systemd.
Also ist Dein Problem im Kern darin begründet, daß systemd so viele
Dinge tut, vom Systemboot über das Login- und Servicemanagement, das
Logging, die Netzwerkverwaltung und so weiter. Ok, darüber kann man
diskutieren, dann aber bitte ohne darüber zu klagen, daß dieses wie
jedes neue System eben erstmal erlernt werden muß.
> Gut, auf Pidfiles kann ich noch verzichten. Aber die /etc/resolve.conf> will ich nicht missen. Auf meinem Server mit einer statischen IP> bearbeite ich diese manuell, ohne NetworkManager, resolvconf oder> dhclient.
Prima, dann mußt Du zur Netzwerkkonfiguration also bereits zwei Dateien
anfassen: die /etc/network/interfaces und /etc/resolv.conf. Nein, sorry,
da konfiguriere ich mein Netzwerk lieber komplett über die
interfaces-Datei, dank resolvconf inklusive Nameserver und Suchpfad. So
ist alles schön übersichtlich an genau einer einzigen Stelle
zusammengefaßt. Für einen einzelnen Server spielt das vermutlich keine
Rolle, aber spätestens wenn das Netzwerk wächst und Du ein paar Dutzend
Server verwalten mußt, kostet jede weitere zu editierende Datei nur
Zeit, Geld, und Nerven.
> Auf meinem Arbeitsplatzrechner lasse ich diese zusammensetzen,> damit ich sowohl die DHCP search domains und die VPN Search domains> habe, und trotzdem meinen lokalen DNS Server nutzen kann um den Traffic> auf die richtigen DNS Server je nach Domain aufzuteilen. Auf meinem> Laptop wird die Datei von dhclient geupdated. Es gibt damit keine> Probleme, alles funktioniert einwandfrei, und es ist echt einfach zu> verwenden. Wieso sollte ich das ersetzen wollen.
Zum Beispiel, weil Dein Distributor auf ein neues Init-System setzt, das
diese Dinge anders handhabt als bisher.
> Und als Bonus: Was> passiert mit Systemd-resolved wenn man keine DNS Konfiguriert? Genau,> Google DNS ist als Default hardcodiert, keine DNS verwenden nicht> möglich! Was könnte man denn schon anderes erwarten, ist doch jedem> sofort klar auch ohne Dokumentation? It's not a bug, it's a feaure:> Won't Fix! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
Entschuldige, aber ein Netzwerk-Setup ohne DNS ist kein Argument,
sondern einfach nur sinnlos. Und für die, die das nicht wissen, gibt es
einen IMO halbwegs sinnvollen Default. Wo ist das Problem?
> Sheeva P. schrieb:>> Es bietet zunächst bei Weitem nicht die Funktionalität, die systemd an>> dieser Stelle anbietet. Da kannst Du Dein Programm nicht stoppen, nicht>> temporär deaktivieren>> Doch, ich nehme einfach den Eintrag raus und mache init q oder telinit> q.
Also editierst Du eine Datei, kommentierst das Entsprechende aus, und
rufst dann ein Kommando auf, um Deinem Init-Prozeß zu sagen, daß er die
Datei bitte neu laden soll. Sorry, aber verglichen mit einem schlichten
"systemctl stop <daemon>" ist das aufwändig und fehleranfällig.
> Weisst du, da gab es doch mal dieses total veraltete konzept von> runlevels,
Das gibt es immer noch als runlevel?.target -- und obendrein mit neuen,
sprechenden Namen.
> Nein, darum kümmert sich der Logging service. Man konnte vorher syslog,> rsyslog, etc. installieren,
Genau -- und schon haben wir wieder eine weitere eigene Komponente, die
installiert, konfiguriert und gepflegt werden muß.
> Da bin ich anderer Meinung. Lennart Poettering, der typ hinter der> Systemd Geschichte, arbeitet bei RedHat.
Ja, ich weiß. Aber was möchtest Du mir damit sagen? Alan Cox war auch
bei RedHat, genauso wie viele andere bekannte Kernel- und
Systementwickler.
> Bei der Umstellung bei Debian gab es viele Gegner,
...und viele Befürworter, und die haben sich durchgesetzt.
> Debian Derivete hatten keine andere wahl mehr, als zu Systemd zu> wechseln.
Devuan existiert und ist der beste Beweis dafür, daß das nicht stimmt.
>> Systemd of course came over the last year to this point where we>> basically won.
Da hat er doch völlig Recht: systemd hat sich durchgesetzt, und zwar
trotz der Tatsache, daß es äußerst umfangreich und systemintrusiv ist,
und trotz der Tatsache, daß es die POSIX-Kompatibilität bricht. Lennart
hat schon seit vielen Jahren die Zerfaserung der Major-Distributionen
kritisiert und freut sich jetzt, daß er sich mit seinem Ansatz zur
Vereinheitlichung auf breiter Linie durchsetzen konnte.
> Bisher ist mir noch fast jede nicht ganz standard Konfiguration mit> Systemd bei einem Update kaputt gegangen. Bei Nicht Systemen systemen> hatte ich soetwas noch nicht, oder nur sehr selten.
Tja, mir sind bisher noch keine Konfigurationen kaputtgegangen, weder
mit systemd, noch anderweitig. Aber da mein Team und ich einige Hundert
Server verwalten, halten wir uns strikt an vorhandene Standards, und in
wenigen, dokumentierten Ausnahmefällen an Best Current Practices. Anders
ist das im Team gar nicht zu bewerkstelligen. Deswegen geht bei uns
erstaunlich wenig kaputt, weder ohne noch mit systemd.
> Es hat Getan was es sollte, und nicht noch 100 andere Dinge, ohne alles> von sich abhängig zu machen.
Es gab trotzdem überall und immer wieder subtile Abhängigkeiten, die man
kennen und bedienen mußte.
> Jenachdem was man will gibt es ein init system dafür. Glaub es oder> nicht, auch die ganzen features wie cgroups wurden nicht von systemd> erfunden.
Vielen Dank für den Hinweis, aber das wußte ich schon.
> Und zu guter letzt weiss ich von jedem Service genau was er> tut, und dass er nichts tut das ich nicht so eingestellt habe. Kannst du> das auch von deinen Systemd Systemen behaupten?
Ja.
> Für dich mag Systemd alles sein was du willst, aber für mich ist es> nichts.
Das hat ja keiner verlangt, und die Alternativen existieren -- und
FreeBSD natürlich auch. ;-)
Sheeva P. schrieb:>> * Nein, diese wurden nicht nur mangels besserer Alternativen benutzt,>> sie wurden benutzt, weil diese die Beste mögliche Lösung für ein>> spezifisches Problem waren, und kein Allgemeiner Lösungsversuch für>> alles.>> Ja, genau: jedes dieser Werkzeuge hat nur sein eigenes kleines> Problemchen gelöst. Ein "System" im Sinne einer sauberen, konsistenten> und aufeinander abgestimmten Lösung für die vielen Dinge, die es beim> Systemstart, beim Servicemanagement, beim Logging und beim Monitoring> gibt, gab es nicht.
Nur weil die einzelnen Teile nicht aufeinander angewiesen waren, heisst
das nicht, dass diese zusammen keine Saubere und Konsistente lösung
bilden. Beispiel Logging, gibt es irgend einen Grund, warum man Systemd
braucht, um systemd-journald zu verwenden? Einer Anwendung ist es völlig
egal, ob jetzt journald, rsyslog oder syslog verwendet wird. rsyslog und
syslog ist es vollkommen egal, ob man jetzt Systemd, OpenRC oder
SysVinit verwendet. Aber JournalD benötigt Systemd und umgekehrt. (und
ja, ich weiss dass man rsyslog immernoch parallel zu journald
installieren kann). Die Tools und das UI sind in Ordnung, aber die
Architektur ist totaler misst. Das ist nicht Sauber aufeinander
abgestimmt, das ist einfach nur wild zusammengeschweisst.
> Und um das Chaos perfekt zu machen, hat jeder> Distributor eigene Versionen und Geschmäcker der betreffenden Werkzeuge> entwickelt.
So gross sind die Unterschiede auch wieder nicht. Eventuell sind einige
Config Files woanders, oder ein Bug wurde anders gefixt, aber dass wars
dann auch schon.
>> Systemd müsste nicht derart invasiv sein, das ist beabsichtigt.>> Systemd versucht, eine Vielzahl von Dingen konsistent, korrekt, und ein> für alle Male endgültig zu lösen, und das ist dann auch der Grund dafür,> daß es so invasiv ist. Ja, natürlich ist es beabsichtigt, das frühere> Chaos durch eine einheitliche Lösung zu ersetzen.
Für mich sieht es eher so aus, als würde die frühere wunderschöne
Harmonie und Diversität durch ein einheitliches Monolithisches Chaos mit
nettem UI ersetzt. Ganz zu schweigen davon, das es den korrekten Weg
garnicht gibt, weil jeder wieder andere Anforderungen haben kann.
>> Alles schön und gut, aber ich will nicht dazu gezwungen sein es>> verwenden zu müssen.>> Dann laß' es doch, zwingt Dich ja keiner dazu. Devuan existiert, Gentoo> und Alpine benutzen OpenRC und Guix den GNU Shepherd. Das Schöne an der> Vielfalt der Linux-Distributionen ist ja, daß man eine Wahl hat.
Das ist wahr. Aber diese Distributionen haben es nicht einfach. Systemd
zu entfernen ist ein Mammutprojekt. Devuan zum Beispiel ist immernoch in
der Beta Phase, arbeitet daran udev zu ersetzen, und musste shims für
Anwendungen schreiben, die libsystemd0 benötigen, etc. Diese
Abhängigkeiten tauchen an den Undankbarsten stellen auf, inklusive
Server und Desktop Anwendungen. Wenn es nicht derart viele gäbe, die
Systemd nicht benutzen wollen oder können, und aktiv daran Arbeiten,
wären diese Distributionen undenkbar.
>> Wenn es sich auf das Init System beschränken würde,>> und seine Alternativen Services nicht gegenseitig voneinander abhängig>> wären, hätte ich überhaubt kein Problem mit Systemd.>> Also ist Dein Problem im Kern darin begründet, daß systemd so viele> Dinge tut, vom Systemboot über das Login- und Servicemanagement, das> Logging, die Netzwerkverwaltung und so weiter. Ok, darüber kann man> diskutieren, dann aber bitte ohne darüber zu klagen, daß dieses wie> jedes neue System eben erstmal erlernt werden muß.
Schon klar, ich wollte damit ausdrücken, dass man beides Lernen muss und
es überall spezielle Dinge gibt, die man erst herausfinden muss. Deshalb
glaube ich nicht, dass das eine einfacher als das andere ist. Es sind
einfach andere Schwierigkeiten, die für unterschiedliche Personen
unterschiedlich Schwierig zu lösen sind.
>> Auf meinem Arbeitsplatzrechner lasse ich diese zusammensetzen,>> damit ich sowohl die DHCP search domains und die VPN Search domains>> habe, und trotzdem meinen lokalen DNS Server nutzen kann um den Traffic>> auf die richtigen DNS Server je nach Domain aufzuteilen. Auf meinem>> Laptop wird die Datei von dhclient geupdated. Es gibt damit keine>> Probleme, alles funktioniert einwandfrei, und es ist echt einfach zu>> verwenden. Wieso sollte ich das ersetzen wollen.>> Zum Beispiel, weil Dein Distributor auf ein neues Init-System setzt, das> diese Dinge anders handhabt als bisher.
Nein, das Init-system verhält sich dort bei allen gleich. Es ist nur so,
dass ich bei meinem Arbeitsplatzrechner verschiedene Services nur einen
kleinen Teil der DNS Konfiguration ändern lassen muss, wenn ich diese
verwende, und nicht die Gesamte, während ich auf meinem Laptop ein
relativ gewöhnliches Netzwerk Setup habe.
> Entschuldige, aber ein Netzwerk-Setup ohne DNS ist kein Argument,> sondern einfach nur sinnlos. Und für die, die das nicht wissen, gibt es> einen IMO halbwegs sinnvollen Default. Wo ist das Problem?
Das Problem ist, dass es etwas tut, dass ich nicht eingestellt habe, und
ich nicht ausstellen kann. Es ist auch nicht sinnlos, ich kann immernoch
per IP auf andere Geräte zugreifen und bemerke wenigstens, wenn mit
meiner DNS Konfiguration, die auch über DHCP gekommen sein könnte, etwas
nicht stimmt. Eventuell habe ich z.B. ein Rechen Cluster, welches per
Multicast kommuniziert und keine DNS benötigt und mit DNS Lookups keine
zeit verschwenden soll, weil es nur rechnen soll. Oder sonst einen
non-standard Grund, ich gehe mit den Technischen Möglichkeiten gerne ans
Limit.
>> Doch, ich nehme einfach den Eintrag raus und mache init q oder telinit>> q.>> Also editierst Du eine Datei, kommentierst das Entsprechende aus, und> rufst dann ein Kommando auf, um Deinem Init-Prozeß zu sagen, daß er die> Datei bitte neu laden soll. Sorry, aber verglichen mit einem schlichten> "systemctl stop <daemon>" ist das aufwändig und fehleranfällig.
Dafür kann ich mir meinen Login Bildschirm nicht ausversehen stoppen, am
besten noch über das Stoppen von einem anderen Service.
>> Nein, darum kümmert sich der Logging service. Man konnte vorher syslog,>> rsyslog, etc. installieren,>> Genau -- und schon haben wir wieder eine weitere eigene Komponente, die> installiert, konfiguriert und gepflegt werden muß.
Journald muss genauso Konfiguriert und Gepflegt werden, auch wenn bei
Systemd servicen die Maintainer teilweise etwas Interessante
Auffassungen dazu haben, was ein Bug ist und was geändert werden muss.
Auf nicht systemd Systemen hat man immer nur einen logging Service, den
man nur einmal Konfigurieren muss. Nur weil man mehr Auswahl hat, hat
man nicht mehr Arbeit.
>> Da bin ich anderer Meinung. Lennart Poettering, der typ hinter der>> Systemd Geschichte, arbeitet bei RedHat.>> Ja, ich weiß. Aber was möchtest Du mir damit sagen? Alan Cox war auch> bei RedHat, genauso wie viele andere bekannte Kernel- und> Systementwickler.
Ich will damit sagen, dass es nicht erstaunlich ist, das RedHat
Programme übernimmt, die seine Entwickler erstellt haben.
>> Debian Derivete hatten keine andere wahl mehr, als zu Systemd zu>> wechseln.>> Devuan existiert und ist der beste Beweis dafür, daß das nicht stimmt.
Nein, es ist ein Beweis dafür, wie schwierig das ist. Alle Debian
Distributionen ohne Systemd basieren auf Devuan. Devuan hat immernoch
kleine Überbleibsel von Systemd und ist noch im Beta Stadium. Grosse
Distributionen können es sich nicht zur Lebensaufgabe machen, Systemd zu
entfernen, und können es nicht Riskieren auf eine andere
Basisdistribution zu wechseln, dessen Zukunft derart ungewiss ist.
>>> Systemd of course came over the last year to this point where we>>> basically won.>> Da hat er doch völlig Recht: systemd hat sich durchgesetzt, und zwar> trotz der Tatsache, daß es äußerst umfangreich und systemintrusiv ist,> und trotz der Tatsache, daß es die POSIX-Kompatibilität bricht. Lennart> hat schon seit vielen Jahren die Zerfaserung der Major-Distributionen> kritisiert und freut sich jetzt, daß er sich mit seinem Ansatz zur> Vereinheitlichung auf breiter Linie durchsetzen konnte.
Das ist eine Betrachtungsmöglichkeit. Ich denke eher, dass es sich
durchgesetzt hat, weil es so systemintrusiv ist. Es ist ein Klassisches
Vendor-Lockin Szenario, sobald man es verwendet wird man es nichtmehr
los, weil bereits alles andere davon abhängt. Ich bin mir fast sicher,
dass das alles so beabsichtigt war, und das stört mich wirklich. Da
kommt eine Person und will seine Vorstellung vom "Richtigen" weg überall
durchsetzen.
>> Es hat Getan was es sollte, und nicht noch 100 andere Dinge, ohne alles>> von sich abhängig zu machen.>> Es gab trotzdem überall und immer wieder subtile Abhängigkeiten, die man> kennen und bedienen mußte.
Sicher, aber diese lassen sich meist auch sehr einfach ändern.
Daniel A. schrieb:> Einer Anwendung ist es völlig egal, ob jetzt journald, rsyslog oder> syslog verwendet wird.
Nein -- weder der Anwendung selbst, noch dem Systemadministrator und dem
Entwickler. Dank systemd kann man heute einfach auf std{out,err} loggen,
und journald kümmert sich um den Rest. Dazu waren früher entweder eine
Anbindung an r?syslogd oder fiese Hacks nötig.
> So gross sind die Unterschiede auch wieder nicht. Eventuell sind einige> Config Files woanders, oder ein Bug wurde anders gefixt, aber dass wars> dann auch schon.
Ich sag' nur start-stop-daemon (Debian) versus das RedHat-Zeug. Um auf
die oben bereits erwähnten Initskripte für Wildfly zurück zu kommen: es
gibt gute Gründe, warum die Wildfly-Entwickler für beide Distributionen
je ein eigenes, mit je 208 und 298 Zeilen auch recht umfangreiche
Startskripte pflegen, deren unterschiedlicher Umfang ein deutlicher
Hinweis darauf ist, wie groß die Unterschiede tatsächlich sind. Nur zum
Vergleich: die Dateien für systemd haben einen Umfang von gerade einmal
27 Zeilen.
> Für mich sieht es eher so aus, als würde die frühere wunderschöne> Harmonie und Diversität durch ein einheitliches Monolithisches Chaos mit> nettem UI ersetzt.
Schau' doch bitte einfach mal in die erwähnten Startskripte von Wildfly
und verrate mir, wo Du da Harmonie entdeckst, gar eine wunderschöne. Mir
sich diese Schönheit leider nicht erschließen.
> Ganz zu schweigen davon, das es den korrekten Weg garnicht gibt, weil> jeder wieder andere Anforderungen haben kann.
Genau, und die Flexibilität, die diese unterschiedlichen Anforderungen
notwendig machen, ist der Grund für einen wesentlichen Teil ebenjener
Komplexität, die Du systemd jetzt vorwirfst.
> Das ist wahr. Aber diese Distributionen haben es nicht einfach.
Distributionen, die etwas anders machen wollen als der Mainstream,
hatten es noch nie einfach. Ich wüßte nicht, warum ausgerechnet systemd
etwas an diesem Umstand ändern sollte.
> Systemd zu entfernen ist ein Mammutprojekt. Devuan zum Beispiel ist> immernoch in der Beta Phase, arbeitet daran udev zu ersetzen,
Hm... hätte man da nicht lieber eine frühere Debian-Version ohne systemd
und dem alten udev nehmen und die weiterführen können, anstatt die Dinge
erst zu übernehmen und dann aufwändig wieder zu entfernen?
> Ich will damit sagen, dass es nicht erstaunlich ist, das RedHat> Programme übernimmt, die seine Entwickler erstellt haben.
Das halte ich auch nicht für erstaunlich. Allerdings haben auch
openSuSE, Debian, Ubuntu und Arch systemd übernommen, und für die
arbeitet Lennart doch wohl nicht, soweit bekannt.
>>> Debian Derivete hatten keine andere wahl mehr, als zu Systemd zu>>> wechseln.>>>> Devuan existiert und ist der beste Beweis dafür, daß das nicht stimmt.>> Nein, es ist ein Beweis dafür, wie schwierig das ist.
Entschuldige, aber das ist einerseits die Folge der Designentscheidung,
erst ein systemd-basiertes Debian zu nehmen und dann systemd aufwändig
wieder auszubauen. Andererseits hat es, wenn ich mich recht entsinne,
Linux-Systeme vor systemd gegeben, und tatsächlich gibt es sogar heute
noch welche. Es ist also offensichtlich so, daß man Linux-Systeme auch
ohne systemd booten und betreiben kann.
> Das ist eine Betrachtungsmöglichkeit. Ich denke eher, dass es sich> durchgesetzt hat, weil es so systemintrusiv ist. Es ist ein Klassisches> Vendor-Lockin Szenario, sobald man es verwendet wird man es nichtmehr> los, weil bereits alles andere davon abhängt. Ich bin mir fast sicher,> dass das alles so beabsichtigt war, und das stört mich wirklich.
Ich kann immer noch unter mehreren Linux-Distributionen mit systemd und
solchen ohne systemd wählen, und obendrein gibt es eine ganze Reihe von
Distributionen, die systemd nutzen. Wo soll da ein Vendor-Lockin sein?
Devuan zeigt außerdem, daß man es wieder loswerden kann. Richtig ist,
daß das nicht so ganz einfach ist, einerseits weil die Devuan-Leute sich
dazu entschieden haben, eine Distribution MIT systemd zu benutzen und
ihn DANN wieder herauszukonfigurieren, und andererseits, weil systemd
mittlerweile das udev-System übernommen hat, welches sich seit gefühlten
Ewigkeiten um die dynamische Hardware-Konfiguration kümmert. Ich
erinnere mich noch an die Wechsel von /dev auf devfs und dann auf udev.
Da gab es ganz ähnliche Diskussionen wie diese, teils sogar mit
denselben Argumenten und manchmal sogar exakt denselben Pro- und
Antagonisten. ;-)
> Da kommt eine Person und will seine Vorstellung vom "Richtigen" weg> überall durchsetzen.
Zum Durchsetzen gehören ja immer zwei: ein "Durchsetzer" und einer, der
das zuläßt. In diesem Falle haben sich alle Majors dazu entschieden, das
neue System zu benutzen, und ich nehme an, daß keiner mit vorgehaltener
Waffe dazu gezwungen worden ist.
Im Gegenteil hat es mittlerweile doch schon einige andere Versuche für
ein neues Init-System gegeben, zum Teil durchaus gelungene.
Offensichtlich gab es also noch andere Entwickler, die mit dem alten
SysV-Init nicht so recht glücklich waren und deswegen etwas Neues
entwickelt haben, etwa OpenRC und Upstart -- oder eben auch systemd.
Unter all diesen Init-Systemen hat sich systemd jetzt bei allen Majors
durchgesetzt, sogar bei denen, die selbst signifikante Investitionen in
ein eigenes Init-System getätigt hatten, wie Ubuntu mit Upstart. Dafür
gibt es sicherlich bessere Gründe als die hübschen blauen Augen seines
Entwicklers, und vermutlich liegt der eine oder andere Grund auch darin,
daß dieses System so viele mehr oder weniger zusammenhängende Probleme
konsistent, flexibel, einheitlich und, die Du ja selbst sagst, mit einem
durchaus gefälligen User Interface löst.
Wir als Nutzer haben jetzt die Wahl: entweder, wir freunden uns damit an
und bleiben bei den Major-Distributionen, oder wir tun es eben nicht und
suchen uns was anderes. Das Argument, daß man systemd nicht "wieder los"
würde, lasse ich dabei allerdings nicht gelten: das ist nämlich IMHO ein
künstliches Argument von Menschen, die systemd aus ganz anderen Gründen
los werden wollen, allen anderen stellt sich dieses Problem nämlich gar
nicht erst. Über diese anderen -- und nach meiner Wahrnehmung auch nicht
immer sachlichen oder technischen -- Gründe können wir zwar diskutieren.
Ich fürchte nur, daß das nichts nutzt: die Majors haben ihre
Entscheidung getroffen, der Drops ist gelutscht, und solange die User
nicht in höheren Anzahlen mit den Füßen abstimmen und sich andere
Distributionen suchen, werden die Majors an dieser Entscheidung
festhalten.
Ja, systemd bricht mit einigen UNIX-Traditionen, der
POSIX-Kompatibilität und die binären Logs gefallen mir auch nicht. Aber
ich stimme mit Linus Torvalds überein, daß das überschau- und lösbare
Details sind und daß die positiven Eigenschaften diese überwiegen.
Sheeva P. schrieb:> Es ist also offensichtlich so, daß man Linux-Systeme auch> ohne systemd booten und betreiben kann.
Das ist offensichtlich. Außer, du willst Dinge tun, die er so nicht
vorgesehen hat. Zum Beispiel /usr nachträglich mounten (Squashfs kann
sehr praktisch sein und Flash-Bausteine teuer). Sowas geht dann aus
Prinzip nicht, wie man bei deren Bugreports immer wieder schön sieht.
Auch der Support für /etc/rc.local wurde nur widerwillig nachgereicht.
Man bekommt dann immer dieses heimelige Apple-Gefühl, wo ein großer
weiser Mann über dir steht und dir sagt, was die richtige Lösung ist und
was du zu tun und zu lassen hast.
Sheeva P. schrieb:> Wo soll da ein Vendor-Lockin sein?
Die systemd-Entwickler lösen nicht nur ein Problem, sondern viele
gleichzeitig. Und bis zu einem gewissen Punkt funktioniert das auch
wunderbar. Der Vendor-Lockin kommt, weil alle anderen Lösungen von
denen, also alles, was nichts mit Init-System zu tun hat, aber trotzdem
äußerst praktisch ist, relativ grundlos systemd voraussetzt.
Um logind benutzen zu können, muss ich auch systemd benutzen. Und
plötzlich funktioniert mein gesamter Desktop nur richtig, wenn ich
systemd benutze. Obwohl der Desktop gar keine Dienste verwaltet!
Freut einen übrigens, wenn man merkt, dass z.B. xfce unter FreeBSD nur
eingeschränkt tauglich ist, weil das zugrundeliegende Gnome vollständig
auf logind aufsetzt und Alternativen nicht unterstützt werden.
Interoperabilität eingeschränkt.
Sheeva P. schrieb:> Entschuldige, aber ein Netzwerk-Setup ohne DNS ist kein Argument,> sondern einfach nur sinnlos.
Ein Netzwerk-Setup ohne DNS ist schlicht kaputt. *Und das will ich als
Systemadministrator auch wissen und nicht durch einen externen Fallback
verschleiert haben.*
Sonst gibt es nämlich so schöne Argumente wie
- bei manchen funktioniert es, bei anderen nicht
- Internet funktioniert, aber das lokale Netzwerk nicht
- Traffic wird produziert, obwohl doch alles abgeschaltet ist
Was mich an den systemd-Leuten hauptsächlich ankotzt, ist nichtmal deren
Software, sondern schlicht deren Selbstverständnis. "Wir lösen Probleme
und ihr müsst entweder exakt unseren Weg gehen oder sie selbst lösen.
Aber wir sorgen dafür, dass unsere Lösung alternativlos bleibt."
Es gab einen durchaus hörenswerten CRE mit Poettering, wo er mal über
Avahi, Pulseaudio und Systemd frei erzählt. Und ich finde z.B. eine
massive Diskrepanz zwischen seiner Beschreibung von Pulseaudio und der
Realität.
Es ist irgendwo bezeichnend, dass Poettering selbst
- nicht nennenswert Server administriert
- nur aktuelle Snapshots seiner Software verwendet.
Sheeva P. schrieb:> Devuan zeigt außerdem, daß man es wieder loswerden kann.
Es zeigt eher das Gegenteil. Eben weil Vendor-Lockin.
S. R. schrieb:> Sheeva P. schrieb:>> Es ist also offensichtlich so, daß man Linux-Systeme auch>> ohne systemd booten und betreiben kann.>> Das ist offensichtlich. Außer, du willst Dinge tun, die er so nicht> vorgesehen hat. Zum Beispiel /usr nachträglich mounten
Dazu kann man sicherlich btrfs und / oder unionfs verwenden.
> Die systemd-Entwickler lösen nicht nur ein Problem, sondern viele> gleichzeitig. Und bis zu einem gewissen Punkt funktioniert das auch> wunderbar. Der Vendor-Lockin kommt, weil alle anderen Lösungen von> denen, also alles, was nichts mit Init-System zu tun hat, aber trotzdem> äußerst praktisch ist, relativ grundlos systemd voraussetzt.
Also ist der eigentliche Vorwurf der hohe Integrationsgrad? Sorry, ich
sehe da durchaus Bezugspunkte zwischen systemd, logind, journald, und
den anderen systemd-Komponenten -- insbesondere dann, wenn man andere
Aspekte wie ulimits, Capabilities, SELinux, AppArmor, Controlgroups,
Linux Kernel Namespaces, Container etc. betrachtet.
Einer der Ansprüche von systemd war es, diese Dinge zusammenhängend und
konsistent zu lösen, und jetzt wirfst Du ihm genau diese Konsistenz vor.
Ein weiterer Anspruch von systemd war eine Standardisierung, und jetzt
wirfst Du ihm genau diese Standardisierung vor.
> Freut einen übrigens, wenn man merkt, dass z.B. xfce unter FreeBSD nur> eingeschränkt tauglich ist, weil das zugrundeliegende Gnome vollständig> auf logind aufsetzt und Alternativen nicht unterstützt werden.> Interoperabilität eingeschränkt.
Aus meiner Perspektive ist das aber kein Problem von systemd, sondern
von Gnome bzw. XFCE. Das als Kritikpunkt an systemd aufzuführen, geht
IMHO am eigentlichen Ziel vorbei.
> Sheeva P. schrieb:>> Entschuldige, aber ein Netzwerk-Setup ohne DNS ist kein Argument,>> sondern einfach nur sinnlos.>> Ein Netzwerk-Setup ohne DNS ist schlicht kaputt. *Und das will ich als> Systemadministrator auch wissen und nicht durch einen externen Fallback> verschleiert haben.*
Für Systemadministratoren existieren nslookup(1) und dig(1). ;-)
> Was mich an den systemd-Leuten hauptsächlich ankotzt, ist nichtmal deren> Software, sondern schlicht deren Selbstverständnis. "Wir lösen Probleme> und ihr müsst entweder exakt unseren Weg gehen oder sie selbst lösen.> Aber wir sorgen dafür, dass unsere Lösung alternativlos bleibt."
Aber es gibt doch Alternativen: Guix setzt auf den GNU Shepherd, Alpine
und Gentoo setzen auf OpenRC. Systemd ist nur dann alternativlos, wenn
man ausgerechnet eine jener Major-Distributionen benutzen will, die sich
für systemd entschieden haben.
Im Endeffekt setzt sich Dein Vorwurf aus zwei Vorwürfen zusammen: daß
systemd die Ziele Integration, Konsistenz und Standardisierung verfolgt
(und IMHO auch erreicht), daß die systemd-Entwickler nicht schon von
vorneherein die Möglichkeit vorgesehen haben, systemd vollständig oder
teilweise wieder zu entfernen, und daß die großen Distributoren sich
ausnahmslos für systemd entschieden haben.
Entschuldige bitte, aber systemd ist nicht vom Himmel gefallen, und zu
Beginn war nicht einmal RedHat sonderlich scharf darauf. Die
Debian-Leute sind ohnehin skeptisch gegenüber allem, was von RedHat
kommt, und Ubuntu hatte bereits einiges an Gehirnschmalz, Zeit, Arbeit,
und Geld in seine Eigenentwicklung Upstart investiert. Und trotzdem
haben sich alle diese Leute aus freien Stücken, zweifellos aus guten
Gründen und wider alle Kritik zu der Entscheidung für systemd
durchgerungen.
Tut mir leid, liebe systemd-Kritiker, vielleicht wart Ihr zu wenige oder
zu leise, habt nicht genügend sachliche Argumente gehabt oder sie nicht
treffend genug auf den Punkt gebracht, sie nicht bei den richtigen
Leuten oder nicht bei den passenden Gelegenheiten vorgetragen. Jetzt ist
diese Sache gegessen, systemd ist da, und, sorry, aber die Diskussionen
über dessen Für und Wider sind verschwendete Zeit, Energie, und Nerven.
Ihr habt jetzt noch genau zwei Chancen, Euch konstruktiv zu verhalten:
die erste ist, genug Leute von einem Wechsel auf Distributionen ohne
systemd zu überzeugen (was ich persönlich für aussichtslos halte), oder
Euch an der Weiterentwicklung zu beteiligen und die Dinge, die Euch am
meisten stören, durch bessere und überzeugendere Lösungen zu ersetzen.
> Es gab einen durchaus hörenswerten CRE mit Poettering, wo er mal über> Avahi, Pulseaudio und Systemd frei erzählt. Und ich finde z.B. eine> massive Diskrepanz zwischen seiner Beschreibung von Pulseaudio und der> Realität.
Dazu kann ich leider nichts sagen, da mir die Aussagen von Lennart und
auch die von Dir wahrgenommenen Diskrepanzen unbekannt sind.
> Es ist irgendwo bezeichnend, dass Poettering selbst> - nicht nennenswert Server administriert> - nur aktuelle Snapshots seiner Software verwendet.
Die meisten Kernel-, Libc- und sonstigen Entwickler administrieren keine
größeren Netzwerke, und die meisten dürften die aktuellsten Versionen
ihrer eigenen Software benutzen. Was genau ist der Punkt?
> Sheeva P. schrieb:>> Devuan zeigt außerdem, daß man es wieder loswerden kann.>> Es zeigt eher das Gegenteil. Eben weil Vendor-Lockin.
Von welchem Vendor denn? Und was für ein Lock-In? Ein Vendor-Lock-In
ist, wenn die Software des Herstellers meine eigenen Daten in
undokumentierte, proprietäre Formate einsperrt, aus denen ich sie nur
mit hohen Kosten und Aufwänden wieder herausbekommen kann. Ein Lock-In
besteht also darin, die Hürden für den Umstieg auf andere Software
künstlich zu erhöhen, so daß es für den Kunden ökonomischer ist,
weiterhin die in solchen Fällen meistens überhöhten Lizenz- und
sonstigen Kosten der vorhandenen Software weiterhin zu bezahlen. Damit
ist ein Vendor-Lock-In ein ökonomisches Druckmittel zur Kundenbindung
durch, letztlich, eine Nötigung.
Stattdessen ist systemd OpenSource, benutzt keine undokumentierten oder
proprietären Formate oder Protokolle, und wer einmal systemd benutzt
hat, kann jederzeit und vollkommen schmerzfrei zu einer Distribution
ohne systemd wechseln. Ich kann da keinen einzigen Aspekt eines
klassischen Vendor-Lock-In erkennen, sorry. Dieser Vorwurf ist so
sinnvoll wie die Klage, daß Linux-Systeme einen Linux-Kernel benutzen --
versuch' doch einmal, den loszuwerden... ;-)
Sheeva P. schrieb:>> Was mich an den systemd-Leuten hauptsächlich ankotzt, ist nichtmal deren>> Software, sondern schlicht deren Selbstverständnis. "Wir lösen Probleme>> und ihr müsst entweder exakt unseren Weg gehen oder sie selbst lösen.>> Aber wir sorgen dafür, dass unsere Lösung alternativlos bleibt.">> Aber es gibt doch Alternativen: Guix setzt auf den GNU Shepherd, Alpine> und Gentoo setzen auf OpenRC. Systemd ist nur dann alternativlos, wenn> man ausgerechnet eine jener Major-Distributionen benutzen will, die sich> für systemd entschieden haben.
Alle Distributionen bieten mehr oder weniger die Gleichen Anwendungen an
(apache, bind, etc.).
Diese haben die selben Quellen. Wenn eine dieser Anwendungen nun Systemd
voraussetzt, z.B. durch die Verwendung von sd-bus, dann ist dass auch
für BSD und nicht-Systemd Systeme ein Problem. Diese können nämlich
nicht einfach aufhören, ihre Software Pakete zu aktualisieren, nur weil
diese nun von Systemd abhängig geworden sind. Deshalb macht es auch
Sinn, dass z.B. Devuan die Packete von Debian Jessie, und nicht von
Debian Wheezy übernimmt.
> Im Endeffekt setzt sich Dein Vorwurf aus zwei Vorwürfen zusammen: daß> systemd die Ziele Integration, Konsistenz und Standardisierung verfolgt> (und IMHO auch erreicht), daß die systemd-Entwickler nicht schon von> vorneherein die Möglichkeit vorgesehen haben, systemd vollständig oder> teilweise wieder zu entfernen, und daß die großen Distributoren sich> ausnahmslos für systemd entschieden haben.
Ich habe nichts gegen Integration, Konsistenz und Standardisierung, ganz
im Gegenteil, aber abgesehen vom UI und den Unit files hat Systemd ja
wohl nichts standardisiert, und die Technische Umsetzung ist einfach
kaputt. Mein Vorwurf ist dabei nicht, dass Sie keine Möglichkeit
vorgesehen haben, systemd vollständig oder teilweise wieder zu
entfernen, sondern dass es absichtlich so geschrieben wurde, dass man es
und seine Komponenten nicht einfach durch andere Ersetzen kann. Das ist
einfach nur schlechtes Softwarearchitekturdesign.
Dir scheint offenbar nicht klar zu sein, dass Integration und
Entkopplung sich nicht ausschliessen, im Gegenteil. Eine Komponente ist
gut Entkoppelt, wenn diese wenige Abhängigkeiten hat und einfach zu
Ersetzen ist. Die Integration ist gut, wenn Komponente A mit Komponente
B kommunizieren kann, und eventuell umgekehrt. Dabei müssen Komponente A
und Komponente B nicht voneinander abhängig sein. Um dass zu
verdeutlichen, veranschauliche ich zunächst diverse Architekturen, und
was gutes Software Design ausmacht und was nicht:
Die Systemd lösung:
1
|--------------| z.B. Direkte Vorausgesetzte |--------------|
2
| Komponente A | Unstandardisierte Funktionsaufrufe: | Komponente B |
Beide Anwendungen greifen unkontrolliert aufeinander zu, es wird kein
wert darauf gelegt
eine ersetzen zu können, die ständig ändernde unversionierte API der
Komponenten verhindern
das Entfernen oder Ersetzen einzelner Komponenten => Kaputtes Software
Design.
Wie man soetwas Schön lösen könnte:
1
|--------------| Standardisierte minimale API |--------------|
2
| Komponente A | mit Versionierung: | Komponente B |
Beide Komponenten erfüllen noch die selben Aufgaben und sind genauso gut
aufeinander abgestimmt.
Aber hier kann Komponente B und problemlos Komponente A ersetzt werden.
Eine festgelegte API sichert
die Kompatiblität von Komponente B zu einer beliebigen Implementation
von Komponente A.
Callback Funktionen entkoppeln Komponente B von Komponente A. Komponente
A benötigt nur eine Komponente B, welche die API bereitstellt.
Komponente B benötigt Komponente A nicht. => Gutes Design
Eine andere Variante, falls beide Komponenten stärker interagieren
müssen:
Komponente A und Komponente B sind nicht voneinander abhängig. Diese
benötigen nur einen Dienst, der die Funktionalität der anderen
Komponente bietet. Die Nachrichten zur Ansteuerung der Funktionalität
welche beide Komponenten Anbieten, und die Nachrichten welche diese
Senden um andere Dienste über neue Events zu Informieren wurden z.B. mit
einem Protokoll standardisiert. => Gutes Design
Die Systemd Variante:
1
Neue APIs speziell für Komponente A, nicht standardisierte Protokolle, Portabilität egal
2
↓
3
|--------------| |-----------| |--------------|
4
| Komponente A | ---> | IPC Diest | <--- | Komponente B |
5
| | <--- | | |--------------|
6
|--------------| ^ | |
7
| | | |--------------|
8
| | | <--- | Komponente C |
9
| | | |--------------|
10
| |-----------|
11
|
12
Unnötige Abhängigkeit ohne Nutzen & nicht standardisierte Protokolle
Komponente A hängt von Komponente B ab, weil der IPC Dienst (=sd-bus)
unnötiger weise von Komponente A (=libsystemd0) abhängt. Komponente B
hat nichts mit Komponente A Zutun und will eigentlich nur über den IPC
Dienst mit Komponente C reden. Komponente C ist ebenfalls von Komponente
A Abhängig, genauso grundlos. => Schlechtes Software Design
Ich könnte das hier noch eine weile Weiterführen, aber ich hoffe du
erkennst langsam, was dazu führt dass alle Anwendungen von Systemd
abhängig macht. Sämtliche Anwendungen die sd-bus statt dem Portablen
dbus, logind statt dem portablen libpam, etc. verwenden. Es gibt eine
minimal nettere API, der Umstieg von sd-bus nach dbus ist Minimal, aber
hat man das mal eingebaut, ist es schwierig sd-bus wieder mit dbus zu
ersetzen. Deshalb rede ich von Vendor-LockIn. Die Vendoren sind Systemd
Entwickler/Systeme und Lennart. Das Produkt von welchem man abhängig
wird ist Systemd. Das man davon abhängig geworden ist bemerkt man selbst
zunächst gar nicht, weil Systemd ja bereits installiert ist. Die gleiche
Funktionalität, Vereinheitlichung & Integration würde sich problemlos
ohne diese Abhängigkeiten zu Systemd erreichen lassen.
Und nun überlege dir, was Systemd bereits alles übernommen hat. Sobald
eine Anwendung eine andere Benötigt, die Systemd benötigt, braucht man
Systemd. Und Systemd hat die meisten core-services übernommen!
------------------------------------------------------------------------
> Daniel A. schrieb:>> Einer Anwendung ist es völlig egal, ob jetzt journald, rsyslog oder>> syslog verwendet wird.>> Nein -- weder der Anwendung selbst, noch dem Systemadministrator und dem> Entwickler.
Doch. Die API ist Simpel, Standardisiert und hat eine man Page:
https://linux.die.net/man/3/openlog
Egal ob syslog, rsyslog oder journald, die Anwendung ruft die selbe
Funktion auf.
> Dank systemd kann man heute einfach auf std{out,err} loggen,> und journald kümmert sich um den Rest. Dazu waren früher entweder eine> Anbindung an r?syslogd oder fiese Hacks nötig.
Einfach nur nach std{out,err} zu loggen ist besonders bei grossen
Anwendungen eine schlechte Idee. Dabei kann man nämlich keinen Log Level
angeben, und ich kann mit dem Logging Service die z.B. INFOs beim loggen
nicht weglassen. Man konnte mit logger schon immer per stdout loggen,
Ausserdem ist eine simple Pipe nach logger ja wohl kein fieser Hack.
Pipes sind die wohl beste und Mächtigste Erfindung aus der Unix Welt.
>> So gross sind die Unterschiede auch wieder nicht. Eventuell sind einige>> Config Files woanders, oder ein Bug wurde anders gefixt, aber dass wars>> dann auch schon.>> Ich sag' nur start-stop-daemon (Debian) versus das RedHat-Zeug.
Das sind doch nur ein paar Programme um das etwas zu vereinfachen.
> Um auf die oben bereits erwähnten Initskripte für Wildfly zurück zu kommen: es> gibt gute Gründe, warum die Wildfly-Entwickler für beide Distributionen> je ein eigenes, mit je 208 und 298 Zeilen auch recht umfangreiche> Startskripte pflegen, deren unterschiedlicher Umfang ein deutlicher> Hinweis darauf ist, wie groß die Unterschiede tatsächlich sind.
So ein paar Hilfsscripte sind ja wohl nichts weltbewegendes. Die
Programme stammen meistens von den selben quellen, haben die selben
Argumente, etc. Ich meine, schön, dann hat RedHat eben deamon statt
start-stop-daemon, dann gibt es beim Debian Script bei dem Programm eben
noch ein par mehr Dinge die erst kontrolliert werden. Das könnte man
alles natürlich viel kürzer schreiben, aber im Vergleich zu der
Anwendung gibt so ein Skript doch keine Arbeit.
> Nur zum Vergleich: die Dateien für systemd haben einen Umfang von gerade einmal> 27 Zeilen.
Wenn das wirklich mal jemanden gestört hätte hätte eben jemand ein
Programm oder Skript geschrieben, dass man statt #!/bin/sh angibt, und
einfach das Kommando und Pidfile einlist und den rest erledigt. Dann
hätte man vermutlich sogar weniger als 27 Zeilen benötigt. Man könnte
natürlich auch upstart nehmen und selbst ein Skript schreiben, dürfte
ebenfalls relativ kurz werden. Insgesamt schreibt man init Scripte aber
einfach nicht besonders oft, warum sollte das also überhaupt relevant
sein?
>> Für mich sieht es eher so aus, als würde die frühere wunderschöne>> Harmonie und Diversität durch ein einheitliches Monolithisches Chaos mit>> nettem UI ersetzt.>> Schau' doch bitte einfach mal in die erwähnten Startskripte von Wildfly> und verrate mir, wo Du da Harmonie entdeckst, gar eine wunderschöne. Mir> sich diese Schönheit leider nicht erschließen.
Für eine Harmonie benötigt man eine Komposition, also mehrere Services
die miteinander harmonieren können. Das hat nichts mit dem Format der
Init Scripte Zutun, sondern damit, wie die eigentlichen Programme welche
damit gestartet wurden sich gegenseitig Ergänzen, ohne einander in die
Quere zu kommen oder ineinander verknotet zu sein. Etwas Schönes haben
aber selbst die SysvInit Scripte: Sie starten das System deterministisch
und sind Shell Scripte, jeder Unix User sollte mit einer Shell umgehen
können.
>> Ganz zu schweigen davon, das es den korrekten Weg garnicht gibt, weil>> jeder wieder andere Anforderungen haben kann.>> Genau, und die Flexibilität, die diese unterschiedlichen Anforderungen> notwendig machen, ist der Grund für einen wesentlichen Teil ebenjener> Komplexität, die Du systemd jetzt vorwirfst.
Ich werfe Systemd keine Komplexität vor, ich werfe ihm vor Architektur
mässig schlecht Implementiert zu sein. Ausserdem drücke ich hier aus,
dass ein Programm niemals flexibel genug für alle möglichen Anwendungen
sein kann. Es wird also niemals flexibel genug sein, um jede Anforderung
abzudecken. Tatsächlich kann man sich ein beliebiges in Systemd
hart-codiertes Feature aussuchen, und sich einen Fall vorstellen, in
welchem man es deaktivieren oder ändern müsste. Da habe ich es dann
lieber, wenn ich ein Programm aussuchen kann welches sich bereits
ungefähr auf meinen Anwendungsbereich spezialisiert hat, statt an einer
generischen Lösung herumdoktern zu müssen.
>> Das ist wahr. Aber diese Distributionen haben es nicht einfach.>> Distributionen, die etwas anders machen wollen als der Mainstream,> hatten es noch nie einfach. Ich wüßte nicht, warum ausgerechnet systemd> etwas an diesem Umstand ändern sollte.
Na weil Systemd das erste Programm ist, von dem alle anderen Programme
abhängig wurden.
Sheeva P. schrieb:>>>> Debian Derivete hatten keine andere wahl mehr, als zu Systemd zu>>>> wechseln.>>>>>> Devuan existiert und ist der beste Beweis dafür, daß das nicht stimmt.>>>> Nein, es ist ein Beweis dafür, wie schwierig das ist.>> Entschuldige, aber das ist einerseits die Folge der Designentscheidung,> erst ein systemd-basiertes Debian zu nehmen und dann systemd aufwändig> wieder auszubauen.
Es macht keinen Unterschied, auf welcher Sie es aufgebaut hätten. Sie
hätten die Pakete so oder so aktualisieren müssen, und die Sourcen
dieser hätten das trotzdem Systemd vorausgesetzt.
> Andererseits hat es, wenn ich mich recht entsinne,> Linux-Systeme vor systemd gegeben, und tatsächlich gibt es sogar heute> noch welche. Es ist also offensichtlich so, daß man Linux-Systeme auch> ohne systemd booten und betreiben kann.
Diese Systeme unterscheiden sich aber stark von gewöhnlichen Systemen.
Dies umfasst NAS Systeme, die auf BusyBox aufbauen, Dinge wie rancher
os, die ihr eigenes init system machen und alles Virtualisieren,
inklusive udev, und andere exotische Distros.
> Wir als Nutzer haben jetzt die Wahl: entweder, wir freunden uns damit an> und bleiben bei den Major-Distributionen, oder wir tun es eben nicht und> suchen uns was anderes. Das Argument, daß man systemd nicht "wieder los"> würde, lasse ich dabei allerdings nicht gelten: das ist nämlich IMHO ein> künstliches Argument von Menschen, die systemd aus ganz anderen Gründen> los werden wollen, allen anderen stellt sich dieses Problem nämlich gar> nicht erst.
Nein, dass ist ein künstliches Argument, dass man überall anführen
könnte. Beispiel: Jeder Mensch auf der Erde gibt mir 1 Fr pro Tag. Was,
das willst du nicht? Dass lasse ich jetzt aber nicht gelten, alle
anderen die Zahlen finden dass ja auch OK.
Wenn es nicht jeder verwenden will, sollte es auch nicht jeder verwenden
müssen. Es ist schon aufwendig genug von den Grossen Firmen unabhängig
zu bleiben, jetzt muss ich auch die Open Source wellt retten.
> Über diese anderen -- und nach meiner Wahrnehmung auch nicht> immer sachlichen oder technischen -- Gründe können wir zwar diskutieren.> Ich fürchte nur, daß das nichts nutzt: die Majors haben ihre> Entscheidung getroffen, der Drops ist gelutscht, und solange die User> nicht in höheren Anzahlen mit den Füßen abstimmen und sich andere> Distributionen suchen, werden die Majors an dieser Entscheidung> festhalten.
Irgendwann werden sie schon untergehen, und wenn es soweit ist, werde
ich da sein.
> S. R. schrieb:>> Sheeva P. schrieb:>>> Es ist also offensichtlich so, daß man Linux-Systeme auch>>> ohne systemd booten und betreiben kann.>>>> Das ist offensichtlich. Außer, du willst Dinge tun, die er so nicht>> vorgesehen hat. Zum Beispiel /usr nachträglich mounten>> Dazu kann man sicherlich btrfs und / oder unionfs verwenden.
Dass führt dann aber zu ziemlichen Schweinereien. Updates würden eine
echte Tortur.
>> Freut einen übrigens, wenn man merkt, dass z.B. xfce unter FreeBSD nur>> eingeschränkt tauglich ist, weil das zugrundeliegende Gnome vollständig>> auf logind aufsetzt und Alternativen nicht unterstützt werden.>> Interoperabilität eingeschränkt.>> Aus meiner Perspektive ist das aber kein Problem von systemd, sondern> von Gnome bzw. XFCE. Das als Kritikpunkt an systemd aufzuführen, geht> IMHO am eigentlichen Ziel vorbei.
Es ist von Systemd abhängig geworden, genau darum geht es hier doch die
Ganze zeit. Und dass soetwas passiert ist durchaus auf den Aufbau und
die Politik von Systemd zurückzuführen.
>> Sheeva P. schrieb:>>> Entschuldige, aber ein Netzwerk-Setup ohne DNS ist kein Argument,>>> sondern einfach nur sinnlos.>>>> Ein Netzwerk-Setup ohne DNS ist schlicht kaputt. *Und das will ich als>> Systemadministrator auch wissen und nicht durch einen externen Fallback>> verschleiert haben.*>> Für Systemadministratoren existieren nslookup(1) und dig(1). ;-)
Hilft nicht viel, wenn der DNS Server mal ausfällt merkt man davon erst
mal nichts, und um das Testen geht es auch gar nicht. Es geht darum, das
mein Server nur tun soll, was ich von ihm will und nicht mehr. Wenn ich
etwas kaputt konfiguriere dann soll es gefälligst auch kaputt sein. Wenn
ich den Befehl zum Sprengen meines PCs gebe, dann soll er auch in die
Luft fliegen. Dass ist Kontrolle.
Sheeva P. schrieb:>> Es ist irgendwo bezeichnend, dass Poettering selbst>> - nicht nennenswert Server administriert>> - nur aktuelle Snapshots seiner Software verwendet.>> Die meisten Kernel-, Libc- und sonstigen Entwickler administrieren keine> größeren Netzwerke, und die meisten dürften die aktuellsten Versionen> ihrer eigenen Software benutzen. Was genau ist der Punkt?
Eventuell sich mit einem simplen Bugfix nicht gleich 10 Breaking Changes
mit zu updaten?
Sheeva P. schrieb:>> Sheeva P. schrieb:>>> Devuan zeigt außerdem, daß man es wieder loswerden kann.>>>> Es zeigt eher das Gegenteil. Eben weil Vendor-Lockin.>> Von welchem Vendor denn? Und was für ein Lock-In? Ein Vendor-Lock-In> ist, wenn die Software des Herstellers meine eigenen Daten in> undokumentierte, proprietäre Formate einsperrt, aus denen ich sie nur> mit hohen Kosten und Aufwänden wieder herausbekommen kann. Ein Lock-In> besteht also darin, die Hürden für den Umstieg auf andere Software> künstlich zu erhöhen, so daß es für den Kunden ökonomischer ist,> weiterhin die in solchen Fällen meistens überhöhten Lizenz- und> sonstigen Kosten der vorhandenen Software weiterhin zu bezahlen. Damit> ist ein Vendor-Lock-In ein ökonomisches Druckmittel zur Kundenbindung> durch, letztlich, eine Nötigung.
Du sagst es doch selbst:
> Ein Lock-In> besteht also darin, die Hürden für den Umstieg auf andere Software> künstlich zu erhöhen
Das muss seitens des Herstellers (Lennart) nicht unbedingt Finanziell
motiviert sein, auch eine stärkere Marktposition/Verbreitung kann
gewünscht sein. Auch muss es nicht immer ein Proprietäres Format sein,
spezielle Hardware, Patente, Lokale Wärungen oder Punktesysteme, wie man
den anderen den Umstieg erschwert oder Wovon ist unerheblich. Die
entscheidende Charakteristik ist, dass der Einstieg (übernehmen von
Systemd) einfach, und der Ausstieg und Umstieg (für Distributoren)
schwer ist.
> Stattdessen ist systemd OpenSource, benutzt keine undokumentierten oder> proprietären Formate oder Protokolle, und wer einmal systemd benutzt> hat, kann jederzeit und vollkommen schmerzfrei zu einer Distribution> ohne systemd wechseln.
Sofern die Distributoren den entstehenden Aufwand durch Systemd managen
und die neuen Benutzer das Überleben der Distribution sicherstellen
können. Das sind die versteckten Kosten, wenn es die User nicht
schmerzhaft entfernen, kann es niemand von der Distribution entfernen.
> Ich kann da keinen einzigen Aspekt eines> klassischen Vendor-Lock-In erkennen, sorry. Dieser Vorwurf ist so> sinnvoll wie die Klage, daß Linux-Systeme einen Linux-Kernel benutzen --> versuch' doch einmal, den loszuwerden... ;-)
Das sollte mit BSD durchaus machbar sein. Einerseits liefern die
Distributionen den Quellcode der Pakete mit, also könnte man diese für
BSD kompilieren, und andererseits gibt es einen Kompatibilitätsmodus für
Linux elf Binaries.
Daniel A. schrieb:> Alle Distributionen bieten mehr oder weniger die Gleichen Anwendungen an> (apache, bind, etc.).> Diese haben die selben Quellen. Wenn eine dieser Anwendungen nun Systemd> voraussetzt, z.B. durch die Verwendung von sd-bus, dann ist dass auch> für BSD und nicht-Systemd Systeme ein Problem. Diese können nämlich> nicht einfach aufhören, ihre Software Pakete zu aktualisieren, nur weil> diese nun von Systemd abhängig geworden sind. Deshalb macht es auch> Sinn, dass z.B. Devuan die Packete von Debian Jessie, und nicht von> Debian Wheezy übernimmt.
Im Prinzip ist die Sache ganz einfach: eine Anwendung wird noch nicht
von systemd abhängig, nur weil sie von systemd verwaltet wird. Eine
Anwendung wird nur und ausschließlich nur dann von systemd abhängig,
wenn sie die Libraries nutzt, die systemd bereitstellt. Diese Libraries
zu nutzen, ist allerdings eine bewußte Entscheidung der Entwickler
dieser Anwendung.
Andererseits nutzen die Entwickler einer Anwendung die Schnittstellen
aus den systemd-Libraries natürlich ausschließlich dann, wenn sie sich
davon etwas versprechen. Die meisten Entwickler von langfristig
erfolgreichen Projekten wie Gnome oder XFCE haben Erfahrung mit
sensiblen Entscheidungen hinsichtlich der Architektur und des Designs
ihrer Software -- anders kann man nämlich keine komplexen, über längere
Zeiträume erfolgreiche Software entwickeln -- und sind sich der
Konsequenzen ihrer Entscheidungen durchaus bewußt. Wenn diese Entwickler
sich nun dazu entschließen, die Libraries von systemd zu benutzen und
ihre Software somit von den systemd-Libraries abhängig zu machen, dann
werden sie dafür sicher gute Gründe haben, zum Beispiel eine verbesserte
Funktionalität, Stabilität, Systemintegration oder andere von ihnen
gewünschte Ziele.
Genau dasselbe gilt für die Distributoren: wenn diese sich entscheiden,
SysV-Init durch eine andere Lösung wie systemd zu ersetzen, dann haben
sie zweifellos ebenfalls ihre guten Gründe dafür -- im Falle von Debian
gibt es dazu sogar ein Dokument im Netz, das diese Gründe ausführlich
erklärt. Anders als Du halten die Entscheider der Major-Distributionen
und auch von Debian systemd offensichtlich für das bessere, wenn nicht
sogar für das beste und reifeste im Moment verfügbare Init-System --
ansonsten hätten sie diese Entscheidung sicherlich nicht getroffen.
Wie dem auch sei: wenn Entwickler und Distributoren für ihre Anwendungen
und Distributionen auf systemd setzen, dann ist das ganz alleine deren
freie Entscheidung. Wenn Du daran etwas kritisieren möchtest, dann wende
Dich bitte an diejenigen, die diese Entscheidungen getroffen haben. Die
Entwickler von systemd, sowie systemd selbst sind dabei, übrigens ebenso
wie ich, der falsche Adressat.
So war und ist es auch schon bei Deinem Rant über systemd gewesen, als
die Entwickler und / oder die Debian-Maintainer kaputte Unitfiles für
OpenDKIM und Postfix ausgeliefert haben. Es liegt nicht in der
Verantwortung von systemd oder seiner Entwickler, wenn jemand kaputte
Unitfiles für seine Anwendung ausliefert. Das ist einzig und alleine die
Schuld dessen, der die kaputten Unitfiles ausgeliefert hat!
Am Ende ist und bleibt es so, daß ich systemd mag. Für meine Software
und meine Systeme funktioniert es wunderbar, vereinfacht und
vereinheitlicht den Bootprozeß an vielen Stellen, und macht ihn in den
übrigen Bereichen jedenfalls nicht komplizierter. Es löst viele Probleme
und Aufgaben, die bisher von unzusammenhängenden Subsystemen erledigt
worden sind, zentral, konsistent, und umfassend. Natürlich muß systemd
nicht gut finden, keine Frage. Aber ich kann es, ich tue es, und daß ich
mich dabei in der guten Gesellschaft von anderen erfahrenen Entwicklern
und Distributoren befinde, läßt mich vermuten, daß ich damit wohl nicht
völlig daneben liege.
Sheeva P. schrieb:> Sorry, ich sehe da durchaus Bezugspunkte zwischen systemd,> logind, journald, und den anderen systemd-Komponenten
Ich sehe auch Bezugspunkte zwischen Webanwendungen und MySQL. Dennoch
bin ich strikt dagegen, MySQL als zwingende Voraussetzung für
Webanwendungen zu sehen. Gleiches gilt für logind und systemd auch.
Sheeva P. schrieb:>> Das ist offensichtlich. Außer, du willst Dinge tun, die er so nicht>> vorgesehen hat. Zum Beispiel /usr nachträglich mounten> Dazu kann man sicherlich btrfs und / oder unionfs verwenden.
Nein, kann man nicht, weil Lennart der Meinung ist, man müsse das nicht
unterstützen und daher einen /usr-Eintrag in der /etc/fstab absichtlich
ignoriert. EWONTFIX.
Sheeva P. schrieb:> Im Prinzip ist die Sache ganz einfach: eine Anwendung wird noch nicht> von systemd abhängig, nur weil sie von systemd verwaltet wird. Eine> Anwendung wird nur und ausschließlich nur dann von systemd abhängig,> wenn sie die Libraries nutzt, die systemd bereitstellt.
So. Danach jetzt stellst du fest, dass diese Library nicht funktioniert,
wenn du nicht auch systemd als Init-System nutzt, obwohl diese Library
garnicht zwingend vom Init-System abhängt. Besser noch, ihre
Benutzerschnittstelle ist sogar so entworfen, dass du sie nicht einmal
einfach auf einer anderen Basis nachprogrammieren kannst.
Schon eine einzelne Anwendung mit systemd-Integration zwingt mich dazu,
mein gesamtes System auf systemd umzustellen.
Sheeva P. schrieb:>> Ein Netzwerk-Setup ohne DNS ist schlicht kaputt. *Und das will ich als>> Systemadministrator auch wissen und nicht durch einen externen Fallback>> verschleiert haben.*>> Für Systemadministratoren existieren nslookup(1) und dig(1). ;-)
Willst du mich absichtlich missverstehen?
Sheeva P. schrieb:> Also ist der eigentliche Vorwurf der hohe Integrationsgrad?
Willst du mich absichtlich missverstehen?
Ich bin nicht dagegen, dass die systemd-Tools mit systemd gut
zusammenarbeiten. Ich bin dagegen, dass man keinen Teil von systemd ohne
das Gesamtpaket benutzen kann!
Microsoft hat für ähnliches Verhalten übrigens mal furchtbar von der EU
aufs Maul bekommen und aus irgendeinem Grund bin bin ich mir sicher,
dass du da nicht auf Microsofts Seite standest...
Sheeva P. schrieb:> Von welchem Vendor denn? Und was für ein Lock-In? Ein Vendor-Lock-In> ist, wenn die Software des Herstellers meine eigenen Daten in> undokumentierte, proprietäre Formate einsperrt, aus denen ich sie nur> mit hohen Kosten und Aufwänden wieder herausbekommen kann.
Vendor-Lock-In hat nichts mit undokumentierten und proprietären Formaten
zu tun, Android ist z.B. auch Open Source. Was die systemd-Entwickler
hingegen tun, ist die Kosten für die Nichtbenutzung von systemd
absichtlich zu steigern - und dich damit in ihre Welt einzusperren.
Auch ein guter Diktator ist ein Diktator. Und Lennart ist zu allem
Überfluss auch noch ein gut-gemeinter Diktator.
Sheeva P. schrieb:> und wer einmal systemd benutzt hat, kann jederzeit und vollkommen> schmerzfrei zu einer Distribution ohne systemd wechseln.
Ich lachte einmal kurz und staune, dass deine Verblendung tatsächlich
auf dem Niveau typischer Applenutzer liegt. Ich hatte Linuxer generell
für vernünftiger gehalten.
S. R. schrieb:> Sheeva P. schrieb:>> Sorry, ich sehe da durchaus Bezugspunkte zwischen systemd,>> logind, journald, und den anderen systemd-Komponenten>> Ich sehe auch Bezugspunkte zwischen Webanwendungen und MySQL.
Ich nicht. Etliche Webseiten und -anwendungen kommen ohne MySQL aus.
Aber kein Linux-System kommt ohne Init- oder Logging-System aus.
> Sheeva P. schrieb:>>> Das ist offensichtlich. Außer, du willst Dinge tun, die er so nicht>>> vorgesehen hat. Zum Beispiel /usr nachträglich mounten>> Dazu kann man sicherlich btrfs und / oder unionfs verwenden.>> Nein, kann man nicht, weil Lennart der Meinung ist, man müsse das nicht> unterstützen und daher einen /usr-Eintrag in der /etc/fstab absichtlich> ignoriert.
Man kann Dateisysteme auch ohne Eintrag in der /etc/fstab mounten, zum
Beispiel über ein Unitfile, und dabei kann man problemlos ein unionfs
mit einem anderen Dateisystem über das zum Booten nötige /usr legen.
Ansonsten erklären die systemd-Entwickler hier [1] nicht nur die Gründe
für ihre Entscheidung, sondern zählen auch noch eine Reihe von Software
auf, die zum Booten eines Systems nötig sein kann, aber ohne /usr ganz
oder teilweise nicht funktioniert: "udev-pci-db/udev-usb-db and all
rules depending on this (using the PCI/USB database in /usr/share),
PulseAudio, NetworkManager, ModemManager, udisks, libatasmart,
usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS,
Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of
most programs and a lot of other stuff."
[1]
https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/> Besser noch, ihre> Benutzerschnittstelle ist sogar so entworfen, dass du sie nicht einmal> einfach auf einer anderen Basis nachprogrammieren kannst.
systemd und seine Libraries sind so entworfen, daß sie sauber
miteinander und mit etlichen anderen Systemkomponenten zusammenarbeiten.
Das tun sie. Alles andere sind Verschwörungstheorien und böswillige
Unterstellungen.
> Schon eine einzelne Anwendung mit systemd-Integration zwingt mich dazu,> mein gesamtes System auf systemd umzustellen.
Dann hast Du drei Möglichkeiten. Erstens kannst Du die Entwickler dieser
Anwendung bitten, die Integration mit systemd zu lösen. Zweitens kannst
Du Dir eine alternative Anwendung suchen. Und wenn Dir so viel an dieser
ganz speziellen Anwendung liegt, kannst Du natürlich systemd benutzen.
You can not eat the cake and have it.
> Sheeva P. schrieb:>> Also ist der eigentliche Vorwurf der hohe Integrationsgrad?>> Willst du mich absichtlich missverstehen?
Nein, aber wenn Du so etwas schreibst:
> Ich bin nicht dagegen, dass die systemd-Tools mit systemd gut> zusammenarbeiten. Ich bin dagegen, dass man keinen Teil von systemd ohne> das Gesamtpaket benutzen kann!
... dann ist Dein eigentlicher Vorwurf also der hohe Integrationsgrad,
und ich habe Dich vorher schon ziemlich gut verstanden. Daß systemd eben
nicht modular entworfen wurde und starke Abhängigkeiten voneinander hat,
ist der Preis für eine konsistente Lösung. Ein modularer Entwurf hätte
allerdings nicht nur dem Ziel von systemd nach Standardisierung und
Vereinheitlichung entgegen gestanden, sondern hätte systemd auch noch
viel komplizierter und aufwändiger gemacht, als es ohnehin schon ist.
Das hat auch nichts mit der oben unterstellten Verschwörungstheorie zu
tun, sondern ist ein ganz normales Vorgehen. Ich als Entwickler entwerfe
meine Software auch nicht mit dem primären Ziel, daß der Anwender Teile
davon durch eine andere Software ersetzt.
> Microsoft hat für ähnliches Verhalten übrigens mal furchtbar von der EU> aufs Maul bekommen und aus irgendeinem Grund bin bin ich mir sicher,> dass du da nicht auf Microsofts Seite standest...
Im Gegenteil: Microsoft hat was auf die Mütze bekommen, weil sie
Software, die eben nicht hochintegriert war und problemlos autark hätte
betrieben werden können, mißbräuchlich miteinander gebündlt hatte, um
Konkurrenten aus dem Markt zu drängen. Dabei ging es primär um den
Internet Explorer, von dem Microsoft gegenüber der EU behauptete, man
könne ihn nicht vom restlichen System trennen, worauf die Fachleute der
EU dann feststellten, daß mit Windows Mobile ein Windows-System ohne IE
möglich und der IE also offensichtlich nicht zwingender Bestandteil des
Systems war.
Im Übrigen finde ich es ehrlich gesagt unter aller Sau, systemd und
seine Entwickler mit Microsofts unlauteren Geschäftspraktiken in
Verbindung zu bringen oder sogar gleichzusetzen.
> Was die systemd-Entwickler> hingegen tun, ist die Kosten für die Nichtbenutzung von systemd> absichtlich zu steigern - und dich damit in ihre Welt einzusperren.> Auch ein guter Diktator ist ein Diktator. Und Lennart ist zu allem> Überfluss auch noch ein gut-gemeinter Diktator.
Ich habe keine Lust, über böswillige Unterstellungen und persönliche
Beleidigungen gegenüber OpenSource-Entwicklern zu diskutieren...
> Ich lachte einmal kurz und staune, dass deine Verblendung tatsächlich> auf dem Niveau typischer Applenutzer liegt. Ich hatte Linuxer generell> für vernünftiger gehalten.
...und ich habe auch keine Lust, mich als verblendet, unvernünftig, oder
als "typischen Applenutzer" verunglimpfen zu lassen. Guten Tag.
Sheeva P. schrieb:>> Ich bin nicht dagegen, dass die systemd-Tools mit systemd gut>> zusammenarbeiten. Ich bin dagegen, dass man keinen Teil von systemd ohne>> das Gesamtpaket benutzen kann!>> ... dann ist Dein eigentlicher Vorwurf also der hohe Integrationsgrad,> und ich habe Dich vorher schon ziemlich gut verstanden. Daß systemd eben> nicht modular entworfen wurde und starke Abhängigkeiten voneinander hat,> ist der Preis für eine konsistente Lösung.
Nein, das ist ganz einfach nur schlechtes Software Design. Ich habe in
meinem Beitrag oben ja schon aufgezeigt, wie man Komponenten entkoppelt,
ohne deren Funktionalität zu ändern. Systemd müsste nichts an seinem
Userinterface oder Konfigurationsdateien ändern um dies zu tun. Auch
wäre der Aufwand nicht grösser, im Gegenteil. Wenn man Software sauber
Aufbau, kann man die Komplexität, Fehleranfälligkeit, Wartbarkeit,
Testbarkeit und Integration der Implementierung enorm vereinfachen &
verbessern, ohne Kompromisse bei der Funktionalität eingehen zu müssen.
Wenn die Implementation übermässig Komplex wird, und unzusammenhängende
Aufgaben direkt verknüpft sind, dann ist die Software Architektur
eindeutig Schrott. Das ist nicht der Preis einer konsistenten Lösung,
das ist ein klares Zeichen das die Architektur nicht sauber aufgebaut,
oder sogar inkonsistent ist (was natürlich nicht heisst das das UI oder
die Configfiles inkonsistent wären oder angepasst werden müssten, diese
sind nicht direkt teil der internen Architektur). Das ist in etwa so,
wie mit einem Haus ohne Fundament (Architektur). Man sieht (UI) keinen
Unterschied zu einem mit Fundament (Architektur), bis es dann plötzlich
schräg Einsinkt, davon gewindet wird oder sonstwie kaputt geht. Lies dir
doch ein paar Bücher zu Softwarearchitektur best practice, Fehler beim
Software Design, SOA und Modularisierung durch.
> Ein modularer Entwurf hätte> allerdings nicht nur dem Ziel von systemd nach Standardisierung und> Vereinheitlichung entgegen gestanden, sondern hätte systemd auch noch> viel komplizierter und aufwändiger gemacht, als es ohnehin schon ist.
Ganz im Gegenteil:
* Es hätte mehr Standardisierung gegeben, weil neben dem Unit File
Format und dem UI auch die Schnittstellen und die Kommunikation zwischen
den Komponenten standardisiert gewesen wären.
* Es hätte an der Vereinheitlichung nichts geändert, reine Systemd
Systeme hätten weiterhin das selbe UI und die selben Formate benutzen
können. Jedoch hätte es die Wahlfreiheiten und Möglichkeiten der Nutzer
nicht eingeschränkt.
* Es hätte Systemd Architekturmässig einfacher gemacht, weil die
Schnittstellen und der Aufbau der Komponenten untereinander sauber
Definiert und weniger Komplex gemacht worden wäre, also gut geplant.
Gleichzeitig wäre auch die Bedienung nicht schwieriger geworden, weil
das UI und die Dateiformate ja nicht anders sein hätten müssen.
Also zusammenfassend: Es hätte nur Vorteile für die Entwickler gegeben
(Klarer Funktionsumfang, einfacher Weiterzuentwickeln, etc.), es hätte
nur Vorteile für die Benutzer gegeben (bessere Stabilität, mehr
Freiheiten, etc.), aber es hätten sich eben nicht alle so einfach
Zwangsumstellen lassen.
Sheeva P. schrieb:> Wie dem auch sei: wenn Entwickler und Distributoren für ihre Anwendungen> und Distributionen auf systemd setzen, dann ist das ganz alleine deren> freie Entscheidung. Wenn Du daran etwas kritisieren möchtest, dann wende> Dich bitte an diejenigen, die diese Entscheidungen getroffen haben. Die> Entwickler von systemd, sowie systemd selbst sind dabei, übrigens ebenso> wie ich, der falsche Adressat.
Die Systemd Entwickler sind für sehr wohl für die Architekturentscheide
verantwortlich, die dazu führen, das eine Systemd Komponente all die
anderen Systemd Komponenten mit hinein ziehen. Oder ist es Lennart's
schuld? Ausserdem, glaubst du wirklich die Entwickler prüfen jede
Abhängigkeit wenn diese nur den IPC Service wechseln, insbesondere wenn
auf ihrem System diese bereits installiert ist?
> So war und ist es auch schon bei Deinem Rant über systemd gewesen, als> die Entwickler und / oder die Debian-Maintainer kaputte Unitfiles für> OpenDKIM und Postfix ausgeliefert haben. Es liegt nicht in der> Verantwortung von systemd oder seiner Entwickler, wenn jemand kaputte> Unitfiles für seine Anwendung ausliefert. Das ist einzig und alleine die> Schuld dessen, der die kaputten Unitfiles ausgeliefert hat!
Ach ja stimmt, der Rant von damals:
Beitrag "[rant] SystemD, jetzt reichts!"
Schon klar, dass das nicht wirklich Systemd's schuld war, aber zu einem
Beliebigen anderen init-System zu wechseln hat mein Problem trotzdem
gelöst. Ausserdem habe ich mich dadurch anschliessend intensiv mit der
Thematik auseinandergesetzt, und sehr viel über Linux und init Systeme
gelernt.
Daniel A. schrieb:> Ganz im Gegenteil:> * Es hätte mehr Standardisierung gegeben, weil neben dem Unit File> Format und dem UI auch die Schnittstellen und die Kommunikation zwischen> den Komponenten standardisiert gewesen wären.
Ich bin mir vollkommen sicher, daß systemd früher oder später auch einen
Standardisierungs- und Modularisierungsprozeß durchlaufen wird -- wie es
schließlich ja auch der Linux-Kernel, der X-Server, der
Apache-Webserver, die PostgreSQL-Datenbank und andere im Laufe der Zeit
vorgemacht haben. Aber im Moment ging es erst einmal darum, eine
funktionierende, stabile, benutzbare und konsistente Software zu haben
-- und das ist systemd.
> * Es hätte an der Vereinheitlichung nichts geändert, reine Systemd> Systeme hätten weiterhin das selbe UI und die selben Formate benutzen> können. Jedoch hätte es die Wahlfreiheiten und Möglichkeiten der Nutzer> nicht eingeschränkt.
Wahlfreiheit hört sich ja erstmal gut an, ist aber das, was Linux dahin
gebracht hat, daß jeder Hansel seine eigenen "Standards" definiert hat.
Für Entwickler und Admins war das ein hoher Aufwand, vor allem wenn sie
auch noch mehrere Distributionen unterstützen wollten oder mußten. Dabei
spielt sicher auch eines der Kernkonzepte von OpenSource eine Rolle, der
Leitspruch "release early, release often" nach Eric S. Raymonds "The
cathedral and the bazaar".
> * Es hätte Systemd Architekturmässig einfacher gemacht, weil die> Schnittstellen und der Aufbau der Komponenten untereinander sauber> Definiert und weniger Komplex gemacht worden wäre, also gut geplant.
Das hätte zunächst einen enormen Aufwand bedeutet, noch bevor die erste
Zeile Software geschrieben worden wäre. Ich kenne wenige zuverlässigere
Wege, größere Softwareprojekte gleich von vorneherein zum Scheitern zu
verurteilen, als sie zu Tode zu spezifizieren.
Früher hat man meistens anhand von festen vorgegebenen Budgets mit fixen
Lasten- und Pflichtenheften entwickelt. Weil das eher schlecht als recht
funktioniert hat und mehr als die Hälfte aller Softwareprojekte nicht in
der Zeit, im Budget oder regelmäßig sogar gar nicht abgeschlossen
wurden, sind mittlerweile bessere Strategien wie die agile Entwicklung
etabliert, die mit veränderlichen Anforderungen besser umgehen können.
Das Problem: bei komplexer Software kannst Du nicht jeden noch so
kleinen Fitzel vorausplanen, so daß Du irgendwann vor der Wahl stehst,
entweder den Standard zu ändern -- was eben nicht im Sinne eines
Standards ist und bei jeder Änderung mindestens denselben Bohei
verursacht hätte wie jetzt systemd -- oder um die Unzulänglichkeiten des
Standards herum zu arbeiten. Insofern ging es bei systemd erst einmal um
eine konsistente Lösung aus einem Guß, und alles andere wird die Zeit
bringen.
Darüber hinaus ist es auch nur teilweise richtig, daß man systemd nur
entweder ganz oder gar nicht benutzen kann. Das uselessd-Projekt zeigt,
daß man systemd bereits jetzt auf die wesentlichen Kernkomponenten des
Init-Systems zusammenkürzen kann, wenn man das denn will.
> Die Systemd Entwickler sind für sehr wohl für die Architekturentscheide> verantwortlich, die dazu führen, das eine Systemd Komponente all die> anderen Systemd Komponenten mit hinein ziehen.
Natürlich -- und trotzdem hat systemd die Distributoren offensichtlich
so überzeugt, wie es nun einmal ist. Was glaubst Du, warum das so ist?
Weil die alle keine Ahnung von Softwaredesign und Architektur haben?
Weil die ihren Nutzern schaden oder sonstwas Böses wollen?
Und wenn systemd so schlecht designt wäre, wie Du sagst: warum äußern
sich dann ansonsten als meinungsstark bekannte Leute wie Linus Torvalds,
Alan Cox und Greg Kroah-Hartman nicht entsprechend, sondern übernehmen
immer wieder Patches der systemd-Entwickler in ihren Kernel? Sogar
Richard M. Stallman, der ansonsten um keinen Rant verlegen ist, wenn er
die Freiheit der Anwender in Gefahr sieht, hat nichts gegen systemd zu
sagen. Wie paßt das zu dem angeblichen "Vendor Lock-In"?
Sei mir bitte nicht böse, aber wenn systemd wirklich so furchtbar
schlimm, schlecht designt und böse wäre, wie Du und andere behaupten:
warum äußern sich die führenden Köpfe der Linux-Community denn nicht nur
nicht ähnlich ablehnend wie Du, sondern übernehmen systemd-Patches in
den Linux-Kernel und systemd in die großen Distributionen und andere
Software?
> Ausserdem, glaubst du wirklich die Entwickler prüfen jede> Abhängigkeit wenn diese nur den IPC Service wechseln, insbesondere wenn> auf ihrem System diese bereits installiert ist?
Ja. Wer größere Projekte entwickelt, der muß das machen, und zwar mit
großem Bedacht der möglichen Konsequenzen. Erfahrenen Entwicklern ist
beispielsweise ImageMagick noch in böser Erinnerung...
Sheeva P. schrieb:> Daniel A. schrieb:>> Ganz im Gegenteil:>> * Es hätte mehr Standardisierung gegeben, weil neben dem Unit File>> Format und dem UI auch die Schnittstellen und die Kommunikation zwischen>> den Komponenten standardisiert gewesen wären.>> Ich bin mir vollkommen sicher, daß systemd früher oder später auch einen> Standardisierungs- und Modularisierungsprozeß durchlaufen wird -- wie es> schließlich ja auch der Linux-Kernel, der X-Server, der> Apache-Webserver, die PostgreSQL-Datenbank und andere im Laufe der Zeit> vorgemacht haben. Aber im Moment ging es erst einmal darum, eine> funktionierende, stabile, benutzbare und konsistente Software zu haben> -- und das ist systemd.
Die starke Parallelisierung von Systemd macht dieses weniger
deterministisch, ich finde das widerspricht der Anforderung nach
Stabilität ein wenig.
Ansonsten kann ich nur hoffen, dass du damit richtig liegst dass sich
die Modularität & Standardisierung mit der zeit noch verbessert. Dazu
müsste Systemd aber auch einmal einen Stand erreichen können, in welchem
sagen kann dass man eine Vollständige Version hat. Im Moment kommen
hauptsächlich immer mehr Features und Möglichkeiten hinzu, so dass ich
im Moment keine Motivation bei den Entwicklern erkennen kann die nicht
funktionalen Aspekte von Systemd zu verbessern, abgesehen vielleicht von
"Optimierungen". Auch das Uselessd Projekt wurde deshalb ja bereits vor
Jahren aufgegeben. Die grösste gefahr sehe ich im Moment darin, dass die
schräge Architektur von Systemd nicht aufgeräumt wird, aber dennoch zu
einem Pseudostandard wird. Wenn dies passiert ist der Schaden nichtmehr
reparierbar.
Sheeva P. schrieb:> Wahlfreiheit hört sich ja erstmal gut an, ist aber das, was Linux dahin> gebracht hat, daß jeder Hansel seine eigenen "Standards" definiert hat.> Für Entwickler und Admins war das ein hoher Aufwand, vor allem wenn sie> auch noch mehrere Distributionen unterstützen wollten oder mußten.
Ich denke der teil hat sogar sehr gut funktioniert. Egal ob ich ssmtp,
exim, postfix oder sendmail nehme, ein sendmail Programm/Symlink liefern
sie alle. Egal ob ich syslog-ng, dsyslog, rsyslog, etc. nutze, logger
und die syslog Funktionen hab ich immer. Einen klar abgegrenzten Zweck,
der sich teils stark unterscheiden kann, haben die Programme auch alle.
Was sich unterscheidet sind also nur der Ort der Konfigurationsdateien,
kleine Distributionsspezifische Hilfsprogramme, die init scripte, die
Packetverwaltung und der Umfang/die Namen der verfügbaren Packete in
dieser. Ein Sysadmin muss in der Regel also nur den Paketnamen und das
Installationskommando, sowie den Ort der Konfigurationsdateien nachsehen
(welche meistens sowieso in /etc/packetname liegen). Die eigentliche
Konfiguration unterscheidet sich dann nichtmehr, selbes Programm =>
selbe Konfiguration. Die paar Kleinigkeiten bereiten jemandem mit etwas
Erfahrung doch keine Schwierigkeiten oder Mehraufwand.
Wenn man natürlich andere Programme verwendet, dann hat man natürlich
auch andere Konfigurationsformate. Wenn man dass macht aber beides mal
die selbe Aufgabe lösen muss, aber andere Programme verwendet, ist dass
einfach eine dumme Entscheidung. Wenn man mit den Programmen
unterschiedliche Dinge macht, muss man diese so oder so kennen, und
diese zu Vereinheitlichen oder eines davon auszuschliessen würde nicht
funktionieren. Die Programme die man verwendet wählt man doch sorgfältig
aus, und nimmt nicht einfach das erst beste.
Ausserdem, wenn ein Admin mit seinen Systemen/Programmen nicht
klarkommt, dann liegt das Problem doch beim Admin der noch nicht genug
Erfahrung mit dem System/Programmen für die er zuständig ist hat. In der
Informatik muss man immer viel lernen, und wer dazu zu faul ist hat
einfach den falschen job.
> Dabei spielt sicher auch eines der Kernkonzepte von OpenSource eine Rolle, der> Leitspruch "release early, release often" nach Eric S. Raymonds "The> cathedral and the bazaar".
Das sehe ich eigentlich nicht als ein Kernkonzept von OpenSource an. Der
entscheidende Punkt bei OpenSource ist doch, dass alle Mithelfen können
und die Quellen ansehen können. Wenn man sich grosse OpenSource Projekte
ansieht, sieht man häufig stabile releases, welche nur Bugfixes und
kleine Anpassungen bekommen, Testing releases mit teils auch neuen
Funktionen, und die momentane Entwicklungsversion. In der Regel
verlieren die Entwickler jedoch nicht aus den Augen, was die Software
eigentlich können soll, wozu sie da ist. Es werden nicht wahllos
Funktionen hinzugefügt, die keiner wirklich braucht. Deshalb
unterscheidet sich der Funktionsumfang ähnlicher Programme stark, weil
diese sich auf andere Teilprobleme spezialisieren. Dass ist aber eine
Gute Sache, denn es bedeutet, dass man sich ein Programm aussuchen kann
dass am ehesten auf seine Anforderungen passt. Stelle dir nur mal vor,
jemand würde versuchen die Konfiguration oder den Funktionsumfang von
Postfix, Exim und sendmail anzugleichen, das wäre absolut absurd.
Sicher, ich könnte z.B. mit dem Generischen exim das Versenden der Mails
in meinen LXC Containern, und das Empfangen/Senden von mails auf meinem
Mailserver lösen, aber warum sollte ich das tun, wenn ein
minimalistisches SSMTP in den Containern und ein Postfix auf den Servern
das Problem einfacher und besser löst?
Ich denke, insgesamt könnte man sagen, dass ich einfach den Vorteil von
generischen Lösungen gegenüber Lösungen die genau für mein Problem
konzipiert wurden nicht sehe. Bei der Generischen Lösung muss ich doch
mehr lernen, bis ich alle Funktionen kenne und die richtige gefunden
habe.
Und ganz abgesehen davon, Wahlfreiheit hört sich nicht nur gut an, es
ist gut. Beispiel: Ich mag keine Snickers aber ich mag Mars. Ich sollte
anderen das leben einfacher machen, und nurnoch Mars verkaufen.
Sheeva P. schrieb:>> * Es hätte Systemd Architekturmässig einfacher gemacht, weil die>> Schnittstellen und der Aufbau der Komponenten untereinander sauber>> Definiert und weniger Komplex gemacht worden wäre, also gut geplant.>> Das hätte zunächst einen enormen Aufwand bedeutet, noch bevor die erste> Zeile Software geschrieben worden wäre. Ich kenne wenige zuverlässigere> Wege, größere Softwareprojekte gleich von vorneherein zum Scheitern zu> verurteilen, als sie zu Tode zu spezifizieren.
Man muss es ja nicht übertreiben. Einige wenige Rahmenbedingungen und
Grundsätze am Anfang zu setzen reicht doch völlig aus. z.B. journald ist
fürs logging zuständig, wir Speichern die Daten mit dem bereits
vorhandenen Format Y und verwenden dazu die Library Y. Wir brauchen nur
Abhängigkeiten zu Komponenten Z und U, aber nicht zu libsystemd0. Schon
wäre die Sache gegessen, und ein Quasistandard würde sich ganz von
selbst entwickeln.
> Darüber hinaus ist es auch nur teilweise richtig, daß man systemd nur> entweder ganz oder gar nicht benutzen kann. Das uselessd-Projekt zeigt,> daß man systemd bereits jetzt auf die wesentlichen Kernkomponenten des> Init-Systems zusammenkürzen kann, wenn man das denn will.
Das uselessd-Projekt ist seit Jahren tot.
> Und wenn systemd so schlecht designt wäre, wie Du sagst: warum äußern> sich dann ansonsten als meinungsstark bekannte Leute wie Linus Torvalds,> Alan Cox und Greg Kroah-Hartman nicht entsprechend, sondern übernehmen> immer wieder Patches der systemd-Entwickler in ihren Kernel? Sogar> Richard M. Stallman, der ansonsten um keinen Rant verlegen ist, wenn er> die Freiheit der Anwender in Gefahr sieht, hat nichts gegen systemd zu> sagen.
Zunächst einmal würden die Änderungen in den Kernel nicht aufgenommen,
wenn diese für irgendwelche Nutzer einen Nachteil ergeben würden, oder
diese sonst wie unsinnig wären. Beispiel:
https://lkml.org/lkml/2014/4/2/420
Wenn Systemd Leute also Dinge in den Kernel einbauen, welche rein von
einem Kernel Standpunkt aus sinnvoll sind, dann kommt es da auch rein.
Wenn es um den Kernel geht gibt es keine bessere Ansprechperson als
Linus Torvalds, wenn es um den Userspace geht sieht die Sache jedoch
anders aus. Linus nutzt gängige Distributionen und freut sich über alle
Nutzer seines Kernels, sei das nun ein PC, ein Android Phone oder sonst
was. Ich habe den Eindruck, dass wenn es nicht um den Kernel geht er
sich generell gerne etwas zurück hält. Ausserdem sieht er Systemd als
eine Ursache für die weitere Verbreitung von Linux auf Laptops, also
gibt es keinen Grund warum er etwas gegen Systemd haben sollte.
Ich weiss nicht wirklich, was ich von Greg Kroah-Hartman halten soll.
Die Entwicklung von udev muss viel Zeit in Anspruch genommen haben,
vielleicht hat er es deshalb an Systemd abgegeben. Linus Torvalds hat
wie dessen Weiterentwicklung anfangs gehandhabt wurde übrigens nicht
unbedingt gefallen: https://lkml.org/lkml/2012/10/3/484 Nach allem was
ich gelesen habe scheint es so, als würde Greg ebenfalls an diesen
Vereinheitlichuns-nonsens von Systemd zu glauben. Ich hallte seinen
grossen Einfluss auf die Kernel/Userspace API für ausserst bedenklich.
Bei Richard M. Stallman denke ich, dass er die Problematik einfach nicht
sieht. Es sind keine Rechtlichen oder Physische Einschränkungen, wie die
gegen welche er in der Vergangenheit vorgegangen ist, und die Verwendung
von freier Software ist nicht offensichtlich, im sinne von man könnte
weiterhin welche schreiben, die auf Systemd abgestimmt ist, oder ein
System ohne Systemd aufbauen. Was er darüber schreibt wie er Computer
nutzt ist wirklich extrem: https://stallman.org/stallman-computing.html,
es würde mich nicht wundern wenn er mit Systemd noch garnicht allzuviel
zutun hatte. Ausserdem scheint er sich bereits mit vielen auch teils
gröberen Problemen zu befassen: https://www.stallman.org/ deshalb
erstaunt es mich nicht, dass er kein sonderliches Interresse an der
Systemd debatte hat.
> Wie paßt das zu dem angeblichen "Vendor Lock-In"?
Nun, was soll die Meinung dieser Leute denn damit zutun haben, ob es ein
Vendor Lock-In ist? Was passt dir an dieser Bezeichnung des Problems
nicht, findest du ein anderer Ausdruck wäre passender?
> Sei mir bitte nicht böse, aber wenn systemd wirklich so furchtbar> schlimm, schlecht designt und böse wäre, wie Du und andere behaupten:> warum äußern sich die führenden Köpfe der Linux-Community denn nicht nur> nicht ähnlich ablehnend wie Du, sondern übernehmen systemd-Patches in> den Linux-Kernel und systemd in die großen Distributionen und andere> Software?
Da linux eine Comunity ist, gibt es nicht wirklich Die führenden
Köpfe. Klar, einige Distributionen haben grössere Verbreitung als
andere, aber das heist nicht, dass das auch so bleibt. Innerhalb der
Linux-Community gibt es viele, die nicht besonders viel Ahnung von der
Thematik haben. Zusätzlich hat sich das Systemd-Kollektiv in diser
Community gebildet und seine Ideen vom Richtigen Einheitlichen System
verbreitet. Dass sich dadurch eine Mehrheit gebildet hat, die Systemd
eine gute Idee fanden, oder zumindest nichts dagegen hatten ist deshalb
nicht erstaunlich. Zusätzlich gab es eigentlich keine Objektiven
Diskussionen, die nicht blitzartig eskaliert sind. Es ist wie mit allen
Dingen, solange man das Problem nicht Spürt, interessiert es keinen.
Daniel A. schrieb:> Die starke Parallelisierung von Systemd macht dieses weniger> deterministisch, ich finde das widerspricht der Anforderung nach> Stabilität ein wenig.
Das widerspricht nur der Forderung nach Determinismus, nicht der nach
Stabilität. Außerdem wird dem Determinismus in systemd doch durch die
Targets und die Abhängigkeiten Rechnung getragen. ;-)
> Ansonsten kann ich nur hoffen, dass du damit richtig liegst dass sich> die Modularität & Standardisierung mit der zeit noch verbessert. Dazu> müsste Systemd aber auch einmal einen Stand erreichen können, in welchem> sagen kann dass man eine Vollständige Version hat.
Auch das glaube ich nicht. Im Laufe der Zeit werden zuerst die
stabilsten und drängendsten Teile diesen Prozeß durchlaufen, andere erst
später und manche vielleicht sogar nie. Aber zum jetzigen Zeitpunkt ist
es IMHO noch verfrüht, dazu Prognosen abzugeben. Denn, wie gesagt: jetzt
ging es erst einmal darum, überhaupt was zu haben, das dann später
standardisiert und modularisiert werden kann.
> Auch das Uselessd Projekt wurde deshalb ja bereits vor Jahren> aufgegeben.
Aufgrund eines "growing lack of interest", wie der Autor schreibt, also:
weil kein Mensch das Ding gebraucht hat.
> Ich denke der teil hat sogar sehr gut funktioniert. Egal ob ich ssmtp,> exim, postfix oder sendmail nehme, ein sendmail Programm/Symlink liefern> sie alle.
Ja, zur Wahrung der Abwärtskompatibilität. Aus haargenau demselben Grund
kann systemd auch SysV-Startskripte abarbeiten.
Wo Du gerade sendmail erwähnst: ich kann mich an ähnliche Diskussionen
wie diese erinnern, als die ersten Distributionen von sendmail auf
andere MTAs gewechselt sind. Spannenderweise wurde damals auch die
Modularisierung der neuen MTAs als Quelle von Komplexität und
Sicherheitsproblemen aufgeführt, und die Widerstände gegen Exim und
Postfix waren noch wesentlich stärker als heute der Widerstand gegen
systemd. Vielleicht möchtest Du Dir einmal eine alte sendmail.cf
anschauen, um zu verstehen, warum sich die besseren MTAs letztlich
gegenüber sendmail durchsetzen konnten.
> Egal ob ich syslog-ng, dsyslog, rsyslog, etc. nutze, logger> und die syslog Funktionen hab ich immer.
Ja, und Du hast sie weiterhin. Niemand zwingt Dich, journald zu
benutzen. Wenn Du magst, kannst Du wie bisher die Syslog-API benutzen.
> Was sich unterscheidet sind also nur der Ort der Konfigurationsdateien,> kleine Distributionsspezifische Hilfsprogramme, die init scripte, die> Packetverwaltung und der Umfang/die Namen der verfügbaren Packete in> dieser. Ein Sysadmin muss in der Regel also nur den Paketnamen und das> Installationskommando, sowie den Ort der Konfigurationsdateien nachsehen> (welche meistens sowieso in /etc/packetname liegen). Die eigentliche> Konfiguration unterscheidet sich dann nichtmehr, selbes Programm =>> selbe Konfiguration. Die paar Kleinigkeiten bereiten jemandem mit etwas> Erfahrung doch keine Schwierigkeiten oder Mehraufwand.
Nach gut dreißig Jahren Berufserfahrung kenne ich den Aufwand für diese
"Kleinigkeiten" leider sehr viel besser, als mir lieb ist. Daher weiß
ich auch, daß das keineswegs Kleinigkeiten und die Mehraufwände groß
sind.
> Ausserdem, wenn ein Admin mit seinen Systemen/Programmen nicht> klarkommt, dann liegt das Problem doch beim Admin der noch nicht genug> Erfahrung mit dem System/Programmen für die er zuständig ist hat. In der> Informatik muss man immer viel lernen, und wer dazu zu faul ist hat> einfach den falschen job.
;-)
> Der entscheidende Punkt bei OpenSource ist doch, dass alle Mithelfen> können und die Quellen ansehen können.
Das kannst Du auch bei systemd: https://github.com/systemd/systemd> Wenn man sich grosse OpenSource Projekte> ansieht, sieht man häufig stabile releases, welche nur Bugfixes und> kleine Anpassungen bekommen, Testing releases mit teils auch neuen> Funktionen, und die momentane Entwicklungsversion.
Das wird üblicherweise so gehandhabt, wenn die Software erstmal stabil
ist und die gewünschte Funktionalität weitgehend ausentwickelt ist. Das
wird früher oder später auch bei systemd der Fall sein.
> Sheeva P. schrieb:>>> * Es hätte Systemd Architekturmässig einfacher gemacht, weil die>>> Schnittstellen und der Aufbau der Komponenten untereinander sauber>>> Definiert und weniger Komplex gemacht worden wäre, also gut geplant.>>>> Das hätte zunächst einen enormen Aufwand bedeutet, noch bevor die erste>> Zeile Software geschrieben worden wäre. [...]>> Man muss es ja nicht übertreiben.
Doch, natürlich. Entweder man macht so etwas ganz, oder gar nicht, sonst
läuft die Entwicklung auseinander. Ungenaue und nicht ausspezifizierte
Standards sind schlimmer als gar keine. Dann interpretiert jeder diesen
Standard nämlich so, wie es ihm in den Kram paßt, und am Ende hat man n
inkompatible Implementierungen und jeder schreit "meine ist richtig".
Ein Riesenspaß für die ganze Familie, BTDT!
>> Darüber hinaus ist es auch nur teilweise richtig, daß man systemd nur>> entweder ganz oder gar nicht benutzen kann. Das uselessd-Projekt zeigt,>> daß man systemd bereits jetzt auf die wesentlichen Kernkomponenten des>> Init-Systems zusammenkürzen kann, wenn man das denn will.>> Das uselessd-Projekt ist seit Jahren tot.
Wie gesagt: aufgrund mangelnden Interesses. Aber daß das Zusammenkürzen
möglich ist, hat es trotzdem bewiesen.
> Wenn es um den Kernel geht gibt es keine bessere Ansprechperson als> Linus Torvalds, wenn es um den Userspace geht sieht die Sache jedoch> anders aus. Linus nutzt gängige Distributionen und freut sich über alle> Nutzer seines Kernels, sei das nun ein PC, ein Android Phone oder sonst> was. Ich habe den Eindruck, dass wenn es nicht um den Kernel geht er> sich generell gerne etwas zurück hält.
Diesen Eindruck habe ich nicht: http://www.golem.de/1108/85472.html> Da linux eine Comunity ist, gibt es nicht wirklich Die führenden> Köpfe.
Oh.
> Innerhalb der Linux-Community gibt es viele, die nicht besonders viel> Ahnung von der Thematik haben.
Linus, Greg, Richard, die Maintainer von Debian, Ubuntu, Arch, Fedora,
RedHat, CentOS: die haben alle keine Ahnung? Das glaube ich nicht. Und
bereits bei Upstart hat es viele heftige Diskussionen gegeben, aber bei
systemd sollen dieselben Leute dann auf einmal keine Ahnung oder kein
Interesse mehr gehabt haben? Sorry, das ist absurd.
> Zusätzlich hat sich das Systemd-Kollektiv in diser Community gebildet> und seine Ideen vom Richtigen Einheitlichen System verbreitet. Dass sich >
dadurch eine Mehrheit gebildet hat, die Systemd eine gute Idee fanden,
> oder zumindest nichts dagegen hatten ist deshalb nicht erstaunlich.
Doch, das finde ich schon -- insbesondere vor dem Hintergrund der
hitzigen Diskussionen, die seinerzeit um Upstart geführt wurden. Ich
sehe auch kein Kollektiv, das sich irgendwie gebildet haben soll, und
gehöre auch keinem solchen Kollektiv an. Meine Erfahrungen mit systemd
sind sehr gut, seine Dokumentation und der Quellcode sehen nach allem,
was ich bislang davon gesehen habe, ebenfalls ordentlich aus. Daß die
Module von umfangreichen Softwarepaketen auf einander aufbauen und sich
gegenseitig ergänzen, sehe ich ebenfalls nicht als Problem an --
insbesondere dann nicht, wenn sie so viele Funktionalitäten ersetzen und
vereinheitlichen.
> Es ist wie mit allen Dingen, solange man das Problem nicht Spürt,> interessiert es keinen.
Mag sein, aber anstelle Eurer Probleme sehe und spüre ich vor allem die
Vorzüge von systemd und mag ihn deshalb. Bisher habe ich auch noch kein
Argument gelesen oder gehört, das mich davon abbringen würde. Vielleicht
habe ich ja, wie Du andeutest, tatsächlich keine Ahnung und / oder sogar
meinen Beruf verfehlt, das kann ich natürlich nicht ausschließen. Bisher
sehe ich aber nur, wie einige Traditionalisten sich gegen den
Fortschritt wehren und dabei allen, die eine andere Meinung zu vertreten
wagen, die Erfahrung und Kompetenz absprechen. Das überzeugt mich nicht.
Zudem benutzt jedes Linux ein Init-System, und die großen Distributionen
benutzen mittlerweile alle systemd dafür. Wenn das wirklich so übel
wäre, wie Du behauptest, dann hätten sehr viel mehr Leute die von Dir
genannten Probleme am eigenen Leib erfahren. Und wenn diese Probleme
tatsächlich an systemd gelegen hätten, wären sie dagegen Sturm gelaufen.
Aber sowas hat niemals stattgefunden, so daß ich vermute, daß die
angeblichen Probleme nicht annäherungsweise so groß sind, wie Du
behauptest. Diese Vermutung deckt sich dann auch mit meinen eigenen
Erfahrungen, bei denen Sammlung mir bislang keine gravierenden Probleme
begegnet sind. Ganz im Gegenteil hat mich meine praktische Arbeit mit
systemd zu der Überzeugung gebracht, daß das bereits jetzt eine bessere
und konsistentere Lösung ist, als es SysV-Init, GNU Shepherd, OpenRC und
Upstart je waren.
Die einzigen Argumente, die Du und andere gegen systemd vorbringt, sind
im Prinzip ja immer wieder dieselben beiden: erstens, daß die
Einzelteile des systemd-Paketes von einander abhängig sind und einander
voraussetzen, und zweitens, daß systemd sich nicht nur den klassischen
Bootprozeß kümmert, sondern auch um einige weitere Aspekte, die mehr
oder weniger eng mit dem Bootprozeß gekoppelt und damit verbunden sind.
Keines dieser Argumente überzeugt mich, denn ersteres ist nicht
ungewöhnlich -- es beschwert sich ja auch keiner darüber, daß man
Apache-Module nur mit dem Apache-Webserver benutzen kann -- und
letzteres ist dem Designziel einer konsistenten und einheitlichen
Standardlösung geschuldet. Warum das so problematisch sein soll, sehe
ich auch nach dieser langen Diskussion noch nicht.
Sheeva P. schrieb:>> Nein, kann man nicht, weil Lennart der Meinung ist, man müsse das nicht>> unterstützen und daher einen /usr-Eintrag in der /etc/fstab absichtlich>> ignoriert.>> Man kann Dateisysteme auch ohne Eintrag in der /etc/fstab mounten, zum> Beispiel über ein Unitfile, und dabei kann man problemlos ein unionfs> mit einem anderen Dateisystem über das zum Booten nötige /usr legen.
Nein, weil systemd ein vollständig vorhandenes /usr zum Booten braucht
und dieses auch nicht remountet. Entsprechende Einträge in der
/etc/fstab werden absichtlich ignoriert, weil Lennart das so will.
Nachträglich ein Overlay auf /usr legen zu wollen ist übrigens reichlich
bescheuert.
> systemd und seine Libraries sind so entworfen, daß sie sauber> miteinander und mit etlichen anderen Systemkomponenten zusammenarbeiten.
Du hast das falschrum. Systemd und seine Libraries sind so entworfen,
dass andere Systemkomponenten mit ihnen gut zusammenarbeiten können,
sehr gut sogar.
Wenn systemd mit anderen Systemkomponenten (oder deren Entwicklern)
nicht zusammenarbeiten kann, wird die andere Systemkomponente unter dem
systemd-Regenschirm ersetzt (logind, networkd).
> Ein modularer Entwurf hätte allerdings nicht nur dem Ziel von> systemd nach Standardisierung und Vereinheitlichung entgegen> gestanden, sondern hätte systemd auch noch viel komplizierter> und aufwändiger gemacht, als es ohnehin schon ist.
Standardisierung und Vereinheitlichung gibt es auch, ohne dass man einen
monolithischen Stahlblock hinstellt und sagt "friss oder stirb".
> Ich als Entwickler entwerfe meine Software auch nicht mit dem> primären Ziel, daß der Anwender Teile davon durch eine andere> Software ersetzt.
Entwickelst du deine Software zufällig so, dass sie, wenn es sich
anbietet, die Funktionalität anderer Software ebenfalls bietet?
Mit dem Sekundärziel, dass die Nutzer möglichst einfach auf deine
Software migrieren können, aber nur möglichst schwierig davon weg? Bei
kommerzieller Software ist das üblich.
>> Microsoft hat für ähnliches Verhalten übrigens mal furchtbar von der EU>> aufs Maul bekommen und aus irgendeinem Grund bin bin ich mir sicher,>> dass du da nicht auf Microsofts Seite standest...>> Im Gegenteil: Microsoft hat was auf die Mütze bekommen, weil sie> Software, die eben nicht hochintegriert war und problemlos autark hätte> betrieben werden können, mißbräuchlich miteinander gebündlt hatte, um> Konkurrenten aus dem Markt zu drängen.
Nein, sie haben angefangen, die Windows-Oberfläche als Webseite zu
betrachten ("Active Desktop") und den Interner Explorer als
Rendering-Engine missbraucht. Dass das technisch sinnvoll ist, siehst du
übrigens an der heutigen Realität.
Die Konkurrenz zu vernichten, war nur ein gewünschter Nebeneffekt: Sie
hatten ein System aus integrierten Teilen gebaut, welches die
Funktionalität fremder Software (Netscape) hinreichend inkompatibel
(eigene Standards) enthält. Dann haben sie gewartet, bis die Nutzer
begriffen haben, dass sie die fremde Software jetzt nicht mehr brauchen.
Und jetzt schaue dir das Entwicklungsmodell von systemd nochmal an: Sie
haben ein System aus integrierten (libsystemd0) Teilen gebaut, welches
die Funktionalität fremder Software (sysvinit, syslog, PolKit,
NetworkManager) hinreichend inkompatibel (eigene DBus-Schnittstellen)
enthält. Jetzt müssen sie nur warten, bis die Nutzer begriffen haben,
dass sie die fremde Software jetzt nicht mehr brauchen.
> Im Übrigen finde ich es ehrlich gesagt unter aller Sau, systemd und> seine Entwickler mit Microsofts unlauteren Geschäftspraktiken in> Verbindung zu bringen oder sogar gleichzusetzen.
Es gibt zwei wesentliche Unterschiede:
- du bekommst den Quelltext unter einer freien Lizenz dazu,
- deine Definition von "unlautere Geschäftspraktiken" ist anders.
Die systemd-Entwickler fahren ein klassisches "embrace, extend,
extinguish" und stehen öffentlich dazu. Und die Masse jubelt.
Und obwohl ich weiß, dass du meinen Beitrag nicht zu Ende lesen wirst,
möchte ich dich noch auf etwas hinweisen: Ich habe tatsächlich nichts
gegen die technischen Ansätze von systemd, denn das meiste davon ist
wirklich gut begründet und sinnvoll.
Ich habe aber etwas gegen die Art, wie die systemd-Entwickler mit ihrer
Implementation Politik betreiben. Die ist genauso schmutzig wie
Microsofts Strategie vor 20 Jahren, nur weniger geheim.
Thread beobachten
Seitenaufteilung abschalten