Boycott Systemd

Status
Für weitere Antworten geschlossen.
Athaba schrieb:
Der aller größte Teil der Software braucht aber kein Systemd.
Zum Vergrößern anklicken....
Die Frage ist dann was denn systemd für einen Teil der jeweiligen System so interessant macht. Oft ist es ja so das bestimmte Features die nur in einem Teil benötigt werden es erforderlich machen das ganze System zu verändert da das anders nicht zu integrieren ist. Wenn das so ist, wäre eine solche Umstellung zu verstehen.
 
Azazyel schrieb:
Um 2014 hatte der Leidensdruck mit SysVinit auch innerhalb konservativer Distros eine kritische Masse erreicht. Zu diesem Zeitpunkt gab es dann die Möglichkeiten:
  • Man spart sich den Aufwand, bleibt bei SysVinit und lebt mit den großen und immer größer werdenden Schmerzen
  • Man wechselt zu OpenRC/Upstart/daemontools/runit und löst die eine Hälfte der SysVinit-Probleme, während die unlösbare andere Hälfte absehbar immer größere Schmerzen bereiten wird
Zum Vergrößern anklicken....
Was für schmerzen hab ich denn mit OpenRC oder dem "init" System von OpenBSD was durch systemd gelöst wird? Das ist ja etwas was ich öfter lese, aber so aus der Praxis als "Administrator" nun so garnicht nachvollziehen kann.

Ich nutze Privat seit einiger Zeit OpenRC unter Gentoo sowie OpenBSD, und bin damit hoch zurfrieden. Ich konnte alles irgendwie nachvollziehen und generell scheint einfache alles zu klappen.Davor hab ich meist OpenBSD und Archlinux (Pre-Systemd-Zeiten) genutzt mit dem gleichen Ergebniss.

Beruflich habe ich primär mit OpenSuse und Systemd zu tun (ca. 10 Server für ca. 400 user in einer klassischen Office Umgebung) und bin da über einige Fehler oder "merkwürdige verhaltensweisen" gestolpert, und finde auch die Kommandos extrem unintuitiv. Auf einem "Mehrwert" bin ich hier noch nicht gestoßen, mache mir aber extreme sorgen das ich bei größeren Fehlern im zusammenhang mit systemd nicht "schnell" nachvollziehen kann wo es eventuell hapert - etwas das mir selbst unter sysv init noch relativ gut gelungen ist.

SysV init hatte ich auch einige Zeit, und die ganzen Symlinks und so waren echt nicht so der hammer, aber ich fands immer noch etwas leichter nachzuvollziehen als systemd, und das ist im Fehlerfall für mich das wichtigste.

Genau da sehe ich auch ein Init-System: Im Normalfall startets halt die Daemons die ich irgendwie mehr oder weniger einfach irgendwo einstelle, sammelt die wesentlichen log daten von dem was es so macht und kann mir ggf. noch den Status sagen, und das bitte möglichst robust und mit wenig ressourcenverschwendung. Und im Fehlerfall bietet es mir möglichst einfache Optionen nachzuvollziehen ob es irgendwo "hakt".

Das ist doch genau einer der Gründe nicht Windows zu verwenden: Einfachheit und Robustheit und nicht einen "Dienstemanager" der nichts ausser irgendwelche Kryptischen Fehlermeldungen rausschmeißt.
 
Ich sehe es so: systemd war die richtige Lösung zur richtigen Zeit und hatte anders als die Alternativen den Vorteil, dass es einflussreiche Führsprecher hatte. Red Hat als Firma und Lennart Pöttering als sozusagen Hauptentwickler. Dazu kam, dass sich einige andere Projekte, allen voran das ebenfalls hauptsächlich von Red Hat kontrollierte Gnome, früh auf systemd festlegten und damit Fakten schufen.

In dieser Frühphase war systemd auch völlig okay und wäre es bei dem damals Funktionsumfang geblieben, hätte es die ganze Debatte, den Streit und den Aufruf Bitcoins für einen Profikiller zu sammeln nie gegeben. Nur irgendwann begann man halt ohne erkennbaren Plan immer größere Teile der Userland-Dienste zu absorbieren. Das ging los mit journald und die bis heute nicht schlüssig begründete Entscheidung, wieso man Text-Logs durch Binär-Logs ersetzen muss. Das journald massive Probleme mit defekten Logs hatte und noch immer hat, war dann der erste Tropfen auf den langsam heißer werdenden Stein der systemd-Kritiker.
Dann kam das Session-Management, dessen Begründung seinerzeit vor allem daraus bestand, dass Gnome seine Kindprozesse und temporären Dateien nicht im Griff hat und man zentral für Ordnung sorgen müsse. Was dann allen Ernstes dazu führte, dass man einfach von diversen anderen Projekten forderte, doch bitte systemd-Kram zu integrieren. Prominent ist das das zum Beispiel der Fall von tmux. Wer Session Management sagt, muss auch IPC sagen. Also folgte die Sache mit libdbus in PID 1. Das es keine wirklich überragende Idee war, sah man dann irgendwann auch bei den systemd-Entwicklern selbst ein und entfernte libdbus wieder aus PID 1. Das führte über einige Umwege zu der kdbus-Geschichte.

Aber mit all diesen Dingen hatte ich persönlich kein Problem und auch die meisten anderen systemd-Kritiker hätten sicher damit leben können. Überhaupt ging es da vor allem um die Frage, warum jede undurchdachte Idee gleich in HEAD implementiert werden und damit nahezu zwangsläufig an die Distributionen durchgereicht werden muss. Warum keine stabile Branch mit Bugfixes und die mit heißer Nadel gestrickten Neuerungen erstmal woanders? Wieso sich hinstellen und sagen, dass die Distributoren ja Bugfixes selbst backporten können? Nein, bis einschließlich IPC war es vor allem die Teils sehr arrogante und von Oben herab wirkende Art der systemd-Entwickler, die Gemüter erhitzte.

Das eigentliche Problem, weshalb es auch diesen Thread gibt, begann etwa mit Version 209. Denn da begann man einfach haufenweise Funktionionalität in systemd zu integrieren, die dort einfach nicht hineingehört. Zuerst hat man udev absorbiert und damit den de factor einzig brauchbaren Device Manager an system gebunden. Es folgten DHCP, NTP, Cron, Gummiboot, die Idee der Userspace-Konsole... Man bekam den Eindruck, dass systemd nach und nach alle Userland-Dienste integrierte. Oft wieder mit der sehr heißen Nadel gestrickt, zwischen verbuggt und defekt. Und damit explodierte Diskussion, ob das, was dort läuft, sinnvoll ist. Zwar wurde immer wieder das "ihr braucht es ja nicht nutzen!"-Argument gebracht, aber wirklich beruhigend war das nicht. Einerseits, weil Funktionalität einfach alternativlos an systemd gebunden wurde (udev, Gummiboot). Andererseits, weil man einfach Angst hatte, dass es die integrierte Funktionalität bald nicht mehr stand alone geben würde. Und sei es nur, da die systemd-Entwickler keine Rücksicht mehr auf sie nähmen. Dazu kam das Security-Argument. Ja, es sind Module. Aber letztendlich läuft systemd selbst als root, die meisten Dienste als User systemd. Die Dienste kommunizieren über systemds IPC, sie vertrauen sich nahezu vollständig. Also stand bald die Angst im Raum, dass ein Angriff auf einen netzwerkfähigen systemd-Dienst das Potential hat, zum Super-GAU zu werden.

Die systemd-Debatte ist nun ein wenig abgeklungen. Das mag einerseits daran liegen, dass Kritiker resigniert haben. Aber sicher spielt auch mit hinein, dass seit etwa Version 220 kaum noch vorhandene Funktionalität in systemd übernommen wurde und das Qualität eine etwas höhere Priorität bekommen hat. Zudem wurde klar gemacht, unter anderem auch durch Linus himself, wo die Grenzen liegen. Siehe die Geschichte mit dem Kernel Message Buffer und den Block von kdbus. Nur eine gute Software wird systemd dadurch in meinen Augen noch lange nicht. Im Gegenteil. systemd ist durch die Unmengen integrierter, eng zusammenhängender Funktionalität eine massive Verletzung der Prinzipien guten Systemdesigns.
 
TCM schrieb:
Eher das debile Kleinkind von Skynet, was ständig über die eigenen Füße fällt und sabbernd die Windel vollmacht.
Zum Vergrößern anklicken....

Ist aber voellig hinreichend, um nukleare
Sprengkoepfe als "freindly Fire" zu zuenden
bzw. zu detonieren.

:D

Athaba schrieb:
Habe da sicher ein paar größere (von der Nutzerbasis her) Systeme vergessen.
Zum Vergrößern anklicken....

QNX.

Wenn ich mir
vergegenwaertige, so fass ich SystemD als
eine konkrete Bedrohung auf, die versucht
sich als "Pseudostandard" in die Welt der
Eingebetteten Systeme zu etablieren bzw.
zu infiltrieren.

Ist schon gruselig, dass Linaro dieses
ACPI (neben FTD) fuer aarch64 (optional)
integriert haben... aber SystemD und
"Webservices" als "Plumbing-Layer"
setzt dem noch die Krone auf.

Meinen die Entwickler, das was da etwa auf
dieser "Konferenz" postuliert wird etwa ernst?

Wie ist das moeglich, dass Unternehmen und
Organisationen, die profesionelle Entwickler
sowie Informatiker beschaeftigen, diesen
"Schrott" bzw. SystemD (bald bus1) meinen
ernsthaft in ihre "Produkte" und Systeme zu
integrieren, die dazu "mission critical" sind?

Haben die ihren Verstand aufgegeben?

Wurden die von den Borg assimiliert?

Mir deucht es als ob sich die "Industrie"
in eine Operating System Crisis verenne?

Mir macht diese Entwicklung bzgl. SystemD angst,
da mir das Kopfkino bzgl. moeglicher Stoerfaelle
auf kritischen Systemen mich gruselt.
 
CrimsonKing schrieb:
https://twitter.com/docsmooth/status/800639999364448256:D
Zum Vergrößern anklicken....

@CrimsonKing sieh es doch mal so: So etwas bietet ganz neue Berufsmöglichkeiten, Dienstleistungen rund um systemd, d.h., jedes Unternehmen, was ein systemd-basiertes System nutzt, muss als Diensstleistung zukünftig eine Systemd-Wartung aus dem Laden RedHat mit einkaufen, um noch einigermaßen klar kommen zu können mit diesem monströsen Stück Software :D

Das erinnert mich an das sehr erfolgreiche SAP, die machen das doch ähnlich, kauft man ein SAP-Produkt, kauft man auch gleich eine SAP-Betreung aus dem Hause SAP mit ein (ist dort, wo ich arbeite, auch so).

Im Vergleich zu systemd stehen SAP-Produkte wohl nicht unter einer freien Lizenz. Aber hier hilft auch nicht, dass systemd als freie quelloffene Software unter der GPL steht, weil sich systemd umgekehrt proportional zur Unix-Philosophie verhält: Während letztere sich dadurch auszeichnet, mit einfachen Mitteln Komplexes schrittweise zu lössen, zeichnet sich systemd dadurch aus, dass selbst die banalsten Dinge mit einem sehr komplizierten Monstrum bewältigt werden müssen, und um dessen Design-Unzulänglichkeiten immer weiterer Krempel herum programmiert wird.

systemd als Arbeitsbeschaffungsmaßnahme von RedHat (also das muss man denen lassen, wenn das so geplant ist, dann haben die ein Gespür dafür, wie man zusätzlich Kohle machen kann).

Viele Grüße,
Holger
 
Welche Version hat systemd in CentOS (219)? Und wo ist die Entwicklung aktuell (231)? Das sind "fast" zwei Jahre Entwicklung und da hat sich viel getan. Was interessiert die systemd Entwickler diese uralt Version?
 
Naja, ist ohnehin nurnoch Bloatware:
LOC:
systemd > 500.000 Zeilen
Linux 4.9 (Dez. 2016) > 22 Millionen
Debian (2009) > 324 Millionen

Hat hierzu jemand eine Vergleichsliste mit Free-, Net- und OpenBSD, google spuckt mir leider nichts zufriedenstellendes aus.
 
foxit schrieb:
Welche Version hat systemd in CentOS (219)?
Zum Vergrößern anklicken....

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.
 
CrimsonKing schrieb:
^ Warum ich Pythonscripts nicht traue, Teil 761.
Zum Vergrößern anklicken....

Betrifft halt so ziemlich alle Programmiersprachen. Der Supportzeitraum ist dort teilweise länger als entsprechende Anwendungssoftware bereit ist diese Sprachversion zu unterstützen. Versuch mal ne Rails 5 Anwendung auf CentOS 6 auszurollen xD

Aber gut... wenn man wegen mieser Standard-Optionen PKG nicht direkt nutzen kann, ist die Nutzung von Python 3 unter FreeBSD auch recht schwierig.
 
lme schrieb:
Schlimm finde ich ja den Workaround mit "--force --force" :ugly:
Zum Vergrößern anklicken....
Das ist die programmatische Methode von fest dagegen treten. Hätte ich sogar schon mal gebraucht.

Mein Vater hat ein aktuelles OpenSuSE - mit KDE3 übrigens, weshalb ich immer mal wieder in Kontakt damit bin. Die Herausforderung was mit funktionierendem KDE3 und ohne Systemd zu finden ist nicht ganz ohne. Rein theoretisch ja OpenBSD, aber auch wenn's da ein Package gäbe weiß ich nicht wie gut das klappen würde. Wenn ich mal Zeit habe probiere ich das aber aus. :)
 
holgerw schrieb:
ich hatte mal MX-Linux mit trinity installiert, da hat man ein System ohne systemd samt kde3.
Zum Vergrößern anklicken....
Sehe ich gerade nicht. Dürfte XFCE sein? Auch unter auf der Trinity finde ich nicht viel. FreeBSD-Support ist work in progress (langsam).

mogbo schrieb:
ftp://ftp.hostserver.de/pub/OpenBSD/6.0/packages/amd64

Hab KDE nie getestet, scheint aber alles an Packages vorhanden zu sein.
Zum Vergrößern anklicken....

Ja, darum habe ich OpenBSD erwähnt. Ich habe mich vor einer Weile kurz damit gespielt, aber nicht genug um groß Aussagen machen zu können. Hatte einige Macken. Ich nehme eben an, dass auch wenn es mit Trinity und so Potential gibt/gab, dass da nicht mehr genug Interesse gibt, das kompatibel zu halten.
 
Athaba schrieb:
Sehe ich gerade nicht. Dürfte XFCE sein? Auch unter auf der Trinity finde ich nicht viel. FreeBSD-Support ist work in progress (langsam).
Zum Vergrößern anklicken....
Hallo,

da war ich etwas knapp, sorry:
MX-Linux (basiert auf Debian, allerdings ohne systemd) kommt standardmäßig mit xfce4, dort fügst Du nach dem Aufsetzen die Debian-Quelle für trinity hinzu und dann hast Du es.

Viele Grüße,
Holger
 
Das mit dem abstürzenden systemd, so dass dann das sauberere Linux herunterfahren verhindert wird, das kenne ich schon länger. Dachte aber, dies wäre eher ein Einzelfall. Was ich aber noch nicht kannte war quasi diese Meister Yoda Nummer: "--force --force". Ein Dankeschön ausrichten lässt Luke Skywalker. :)
 
Schön finde ich immer auch, wenn systemd anfängt das System herunterzufahren und auf halbem Weg im Deadlock hängen bleibt. Dann hilft nur noch der Reset-Knopf, weil man nicht mehr auf eine Shell zurückkommt. Das ist in den letzten Versionen aber zumindest tendenziell seltener geworden.
 
Yamagi schrieb:
Schön finde ich immer auch, wenn systemd anfängt das System herunterzufahren und auf halbem Weg im Deadlock hängen bleibt. Dann hilft nur noch der Reset-Knopf, weil man nicht mehr auf eine Shell zurückkommt. Das ist in den letzten Versionen aber zumindest tendenziell seltener geworden.
Zum Vergrößern anklicken....

Ja, das kenn ich auch gerade bei unseren OpenSuse kisten schon fast die Regel (Bzw. der "Virtuelle" Reset-Knopf, sind immer nur die VMs die sich da aufhängen, der Host auch mit OpenSuse / System D nicht)
 
pillow schrieb:
Hallo

ich habe nicht alle Beiträge durchgelesen vllt. hat es schon jmd. erwähnt,
hier sprich der Initiator des Projekts, Lennart Poettering fast 3h über diese geliebte Thema:)
http://cre.fm/cre209-das-linux-system#t=20:33.867
servus
Zum Vergrößern anklicken....
Hatte mir den Podcast vor einigen Monaten angehört und fand ihn durchaus interessant - insofern, als dass mir klarer wurde, wie Lennart tickt und weshalb systemd gewisse Eigenschaften aufweist. Für mich kam nämlich im Podcast raus, dass Lennart schlicht keine Ahnung von Server-Betrieb und Administration hat und gleichzeitig leider auch keinerlei Verständnis für die dort abweichenden Anforderungen zeigt. Er scheint eine ausschließlich Desktop-zentrierte Sicht zu haben - was ja erst mal OK ist, aber aus meiner Sicht in Verbindung mit ignoranten Entscheidungen von Distributionen und dem damit verbundenen Pushen von systemd massiv eine Entwicklung von Linux als Ökosystem vorangetrieben hat: Die voranschreitende Untauglichkeit als Server-Plattform durch Bloat...

Ich hätte es sinnvoll gefunden, wenn sich Distributionen im Zuge des systemd-Hypes (aber vor der allgemeinen Einverleibung in sämtliche Distributionen) klar positioniert hätten a la "wir fokussieren uns auf Server, also brauchen wir deterministisches Verhalten von Prozessen mit Fail-Safe und pfeifen dafür auf schnelles Booten" (Beispiel, nicht abschließend) vs. "wir zielen auf den (mobilen) Desktop und wollen, dass das System maximal dynamisch mit veränderlichen Gegebenheiten klarkommt (Netzwerk, Hardware, etc.)" (Beispiel, nicht abschließend). Für den ersten Einsatzzweck scheint mir systemd völlig ungeeignet, für den zweiten aber durchaus angemessen.

Das ist meine persönliche Sicht, die zugegebenermaßen sicher dadurch beeinflusst ist, dass mein IT-Fokus sowohl privat als auch beruflich klar auf Servern und nicht auf Clients liegt. Mich interessiert z.B. Linux auf Clients überhaupt nicht (FreeBSD übrigens auch nicht), ich ärgere mich aber beruflich im Server-Umfeld immer wieder über gewisse Design-Entscheidungen im Linux-Gesamtsystem wie z.B. systemd und damit verbundene Dinge wie journald. Privat lässt mich aber die Entwicklung kalt, da ich glücklich bin, vor einigen Jahren vollständig auf FreeBSD-Server umgestiegen zu sein.

Gruß
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben