Systemd betrügt UNIX-Philosophie?

G

Gnu-Freund

Hallo zusammen,

heute habe ich unter http://www.pro-linux.de/news/1/21636/debian-abspaltung-in-aussicht-gestellt.html u.a. folgendes gelesen:

Pro-Linux.de schrieb:
Warum man erwägt, Debian zu forken, wird damit beantwortet, dass die Macher täglich professionell oder privat mit Debian zu tun haben und Systemd nicht benutzen möchten, da es die UNIX-Philosophie betrüge. Es sei zu erwägen, ein moderneres Init-System als Sysvinit zu benutzen, aber keinesfalls eines, das »die grundlegenden Designvorgaben des 'Tue eine Sache und tue sie richtig' mit Dutzenden von eng gekoppelten Binärdateien und undurchsichtigen Logs unterminiert«.

Der Systemd-Entwickler Lennart Poettering hatte sich erst kürzlich über die seines Erachtens vorhandene Agressivität in der Linux-Community geäußert. Man habe im IRC sogar Bitcoins gesammelt um ein Attentat auf ihn zu finanzieren! Und das alles wegen Systemd!

Zur Info: Ich bin einfacher Anwender und kenne mich mit den Unterschieden zwischen SysVinit und Systemd nur soweit aus, als ich etwas in gängigen Linux-Zeitschriften oder dem Internet darüber lesen konnte.. es soll schneller starten, zur Vereinheitlichung von Linux-Distributionen beitragen und zeitgemäße Funktionen bieten. Eigentlich hört sich das für mich als einfacher Anwender ganz positiv an.

Ich bin daher über die heftigen Reaktionen in der Community scheinbar speziell aus den Gentoo- und Debian-Lagern über die Einführung von Systemd als Standard irritiert.
Was hat es damit auf sich? Warum diese Aufregung? Bricht Systemd tatsächlich mit der UNIX-Philosophie?
Was meint Ihr?
 
Hallo

Lies die diversen Forenbeiträge, oder die Mailinglisten, vieles davon sind in meinen Augen Halbwahrheiten, dummes Philosophiegelaber.
Systemd hat eindeutig Vorteile, nur einige wollen am althergebrachten festhalten, negieren die Vorteile, gerade im Desktopbereich.

Nur die Art und Weise, wie teileise die systemdgener diskutieren und andere direkt angreifen, geht sehr oft unter die Gürtellinie und ist ganz dummer, kleinkarierter Stil.
Da fehlt Einigen wohl die nötige Erzioehung und ein groß0er geistiger Horizont.



mfg
schwedenmann
 
Systemd hat eindeutig Vorteile, nur einige wollen am althergebrachten festhalten, negieren die Vorteile, gerade im Desktopbereich.

Und genau da liegt der Schwachpunkt der Argumentation für systemd. Es macht im Desktop-Bereich Sinn, bei Servern aber eher nicht. Und wo ist Linux am weitesten verbreitet? Ganz bestimmt nicht auf Desktops. Gerade Debian wird primär auf Servern eingesetzt und imo ist es langsam an der Zeit, dass sich Distros für den Desktop-Einsatz und Distros für den Server-Einsatz entwickeln. Dieser ständige Spagat zwischen Desktop und Server wird mittelfristig nicht funktionieren, da die Software für beide Anwendungsbereiche immer spezialisierter wird.
 
... im Desktop-Bereich Sinn, bei Servern aber eher nicht.
Was genau meinst du hier mit: "bei Servern eher nicht?" Wenn du Init meinst, liegst du falsch! Genau bei dieser Geschichte hatte man nie Probleme mit systemd. Diesen Job macht es sehr gut. Das Problem ist, dass es sich wie ein Geschwür duch das ganze OpenSource Umfeld frist und fehlerlose Software welche Jahre auf Bug abgesucht wurde durch zweifelhaften Code ersetzt, was die Qualität angeht.
 
Zum Thema "UNIX-Philosophie" konnte ich heute beim Stöbern in der CHIP-Linux folgendes Zitat finden:
CHIP-Linux 5/2014 schrieb:
Wesentlicher Teil der Philosophie von Unix-artigen Betriebssystemen ist, dass jedes Tool genau eine Aufgabe übernimmt und sie optimal erledigt. Um komplexere Aufgaben durchzuführen, muss man daher Programme kombinieren. Das geschieht mit Pipes.
Kommt es durch Systemd zum Bruch mit dieser Philosophie wie im Zitat des ersten Postes behauptet?
 
Zum Thema "UNIX-Philosophie" konnte ich heute beim Stöbern in der CHIP-Linux folgendes Zitat finden:

Kommt es durch Systemd zum Bruch mit dieser Philosophie wie im Zitat des ersten Postes behauptet?

Im Prinzip schon, da es z.B. die Aufgaben von (x)inetd und SysVInit kombiniert. Nun kann man sich allerdings darüber streiten inwiefern ein Init-System auch ereignisbasiertes Starten von Diensten übernehmen sollte.

Ich sehe diese ganze Streiterei übrigens als einen übel ausgearteten Flame-War. Ich denke systemd hat durchaus in einigen Anwendungsfeldern seine Berechtigung. Für manche Anwendungsfelder schleppt es allerdings auch unnötig viel Ballast mit, die dort eher negativ wirken. Das beste Beispiel ist die Trennung von Server-OS und Desktop-OS. Es macht absolut Sinn auf Desktops die Dienststarts zu parallelisieren, gerade auf heutigen Multicore-Systemen. Auf Servern besteht aber zumeist sowieso eine Abhängigkeitskette zwischen den Diensten, so dass es dort nicht notwendig ist. Ausserdem werden sie üblicherweise äußerst selten neu gestartet. Damit bringt systemd auf modernen Desktop-Computern durchaus einige Vorteile, auf Servern aber eher nicht.

Und diese Schere zwischen Server und Desktop wird in Zukunft vermutlich noch weiter auseinandergehen, da im Server-Bereich die Anforderungen an Sicherheit usw. immer weiter wachsen, die auf auf Desktops eher zu Behinderungen führen würden. Auch hier gibt es ein wunderbares Beispiel mit SELinux. Was macht der Desktop-Nutzer bei CentOS und anderen Distros mit SELinux als Default zuerst, wenn er auf ein Problem stösst? Er deaktiviert SELinux, da es im Desktop-Bereich eh kaum Sinn macht und eher hinderlich bei der täglichen Arbeit ist, weil man ständig die User-Rollen wechseln muss, die Rollen der eingesetzten Software beachten muss, Userspace-Tools kaum verwenden kann usw.. Auf Servern ist aber ein RBAC wie SELinux heutzutage kaum noch wegzudenken.

Imo sollte man daher langsam mal anfangen Systeme für spezielle Aufgaben zu entwickeln. Niemand erwartet von einem Android, dass es als Server eingesetzt werden kann. Es ist speziell für Touchscreens und mobile Devices entwickelt und kann sich dadurch wesentlich besser spezialisieren und seine Aufgaben wesentlich effizienter und sinnvoller verrichten. Würde man dort den ganzen Server-Kram noch integrieren, hätte es sich ganz schnell mit der Usability von Android erledigt. Auch bei den Linux-Distros sollte daher langsam mal klar werden, dass es durchaus Sinn macht nicht nur die Programme für jeweils eine Aufgabe zu bauen sondern auch die Systemtools und den Kernel. Beim Kernel versucht man diesen Spagat durch Modularität. Wieso nicht bei der Software?

Und vor allem sollte man endlich aufhören sich gegenseitig zu behacken. Es gab mal Zeiten in der OSS-Community, in der man neue Ideen sachlich diskutiert hat und in der Entwickler auch akzeptiert haben, wenn ihre Idee mal nicht so gut ankam. Bei Systemd habe ich das Gefühl, dass beides nicht mehr der Fall ist. Man findet kaum irgendwo nüchterne und sachliche Diskussionen und ich kann auch nicht verstehen, warum die Entwickler von systemd nicht einfach sagen "Na dann halt nicht", wenn eine Distro lieber beim alten Init-System bleiben will. Warum denn nicht einen Fork von Debian machen und eines für Desktops ausbauen, das andere für Server? Damit wäre der IT-Welt weitaus mehr geholfen als wenn sich die Community untereinander zofft und das dann "Diskussion" nennt.
 
Hallo


@bitmuncher,
Warum denn nicht einen Fork von Debian machen und eines für Desktops ausbauen, das andere für Server? Damit wäre der IT-Welt weitaus mehr geholfen als wenn sich die Community untereinander zofft und das dann "Diskussion" nennt.
Ich glaube da steht das Dogma "Unix Philosophy" im Weg, bzw. die Interpretation , was genau darunter fällt (der Kernel nicht, aber selbstverständlich systemd).

Was aber bemerkenswert ist, das andere Distris, egal ob für Server oder Desktop, diese Diskusson nicht haben.



mfg
schwedenmann
 
Mir kommt skynet .. ähm systemd nicht ins Haus,
Ein Programm eine Funktion hat die letzten Jahre sehr gut funktioniert, daher sehe ich für mich absolut kein Grund davon abzuweichen,
vielleicht wenn systemd mir mein Kaffee kochen und holen kann und mir jeden Abend eine Gute Nacht Geschichte vorliest, dann überleg ichs mir nochmal, warscheinlich ist es bald schon so weit, bei dem ganzen kram den die da jetzt schon eingebaut haben.

Sollen sie es halt als modul anbieten, wer den mist haben will, soll ihn nutzen, wer ihn nicht will sollte ihn nicht nutzen müssen, bzw ihn erst von haus aus dem system werfen müssen.
 
schwedenmann schrieb:
Was aber bemerkenswert ist, das andere Distris, egal ob für Server oder Desktop, diese Diskusson nicht haben.
Ich denke es ist kein Zufall das gerade Gentoo- und Debian-User eine solche Aufregung um die Einführung von systemd machen.
Wenn man sich die Tradition dieser beiden Distributionen mal ansieht fällt auf das es sich hier eher um "konservative" Distributionen handelt, die Neuerungen am System nur sehr zögerlich aufnehmen/annehmen. Gerade Gentoo-User scheinen ja ein Faible für old-school Unixstyle zu haben (Quellen kompilieren, System händisch zusammenfriggeln), da passt ein so vom Good-Old-Unix abweichender init-Dienst nicht rein.
Erst kürzlich habe ich einen sehr interessanten Bericht über BSD und Linux auf youtube gesehen, wo die BSD-Einstellung "Alles so belassen wie es ist, nichts verändern außer es ist zwingend erforderlich" benannt wurde. Linux wurde als im Gegensatz dazu eher Progressiv geschildert: "Wenn es eine Idee gibt, die besser funktioniert als die Alte... rein damit.. auch wenn das ganze System umstrukturiert werden muss!"
Ich persönlich bevorzuge die progressive Variante, denke aber das man dabei vorsichtig sein sollte um die "Identität" von Linux (unixoid) nicht zu gefährden!
 
und es ist ein Irrglaube, daß die Diskussionen "im alten System" nicht vorhanden wären.

vi vs. emacs ist da eines der besten Beispiele.

Im konkreten Fall geht's vermutlich eher um Gewohnheiten - das war nicht anders, als irgendwann plötzlich irgendjemand grub erfunden hat und der Rest der Welt plötzlich gezwungen war, lilo zu vergessen.

http://lwn.net/Articles/89772/
 
@Gnu-Freund: Ich kann dem überhaupt nicht zustimmen. Wenn es ein reform-unwilliges System auf dieser Welt gibt, dann ist Linux dafür das Paradebeispiel und zwar egal welche Distro. Dazu muss man sich nur mal den bis heute monolithisch aufgebauten Kernel anschauen. Wirklich grundlegende und notwendige Änderungen werden bei Linux nicht angegangen. Da pappt man lieber an den alten Haufen noch ein bisschen mehr ran und hofft, dass er nicht zusammenfällt. So lange so ein Murks unter der Haube läuft, helfen auch die besten Tools nichts und bringen evtl. eher neue Gefährdungen in's System, die die alten Tools bereits überstanden haben.

Allerdings kann ich den Reform-Unwillen von Distros, die primär auf Servern Anwendung finden, durchaus verstehen. Denn bis heute gilt bei Servern, dass strukturelle Änderungen im System auch notwendige Änderungen bei Programmen und Diensten nach sich ziehen. Da aber gerade die OSS-Community sich ausserstande sieht sich mit den grossen kommerziellen Anbietern von Software abzustimmen (die sind ja alle böse, weil nicht OSS), bringen strukturelle Änderungen im System oft drastische Probleme im Server-Umfeld mit sich. Ein gutes Beispiel dafür sind aktuell die Probleme mit OpenSSL. Man konnte einfach keine saubere Implementierung auf Linux machen solange der Kernel keinen besseren Zufallszahlengenerator bekommen hatte, was ja (un)glücklicherweise vor einiger Zeit geschah. Allerdings ticken jetzt diverse auf Linux basierte Tools, die Zufallszahlen für statistische Auswertungen brauchten, völlig aus und zeigen drastische Abweichungen von ihren bisherigen Werten. Das wiederum wird dann zu einem echten Problem, wenn (wie bei mir kürzlich geschehen) Angriffserkennungssysteme, die statistische Auswertungen zum Erkennen von Anomalien wie Covert Channels nutzen, davon betroffen sind. Solche Tools können dann ihre Arbeit nicht mehr korrekt verrichten, weil sie eine komplett neue Datenbasis brauchen, auf der sie arbeiten können. Die Folge sind lange Ausfallzeiten zur Erstellung einer neuen Datenbasis.

Es ist daher verständlich, dass "Server-Distros" sich gegen strukturelle Änderungen wehren. Diese Sichtweise aus dem Blickwinkel eines professionellen Admins fehlt aber den meisten Leuten, die sich in Diskussionen um grundlegende Änderungen einmischen und oftmals will man diese Sichtweise auch einfach nicht anerkennen. Es hat also nicht unbedingt was mit Reform-Unwillen oder "old school" zu tun, sondern auch mit der Notwendigkeit den Kunden/Server-Betreibern/Server-Betreuern ein verlässliches System zu bieten.

Und es zeigt mal wieder deutlich, dass Linux endlich eine strikte Trennung zwischen Servern und Desktops einführen muss. Natürlich will der Desktop-User immer die neueste Technologie, und die soll er auch gern bekommen. Es muss aber auch beachtet werden, dass die Anforderungen an Server drastisch andere sind und Linux hat nunmal nicht gerade einen grossen Marktanteil bei den Desktops. Es ist in seinen heutigen Ausführungen/Distros in erster Linie ein Server-System und somit ist es logisch, dass Distro-Betreuer auch eher aus dem Bedarf für Server heraus agieren als für die paar Hanseln, die ihre Distro auf einem Desktop quälen.

@marce: Als Grub heraus kam, gab es solche Streitereien nicht. Die Vorteile von Grub lagen zu klar auf der Hand und überwiegten den Umstellungsaufwand. Allerdings gibt es durchaus einen Grund warum bis heute Lilo trotzdem mitgeliefert wird. Es gibt nämlich diverse BIOS, mit denen Grub einfach nicht funktioniert. Und da systemd ja kompatibel zu SysVInit ist, wäre es durchaus eine Überlegung diesen einfach als optionale Komponente den Distros beizulegen anstatt ihn krampfhaft als Standard erzwingen zu wollen.

Die meisten heutigen Deployment- und Konfigurationsmanagement-Tools sind auf die Verwendung von SysVInit, (x)inet usw. ausgelegt. Würde man systemd plötzlich zum Standard erheben und diese Tools ablösen, hätten viele Server-Admins ein Problem, weil sie ihre Deployments komplett überarbeiten müssten. Und daneben steht der Manager, der sich dann fragt wie wirtschaftlich der Einsatz von Linux wirklich ist, wenn die Admins wegen sowas viele Stunden Arbeitszeit verschwenden müssen und ihre Arbeit im Prinzip alle paar Jahre neu machen, weil irgendwer mal wieder irgendein innovatives Stück Software zum Standard erheben muss. Da bieten dann andere Systeme wie *BSD, OSX oder auch Windows die zuverlässigere Basis.

Warum ist der grosse Plan, Linux auf die Office-Desktops zu bringen, denn bisher gescheitert? Weil der Wartungsaufwand (u.a. durch ständige Änderungen und fehlende Abwärtskompatibilität) so hoch ist, dass die Kosten nicht wirklich unterhalb dessen liegen, was Lizenzkosten beim Einsatz von Macs oder Windows-PCs verursachen. Wer will, kann ja gern mal versuchen die alte Version von Kylix 3 auf einer heutigen Linux-Distro zum laufen zu bekommen. Erschien ca. 1 Jahr nach Windows XP. Als Vergleich nutzt man mal das alte Delphi auf einem aktuellen Windows. Dort läuft es auch heute noch. Auf Linux scheitert man ziemlich sicher wegen einer inkompatiblen Glibc.

Und warum wurde jetzt wohl ein LTS-Kernel eingeführt? Weil die Firmen, die Treiber für Linux entwickeln, sich über die ständig ändernden Schnittstellen im Kernel ärgerten. Dadurch waren immer wieder neue Versionen der Treiber notwendig. Solche ständigen Änderungen von den Hardware-Herstellern zu erwarten treibt 1. die Preise in die Höhe und 2. würden es sich Firmen wie Microsoft oder Apple niemals trauen sowas zu tun, weil ihnen damit ihre Unterstützer weglaufen würden. Die logische Konsequenz eines betroffenen Herstellers ist also, sich den Systemem zuzuwenden, die ihm weniger Aufwand/Kosten bei höherem Umsatz/Verkaufszahlen bringen, also Windows.

Mit Gewohnheit hat das also nicht wirklich zu tun sondern mit einem simplen Kosten-Nutzen-Faktor.
 
Zurück
Oben