Debians Init-System der Zukunft

[runsnake]

Na toll, als hätte ich es nicht geahnt.

Es würde mich nicht wundern, wenn man demnächst gleich noch Gnome als Standartdesktop erklären würde, es stand ja schon einmal zur Debatte.

Immerhin ist der Gnome jetzt schon teilweise von Systemd abhängig und wenn die beiden so schön ineinandergreifen, performen sie am Ende wahrscheinlich besser alles andere, oder die anderen werden ebenfalls abhängig von Systemd.

Nur dummerweise hat man dann ein total voneinander abhängigen Kram an der Backe, womit zukünftige Neuheiten erstmal schlechtere Karten haben.

Ich werde einfach das Openrc benutzen, damit Dienste parallel gestartet werden.

Auf ein paar Millisekunden mehr oder weniger kommt es dann auch nicht mehr an.

Und wenn Openrc nur für Kfreebsd und Hurd portiert wird, nehme ich gleich Freebsd.

Schon alleine wegen der guten, alten UNIX-Philosophie.

Wenn ich solche komplexen Codekonstrukte wie Systemd im System haben wollte, dann könnte ich ja gleich Windoof nehmen.

[schorsch_76]

Ok, muss man erstmal hinnehmen diese Entscheidung.

Aber: Ist es die DL oder die DT Lösung? Das hab ich jetzt nicht rausgelesen? Sprich darf Software vom Initsystem abhängen? Werden andere Initsysteme wie das alte sysvinit weiter gepflegt?

[runsnake]

Zumindest wurde vor kurzem ein neues Paket aufgenommen, womit sich ein anderes Init-System auswählen lässt (dpkg-reconfigure).

Der Name will mir gerade nicht einfallen.

[JTH]

Der Name will mir gerade nicht einfallen.

init-select

[Dogge]

Cool kannte ich noch gar nicht. Unterscheidet sich das irgendwie zum init= ... in der Grub-config?

[runsnake]

Scheinbar nein:

This tool currently only supports the GRUB boot loader.

[Evox]

Brauche keine Monster auf ein Server und Bloatware Distributionen gibt es nun wirklich zu genüge. Es reicht nicht das Desktops unnötig Aufgeblasen werden, nein jetzt muss das ganze System verunstaltet werden. Typisch Mainstream bekommt den Hals auch nicht Voll und bei kleinste Probleme immer gleich nach "Mama" schreien, hier mach Mal.
Bisher immer die Debian Flagge oben getragen und jeden dazu Ermuntert wenigstens als Alternative zu Installieren, ist wirklich sehr Schade soviel Jahre und dann so was.

[Radfahrer]

Auch Ubuntu wird auf SystemD umsteigen:

http://blog.stefan-betz.net/2014/02/14/ ... pAlles+%28

[dufty2]

Auch Ubuntu wird auf SystemD umsteigen:

http://blog.stefan-betz.net/2014/02/14/ ... pAlles+%28

Sehr vernünftiges Posting von Mark.
Hät ich ihm gar nicht zugetraut

[4A4B]

Auch Scott James Remnant, der erste Entwickler von Upstart, hält Systemd für eine gute Wahl:

https://plus.google.com/u/0/+ScottJames ... eHMc2tvp7C

[ctwx]

Hier noch direkt aus Shuttleworth's Blog: http://www.markshuttleworth.com/archives/1316

[Milbret]

Will zwar nicht der schwarze Peter sein aber ich halte Shuttleworths Umschwung nur für die Erkentniss das Upstart keine Zukunft hat.
Deshalb muss er sich geschlagen geben, da aktuell wohl die ganze Situation bei Ubuntu immer problematischer wird.

Ich habe das Gefühl, dass Mark Shuttleworth am liebsten Debian die ganze Entwicklung aufdrücken möchte und sich nur noch bedienen muss.
Aktuell gibt es auch einen tollen Krach mit Linux Mint über Binär Pakete aus Ubuntu und deren Lizensierung.
Ubuntu und Shuttleworth sind mit seit langen absolut unsympathisch.

Ich halte die nur für einen Strategiewechsel von Shuttleworth.
Wahrscheinlich knickt er auch demnächst bei seiner Eigenentwicklung Mir ein und springt auch auf Wayland um.
Ist alles nur Strategie um Kosten zu drücken.

Nachtrag:
Was Systemd angeht -> Das System ist mir aktuell zu fett und verstößt gegen gewisse Unix Prinzipien und scheint sich auch schon zum eigenen OS zu entwickeln.
Auch wird es wegen Portierbarkeit für Debian wahrscheinlich noch schwerer werden.

Mich stört vorallem, dass die System Logs wohl in einem eigenen Format gespeichert werden und man ein extra Programm zum auslesen braucht.
Aus meiner Sicht ist das Müll.

Martin

[wanne]

Trotzdem begrßenswert.

[catdog2]

Ich habe das Gefühl, dass Mark Shuttleworth am liebsten Debian die ganze Entwicklung aufdrücken möchte und sich nur noch bedienen muss.

Ja. War schon immer so, dass er die Arbeit anderen aufdrücken wollte und ist in letzter Zeit noch schlimmer geworden. Bei Canonical ist man sich da wohl für nichts zu schade: https://plus.google.com/+MartinGr%C3%A4 ... APGX3pHR2H

[nudgegoonies]

Kann eigentlich mal jemand verkünden wie die Sache jetzt genau aussieht bzw. weitergeht? Was eben durch die Medien ging, ist dass SystemD Standard wird. Punkt. Das impliziert aber so viele Folgefragen, z.b. fliegen kFreeBSD und Hurd raus oder machen deren Leute mit SysVInit weiter, was bedeuten würde das doch zwei Initsysteme gepflegt werden bei denen man auch unter Linux wählen könnte, kommt kdbus als nächster "Segen", etc.

[Saxman]

Kann eigentlich mal jemand verkünden wie die Sache jetzt genau aussieht bzw. weitergeht? Was eben durch die Medien ging, ist dass SystemD Standard wird. Punkt.

Nachdem sich das TC für Systemd entschieden hat und mittlerweile selbst Canonical Systemd favorisiert, schaut die Lage für Upstart selbst bei einer GR schlecht aus. OpenRC hatte letztlich auch nur eine Außenseitenrolle. Spricht also alles dafür, dass es bei Systemd bleibt.

Das impliziert aber so viele Folgefragen, z.b. fliegen kFreeBSD und Hurd raus oder machen deren Leute mit SysVInit weiter, was bedeuten würde das doch zwei Initsysteme gepflegt werden bei denen man auch unter Linux wählen könnte, kommt kdbus als nächster "Segen", etc.

Da ist schon die nächste Diskussion im Gange, über das zukünftige Init-System für Nicht-Linux Platformen.

[nudgegoonies]

Da ist schon die nächste Diskussion im Gange, über das zukünftige Init-System für Nicht-Linux Platformen.

Mit etwas Glück bedeutet dass vielleicht, das man auch unter Linux dieses "zukünftige" Init-System statt SystemD wählen kann. Zumindest die Leute, die kein Gnome verwenden.

[catdog2]

Da Problem mit den non Linux Ports hat man sowiso sowohl bei systemd als auch bei upstart. Bei upstart stünde Upstream zwar einer Portierung nicht im Weg aber machen muss das auch erst mal wer. Nur bei openrc wäre es wohl weniger problematisch weil gentoo auch non Linux Ports betreibt.

Da ist schon die nächste Diskussion im Gange, über das zukünftige Init-System für Nicht-Linux Platformen.

Die Diskussion ist auch sicher nötig und es wäre seltsam, wenn sie nicht geführt würde.

Mit etwas Glück bedeutet dass vielleicht, das man auch unter Linux dieses "zukünftige" Init-System statt SystemD wählen kann. Zumindest die Leute, die kein Gnome verwenden.

Eventuell Glück für die systemd hater.

[nudgegoonies]

So langsam wird ein Betriebssystem draus http://www.heise.de/open/meldung/Init-P ... 19141.html

[Milbret]

So langsam wird ein Betriebssystem draus http://www.heise.de/open/meldung/Init-P ... 19141.html

Traurig aber wahr.
Ich mag Systemd nicht besonders, da es schon mehr als nur ein init System ist.
Es überfüllt sich selbst, was mich sehr stört.

Ein Init System soll sich nur um den Bootvorgang kümmern. Punkt.
Alles andere sind nette Features die aber nicht in ein Init System gehören.

Martin

[cosmac]

Da ist schon die nächste Diskussion im Gange, über das zukünftige Init-System für Nicht-Linux Platformen.

Mit etwas Glück bedeutet dass vielleicht, das man auch unter Linux dieses "zukünftige" Init-System statt SystemD wählen kann. Zumindest die Leute, die kein Gnome verwenden.

Die Diskussion ist lesenswert -- keine Schimpfworte und Beleidigungen, man kann jetzt wieder vernünftig über technische Details reden. Ich hab' den Eindruck, die Chancen stehen nicht schlecht für mehr als ein Init-System.
Ein interessanter Link war auch dabei:
http://blogs.gnome.org/mclasen/2014/02/ ... rtability/
demnach war "gnome setzt systemd voraus" ein Gerücht aus dem Wahlkampf...

Ein Init System soll sich nur um den Bootvorgang kümmern. Punkt.

deshalb heißt das Teil ja auch "systemd" und nicht "initd"

[Milbret]

@cosmac
Soweit mir aber bekannt war sollte systemd "nur" ein init Ersatz werden.
Und init hat eben keine weiteren Aufgaben als sich um den Bootvorgang zu kümmern.

Entsprechend habe ich auch eine Ablehende Haltung zu systemd, da es sich zu einem Monster verwandelt, dass sich nicht an gewisse Vorgehensweisen aus der Unix Welt hält.
So ignoriert man dort das KISS Prinzip völlig.
Ebenfalls braucht man ein extra Tool um die systemd Log, die in einem nicht Lesbaren Format gespeichert werden, auslesen zu können.
Hier verlang systemd also, dass man komplette Aufgaben an ein Tool auslagern soll.

Dies ist für mich ein Versuch gewisse Paradigmen zu unterlaufen und dann auch noch eine riesige Abhängigkeit zu schaffen.
Sowas wiederspricht aber dem aktuellen Status Quo.

Nimm es mir nicht übel aber ich kann system nicht leiden, da es die Paradigmen die Unix und eben später auch Linux soweit gebracht haben komplett über Bord wirft.
Und durch die Abhängiokeiten bei den Distributionen festigt hier Red Hat ebenfalls noch Abhängikeiten für die eigenen Geschäfte.
Ich halte deshalb systemd auch als einen Versuch hier ein gewisses Monopol mit Einflussmöglichkeiten zu schaffen.

Klingt zwar nach Verschwörung, könnte sich aber in Zukunft auch als Wahr erweisen )

Martin

[nudgegoonies]

Ein Init System soll sich nur um den Bootvorgang kümmern. Punkt.

deshalb heißt das Teil ja auch "systemd" und nicht "initd"

Der Name ist wirklich unpassend, sie sollten es operatingsystemd nennen

Die Sache bezüglich KISS Prinzip müsste man sich genauer ansehen. Grob draufgeschaut: Aus dem Quellpaket werden 20 Binärpakete gebaut und das wichtigste davon, das systemd Paket, enthält alleine schon 21 ausführbare Dateien. So ganz un-modular scheint es zumindest mir auf den ersten Blick gar nicht zu sein. Ein großer Blob ist es zumindest nicht.

Ich bin mal neugierig, ob sich das wirklich durchsetzen wird. Man denke nur mal an ifconfig und netstat. Solange die noch paketiert werden sehe ich keinen Grund mich auf ip und ss umzugewöhnen. Ich habe keine Vorteile gefunden bzw. nichts vermisst und habe nur den Nachteil, mich umgewöhnen zu müssen. Also mache ich es halt nicht. Und solange systemd init.d scripte unterstützt werde ich mir das systemd Format wahrscheinlich auch nicht mal ansehen. Etwas das man gelernt hat und das funktioniert ist selbst bei den Informatikern, wo es ständig Neuerungen gibt, der größte Hemmschuh sich auf was neues einzulassen. Und sicher auch die Erfahrung, dass viele radikale Neuanfänge so sehr in die Hose gegangen sind.

[cosmac]

@cosmac
Soweit mir aber bekannt war sollte systemd "nur" ein init Ersatz werden.
Und init hat eben keine weiteren Aufgaben als sich um den Bootvorgang zu kümmern.

wobei es sogar nur um den rc-Mechanismus ging, es war absolut überflüssig, an /sbin/init (pid 1) etwas zu ändern.

Ebenfalls braucht man ein extra Tool um die systemd Log, die in einem nicht Lesbaren Format gespeichert werden, auslesen zu können.
Hier verlang systemd also, dass man komplette Aufgaben an ein Tool auslagern soll.

das ist ein Beispiel, wo systemd eine Schwäche des alten Systems ausnutzt um den Usern seinen Müll schmackhaft zu machen. Es war ja ziemlich schwierig, die Meldungen der init-Scripte zu speichern. Dafür, dass das jetzt richtig funktioniert, nimmt man gerne in Kauf, dass man sie nicht mehr lesen kann

Nimm es mir nicht übel aber ich kann system nicht leiden

dann sind wir ja schon zu zweit. Also, wenn ich das Umfrageergebnis hier im Forum anschaue... Wenn eine Firma so entscheidet, meinetwegen, aber hier stimmen doch Leute ab, die dann selber den Stress mit dem Teil haben werden. Ich werde es nie verstehen

Und durch die Abhängiokeiten bei den Distributionen festigt hier Red Hat ebenfalls noch Abhängikeiten für die eigenen Geschäfte.

das würde ich ihnen sogar gönnen, es gibt "bösere" Firmen. Und wenn es zu schlimm kommt, wird es eine Alternative geben (hoffe ich jedenfalls).

Klingt zwar nach Verschwörung, könnte sich aber in Zukunft auch als Wahr erweisen )

eine Verschwörung ist es definitiv

Verschwörung
Eine Verschwörung (Lehnübersetzung von lat. coniuratio; auch: Konspiration) ist ein heimliches Bündnis mehrerer Personen mit dem Zweck, einen Plan auszuführen; dieser kann ein selbstsüchtiges, verwerfliches Ziel haben und den Schaden anderer beinhalten, aber auch die Beseitigung tatsächlicher oder vermeintlicher Missstände umfassen. Eine Verschwörung beruht also nicht notwendigerweise auf moralisch niederen Motiven, sie basiert jedoch stets auf Täuschung.

Die Sache bezüglich KISS Prinzip müsste man sich genauer ansehen. Grob draufgeschaut: Aus dem Quellpaket werden 20 Binärpakete gebaut und das wichtigste davon, das systemd Paket, enthält alleine schon 21 ausführbare Dateien. So ganz un-modular scheint es zumindest mir auf den ersten Blick gar nicht zu sein. Ein großer Blob ist es zumindest nicht.

Was helfen mir 21 einzelne Programme, wenn die alle aufeinander angewiesen sind und über nicht dokumentierte Kanäle kommunizieren? Außerdem ist schon das Grundprinzip das Gegenteil von kiss: es gibt keine einheitliche Schnittstelle zu anderen Paketen, stattdessen werden einzelne (nicht alle!) Funktionen in systemd übernommen.

Ein Beispiel das mir Arbeit machen würde: hwclock funktioniert hier wegen spezieller Hardware ganz anders. Bisher konnte ich das init-Script anpassen (oder abschalten), jetzt muss ich überhaupt erstmal auf die Idee kommen, dass der systemd heimlich die Uhr manipuliert -- das sind Fehlerquellen, die die Welt wirklich nicht braucht. Nachdem ich das zufällig entdeckt hab', bin ich natürlich sehr skeptisch, was den Rest angeht.

Ich bin mal neugierig, ob sich das wirklich durchsetzen wird. Man denke nur mal an ifconfig und netstat. Solange die noch paketiert werden sehe ich keinen Grund mich auf ip und ss umzugewöhnen. Ich habe keine Vorteile gefunden bzw. nichts vermisst

Jetzt wo du es sagst: welche Vorteile habe ich als Benutzer eigentlich von systemd? Selbst das alte Werbeargument "bootet schneller" ist ja wohl vom Tisch und war angeblich nie das Ziel der Entwicklung.

[wanne]

Ein Beispiel das mir Arbeit machen würde: hwclock funktioniert hier wegen spezieller Hardware ganz anders. Bisher konnte ich das init-Script anpassen (oder abschalten), jetzt muss ich überhaupt erstmal auf die Idee kommen, dass der systemd heimlich die Uhr manipuliert -- das sind Fehlerquellen, die die Welt wirklich nicht braucht. Nachdem ich das zufällig entdeckt hab', bin ich natürlich sehr skeptisch, was den Rest angeht.

Genau das ist das was ich meine: Alles funktioniert bei 99% hervorragend aber hier und da findet sich dann doch eine Kleinigkeit und die ist dann praktisch nicht zu beheben.

Aus dem Quellpaket werden 20 Binärpakete gebaut und das wichtigste davon, das systemd Paket, enthält alleine schon 21 ausführbare Dateien.

In C Kann man jede Funktion als eigene Binary bauen. Ob das deswegen modularer ist oder nicht sei mal dahingestellt. Der Vorteil von modularität ist eigentlich dass man teile durch andere (nicht systemd) austauschen/weglassen kann. Das geht bei systemd nur schwer.

Man denke nur mal an ifconfig und netstat. Solange die noch paketiert werden sehe ich keinen Grund mich auf ip und ss umzugewöhnen.

Es gibt schon massenhafs sachen die mit ifconfig/route extreme verbiegungen gebraucht haben. Und die die Leute deswegen für kompliziert gehalten und großteils gemieden haben.
Nur so ein paar: Mehrere IPs pro interface sind einfach ne tolle sache. Gerade, wenn man mal 5 Server betreiben will. Eigentlich will man da nicht auf andere Ports ausweichn. Aber weil das mit ifconfig gefriekel war hat man das halt doch gemach. Oder wenn man mal 2 Netze hat.
Load balancing über mehrere Interfaces oder CPUs. Wurde mir immer als zu kompliziert von abgeraten mit ip ein einzeiler. Selbiges gilt für routing anhand von TOS u.ä.
Für diverse tunnel Mechanismen (OpenVPN o.ä.) wäre es ein segen, wenn sie von den Fähigkeiten von IP gebrauch machen würden statt nochmal alles neu zu erfinden.
Und multicastrouting habe ich zwar noch nicht benutzt aber das war glaube ich mit route auch nicht möglich. Warum das allerdings nicht in die alten tools eingepflegt wurde und man sich weg von der BSD syntax hin zu der von CISCO IOS bewegt hat verstehe ich auch nicht so richtig. Passt aber stark zur entwickluch von Linux weg aus dem GNU/POSIX bereich.