Ich weiß garnicht mehr, wie wir auf PG gekommen sind. Hat jetzt nicht viel mit dem init-System zu tun. Ich mache seit mindesten 8.4 PG-Upgrades auf Produktionssystemen und habe glaube ich nur ein zwei mal Versonen übersprungen (9.0). Da mache ich über die Variante mit vollen Dumps. Ich weiß, dass das nicht für alle Anwendungsfälle möglich ist. Allerdings hat es ein paar Vorteile. War schon öfters mal der Fall, dass pg_upgrade auch ein paar andere Probleme hat oder bestimmte Dinge nicht abdeckt und man dann ohnehin Indices neu machen darf und ähnliche Themen. Da ist dumpall sauberer.
Das tue ich sowohl unter BSD, als auch unter Linux (mit und ohne systemd). pg_upgrade ist ein Graus. Da stimme ich zu. Ganz generell. Nachdem ich PostGIS verwende ist das nochmal ein wenig schwieriger. Ich gehe in den meisten Fällen de pg_dumpall-Weg, denn selbst wenn ich sowas wie Spezial-Pakete für pg_upgrade habe muss ich mich noch um postgis kümmern und das ist eine Sache für sich. Beim 9.6er wurde das Ganze etwas verbessert, mit Verzeichnisstrukturänderung. Das fand ich recht gut.
Nachdem ich auch schon auf PGCons war wundert mich die Behauptung, dass PG-Upgrades irgendwo gut sind ziemlich. Das hätte dort sicher jemand erwähnt, dass das Problem gelöst sein. Mein letzter Stand war, dass man sich jetzt daran machen will, pg_upgrade so umzubauen, dass es eben keine zwei Installationen mehr benötigt. Weiß jetzt den genaue Stand dabei aber nicht.
Unter FreeBSD hatte ich tatsächlich weniger Probleme, was aber nicht an einer großen Eigenheit liegt, sondern einfach daran, dass die Pakete da relativ nah an dem was man von PG bekommt liegen und beim Upgrade keine Automatismen sind, die einem dazwischenfunken. Ein anderer Faktor ist, dass die Dinge meist besser planbar sind, weil die PG-Releases (und wieder PostGIS) relativ unabhängig von Distributions-/OS-Releases sind und ich deshalb sagen kann "Anfang November werde ich das Postges/PostGIS-Upgrade fahren.
Aber wie gesagt, das hat jetzt meines Erachtens relativ wenig mit dem init-System zu tun. Korrigiert mich wenn ich falsch liege!
Wenn man die modernen Init-Systeme auf das Featureset von rc.d runterbricht ja. Verstreut man aber leichte Prisen von Sandboxing, Limits und Laufzeit-Infos, und automatisches Neustarten von Diensten, dann erübrigt sich schnell die Diskussion. Aber das war hier schon vor ein paar Seiten das Thema. Es endete in etwa in "ich brauche das nicht, darum bin ich dagegen".
Ja und nein. Erstens finde ich das grundsätzlich nicht schlecht. Allerdings gibt's da zwei kleine Relativierungspunkte. Erstens finde ich da trotzdem Kommandos fllexibler, beim Sandboxing. Und der zweite Punkt und auch die Begründung dazu ist, dass systemd damit potentiell einen längerfristigen Fehler macht, denn solche Dinge ändern sich. Nein ehrlich, derzeit ist ständig eine andere Art zu virtualisieren hipp. Das sieht gerade aus, als würde das zu viel deprecated Zeug mittelfristig führen. Das ist generell der Fall, wenn man alles in Configs gießt. Man erzeugt damit was, was dann irgendwann Turing Complete wird (jetzt mal übertrieben gesagt und weiß es bei anderen Dingen schon passiert ist) und/oder jede Menge Altlasten entwickelt. Wäre cool, wenn das nicht so ist.
Die Diskussion ist meines Erachtens nicht "ob man das braucht oder nicht". Da stimme ich dir voll und ganz zu. Die Frage und das meinte ich mit philosophisch: Sollen die Dinge "bei Convention" sein und das sind sie bei den meisten rc.d Skripten. Die sind sehr, sehr ähnlich aufgebaut oder will man sie hart haben. Und genau solche Dinge sind es ja auch was diverse Flamewars wenn's um Programmiersprachen geht starten. Welche Dinge sollen wie lang und wie explizit sein und ähnliches. Da kannst du in alle Extremen gehen und alle werden einen Hauch unterschiedliche Meinungen haben.
Wenn das alles so objektiv wäre hätten wir weniger Programmiersprachen, Betriebssystem, Linuxdistributionen, Editoren, SQL-Datenbanken, init-Syteme, ... Dann gäb's nur eine Hand voll. Die hätten ein paar klar daefinierte Vor- und Nachteile. Allerdings gibt es davon zig, bis hunderte, die tatsächlich produktiv genutzt werden. Leute und Unternehmen sind damit erfolgreich sind und sich gegenseitig in unterschiedlichster Hinsicht überlegen.
Ich stimme dir ja zu, dass viel zu viel über systemd geflamed wird und ich gestehe auch gerne ein, dass ich da manchmal mitmache bei so Stammtischdiskussionen, aber mal ehrlich, der "What the Fuck" Level ist groß. Da haben die systemd-Leute auch teilweise eingesehen und eingelenkt. Solche Dinge würde ich dann auch nicht mehr argumentieren, außer dass es halt kein gutes Bild macht, insgesamt.
Was du auch angesprochen hast ist, dass man Dinge auswechseln kann - wie gut das geht ist lass ich mal offen und will ich auch wirklich nicht diskutieren. Das ist gut, aber das ist meines Erachtens auch ein Problem bei solchen Diskussionen. Systemd ist ja auch wenn es au mehrere Pakete, Module, ... aufgeteilt ist alles unter einer Fahlen und an jedem Eck gibt's natürlich Kritikpunkte. Da kommt was zusammen. Das wirst du aber auch anderswo haben. Da ist dann mitunter auch die Frage berechtigt, warum man gleich 20 andere Dinge untergeschoben (klingt jetzt negativer als gemeint) bekommen muss. Gerade im Linuxbereich regt das die Leute ja mitunter etwas auf. systemd ist ja mehr ein Toolbelt, als ein Initsystem, aber so halb unter einem Namen.
Und dass es schlechte rc.d-Skripte und gute Skripte gibt, genauso wie Unitfiles will ich ebenfalls nicht bestreiten. Ändert eben trotzdem nichts dran, dass systemd+tools genug Macken hat und nicht perfekt ist. Ich find's eben allein schon deshalb und auf Grund von eh schon erwähnten einfach nicht schlüssig wenn man behauptet, dass systemd objektiv besser als etwaige Alternativen ist. Für gewisse Anwendungsfälle ganz sicher, aber du hast trotzdem deine Vor- und Nachteile und dafür hat systemd anderswo Defizite.
Allein schon ob init und supervisor das selbe System sein soll hat auch schon vor systemd zu Glaubenskriegen geführt.
So wie hier. Wenn rc.d in FreeBSD kritisiert wird, wird man ja auch gleich als inkompetent bezeichnet.
Hast du da ein Beispiel?
rc.d hat mir beim Versuch Apache 2.4+PHP7 zum Laufen zu kriegen auch dauernd gesagt, dass Apache "started" sei... nö.
Habe ich unter Arch Linux auch mit einem Service. Das ist ganz komisch. Gar kein Output und wenn ich entweder nochmal start mache oder restart klappt's. Ich glaube es ist eine Initialisierungssache, aber es ist recht seltsam.
Einen anderen Punkt, den ich hatte (verwende die Software aber nicht mehr) war, dass ich im Zusammenhang mit sd-notify ein Problem hatte. Das war eine Software, die als erstes sd-notify gemacht hat. Mit fork, ziemlich am am Anfang in main. Der Code wurde definitiv aufgerufen, trotzdem hat systemctl ziemlich zufällig dort gehangen. Keine Rückmeldung. Meine meisten negativen Erfahrungen sind Dinge, wo ich keinen Output dazu habe was gerade passiert ist. Das wundert mich deshalb, weil ja systemd eben auch Supervisor sein soll und da ist sowas doch recht kritisch. Ja, rc.d ist kein Supervisor, aber dafür hat rc.d auch noch keines der beiden Probleme.
Wie gesagt, das Spiel kann man ewig betreiben und auch nicht nur zwischen systemd und rc.d.
Bei einer weiteren Sache stimme ich dir auch noch zu: Sachen zu kritisieren mit denen man nicht arbeitet, die man nicht gelernt hat macht die Sache recht fruchtlos. Das ist ein wenig das, was vor allem anfangs von der Community bei systemd so stark kritisiert wurde und auch bei Pulseaudio, dass einfach so wahnsinnig schlecht mit Kritik umgegangen wird.
Von dem was du so schreibst, scheinst du die genau gegenteiligen Erfahrungen gemacht zu haben, aber das sind Dinge, die ich an den BSDs, PostgreSQL und anderen Projekten so stark schätze. Man ist meist sachlich und Lösungsorientiert. Man ist vielleicht nicht übermäßig freundlich (häufig doch), aber recht faktenorientiert. Soll heißen, dass wenn man einen Stuss macht oder Behauptungen aufstellt, für die es keine Beweise oder Hinweise gibt man das direkt gesagt bekommt, aber man Kritik nicht unsachlich abwehrt.
Für rc.d habe ich jetzt noch nicht viel Kritik gesehen. Das hat mich nie wirklich interessiert (ist einfach nicht meine Priorität bzw. eben hinreichend gut - aber auch nicht perfekt), aber dein Beispiel oben was pg_upgrade betrifft. Das wurde nie als "das war schon immer so" oder gute Situation bezeichnet. Da war man sich immer einig, dassdas besser sein könnte und sollte. Vielleicht gab's Diskussionen über Priorität davon, manche meinten, dass das nicht so arg wichtig für sei, aber das war's.
Ein anderes Thema ist dann auch noch, dass man verschiedene Vorstellungen von Modularität haben kann. Unter systemd hat man quasi die Funktionalität von daemon(8) drin unter FreeBSD baut man das ins RC-Script. Ist aufwendiger und explizit. Persönlich finde ich daemon(8) für eine sinnvollere Methode, aber wenn andere, auch auf Grund ihrer wahrscheinlich anderen Erfahrungen systemd's Art bevorzugen dann glaube ich ihnen das auch und halte sie nicht für dumm oder so. Ist aber trotzdem einfach nur ein anderer Weg das zu tun, mit anderen Vor- und Nachteilen und wenn dann so Argumente kommen, wie "Das ist aber die Zukunft, weil daemon ist älter [wurde zeitlich früher programmiert]", dann beginne ich mir schon Sorgen über die Art der Argumentation zu machen. Da wüsste ich selbst bessere/echte Kritikpunkte.
Und
TrueOS ist gerade auf OpenRC umgestiegen - mit dem von Kris Moore verkündeten Ziel, bei Erfolg auch FreeBSD dafür zu gewinnen.
Wow, wusste ich noch gar nicht. Sehr cool!
EDIT: Uff, sorry für die langen Posts. Tu mir echt schwer sie zu kürzen.
EDIT2:
ch hab die Init-Skripte kritisiert weil sie in teils komplett unleserlichem SH geschrieben sind. Im Gegensatz dazu werden Systemd-Init Files als zu eingeschränkt kritisiert.
Ich hoffe du fasst Kritik an systemd nicht als persönlich auf?
Ich wurde als Inkompetent eingestuft "und sollte keine Server betreuen"... natürlich mit zig weiteren Annahmen über mich.
Wo? Ich habe jetzt nach "keine Server betreuen" gesucht, aber nur deine Aussage hier gefunden. Bin mir nicht ganz sicher was du mit den Annahmen über dich meinst.
