Boycott Systemd

Status
Für weitere Antworten geschlossen.
Ist das wirklich so?
Früher, als ich noch Slackware genutzt habe, hat Slackware ein auf BSD-like getrimmtes SysV-Init verwendet.
Hm, das könnte natürlich auch sein. Es war auf keinen Fall das übliche SysV-Init, das man sonst so findet,
ich dachte es wäre ein BSD-Init mit SysV-Compat-Schicht gewesen, aber es ist schon eine Weile her dass ich Slackware genutzt habe
und möchte mich daher nicht so weit aus dem Fenster lehnen ;).
 
Mist, Bearbeitungszeit abgelaufen, langsam nervts :)

Vorranging bedient systemd ja auch Server, die zusätzliche Funktionalität für den Desktop ist ein Nebenkriegsschauplatz.

Das ist das „neue“ Marketing von systemd. Das alte hat immer die Vorteile für den Desktop angepriesen, aber seit sie die primären Desktop-Distributionen in der Tasche haben,
ist es plötzlich schon immer nur eine Server-Sache gewesen.
Und genau solche Wechsel legen die systemd-Entwickler öfters hin und behaupten dann, es wäre schon immer anders gewesen. Daher kann man denen schlichtweg kein Wort mehr glauben.
Bor allem der Poettering ist ein notorischer Lügner, mit der Agenda GNOME als einzig wahren Desktop zu etablieren. Alles andere ist immerhin “deprecated“.
Daher sehe ich auch sein Jammer-Posting gelassen, zumal er ja auch immer kräftig austeilt, sachlich bleibt der selten genug.
Gerade in der Anfangszeit von systemd war seine Lieblingsverteidigung der ad hominem Attacken auf die Kritiker. Aber jetzt ist das natürlich wieder andersrum…
(Aber dass er oft genug persönlich angegriffen wird möchte ich nicht leugnen, auch ich äußere mich negativ über ihn. Aber ich denke das liegt in vielen Fällen an dem Übermaß an schlechten Erfahrungen mit „seiner“ Software bzw. von ihm initiierten Projekten.)
 
In meinen Augen ist Lennart Pöttering ein Werkzeug. Oder noch krasser gesagt ein Bauer auf dem großen Schachbrett. Das große Ziel ist wohl GNU/Linux in ein "Linux Enterprise Edition" umzubauen, dass es Red Hat ermöglicht mit einem möglichst geringen Eigenanteil möglichst viel Geld zu verdienen. Das heißt kein unixoides Serversystem mehr, wie es etliche gibt, stattdessen ein weitgehend automatisiertes Serversystem in der Art von Windows Server. Leicht zu erstellende, und zentral zu verwaltende Appliances für die Cloud, Massenhoster und so weiter. Einen komfortablen, standardisierten Desktop, der eine gute Grundlage für kommerzielle Anwendungen ist. Dann jede Menge teurer Services und Supportverträge außen herum. Pöttering ist nur die arme Sau, die man ganz vorn an die Front gestellt hat, um die Drecksarbeit zu machen und die notwendigen Änderungen gegen den Widerstand der Community durchzusetzen.

Aber ehrlich gesagt sehe ich es mit ein wenig Schadensfreude. Ich war und bin kommerziellen Interessen gegenüber immer offen gewesen, teilweise vielleicht sogar mehr als so manche andere Open Source Frickler. Aber ich wies trotzdem öfter darauf hin, dass im Linux-Lager einige wenige Firmen viel zu mächtig geworden sind und daher einen zu großen Einfluss haben. In etwa die gleiche Situation, als das ganze FreeBSD Projekt vor inzwischen fast 15 Jahren am Wohl und Wehe von Yahoo hing. Nun ist genau das passiert, was absehbar war. Red Hat, die ihre Finger überall drin haben und inzwischen sicher ein Viertel der ein Linuxsystem stellenden Projekte direkt oder indirekt maßgeblich entwickeln, schlägt einen anderen Weg ein, als große Teile der Community es wollen. Die hat nur kaum eine Möglichkeit sich wirksam dagegen zu wehren, es heißt friss oder stirb. Morddrohungen gegen das Gesicht der Entwicklung sind nur aufgestaute, sich aus Frust über die eigene Hilfslosigkeit speisende Wut.
 
Hm, das könnte natürlich auch sein. Es war auf keinen Fall das übliche SysV-Init, das man sonst so findet,
ich dachte es wäre ein BSD-Init mit SysV-Compat-Schicht gewesen, aber es ist schon eine Weile her dass ich Slackware genutzt habe
und möchte mich daher nicht so weit aus dem Fenster lehnen ;).
Ich hab gerade mal in einen Slackware-Mirror geschaut, dort ist als Initpacket der SysV-init von Miquel van Smoorenburg zu finden. Laut http://www.slackware.com/config/init.php hat Slackware seit 7.0 eine sysV-kompatibilität.
In meiner Erinnerung ist das ganze so, dass die /etc/inittab bei Slackware so aufgebaut ist, dass ein BSD-Init simuliert wird.

Back to Topic: Beim googeln nach Miquel van Smoorenburg (dem Autor von Slackwares Sys-V-init) bin ich auf folgenden Artikel zum Thema "Which init?" aus dem Jahr 1998 gestoßen: http://www.linux.it/~rubini/docs/init/
Dort ist auch erklärt, wie der SysV-Init/die inittab bei Slackware (und als Kontrast dazu bei Debian) aufgebaut ist.
 
@Yamagi: Ich glaube es ist beides. Poettering ist sicher nicht nur eine arme Schachfigur. Kann mir schon vorstellen, dass er weiß warum er alles andere niedermacht und systemd als das einzig Wahre bezeichnet. Ist bei Red Hat angestellt und laut Wikipedia ist sein großes Ziel "Sandboxed Applications for GNOME/Linux".
 
Wenn der im Sandkasten buddeln will, kann der gerne bei mir vorbei kommen. Mein Kind leiht ihm auch gerne ein Schäufelchen und sie können beide mit nackten Füßen durch den Sand trampeln, um Abdrücke zu machen - Limo und Eis kann er auch gerne haben. Hauptsache er macht sonst keinen Unfug in der Zeit ...
 
Slackware nutzt BSD Init,
Tatsächlich und wie chaos meinte ein an FreeBSD angelehntes simple init mit sysvinit Scripten. Hab' mal nachgesehen.
ps: Edit: wurde offenbar schon beantwortet

Theo möchte sicherlich nicht systemd in OpenBSD einführen.

Angesichts dessen, dass OpenBSD nach wie vor das klassische simple init ohne sysvinit Scripte nutzt, vermutlich tatsächlich eine geringere Gefahr.
Würde sich rc.securelevel mit systemd überhaupt noch konsequent durchfühen lassen?

Aber wie steht's um Free&NetBSD, welche sich vom ursprünglichem simple init bereits entfernt hatten?

Auch unter OpenBSD gibt's
Code:
# init
, doch Aufrufe wie etwa um während des Betriebs den SingleModus zu erzwingen

Code:
# init -s

oder
Code:
# init 0
bleiben unwirksam.
 
NAbend Yamagi, @all,

Red Hat, die ihre Finger überall drin haben und inzwischen sicher ein Viertel der ein Linuxsystem stellenden Projekte direkt oder indirekt maßgeblich entwickeln, schlägt einen anderen Weg ein, als große Teile der Community es wollen. Die hat nur kaum eine Möglichkeit sich wirksam dagegen zu wehren, es heißt friss oder stirb. Morddrohungen gegen das Gesicht der Entwicklung sind nur aufgestaute, sich aus Frust über die eigene Hilfslosigkeit speisende Wut.

... dann frage ich mich, warum die Debian-Community auf systemd einschwenkt... An den Treibern bzw. Kernel-Internas kann es ja wohl nicht liegen, da sie bei RedHat unter der gleichen Lizenz vorliegen, wie bei den anderen Linux-Distris.

Auch die Argumentation seitens Gnome und anderer Entwickler halte ich für sehr fadenscheinig: "Wenn ihr kein systemd habt, dann gibts kein Gnome mehr" => Das Betriebssystem hat sich nach der Applikation zu richten. Irgendwie muss ich outdated oder oldschool sein, aber meines Wissens sollte eine Applikation die vorhandenen Resourcen so optimal wie möglich nutzen. Die Gnome-Entwickler sollen ihr Softwarepaket gefälligst so entwickeln, dass es auch ohne systemd auskommt. Meine Güte, dann ist halt keine Init-Überwachung, "Realtime-Locale-Switching", Login-Steuerung oder anderes Zeugs unter FreeBSD oder systemd-free-Debian möglich. Warum gehts bei KDE?

Ich wünsche kopfschüttelnd einen schönen Abend

JueDan
 
Das sind politische Entscheidungen um systemd in den Markt zu zwingen. Klar ginge es auch ohne. Dass der Pflegeaufwand für Software die in verschiedenen Umgebungen laufen soll entsprechend zunimmt ist zwar richtig, aber daher muss ich ja nicht direkt alles andere rauswerfen... es sei denn ich nutze das als "Druckmittel" ;)
 
Auf dem Server hat man auch kein Interesse ein systemd-Feature zu nutzen, bei dem Dienste im Kreis neugestartet werden, falls sie ausfallen.Wenn ein Dienst ausfällt hat das nämlich einen Grund, der untersucht werden muss.

Wenn der Hersteller einer Software sagt "Dienst schmiert ab, Fehler bekannt, Fix in QS, Workaround: Dienst wieder starten", dann ist doch die Möglichkeit des automatischen Neustarts des Dienstes (und etwaiger Abhängigkeiten) um Größenordnungen besser als jedesmal einen manuellen Eingriff des Admins zu erzwingen.

Wenn ein Dienst ausfällt hat das nämlich einen Grund, der untersucht werden muss.

Auch in der Zwischenzeit sollte eine möglichst hohe Verfügbarkeit des Dienstes gewährleistet sein.

Beim Desktop ist das für DAUs, die nichts vom System verstehen schon ok, so ein Windows-like Verhalten zu emulieren (kennt jeder: nach dem Explorer-Crash verschwindet kurz die Leiste unten und dann erscheint sie wieder nachdem der Explorer nochmal gestartet wird).

Dein Alternativvorschlag? Den Desktop in einem unbenutzbaren Zustand lassen und den Anwender zum Griff zum Reset-Knopf zwingen?
Wenn ein Programm unter BSD sämtlichen RAM verbraucht, sollte nicht das Programm abgeschossen werden, sondern eine Kernel Panic erfolgen?

Das ist das „neue“ Marketing von systemd.

Da muss ich dich enttäuschen - ich habe mir schon in den Anfängen von systemd gedacht:
"Mensch, endlich Features à la SMF unter Solaris auf dem Linux-Server - haben will!"

Die Desktop-Features sind zwar lange überfällig und bringen den Desktop auch meilenweit voran, der Abstand zur etablierten Konkurrenz ist aber nach wie vor gigantisch.

... dann frage ich mich, warum die Debian-Community auf systemd einschwenkt... An den Treibern bzw. Kernel-Internas kann es ja wohl nicht liegen, da sie bei RedHat unter der gleichen Lizenz vorliegen, wie bei den anderen Linux-Distris.

Schon erstaunlich, wo systemd doch auch angeblich keinerlei Features bringt, die irgendjemand brauchen könnte. ;)

Auch die Argumentation seitens Gnome und anderer Entwickler halte ich für sehr fadenscheinig: "Wenn ihr kein systemd habt, dann gibts kein Gnome mehr" => Das Betriebssystem hat sich nach der Applikation zu richten.

Die GNOME-Entwickler wollen sehr wohl andere Plattformen unterstützen, bekommen aber die kalte Schulter gezeigt.

Irgendwie muss ich outdated oder oldschool sein, aber meines Wissens sollte eine Applikation die vorhandenen Resourcen so optimal wie möglich nutzen.

Das machen doch die GNOME-Entwickler. Sie verschwenden keine Entwickler-Resourcen auf die Implementierung von Funktionalität, die vom Betriebssystem im weiteren Sinne kommen sollte.

Die Gnome-Entwickler sollen ihr Softwarepaket gefälligst so entwickeln, dass es auch ohne systemd auskommt.

Die Anspruchshaltung muss man sich leisten können. Wenn man die Bedürfnisse der Entwickler ignoriert und keine Alternativen bietet, während die Konkurrenz liefert, darf man sich hinterher nicht über einen Platz in der zweiten Reihe beschweren.

Meine Güte, dann ist halt keine Init-Überwachung, "Realtime-Locale-Switching", Login-Steuerung oder anderes Zeugs unter FreeBSD oder systemd-free-Debian möglich.

Die Gnome-Entwickler hätten aber gerne die Grundlage für Features, die anderenorts seit mehr als 10 Jahren selbstverständlich sind. Sie akzeptieren aber bereitwillig Patches zur Unterstützung von Umgebungen, die das (noch) nicht liefern.

Warum gehts bei KDE?

KDE schwenkt - mangels Alternativen - auch schon langsam aber sicher auf systemd um.
 
Wenn der Hersteller einer Software sagt "Dienst schmiert ab, Fehler bekannt, Fix in QS, Workaround: Dienst wieder starten", dann ist doch die Möglichkeit des automatischen Neustarts des Dienstes (und etwaiger Abhängigkeiten) um Größenordnungen besser als jedesmal einen manuellen Eingriff des Admins zu erzwingen.
Nicht wirklich eine Lösung. der Standardfall für einen Server ist, den Dienst zu inspizieren. Es ist wie gesagt auf dem Desktop eine mögliche Lösung, aber spätestens, wenn Du aus Versehen wiederholt Schaden anrichtest, der richtig Geld kostet, anstatt nur 1x und dann Abbruch, wirst Du der Meinung sein, dass ein kaputter Dienst lieber nicht weiter unbeobachtet laufen sollte.
 
  • Like
Reaktionen: lme
Wenn der Hersteller einer Software sagt "Dienst schmiert ab, Fehler bekannt, Fix in QS, Workaround: Dienst wieder starten", dann ist doch die Möglichkeit des automatischen Neustarts des Dienstes (und etwaiger Abhängigkeiten) um Größenordnungen besser als jedesmal einen manuellen Eingriff des Admins zu erzwingen.

...

Auch in der Zwischenzeit sollte eine möglichst hohe Verfügbarkeit des Dienstes gewährleistet sein.

Das ist doch alles graue Theorie, wenn Du einen Dienst hast, der nichts anderes tut, als alle 3,4679 sec einen xbill über den Bildschirm zu jagen und der Dienst stürtzt ab, dann kannst Du den ja von mir aus so lange neu starten, bis das Ende aller Tage gekommen ist.

Wenn Du aber das Problem hast, daß Dir alle paar Stunden deine betriebsrelevante Datensammelmaschine niederbrennt, dann würde ich zumindest den Teufel tun, das Ding alleine starten zu lassen, denn es ist nicht auszuschließen, daß der Lieferant zwar in zwei Wochen den Patch liefert, aber dann blöderweise doch irgendwelche Daten inkonsistent geworden sind und das erst dem Friseur in 6 Monaten auffällt. Das ist dann kaum noch sinnvoll aufzuräumen.

Und ehrlich gesagt, ich habe nur wenige Server unter mir, aber das seit 20 Jahren und das mir bei denen irgendein Dienst dauernd weggestorben ist, kann ich nicht sagen. Das waren FreeBSD, OS/2, Debian und CentOS / Scientific Linux. Insofern ist es mir ziemlich egal, ob die LinuxLover da wiedermal irgendein Feature reingefrickelt haben, was sie jetzt dringend meinen nutzen zu müssen.
If it aint broken, don't fix it.

Sollte irgendwann dann auch mal X unter den BSDs wegsterben, weil der dringend noch eine coffee.app haben will und es die dort nicht gibt, dann schreiben wir halt unsere pdf wieder mit vi.
 
Die GNOME-Entwickler wollen sehr wohl andere Plattformen unterstützen, bekommen aber die kalte Schulter gezeigt.
Dann sollen sie es halt nach der Art
Code:
if Dienst_vorhanden then
 use it
else
 don't offer it
endif
programmieren.
Ich persönlich vermute, dass Gnome schon zu stark an Linux gebunden ist und sie mangels Personal nicht mehr zurück können. Ich stelle mir nur die Frage, wenn nächstes Jahr systemd wieder hinausgeworfen werden sollte(!), was die Gnome-Entwickler dann machen wollen? Ist deren Code so portabel, dass sie innerhalb kürzester Zeit umschwenken können?
 
... Das große Ziel ist wohl GNU/Linux in ein "Linux Enterprise Edition" umzubauen, dass es Red Hat ermöglicht mit einem möglichst geringen Eigenanteil möglichst viel Geld zu verdienen. Das heißt kein unixoides Serversystem mehr, wie es etliche gibt, stattdessen ein weitgehend automatisiertes Serversystem in der Art von Windows Server. Leicht zu erstellende, und zentral zu verwaltende Appliances für die Cloud, Massenhoster und so weiter. Einen komfortablen, standardisierten Desktop, der eine gute Grundlage für kommerzielle Anwendungen ist. Dann jede Menge teurer Services und Supportverträge außen herum.

Das kommt denke ich ganz gut hin.

Mal rein kommerziell gesehen ist es ja so, dass man als Spieler auf einem zunehmend großen Markt Alleinstellungsmerkmale braucht und/oder als leader dastehen sollte.

Zum anderen: Wer, mal abgesehen vom kernel, den Systemstart kontrolliert, der kontrolliert das System. Oder, auf Distro-Ebene gesehen: Wer den Systemstart kontrolliert, der kann den anderen Mitspielern so einige Vorgaben machen ... und sich selbst immer einen Vorsprung erhalten.

Aber, ehrlich gesagt, finde ich das alles ziemlich egal, weil linux in meinen Augen sowieso zunehmend unbrauchbarer Frickel-Mist ist. Erschwerend kommt ein Wirrwarr an (tatsächlich oder pseudo) offiziellen Einrichtungen wie freedesktop dazu; und weil das noch nicht reicht, müssen natürlich auch gnome und Konsorten (auf Standards schei... und) eigene de facto Standards schaffen/aufzwingen.

Nur mal so als Beispiel: Man sehe sich mal an, wie man etwas im Grunde simples wie den Rechner runterfahren dank freedesktop, dbus, etc. aufwendig von hinten durch die Brust ins Auge erledigt...

Letztlich sehe ich immer wieder die drei "Grundgesetze" der IT:
- Wenn's mit Sound zu tun hat, wird die Qualität von Konzept und Code schlecht und die Menge groß. Wenn's auch noch bunt wird (gui, wm, ...) dann endet es meist völlig konzeptionslos wirkend, akut unprofessionell und qualitativ beschi...
- Fricklern wünsche ich viel Spass beim "Programmieren" von Hobbykram. An Betriebssystemen, servern und anderen Core Geschichten sollten ausschließlich erfahrene Profis arbeiten.
- Demokratie hat ihren Platz. Und der ist *nicht* im Bereich OS core und ähnliches.

Oder, etwas weniger nett ausgedrückt: Linux ist in meinen Augen viel Geplärr und Gezänk um gpl-Extremismus, ein Haufen inkompetenter Hobbybastler und jede Menge undurchdachter Mist. Daran ändern auch einige wenige kompetente Leute nichts.
Positiv sehe ich da mittlerweile nur noch - und das anerkenne ich auch - dass linux viel bewirkt hat in Sachen Treiber, Hersteller Infos, Portierungen nach Unix (na ja, linux, aber ein Anfang immerhin).

Was mich ärgert ist auch: Da gibt es OpenSxce, ein ziemlich gutes Open Source Solaris, das im wesentlichen von 1 (einem!) Mann gemacht wird. Und der muss seine geliebten Maschinen verkaufen, um seine Miete bezahlen zu können. Aber linux kriegt Milliarden nachgeschmissen.

Ein linux will ich eh nicht, aber eins mit systemd kommt mir keinesfalls auf die Kiste. Eher noch probiere ich ReactOs *g
 
@rmoe

Mit solchen Aussagen machst du es dir ein bisschen zu einfach. Ich behaupte die Open Source Software Welt wäre ohne GPL nicht da wo sie jetzt ist.(Das ist aber ein anderes Thema) Und klar ist auch, dass Firmen welche Millionen in den Kernel Code von Linux stecken dies auch irgendwie wieder haben wollen. Ich mag mich noch erinnern als es hiess: "Jedes Linux ist anderst. Man muss immer etwas neues lernen. [1]"

Mit systemd kommt hier eine grosse Erleichterung auf die Admins zu. Es wird alles in der Linux Welt einheitlicher.

Der Markt wollte das Open Solaris nicht. Selbst bei Oracle steht Linux weit vor Solaris. Sun hat der Welt das wichtigste von Solaris geschenkt ZFS!

[1] http://xaharts.org/funny/i/Microsoft_Linux_ad-s.jpg
 
Eben auf die Admins nicht, foxit, auf den Desktop-User. Einheitlich machen durch Einführung von Unportabilität ist natürlich sowas wie "sich die Welt einfacher machen". So kann ich natürlich immer die Software verkaufen: wir müssen nur auf alle anderen Systeme verzichten, dann läuft bei "allen" alles besser ("allen" weil die Welt kleiner geworden ist; alle Leute, die wir nicht persönlich kennen, interessieren uns nicht!).

Ich bin gespannt wie das wäre, wenn BSD-Systeme ab jetzt mit Standards brechen würden. Lasst uns das mal machen. Alles an Netzwerkdiensten standardmäßig mit KQUEUE/KEVENT versehen, standardmäßig Jails und ZFS voraussetzen, netgraph und GEOM überall verwurschteln. Das wäre ein Stöhnen dann.

Außerdem, ich drehe hier geduldig die Däumchen bis der erste Nutzer sein System nicht reparieren kann, weil ein systemd-Dienst alles so blockt, dass systemd selbst beeinflusst wird und keine Möglichkeit mehr zur Reparatur des Systems lässt.
 
Und wie hilft mir das genau? Entbindet mich diese Auflistung der Dienste von der Pflicht sie zu überprüfen, ob sie (korrekt) laufen? Ich kann auch laufende Dienste auflisten (da gibt es mehrere Möglichkeiten, aber schön nach dem Aspekt, der mich gerade daran interessiert, zum Beispiel Reihenfolge in der sie gestartet werden/wurden oder ob ein Prozess gerade aktive Kinder hat und nicht einfach geschlossen werden sollte), aber das heißt noch lange nicht, dass sie nutzbar sind.

Beim Administrieren von Diensten ist da mehr zu tun als nur init zu bedienen. Ich benutze so etwas eigentlich nie. Gerade habe ich eben "service -e" entdeckt, was mir die oben besagte Reihenfolge von gestarteten Diensten anzeigt. Ja und? Ich habe meistens den Aufwand beim Upgrade, zum Beispiel von MySQL. Da gibt es eine feste Vorgehensweise, damit der Betrieb gesichert ist. Genauso bei Mediawiki, Apache, PHP, Perl uvm. Was soll ich mit einer Service-Übersicht und der Mitteilung, dass ein Service nicht läuft. Wenn ich nicht komplett verblödet bin, dann sehe ich das auch so, dass Mediawiki nach dem Update nicht mehr läuft.
 
Und wie hilft mir das genau? Entbindet mich diese Auflistung der Dienste von der Pflicht sie zu überprüfen, ob sie (korrekt) laufen?

Böse Zungen - zum Beispiel die meine - würden nun einwenden, dass viele gerade junge Admins das nicht tun, weil sie irrsinniger medialer Berichterstattung glauben, die "Linux ist bedingungslos sicher" postuliert.
Was ich da schon an Servern im Bekanntenkreis gesehen habe, tut mir wirklich weh.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben