Boycott Systemd

Status
Für weitere Antworten geschlossen.

Athaba

Libellenliebhaber
Hallo,

ich weiß, der Thread damals war unheimlich lang und ermüdend. Aber deshalb mehr als Heads Up für die Leute, die das Thema interessiert. Es gibt scheinbar immer größeren Widerstand. Ich glaube in dem Thread damals wurde schon extrem viel gesagt und hoffe mal, dass ich keine Wiederholung lostrete, aber ich glaube neuere Entwicklungen zu dem Thema sollten diskutabel sein. Hoffe es nimmt mir dementsprechend niemand zu sehr übel.

http://boycottsystemd.org/

Hacker News dazu: https://news.ycombinator.com/item?id=7639170
 
We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.

Unabhängig davon, was man von systemd hält, dann sollen sie halt ein besseres Projekt starten und sagen "Hier nehmt das" und nicht "nehmt das nicht". Es mangelt einfach an entsprechenden Alternativen. Die bisherigen Alternativen sind entweder genauso ein Mist oder nicht umfassend genug.
 
Das Dumme ist glaube ich, dass eine "Alternative" für systemd ähnlich wie systemd aussehen müsste. Die Leute haben ja mit dem ganzen Prinzip ein Problem, nicht mit der Implementierung.
 
Systemd wird nicht aussterben, es wird sogar noch ausgebaut, und das lustige ist dass alle grossen Distros da mitmachen weil die sofort jede bleedingedge scheisse in ihre systeme integrieren muessen ohne dass es wirklich einen grund gibt ein bereits bestehendes system welches keine probleme bereitet hatte und einfach funktionierte auszutauschen. Die Userbase kreischt, aber grossartig unternehmen tut auch niemand was, es artet nur irgendwann in tausend Forks und anderen neuen kleineren Distros aus, die dann aber genau so qualvoll sterben werden wie fast alle Forkprojekte die aufgrund von antipathie gestartet wurden
 
Das Momentum gegen den Strom zu schwimmen ist doch längst vorbei. Systemd ist Realität, genauso wie die linuxlastigen DE und die Nichttrennung von Kernel Features und Anwendungen.
 
Das Dumme ist glaube ich, dass eine "Alternative" für systemd ähnlich wie systemd aussehen müsste. Die Leute haben ja mit dem ganzen Prinzip ein Problem, nicht mit der Implementierung.

Also wenn ich mir die genannten Probleme anschaue, dann sind das alles eher ein paar Design-Entscheidungen in der Implementierungen bzw. die Entwickler-Mentalität, die da stören.

z.B.:
- binärlogs
- core dumps to journal
- glibc centric
- linux centric

Jeder kann sich hinsetzen und ein ähnlich mächtiges Init-System bauen, was nicht die genannten Probleme hat. Aber solange das nicht existiert ist halt systemd die einzige moderne Alternative. Wie gut oder schlecht sie nun sein mag. Da es aber noch nicht mal eine Alternative zu Pulseaudio geschafft/gereicht hat, wird es mit systemd nicht anders laufen.

Du erwartest ja von Apple oder MS auch nicht, dass deren Software unter Linux oder BSD out-of-the-box läuft. Warum sollte RedHat hier die Ausnahme sein?

Das Leute anfangen hart gegen systemd zu coden, kann man ja nun nicht systemd anlasten.
 
Jeder kann sich hinsetzen und ein ähnlich mächtiges Init-System bauen, was nicht die genannten Probleme hat. Aber solange das nicht existiert ist halt systemd die einzige moderne Alternative

Mich stört, wie hier ohne Hinterfragen angenommen wird, ein "mächtiges" init-System wäre nötig oder förderlich. Das ist doch schon die falsche Prämisse.
 
Ist syystemd überhaupt noch ein Initsystem?
Ich denke das das initsystem nur eine der Aufgaben von systemd ist.
Als weitere Aufgaben kommen da in der aktuellen Planung noch
  • syslog
  • cron
hinzu. Welcher Dienst wird als nächstens integriert?
  • Login (Konsole/*DM)
  • Mailserver, schließlich wollen die Ausgabe von cron verschickt werden
  • cpufreqd, schließlich ist die Bereitstellung der CPU ein Systemdienst
  • to be continued

Was mich an systemd stört ist, dass
  • das KISS-Prinzip fundamental verletzt wird,
  • das Unix-Paradigma one-job-one-tool ignoriert wird (any-job-systemd)
  • und schließlich ein komplexer Daemon alle Aufgaben übernimmt, und so ein geschlossenes System auf Opensource basis gebaut wird
 
Das Dumme ist glaube ich, dass eine "Alternative" für systemd ähnlich wie systemd aussehen müsste. Die Leute haben ja mit dem ganzen Prinzip ein Problem, nicht mit der Implementierung.

Die Alternative wäre Solaris Management Facility. Das Konzept funktioniert seit nun fast Zehn Jahren hervorragend.

Aber der Zug um an Systemd vorbei zu kommen ist abgefahren, sobald der RHEL7 den Markt erreicht und die Kunden von RHEL 4,5,6 auf RHEL 7 migrieren ist der Käse gegessen.
Wenn Systemd im professionellen Betrieb und auch bei den Proprietären Anwendungen nicht für ganz große Schmerzen sorgt, ist die Kuh vom Eis und der Rest kuckt dann in die Röhre.
Die größte Hoffnung die man wohl haben kann ist das Kollege Poetering irgend wann mal die Lust an seinem Baby verliert, Xboxen programmiert und Redhat zum Schluss kommt das der ganze Rotz auf ein gesundes Maß zurück gestutzt wird weil völlig Gaga. Wobei ich mir eben vorstellen kann das es für Redhat ganz geschickt ist, da man eine Art indirekten Vendor Lock erzeugt hat.
 
Falls ihr es noch nicht gelesen habt, das Ding bekommt einen integrierten webserver und eine qr-code library, damit Abstürze am Start in Form einen Qr-Codes übers Netzwerk angezeigt werden können, den ein Schmartphone dann abfotograrfieren kann.
Ich freue mich schon darauf wenn der erste SystemD Virus sich über diese Schnittstelle dann aufs Android-Handy und von dort vweiterverbreitet :zitter:
 
Mich stört, wie hier ohne Hinterfragen angenommen wird, ein "mächtiges" init-System wäre nötig oder förderlich. Das ist doch schon die falsche Prämisse.

Das ist aber der Grundstein dieses Threads, da er auf einer Webseite beruht, die das meint.

Wer meint er bräuchte kein umfangreicheres Init-System, der wird mit keiner der weiteren Entwicklungen je zufrieden sein. Aber "es geht aktuell" oder "ich will mich nicht umgewöhnen" ist keine gute Basis für einen Fortschritt.

Leider werden aber die alten Init-Systeme in Zeiten von Sandboxing, Virtualisierung, Parallelisierung und Co. zunehmend komplizierter und fehleranfälliger. Darum basiert auch kaum noch ein System auf SysVInit und Co.
 
Ich habe einmal gelernt, dass Software mindestens zwei Aspekte hat:
- Den technischen Aspekt
- Den sozialen Aspekt
Sehr viel Kritik an systemd wird hinsichtlich des technischen Aspekts geäußert und sie mag gerechtfertigt sein. Aber ein in meinen Augen größeres Problem ist der oft übersehene soziale Aspekt. Es beginnt damit, wie systemd mit Nutzern vorhandener Init-Systeme und weiteren Entwicklern in anderen Bereichen des Ökosystems umspringt. Es benimmt sich wie ein Elefant im Porzelanladen, schlägt alles vorhandene kaputt und macht sich breit. Egal ob Änderung notwendig und sinnvoll ist oder nicht; so ein Verhalten führt zwangsläufig zu einer ablehnenden Haltung. Wäre ein systemd eine Software, welche in einem Unternehmen eingeführt wird, wäre die Einführung an diesem Punkt bereits gescheitert.
Ein weiterer Punkt ist das Verhalten der Entwickler. Es ist nicht nur Poettering mit seiner charmanten Art, stattdessen die ganze Bande. Diese arrogante Art, mit der jede Kritik abgebügelt und jeder Kritiker als dummer Opa von gestern dargestellt wird. Der Umgang mit Bugs, wo ein simples "Interessiert uns nicht patch es doch selbst, Arschloch!" oft genug die Antwort ist. Wenn auch vielleicht ohne Schimpfwort. Man hat es sogar geschafft, dass Linus mit Commit-Sperre drohte, als man die Bitte den Kernel Ringpuffer nicht totzuspammen wegdiskutieren wollte. Die "Open Source Tea Party" halt, hat per Definition recht. Mit solchen Leuten wollen und können viele andere Personen einfach nicht arbeiten, was u.A. zu frustrierten Boykott-Aufrufen führt.
systemd, ob technisch nun sinnvoll oder nicht, hat im ganzen Open Source Umfeld einiges an Geschirr zerschlagen. Und was wird Konsequenzen haben, wenn auch vielleicht nicht sofort. Frustrierte Admins, die Nicht-Linux-Systeme anschauen. Und seien sie vom sympathischen Weltmarktführer. Entwickler, die sich weniger beteiligen und Patches nicht mehr Upstream schicken. In sich zerstrittene Distros, weil Demokratie nicht zwingend bedeutet, dass die Mehrheit Recht hat und tun kann, was sie für richtig hält. Verlorenes Vertrauen in Red Hat als Zentrum der Linux-Welt, was sich lachend das Spiel angeschaut hat. Und nicht zuletzt diesen Thread.
 
Unter meinem Arch Linux habe ich versucht OpenRC zu installieren, was ich vom Ansatz her gut finde - tut ein Ding und ist menschenlesbar. Das Problem dort ist die Baustelle, dass es 2 Pakete gibt, die sich unterschiedlich verhalten und beide haben nicht zum Start von gdm3 geführt.

EDIT: OpenBSD möchte anscheinend im GSOC 2014 "systemd-like support for ports". Na da bin ich ja mal gespannt...
 
EDIT: OpenBSD möchte anscheinend im GSOC 2014 "systemd-like support for ports". Na da bin ich ja mal gespannt...


Etwas mehr Infos dazu unter http://www.openbsdfoundation.org/gsoc2014.html#systemd:
Project: Provide bsd-licenced, os-agnostic, dbus-api compatible systemd-{hostnamed,timedated,localed,logind} replacements.
Brief explanation: More and more desktop-level applications now depend on apis provided by linux's systemd. We need to have an equivalent to keep up with them.
Expected results: Working & seamless integration of those components as ports.
 
Die Geschichte ist ja gruselig. Ich find es interessant, wie es die Entwickler mit jeder Geschichte über systemd schaffen, noch tiefer zu sinken :)
 
Linux from Scratch ist wohl auch wieder weg von systemd. Wenn ich mich recht entsinn wollen sie (e)udev wieder/weiter nutzen. Auf der lfs-devel mailingliste von Maerz/April/Mai findet man systemd. In einer der Mails stand es. Hat wohl keinen sonderlichen Einfluss, aber vielleicht nett zu wissen. ^^

Gruesse
swaf
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben