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?
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.
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...
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ä?
:
Bearbeitet durch User
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
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
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
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!
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.
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!
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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.
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.
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
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
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
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.
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.
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.
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.
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
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?
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.