systemd-freie Linux

Für mich widerspricht systemd der klassischen Linux-Philosophie: Mach 
nur eine Sache, aber die richtig. Und mach sie so, dass das Werkzeug 
austauschbar bleibt.

Je mehr Aufgaben ein Werkzeug an sich zieht, desto schwieriger wird es, 
es irgendwann auszutauschen. Desto abhängiger wird man davon.

A. K. schrieb:
> Für mich widerspricht systemd der klassischen Linux-Philosophie

Man könnte es auch als klassische "Unix-Philosophie" sehen, das klingt 
noch klassischer ;-)

Übrigens bin ich da Deiner Meinung: Die Unix-Tools sind im allgemeinen 
klein, überschaubar und in Kombination (z.B. über Pipes) ungemein 
flexibel. Ich kann mich nur wenig mit systemd anfreunden.

Aber: man kann in systemd eine Unit schreiben, die ein Programm bei 
Fehlschlag dreimal nach zehn Sekunden neu startet, und beim Stoppen der 
Unit das Programm und seine 12 Kindprozesse alle terminiert, ohne dabei 
wahnsinnig zu werden. Das hat sysvinit in seinen 20 Jahren Existenz 
nicht geschafft. systemd bietet halt eine gewisse Menge nichttrivialer 
Features, die dazu noch auf jedem System gleich funktionieren, und man 
muss nicht jedes Mal das Rad in einem hässlichen Shellskript neu 
erfinden. Da ist mir die Unix-Philosophie dann auch egal -- 
Benutzbarkeit geht erstmal vor.

Re. Thread: du beschwerst dich über den Poettering und systemd, hast 
aber keine Ahnung was dich daran eigentlich stört bzw. was bei einer 
anderen Lösung besser wäre? Hä?

Sven B. schrieb:
> Aber: man kann in systemd eine Unit schreiben, die ein Programm bei
> Fehlschlag dreimal nach zehn Sekunden neu startet, und beim Stoppen der
> Unit das Programm und seine 12 Kindprozesse alle terminiert, ohne dabei
> wahnsinnig zu werden.

Das gehört zu dem, was JJ schrieb, und dem ich zustimme.

JJ schrieb:
> Würde systemd sich darauf beschränken Programme zu starten und ggf. am
> laufen zu halten wäre es eine wirklich geniale Software. An der Stelle
> gefällt es mir ernsthaft sehr gut!

Aber warum muss syslog da rein? Hatte schon Zores damit.

Das journal-Zeug fand ich am Anfang auch doof, aber inzwischen finde ich 
es super. Endlich muss man nicht mehr in wirren Logdateien rumgraben, 
die in jeder Version jedes Programms woanders rumfahren, endlich kümmert 
sich eine sinnvoll voreingestellte Logik darum, dass zwar ordentlich 
Logs aufgehoben werden aber nicht die ganze Platte zumüllen, und zudem 
ist es auch extrem einfach geworden, ordentliche Logs mit eigenen 
Programmen zu generieren. Ich finde, das gehört so gesehen eigentlich zu 
einem Init-System dazu. Klar muss man sich mal zehn Minuten durch die 
journalctl-Manpage lesen, aber das lohnt sich, das Tool ist m.E. 
eigentlich super.

Die ganzen anderen Subsysteme kann man ziemlich problemlos abschalten 
oder ersetzen, gerade systemd-networkd benutzt ja eigentlich keiner auf 
seinem Desktop ... auf Embedded-Systemen oder Servern ist es aber ganz 
gut.

Eine meiner vorherigen zusammenfassung: 
Beitrag "Re: Vor-/Nachteile Systemd vs. SysVinit für Benutzer?"
Eine vorherige längere diskussion: 
Beitrag "Re: RasPi Autostart Skript nicht als root"

Sven B. schrieb:
> Aber: man kann in systemd eine Unit schreiben, die ein Programm bei
> Fehlschlag dreimal nach zehn Sekunden neu startet, und beim Stoppen der
> Unit das Programm und seine 12 Kindprozesse alle terminiert, ohne dabei
> wahnsinnig zu werden. Das hat sysvinit in seinen 20 Jahren Existenz
> nicht geschafft

Das gehört auch nicht in ein rc-System, auch wenn es dort gerne 
integriert wird. Dafür verwendet man einen Supervisor.

Sven B. schrieb:
> Das journal-Zeug fand ich am Anfang auch doof, aber inzwischen finde ich
> es super. Endlich muss man nicht mehr in wirren Logdateien rumgraben,
> die in jeder Version jedes Programms woanders rumfahren, endlich kümmert
> sich eine sinnvoll voreingestellte Logik darum, dass zwar ordentlich
> Logs aufgehoben werden aber nicht die ganze Platte zumüllen, und zudem
> ist es auch extrem einfach geworden, ordentliche Logs mit eigenen
> Programmen zu generieren.

Schön für dich.

> Ich finde, das gehört so gesehen eigentlich zu
> einem Init-System dazu.

Definitiv nicht. Es gibt keinen Grund, warum das eine das ander 
vorraussetzen sollte. Wenn man alles auf einmal istallieren will, kann 
man dafür ja statdessen auch ein Virtuelles oder Metapacket erstellen, 
ohne harte Abhängigkeiten zu erzwingen.

Sven B. schrieb:
> Die ganzen anderen Subsysteme kann man ziemlich problemlos abschalten
> oder ersetzen, gerade systemd-networkd benutzt ja eigentlich keiner auf
> seinem Desktop ... auf Embedded-Systemen oder Servern ist es aber ganz
> gut.

Ausser wenn mal etwas davon abhängig ist. Versuche mal iio-sensor-proxy 
oder snaps ohne systemd zu verwenden. Es geht nicht!

Daniel A. schrieb:
> Sven B. schrieb:
>> Aber: man kann in systemd eine Unit schreiben, die ein Programm bei
>> Fehlschlag dreimal nach zehn Sekunden neu startet, und beim Stoppen der
>> Unit das Programm und seine 12 Kindprozesse alle terminiert, ohne dabei
>> wahnsinnig zu werden. Das hat sysvinit in seinen 20 Jahren Existenz
>> nicht geschafft
>
> Das gehört auch nicht in ein rc-System, auch wenn es dort gerne
> integriert wird. Dafür verwendet man einen Supervisor.

Aha. Zum Beispiel welche halbwegs verbreitete Software?

>> Ich finde, das gehört so gesehen eigentlich zu
>> einem Init-System dazu.
>
> Definitiv nicht. Es gibt keinen Grund, warum das eine das ander
> vorraussetzen sollte. Wenn man alles auf einmal istallieren will, kann
> man dafür ja statdessen auch ein Virtuelles oder Metapacket erstellen,
> ohne harte Abhängigkeiten zu erzwingen.

Man kann vieles tun. Es fragt sich nur, warum. Ich finde es bietet einen 
großen Mehrwert, dass das Log-System in systemd integriert ist.

> Sven B. schrieb:
>> Die ganzen anderen Subsysteme kann man ziemlich problemlos abschalten
>> oder ersetzen, gerade systemd-networkd benutzt ja eigentlich keiner auf
>> seinem Desktop ... auf Embedded-Systemen oder Servern ist es aber ganz
>> gut.
>
> Ausser wenn mal etwas davon abhängig ist. Versuche mal iio-sensor-proxy
> oder snaps ohne systemd zu verwenden. Es geht nicht!

Sehr merkwürdiges Argument. Das ist Problem dieser Software, nicht von 
systemd!

Sven B. schrieb:
> Das journal-Zeug fand ich am Anfang auch doof, aber inzwischen finde ich
> es super. Endlich muss man nicht mehr in wirren Logdateien rumgraben,

ok, aber wie recherchiert man in dem journal richtig?

Was ich regelmäßig brauche, ist sowohl das aktuelle log live ansehen, 
als auch anhalten und von da aus dann zurück suchen. Dann wieder live 
weiter ansehen usw. Das Ganze per SSH auf einem entfernten Server.

Wie geht das mit dem journald?

Ein normales Logfile mache ich mit less auf, mit 'F' bin ich im 
follow-Modus und sehe live was geloggt wird. Mit Ctrl-C halte ich an und 
kann mit ? rückwärts suchen. Mit 'F' wieder die neu geloggten Sachen 
sehen etc.

Beim journalctl kann ich zwar -f verwenden, dann kann ich von da aus nur 
die neu geloggten Einträge sehen, ich kann nicht mehr Rückwärts in die 
bisherigen Daten reinsuchen. Verwende ich dagegen kein -f, sehe ich nur 
die bis zum Moment des Aufrufs geloggten Daten, keine neuen.

Wie ist gedacht daß man das benutzt?

Gerd E. schrieb:
> Sven B. schrieb:
>> Das journal-Zeug fand ich am Anfang auch doof, aber inzwischen finde ich
>> es super. Endlich muss man nicht mehr in wirren Logdateien rumgraben,
>
> ok, aber wie recherchiert man in dem journal richtig?
>
> Was ich regelmäßig brauche, ist sowohl das aktuelle log live ansehen,
> als auch anhalten und von da aus dann zurück suchen. Dann wieder live
> weiter ansehen usw. Das Ganze per SSH auf einem entfernten Server.
>
> Wie geht das mit dem journald?

Wenn du es genau wie mit der Datei willst: journalctl -f |less

Sven B. schrieb:
>> Wie geht das mit dem journald?
>
> Wenn du es genau wie mit der Datei willst: journalctl -f |less

Ne, eben genau nicht. Denn dann sehe ich im less nur das, was ab dem 
Moment des Aufrufs neu geloggt wird (und ein paar Zeilen vorher).

Ich kann dann NICHT mehr mit ? in die Daten von vor z.B. 10 Minuten 
zurück suchen.

Gerd E. schrieb:
> Sven B. schrieb:
>>> Wie geht das mit dem journald?
>>
>> Wenn du es genau wie mit der Datei willst: journalctl -f |less
>
> Ne, eben genau nicht. Denn dann sehe ich im less nur das, was ab dem
> Moment des Aufrufs neu geloggt wird (und ein paar Zeilen vorher).

journalctl -f --since="1 hour ago" |less +F

Sven B. schrieb:
> Daniel A. schrieb:
>> Das gehört auch nicht in ein rc-System, auch wenn es dort gerne
>> integriert wird. Dafür verwendet man einen Supervisor.
>
> Aha. Zum Beispiel welche halbwegs verbreitete Software?

daemontools ist ein Klassiker. runit, shepard, upstart haben es 
integriert. Wikipedia hat noch ne liste: 
https://en.m.wikipedia.org/wiki/Process_supervision

>>> Ich finde, das gehört so gesehen eigentlich zu
>>> einem Init-System dazu.
>>
>> Definitiv nicht. Es gibt keinen Grund, warum das eine das ander
>> vorraussetzen sollte. Wenn man alles auf einmal istallieren will, kann
>> man dafür ja statdessen auch ein Virtuelles oder Metapacket erstellen,
>> ohne harte Abhängigkeiten zu erzwingen.
>
> Man kann vieles tun. Es fragt sich nur, warum. Ich finde es bietet einen
> großen Mehrwert, dass das Log-System in systemd integriert ist.

Man hätte auch einfach die syslog API verwenden können, so wie jeder 
andere logger auch. Oder ein unabhängiges Tool wie z.B. logger. Mir wäre 
sogar noch ziemlich egal, wenn systemd von journald abhängt, aber dass 
journald von Systemd abhängt geht garnicht. Jede anwendung, die jetzt 
die journald api nutzt, generiert einfach keine logs auf non-systemd 
Systemen. Zudem würden diese auf non-systemd Systemen den libsystemd 
shim verwenden, (der nebenbei von systemd zur buildtime abhängt), und 
bei Funktionsaufrufen immer einfach nichts tut. Und da alle APIs in 
libsystemd sind, kann man nichteinmal sinvoll alternative Binary 
packages erstellen, die nur eine API ersetzen!

>> Sven B. schrieb:
>>> Die ganzen anderen Subsysteme kann man ziemlich problemlos abschalten
>>> oder ersetzen, gerade systemd-networkd benutzt ja eigentlich keiner auf
>>> seinem Desktop ... auf Embedded-Systemen oder Servern ist es aber ganz
>>> gut.
>>
>> Ausser wenn mal etwas davon abhängig ist. Versuche mal iio-sensor-proxy
>> oder snaps ohne systemd zu verwenden. Es geht nicht!
>
> Sehr merkwürdiges Argument. Das ist Problem dieser Software, nicht von
> systemd!

Doch, ist es. Systemd wurde von anfang an so designed, dass es viele 
convinience APIs bietet, damit andere Programme diese nutzen, und diese 
ohne es nichtmehr oder nichtmehr richtig oder nur teilweise laufen. Bei 
snaps z.B. sind es die API Abstraktionen für 
Namespaces/cgroups/container, von denen es abhängt, die komplett 
unnötigerweise von Systemd abhängen.

Nop schrieb:
> Zudem sollte man bedenken, daß durch Parallelisierung das Starten mit
> systemd schneller geht.

Stimmt nur leider nicht, selbst wenn man andere init systeme mit 
parallelisierung ignoriert. Der Ressourcenoverhead für die 
Synchronisierung, Taskswitches, Namespaces, etc. von Systemd können es 
sogar langsamer als sysvinit werden lassen. Ausserdem ist gerade bei 
Servern, und oft auch bei PCs, die Hardware initialisierung um 
grössenordnungen langsamer als der System init.

Daniel A. schrieb:
>> Aha. Zum Beispiel welche halbwegs verbreitete Software?
>
> daemontools ist ein Klassiker. runit, shepard, upstart haben es
> integriert. Wikipedia hat noch ne liste:
> https://en.m.wikipedia.org/wiki/Process_supervision

Hm, was noch auf der Liste steht ist systemd ...?
Hier verstehe ich das Argument nicht. Warum soll das jetzt irgendwie 
besser sein, wenn man dafür ein anderes Tool benutzt?

>> Sehr merkwürdiges Argument. Das ist Problem dieser Software, nicht von
>> systemd!
>
> Doch, ist es. Systemd wurde von anfang an so designed, dass es viele
> convinience APIs bietet, damit andere Programme diese nutzen, und diese
> ohne es nichtmehr oder nichtmehr richtig oder nur teilweise laufen. Bei
> snaps z.B. sind es die API Abstraktionen für
> Namespaces/cgroups/container, von denen es abhängt, die komplett
> unnötigerweise von Systemd abhängen.

Hm, aber die Software benutzt doch die APIs? Wenn das so eine schlechte 
Idee ist, könnte sie ja was anderes benutzen ...
systemd vorzuwerfen, dass es komfortable APIs zur Verfügung stellt, 
finde ich albern.

> Nop schrieb:
> Stimmt nur leider nicht, selbst wenn man andere init systeme mit
> parallelisierung ignoriert. Der Ressourcenoverhead für die
> Synchronisierung, Taskswitches, Namespaces, etc. von Systemd können es
> sogar langsamer als sysvinit werden lassen. Ausserdem ist gerade bei
> Servern, und oft auch bei PCs, die Hardware initialisierung um
> grössenordnungen langsamer als der System init.

Ach komm, das ist doch jetzt wirklich völliger Quark. Als systemd damals 
aufkam, hat sich auf genau derselben Hardware die Boot-Zeit von 45 
Sekunden auf 6-7 reduziert. Auch und gerade Hardwareinitialisierung kann 
man zum größten Teil parallel machen. Klar bringt es in manchen Fällen 
mehr und in anderen weniger, aber "Resourcenoverhead und 
Synchronisierung und Taskswitches" ist komplettes FUD. Das spielt null 
Rolle bei den Zeiten, von denen man hier redet.

Sven B. schrieb:
> journalctl -f --since="1 hour ago" |less +F

Damit das brauchbar wird, wirst Du aber oft nen paar Stunden zurückgehen 
wollen. Und jetzt scrollt der doch die ganzen Megabytes durch - das 
kannst Du über SSH auf ner langsamen Leitung vergessen, selbst auf nem 
schnellen System + guter Leitung macht es keinen Spaß das regelmäßig 
aufzurufen warten zu müssen.

Vor allem wenn man weiß, wie schön schnell und effizient das vorher mit 
normalen Logfiles ging.

Wie gesagt, diese Art der Abfragen und Recherche ist für mich täglich 
Brot: sehen was jetzt auf dem System schief läuft, zurückspringen an die 
Stelle, an der das Problem das erste mal aufgetreten ist, Ursache 
identifizieren. Das muss fix funktionieren und bequem sein. Ich verstehe 
nicht, daß das für andere nicht auch ein K.O.-Kriterium ist.

Ich fürchte, solange die nicht ein Tool wie less haben, was direkt die 
internen Datenstrukturen vom journald anzapft und direkt die gewünschten 
Bereiche anspringen kann, werde ich mit dem journal nicht glücklich.

Daniel A. schrieb:
> Ausserdem ist gerade bei
> Servern, und oft auch bei PCs, die Hardware initialisierung um
> grössenordnungen langsamer als der System init.

Jo, bis ein ordentliches Stück Serverblech endlich beim grub angekommen 
ist, ist der Kaffee kalt. Im Zeitalter virtualisierter Server spielt das 
aber keine so grosse Rolle. Und das muss man ihm lassen: Ein Reboot vom 
RHEL 7 geht unter VMware sehr schnell. Nur ist mir das ziemlich egal, 
wär kein Beinbruch, wenn 10 Sekunden dazu kämen.

Daniel A. schrieb:
> Der Ressourcenoverhead für die
> Synchronisierung, Taskswitches, Namespaces, etc. von Systemd können es
> sogar langsamer als sysvinit werden lassen.

Das habe ich noch nirgends in der Praxis beobachtet. Start und Shutdown 
sind durch systemd schon deutlich schneller geworden.

Vor allem daß man saubere Abhängigkeiten, z.B. von Netzwerkstatus und 
Mount- und Unmount von Netzwerkdateisystemen setzen kann, ist Gold wert.

Nop schrieb:
> Daniel A. schrieb:
>> Ausserdem ist gerade bei
>> Servern, und oft auch bei PCs, die Hardware initialisierung um
>> grössenordnungen langsamer als der System init.
>
> Bei VMs braucht es keine physikalische Hardware-Inititalisierung. Es
> geht nicht um den physikalischen Bootvorgang

Mein Devuan LXC Container mit grafischer Oberfläche startet in 2 bis 3 
Sekunden.

Sven B. schrieb:
> Daniel A. schrieb:
>>> Aha. Zum Beispiel welche halbwegs verbreitete Software?
>>
>> daemontools ist ein Klassiker. runit, shepard, upstart haben es
>> integriert. Wikipedia hat noch ne liste:
>> https://en.m.wikipedia.org/wiki/Process_supervision
>
> Hm, was noch auf der Liste steht ist systemd ...?
> Hier verstehe ich das Argument nicht. Warum soll das jetzt irgendwie
> besser sein, wenn man dafür ein anderes Tool benutzt?

Du argumentiertest, dass es ohne Systemd zu aufwendig sei. Ich zeige nur 
vertretbare Alternativen auf, um zu zeigen dass Systemd hier nicht die 
einzig vernünftige Lösung ist. In diesem speziellen fall habe ich keine 
starke Preferenz von einem Model, deshalb zähle ich ja auch dinge wie 
runit und upstart auf.

>>> Sehr merkwürdiges Argument. Das ist Problem dieser Software, nicht von
>>> systemd!
>>
>> Doch, ist es. Systemd wurde von anfang an so designed, dass es viele
>> convinience APIs bietet, damit andere Programme diese nutzen, und diese
>> ohne es nichtmehr oder nichtmehr richtig oder nur teilweise laufen. Bei
>> snaps z.B. sind es die API Abstraktionen für
>> Namespaces/cgroups/container, von denen es abhängt, die komplett
>> unnötigerweise von Systemd abhängen.
>
> Hm, aber die Software benutzt doch die APIs? Wenn das so eine schlechte
> Idee ist, könnte sie ja was anderes benutzen ...
> systemd vorzuwerfen, dass es komfortable APIs zur Verfügung stellt,
> finde ich albern.

Weisst du, was Vendor-lockin ist? Kennst du die Methoden, die verwendet 
werden, um es zu erzielen? Richtig, indem man andere von sich abhängig 
macht, verhindert man das sich etwas anderes durchsetzen kann, und 
kontrolliert letztendlich den user, oder hier, die OSS Welt.

Sven B. schrieb:
> Ach komm, das ist doch jetzt wirklich völliger Quark. Als systemd damals
> aufkam, hat sich auf genau derselben Hardware die Boot-Zeit von 45
> Sekunden auf 6-7 reduziert.

Bei mir wurde sie länger. Und bis es wieder sauber herunterfuhr, soweit 
bekahm ich es garnicht erst.

A. K. schrieb:
> Für mich widerspricht systemd der klassischen Linux-Philosophie: Mach
> nur eine Sache, aber die richtig. Und mach sie so, dass das Werkzeug
> austauschbar bleibt.
>
> Je mehr Aufgaben ein Werkzeug an sich zieht, desto schwieriger wird es,
> es irgendwann auszutauschen. Desto abhängiger wird man davon.

Lieber Kollege, ich widerspreche Dir ungern, aber systemd ist nicht 
ein Werkzeug, sondern eine Vielzahl von Werkzeugen. Daß diese 
Werkzeuge stark miteinander verzahn und relativ gut aufeinander 
abgestimmt sind, ändert letztlich nichts daran, daß auch im 
systemd-Universum jedes Werkzeug eine definierte Aufgabe hat und gegen 
ein anderes Werkzeug ausgetauscht werden kann, solange es Schnittstellen 
zu den übrigen Teilen abbildet.

systemd steht noch ziemlich am Anfang, und das Wichtigste, das man ihm 
aus meiner Sicht wirklich vorwerfen kann, ist der journald, diese 
Ablösung des klassischen Syslog durch Binärkram. Aber da ich nicht der 
Einzige bin, der diesen Punkt kritisiert, gehe ich davon aus, daß da 
früher oder später ein Drop-In-Ersatz entstehen wird. Vielleicht kommen 
Lennert und Kay aber auch selbst irgendwann zur $Vernunft.

Ansonsten scheint es viele unserer Kollegen zu stören, daß systemd so 
viele Dinge tut, sehr viel mehr als das klassische SysV-Init. systemd 
vereint die Funktionalitäten von SysV-Init und bildet dabei auch etliche 
Funktionen ab, welche klassischerweise einen Prozeßmanager wie monit, 
supervisord, oder runit benötigt hätten, hinzu kommen Sessionmanagement, 
Netzwerkverwaltung, Logging und Zeitsynchronisierung, um nur einige 
Komponenten zu nennen.

Ich sehe und verstehe, daß es viele erfahrene UNIX-User erschreckt, so 
viele gewohnte, vielleicht auch liebgewonnene und jedenfalls für seine 
Systeme so wichtige Funktionen an etwas Neues abzugeben, das zudem auch 
noch (fälschlicherweise) als Monolith wahrgenommen wird. Dies besonders 
dann, wenn mittlerweile auch Anwendungsentwickler beginnen, ihre 
Software auf den Betrieb mit systemd auszurichten oder sie sogar so 
direkt mit systemd zu verzahnen, daß sie nicht mehr ohne läuft.

Andererseits war doch auch schon seit vielen Jahren klar, daß SysV-Init 
nicht wirklich gut mit den Fähigkeiten moderner Hard- und Software 
umgehen konnte, und deswegen ein Ersatz gefunden werden müßte. Egal ob 
Ubuntu mit seinem Upstart, Void mit runit, oder Alpine mit OpenRC, alle 
waren auf der Suche nach etwas Neuem, Besseren. Und wenn ich mich zurück 
entsinne, was für fiese Hacks ich in dem einen oder anderen 
SysV-Initskript verbrechen mußte, um die eine oder andere Software ans 
Laufen zu bringen: also ich kann nur sagen, ich mag systemd. Trotz 
seiner Schwächen, insbesondere der Angelegenheit mit dem Syslog und der 
etwas hemdsärmeligen Dokumentation.

Sonntagmorgen schrieb:
> Ich halte dies für den größten Blödsinn!

Herzlichen Dank für Deine unübertroffen ausführlichen Sachargumente. ;-)

Systemd ist doch die Voraussetzung daß Linux endlich den Desktop 
übernimmt!!11!!1

Michael X. schrieb:
> Systemd ist doch die Voraussetzung daß Linux endlich den Desktop
> übernimmt!!11!!1

Ich habe gehört nächstes Jahr soll es endlich so weit sein!

Daniel A. schrieb:
> Man hätte auch einfach die syslog API verwenden können, so wie jeder
> andere logger auch.

Ja, das wäre eine sehr gute Idee gewesen.

> Jede anwendung, die jetzt
> die journald api nutzt, generiert einfach keine logs auf non-systemd
> Systemen.

Naja, so ziemlich jede mir bekannte Software, die ich auf meinen 
Systemen haben will, besitzt ein konfigurierbares Logging. Und wenn eine 
das nicht hat, sondern sich vollständig von journald abhängig macht, 
dann ist das sicherlich kein Problem von oder mit systemd, sondern mit 
den Entwicklern der betreffenden Anwendung.

> Doch, ist es. Systemd wurde von anfang an so designed, dass es viele
> convinience APIs bietet, damit andere Programme diese nutzen, und diese
> ohne es nichtmehr oder nichtmehr richtig oder nur teilweise laufen. Bei
> snaps z.B. sind es die API Abstraktionen für
> Namespaces/cgroups/container, von denen es abhängt, die komplett
> unnötigerweise von Systemd abhängen.

Entschuldige, aber das ist dann trotzdem kein Problem von systemd, 
sondern immer noch ausschließlich eines der betreffenden Anwendung. Was 
ist dabei denn Dein Vorwurf gegenüber systemd? Daß es angenehme APIs 
anbietet? Einer Software vorzuwerfen, daß sie APIs anbietet, ist doch 
Unfug. Wo Entwickler ihre Software vollständig und ausschließlich von 
nicht-standardisierten und nur in einer bestimmten Software vorhandenen 
APIs abhängig machen, dann ist das immer noch die bewußte Wahl und 
deswegen auch die alleinige Verantwortung der betreffenden Entwickler.

Ich bin auch bekennender systemd-Verweigerer, auch wenn das unter Debian 
nicht ganz einfach ist. ich war (und bin) sehr verwundert, dass sich 
Debian für systemd entschieden hat (wenn auch knapp und nicht 
friktionsfrei)

Neben den genannten Kritikpunkten, die ich unterschreibe, sehe ich vor 
allem kritisch, dass Init als "Mutter aller Prozesse" doch eine 
Sonderstellung einnimmt, und deswegen klein, überschaubar und stabil 
sein sollte (was bei systemd definitiv nicht der Fall ist.

Nebenbei ist meine Einschätzung zur "Diva" Kay Sivers als 
"Software-Designer" eine sehr ambivalente... zu gut habe ich noch die 
"udev-hell" in Erinnerung. Und von Linus höchstpersönlich und offiziell 
aus der Kernel-Entwicklung ausgeschlossen zu werden, muss man auch 
erstmal schaffen...

Daniel A. schrieb:
> Weisst du, was Vendor-lockin ist? Kennst du die Methoden, die verwendet
> werden, um es zu erzielen? Richtig, indem man andere von sich abhängig
> macht, verhindert man das sich etwas anderes durchsetzen kann, und
> kontrolliert letztendlich den user, oder hier, die OSS Welt.

Die klassische Methodik eines Vendor-Lockin ist es, die Daten des Kunden 
in proprietäre Formate einzusperren, aus denen er sie nicht oder nur mit 
sehr hohen Kosten wieder heraus bekommen kann. Davon kann bei systemd 
keine Rede sein. Und nicht systemd macht andere von sich abhängig, 
sondern andere machen ihre Software von systemd abhängig, das ist ein 
großer Unterschied. Wenn Du diesbezüglich jemanden kritisieren möchtest, 
dann sind systemd, die Autoren und die Befürworter die flashcne 
Adressaten.

Michael R. schrieb:
> Ich bin auch bekennender systemd-Verweigerer, auch wenn das unter Debian
> nicht ganz einfach ist.

Einfach finde ich es schon, man muss doch nur sysvinit-core und 
Freunde installieren. Na gut, dann kann man manche Pakete nicht mehr 
installieren, das ist schade, aber manche Windows-Programme laufen auch 
nicht unter Debian, so what? Das nehme ich gern in Kauf für ein System, 
das ohne Überraschungen einfach stabil läuft.

Richtig mühsam wird's, wenn man systemd eine Chance geben will. Man muss 
schon sehr viel Zeit investieren bis das System halbwegs rund läuft. 
Unter Debian funktioniert z.B. ntp nicht mehr und der ntp-Ersatz von 
systemd ist ein schlechter Witz. Um den abzuschalten muss man systemd 
lernen.

Das könnte Debian wirklich anders machen und die Modularität von systemd 
dem einfachen User zugänglich machen, also z.B. per Default keinen 
Zeitservice installieren. Ich glaube, ein Teil der systemd-Hasser könnte 
es sich dann nochmal überlegen.

Arno schrieb:
> Zumindest zu Beginn der systemd-Entwicklung - wie gesagt, den heutigen
> Stand kenne ich nicht, weiß nicht, ob der besser geworden ist - wäre das
> an fehlender Dokumentation und fehlender Stabilität der Interfaces
> gescheitert. Nichtmal eine vernünftige Beschreibung der Unit-Files gab
> es, außer auf irgendeinem privaten Blog ein paar Beispiele von "so
> schreibt man ein Unit-File für Software XY".

Erinnert doch irgendwie fatal an udev, oder?