systemd, der nächste Horror für BSD?

[Azazyel]

Vox populi:

Rc-Scripts bringen mit auf meinem sonst superaktuellen System keinen Nachteil und systemd, keinen Vorteil.

"[...] steht fest, daß ALLE, wirklich alle Distributionen weg sind oder weg wollen von SysV, also müssen die Gründe wohl schwerwiegend genug für die Distris gewesen sein."

Warum ist das nicht mehr adäquat?

• "Modern systems' processes, especially on modern desktop and laptop systems, need to start and stop in an event-driven fashion, rather than in a predictable time sequence, e.g. triggered by plugging in or removing hot-swappable hardware, availability or unreachability of network filesystems, firmware initialisation, negotiation with WAPs, receipt of IP addresses from networks, login sequences. Attempting to make all this happen in a predetermined order keeps startup slow, prevents parallel startup, and creates problems. [...]
  SystemVInit's lack of facilities to make sure that services remain running is also a particularly grievous lack."
• "It's unreliable. A shell script cannot kill every sub-process that a daemon may create. [...]
  Lastly, init doesn't automatically manage services. Sure it can start them once and stop them at shutdown (or runlevel change). However, if a service dies at some random point, init has no mechanism to automatically restart the service."
• "Öh, der Witz bei der Dienstüberwachung ist, dass man erstmal mitkriegt das was nicht stimmt *bevor* der Kunde anruft. Wenn [man] das nicht integriert startet z.B. monit/wasauchimmer den Dienst während dem Deployment neu (obwohl er am Anfang über sysVinit gestoppt wurde). Das Deployment will am Ende den Dienst wieder starten, der läuft aber schon wieder -> Peng rc !== 0 -> fail! Ein elendes Gebastel die beiden Systeme abzustimmen."
• "Du magst also weiterhin manuell Dienste im Hintergrund starten, die PID manuell in einem PID File speichern, beim Stoppen die PID von dort wieder lesen, versuchen den Prozess zu killen, Fehlermeldungen anständig verstecken, falls der Dienst schon gar nicht mehr läuft, manuell beim starten prüfen ob der Dienst bereits läuft, manuell einen Restart implementieren und so weiter."
• "Mein Liebling ist ja mysql. Ein frickeliges Initscript mit for-Schleifen mit sleep drin, irgendwelchen alive-Checks, und am Ende startet das nur einen weiteren Scriptverhau (/usr/bin/mysqld_safe), der nochmal eine Art Dienstüberwachung in ein paar hundert Zeilen Shell implementiert. Ganz großes Tennis!
  Aber dank der Sysvinit-Experten hier wissen wir ja nun, dass das alles total zuverlässig, ist, dem KISS-Paradigma entspricht und sowieso alles der UNIX-Philosophie treu bleibt."

Außerdem kommt das irgendwie zu einem komischen Zeitpunkt. SSD machen vieles schneller.

"Myth: systemd ist about speed. Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right."

Die Fakten sind jetzt geschaffen, über kurz oder lang werden wirklich alle Distros zu systemd gehen. Linux wollte mal sein wie UNIX, hat sich aber vor langer Zeit schon davon verabschiedet und geht jetzt seinen eigenen Weg.

"Linux arbeitet hier in einer guten Tradition: Unix-"Standards" sind genau wie Internet-Standards schon immer durch Rough Consensus And Running Code zementiert worden. Und nicht von Posix- und IEEE-Gremien im Herstellerfingerhakeln definiert, auch wenn einem dieser Gedanke bei der Lektüre mancher ererbter Dokumentation aus den schlimmen 80er Jahren kommen mag."

 

[nakal]

Nochmal.. mir ist egal, ob Linux-Distris systemd wollen. Ich habe ja die Freiheit, diese nicht zu wählen. Problematisch wird, wenn mir die Freiheit genommen wird, durch solche pseudoproprietären Lösungen wie systemd, gewöhnliche Software auf gewöhnlichen Systemen zu installieren.

1) "Moderne Systeme" haben ein devd und devfs, welche Geräte automatisch einbinden. Das ganze ist Event- und regelbasiert und ich kann mich nicht daran erinnern, dass es da Probleme gegeben hat.
2) Es ist auch nicht wünschenswert, alle Prozesse zu killen, die ein Daemon startet. Wieso soll man das wollen? Dann braucht man auch kein Service anzubieten, wenn Tasks mitten im Service abbrechen. Automatische Restarts? LOL... da haben wir gerade drüber gelacht.
3) Wenn man beim Deployment einen Daemon neu starten muss, ist der Daemon kaputt. Ein Daemon wird nicht gekillt, es sei denn, man installiert eine komplett neue Software. Sonst unterhält man sich mit dem Daemon über Signale und fordert ihn auf, eine neue Konfiguration zu laden, ohne die gespawnten Prozesse zu stören, sonst hat man eine Downtime!
4) Manuell Dienste im Hintergrund starten/stoppen/fortführen? Ist das unter Linux so üblich? Jetzt verstehe ich allmählich woher der Begriff "Linux-Frickler" kommt.
5) MySQL ist kein typischer Daemon, sondern erstmal ein Server. Da ist viel selbst gestrickt, womit ich mich noch nie beschäftigen musste. Ich habe auch noch nie erlebt, dass es damit Probleme gegeben hätte.

Ob 900ms oder 4s (bei mir unoptimiert auf FreeBSD) spielt, meiner Ansicht nach, keine Rolle. Wichtiger ist die komplette Startzeit bis die Basisanwendungen (Web-Browser, Mail-Client etc) nach dem Einloggen alle da sind und die Platte anschließend komplett idle ist. Ab diesem Zeitpunkt erst kann man vernünftig arbeiten. "Doing things right" klingt nach Consulting-Gequatsche. Er sollte man vergleichen wie schnell init-basiertes System auf Linux und auf FreeBSD, gemittelte Laufzeiten, läuft und dann das gleiche mit systemd machen.

Linux-Distris sind erstmal ein Wildwuchs von Sachen, die zu einem nicht unerheblichen Teil fehlgeschlagen sind. Hätten die Leute da einen Konsensus angestrebt, der allgemeine Interessen abdeckt, dann würde jeder von uns 5-10 Jahre weiter sein.

 

[Athaba]

Vox populi:

"[...] steht fest, daß ALLE, wirklich alle Distributionen weg sind oder weg wollen von SysV, also müssen die Gründe wohl schwerwiegend genug für die Distris gewesen sein."

"Myth: systemd ist about speed. Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right."

Einziges Problem ist, dass sie bisher aus meiner Sicht vollkommen unfähig waren mir einen konkreten Grund zu nennen. Sie haben ganz am Anfang Speed gesagt. Dann sind so umgeschwankt auf "Wir sind moderner" mit absolut null konkreten Vorteilen.

Was ist das bitte für eine Argumentation, wenn man ständig sagt, dass man Sachen richtig besser macht und nicht einen einzelnen Vorteil nennen. Der Grund warum das in der FAQ ist, ist weil sie es am Anfang ständig als Killerfeature genannt haben und diverse Distributionen sind scheinbar mangels Wissen da drauf aufgesprungen. Dann sind sie draufgekommen, dass das vielleicht nicht so zieht und auf einmal waren sie einfach besser.

Außerdem steht vor allem Fest, dass in den letzten Jahren, vielleicht Jahrzehnten zu so viel Widerstand und Forks geführt hat wie Systemd - bis rauf zu Linus, der ja sicher ganz wenig Ahnung hat. Konkurriert locker mit der Übernahme von Sun durch Oracle in dem Bereich.

Vox populi:

• "Modern systems' processes, especially on modern desktop and laptop systems, need to start and stop in an event-driven fashion, rather than in a predictable time sequence, e.g. triggered by plugging in or removing hot-swappable hardware, availability or unreachability of network filesystems, firmware initialisation, negotiation with WAPs, receipt of IP addresses from networks, login sequences. Attempting to make all this happen in a predetermined order keeps startup slow, prevents parallel startup, and creates problems. [...]

[/quote]

Hä? Even Driven heißt ich warte auf ein Event (zum Beispiel ein startendes Service, Internetverbindung oder neue Hardware) und tu dann was. Hat prima unter allen OSs (und glaub mir, ich habe viele gesehen) funtkioniert. Funktioniert wunderbar unter sowohl Linux als auch BSD, komplett ohne Linux, auch einigermaßen portabel. Gibt Unmengen an Software, die darauf reagieren, dass du den Netzstecker ziehst, neue IPs bekommst, User sich einloggen, whatever. Scheint nicht wirklich so die große Herausforderung sein, auch nicht für Sofware, die auf mehr als einem OS läuft. Aber systemd kann das jetzt auch in einer nicht portablen Lösung. Welch ein Fortschritt. Erinnert mich an ein Projekt, dass es als fortschrittlich ansah kein /usr/bin/env für seine Shebangs zu verwenden und damit quasi nur unter Ubuntu zu laufen.

• SystemVInit's lack of facilities to make sure that services remain running is also a particularly grievous lack."

Noch ein Problem von dem ich noch nicht gehört habe. Im primitivsten Fall ein while true. Ansonsten ein Wrapper. Warum dieser Wrapper nun unportabel und ein monolith sein soll, der unbedingt das ganze System dominieren will erschließt sich mir nicht.

• "It's unreliable. A shell script cannot kill every sub-process that a daemon may create. [...]
  Lastly, init doesn't automatically manage services. Sure it can start them once and stop them at shutdown (or runlevel change). However, if a service dies at some random point, init has no mechanism to automatically restart the service."

kill -9 und while true? Pid Files, alles bewärt, portabel und extrem flexibel. Wieder die primitivsten Ansätze. Der Vorteil ist aber, dass du eben flexibel bist.

• "Öh, der Witz bei der Dienstüberwachung ist, dass man erstmal mitkriegt das was nicht stimmt *bevor* der Kunde anruft. Wenn [man] das nicht integriert startet z.B. monit/wasauchimmer den Dienst während dem Deployment neu (obwohl er am Anfang über sysVinit gestoppt wurde). Das Deployment will am Ende den Dienst wieder starten, der läuft aber schon wieder -> Peng rc !== 0 -> fail! Ein elendes Gebastel die beiden Systeme abzustimmen."

Ewiges Basteln? Ist ein relativ leicht zu lösendes Problem und die Lösung ist dann sowohl generisch, als auch portabel. Ja, ich habe auch schon Systeme gesehen, wo es sowas gab. Zum einen hat es keine Auswirkungen - also derartiges Neustarten ist sowieso ein übler Hack und das auf Dauer so zu machen und blind Systeme neu zu starten klingt nicht gerade nach einem Plan. Je nachdem was es für ein System ist kann das ein ganz böses Erwachen gehe,

• "Du magst also weiterhin manuell Dienste im Hintergrund starten, die PID manuell in einem PID File speichern, beim Stoppen die PID von dort wieder lesen, versuchen den Prozess zu killen, Fehlermeldungen anständig verstecken, falls der Dienst schon gar nicht mehr läuft, manuell beim starten prüfen ob der Dienst bereits läuft, manuell einen Restart implementieren und so weiter."

Einmal gelöst ist es ein Copy & Paste, super generisch, relativ portabel. Warum muss systemd das nun mit all seinen Nachteilen neu lösen und worin besteht da der Fortschritt?

• "Mein Liebling ist ja mysql. Ein frickeliges Initscript mit for-Schleifen mit sleep drin, irgendwelchen alive-Checks, und am Ende startet das nur einen weiteren Scriptverhau (/usr/bin/mysqld_safe), der nochmal eine Art Dienstüberwachung in ein paar hundert Zeilen Shell implementiert. Ganz großes Tennis!
  Aber dank der Sysvinit-Experten hier wissen wir ja nun, dass das alles total zuverlässig, ist, dem KISS-Paradigma entspricht und sowieso alles der UNIX-Philosophie treu bleibt."

Okay, ich bin kein SysV-System, aber es gibt OpenRC, etc. SysV ist nur ein System und ich kann verstehen, dass sie nicht Happy sind. Finde es nur traurig, dass sie die nächste Fehlentscheidung treffen.

Und ganz generell denke ich, dass der Umstieg so vieler Systeme vor allem ein Marketingerfolg ist. Es gab viele Dinge, die sich rasend verbreitet haben und vielleicht ein Jahr oder zwei überlebt haben. Am Anfang war der schnelle Start das tolle Killerfeature das alle haben wollten und das ist der Grund warum ich mich über das so ausgelassen habe. Man hat dann realisiert, dass es mehr daran hing, dass man jetzt alles optimiert hat und plötzlich beginnt man komplett untechnisch zu werden und kommt mit vollkommen faktenlosen und inhaltsleeren Argumenten und mit "Wir sind halt auch generell besser." und wenn irgendjemand das widerlegt kommt ein "wenn wir wissen was der Grund ist und warum das so ist und wir herausfinden wie wir das lösen, dann werden wir es auch lösen". Ich mein stimmt ja und ich vertrau denen, dass das ihr Ziel ist, aber rein aus den Erfahrungen, die ich gemacht habe schreckt mich das ab. Weil wenn man sowas hört heißt das dann schlussendlich meist, dass man sich auf Grund der Architektur für eine von möglicherweise mehreren Alternativen mit vor und Nachteilen entscheiden muss. Das ist der Grund warum alle so auf KISS und selbst skripten stehen. Man hat kleine elementare Bauteile, die nur Bauteile und keine Lösungen mit vordefinierten Vor- und Nachteilen sind. Das heißt man entscheidet selbst was das Richtige ist. Als Boni hat man gleich dass sich simplere Systeme meist leichter portieren lassen und man kein dickes, komplexes System lernen und durchblicken muss um die eine Kleinigkeit zu machen. All die Logik und ich bin mir sicher, die ist an und für sich gut ausgeklügelt hat immer noch den Nachteil gegenüber einem simplen, wenn du willst dummen System, dass sie schwer zu bedienen und meist recht unflexibel ist.

Das ist der Grund warum die ganzen OS-Heinis, Systemprogrammierer, etc. so auf Simplität stehen. In der Anwendungsentwicklung ist alles ein wenig anders. Da ist simpel oft sehr stark mit dem einen Task definiert. Das Blöde ist, dass ein OS und die Infrastruktur, die nah n ihm dran ist, extrem unterschiedlich genutzt wird und deshalb hat man da viel kleinere Bausteine, die erstmal nach viel Arbeit aussehen, aber wenn man wo hängt einem auch vieles erlauben. Klar, man kann viel Mist machen. Aber das ist wie bei Programmen und Skripten. Man muss das richtige machen und manchmal ist es am einen Hack zu erlauben, vor allem wenn es so ein Teil ist, dass immer abschmirrt und nicht anständig will.

Generell zu dem Ganzen neu starten, PIDs, Logs, etc. Das ist wirklich schon übermäßig und portabel gelöst. Mittlerweile gibt es neben den daemontools, Supervisord (Python) sogar JavaScripts(!) die das Problem lösen. Warum also systemd? Und warum generell eine Lösung die alles macht. Die daraus resultierenden Probleme sind bekannt und der Grund warum es Armeen an Entwicklern gibt, die das KISS-Prinzip über alles stellen.

Ernsthaft, ich würde gerne wissen warum alle drauf umsteigen und vielleicht übersehe ich ja was, aber der einzige Grund, den ich dafür bisher gehört habe war nunmal Geschwindigkeit und wenn das nicht der Grund ist, dann war wohl eigentlich kein Grund da oder ich habe es noch nicht geschafft dahinterzukommen.

Bzw. anders gesagt kenne ich mehr Argumente, die ab und zu gebracht werden. Vor allem in Richtung einfaches Hoplugging und Service Sandboxing. Die Frage die sich da aber stellt ist aber ob die Abwägung gegenüber Dingen wie ein simples System und Unix-Philosophie, die doch in kleine, simple Systeme geht und das aus gutem Grund überwiegt. Dass es nicht portabel und schwer austauschbar ist ist einfach etwas wo die Erfahrung und Geschichte gezeigt hat, dass das zu Systemen führt die scheitern, ewig unfertig sind, etc. Einfach nur weil man sich darin verfängt, dass das System dann stärker auf bestimmte Dinge zugeschnitten sind und alles andere dann nicht funktioniert und Jahrelang ein Known Bug ist, den man irgendwann mal fixen will und bis dahin wohl das ganze System überholt ist.

Also geht das ganze mehr in: Ja, SysV und Co sind vielleicht nicht perfekt, aber sie sind ausgereift, portabel, etc. Systemd ist ganz sicher auch nicht perfekt und du verschiebst damit das Problem nur auf die Punkte die bei den jetzigen Systemen offen sind, reißt aber anderswo neue Löcher auf.

 

[juedan]

Moin,

Vox populi:
"Mein Liebling ist ja mysql. Ein frickeliges Initscript mit for-Schleifen mit sleep drin, irgendwelchen alive-Checks, und am Ende startet das nur einen weiteren Scriptverhau (/usr/bin/mysqld_safe), der nochmal eine Art Dienstüberwachung in ein paar hundert Zeilen Shell implementiert. Ganz großes Tennis!
Aber dank der Sysvinit-Experten hier wissen wir ja nun, dass das alles total zuverlässig, ist, dem KISS-Paradigma entspricht und sowieso alles der UNIX-Philosophie treu bleibt."

Ist das nicht eher ein MySQL-Problem? Wenn der Server beim Starten Schwierigkeiten hat, dass sollten sich die Entwickler um das Problem kümmern, weil doch irgendwas nicht stimmt.

Ich gewinne immer mehr den Eindruck, dass systemd Probleme lösen soll, welche die Entwickler der Daemons nicht gebacken bekommen. Man frickelt mal wieder nur an den Symptomen und nicht am eigentlichen Übel.

 

[grogolz]

Der Zug mit systemd ist abgefahren und PC-BSD mit seinen uralten Desktop-Versionen wird ihn nicht aufhalten. Kann man die für PC-BSD gebundenen Kapazitäten denn nicht sinnvoller einsetzen?

 

[grogolz]

Die sogenannte Unix-Philosophie. Newton sah die Welt anders als Einstein. Was kommt nach systemd?

 

[goblin]

Der Zug mit systemd ist abgefahren und PC-BSD mit seinen uralten Desktop-Versionen wird ihn nicht aufhalten. Kann man die für PC-BSD gebundenen Kapazitäten denn nicht sinnvoller einsetzen?

a) Es geht nicht mehr um den Desktop. Der ist aufgrund GNOME/freedesktoo.org bereits tot. Jetzt machen sie sich daran, die nächste Ebene drunter anzugreifen, Serverdienste etc. und das betrifft uns definitiv auch.
b) Wieso sollten die Macher von PC-BSD aufhören, ihre Arbeit weiter zu tun? Sie wollen das, höchstwahrscheinlich nicht zuletzt, weil es ihnen Spaß macht. Wir sind hier nicht die GNOME-Foundation, wo das Branding wichtiger ist als die Nutzer, wo sie sich aufführen als wären sie ein Konzern der Marktanteile erobern muss.
Das Problem liegt nicht auf unserer Seite, wir machen hier nichts falsch. Das Problem ist diese virale Verbreitung von systemd und die dadurch entstehende Unportabilität von Drittsoftware. Das ist aber nichts, was wir ändern können, weder die Drittsoftware noch systemd. Das einzige wäre, durch Argumente die Verbreitung einzudämmen, aber dafür ist es auch zu spät. Ähnlich wie bei PulseAudio hat sich hier das Stockholm-Syndrom durchgesetzt, alle haben kaputte Systeme, aber sie lieben sie dennoch.
Und ganz ehrlich: Das Desktop-Erlebnis ist unter Linux auch nicht so richtig prickelnd, ich finde die meisten Desktops dort noch deutlich instabiler als unter BSD.

Die sogenannte Unix-Philosophie. Newton sah die Welt anders als Einstein. Was kommt nach systemd?

Das kann man nur ahnen, höchstwahrscheinlich bald wieder was neues, wenn Lennart und Kai die Sache langweilig geworden ist. Zumindest Lennart hat sich nicht gerade einen Namen gemacht, Verantwortung für seine Kreationen zu übernehmen und diese dann auch zu warten.
Aber das ist auch für uns nicht mehr wirklich wichtig, glaube ich. Durch systemd werden die Systeme auseinanderdriften, wenn sie in 3 Jahren systemd zum Teufel jagen und die nächste neue heiße Sau durchs Dorf treiben, dann kann uns das egal sein, dann gibt es die betroffene Software wahrscheinlich nicht mehr für BSD.
Aber jetzt ist das noch nicht so, deswegen habe ich auch jetzt noch Hoffnung, dass nicht alle Projekte systemd Abhängigkeiten einführen.

 

[Athaba]

Hä? Es gibt über 2000 PC-BSD-Maschinen. Du magst zwar keiner davon sein, aber definiere mal Kapazitäten sinnvoll einsetzen. Man geht ja auch nicht rum und sagt den Leuten mit Videospielen, TV und Co, ob sie ihre Zeit nicht sinnvoller verwenden könnten. Was sinnvoll ist ist (kritisch-rational gesehen) vollkommen subjektiv.

 

[grogolz]

Hä? Es gibt über 2000 PC-BSD-Maschinen. Du magst zwar keiner davon sein, aber definiere mal Kapazitäten sinnvoll einsetzen. Man geht ja auch nicht rum und sagt den Leuten mit Videospielen, TV und Co, ob sie ihre Zeit nicht sinnvoller verwenden könnten. Was sinnvoll ist ist (kritisch-rational gesehen) vollkommen subjektiv.

In der Tat habe ich mir PC-BSD schon angetan. Es war der pure Frust. Anspruch und Wirklichkeit klaffen weit auseinander. Zuletzt bootete eine frische Installation (war so ein 9.x) auf nackter Platte nicht. Da nehme ich lieber ein Manjaro Linux inclusive systemd und habe keinen Streß.

 

[grogolz]

FreeNAS könnte Entwickler von PC-BSD gebrauchen. Die haben genug Probleme. Zumindest solange es die Möglichkeit gibt von XYZ-Linux auf dort laufende Daten/Dienste zuzugreifen. Das wäre aus meiner Sicht ein sinnvoller Einsatz.

Nachtrag:

Man könnte bei PC-BSD auch so tun als wären sie abgeschottet von der "bösen Linuxwelt" und ihre Frickelei (ist halt meinen Meinung nach den Pleiten) weiter anbieten. Ich brauche PC-BSD zum Glück nicht.

 

[Azazyel]

Es ist auch nicht wünschenswert, alle Prozesse zu killen, die ein Daemon startet.

Bitte? Es gibt spezielle Anwendungsfälle (vgl. "apache2ctl graceful"), aber wenn ich einen Daemon explizit stoppe, soll der doch bitteschön komplett stoppen - und nicht irgendwie je nach Wetterlage unkontrollierbar weiterlaufen können.

Wenn man beim Deployment einen Daemon neu starten muss, ist der Daemon kaputt. Ein Daemon wird nicht gekillt, es sei denn, man installiert eine komplett neue Software.

Ich möchte sehen, wie du eine neue Version einer Anwendung, die von einer Datenbank-Änderung abhängt (gerne auch mit einem Migrationsskript, das vor Einspielen der neuen Version laufen muss), ohne Beenden des Daemons hinkriegst. Nicht alle Anwendungsfälle lassen sich on-the-fly abhandeln.

MySQL ist kein typischer Daemon, sondern erstmal ein Server.

Auch das muss ein Init-System können, sonst wird es den Anforderungen nicht gerecht. Ich erwarte ja auch vom Betriebssystem, dass ein "kill -9" einen einzelnen Prozess komplett wegschießt - alles andere wäre ein Fehler.

Da ist viel selbst gestrickt, womit ich mich noch nie beschäftigen musste. Ich habe auch noch nie erlebt, dass es damit Probleme gegeben hätte.

Du meinst, weil du noch nie ein Problem damit hattest, gibt es kein Problem? Was war denn das größte und komplexeste Projekt, an dem du jemals mitgearbeitet hast?

Hätten die Leute da einen Konsensus angestrebt, der allgemeine Interessen abdeckt, dann würde jeder von uns 5-10 Jahre weiter sein.

Definiere "allgemeine Interessen". Unabhängig von den tatsächlichen Vor- und Nachteilen der einzelnen Systeme glaube ich nicht, dass es hier zwischen den beiden Enden des Meinungsspektrums - SysVinit und systemd - einen Kompromiss geben kann.
Mit der Architektur von SysVinit lassen sich prinzipbedingt gewisse Probleme nicht lösen. Mit Monit und Konsorten kann man probieren, das nachzurüsten, landet aber in einer unzuverlässigen, intransparenten Hölle. Das kann man nur fundamental lösen (analog ZFS), lässt damit aber zwangsläufig einen Teil der alten Welt hinter sich. Ich wüsste nicht, wie hier der Mittelweg aussehen könnte, lasse mich aber gerne eines besseren belehren.

Und ganz generell denke ich, dass der Umstieg so vieler Systeme vor allem ein Marketingerfolg ist.

Genau. Die ganzen Maintainer, die systemd in aller Ruhe angeschaut und knapp 3 Jahre systemd-Erfahrung bei Fedora berücksichtigt haben, haben sich gedacht: "Bei dem tollen Marketing stelle ich mal eben meine Distro auf systemd um, ich habe ja sonst gerade nichts zu tun."

 

[xbit]

Ob nun ein Daemon via "kill -HUP" seine Konfiguration neu einliest oder ich den Daemon neu starten muss, ist mir egal. Hauptsache es funktioniert und das Verhalten ist konsistent.

Dienste ueberwachen ist ok. Sowas aehnliches hat das "alte" init mit "respawn" ja auch im Angebot, auch wenn dies anders funktionierte. Wenn systemd Dienste, die instabil laufen, automatisch neu startet, mag das fuer den Nutzer ok sein. Der Dienst ist eben erreichbar. Das Problem liegt aber eigentlich woanders und das wird entweder kaschiert oder muss wieder anders ueberwacht werden (zB nagios, icinga, ...). Zudem verschickt systemd ja keine Mails, dass ein Dienst neu gestartet wurde. Da muss man dann auch wieder mit anderen Tools ran. Insofern glaube ich, dass dort versucht wird, Probleme zu loesen, die man vor Jahren schon geloest hat.

Ich finde viel fragwuerdiger, dass systemd via DBus kommuniziert. Fuer beliebige Daemons ist das vollkommen ok, aber systemd will ein Init sein. Da gehoert fuer mich keine Abhaengigkeit zu einem anderen Systemdienst dazu. Mag systemd nicht mehr mit DBus sprechen, kann ich das System u.U. nicht einmal mehr sauber runterfahren.

 

[darktrym]

Bitte? Es gibt spezielle Anwendungsfälle (vgl. "apache2ctl graceful"), aber wenn ich einen Daemon explizit stoppe, soll der doch bitteschön komplett stoppen - und nicht irgendwie je nach Wetterlage unkontrollierbar weiterlaufen können.


Genau. Die ganzen Maintainer, die systemd in aller Ruhe angeschaut und knapp 3 Jahre systemd-Erfahrung bei Fedora berücksichtigt haben, haben sich gedacht: "Bei dem tollen Marketing stelle ich mal eben meine Distro auf systemd um, ich habe ja sonst gerade nichts zu tun."

Ich kann dir sagen, warum die meisten nun umsteigen, die sehen sich die Perspektiven an und erkennen dass sie auf verlorenen Posten stehen. Selbst Ubuntu kann nicht ewig Teile von systemd als Fork weiterführen. Systemd mag Module besitzen die man ausschalten kann. Die Module selbst sind aber kaum einzeln einsetzbar. Ja praktisch könnte man auch X ohne Grafikbeschleunigung betreiben, weil man auf massives Ruckeln steht. Ist irgendwie bei der VHS, nicht immer gewinnt die bessere Lösung.

 

[kmh]

Seht es doch mal anders, als Chance für das *BSD--Lager einen eigenen auf der BSD-Lizenz aufbauenden zu Systemd komatiblen init-Deamon zu bauen Falls sich die BSD'ler dagegen entscheiden, auch gut.

Ich kann Azayel nur zustimmen, nur weil einige Leute kein Interesse oder keinen Mehrwert in systemd erkennen können oder wollen Heißt dass nicht dass es diesen nicht gibt.

 

[Puppets]

Kann sein das man mit den Jahren eingefahren ist aber warum diese "Zwangsbeglückung". Mag irgendwo ein Schwarzseher sein aber sehe das so kommen : Auf die Knie und bete zu deinen Gott ähm Red Hat.

 

[kmh]

Ja, RedHat hat es entwickelt ... ZFS wurde auch von SUN entwickelt... und?

 

[darktrym]

Red Hat macht hier keiner einen Vorwurf. Eher den Luschen die meinen wartbarbarer Code beginnt damit sich aus der Verantwortung zu stehlen. Gnome sollte das mal fett auf der Startseite schreiben: "Wir sind nicht interessiert, dass Leute außerhalb der Linuxplattform unseren Kram, den nicht nur die Nutzer zwiespältig gegenüberstehen, nutzen".

 

[Azazyel]

Seht es doch mal anders, als Chance für das *BSD--Lager einen eigenen auf der BSD-Lizenz aufbauenden zu Systemd komatiblen init-Deamon zu bauen Falls sich die BSD'ler dagegen entscheiden, auch gut.

Schlimmstenfalls müssten die BSDs die relevanten systemd-APIs implementieren, falls tatsächlich Anwendungen systemd voraussetzen würden und die BSDs nicht auf diese Anwendungen verzichten wollten. Wenn ich mir die systemd-Interfaces anschaue, ist für die BSDs von trivial bis hin zu kaum implementierbaren APIs alles dabei.

Selbst Ubuntu kann nicht ewig Teile von systemd als Fork weiterführen.

Stimmt, Ubuntu wird laut Mark Shuttleworth wohl bald folgen (vgl. heise.de, golem.de): Nevertheless, the decision is for systemd, and given that Ubuntu is quite centrally a member of the Debian family, that’s a decision we support. I will ask members of the Ubuntu community to help to implement this decision efficiently, bringing systemd into both Debian and Ubuntu safely and expeditiously.

 

[Yamagi]

Diese Diskussion bewegt sich nun etwa 10 Seiten in einem endlosen Kreis. Glaubt ihr nicht, dass es sinnvoll wäre hier erst einem einen Schlussstrich zu ziehen, bis es wieder etwas substantielles zu sagen gibt?

 

[nakal]

Bitte? Es gibt spezielle Anwendungsfälle (vgl. "apache2ctl graceful"), aber wenn ich einen Daemon explizit stoppe, soll der doch bitteschön komplett stoppen - und nicht irgendwie je nach Wetterlage unkontrollierbar weiterlaufen können.

Und was schlägst Du vor? Ein kill an Unterprozesse zu senden ist etwa eine gute Idee? Wenn Unterprozesse so programmiert sind, dass sie nicht auf das killen des Parents reagieren, hat das einen guter Grund. Meistens ist das Datenkonsistenz, die hier eine Rolle spielt.

Ich möchte sehen, wie du eine neue Version einer Anwendung, die von einer Datenbank-Änderung abhängt (gerne auch mit einem Migrationsskript, das vor Einspielen der neuen Version laufen muss), ohne Beenden des Daemons hinkriegst. Nicht alle Anwendungsfälle lassen sich on-the-fly abhandeln.

Wir sind hier nicht im Kindergarten. Seit wann muss man eine DB-basierte Anwendung neu starten, wenn die Daten in der DB aktualisiert werden? Kennst Du das Qualitätsmaß namens "Robustheit"?

Auch das muss ein Init-System können, sonst wird es den Anforderungen nicht gerecht. Ich erwarte ja auch vom Betriebssystem, dass ein "kill -9" einen einzelnen Prozess komplett wegschießt - alles andere wäre ein Fehler.

Es ist aber ein Irrglaube, dass man Kindprozesse mitkillen soll. Es hat oft ein Grund, dass man das so programmiert hat. Killst Du bei einem Server mit -9 einen Kindprozess, riskierst Du inkonsistente Daten und dass der Server evtl auch nicht mehr startet nächstes Mal, weil es sich saubererweise über Inkonsistenzen beschwert.

Du meinst, weil du noch nie ein Problem damit hattest, gibt es kein Problem? Was war denn das größte und komplexeste Projekt, an dem du jemals mitgearbeitet hast?

1) Administration hat nur marginal etwas mit Projekten zu tun. 2) Du würdest Dich wundern. Aber diese Frage ist recht privater Natur, deswegen beantworte ich sie nicht.

Definiere "allgemeine Interessen".

Ich habe auf einen Konsens in dieser Sache gehofft. Wenn Leute schon die Probleme, die Linux mit System-V-Init hat gelöst haben, braucht man nur rüberzulinsen und Verbesserungsvorschläge so einbringen, dass alle glücklich sind. Alleingang inklusive Radneuerfinden ist auf alle Fälle nervig (wie man sieht).

Unabhängig von den tatsächlichen Vor- und Nachteilen der einzelnen Systeme glaube ich nicht, dass es hier zwischen den beiden Enden des Meinungsspektrums - SysVinit und systemd - einen Kompromiss geben kann.

Ich habe nie davon geredet, dass die Linux-Distris bei System-V-Init bleiben sollten. Sie sollten nur tolerant sein und sich nicht wie der Nabel der Welt verhalten.

Ich wüsste nicht, wie hier der Mittelweg aussehen könnte, lasse mich aber gerne eines besseren belehren.

Das ist ja auch nicht Deine Sache, es zu wissen. Aber an den Entscheidungen, bei denen ganze Software-Gemeinde von betroffen ist, ist es schon von Vorteil, auch auf alle Rücksicht zu nehmen. Herr Poettering hat aber mit seiner arroganten Art eindeutig zu erkennen gegeben, dass er das feindlich meint mit seinen Änderungen. So kam der Ball überhaupt ins Rollen! Hätte er damals ein wenig diplomatischer gedacht und gehandelt, wäre systemd ganz anders aufgestellt.

 

[darktrym]

Matthias Clasen hat sich zu Gnome und systemd geäußert. Irgendwie hab ich das Gefühl der gute Mann ist ein wenig zu oft gegen eine Glasscheibe gelaufen. Anders kann ich nicht seine Aussagen zu Portabilität verstehen.

Tolles Zitat von Gnome dazu:

It is assumed and encouraged (but not required!) that distributions make use of the following technologies:

• Wayland
  
  
• systemd

Systemd bekommt nun Code für KDBus.

 

[Yamagi]

Und das Ding kann nun auch Netzkarten verwalten: http://heise.de/-2119141

 

[suiyuan]

Kann daß sein, das DBUS längerfristig auch nicht mehr weiterentwickelt wird? In dem Beitrag steht was von

Die neue Version der Sammlung mit Software rund um das Hochfahren von Linux-Systemen unterstützt zudem die Interprozesskommunikation mit Kdbus. Dieser im Systemd-Umfeld vorangetriebene und im Kernel angesiedelte IPC-Mechanismus soll mittelfristig D-Bus ersetzen; auf D-Bus greifen Anwendungen sowie Desktop-Umgebungen wie Gnome und KDE derzeit zumeist zurück, um Nachrichten zwischen Prozessen auszutauschen.

 

[q000te]

Na das wird doch nicht GNU/SystemD werden...

Das kennt Ihr wahrscheinlich schon: "The Six Stages of systemd"

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

 

[bsd4me]

Diese Diskussion bewegt sich nun etwa 10 Seiten in einem endlosen Kreis. Glaubt ihr nicht, dass es sinnvoll wäre hier erst einem einen Schlussstrich zu ziehen, bis es wieder etwas substantielles zu sagen gibt?

Sehe ich auch so...

Aber ich fände es generell nicht schlecht, wenn Zugriffe auf temporäre Festplatten, Tastaturen etc. konsistent und sicher zu handeln wären. Ist ja auch schon um Lngen besser, als noch vor Jahren. Wenn man das mit der "traditionellen" Philosophie von Unix vereinbaren könnte, wäre es klasse... Bisher hat mir FreeBSD immer um Längen besser gefallen als Linux...

Was PC-BSD angeht, die habe ich als Version 9.2 mal über Monate auf meinem Laptop Lenovo R61 genutzt. Lief anständig :-) Bis auf den Hibernation Knopf Fn links unten, den ich sowieso nicht nutze.

Also dann auf system-adeeee, Norbert ;-)