Boycott Systemd

Status
Für weitere Antworten geschlossen.
-Nuke- schrieb:
219, ja. Aber diese ganzen LTS Distributionen waren nie für ihre aktuelle Software bekannt. Certbot (der offizielle Let's Encrypt Client) musste sogar Python 2.6 Support einbauen, weil CentOS 6 noch bis 2020 unterstützt wird aber nur Python 2.6 mitliefert. Der Rest der Software ist ebenso uralt.

Entsprechend ignoriere ich Software-Rants von Nutzern von LTS Distributionen auch so ziemlich immer. Von mir aus... CentOS, RHLE, Debian Release... alle in einen Sack stecken und draufhauen. Deren Konzept das ganze OS samt sämtlicher Pakete einzufrieren ist einfach nur dumm.
Zum Vergrößern anklicken....
Ich werfe nur mal die Punkte Zertifizierte Systeme und Support in den Raum, von wegen Tellerrand und so ;-)
 
Leider bin ich auch nicht so technik affin, was den Serverbetrieb angeht. Ich habe den Diskurs über systemd und die damit unvermeidlichen Auseinandersetzungen aber dennoch verfolgt. Mein Eindruck war, das es die User gespalten und polarisiert hat.

Mein Denkansatz war:

Cui bono?

Ja wem nutzt es denn nun wirklich und warum hat man dann in Kauf genommen, einen großen Teil der Admins und Nutzer, die sich tagtäglich damit in der Praxis auseinandersetzen müssen, vor den Kopf zu stoßen und zu verprellen?

Der Preis war hoch und gänzlich haben sich die Wellen ja auch noch nicht geglättet.

Es ist doch wie in der Politik, was nutzt ein Gesetz, was eh niemand befolgt...

Allerdings hat außer uns BSD Nutzer ja sonst niemand die Wahl, auf systemd zu verzichten.

Extreme oder Zwänge waren noch nie mein Ding. Wenn schon systemd unvermeidlich war, so hätte ich es gut befunden, wenn es eine sowie als auch Situation gegeben hätte. Also das der Nutzer die Wahl hat, systemd einzusetzen und zu benutzen oder eben nicht.

Jetzt scheint mir der Zug abgefahren zu sein, alle namhaften Linux Distris setzen ja auf systemd, so das es sich jetzt etabliert hat.

Gottlob sind wir ja nicht davon betroffen.
 
ralli schrieb:
Ja wem nutzt es denn nun wirklich und warum hat man dann in Kauf genommen, einen großen Teil der Admins und Nutzer, die sich tagtäglich damit in der Praxis auseinandersetzen müssen, vor den Kopf zu stoßen und zu verprellen?
Zum Vergrößern anklicken....
Die Erfahrung aus meinem Umfeld: die meisten Admins haben mit SystemD keine Probleme, sind eher froh drum, weils so manches einfacher macht. Das sind halt nicht die, die im lautesten im Netz "rumschreien". Ich will damit sagen: nur weil manche laut schreien muss das noch nicht bedeuten, dass man den Großteil der Admins vor den Kopf gestossen hat.

Wenn sogar konservative Distributionen wie Debian Basisdemokratisch entscheiden per default auf SystemD zu gehen, kanns gar nicht so schlimm sein :-)
 
Ein Faktor ist auch, dass in modernen Serverfarmen Stabilität eine untergeordnete Rolle spielt. Es wird davon ausgegangen, dass die Maschinen so oder so regelmäßig wegklappen und der Fall wird zur Norm erklärt und durch Redundanz ausgeglichen. Das geht sogar soweit, dass Netflix seine Systeme mutwillig abschießt, um das Gesamtsystem zu testen.
Systemd überträgt diese Philosophie auf einzelne System (dein Service ist kaputt? Kein Problem, einfach neu starten…), was im obigen Kontext nicht so problematisch ist. Wenn man aber kleine Systeme mit einzelnen Servern hat (nicht jede Firma arbeitet in den Größenordnungen von Netflix, Amazon, Google, …), dann sehe ich da sehr deutliche Probleme mit dieser Einstellung.
 
Man darf bei der ganzen Sache auch eines nicht vergessen: sysvinit war ein riesiger, seit mindestens 15 Jahren überholter Haufen Scheiße. Um es mal deutlich zu sagen. sysvinit fehlten grundlegende Dinge, die in jedem besseren Init-System schon ewig Standard waren. Beispielsweise keine wirkliche Bibliothek, sodass jedes Startscript viel Logik wieder und wieder selbst implementieren musste. Eher schwammige Grenzen zwischen Runlevel, statt einem klar definierten Early-Late-Divider. Dadurch schwer zu erkennen, wann grundlegende System-Dienste verfügbar sind. Und so weiter. Daher war der Druck für eine neue Lösung groß und systemd bot einfach die richtige Mischung aus dem passenden Zeitpunkt, mächtigen Fürsprechern, etc. Die BSDs hatten diesen Druck nicht, da ihre Init-Systeme viele der Probleme des sysvinits schlicht nicht haben.
 
goblin schrieb:
Systemd überträgt diese Philosophie auf einzelne System (dein Service ist kaputt? Kein Problem, einfach neu starten…), was im obigen Kontext nicht so problematisch ist. Wenn man aber kleine Systeme mit einzelnen Servern hat (nicht jede Firma arbeitet in den Größenordnungen von Netflix, Amazon, Google, …), dann sehe ich da sehr deutliche Probleme mit dieser Einstellung.
Zum Vergrößern anklicken....
Das Prinzip des Redeployment nicht vergessen. Die Kiste kommt nicht mehr hoch? Ziehen wir sie halt aus Saltstack, Ansible und ähnlichem neu hoch. Wenn man so denkt, will man seinen Systemstart gar nicht debuggen können. Man braucht auch keine zuverlässigen, lokalen Log-Dateien. Wegwerf-Hosts halt.
 
goblin schrieb:
Systemd überträgt diese Philosophie auf einzelne System (dein Service ist kaputt? Kein Problem, einfach neu starten…)
Zum Vergrößern anklicken....
Was soll systemd denn sonst machen? Es ist nicht die Aufgabe von systemd einen Prozess am laufen zu halten sondern darauf zu reagieren, sollte etwas bestimmtes passiert.
 
marmorkuchen schrieb:
Ich werfe nur mal die Punkte Zertifizierte Systeme und Support in den Raum, von wegen Tellerrand und so ;-)
Zum Vergrößern anklicken....

Das ist kein Grund die gesamte Paketsammlung einzufrieren. Das ist einfach nur dumme Papierkram-Regelung und hat meiner Meinung nach gar keinen Sinn. Schon gar nicht wenn man auch noch an Minor-Versions festklebt obwohl die nächste Minor 0 Breaking Changes hat. Dort wird einfach gesagt. "Joahr 1.8 ist jetzt die Version, 1.9 nehmen wir nicht, weil nach dem Komma eine Zahl größer ist".

Das ist einfach nur dumm... sehr sehr dumm. Und es erhöht bei einem Update nach Ende des Support-Zeitraums der Distribution auch noch immens die Upgrade-Hürden.
 
goblin schrieb:
Ein Faktor ist auch, dass in modernen Serverfarmen Stabilität eine untergeordnete Rolle spielt. Es wird davon ausgegangen, dass die Maschinen so oder so regelmäßig wegklappen und der Fall wird zur Norm erklärt und durch Redundanz ausgeglichen.
Zum Vergrößern anklicken....

Das liegt auch schlicht an der gesteigerten Komplexität. Die Zeiten wo ein einzelner Server alle Daten verarbeiten kann ist vorbei oder eben zu teuer. Und Gründe warum irgend ein Dienst wegsterben kann sind halt so vielfältig, da ist es einfach billiger und einfacher das System redundant und selbstheilend aufzubauen.
 
ralli schrieb:
Allerdings hat außer uns BSD Nutzer ja sonst niemand die Wahl, auf systemd zu verzichten.
Zum Vergrößern anklicken....

Doch, eigentlich alle. Nur die Linuxer halt nicht. :D

-Nuke- schrieb:
Die Zeiten wo ein einzelner Server alle Daten verarbeiten kann ist vorbei oder eben zu teuer.
Zum Vergrößern anklicken....

Je nachdem, was so ein Server tut und wie viele Daten du hast. Ein Mailserver kann auch mal gut abgehangen sein, bei einem Webserver, womöglich noch mit irgendwelchen Interpretern drauf, wäre ich mit ranziger Software schon vorsichtiger.
 
CrimsonKing schrieb:
Doch, eigentlich alle. Nur die Linuxer halt nicht. :D
Zum Vergrößern anklicken....

So überraschend es auch klingt... aber wie schon gesagt wurde... die meisten Linuxer haben auch gar kein Problem mit systemd :D

CrimsonKing schrieb:
Je nachdem, was so ein Server tut und wie viele Daten du hast. Ein Mailserver kann auch mal gut abgehangen sein, bei einem Webserver, womöglich noch mit irgendwelchen Interpretern drauf, wäre ich mit ranziger Software schon vorsichtiger.
Zum Vergrößern anklicken....

Es kommt vermutlich eher auf die nötigen Requests/s an. Die meisten einfachen Web-Server verrecken schon bei 20'000 Requests/s.
 
-Nuke- schrieb:
Das ist kein Grund die gesamte Paketsammlung einzufrieren. Das ist einfach nur dumme Papierkram-Regelung und hat meiner Meinung nach gar keinen Sinn. Schon gar nicht wenn man auch noch an Minor-Versions festklebt obwohl die nächste Minor 0 Breaking Changes hat. Dort wird einfach gesagt. "Joahr 1.8 ist jetzt die Version, 1.9 nehmen wir nicht, weil nach dem Komma eine Zahl größer ist".

Das ist einfach nur dumm... sehr sehr dumm. Und es erhöht bei einem Update nach Ende des Support-Zeitraums der Distribution auch noch immens die Upgrade-Hürden.
Zum Vergrößern anklicken....
Das hilft Dir alles nichts, wenn Du für SAP, Hybris, Oracle und was es sonst da noch alles gibt Support benötigts und halt nur ein zertifizierter Stand unterstützt wird. Da kannste Du wie das Rumpelstielzchen umherhüpfen, die werden Dir was husten :-)
 
Tanne schrieb:
Kannst du mir das bitte ein wenig ausführlicher erläutern?
Zum Vergrößern anklicken....
Mein Hauptpunkt ist die Bibliothek. sysvinit bot in der rohen Fassung kaum zentrale Funktionen, auf die einzelne Startscripte zurückgreifen konnten. Einige Distributionen kochten da zwar eine eigene Suppe drum herum, aber nutzt man die, ist man zu anderen Distros inkompatibel. Das geht schon damit los, dass das Script eine Fallunterscheidung für die Parameter machen muss. Also in etwa so:
Code: 
# See how we were called.
case "$1" in
  start)
  start
  ;; 
  stop)
  stop
  ;; 
  restart)
  restart
  ;; 
  reload|force-reload)
  status exim > /dev/null || exit 7
  echo -n $"Reloading exim:"
  killproc exim -HUP
  echo
  ;; 
  condrestart|try-restart)
  status exim > /dev/null || exit 0
  restart
  ;; 
  status)
  status exim
  ;; 
  *) 
  echo $"Usage: $0 {start|stop|restart|reload|force-reload|status|condrestart|try-restart}"
  exit 2
esac

Im rc (ehemals rcng) von DragonFly, Free- und NetBSD macht das Framework es. Man muss ihm nur das Kommando sagen, was ausgeführt werden soll:
Code: 
command=/usr/local/sbin/exim

Kurz gesagt, was sich bei den BSDs mit einer Hand voll Zeilen erledigen lies, brauchte bei sysvinit nicht selten mittelkomplexe Shell-Scripte. Sollten dann noch die diversen Unterschiede zwischen Distributionen beachtet werden, wurde es schnell eklig. Zumindest ich habe sysvinit dafür gehasst und mir daran unzählige Male die Finger abgebrochen.
 
Es glaub' es gab mal ein Interview mit Bryan Cantrill zu dem Thema Debugging, müsste bsdnow gewesen sein.
Er sprach über den Fehler in Systemd bzgl. assert und Hänger. Danach musste ich überlegen, was ich für ein Typ bin, was ich bevorzuge.

Entweder läuft dein System relativ still, rebootet aber oft neu(man kann ihm aber uU. nicht 100% vertrauen) oder man nimmt Auszeiten in Kauf dafür hat man stets definiertes Verhalten und dann aussteigert wenn assert = false ist. Erste ist offensichtlich Linux/Systemd-Mentalität.

Ich möchte der Software vertrauen, das sie ihren Job tut.
 
Naja, man kann das aber auch alles entspannter sehen, dann lebt es sich einfacher :D Nur weil systemd das Feature hat, zu konfigurieren was bei einem nicht mehr laufenden Dienst zu tun ist, heißt das ja nun nicht dass unter systemd laufend alle Dienste crashen. Dieser Bogen "systemd hat ein Feature was mir nicht gefällt" zu "systemd zwingt mir dieses (optionale) Feature auf" ist halt auch schon relativ ausgeleiert.
 
Aber mal anders gefragt... wenn die BSDs irgendwann mal (und das werden sie vermutlich) ein systemd-Äquivalent rausbringen und benutzen... was dann? Zu FreeDOS wechseln? Oder wäre ein BSD Äquivalent automatisch besser?
 
Naja... die Aussage "es funktioniert" muss nicht unbedingt bedeuten "ist zeitgemäß"... Man kriegt auch mit einem Stein einen Nagel in die Wand. ;)

Aber das war auch gar nicht die Frage, ob man das Verlangen nach einer besseren Dienst-Verwaltung hat oder nicht... die Frage ist... wenn FreeBSD sowas machen würde, würden die jetzigen FreeBSDler auch alle weglaufen? Ich meine systemd wird ja auch schon alleine dafür kritisiert, dass es die Features hat. Es wird ja niemand gezwungen diese zu nutzen, aber das ist bei den Kritikern unerheblich.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben