systemd, der nächste Horror für BSD?

Status
Für weitere Antworten geschlossen.
Irgendwie sieht das alles ein wenig nach Microsoft s"Strangle and squeeze out"-Strategie aus den 90ern aus. Systemd ist ein Tumor, der sich überall rein frisst. Wenn es so weiter geht, wird es für Linux-Distros in absehbarer Zeit ein wichtigerer Systembestandteil als der Kernel sein. Schließlich hängt alles daran. Boot, Systemkonsole, Login, Lockin, /dev, Audio, IPC, X... Ohne systemd kein brauchbares System. Punkt. Und damit hat Red Hat - die bezahlen den Wahnsinn schließlich - die anderen Distros da, wo sie keinen Ärger mehr machen. Sie müssen systemd nehmen, durch systemd werden sie im Kern aber alle kleine Red Hats. Das neben dem Paketmanagement wichtigste Unterscheidungsmerkmal der Distros, die unterschiedliche Architektur mit verschiedenen Stärken und Schwächen, fällt damit raus. (also "Strangle") Wenn es aber keine nennenswerten Unterschiede in der Architektur mehr gibt, kann ich als kommerzieller Anwender auch gleich das "beste" Produkt nehmen. Kurz gesagt, das Produkt des Stärksten auf dem Markt. Und das ist wiederum Red Hat. (also "Squeeze out" der Konkurrenz) Ja, das klingt nun nach Verschwörungstheorie und wahrscheinlich plant das so auch niemand. Aber dennoch könnte diese Entwicklung - ob nun beabsichtigt oder nicht - mittelfristig genau dazu führen. Red Hat / Fedora / CentOS an der Spitze, alles weitere unter ferner liefen.
 
puuuh, direkt mal gucken, wie gut Percona unter 10.0 im Vergleich zu Linux läuft. Damit wären dann evtl. wieder der ein oder andere Linuxserver auf der Abschußliste :D
 
Ich vergaß, Weston die Referenzimplementierung von Wayland hat auch systemd Integration.
Hat Weston nicht sowieso alles mögliche integriert? Ich folge dem ganzen nur lose u.a. auf dev@suckless.org, und dort war das einer ger größten Kritikpunkte.
Linux nähert sich halt deutlich an Windows an, was die Technik angeht, was mich wirklich stört.
Irgendwann verzichten die auf Programme und Prozesse, dann gibts nurnoch dynamisch geladene solibs und Threads.
Bye bye Unix
 
Ach, irgendwann stellt an fest, dass doch alles doof ist und entwickelt eine Alternative... wäre ja nicht das erste Mal...
Ich vergaß, Weston die Referenzimplementierung von Wayland hat auch systemd Integration.

Weston ist nicht die Referenzimplementierung von Wayland, sondern ist die Referenzimplementierung eines Compositor _für_ Wayland. Es wird auch nicht sonderlich erwartet, dass Weston großartig Verwendung findet, sondern es dient dazu, die ganze Sache auch mal ausprobieren zu können. Es ist quasi der Forschungsgegenstand oder auch als "Eat your own dogfood" bezeichnet. Anders findet man Desgin-Fehler/Mängel in Wayland halt nicht so schnell.
 
Das muss nicht immer alles negativ sein, nur weil jetzt alles weiter und immer enger verzahnt wird. Portierungen werden so noch einfacher zwischen X und Y. Ja "systemd" ist gräbt sich sehr tief ins System aber wenn es funktioniert!? Das wollte man doch immer! Man wollte immer, dass sich die Distributionen annähern und nicht weiter auseinander driften...

Weston? Ist doch egal Gnome Cinnamon und KDE verwenden ihren eigenen Implementierungen.

Es wäre vielleicht eine gute Entscheidung, wenn sich die ganzen *BSD's zusammen tun würden und Wayland portieren. Es gab ja schon Patches in der Richtung. Wie soll es den im BSD Lager weiter gehen, wenn X gefallen ist?
 
Das muss nicht immer alles negativ sein, nur weil jetzt alles weiter und immer enger verzahnt wird. Portierungen werden so noch einfacher zwischen X und Y. Ja "systemd" ist gräbt sich sehr tief ins System aber wenn es funktioniert!? Das wollte man doch immer! Man wollte immer, dass sich die Distributionen annähern und nicht weiter auseinander driften...

Neil Brown, seines Zeichens Linux-Kernel-Entwickler und Vater von mdadm, hat einen interessanten Beitrag zum Thema geschrieben:

Ich habe jetzt systemd seit einiger Zeit privat unter archlinux im Einsatz und muss feststellen, nach anfänglicher Skepsis möchte ich es inzwischen nicht mehr missen.

Es wäre vielleicht eine gute Entscheidung, wenn sich die ganzen *BSD's zusammen tun würden und Wayland portieren. Es gab ja schon Patches in der Richtung. Wie soll es den im BSD Lager weiter gehen, wenn X gefallen ist?

Dafür ist der Schmerz noch nicht groß genug. X wird so schnell nicht fallen, das Siechtum wird sich noch viele Jahre hinziehen. :eek:

Bis dahin wird Stück für Stück immer mehr Software nicht mehr unter BSD laufen und die Apologeten werden unter den Steinen hervorgekrochen kommen und behaupten, dass genau diese Software sowieso niemand bräuchte. :belehren:
 
Das muss nicht immer alles negativ sein, nur weil jetzt alles weiter und immer enger verzahnt wird. Portierungen werden so noch einfacher zwischen X und Y. Ja "systemd" ist gräbt sich sehr tief ins System aber wenn es funktioniert!? Das wollte man doch immer! Man wollte immer, dass sich die Distributionen annähern und nicht weiter auseinander driften...

Weston? Ist doch egal Gnome Cinnamon und KDE verwenden ihren eigenen Implementierungen.

Es wäre vielleicht eine gute Entscheidung, wenn sich die ganzen *BSD's zusammen tun würden und Wayland portieren. Es gab ja schon Patches in der Richtung. Wie soll es den im BSD Lager weiter gehen, wenn X gefallen ist?

hi

sorry aber die verzahnung , bzw abhaengigkeit , macht linux fuer mich immer weniger sinnvoll fuer den server einsatz , da die zwaege die das mit sich bringt
kontra produktiv ist ( ich sach nur binaer logfiles , kein single user mode )


deweiteren wird es nie passieren das sich die verschiedenen bsds zu sammen tun , da der entwicklungs fucus der einzelnen bsds zu verschieden ist.

und sorry ich bleibe dabei systemd ist genauso unoetig wie udev.
wenn jemand schneller booten will so sich ne ssd kaufen .

holger
 
...da die zwaege die das mit sich bringt
kontra produktiv ist ( ich sach nur binaer logfiles , kein single user mode )
Wo ist der Unterschied wenn du "grep, tail etc." oder "journalctl" nutzt? Beides sind Binaries, die du brauchst und sei es von einer LiveCD.

wenn jemand schneller booten will so sich ne ssd kaufen
Sorry ich bin bei Leibe kein "systemd" Befürworter aber wenn man "systemd" nur mit schnellerem booten gleichsetzt, dann hat man das System nicht verstanden.
 
schnell booten war der erste grund fuer systemd zu entwickeln ( parralelles starten von processen beim booten )
davor waren alle gluecklich mit dem sysv init system


und schon mal ueberlegt das es bereiche und situationen gibt wo logfiles permanen ueberwacht werden ?

mit verschiedensten tools z.b. ossec .

diese brauchen klartext logs .

es ist schon ein problem einem security auditor fuer pci-dss zu verkaufen das openbsd die pf logs als binaerfile wegschreibt.

sorry systemd ist eine entwicklung in die falsche richtung .......... wie einige andere themen bei linux auch.
zumal unnoetig.

holger
 
Einfacher wäre es wenn systemd nicht fest verzahnt mit dem Linux Kernel ist, auch ist der Code Anteil mittlerweile beträchtlich. Meines Wissen ist udev ohne systemd auch an der Grenze zur Benutzbarkeit. Und zu KDE, Martin Gräßlin befürwortet eine Systemd Integration in KDE wie andere auch.
 
und schon mal ueberlegt das es bereiche und situationen gibt wo logfiles permanen ueberwacht werden ?
Rsyslog hat schon eine Schnittstelle zu "systemd" ich denke wa wird es sicher Wege geben.

http://www.linux-magazin.de/NEWS/Rsyslog-7.4.0-mit-Log-Signatur-und-Systemd-Anbindung

Meines Wissen ist udev ohne systemd auch an der Grenze zur Benutzbarkeit.
Udev soll mit systemd verschmelzen.

http://www.golem.de/news/linux-systemd-und-udev-werden-zusammengefuehrt-1204-90965.html

Da habe ich noch etwas! D-Bus soll in den Linux-Kernel

http://www.heise.de/open/meldung/D-Bus-soll-in-den-Linux-Kernel-1801341.html
 
KDBUS nicht D-BUS, das widerum mit systemd verzahnt wird. Systemd ist nicht portierbar, war aber allen klar. Den aktuellen Stand von udev kenn ich nicht, bisher verbreitet man das Gerücht man könnte sich Teile von systemd bedienen, ohne systemd als Init zu verwenden, IMHO Wunschdenken man könnte die Entwicklung aufhalten und eigene Versionen warten.
 
Ehrlich gesagt kann ich die Bgeisterung für systemd nicht so richtig teilen.
Es ist mir zu groß, zu invasiv und zu schlecht kontrollierbar. Wenn ich ein System möchte, bei dem ich nicht weiß, was es macht und auch kaum oder nur kryptischen Einfluß darauf habe, dann nehme ich ein Windows - Läuft irgendwie und ich weiß nicht warum.

Dasselbe stelle ich mehr und mehr bei meinem fedora fest. Ich bin jetzt bei 19 und es äuft irgendwie immer, aber manchmal auch nicht und ich weiß nicht mehr warum und kann es kaum beeinflussen.
 
Hat jemand schon mal eine stichhaltige Argumentation gesehen, die ueberzeugend darlegt, warum eine Abkehr von der Unix-Philosophie (auch POLA gehoert dazu) Sinn macht? Ich haette gedacht, dass solch eine Diskussion am Anfang solcher einschneidender Veraenderungen stehen muesste.

Fehlerfreie Software wird es schwerlich je geben. Je einfacher und ueberschaubarer aber ein Stueck Software gehalten ist, desto einfacher ist es einem User, der nicht unbedingt mit den Details dieser Software vertraut ist, diese Software zu bedienen und ggf. einen Fehler einzugrenzen und aufzuspueren.

Es ist ja leider nicht so, dass systemd der einzige Kandidat ist, der gegen solche Prinzipien verstoesst. Aber an diesem Beispiel kann man gut die Auswirkungen der Abkehr vom Prinzip studieren. Die "Insider" machen sich so unentbehrlich ...
 
Dasselbe stelle ich mehr und mehr bei meinem fedora fest. Ich bin jetzt bei 19 und es äuft irgendwie immer, aber manchmal auch nicht und ich weiß nicht mehr warum und kann es kaum beeinflussen.
Die letzte stabil laufende Version von Fedora war die 14. Danach unerklärliche Abstürze von DBus - man braucht sich nur die Bugreports zu Gnome-Terminal durchlesen...
 
Hat jemand schon mal eine stichhaltige Argumentation gesehen, die ueberzeugend darlegt, warum eine Abkehr von der Unix-Philosophie (auch POLA gehoert dazu) Sinn macht? Ich haette gedacht, dass solch eine Diskussion am Anfang solcher einschneidender Veraenderungen stehen muesste.
An ein Argument kann ich mich noch genau erinnern: systemd soll das Starten von Systemdiensten zuverlässiger und überwachbarer machen als SysV-Init. Bis jetzt habe ich allerdings davon nix gemerkt: Prompt für Passwort für Freischaltung einer verschlüsselten Partition gibt es nicht, DBus-Daemon stürzt ab, ohne das systemd es merkt (Fedora 17)
 
Na ja Fedora ist allgemein nicht gerade "stabil". Ob das jetzt alles mit "systemd" zusammen hängt, kann man wirklich nicht sagen.
 
Hat jemand schon mal eine stichhaltige Argumentation gesehen, die ueberzeugend darlegt, warum eine Abkehr von der Unix-Philosophie (auch POLA gehoert dazu) Sinn macht?

Wie nah oder fern systemd an der Unix-Philosophie ist, ist die Frage (vgl. http://0pointer.de/blog/projects/the-biggest-myths.html Punkt 10).

Unabhängig davon muss man systemd attestieren, dass es verflucht viele Probleme eines modernen Unix löst, die mit SysVinit faktisch nicht oder teilweise nur mit haarsträubenden Krücken lösbar sind (vgl. http://0pointer.de/blog/projects/why.html). Es hat schon einen Grund, warum so viele Projekte inzwischen auf den systemd-Zug aufgesprungen sind.

Ich haette gedacht, dass solch eine Diskussion am Anfang solcher einschneidender Veraenderungen stehen muesste.

Die Diskussion läuft schon seit Jahren, aber durch die unterschiedlichen Interessenslagen (man darf upstart in dem Gemenge nicht vergessen) dreht sich die Diskussion im Kreis. Momentan sieht es so aus, also würde systemd sich durchsetzen, weil es reale Probleme statt philosophischer Fragen löst.

Fehlerfreie Software wird es schwerlich je geben. Je einfacher und ueberschaubarer aber ein Stueck Software gehalten ist, desto einfacher ist es einem User, der nicht unbedingt mit den Details dieser Software vertraut ist, diese Software zu bedienen und ggf. einen Fehler einzugrenzen und aufzuspueren.

Korrekt. ZFS ist zum Beispiel ein extrem komplexes Stück Software im krassen Widerspruch zur Unix-Philosophie (https://blogs.oracle.com/bonwick/entry/rampant_layering_violation), macht unterm Strich dem User das Leben unterm Strich aber deutlich einfacher.
Ist das jetzt gut oder schlecht?

Es ist ja leider nicht so, dass systemd der einzige Kandidat ist, der gegen solche Prinzipien verstoesst. Aber an diesem Beispiel kann man gut die Auswirkungen der Abkehr vom Prinzip studieren. Die "Insider" machen sich so unentbehrlich ...

Momentan ist systemd das Projekt, das die anstehenden Probleme löst. Aus dem SysVinit-Lager hört man außer Kritik wenig Input, wie sie die zeitgenössischen Anforderungen denn in den Griff kriegen wollen.
 
Zuletzt bearbeitet:
Noch ein Punkt zum Verletzen der Unix Philosophi, das tun neben ZFS auch X. Nur im Gegensatz zu systemd sind die Auswirkungen begrenzt weil man erstens sich Gedanken über Alternativen macht/machte und zweitens sich nicht quer durch alle Bereiche frisst. Systemd setzt auf aktuelle Kernelfeatures und gibt diese dann weiter an Anwendungsprogramme. Dies macht das komplette Ökosystem von FLOSS kaputt weil damit jede Portierung bedeutet eine Lösung für Kernelfeatures zu finden.
 
Wie nah oder fern systemd an der Unix-Philosophie ist, ist die Frage (vgl. http://0pointer.de/blog/projects/the-biggest-myths.html Punkt 10).

Ich habe diesen Punkt mal zusammen gefasst:
  • systemd nutzt "alles ist eine Datei"
  • systemd bietet multi-seat (nicht als Terminal wie das Origianl-Unix, weil das nicht zeitgemaess ist)
  • systemd ist eine Sammlung von integrierten Werkzeugen, die alle eigenen Zwecken dienen und zusammen mehr sind, als die Summe der Teile
  • die Entwicklung wird so aehnlich wie bei BSD verwaltet, BSD ist Unix (also wird die Entwicklung so aehnlich wie bei Unix verwaltet)

Unabhängig davon muss man systemd attestieren, dass es verflucht viele Probleme eines modernen Unix löst, die mit SysVinit faktisch nicht oder teilweise nur mit haarsträubenden Krücken lösbar sind (vgl. http://0pointer.de/blog/projects/why.html).
Welche Probleme hat ein modernes Unix? In der Liste finde ich "verflucht viele" Features, die Probleme loesen, die es aus meiner Sicht bei einem modernen Unix nicht gibt. Was gibt es fuer ein Problem, wenn die Shell ins Booten involviert ist? Wo gibt es Probleme mit der gewoehnlichen Art zu mounten oder auto-zu-mounte? Welches Problem loest Plymouth?

Es hat schon einen Grund, warum so viele Projekte inzwischen auf den systemd-Zug aufgesprungen sind.
Ich denke, den Grund hat Yamagi schon benannt: Wenn immer mehr Programme ohne systemd nicht mehr funktionieren, so waere jeder Distributor, der am Fortbestand seiner Distribution interessiert ist, dumm nicht auch auf den Zug aufzuspringen ...

Korrekt. ZFS ist zum Beispiel ein extrem komplexes Stück Software im krassen Widerspruch zur Unix-Philosophie (https://blogs.oracle.com/bonwick/entry/rampant_layering_violation), macht unterm Strich dem User das Leben unterm Strich aber deutlich einfacher.
Ist das jetzt gut oder schlecht?
Das finde ich interessant. Es stimmt.
Allerdings werden ja gerade in dem Artikel Gruende dafuer genannt, warum es Sinn macht, von der Philosophie abzuweichen.


Hier habe ich einige interessante Aspekte/Argumentationen zu dem Thema gefunden:
https://wiki.debian.org/Debate/initsystem/
https://wiki.debian.org/Debate/initsystem/sysvinit
https://wiki.debian.org/Debate/initsystem/systemd
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben