News Debian wählt mit Systemd ein neues Init-System

Freut mich als Debian-Nutzer. Danke für die Hintergrundstory. Schön zu sehen, wie demokratisch das System hinter Debian ist.
 
Debian pflegt viele Architekturen, darunter auch GNU Hurd und kFreeBSD, die beide Systemd nicht unterstützen, da deren Betriebssystemkern keine Cgroups unterstützt. Systemd funktioniert aber aus technischen Gründen nur unter Linux, nicht aber unter anderen unixoiden Systemen wie BSD.

Ist mMn ein wenig missverständlich formuliert, die technischen Gründe, warum systemd nicht unter anderen unixoiden läuft sind genau die im ersten Satz erwähnten cgroups.
 
Schöner Artikel :)

Ich hoffe das auch wirklich Systemd das Rennen macht - wie im Artikel erwähnt ist die Entscheidung noch nicht entgültig.
 
NemesisFS schrieb:
Ist mMn ein wenig missverständlich formuliert, die technischen Gründe, warum systemd nicht unter anderen unixoiden läuft sind genau die im ersten Satz erwähnten cgroups.

Da ist wohl was übrig geblieben, was weg kann, danke :)
 
Wie bei fethomm üblich, mal wieder ein sehr schöner Artikel. Kannte das Thema zuvor nicht, aber dadurch, dass hier nicht nur die News erwähnt wird sondern auch ein bisschen die Problematik diskutiert wird, wird man zum recherchieren angeregt ;)
 
Also ich finde systemd Klasse, Archlinux setzt schon eine Weile darauf und ich kann gut damit arbeiten.

Trotzdem frage ich mich, ob die Wahl für Debian die richtige ist, ich kann den Frust an manchen Stellen schon nachvollziehen, so richtig in die Debian Philosophie passt das nicht. Trotzdem auf jeden Fall besser, als Upstart zu wählen!
 
...welche Software in Zukunft Debian-Installationen starten soll und somit den ersten Prozess PID 1 aufruft.
Ist das so nicht teilweise falsch? Entweder halt "Prozess ID 1" oder " PID 1". Aber "Prozess PID 1" ist doch im Grunde ähnlich wie "LCD Display"!

Ansonsten könnte man den Artikel noch um Sailfish OS ergänzen als Beispiel für systemd Nutzende Systeme, dürfte ganz Interessant sein das es auch schon auf dem Smartphone läuft!


@Topic:
Ich hoffe mal es bleibt bei systemd. Wenn jetzt nochmal eine ewige Diskussion startet samt neuem Vote, wirds mit Debian 8 Jessie noch länger dauern.


LeX23 schrieb:
Ob das eine gute Entscheidung war...
Es gibt wohl einige die davon weniger begeistert sind.
http://wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd
Naja, wie soll man einen solch sinnlosen Müll überhaupt ernst nehmen?
Geht ja schon los mit:
Systemd is a critical component of many Linux systems. I fucking hate it.
Fanboys und Hater schreiben halt ziemlich viel crap. In dem ganzen Text gehts ja nur darum das SysV Init das beste ist, Upstart ist beschissen, und systemd noch beschissener. Alles was nicht exakt wie SysV Init Funktioniert ist ebenfalls beschissen. Von daher kann man den ganzen Text in die Tonne kloppen.
 
Zuletzt bearbeitet:
And many shitstorms were had. Aber jetzt, wo dieses Kapitel nun gegessen ist, müssen wir nicht auf unsere Popcornunterhaltung verzichten, ich bin zuversichtlich, dass Kdbus genauso unterhaltsam wird. Mir ist das ganze Thema ziemlich egal, solange Lennart nicht fordert, dass Linux ab sofort Poettering/Linux genannt wird. :p

Passiert das eigentlich beim Artikel-Schreiben automatisch, dass englische Wikipedialinks durch die deutschen ersetzt werden? Letztere gibt es nämlich nicht unbedingt immer.

LeX23 schrieb:

Es gibt sehr wohl Gründe gegen SysV Init, das kann man schon ganz alleine daran sehen, dass die Leute von Debian, die so ziemlich größten Stabilitätsnazis in der gesamten Linuxwelt, sich einig sind, dass der alte Kram weg muss. Ja, Systemd schluckt alles wie ein schwarzes Loch, aber Schriftstücke wie dieses sind der Grund, warum ich die meisten Systemd Gegner einfach nicht ernst nehmen kann. In Capslock was über MUH UNIX PRINCIPLES zu brüllen hilft der Glaubwürdigkeit nicht unbedingt. Außerdem:

Linux is, first and foremost, a Unix

Nicht wirklich. Linux ist nicht Unix, Linux ist Linux. Gerade MUH UNIX PRINCIPLES sind wirklich schon lange nicht mehr erfüllt (oder waren es nie), da ist Systemd nur ein weiterer Schritt.

Der Text wirkt fast, als wäre er von Poettering selbst als Reverse-Troll verfasst worden, denn so macht das nichts anderes, als die Aussage von ihm persönlich zu untermauern, dass das am Ende des Tages alles egal ist, außer deine „Religion ist Unix“ oder wie er sich ausgedrückt hat.
 
Zehkul schrieb:
And many shitstorms were had. Aber jetzt, wo dieses Kapitel nun gegessen ist, müssen wir nicht auf unsere Popcornunterhaltung verzichten, ich bin zuversichtlich, dass Kdbus genauso unterhaltsam wird. Mir ist das ganze Thema ziemlich egal, solange Lennart nicht fordert, dass Linux ab sofort Poettering/Linux genannt wird. :p...

Kdbus wird sicher interessant, vor allem, weil Linus da auch mitmachen darf ;)
 
freu mich für die debian-user.

hoffentlich werden sie aber nicht so wie ich vor 1.5 jahren bei archlinux damit überraschend ins kalte wasser geworfen, sondern bekommen einen sauberen übergang. das war ein spass damals... auf einmal bootete linux nicht mehr nach dem update und ich hatte keinen plan wieso.

trotzdem war ich im nachhinein sehr froh über den wechsel. systemd wirkt einfach viel aufgeräumter als sysvinit, bootup und shutdown sehen cooler aus und man kann es komplett über die console konfigurieren.
 
Bolko schrieb:
Muss man da irgend etwas beachten, wenn man von Debian 7.x einen "apt-get dist-upgrade" macht oder funktioniert das automatisch?

In Debian 7 brauchst du kein dist-upgrade, bestenfalls upgrade. Gerade ist 7.4 herausgekommen mit Sicherheitsupdates und Fehlerbehebungen. Mehr Neues gibt es hald bei Debian STable nicht.
 
Von mir gibt es auch ein Lob für den Artikel - schön gut - lang, aber hat einen einfach mitgezogen weiter zu lesen :) und nichts gekünstelt in die länge gezogen - topp :)
 
Bin gespannt, wie Systemd in einem Jahr dann aussieht. Entweder funktioniert Systemd, dann ist das doch okay. Oder wir bekommen eine debiantypische kreative Lösung. :-)
 
Systemd ist nunmal die Wahl des geringeren Übels. Schon klar, dass ein Packet-Maintainer gerne sein eigenes Paket durchdrücken will, aber ich finde es unverschämt eine Entscheidung immer wieder hinaus zu zögern. Vielleicht sollte dort mal über eine Neubesetzung nachgedacht werden :p
 
(Ich picke jetzt nicht einen einzelnen User bewusst raus, aber bei Zehkul sind einige Argumente versammelt…
Zehkul schrieb:
[…]solange Lennart nicht fordert, dass Linux ab sofort Poettering/Linux genannt wird. :p
IMHO sagt die Vergangenheit: Nicht mehr weit weg.

Ich habe noch keine schluessigen Argumente gehört, was systemd so fundamental besser macht als andere Init-Systeme.
Zehkul schrieb:
[…]dass die Leute von Debian, die so ziemlich größten Stabilitätsnazis in der gesamten
Linuxwelt[…]
Uuuuund Abseits, Schaufel her, Nivea ausgraben! Auf dem Niveau braucht man nicht zu diskutieren.
(Zumal Stabilitaet das ist was man haben will, alles andere kostet i.A. Zeit und (damit) Geld, Nerven etc.
Unternehmen geben ungern Geld aus nur weil dem Herrn Poettering daran liegt vorhandene Funktionalitaet zu vermindern,
und ich moechte ungern die Mehrarbeit, die Microsoft seinen Usern aufdrueckt auch den Linux-Usern aufgedrueckt sehen!

Die Entwickler von systemd haben in er Vergangenheit oft genug gezeigt, dass sie auf vorhadene, "verstandene" und stabile
Technik nicht viel geben und anderen Leuten das Leben schwer machen, on purpose. Beispielsweise gab es Aenderungen an
udev, was mehr oder minder in systemd integriert wurde, die fuer andere udev-Nutzer teilw. schwere Nachteile nach sich
zogen. Nicht zuletzt hat gentoo udev geforked, um weiterhin separat (sprich: spaeter im bootprozess gemountetes) /usr zu
ermoeglichen, wofuer es genuegend Einsatzszenarien gibt. Fuer diese Szenarien unnoetigerweise (die Kernel-Entwickler
sagen da gerne "Don't break user space") eine initr* zu fordern lastet den Aufwand den Usern auf, die im Endeffekt fuer
die (wieder IMHO) Faukheit und insbesondere Ignoranz der systemd-Entwickler buessen muessen.

Zehkul schrieb:
[…]In Capslock was über MUH UNIX PRINCIPLES zu brüllen hilft der Glaubwürdigkeit nicht unbedingt.
Joa korrekt, genausowenig wie die gern gebrachte These, dass systemd alle Probleme loessen wuerde. Was ist schlecht an
diesen unix priniciples? Ueber corner cases kann man sich streiten, aber PID 1 ist der wichtigste Prozess im System, wenn
da was schieff laeufft ist alles verloren und schlecht zu debuggen. Darum gerade haellt man am Unix Credo fest, es hat
sich einfach bewehrt und funktioniert seit vielen Jahren!

Zehkul schrieb:
[…]Nicht wirklich. Linux ist nicht Unix, Linux ist Linux. Gerade MUH UNIX PRINCIPLES sind
wirklich schon lange nicht mehr erfüllt (oder waren es nie), da ist Systemd nur ein weiterer Schritt.
Woher
nimmst du diese Bestimmtheit? Die meisten Tools, die (zum. bei Debian und einigen anderen) unter der Haube arbeiten
verlassen sich auf grep, sed, cat, die quasi seit Menschen gedenken genau dieses Credo erfuellen, worauf man sich (die
versch. sed-implementierungen mal ausser Acht gelassen) verlassen kann, was einfach tut. These durch Gegenbeispiel
Wiederlegt, warte auf shitstorm.

Der gute Poettering hat auch mehrfach unter Beweiss gestellt, dass er nichts auf das alte (Stichwort "alt") gibt, das
mehrfach, immer wieder bewiesen hat und beweisst, dass man sich darauf verlassen kann. Genauso wurde unter Beweiss
gestellt, dass die systemd-Entwickler keinen Pfennig drauf geben, mit bisherigen Loesungen kompatibel zu sein (udev als
gutes Beispiel, viele Aenderungen haben Distributionen probleme gemacht oder waren nicht mit Grundsaetzen vereinbar und
haben damit Mehraufwand fuer Maintainer verursacht).

Was ist denn bitte das (die?) Killer-Features die systemd ggue. bisherigen Loesungen bietet? sysvinit hat bekannte(!)
Probleme, Gentoo bspw. hat mit OpenRC ein paralleles, gut funktionierendes init-system auf die Beine gestellt. Dazu kommt
es mit so vor als wuerden hier Feature-Wuensche definiert, die so nicht vorhanden sind (analog zu Microsoft) (bspw.
Bisher habe ich so tolle sachen gehoert wie "System startet 5 Sekunden schneller" | In 5 Sekunden
Ah, in 5 Sekunden steht bei mir mit unoptimiertem Bootprozess unter OpenRC schon der KDE Logon Screen auf einem 6 Jahre
alten Notebook, viele die diese Argumente bringen nutzen dazu generische Kernel mit riesiger initr*, die bekanntermassen
ewig brauchen alle Treiber zu proben.
Systemd ist auch nicht modular wie oft angepriesen wird, im Gegenteil. Alles ist sehr eng verzahnt, Teilprozesse sind
kaum aus dem ganzen herauszuloesen, zumal es quasi keine API (-Doc) gibt nachdem man Alternativen entwickeln koennte!
(Friss oder stirb, warum braucht ein Desktop-System (Gnome3) Komponenten eines INIT-Systems?! Das eine hat mit dem Anderen nichts, aber auch garnichts zu tun… Ausser natuerlich man definiert sich wieder mal bisher nicht vorhandene Feature-Requests und Verlangen herbei... Persoenlich habe ich das grade bei der als "Hipster" bezeichneten Personengruppe im Informatikerbereich gesehen, brachte jeweils nur ebendiese "Hipster" weiter. Ich moechte niemanden in eine Schublade stecken, aber meine Erfahrung spricht sehr gegen solche Vorgehensweisen, da sie der Allgemeinheit nicht dienlich sind.)
Auch hoert man haeuffig, das System wache schneller auf/schlafe schneller ein, was eher ein optimiertes System bietet
als ein INIT-Prozess, der damit eh nicht viel am Hut hat. Auch hier: o.g. laptop braucht 3 Sekunden fuer s2r/wakeup, aenliches wurde mir von mehreren Personen berichtet. Argument wiederlegt, es geht auch ohne.

Dazu kommt das ganze nachgelagerte Zeugs
journald: "Sicherer, User koennen keine logs mehr lesen und damit Sicherheitsluecken finden!" Wenn User alles /var/log
lesen koennen hat der Admin das Handbuch nicht gelesen!! Binaere logs erschweren die Fehlersuche, zumal sie nicht so
leicht "korrumpieren" wie binaere logs (Ich habe miterlebt dass Admins wegen "korruptem journal" Dinge nicht
nachvollziehen konnten, der parallel laufende syslog daemon aber brav alles in Files gedumped hat und dazu noch uebers
Netz an eine Logauswertung geschickt hat, wodurch dann die QA die Probleme sofort gefunden hat!)
Wieder mal: Schwaechen vorhandener Systeme sind bekannt, Workarounds ebenso! Analog: "Mir gefaellt $syntaxdetail in
$Sprache nicht, machen wir eine neue Programmiesprache um alle Probleme zu loessen!"

Settingsd: Ah, wieder mal jemand der sich unter linux eine Registry wuenscht! Ich sehe zwar die Vorteile, eine gemeinsame
Schnittstelle fuer das lesen von Files mit text/pain aus /etc zu lesen, aber ein daemon? Windows laesst gruessen, mir ist
der ram zu schade den der daemon braucht, da mach ich lieber execve auf bekannte (alte, bekanntermassen funktionierende)
tools die jedes System mitbringt.

Neulich lass ich, dass das netzwerkmodul von systemd nun auch bridges koenne. Super, gross angekuendigt dass es das kann, was andere Systeme, selbst ein banales /etc/rc.local-Script seit vielen Jahren koennen (Gentoo hat uebrigends mit netifrc einen Netzwerk-Layer geschaffen, der einfach und straight-forward noch so einiges mehr kann und seit Jahren (damals war die Scriptsammlung noch Teil von OpenRC) erfolgreich eingesetzt wird.

Was macht eine Distribution, die mehr als Linux unterstuetzt? Wieder Friss oder Stirb, fuer *BSD, Hurd et al muessen die
jeweiligen Maintainer selber sachen basteln, wo bisher ueberhaupt kein Bedarf bestand weil die alten, bekanntermassen
funktionierenden Tools (wiederhole ich diese Aussage etwa?) schon lange auf diesen Systemen funktionierten, hier wird
also bewusst die Kompatibilitaet gebrochen und die Arbeit dafuer outgesourced auf die Distris, die schon genug zu tun
haben!

Aludrin schrieb:
Systemd ist nunmal die Wahl des geringeren Übels.
-1, wie oben dargestellt erzeugt es
nur Mehrarbeit. Der Enduser sieht davon meistens nicht viel, weil hinter den Kulissen die Maintainer schuften!
Aludrin schrieb:
klar, dass ein Packet-Maintainer gerne sein eigenes Paket durchdrücken will, aber ich finde
es unverschämt eine Entscheidung immer wieder hinaus zu zögern.
Imho stellen sich die systemd-Entwickler
(man wiederlege mir das mit geeingeten Argumenten), aenlich auf wie in folgendem Zitat aus Orion, wenn auch nicht ganz
so offensiv: "Wir sind wir, und wenn nicht sprechen eben unsere Lichtwerferbatterien!". Es hat sich wie oben schon
angesprochen schon mehfach gezeigt, dass die systemd-Entwickler einen Kotbrocken auf andere geben, solange ihr System
eingesetzt wird. Ego und so
Aludrin schrieb:
Vielleicht sollte dort mal über eine Neubesetzung nachgedacht werden
:p
Gerne, dann kommen vielleicht wieder Leute dran, die keine Lust auf quengelnde User und instabile Systeme
haben... Oh, damit sind wir wieder bei den Leuten von Damals™, aber das is ja lange ueberholt, das muss alles radikal
neu gemacht werden, ohne Ruecksicht auf Verluste weil unser System ist das einzig wahre, wer es nicht einsetzt ist halt
selber schuld. Kommt mir aus der Politik mancher Staaten und Zeiten bekannt vor.

Alles IMHO, selbstverstaendlich.

Zum lesen: SYSTEMD PROPAGANDA: IT'S A CRAP!
 
Danke für den Artikel, die Story hab ich gar nicht mitbekommen. :) Wenn ich ehrlich sein soll, trauere ich immer noch SysVinit nach. Vor allem jounald ist ein Graus... Aber eine bessere Variante als Upstart ist es allenfalls, von daher: Gute Entscheidung!
 
Photon schrieb:
Danke für den Artikel, die Story hab ich gar nicht mitbekommen. :) Wenn ich ehrlich sein soll, trauere ich immer noch SysVinit nach. Vor allem jounald ist ein Graus... Aber eine bessere Variante als Upstart ist es allenfalls, von daher: Gute Entscheidung!

Was findest Du denn an Journal schlimm? Ich finde es wesentlich besser als rsyslog. Die Kritik, man solle doch bei einem flachen Textformat bleiben anstatt Binaries für Logs anzuwenden kann ich nicht ganz nachvollziehen. Die Auswertungsmöglichkeiten sind meiner Meinung nach so viel besser bei Journal.
 
Zurück
Oben