Boycott Systemd

Status
Für weitere Antworten geschlossen.
Ich war auch kurz davor Mitleid mit Lennart zu haben, weil die Leute mittlerweile nicht mehr konkret technisch argumentieren, sondern bei Lennart sehr unfein persönlich werden. So etwas befürworte ich nicht, dass man den Boden unter den Füßen komplett verliert. Aber dann... lese ich wieder sowas: "Lennart beschuldigt Linus für die Effekte der Ablehnung in der Linux-Gemeinde": http://www.itwire.com/opinion-and-a...nterest-in-poetterings-problems-says-torvalds
 
Ich bin vorgestern an einer Debian (testing) Installation gescheitert. Debian-Installer meinte, er hat keinen Kernel für meinen amd64-Rechner. Das hat er mir am Ende der Installation gesagt. Ich meine, wenn der Installer einen Kernel hat, der offensichtlich gelaufen ist, wieso hat er diesen nicht genommen?? Ist mir noch nie zuvor passiert... Aber hey... Debian testing ist ja auch schon mit systemd. Vielleicht ist das jetzt auch so, dass man den Kernel im systemd-appstored kaufen muss... wer weiß?

Witzig. So eine systemd Geschichte ist mir vor kurzem mit Debian auch passiert. Beim Update von was weiss ich wievielen Paketen habe ich offensichtlich die Warnung(!) in den paar tausend Zeilen Installationshistorie übersehen. Der Paketmanager hat dabei den sysv Init entfernt um einen Konflikt mit systemd zu lösen (WTF!!!)

Das Ende vom Lied war, dass ich den sysv Init nur mit einem systemd-shim aus Unstable wieder bekommen habe, oder auf einen guten Teil meines Systems hätte verzichten müssen. Hat mich nur ein paar Stunden und viele graue Haare gekostet, nachdem ich den ganzen Schlammassel mangels anderer Alternativen mit dem verbliebenen Kernel und einer Busybox wieder reparieren durfte. Beim Gedanken an einen Bug in einem Binary Init wachsen mir noch mehr graue Haare - keine Chance mehr den Fehler mal kurz zu beheben.
 
<ironie>
Man behebt heute ja auch keiner Fehler mehr, man installiert einfach neu. Es ist schließlich nur ein Knopfdruck eine neue VM zu deployen und dann mit Salt oder ähnlichem die Konfiguration zurückzuspielen.
</ironie>

Im Ernst: Wenn die Konsole erst einmal nicht mehr über den Kernel, sondern über systemd bereitgestellt wird, ist eh Ende. Wenn dann was klemmt, heißt es vom USB-Stick booten. Oder eben neu installieren. Als Debianer ist man da insofern noch auf der helleren Seite, da in Jessie sysvinit definitiv noch bereitstehen wird. Wenn auch nur optional und mit systemd-shim außen rum.
 
<ironie>
Man behebt heute ja auch keiner Fehler mehr, man installiert einfach neu. Es ist schließlich nur ein Knopfdruck eine neue VM zu deployen und dann mit Salt oder ähnlichem die Konfiguration zurückzuspielen.
</ironie>
Wer noch wirkliches Eisen verwendet ist doch auch wirklich selber Schuld… die Zukunft gehört der Virtualisierung!

*SCNR*
 
Virtualisierung ist in vielen Fällen ja wirklich sinnvoll und bietet einige Möglichkeiten. Sie ist nur keine Lösung für Softwareprobleme.
 
Dass debian sich infiltrieren ließ und dann in die falsche Richtung umfiel, hat mich auch angekotzt. Die shim "Lösung" halte ich für rein politisch. Die haben einfach kapiert, dass denen die user in Scharen wegrennen, wenn sie so konfrontativ und beschämend korrupt einfach auf systemd umstellen. Also wurde schnell die shim "Lösung" angeboten. Die Idee dahinter (da habe ich keine Zweifel): Sehr viele user merken eh nix; die klicken einfach auf install und fressen, was immer dann eben serviert wird. Und die anderen kriegen das Gift eben langsam verabreicht und können jetzt erst mal treuherzig glauben, ihr debian sei auch langfristig ohne systemd verfügbar.

Aber dankenswerterweise hat pöttering ja beim Nölen den Hinweis auf die bösen, bösen gentoo'ler gegeben ...
 
Ich bin wirklich auch kein systemd Befürworter aber man muss sagen, dass es bis jetzt eigentlich immer das gemacht hat, was es soll (Server). Dazu habe ich mehrere Server im Testbetrieb unter CentOS 7 und Arch Linux. Seit fast 10 Monaten und keine Probleme.

Nach all den Pro und Contras über systemd würde ich gerne mal wisse, wer alles systemd einsetzt und wirklich behaupten kann: "systemd funktioniert nicht"! Damit meine ich aber nicht eine Virtualbox Installation sondern einen Server oder Desktop der über mehrere Monate in Betrieb war.

Ich glaube nicht, dass viele Linux-Admins wegen systemd nach *BSD umschwenken werden...
 
Sicher wird kaum einer sein System wegen systemd umstellen. Meine Kritik geht gar nicht mal so sehr in Richtung, dass systemd nicht funktioniert, sondern das er einem eine richtige Abhängigkeitshölle verschafft. Das Problem muss dann am Ende nicht mal im systemd selbst stecken um für lange Zeit ein nicht mehr vollständig funktionierendes System zu bekommen. Ein einzelnes Paket/Script ist schnell gefixt. Ein Paket, von dem das halbe System abhängt in der nächsten Version - wenn man Glück hat und nur Mainstream-Pakete nutzt.

Für jedes Problem, das systemd löst, gibt es einfachere und skalierbare Lösungen - falls das Problem im jeweiligen System überhaupt gelöst werden soll.
 
Das entscheidende Kriterium ist nicht, ob eine Kiste lange problemlos läuft mit systemd. Entsprechend ist die Hauptkritik an systemd ja auch, dass man ziemlich gef..t ist, wenn es mal *nicht* geht. DAS ist entscheidend.
Serverleute argumentieren ja auch nicht damit, dass Platte X seit 10 Monaten problemlos läuft und lassen's damit gut sein, sondern sie setzen Raids ein und machen backups. Weil 10 Monate oder auch 5 Jahre "läuft einwandfrei" eben nicht bedeutet "läuft auch morgen noch einwandfrei". Und wenn es mal kracht, dann möchte ich Zugang haben, ein überschaubares System auf gut verstandenen teilen und TEXTlogs.

Und, aber das mögen andere anders sehen oder für weniger wichtig halten, systemd verstößt gröbstens gegen Unix Prinzipien, die nicht grundlos hoch gehalten werden; das z.B., keine feature Moloche zu schaffen, sondern mehrere kleine, überschaubare Spezialisten werkeln zu lassen.

Und nein, bestehende server umzuschwitchen auf BSD wird wohl (zumindest einstweilen) eher die Ausnahme sein. Aber neue server gar nicht erst mit linux Mist zu betreiben wird nun noch attraktiver.

Als überzeugter BSD'ler bedanke ich mich aber bei linux, weil nun noch mehr Profis der Unterschied zwischen einem Unix System und einem Bastellabor klar werden dürfte.
 
Das entscheidende Kriterium ist nicht, ob eine Kiste lange problemlos läuft mit systemd. Entsprechend ist die Hauptkritik an systemd ja auch, dass man ziemlich gef..t ist, wenn es mal *nicht* geht. DAS ist entscheidend.

Naja... Jain... Klar ist die Kritik das Design. Aber die Kritik gewinnt erst Gewicht wenn es wirklich Probleme gibt. Solange alles flutscht und läuft interessiert den Durchschnittsadmin eben nicht ob das Init-System nun ein bescheidenes Design hat oder ein vernünftiges. Im Gegenteil das gefrickelte gefällt ihm vielleicht sogar besser wenn es ihm "Grafiken für den Chef liefert" oder "Den dämlichen Dienst automatisch neu startet, dann kann man da nächste Woche mal danach sehen".
Die meisten Menschen Nutzen und Analysieren nicht. Der selbe Grund warum Cloud-Dienste etc. über die jeder schimpft wenn's um Datenschutz etc. geht so boomen... Unter der Haube interessiert nicht solange es funktioniert und einfach ist.
 
Das entscheidende Kriterium ist nicht, ob eine Kiste lange problemlos läuft mit systemd.
Doch das ist das einzige was mit interessiert! Läuft die Kiste stabil und kann ich einen Fehler gut analysieren? Wenn man eine hohe 3 stellige Serveranzahl administriert, kann ein Dienst auch gerne mal von allein neu starten! Ich will einfach einen Auszug, was passiert ist, um dies zu analysieren.

Entsprechend ist die Hauptkritik an systemd ja auch, dass man ziemlich gef..t ist, wenn es mal *nicht* geht. DAS ist entscheidend.
Begründung? Mit den systemd Tools kann man auch eine gründliche Analyse machen.

Und, aber das mögen andere anders sehen oder für weniger wichtig halten, systemd verstößt gröbstens gegen Unix Prinzipien, die nicht grundlos hoch gehalten werden; das z.B., keine feature Moloche zu schaffen, sondern mehrere kleine, überschaubare Spezialisten werkeln zu lassen.
Und ein Trabbie ist immer noch das beste Auto auf der Welt! Alles entwickelt sich weiter warum nicht auch die Unix Prinzipien? Willst du in 60 Jahren immer noch darauf schwören?

Als überzeugter BSD'ler bedanke ich mich aber bei linux, weil nun noch mehr Profis der Unterschied zwischen einem Unix System und einem Bastellabor klar werden dürfte.
Da kann ich dir nur zustimmen.
 
Und ein Trabbie ist immer noch das beste Auto auf der Welt! Alles entwickelt sich weiter warum nicht auch die Unix Prinzipien? Willst du in 60 Jahren immer noch darauf schwören?

Da möchte ich auch mal zustimmen. Ich bin nun bei Leibe kein systemd-Fan (habe damit aber zum Glück auch noch nicht viel Berührung gehabt), aber ich stelle mir auch immer wieder die Frage. Bedenkt man, dass die meisten grundlegenden Prinzipien der Unixwelt bereits über 30 Jahre alt sind kann man sich schon fragen ob die noch richtig sind. Ich bin per se eher konservativ eingestellt und denke, was gestern gut war ist morgen noch nicht schlecht, aber verlieren wir evtl irgendwann den Anschluss weil wir bodenständig agieren in einer Welt die sich immer schneller zu drehen scheint? Großrechner werden immer weniger. Wie schon mehrmals hingewiesen geht es in Richtung "wegwerf"-Rechner (als Virtualisierung) und Mobilgeräte.

Ich mag mein BSD sehr und bin auch sehr froh darüber, dass es keine Bastelwiese ist, aber ich frage mich auch ob es mit dem Wandel auf Dauer klar kommt.
 
Ich bin nicht konservativ, aber ich mag trotzdem stabile Software, die gepflegt wird. Ich probiere gerne alles aus. Ich habe auch systemd in zwei Linux-Distros ausprobiert. Auf Arch war es früh eingeführt worden und meine beiden Rechner (zu Hause und auf der Arbeit) haben nicht mehr gebootet und nach stundenlangem Suchen, haben sie solala gebootet, aber immer noch nicht ohne Race-Conditions mit Netz, NFS und Mounten.

Jetzt habe ich hier Debian Testing in der VM (Virtualbox) und ich habe immer noch eine Race-Condition. Manchmal startet da slim und ich kann nichts eingeben (so ca jedes dritte Mal). Da ist wohl irgendwas mit Keyboard nicht richtig initialisiert und Xorg ist gestartet (oder sowas ähnliches). Naja, zum Glück kann man ja der VM mit einem Hotkey ACPI power-off senden. Das Problem sehe ich aber auch als nicht so schlimm, muss ich zugeben. Die Anfänge von systemd mit Arch Linux waren äußerst übel für mich.

Ich verteufele eigentlich wenig. Ich meckere auch viel weniger als alle anderen. Im Gegensatz zu vielen freue ich mich, wenn man Xorg ersetzen könnte. Ich habe aber einiges an Software, was nicht funktioniert und die ist einfach nur ein Ärgernis. Es ist wirklich zufällig, dass alles was nicht läuft oder einfach grob scheiße ist, mit Poettering zu tun hat (nachdem ich das nachschlage). Ich habe eigentlich nichts gegen ihn persönlich. Bin aber wohl nicht mehr objektiv geworden in dieser Sache, weil wirklich alles was ich finde auf ihn hinzeigt, was ich für einen Müll finde. Es gibt auch andere, die darauf hingewiesen haben (aus der BSD-Welt und auch sogar Linux-Welt). Man muss Poettering zu Gute halten, dass er viel macht und wahrscheinlich auch gute Ideen hat. Die Umsetzung ist aber äußerst grottig... ich weiß nicht warum das so ist. Ich weiß nicht warum das so ist und interessiert mich nicht. Ich meide einfach die Software von ihm oder wo er seine Finger drin hatte (so gut wie es nur geht).
 
Gerade weil sich die Welt schnell bewegen, brauche ich keinen Monolithen, bei dem ich irgendwann aufgeben und auf einen Bugfix warten muss, sondern eine überschaubare skalierbare Lösung, die ich notfalls in 5min selbst fixen kann. Der Entwickler des systemd hat ja schon gezeigt, dass er Problem nicht aktzeptiert, bzw. nicht löst wenn sie nicht seiner Ideologie entsprechen. Damit ist zu erwarten, dass ihm Randprobleme auch in Zukunft am Allerwertesten vorbeigehen. Will ich so ein System an kritischer Stelle einsetzen?! Nein. Wer weiss schon, wann ich mit meinem Problem zur Randgruppe gehöre!
 
Nach all den Pro und Contras über systemd würde ich gerne mal wisse, wer alles systemd einsetzt und wirklich behaupten kann: "systemd funktioniert nicht"! Damit meine ich aber nicht eine Virtualbox Installation sondern einen Server oder Desktop der über mehrere Monate in Betrieb war.

Ich hatte einen OpenSuse-Desktop, der mit systemd schlicht und einfach nicht mehr deterministisch hochgefahren ist.
Alle zwei bis drei Male ist er einfach mittem im Init stehen geblieben und ich musste ihn resetten.
Und das war ein OpenSuse, weil ich mich eben nicht damit beschäftigen wollte, also ist der komplette Kram entsorgt worden.
Danach hab ich erstmal ein Ubuntu draufgepackt, aber als sie irgendwann ihre eigene systemd-compat-Schicht im Update mitgeschickt haben,
da hat der gleiche Mist wieder angefangen.
Seither läuft da Windows…
 
Meine Kritik an systemd richtet sich nicht dagegen, dass es ein Init-System ist. Wie ich bereits von ~100 Beiträgen schrieb, geht es mir vor allem um die teilweise sehr schwachsinnige Standardkonfiguration und dieses tumorartige Verhalten sich überall hineinzufressen. Wäre es ein reines Init-System mit ein wenig Servicemanagement, wäre die Welt völlig in Ordnung. Aber systemd ist längst eine Plattform, welche diverse das Linux-System orchestrierende Dienste in ein zentrales, sehr monolithisches Framework integriert. Und das finde ich a) sinnlos, da diverse Arbeit dupliziert wird und seit teilweise Jahrzehnten einwandfrei laufender Code ohne Not gegen qualitativ fragwürdige Alternativen ersetzt wird, sowie b) durch das gemeinsame Framework und die sehr enge Verzahnung der Dienste ein einziger großer Blob geschaffen wird.
 
Ich wollte auch keineswegs systemd damit befürworten. Wie ich sagte hatte ich bisher wenig Möglichkeit mir eine Meinung dazu zu bilden und auch wenig Gründe. Die Art und Weise wie systemd sich im kompletten Ökosystem breit macht missfällt denn es werden damit andere in Mitleidenschaft gezogen was nicht nötig wäre (und ich denke dabei eben an andere Systeme wie BSDs die damit ihre Schnittstellen geklaut bekommen und gereifte Software die dann einfach hinten runter fällt). Alte Zöpfe abschneiden wenn nötig, ja... Aber nicht dafür und nicht in dem Umfang.
Ich meine aber, dass etwas frischer Wind auch mal gut tun _kann_ und ich stelle eben die Frage ob die Designprinzipien wirklich noch die richtigen sind? Wenn ja, wunderbar, dann sind wir auf dem richtigen Weg... Je atomarer eine Forderung ist desto länger kann sie ihren Bestand rechtfertigen, so ist meine Meinung. Da die Grundsätze nach denen die Systeme entwickelt wurden meist als recht atomar anzusehen sind ist das evtl. der Grund warum sie so lange noch bestand haben.
 
http://de.wikipedia.org/wiki/Unix-Philosophie

Was die Unix-Philosophie und das veralten derselben angeht, kann ich dem nicht zustimmen, da es dabei weniger um bestimmte technische Eigenschaften geht, sondern vor allem darum komplexe Systeme beherrschbar zu machen.
Was unseren Linux-Brüdern und Schwestern sicherlich auch oft das Leben erleichtert hätte.
 
Alles in allem... hat auch systemd eine positive Eigenschaft. Ich habe immer wieder versucht, von FreeBSD auf Linux zu wechseln, weil mich einige Sachen bei FreeBSD stören, die auf Linux ziemlich gut laufen (ich bin natürlich immer wieder an anderen Sachen gescheitert und bin wieder zurück auf FreeBSD). Nun gibt es aber auch systemd, woran ich gleich 2x hintereinander gescheitert bin, einen Linux-Rechner vernünftig zu installieren, dass er meinen Anforderungen entspricht. Das macht meine Entscheidung nun noch einfacher.

Ich bin sozusagen, dank systemd, für eine längere Zeit von Linux kuriert.
 
...Bedenkt man, dass die meisten grundlegenden Prinzipien der Unixwelt bereits über 30 Jahre alt sind kann man sich schon fragen ob die noch richtig sind. ... aber verlieren wir evtl irgendwann den Anschluss weil wir bodenständig agieren in einer Welt die sich immer schneller zu drehen scheint? Großrechner werden immer weniger. Wie schon mehrmals hingewiesen geht es in Richtung "wegwerf"-Rechner (als Virtualisierung) und Mobilgeräte.

Um modern zu sein, muss man keine feature Moloche haben. Man kann auch moderne kleine Spezialisten haben, die den Unix Prinzipien entsprechen.

Ich kann das obendrein von der Entwicklerseite her bestätigen und aus Erfahrung behaupten, dass kleine Spezialisten qualitativ besser sind und auch bleiben, weil sie leichter zu warten sind.

... Im Gegensatz zu vielen freue ich mich, wenn man Xorg ersetzen könnte.

Dito. Nicht "neu" ist schlecht, sondern "schlecht gemacht" ist schlecht und "abstrus und weltfremd konzipiert" ist schlecht.

Meine Erfahrung in RZ und colos ist ganz klar die, dass "läuft und tut" *nicht* das Einzige ist was zählt, sondern schlicht als Normalzustand gilt und dass "was, wenn's mal nicht läuft?" das Entscheidende ist. Mithin Fragen wie "Können das normale admins regeln oder brauche ich (teure) Spezialisten?", "wie schnell und einfach kann man Probleme analysieren und beheben?".

Meine Kritik an systemd richtet sich nicht dagegen, dass es ein Init-System ist. Wie ich bereits von ~100 Beiträgen schrieb, geht es mir vor allem um die teilweise sehr schwachsinnige Standardkonfiguration und dieses tumorartige Verhalten sich überall hineinzufressen. Wäre es ein reines Init-System mit ein wenig Servicemanagement, wäre die Welt völlig in Ordnung. Aber systemd ist längst eine Plattform, welche diverse das Linux-System orchestrierende Dienste in ein zentrales, sehr monolithisches Framework integriert. Und das finde ich a) sinnlos, da diverse Arbeit dupliziert wird und seit teilweise Jahrzehnten einwandfrei laufender Code ohne Not gegen qualitativ fragwürdige Alternativen ersetzt wird, sowie b) durch das gemeinsame Framework und die sehr enge Verzahnung der Dienste ein einziger großer Blob geschaffen wird.

Ja. Und: shell scripts kann der admin zu Fuss und unterwegs fixen. C code nicht. Und kernel code sollte ein admin schon gar nicht erst anfassen müssen.

Im übrigen haben wir's doch von DEM Mann schlechthin, von Linus, dass die ständig Probleme verursachen, sich wie Arschlöcher benehmen, wirren regelwidrigen Mist in den kernel bringen und dann nicht mal aufräumen.
 
Ich bin wirklich auch kein systemd Befürworter aber man muss sagen, dass es bis jetzt eigentlich immer das gemacht hat, was es soll (Server). Dazu habe ich mehrere Server im Testbetrieb unter CentOS 7 und Arch Linux. Seit fast 10 Monaten und keine Probleme.

Hier läuft CentOS 7 und Arch Linux privat sowie RHEL 7 auf Arbeit bislang völlig ohne Probleme.

Man kann auch moderne kleine Spezialisten haben, die den Unix Prinzipien entsprechen.

Es gibt Grenzen dessen, was man mit einzelnen Spezialisten leisten kann.

Man sieht es sehr schön an ZFS, dass als Monolith Dinge leisten kann, mit separatem Dateisystem und Volume Manager einfach nicht möglich sind (end-to-end-checksumming).

SysVinit kann einen Dienst auch im Jahre 2014 nicht zuverlässig stoppen, was mir heute auf Arbeit wieder Verdruss beschert hat und mit systemd nicht passiert wäre. Schön, wenn man den Continous-Integration-Daemon stoppt und SysVinit Vollzug meldet, obwohl noch ein Child-Prozess läuft.

Ich kann das obendrein von der Entwicklerseite her bestätigen und aus Erfahrung behaupten, dass kleine Spezialisten qualitativ besser sind und auch bleiben, weil sie leichter zu warten sind.

Der Trend geht zwar momentan weg von monolithischen Architekturen (nachdem man es dort teilweise ordentlich übertrieben hat) hin zu Microservices, aber auch letztere haben ihre Herausforderungen. Notwendige Komplexität bekommt man nicht weg, man kann sie nur verlagern. Die Komplexität wandert in die Kommunikation zwischen den einzelnen Teilen.

Die Wahrheit liegt meiner Meinung nach aber wie üblich in der Mitte, wobei ich - um zum Thema zurückzukommen - SysVinit zu klein und systemd Stand zu groß geschnitten finde. Wobei man darüber streiten kann, wann systemd funktional den "sweet spot" hinter sich gelassen hat...
 
Notwendige Komplexität bekommt man nicht weg, man kann sie nur verlagern. Die Komplexität wandert in die Kommunikation zwischen den einzelnen Teilen.

Dort ist sie auch gut aufgehoben. Komplexität im Monolithen kann nur der Hersteller beherschen, Komplexität in der Kommunikation kann ich selber beherrschen. Die Praxis zeigt, dass ich mich um meine Probleme immer selber kümmern muss. Dem Hersteller - egal ob Community oder Kommerziell - ist mein Problem völlig egal. Bei systemd wird einem vom Entwickler schon in dieser frühen Phase klargemacht, dass ein entgegenkommen bei Problemen, die nicht in seinen Plan passen, völlig ausgeschlossen sind.
 
Wir drehen uns hier nun schon wieder mehrere Seiten im Kreis und nähern uns einer fruchtlosen Grundsatzdiskussion. Wie wäre es, an dieser Stelle erst einmal einen Schlussstrich zu ziehen und abzuwarten, wie es mit systemd weitergeht? Wenn es Neuigkeiten gibt, kann man hier noch immer weiterdiskutieren.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben