mikrocontroller.net

Forum: PC Hard- und Software systemd-freie Linux


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Sonntagmorgen (Gast)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Auch wenn für das Puls-Audio-Genie
Lennart Poettering die komplette Linux Welt nun mit systemd startet, so 
ist dies wohl nicht die ganze Wahrheit.

Mal von den ( über jeden Zweifel Erhabenen ) BSDs abgesehen, so gibt es 
zb mit OpenRC, runit und S6 einige Linux Distributionen die kein systemd 
brauchen und wollen ( Gentoo, Alpine usw)

Welche Vorteile hat man denn dann?
Macht es Sinn sich damit zu befassen ?
Was meint ihr?

Autor: Gandallf (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nur mal aus Neugier gefragt:
Was spricht für dich gegen systemd?

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: JJ (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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 dann kommen die Extras: Netzwerk übernehmen, ntp neu erfinden, 
syslog in binär nachbauen... da wird einem echt schlecht...

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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ä?

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Sven B. (scummos)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Daniel A. (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
Autor: Sven B. (scummos)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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!

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zudem sollte man bedenken, daß durch Parallelisierung das Starten mit 
systemd schneller geht. Klingt erstmal belanglos, wann bootet man schon 
Linuxserver - die Stoßrichtung von Redhat, die dahinterstehen, geht aber 
in Richtung Cloud-Instanzen. Wenn man die dynamisch nach Bedarf anlegt 
und terminiert, sind schnelle Startzeiten bares Geld.

Autor: Sonntagmorgen (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Sven B. schrieb:

>
> ... Ich finde es bietet einen
> großen Mehrwert, dass das Log-System in systemd integriert ist.
>

Ich halte dies für den größten Blödsinn!

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Nop (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
A. K. schrieb:
> Für mich widerspricht systemd der klassischen Linux-Philosophie: Mach
> nur eine Sache, aber die richtig.

Diese Philosophie ist halt kacke, und endlich kapieren das mal einige 
Leute.

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Arno (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sonntagmorgen schrieb:
> Auch wenn für das Puls-Audio-Genie
> Lennart Poettering die komplette Linux Welt nun mit systemd startet, so
> ist dies wohl nicht die ganze Wahrheit.
>
> Mal von den ( über jeden Zweifel Erhabenen ) BSDs abgesehen, so gibt es
> zb mit OpenRC, runit und S6 einige Linux Distributionen die kein systemd
> brauchen und wollen ( Gentoo, Alpine usw)
>
> Welche Vorteile hat man denn dann?

Man muss sich nicht neu mit einem - zu Beginn, heute mag das anders 
aussehen - mäßig stabilen und mäßig dokumentierten zentralen Stück 
Software beschäftigen. Ich weiß nicht, ob früher alles besser war (tm) 
oder ob ich nur mehr Zeit mit Computern verbracht habe, aber ich habe 
große Probleme mit "wir schreiben da mal drei Blog- und vier 
Foren-Einträge und nennen das Dokumentation" statt vernünftigen 
man-Pages und Howtos. Das gilt für ESP8266-Arduino ebenso wie für 
systemd, beide haben (bzw. für systemd: hatten, den aktuellen Stand 
kenne ich nicht und interessiert mich aktuell auch nicht) dieses 
Problem. Vergleicht nur mal die java-API-Dokumentation mit der 
Arduino-API-Dokumentation, und so ähnlich sah die systemd-Dokumentation 
auch aus.

> Macht es Sinn sich damit zu befassen ?

Wenn du systemd verstanden hast und weißt, wo du die Dokumentation dazu 
findest (oder gar nicht so tief ins System eintauchen willst, dass du 
den Boot-Prozess manipulieren willst) dann nicht (außer aus 
"politischen" Gründen - nicht von einem Stück Software abhängig zu sein)

Ich persönlich nutze nach wie vor seit inzwischen 20 Jahren Slackware 
Linux mit BSD-Style-Init und habe gerade besseres zu tun, als mich 
(nochmal) mit Alternativen zu befassen.

MfG, Arno

Autor: Sonntagmorgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verstehe auch nicht, warum nun plötzlich die bewährten und mit 
dutzenden bekannten Werkzeugen zu bearbeitenden Logfiles „ altmodisch “ 
sein sollen die und durch so einen Müll ersetzt werden mussten

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Sheeva P. (sheevaplug)
Datum:

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

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

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Systemd ist doch die Voraussetzung daß Linux endlich den Desktop 
übernimmt!!11!!1

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael R. (fisa)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DPA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Lieber Kollege, ich widerspreche Dir ungern, aber systemd ist nicht
> ein Werkzeug, sondern eine Vielzahl von Werkzeugen.

Soweit noch richtig.

> 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

Das hatten wir doch schonmal durch. Verzahnung, aka. feste 
Abhängigkeiten, und aufeinander abgestimmt sein, sind zwei vollkommen 
verschiedene und unabhängige Dinge. Es ist keine Änderungen an der 
Bedienung oder Unterteilung der Komponenten nötig, lediglich daran wie 
diese aufeinander aufbauen, um diese voneinander unabhängig zu halten.

> und gegen ein anderes Werkzeug ausgetauscht werden kann,
> solange es Schnittstellen zu den übrigen Teilen abbildet.

Die Schnittstellen müssen aber stabil sein und verschiedene APIs müssen 
in verschiedene Libraries aufgeteilt werden. Insbesondere letzteres ist 
bei Systemd ein Problem. Betrachte z.B. diesen journald shim: 
https://github.com/Daniel-Abrecht/sd_journal_shim
Man kann es zu einer shared library kompilieren. Man kann Programme die 
die journald API verwendeten gegen es linken, oder bei diesen mit 
LD_PRELOAD die library vorladen. Man kann damit aber libsystemd0 nicht 
ersetzen, weil diese noch andere, komplett unabhängige APIs enthält. 
Damit ist es unmöglich, ein Binärpacket für Binärdistributionen wie z.B. 
Debian anzubieten, welches nur Journald ersetzt. Die Komponente ist also 
nicht einfach ersetzbar.

Sheeva P. schrieb:
>> 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?

Dass es die APIs und Komponenten derart ineinander verankert, dass man 
diese eben nicht einfach so ersetzen kann. Dadurch, dass ein Entwickler 
schnell mal dazu verleitet wird, eine Komponente zu nutzen, müssen dann 
alle gleich das ganze Systemd-Packet verwenden, die diese Software 
nutzen wollen. Dieser Lockin ist mien Vorwurf gegen Systemd.

Sheeva P. schrieb:
> 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.

Es müssen nicht unbedingt die Daten sein, und häufig werden auch andere 
Methoden verwendet. Aber das wurde alles schon längst erklärt.

Autor: DPA (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> 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.

Nein, der Lockin ist wegen den Designentscheidungen von Systemd, deshalb 
ist es sehr wohl deren Problem.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arno (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bauform B. schrieb:
> 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.

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".

MfG, Arno

Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Arno (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ja, mit udev hab ich auch eine ganze Weile gekämpft.

Das hat aber wenigstens ein Problem gelöst, das ich tatsächlich hatte.

MfG, Arno

Autor: sonnagabend (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Gerade wenn man möglicherweise das modernste und zukunftsträchtige
Dateisystem ZFS einsetzen will - wären ausserhalb der BSD - Welt die 
Abkömmlinge von Solaris noch eine gute Idee.

Ich nenne mal die Stichworte OmniOS und IllumOS

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.