Von Klaus-Bärbel am Mi, 12. Februar 2014 um 08:17 #
... hätte man wetten können. Die Quote wäre nicht sehr hoch gewesen. Ich schätze allerdings, dass die Diskussionen noch ne ganze Weile anhalten werden.
Nun, Upstart hat durchaus seine Vorteile, wie eine einfachere Portierbarkeit, jedoch stellt sich die Frage: Reichen diese?
Nebenher ist auch die Portierbarkeit von SysVInit nie sonderlich gut gewesen, weswegen u.a. die Debian-Hurd Entwickler spezielle Abstraktionslösungen bauen musste, um SysVInit nutzen zu können. Insofern wäre Systemd hier nicht einmal schlimmer. Upstart wäre wohl ebenfalls nicht ohne Anpassungen nutzbar, lediglich der Aufwand wäre geringer, da es die Lösungen von SysVInit nutzen könnte.
"SysVInit ist sehr klein und brauchte vergleichsweise wenig Anpassungen. "
Das kommt darauf an, wo du die Grenze bei SysVInit ziehst. Gehen die Scripte der Distribution mit hinein, ist es weder klein noch Anpassungsarm für andere Systeme. Speziell beim Thema mounten von Speichermedien und Netzwerk ist es dann doch sehr Systemabhängig.
Sauber programmiert wiegt die vielen Nachteile nicht auf. Vendor-Lock-In. RedHat bekommt zu viel Einfluss auf die Systeme. Das ist mein Problem mit Systemd. Nicht immer sollte man AUSSCHLIEßLICH die technischen Vorteile berücksichtigen. Ich fürchte bald wird alles Mögliche von Systemd abhängen und der Moloch ist für eine Community nicht so leicht handlebar, wie ein Init-System (was ja Systemd nicht (nur) ist, wie wir auch immer wieder von den Befürwortern hören). Warten wir mal ab, wie lange es dauert bis Debian oder andere Systemd forken müssen, weil sie dessen Entwicklung nicht mitgehen wollen.
Schon witzig: Angst davor haben, dass ein Unternehmen Einfluss auf eine Distribution bekommt, wenn es eine Software einsetzt, die *auch* von ihm entwickelt wird. Gleichzeitig sich aber wünschen, die Distribution setzt eine andere Software ein, die *ausschließlich* von einem anderen Unternehmen entwickelt wird.
Wie heuchlerisch oder naiv oder beides muss man eigentlich sein um das ernsthaft zu vertreten?
Mir scheint dies auch kaum das Ziel der systemd Entwickler zu sein. Während upstart tatsächlich relativ genau dann stehen blieb, als das System schneller damit bootete, wird systemd eher in die Richtung einer sinnvollen Lösung für den Betrieb des Systems entwickelt.
Aber diesen Unterschied legen bereits die Namen nahe: upstart systemd
Im Grunde sind die Ziele und das Verständis zur Aufgabe der Projekte damit schon deutlich aufgezeigt
Na zumindest mal eine parallele Abarbeitung nach Abhängigkeiten. Das lineare Abarbeiten der Init-Jobs ist nicht nur langsam sondern auch konzeptionell aus dem letzten Jahrtausend. Man sehe sich nur an, wie SysVinit die liniare Reihenfolge der zu startenden Init-Scripte regelt.
Ein Init-System muss heutzutage auch die Prozess sauber trennen, was systemd mit den cgroups hinbekommt. Für was gibt es denn Fortschritt auf diesem Gebiet, wenn sich Prozesse dann immer noch durch forken vor dem Init-System verstecken können? Aus Spass? Nein, sondern weil es Sinn macht und gebraucht wird. Ein Init-System muss Dienste zuverlässig beenden können.
Als Administrator möchte ich das Schreiben von Init-Scripten abgenommen bekommen. Anweisungen, welche Abhängigkeiten ein Dienst hat, müssen ausreichen.
Das sind imho die Hauptpunkte, die ein modernes Init-System mitbringen muss. Klar sind das nicht alle Vorteile von systemd.
"Na zumindest mal eine parallele Abarbeitung nach Abhängigkeiten."
Außerdem das starten und stoppen von Diensten anhand bestimmter Situationen, anstatt dies stur nur beim Boot zu tun / diese Aufgabe anderen Diensten zu überlassen.
Von hermanvonderalb am Mi, 12. Februar 2014 um 09:29 #
MacOS ist vielleicht auch sauber programmiert, aber benutzen möchte ich es trotzdem nicht. Systemd spaltet die Community, daher wäre jede andere Lösung vorzuziehen. Sauber vorprogrammierter Ärger steht an.
Von oldmcdonald am Mi, 12. Februar 2014 um 10:17 #
Ob nun systemd/poettering oder upstart/shuttleworth die Community spaltet, ist doch eher zweitrangig. Zum spalten und sich spalten lassen gehören immer zwei.
Von hermannvonderalb am Mi, 12. Februar 2014 um 14:05 #
Mich stört an der Diskussion, dass OpenRC keine Chance bekommt. Ich finde das würde besser zu Debian passen. Wenn man bedenkt, wie langfristig sich die Entscheidung auswirkt, hätte man OpenRC ruhig mehr Zeit geben können (und so lange bei sysvinit bleiben können). Wenn alle großen Distros Systemd nutzen, dann werden die Alternativen ziemlich dumm da stehen.
Die Frage kam doch auf der CTTE Mailingliste auch mehrfach auf, wo sich Leute beschwert hatten, dass OpenRC zu wenig Chancen eingeräumt wurden und es gab auch recht ausführliche Antworten der Mitglieder des CTTE.
Grundtenor war, dass man sich zunächst einmal zu den verschiedenen Lösungen "eingelesen" hatte, d.h. die Dokumentation dazu angeschaut hatte um einen ersten Eindruck zu bekommen. Das macht auch Sinn, da man insbesondere OpenRC zunächst nicht "einfach so" auf Debian testen konnte, das Paket wurde ja im Laufe der Diskussion wesentlich weiterentwickelt, um überhaupt eine brauchbare Lösung verfügbar zu haben. Irgendwann gab es dann auch entsprechende VM Images, mit denen das Testen vereinfacht wurde, allerdings war hier der Schaden für OpenRC schon getan: Es existierte einfach zu wenig Dokumentation, um sich über den wirklichen Funktionsumfang, die Beschränkungen etc. ein Bild zu machen. Dieses teilweise nur scheinbare, aber auch wirkliche Defizit an Dokumentation bei OpenRC hat dem System dann den entsprechenden Nachteil gegeben, den es bis Ende nicht mehr aufholen konnte, zumal Upstart aber insbesondere Systemd mit umfangreicher und detaillierter Dokumentation glänzen. Auch wenn ja einiges für die Integration von OpenRC auf Hurd und kFreeBSD getan wurde, aber das war dann wohl nicht mehr genug.
"Setzt man nun ins Verhältnis wie lange es beide schon gibt, bin ich unentschlossen was ich davon halten soll..."
Neue Systeme sind immer etwas anfälliger, das ist völlig normal. Gerade wenn vieles gleichzeitig entwickelt wird, bleiben Probleme nicht aus.
"Zudem wird systemd immer größer und es ist nunmal irgendwann zu groß für die PID-1."
Eigentlich macht systemd als Systemdienst auf PID-1 nicht sonderlich viel, nur das was absolut nötig ist, um seine Aufgabe zu erfüllen. Das mag mehr sein als bei SysVInit, allerdings sind die Erweiterungen von Systemd in PID-1 durchaus sinnvoll dort platziert.
Für zwei der Fehler müsstest du das Äquivalent im Syslog-System suchen für mindestens einen in im Loginmanager einer steckt eigentlich in Polkit die anderen zwei sind ebenfalls Fehler in Aufgaben die zu erfüllen sind aber nicht von SysVinit übernommen werden oder nicht mit SysVinit in Verbindung gebracht werden würden da sie dort in Scripten erledigt würden.
nur weil journald mit systemd in Verbindung gebracht wird steckt er noch immer nicht mit in PID1
Wenn man die CVEs von sysvinit und systemd vergleichen will (und einen halbwegs sinnvollen Vergleich sucht), dann muss man sich auf die CVEs von systemd beschränken, welche PID 1 zugeordnet werden können, exklusive logind, journald o.ä.
Ich machs wie die letzten 10Jahre in denen Linux benutzte... was gut und zuverlässt mit vertretbaren Aufwand läuft bleibt auf dem Rechner alles andere wird wieder gelöscht
Hier macht Ubuntu einiges wohl richtig, auch wenn viele was anderes behaupten :huh:. Umsonst würde es nicht solange auf meinen Rechner bestand haben. Mit Systemd bin ich bis jetzt eher negativ in Berührung gekommen, vielleicht macht das Debian jetzt besser.
Nö, im Grunde genommen ist das kein Schlag gegen die Vielfalt, sondern ein Wechsel von "wenig Vielfalt" auf "wenig Vielfalt" in einer anderen Ausführung.
Bis vor 3-4 Jahren gab es im Linuxumfeld eigentlich nur ein Init: sysvinit Es gab bei der Umsetzung des Inits mit sysvinit eine sehr große Vielfalt, aber bei genau dieser Vielfalt wirst du wohl wirklich Niemanden finden, der das begrüßt, denn das war schlicht und einfach Murks und Chaos. Dann kamen Upstart auf Ubuntu und OpenRC auf Gentoo auf, aber als "gesunde Vielfalt" würde ich das auch nicht bezeichnen, zumal OpenRC ja außerhalb von Gentoo nur in sehr speziellen Fällen Verwendung fand (z.B. auf Arch Linux).
Kurz gesagt: Eine wirkliche Vielfalt gab es beim Init eigentlich nie. Es gab eine kurze Phase, bei der mehrere Lösungen um die Ablösung des alteingedienten Monopolisten gesucht haben, dass sich da langfristig eine Variante durchsetzen wird war eigentlich absehbar und eine Zeit lang hätte man ja sogar vermuten können, dass das Upstart ist (wurde ja auf einigen Distributionen übernommen). Dass es das nicht geschafft hat hatte eben sowohl rechtliche (CLA) als auch technische (Events) Gründe, mit denen man übereinstimmen kann, aber natürlich nicht muss.
Was die anderen Komponenten von systemd angeht (journald, logind, getty, udev, timer), so kann auch in Zukunft auf alternative Lösungen setzen. Ob dann (z.B. im Fall von logind) auch alternative Lösungen von Programmen unterstützt werden ist aber im Endeffekt nicht Frage von systemd, sondern der Entwickler der Programme. Denen kann man aber wohl kaum einen Vorwurf machen, denn auch heute schon gibt es z.B. Programme, welche openssl unterstützen, aber nicht gnutls (oder umgekehrt). So eine Entscheidung obliegt nunmal den Programmierern.
[q]"gesunde Vielfalt"[/q] Gentoo hatte schon vor OpenRC eine eigene Lösung verwendet. Arch hatte vor Systemd eine eigene sehr einfache Lösung, die Arch mit ihrer KISSigkeit beworben hat. Slackware verwendet auch eine eigene BSD-ähnliche Lösung. Die Vielfalt wahr schon da, du hast sie nur nicht bemerkt, da sie nicht mit so aggressiven Mitteln wie Systemd in den Markt gedrückt wurde.
Ich war lange Zeit Gentoo Nutzer und habe in der Zeit auch OpenRC genutzt. Dass es noch andere Systeme gab war mir schon klar, aber das waren eben eher Nischenanwendungen. Meiner Meinung nach waren Upstart und auch OpenRC die ersten echten Versuche eine nachhaltige und moderne Alternative zu sysvinit zu entwickeln. (Init-)Systeme für Nischenanwendungen (sei es nun politisch oder technisch motiviert) wird es auch in Zukunft geben und wie auch bisher wird das sicher manche Vorteile und manche Nachteile haben.
Abgesehen davon wurde systemd vor allem zu Beginn nicht "aggressiv" in den Markt gedrückt. Die ersten 1-1.5 Jahre zu systemd waren eigentlich recht normal. Das was man als "aggressiv" bezeichnen könnte hat sicher eher in den letzten 1.5-2 Jahren entwickelt, hauptsächlich seit journald als Bestandteil des systemd-Pakets entworfen wurde. Davor war aber das Interesse an systemd auch schon sehr groß, da es von der Konzeption ganz anders als alles andere war was man im Linuxbereich bis daher kannte und, da offensichtlich damals schon viele Leute (auch unter den Distributoren) das Potential der Technologie erkannten.
zur Wahl von systemd, war der Vorsitzende des Gremiums, Bdale Garbee.
Nun braucht es aber eine Zweidrittel-Mehrheit unter den 1000 Entwicklern, um die Entscheidung zu revidieren.
Erinnert mich irgendwie an Parallelen zur Politik, wo durch die Unentschlossenheit weniger, ungeliebte Entscheidungen für Viele zustande kommen. Diese Volksentscheide (GR) lassen sich dann später nur noch mit ungleich höherem Aufwand korrigieren, und scheitern dann häufig mangels Beteiligung der Wahlberechtigten. Sei es wegen Frust (Politikverdrossenheit) oder Desinteresse, oder Uneinigkeit.
Das mit der Einfachen Mehrheit habe ich nicht überlesen, doch in der Vergangenheit wurde meist von 2/3 gesprochen, was wohl normalerweise bei einer GR so üblich ist. Daher hab ich das so geschrieben obwohl es hier anders stand.
Heise schreibt aktuell auch noch was von einer Zweidrittelmehrheit hier: http://www.heise.de/open/meldung/Debian-entscheidet-sich-fuer-Systemd-zumindest-fuers-Erste-2111065.html
Scheinbar ist man für die systemd Entscheidung also vom Gewohnten abgewichen, so wie bei Golem zu lesen:
"Denn bei einer bestimmten Auslegung der Debian-Verfassung reicht eine einfache Mehrheit in dieser Entscheidung wohl nicht aus. Deshalb könnte auch die Gesamtheit der Debian-Entwickler in einer sogenannten General Resolution die Entscheidung des CTTE überstimmen. Dazu ist eine Zweidrittelmehrheit erforderlich. Doch das CTTE diskutiert derzeit auch, dies zumindest in der Init-System-Diskussion auf eine einfache Mehrheit zu ändern."
Insofern zeigt muss es wohl stimmen was hier zu Lesen ist. Also doch mal wieder gut recherchiert von Pro-Linux. Gut gemacht, liebe Redaktion.
SysVInit ist seit Jahrzehnten bewährt. Warum muss man wegen ein paar Sekunden bootzeit bewährte Dinge wegwerfen? Systemd ist ein Monster. Es frisst die Netzwerkkonfiguration(netctl), udev und wer weiß was noch alles. upstart ist quasiproprietär. Gruselig, das alles. Man hätte bei SysVInit bleiben s ollen.
Meinst du nicht, daß in dem technischen Gremium Leute sitzen, die sich sehr ausführlich mit den verschiedenen Alternativen beschäftigt haben, die Vor- und Nachteile abgewägt haben und dann ihre Entscheidung getroffen haben?
Die Techniker können auch die Augen vor der Realität nicht verschließen. Systemd frisst sich in div. Subsysteme und nimmt Funktionen auf die vorher von anderen Programmen getan wurden sind. Entweder pflegt man all diese oder schwimmt mit dem Strom. Scheiß auf Modularität und Unix solange es funktioniert.
Auch unter System dienst es noch immer eigenständige Dienste und Programme. An einigen Stellen wurden die Projekte praktisch integriert, an anderer Stelle hat man bemerkt, das in Systemd eine vergleichbare Lösung (aus anderem Hintergrund) existiert, die als Basis besser geeignet ist. Das die Systemteile getrennt waren bedeutet nicht, das ihre Trennung in verschiedene Projekte effizient, von Vorteil für die Nutzer oder einer sinnvollen Planung entsprechend. Oft war die Trennung schlicht "passiert". Da haben einfach verschiedene Leute getrennt an Dingen gearbeitet.
Systemd als Projekt nimmt Funktionen auf, die früher andere Software erledigt hat. Das ist richtig. Systemd ist aber trotzdem Modular, da diese Funktionen genau so noch von anderer Software erledigt werden kann. Ob das Sinn macht ist eine andere Frage, aber du kannst nach wie vor die alte Software mit systemd einsetzten um musst nicht auf logind und Co setzen.
Aber wie gesagt: Das macht keinen Sinn, da das Systemd-Projekt die beste technische Lösung bietet.
Ja, seh ich ähnlich. Ich bleib bei meinem ZX Spectrum. Dieser ganze neumodische Dreck kotzt mich an! Damals hab ich sogar noch selbst gelötet, aber bei den heutigen Monstern geht da gar nichts mehr. Weg mit dem Scheiß!
Es wäre vermutlich schon möglich gewesen mit SysVInit zu booten und systemd nur sehr früh zu starten damit es seine Aufgabe als System Daemon erfüllen kann.
Wird aber vermutlich auch Vorteile haben systemd auch gleich das Booten machen zu lassen
"systemd nur sehr früh zu starten damit es seine Aufgabe als System Daemon erfüllen kann."
Dann hätte Systemd aber keine Kontrolle über die durch SysVInit gestarteten Dienste. Abgesehen davon ergibt das wenig Sinn, immerhin kann Systemd die Aufgaben von SysVInit ja ebenfalls übernehmen. Das wäre ein Flickwerk ohne jeden Mehrwert, aber mit vielen Fehlerquellen. So etwas macht man rein aus dem Prinzip, nicht weil es sinnvoll ist
Richtig. Ich wollte nur darauf eingehen, dass der meiner Meinung nach wesentliche Einsatzzweck von systemd nicht das Booten ist.
Wenn jemand unbedingt der Meinung ist anders zu booten, bleibt systemd trotzdem als derzeit beste Lösung für seine Hauptaufgaben.
Macht zwar weniger Sinn als gleich systemd auch das Booten miterledigen zu lassen, aber wenn man mit diesem Teil nicht einverstanden ist, soll man es halt nicht dafür benutzen
Interessanterweise hatten quasi alle der CTTE-Mitglieder (außer Ian Jackson, der aber eher ein Protestvoting abgegeben hat) alle Init-Optionen über sysvinit gestellt.
Abgesehen davon sind die Gründe nicht (oder zumindest nicht nur) Bootzeit, es gibt viele andere Gründe. Mit anderen Worten: Beschäftige dich mal wirklich damit (so wie die CTTE-Mitglieder) und dann urteile erneut.
Von oldmcdonald am Mi, 12. Februar 2014 um 10:32 #
Systemd ist auf Linux einfach ein Muss. Und es ist gut, dass es ein Muss ist. Sich jetzt gegen Systemd zu entscheiden, hat nur aufschiebende Wirkung und man muss die ganze Arbeit zwei mal machen.
Ich hoffe, dass sich die Wogen bald wieder glätten.
Viele Grüße und weiterhin alles Gute für meine Lieblingsdistro!!!
Ich befürchte eher ein abwandern von Entwicklern. Wer sollte sich auch noch die Mühe machen wenn der Pöbel nach den Linux@X86 und Systemd ruft. Debian musst selbst wissen wo sie hingehören.
Systemd ist nicht auf x86 Prozessoren beschränkt, sehr wohl aber aktuell auf Linux. Bezüglich Debian und nicht-Linux Kernel sei gesagt, das auch das aktuelle SysVInit z.B. bei Hurd nicht ohne größere Anpassungen nutzbar ist. Die Anpassungen zu den cgroups und co. werden bereits durchgeführt, vor allem da sie auch für andere Anwendungen notwendig sein werden. Insofern ist es den Debian-Hurd Leuten - soweit ich bisher gelesen habe - relativ egal, für was sich Debian entscheidet. Bei kFreeBSD dürfte es sicher nicht anders aussehen.
Zudem ist systemd durchaus bei vielen Entwicklern beliebt, einige der Funktionen können das Leben durchaus erleichtern. Genauso gut kann man sagen, das Debian Entwickler verlieren würde, wenn sie bei SysVInit bleiben. Sie würden auch Entwickler verlieren, wenn sie Upstart wählen. So ist das nun einmal, wenn kein Konzens bei einer Sache besteht.
Und für KDBus werden dann auch noch nachgereicht? Wie wir alle wissen ist Lennart scharf auf eine Integration. Und hättest du mein geschriebenes auch richtig verstanden, wäre die aufgefallen dass das eine Kritik am Demokratieprinzip war. Die Masse hat kein Interesse was Minderheiten wollen. Klar gibts wenig die abseits des Mainstream auf dieses Exoten setzen. Nun gibts für sie auch weniger Gründe auf Debian zu setzen. Und wieso sollen Entwickler verschwinden wenn man SysV Init verwendet? Klar ist das nicht mehr zeitgemäß aber es erfüllt seinen Zweck verletzt nicht die Schichtenarchitektur und beschränkt sich aufs nötige.
"Und hättest du mein geschriebenes auch richtig verstanden, wäre die aufgefallen dass das eine Kritik am Demokratieprinzip war."
Hier sei angemerkt, das du das zwar gemeint haben magst, das aber aus deinem Text nicht wirklich ersichtlich wird. Er ist ziemlich knapp, und dabei durchaus missverständlich. Wenn du richtig verstanden werden willst, führe deine Argumente einfach das nächste mal etwas klarer aus, dann missversteht man dich auch nicht.
Nebenher haben die "Minderheiten" bei Debian bisher gar keinen Einfluss auf die Entscheidung verlangt. Ich lese viel davon, das man doch gefälligst Rücksicht auf Hurd und co. nehmen soll, doch bisher sind mir aus dieser Richtung gar keine Anforderungen bekannt geworden. Nur Aussagen, nach dem auch die bisherige Lösung einen bedeutenden Aufwand erforderte, und sich das mit keiner Wahl ändern wird.
Die Aussagen, das man keine Rücksicht auf die kleinen Projekte nimmt, scheinen mir inzwischen mehr als künstlich, und gehen an der Realität der Projekte völlig vorbei.
Zum Thema: "Und wieso sollen Entwickler verschwinden wenn man SysV Init verwendet?"
Hast du dir bereits geantwortet: "Klar ist das nicht mehr zeitgemäß"
Das hat weitreichende Folgen. Vor allem wenn immer mehr andere Distributionen auf systemd setzen, und dessen Vorteile nutzen, wird Debian Probleme bekommen, wie auch Ubuntu. Solch einen Ärger wollen nicht alle Nutzer, dann werden einige Wechseln. Es ist also nicht so, das ein verbleib bei SysVInit - der Zudem absolut keine Option irgendwo in der Diskussion aktuell ist - ein Problem vermeiden würde.
Nebenher sei gesagt, das auch systemd keinerlei "Schichtenarchitekturen" verletzt. Zum einen weil es dafür gar keine Vorgaben gibt, zum anderen weil systemd durchaus logisch und sinnvoll geplant ist. Vielmehr trennt es die einzelnen Ebenen weit sauberer, als dies aktuell der Fall ist. Diverse Hacks bei SysVInit um mit der Abarbeitung der fstab in einem Modernen System klar zu kommen sind grässlich, und in systemd weit sauberer gelöst. SysVInit ist eine Sammlung unschöner Scripte und wenig tauglicher Hacks, die nur mit Spucke zusammen gehalten werden. Darüber gibt es eigentlich gar keine echte Diskussion. Man versucht dieses System seit Jahren los zu werden, nicht erst mit systemd. Selbst upstart ist schon seit 4 Jahren in der Entwicklung.
Noch einmal sei zudem klar gesagt, das Systemd kein großer Dienst ist, sondern zwei Dinge zugleich: 1. Ein schlanker Pid-1 Dienst, der nur das nötigste tut (Dienste starten/stoppen, Abhängigkeiten beachten usw., was ein moderner Startdienst eben können muss) 2. Der Name für ein Projekt, der diesen Dienst und viele weitere umfasst.
Viele haben Angst vor Punkt 1, und kritisieren diesen dann mit Punkt 2, der damit aber wenig zu tun hat.
Ach, bevor ich es vergesse: Bitte immer auch daran denken, das wir alle einen Kernel als Basis nutzen, der so ziemlich jede Regel für sauberes Softwaredesign verletzt, die in den letzten 30 Jahren entwickelt wurden. Und es stört niemanden, denn er funktioniert.
Gute güte, es gab schon Webserver für den Kernel!
Systemd ist um einiges ordentlicher als der Linux-Kernel, dennoch werden an systemd Anforderungen gestellt, die kaum ein normales Projekt erfüllen kann. Dabei wird oft ignoriert, das systemd bereits weit sauberer umgesetzt ist als alles, was es ersetzen soll.
Persönlich habe ich immer noch ein Herz für upstart, aber realistisch betrachtet hat das keine Zukunft.
Absolut. Am Anfang ging es durchaus noch stark um die technischen Vor- und Nachteile.
Das Problem dabei: Während am Anfang viele noch uninformiert waren (das trifft auch auf mich zu), wird es mit der Zeit schwerer die fakten zu ignorieren. Wenn man also etwas ablehnt, bleiben irgendwann nur noch Gefühle und Befindlichkeiten. Aktuell auch gut auf der Debian Mailingliste zum Thema zu beobachten. Eigentlich traurig, aber das ganze wird sich wieder beruhigen. In 2 Jahren werden alle den Kopf schütteln, wie man über so etwas so lange diskutieren konnte.
Keine Ahnung ob du mich bewusst missverstehen wolltest. Er schrieb, dass Kernel Features in Hurd integriert werden damit systemd damit funktioniert. Das ist ja wohl kaum eine Lösung auf Dauer, wie ich bereits schrieb in Hinblick auf weitere Features wie KDBUS. Mal von FreeBSD abgesehen, dass aktiver in der Entwicklung ist und keiner würde sich das antun wollen seinen Code im Sync zu halten.
Wird es sein müssen, denn auch aktuell haben die Debian/Hurd Entwickler bereits Linux-Eigenheiten implementiert, anders lässt sich das System mit SysVInit, wie es Debian nutzt, gar nicht booten.
Solange Hurd ein so kleines Projekt innerhalb von Debian ist, wird es sich an das größere Projekt anpassen müssen. Soweit ich sehe ist das auch für die Debian/Hurd Entwickler kein großes Problem.
Warum ein kFreeBSD das nicht umsetzen sollte kann ich nicht nachvollziehen, zumal die Anforderungen von systemd durchaus sinnvoll sind. Ebenso ist KDBUS einen sinnvolle Entwicklung.
Da bei Hurd ohnehin die Entwicklung langsamer vonstatten geht, ist die Wahrscheinlichkeit das die Lösung eine Weile bestand hat größer als bei FreeBSD. Und deshalb warum sollte jemand den FreeBSD Kernel anfassen wollen? Technisch sind das schon andere Größenordnungen. Bei FreeBSD ist jedenfalls kein cgroups, systemd oder KDBUS in Planung.
"Und deshalb warum sollte jemand den FreeBSD Kernel anfassen wollen?"
Weil es notwendig wäre, um systemd als PID-1 eines Debian/kFreeBSD nutzen zu können. Technisch wäre es nichts anders als bei Hurd auch. Wohlgemerkt, die Anpassungen bei Hurd sind nur bei Debian zu finden, es sind dort eigene Module (es hat eigentlich einen anderen Namen, die Bezeichnungen bei Hurd wollen wir aber gerade nicht einfallen) für diesen speziellen Fall.
Fakt ist: Debian war zuerst eine Linux Distrie, und ist davon auch nicht abgewichen. Hurd und FreeBSD als Kernel sind Spielwiesen, die daneben dazu gekommen sind. Entsprechend passen sich diese Unterprojekte dem Hauptprojekt an, und nicht umgekehrt.
Noch einmal klar: Es geht nicht um FreeBSD, es geht um Debian/kFreeBSD. Das ist ein wichtiger Unterschied. FreeBSD ist ein großes, in sich vollständiges Projekt, von dem Debian/kFreeBSD nur einen Teil nimmt, um ihn im Debian/GNU Userland zu nutzen. Im Grunde ein kleines Monster
Nebenher, wie ich inzwischen gesehen habe, haben die Debian/HURD Entwickler wohl bisher kein sysvinit verwendet, sie wollen dies vielmehr für die Zukunft tun. Möglichweis wird man zu openrc wechseln.
Insofern ist die Diskussion über systemd für Debian Hurd damit eh irrelevant, sie werden tun und lassen was sie wollen. Und auch kFreeBSD, laut deren Mailingliste, wird wohl schlicht etwas eigenes Pflegen. Das Thema ist dort aber eher klein, niemand scheint sich darüber aufzuregen.
Aktuell haben wir hier wohl mehr Posts zu dem Thema produziert, als die betroffenen
Die exakten Anpassungen sind mir auch nicht alle bekannt, aber ein cgroup Equivalent sollte doch im Kernel sein, den hat FreeBSD definitiv nicht. Und einfach die Teile herauspatchen die der Kernel nicht hergibt, ist ebenso aufwendig wie ein komplett eigene Lösung auf Basis etwas anderes zu nehmen.
Fakt ist aber auch Debian wollte sich nie als reine Mainstream Distro sehen nur den aktuellsten Trends und Plattformen folgend. Der Sinn solcher Spielwiesen ist ja nicht nur der Proof-of-Concept sondern auch Abhängigkeiten zu verringern, Fehler zu finden, flexibler zu sein. Aus zwei komplett unterschiedlichen Init zieht man nicht viel raus. Da spielts auch keine Rolle wie groß das ganze ist.
Wie gesagt ist die Diskussion eher künstlicher Natur. Auf den betroffenen Mailinglisten findet sie in dieser Form gar nicht statt. Die Diskussionen dort gehen klar in die Richtung eigener Init-Lösungen, die von Debian abweichen, egal ob man sich dort für Upstart oder Systemd entscheidet. Das sorgt dort auch für kein Kopfzerbrechen, einzig weiter gepflegte Init-Scripte wünscht man sich, weil diese von allen alternativen Verstanden werden. Das ist sicherlich ein tragbarer Kompromiss, da diese ja sowieso bereits vorliegen, und sich zudem selten ändern.
Es sei zudem angemerkt, das Debian/Hurd wie gesagt bereits jetzt ein anderes Init-System nutzte, und das ganze bewusst. Man wechselt wohl gerade zu sysVInit, aber das ist wohl eher ein Übergang. Dafür wiederum wurden eigene Erweiterungen entwickelt, damit dies überhaupt möglich ist. Den SysVInit ist bei Debian Linux-spezifisch implementiert, laut eines Beitrags vor allem in Bezug auf die Erkennung von verfügbarer Hardware (was auch logisch ist). Solche Erweiterungen sind bei kFreeBSD natürlich auch möglich, und vermutlich auch bereits implementiert, wobei der FreeBSD Kernel dem Linux-Kernel allgemein ähnlicher ist, als dies beim Hurd-Microkernel-System der Fall ist.
Das man mit einem kFreeBSD jedoch wirklich Abhängigkeiten verringert... das ist wohl eher ein Wunsch als den Realität. Damit das der Fall ist, müsste es auch praktisch voll nutzbar sein, was mir nicht so zu sein scheint.
Aktuell sind Debian/kFreeBSD und Debian/Hurd Spielwiesen und Proof-of-Concept, aber ganz sicher keine tatsächlich genutzen Projekte.
Und viel wichtiger: Diese Projekt scheinen auch nicht den Anspruch zu erheben, den restlichen Debianern vorzuschreiben, wie sie ihre Entscheidungen fällen. Es scheint mir eher so zu sein, das sie die Vorteile von Unterschieden und passenden Lösungen zu schätzen wissen, und die Wahl eines passenden Systemdienstes für Linux durchaus nachvollziehen können.
Die Mailinglisten bei diesen Projekten sind jedenfalls mit Diskussionen zur praktischen Seite gefüllt, negatives zu der Änderung habe ich nicht finden können.
Interessante Frage. Ich denke eher, dass nicht. Grund ist, dass Hurd als Mikrokernel sowieso IPC-basiert ist, insofern würde man in dem Fall vermutlich auf dessen IPC zurückgreifen und eine Übersetzungsschicht einführen, wie man das für sysvinit in manchen Fällen auch schon getan hat. Oder sagen wir es mal so: Vermutlich ist KDBus das kleinere Problem.
Von oldmcdonald am Mi, 12. Februar 2014 um 11:03 #
Ich nutze auch gerne den PPC-Port von Debian und das ist auch ein Grund, warum ich Debian so klasse finde. Allerdings muss ich als einfacher User akzeptieren, dass es immer Leute geben muss, die Arbeit und Zeit investieren - im Falle von Debian meist ehrenamtlich. _Wenn_ sich jemand darum kümmert, war es bei Debian allerdings auch immer so, dass es auch gemacht wurde, siehe z.B. Emdebian, verschiedene Betriebssystem-Kerne, verschiedene Plattformen - Projekte mit einer Zielgruppe von teilweise weit unter 1% der gängigen x86-User.
Ich kann jetzt also lamentieren, dass Vielfalt kaputt geht - oder ich engagiere mich für Zweige, die mich interessieren und die ich für erhaltenswert erachte. Siduction hat schon vor Monaten ein Debian auf systemd-Basis errichtet - umgekehrt kann jemand aus Debian-Quellen ein System auf VSysInit weiterführen (ein Debian-System mit Upstart gibt's ja schon). Du willst es? Mach es! Debian steht Dir nicht im Weg!
Es mag dir vielleicht nicht bewusst sein aber die freie Zeit eines jeden ist begrenzt. Was nützt einem eine halboff. Version deren Fortbestand fraglich ist, wenn der Hauptzweig sich komplett anders entwickelt.
Dieses Problem gab es immer und wird es immer geben. Dagegen kann das Debian Projekt auch wenig tun. Wenn zu wenig Leute in den kleinen Projekten sind, um diese sinnvoll weiter zu entwickeln, hilft auch die größte Sympathie nichts. Noch einmal: Auch der aktuelle Bootprozess ist für die kleinen alternativen Kernel ein Problem, an dem sie arbeiten. Festhalten hilft denen auch nicht weiter.
Was sie brauchen sind Leute, die ihnen helfen. Wenn aber nicht genug Interesse daran haben, dann ist es eben auch nicht relevant darauf groß Rücksicht zu nehmen.
Das ist keine moralische Frage, anders als z.B. Sexuelle Orientierung, Hautfarbe und Herkunft von Menschen, ist die Wahl des Kernels eine rein persönliche Wahl, und Luxus noch dazu.
Die gleiche Begründung gab's auch bei Gnome oder DBUS zu hören. Es gibt doch Alternativen und forke doch, wenn du willst. Das Ergebnis ist bekannt, keiner mit Verstand benutzt Gnome außerhalb von Linux und ohne systemd.
Tatsächlich wurde GNOME ja nun auch geforkt, was nun einmal ein gültiger Weg ist. Ob ein Fork überlebt, hängt vom Einsatz der Leute ab. Und dieser hängt davon ab, ob die großen Worte ernst gemeint sind, oder doch nur heiße Luft
Nebenher hat die schwierige Entwicklung bei GNOME, meiner Beobachtung nach, vor allem kleinen Desktops wie LXDE und co. etwas aufwind gegeben. Eine durchaus positive Entwicklung.
Ob aktuelle GNOME-Versionen nun aktuell groß außerhalb von Linux genutzt wird oder nicht, dürfte relativ gleichgültig sein. Zum einen gibt es die älteren, die ihren Dienst tadellos verrichten (ich selbst nutze noch immer die 2.x Linie), zum anderen gibt es genug Alternativen. Und auch wenn es hart klingt: Die Entwicklung bleibt nicht stehen, wenn kleine Systeme nicht schritt halten können, ist das nicht der Fehler der schnellen. FreeBSD und co. auf dem Desktop sind die Nische der Nische. Selbst Linux ist auf dem Desktop in der Masse unbedeutend.
Nebenher, Linux geringe Bedeutung auf dem Desktop ist durchaus vergleichbar: Solange die Schnittstellen bekannt sind, ist doch eigentlich alles in Butter.
Gestern habe ich mir einen neuen Drucker gekauft, für den es keine Linux-Treiber vom Hersteller gibt. Aber: Er spricht diverse Standard-Druckersprachen, womit ich ihn dennoch nutzen kann. Der Hersteller verbaut also nichts, unterstützt nur auch nicht direkt, dafür ist Linux als Markt zu klein.
Systemd ist nicht viel anders. Es hat eine Reihe von (sinnvollen) Anforderungen, die es für den eigenen Betrieb braucht. Diese können Problemlos von anderen Kernelns implementiert werden. Systemd selbst tut dafür nichts, hindert aber auch niemanden daran.
Das ist das beste, was eine Nischenlösung erwarten kann.
Dann wird aus Gnu/Linux also Red Hat/Lennux. Bislang war es sehr einfach möglich, Pulse Audio, die *kits, usw. loszuwerden. In großen Umgebungen mögen systemd, journald und Konsorten ihren Nutzen haben. Davon habe ich als Desktop-Nutzer aber nichts. Auf der einen Seite habe ich einen egozentrischen Millionär, der mit Amazon-Werbung unterjubeln will, auf der anderen Seite habe ich ein technisch sicherlich durchdachtes Monstrum, für das ich keine Verwendung habe und keinen Nutzen daraus ziehe. Es geht für mich nicht darum, sich neuen Entwicklungen aus Prinzip entgegen zu stellen. Nach anfänglicher Skepsis hat mich etwa Wayland überzeugt. Ich hege auch keinerlei Abneigungen gegen Poettering. Nur ist sein Weg nicht der meine. Das wird er gewiss verkraften.
Wenn ich das Bedürfnis haben sollte, mich auf einem unixoiden Desktop-Betriebssystem diktatorischen Vorgaben zu unterwerfen, bleibt konsequenterweise nur noch der Biss in den (sauren) Apfel.
Ich habe jetzt seit ein paar Wochen meinen Desktop auf ArchLinux umgestellt. Ich glaube, dass es den meisten Desktopnutzern ziemlich egal ist welches Init-System ihre Distribution nutzt, da sie eh kaum selbst Hand anlegen (gut, bei ArchLinux wird empfohlen netctl für die Netzwerkkonfiguration zu nutzen, das intensiv von systemd Gebrauch macht - von daher braucht man dort schon die Grundlagen). Andererseits ist im Fall der Fälle journalctl für den Desktopnutzer definitiv einfacher zu bedienen als das greppen von Logdateien. Ausgenommen natürlich ein Crash von systemd selbst, das wäre unschön zu Debuggen für einen Anfänger. Das ist aber hoffentlich die absolute Ausnahme. Wir werden es sehen.
Die verbesserte Handhabung dynamischer Anforderungen sind speziell für den Desktop- bzw Laptopgebrauch interessant.
Auch eine leichtere machinelle Interaktion mit dem Basissystem hilft Deskoptbenutzern, weil damit die Einflussnahme auf Systemeinstellungen und ähnliches leichter über Endbenutzerwerkzeuge möglich ist.
Tatsächlich scheinen mir die einzelnen Elemente des Systemd Projekts eher einfacher Natur zu sein. Es sind recht viele, aber das ist eher der sauberen Trennung zu verdanken. Am Ende täuscht man sich auch schnell: Bisher waren viele Projekte getrennt, aber eben doch im Einsatz. Aber wird es einfacher, nur weil es 10 Projekte sind, anstatt eines einzelnen?
> Wenn ich das Bedürfnis haben sollte, mich auf einem unixoiden > Desktop-Betriebssystem diktatorischen Vorgaben zu unterwerfen, > bleibt konsequenterweise nur noch der Biss in den (sauren) Apfel. Wo es den 'launchd' gibt, welcher für SystemD-Ideen Pate gestanden hat.
für das ich keine Verwendung habe und keinen Nutzen daraus ziehe
Nun ja, daran bist du aber auch selbst schuld.
Wenn jemand trotz Computer gerne seine mechanische Schreibmaschine nutzen will kann er das ja gerne tun, aber bitte nicht bei den Computernutzern beschweren.
Mechanische Schreibmaschinen sind hochkomplexe Geräte, deren Funktionsweise aber gleichzeitig sehr leicht von jedem verstanden werden kann, der bereit ist, sich ein wenig damit zu beschäftigen. Zudem ist die Funktion einer mechanischen Schreibmaschine für den Benutzer transparent. Genau das waren die ausschlaggebenden Gründe, die mich zu Linux gebracht haben.
Systemd folgt nun einer anderen Philosophie: Die Funktionsweise soll bewusst vom Benutzer ferngehalten werden. Gnome 3 schlägt in die gleiche Kerbe. Ich beschwere mich also nicht bei den Computernutzern, sondern darüber, dass die Entwickler einen bewährten Pfad verlassen. Deshalb auch mein Hinweis auf den sauren Apfel. Das angebissene Obst richtet sich seit jeher an Nur-Nutzer, die nicht wissen wollen un dmüssen, wie ihre Maschine arbeitet.
Gerade das stimmt aber überhaupt nicht, denn genau aus dem Grund hat systemd eine sehr umfangreiche Dokumentation.
Es ist natürlich richtig, dass man C können sollte um verstehen zu können wie systemd arbeitet und aufgebaut ist. Sich ein bisschen in Shell Skripte einzuarbeiten ist natürlich einfacher. Dennoch würde ich hier zum Beispiel nicht übereinstimmen, dass sysvinit irgendwie transparenter war und von jedem verstanden werden konnte. Die Skripte waren teilweise so komplex, dass man sehr lange Zeit damit verbringen konnte um herauszufinden, was wie funktioniert.
Meinst Du das ernst? Ich sollte C-Programmierer sein, wenn ich geschwind einen eigenen Dienst ins System einklinken will? Ich kann mir ehrlich gesagt nicht vorstellen, dass so einfache Dinge mit systemd komplizierter werden.
Da dürfte eine einfache Service-Datei genügen. Du findest im Internet reichlich Beispiele, mal ein eher zufälliger Treffer von Google: https://wiki.archlinux.org/index.php/Systemd/Services
Die Beispiele sind relativ leicht zu durchschauen. Man hat typische Defaults in den "EnvironmentFile"-Dateien, Regeln für Start und Verhalten des Service sowie Abhängigkeiten.
Nett ist vielleicht auch das Beispiel für XBMC in diesem Wiki, das zeigt wie ein Socketabhängiges starten aussieht.
Eine einfache Konfiguration, kein C. C brauchst du nur, wenn du etwas machen willst, das hierüber hinaus geht. Für einen normalen Dienst dürfte das praktisch nie der Fall sein.
Nein, natürlich nicht, aber genau das "Problem" wurde ja sogar von systemd angegangen. Eine systemd Service Datei (wie von LH_ ja schon netterweise verlinkt) kann nun wirklich jeder schreiben der ein paar Gehirnzellen zur freien Verwendung besitzt. Ein Startup-Skript für sysvinit hingegen erfordert wesentlich Einarbeitung in die Materie und zumindest ein Grundverständnis von Shell Skripten, was längst nicht jeder hat.
Mir kommen die Tränen - wirklich. Dann raus mit den Komponenten aus dem System, die aus dem SystemD-Sourcetree stammen. Wech mit udev. Und logind braucht eh kein Mensch.
apt-get purge udev
Was wird alles gekillt? Eigentlich interessant, so ziemlich alles, was mit xserver-xorg anfängt ist weg, kein network-manager mehr, kein libsane, kein fuse*, kein gvfs*, kein hplip,* kein ntfs*, kein sysvinit. Alsa-base* und acpi-support werde ich auch nicht mehr brauchen, sysvinit auf der Installtion auch nicht mehr. Klasse, vielleicht etwas zu radikal, spart aber jede Menge Plattenplatz.. Systemd ist gleich mit entsorgt worden. Wenn ich jetzt noch eine Idee hätte, wie ich schmerzfrei mit dem System arbeiten soll, dann wäre alles Wölkchen.
Dann raus mit den Komponenten aus dem System, die aus dem SystemD-Sourcetree stammen. Wech mit udev. Und logind braucht eh kein Mensch. ;)
Udev und systemd sollen ja auch weiterhin separat eingesetzt werden können. Dennoch ist die Zusammenführung der beiden eine dieser für mich bedenklichen Entscheidungen. Es ist gewiss purer Zufall, dass beide Entwickler bei Red Hat angestellt sind.
Wie scherzte andernorts ein Forist:
A: "Welchen Kernel setzt du ein?" B: "Weiß ich nicht, aber hier läuft systemd x.y.z. Das macht doch heute eh alles"
Die meisten Debianuser sind sehr vernünftig, aber es ist ein sehr "trolliges" Thema, einige Menschen scheint es besonderen Spaß zu machen, bei dem Thema unpassende Kommentare in der Mailingliste abzusetzen. Erkennbar daran, dass es dann jeweils die ersten und einzigen Wortmeldungen dieser Leute sind.
Wobei auch ein paar erfahrene Mitglieder aktuell etwas emotional reagieren, aber selten in wirklich unpassender weiße.
... hätte man wetten können. Die Quote wäre nicht sehr hoch gewesen. Ich schätze allerdings, dass die Diskussionen noch ne ganze Weile anhalten werden.
So traurig. Ein weiterer Schlag gegen die Vielfalt.
Vielfalt ist nicht immer gut. systemd ist sauber programmiert und upstart hat keine Vorteile.
Nun, Upstart hat durchaus seine Vorteile, wie eine einfachere Portierbarkeit, jedoch stellt sich die Frage: Reichen diese?
Nebenher ist auch die Portierbarkeit von SysVInit nie sonderlich gut gewesen, weswegen u.a. die Debian-Hurd Entwickler spezielle Abstraktionslösungen bauen musste, um SysVInit nutzen zu können. Insofern wäre Systemd hier nicht einmal schlimmer.
Upstart wäre wohl ebenfalls nicht ohne Anpassungen nutzbar, lediglich der Aufwand wäre geringer, da es die Lösungen von SysVInit nutzen könnte.
SysVInit ist sehr klein und brauchte vergleichsweise wenig Anpassungen. Systemd ist eine ganz andere Liga.
"SysVInit ist sehr klein und brauchte vergleichsweise wenig Anpassungen. "
Das kommt darauf an, wo du die Grenze bei SysVInit ziehst. Gehen die Scripte der Distribution mit hinein, ist es weder klein noch Anpassungsarm für andere Systeme.
Speziell beim Thema mounten von Speichermedien und Netzwerk ist es dann doch sehr Systemabhängig.
Sauber programmiert wiegt die vielen Nachteile nicht auf. Vendor-Lock-In. RedHat bekommt zu viel Einfluss auf die Systeme. Das ist mein Problem mit Systemd. Nicht immer sollte man AUSSCHLIEßLICH die technischen Vorteile berücksichtigen. Ich fürchte bald wird alles Mögliche von Systemd abhängen und der Moloch ist für eine Community nicht so leicht handlebar, wie ein Init-System (was ja Systemd nicht (nur) ist, wie wir auch immer wieder von den Befürwortern hören). Warten wir mal ab, wie lange es dauert bis Debian oder andere Systemd forken müssen, weil sie dessen Entwicklung nicht mitgehen wollen.
Schon witzig: Angst davor haben, dass ein Unternehmen Einfluss auf eine Distribution bekommt, wenn es eine Software einsetzt, die *auch* von ihm entwickelt wird. Gleichzeitig sich aber wünschen, die Distribution setzt eine andere Software ein, die *ausschließlich* von einem anderen Unternehmen entwickelt wird.
Wie heuchlerisch oder naiv oder beides muss man eigentlich sein um das ernsthaft zu vertreten?
asdfghjkl hat sich doch gar nicht für upstart ausgesprochen. Gibt ja noch andere Lösungen.
...die technisch jetzt wirklich nicht mehr zeitgemäß sind. Und das nicht nur wegen ein paar Sekunden Bootzeit.
Mir scheint dies auch kaum das Ziel der systemd Entwickler zu sein. Während upstart tatsächlich relativ genau dann stehen blieb, als das System schneller damit bootete, wird systemd eher in die Richtung einer sinnvollen Lösung für den Betrieb des Systems entwickelt.
Aber diesen Unterschied legen bereits die Namen nahe:
upstart
systemd
Im Grunde sind die Ziele und das Verständis zur Aufgabe der Projekte damit schon deutlich aufgezeigt
Die einzige Alternative zu systemd aus technischer Sicht ist aber upstart. Welche andere Lösung ist zukunftsfähig oder wenigstens zeitgemäß?
(und selbst upstart hat da Defizite, da die Entwicklerbasis sehr eingeschränkt und abhängig von den Geldern eines Mäzen ist)
Welche Funktionen muss ein Init-System erfüllen um deiner Meinung nach zukunftsfähig oder zeitgemäß zu sein?
Na zumindest mal eine parallele Abarbeitung nach Abhängigkeiten. Das lineare Abarbeiten der Init-Jobs ist nicht nur langsam sondern auch konzeptionell aus dem letzten Jahrtausend. Man sehe sich nur an, wie SysVinit die liniare Reihenfolge der zu startenden Init-Scripte regelt.
Ein Init-System muss heutzutage auch die Prozess sauber trennen, was systemd mit den cgroups hinbekommt. Für was gibt es denn Fortschritt auf diesem Gebiet, wenn sich Prozesse dann immer noch durch forken vor dem Init-System verstecken können? Aus Spass? Nein, sondern weil es Sinn macht und gebraucht wird. Ein Init-System muss Dienste zuverlässig beenden können.
Als Administrator möchte ich das Schreiben von Init-Scripten abgenommen bekommen. Anweisungen, welche Abhängigkeiten ein Dienst hat, müssen ausreichen.
Das sind imho die Hauptpunkte, die ein modernes Init-System mitbringen muss. Klar sind das nicht alle Vorteile von systemd.
"Na zumindest mal eine parallele Abarbeitung nach Abhängigkeiten."
Außerdem das starten und stoppen von Diensten anhand bestimmter Situationen, anstatt dies stur nur beim Boot zu tun / diese Aufgabe anderen Diensten zu überlassen.
Oh ja. Aber ich glaube dieses Coldplug-Desaster haben die meisten schon verdrängt.
MacOS ist vielleicht auch sauber programmiert, aber benutzen möchte ich es trotzdem nicht. Systemd spaltet die Community, daher wäre jede andere Lösung vorzuziehen. Sauber vorprogrammierter Ärger steht an.
Ob nun systemd/poettering oder upstart/shuttleworth die Community spaltet, ist doch eher zweitrangig.
Zum spalten und sich spalten lassen gehören immer zwei.
Mich stört an der Diskussion, dass OpenRC keine Chance bekommt.
Ich finde das würde besser zu Debian passen. Wenn man bedenkt, wie langfristig sich die Entscheidung auswirkt, hätte man OpenRC ruhig mehr Zeit geben können (und so lange bei sysvinit bleiben können). Wenn alle großen Distros Systemd nutzen, dann werden die Alternativen ziemlich dumm da stehen.
OpenRC wäre politisch in jedem Fall die beste Entscheidung gewesen. Zusätzlich funktioniert OpenRC wohl auch schon mit BSD.
Systemd wurde aber nicht von Politikern gewählt. In der Meldung heist es:
Die Frage kam doch auf der CTTE Mailingliste auch mehrfach auf, wo sich Leute beschwert hatten, dass OpenRC zu wenig Chancen eingeräumt wurden und es gab auch recht ausführliche Antworten der Mitglieder des CTTE.
Grundtenor war, dass man sich zunächst einmal zu den verschiedenen Lösungen "eingelesen" hatte, d.h. die Dokumentation dazu angeschaut hatte um einen ersten Eindruck zu bekommen. Das macht auch Sinn, da man insbesondere OpenRC zunächst nicht "einfach so" auf Debian testen konnte, das Paket wurde ja im Laufe der Diskussion wesentlich weiterentwickelt, um überhaupt eine brauchbare Lösung verfügbar zu haben.
Irgendwann gab es dann auch entsprechende VM Images, mit denen das Testen vereinfacht wurde, allerdings war hier der Schaden für OpenRC schon getan: Es existierte einfach zu wenig Dokumentation, um sich über den wirklichen Funktionsumfang, die Beschränkungen etc. ein Bild zu machen.
Dieses teilweise nur scheinbare, aber auch wirkliche Defizit an Dokumentation bei OpenRC hat dem System dann den entsprechenden Nachteil gegeben, den es bis Ende nicht mehr aufholen konnte, zumal Upstart aber insbesondere Systemd mit umfangreicher und detaillierter Dokumentation glänzen. Auch wenn ja einiges für die Integration von OpenRC auf Hurd und kFreeBSD getan wurde, aber das war dann wohl nicht mehr genug.
systemd:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=systemd
sysvinit:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sysvinit
Setzt man nun ins Verhältnis wie lange es beide schon gibt,
bin ich unentschlossen was ich davon halten soll...
Zudem wird systemd immer größer und es ist nunmal irgendwann zu groß für die PID-1.
"Setzt man nun ins Verhältnis wie lange es beide schon gibt,
bin ich unentschlossen was ich davon halten soll..."
Neue Systeme sind immer etwas anfälliger, das ist völlig normal. Gerade wenn vieles gleichzeitig entwickelt wird, bleiben Probleme nicht aus.
"Zudem wird systemd immer größer und es ist nunmal irgendwann zu groß für die PID-1."
Eigentlich macht systemd als Systemdienst auf PID-1 nicht sonderlich viel, nur das was absolut nötig ist, um seine Aufgabe zu erfüllen.
Das mag mehr sein als bei SysVInit, allerdings sind die Erweiterungen von Systemd in PID-1 durchaus sinnvoll dort platziert.
Schon wichtig ob das Problem nun im pid 1 oder in einem von ihm aufgerufenem unpriviligiertem Prozess ist.
Was steht eigentlich in den CVE?
Für zwei der Fehler müsstest du das Äquivalent im Syslog-System suchen
für mindestens einen in im Loginmanager
einer steckt eigentlich in Polkit
die anderen zwei sind ebenfalls Fehler in Aufgaben die zu erfüllen sind aber nicht von SysVinit übernommen werden oder nicht mit SysVinit in Verbindung gebracht werden würden da sie dort in Scripten erledigt würden.
nur weil journald mit systemd in Verbindung gebracht wird steckt er noch immer nicht mit in PID1
Äh, doch genau das bedeutet das. Wer den Code komplett integriert und scharfgeschaltet ausliefert muss auch die darin enthaltenen Fehler beheben.
Klar, ist aber trotzdem kein Fehler in PID 1.
Wenn man die CVEs von sysvinit und systemd vergleichen will (und einen halbwegs sinnvollen Vergleich sucht), dann muss man sich auf die CVEs von systemd beschränken, welche PID 1 zugeordnet werden können, exklusive logind, journald o.ä.
Naja man wird sehn, abwarten und Tee trinken
Ich machs wie die letzten 10Jahre in denen Linux benutzte... was gut und zuverlässt mit vertretbaren Aufwand läuft bleibt auf dem Rechner alles andere wird wieder gelöscht
Hier macht Ubuntu einiges wohl richtig, auch wenn viele was anderes behaupten :huh:. Umsonst würde es nicht solange auf meinen Rechner bestand haben. Mit Systemd bin ich bis jetzt eher negativ in Berührung gekommen, vielleicht macht das Debian jetzt besser.
Diese von Dir so sehr gewünschte Vielfalt haben wir nun bald bei grafischen Oberflächen: X11, Wayland und Mir. Ist das wirklich so toll?
Nö, im Grunde genommen ist das kein Schlag gegen die Vielfalt, sondern ein Wechsel von "wenig Vielfalt" auf "wenig Vielfalt" in einer anderen Ausführung.
Bis vor 3-4 Jahren gab es im Linuxumfeld eigentlich nur ein Init: sysvinit
Es gab bei der Umsetzung des Inits mit sysvinit eine sehr große Vielfalt, aber bei genau dieser Vielfalt wirst du wohl wirklich Niemanden finden, der das begrüßt, denn das war schlicht und einfach Murks und Chaos.
Dann kamen Upstart auf Ubuntu und OpenRC auf Gentoo auf, aber als "gesunde Vielfalt" würde ich das auch nicht bezeichnen, zumal OpenRC ja außerhalb von Gentoo nur in sehr speziellen Fällen Verwendung fand (z.B. auf Arch Linux).
Kurz gesagt: Eine wirkliche Vielfalt gab es beim Init eigentlich nie. Es gab eine kurze Phase, bei der mehrere Lösungen um die Ablösung des alteingedienten Monopolisten gesucht haben, dass sich da langfristig eine Variante durchsetzen wird war eigentlich absehbar und eine Zeit lang hätte man ja sogar vermuten können, dass das Upstart ist (wurde ja auf einigen Distributionen übernommen). Dass es das nicht geschafft hat hatte eben sowohl rechtliche (CLA) als auch technische (Events) Gründe, mit denen man übereinstimmen kann, aber natürlich nicht muss.
Was die anderen Komponenten von systemd angeht (journald, logind, getty, udev, timer), so kann auch in Zukunft auf alternative Lösungen setzen. Ob dann (z.B. im Fall von logind) auch alternative Lösungen von Programmen unterstützt werden ist aber im Endeffekt nicht Frage von systemd, sondern der Entwickler der Programme.
Denen kann man aber wohl kaum einen Vorwurf machen, denn auch heute schon gibt es z.B. Programme, welche openssl unterstützen, aber nicht gnutls (oder umgekehrt). So eine Entscheidung obliegt nunmal den Programmierern.
[q]"gesunde Vielfalt"[/q]
Gentoo hatte schon vor OpenRC eine eigene Lösung verwendet. Arch hatte vor Systemd eine eigene sehr einfache Lösung, die Arch mit ihrer KISSigkeit beworben hat. Slackware verwendet auch eine eigene BSD-ähnliche Lösung. Die Vielfalt wahr schon da, du hast sie nur nicht bemerkt, da sie nicht mit so aggressiven Mitteln wie Systemd in den Markt gedrückt wurde.
Ich war lange Zeit Gentoo Nutzer und habe in der Zeit auch OpenRC genutzt. Dass es noch andere Systeme gab war mir schon klar, aber das waren eben eher Nischenanwendungen. Meiner Meinung nach waren Upstart und auch OpenRC die ersten echten Versuche eine nachhaltige und moderne Alternative zu sysvinit zu entwickeln.
(Init-)Systeme für Nischenanwendungen (sei es nun politisch oder technisch motiviert) wird es auch in Zukunft geben und wie auch bisher wird das sicher manche Vorteile und manche Nachteile haben.
Abgesehen davon wurde systemd vor allem zu Beginn nicht "aggressiv" in den Markt gedrückt. Die ersten 1-1.5 Jahre zu systemd waren eigentlich recht normal. Das was man als "aggressiv" bezeichnen könnte hat sicher eher in den letzten 1.5-2 Jahren entwickelt, hauptsächlich seit journald als Bestandteil des systemd-Pakets entworfen wurde.
Davor war aber das Interesse an systemd auch schon sehr groß, da es von der Konzeption ganz anders als alles andere war was man im Linuxbereich bis daher kannte und, da offensichtlich damals schon viele Leute (auch unter den Distributoren) das Potential der Technologie erkannten.
zur Wahl von systemd, war der Vorsitzende des Gremiums, Bdale Garbee.
Nun braucht es aber eine Zweidrittel-Mehrheit unter den 1000 Entwicklern, um die Entscheidung zu revidieren.
Erinnert mich irgendwie an Parallelen zur Politik, wo durch die Unentschlossenheit weniger, ungeliebte Entscheidungen für Viele zustande kommen.
Diese Volksentscheide (GR) lassen sich dann später nur noch mit ungleich höherem Aufwand korrigieren, und scheitern dann häufig mangels Beteiligung der Wahlberechtigten. Sei es wegen Frust (Politikverdrossenheit) oder Desinteresse, oder Uneinigkeit.
Zitat:
"und die lediglich eine einfache Mehrheit braucht, um das Ergebnis des CTTE zu kippen"
Nebenher, ist CTTE nicht als Kürzel korrekt, anstatt des mehrfach im Artikel verwendeten TCCE?
Du hast natürlich Recht. Ich weiß nicht, wie oft ich das die letzen Monate (richtig) geschrieben habe. War schon spät gestern
Das mit der Einfachen Mehrheit habe ich nicht überlesen, doch in der Vergangenheit wurde meist von 2/3 gesprochen, was wohl normalerweise bei einer GR so üblich ist.
Daher hab ich das so geschrieben obwohl es hier anders stand.
Heise schreibt aktuell auch noch was von einer Zweidrittelmehrheit hier:
http://www.heise.de/open/meldung/Debian-entscheidet-sich-fuer-Systemd-zumindest-fuers-Erste-2111065.html
Scheinbar ist man für die systemd Entscheidung also vom Gewohnten abgewichen, so wie bei Golem zu lesen:
"Denn bei einer bestimmten Auslegung der Debian-Verfassung reicht eine einfache Mehrheit in dieser Entscheidung wohl nicht aus. Deshalb könnte auch die Gesamtheit der Debian-Entwickler in einer sogenannten General Resolution die Entscheidung des CTTE überstimmen. Dazu ist eine Zweidrittelmehrheit erforderlich. Doch das CTTE diskutiert derzeit auch, dies zumindest in der Init-System-Diskussion auf eine einfache Mehrheit zu ändern."
Insofern zeigt muss es wohl stimmen was hier zu Lesen ist. Also doch mal wieder gut recherchiert von Pro-Linux.
Gut gemacht, liebe Redaktion.
Mein Fehler, sorry.
Das Gremium hat aber entschieden, daß man einer Entscheidung der 1000 Entwickler auch bei einfacher Mehrheit folgen wird.
SysVInit ist seit Jahrzehnten bewährt. Warum muss man wegen ein paar Sekunden bootzeit bewährte Dinge wegwerfen? Systemd ist ein Monster. Es frisst die Netzwerkkonfiguration(netctl), udev und wer weiß was noch alles. upstart ist quasiproprietär. Gruselig, das alles. Man hätte bei SysVInit bleiben s
ollen.
Meinst du nicht, daß in dem technischen Gremium Leute sitzen, die sich sehr ausführlich mit den verschiedenen Alternativen beschäftigt haben, die Vor- und Nachteile abgewägt haben und dann ihre Entscheidung getroffen haben?
Die Techniker können auch die Augen vor der Realität nicht verschließen. Systemd frisst sich in div. Subsysteme und nimmt Funktionen auf die vorher von anderen Programmen getan wurden sind. Entweder pflegt man all diese oder schwimmt mit dem Strom. Scheiß auf Modularität und Unix solange es funktioniert.
Auch unter System dienst es noch immer eigenständige Dienste und Programme. An einigen Stellen wurden die Projekte praktisch integriert, an anderer Stelle hat man bemerkt, das in Systemd eine vergleichbare Lösung (aus anderem Hintergrund) existiert, die als Basis besser geeignet ist.
Das die Systemteile getrennt waren bedeutet nicht, das ihre Trennung in verschiedene Projekte effizient, von Vorteil für die Nutzer oder einer sinnvollen Planung entsprechend. Oft war die Trennung schlicht "passiert". Da haben einfach verschiedene Leute getrennt an Dingen gearbeitet.
Systemd als Projekt nimmt Funktionen auf, die früher andere Software erledigt hat. Das ist richtig. Systemd ist aber trotzdem Modular, da diese Funktionen genau so noch von anderer Software erledigt werden kann. Ob das Sinn macht ist eine andere Frage, aber du kannst nach wie vor die alte Software mit systemd einsetzten um musst nicht auf logind und Co setzen.
Aber wie gesagt: Das macht keinen Sinn, da das Systemd-Projekt die beste technische Lösung bietet.
Die Techniker haben systemd bereits verstanden, während du dich noch von FUD blenden läßt.
Ja, seh ich ähnlich. Ich bleib bei meinem ZX Spectrum. Dieser ganze neumodische Dreck kotzt mich an! Damals hab ich sogar noch selbst gelötet, aber bei den heutigen Monstern geht da gar nichts mehr. Weg mit dem Scheiß!
Es wäre vermutlich schon möglich gewesen mit SysVInit zu booten und systemd nur sehr früh zu starten damit es seine Aufgabe als System Daemon erfüllen kann.
Wird aber vermutlich auch Vorteile haben systemd auch gleich das Booten machen zu lassen
"systemd nur sehr früh zu starten damit es seine Aufgabe als System Daemon erfüllen kann."
Dann hätte Systemd aber keine Kontrolle über die durch SysVInit gestarteten Dienste. Abgesehen davon ergibt das wenig Sinn, immerhin kann Systemd die Aufgaben von SysVInit ja ebenfalls übernehmen.
Das wäre ein Flickwerk ohne jeden Mehrwert, aber mit vielen Fehlerquellen. So etwas macht man rein aus dem Prinzip, nicht weil es sinnvoll ist
Richtig. Ich wollte nur darauf eingehen, dass der meiner Meinung nach wesentliche Einsatzzweck von systemd nicht das Booten ist.
Wenn jemand unbedingt der Meinung ist anders zu booten, bleibt systemd trotzdem als derzeit beste Lösung für seine Hauptaufgaben.
Macht zwar weniger Sinn als gleich systemd auch das Booten miterledigen zu lassen, aber wenn man mit diesem Teil nicht einverstanden ist, soll man es halt nicht dafür benutzen
Interessanterweise hatten quasi alle der CTTE-Mitglieder (außer Ian Jackson, der aber eher ein Protestvoting abgegeben hat) alle Init-Optionen über sysvinit gestellt.
Abgesehen davon sind die Gründe nicht (oder zumindest nicht nur) Bootzeit, es gibt viele andere Gründe. Mit anderen Worten: Beschäftige dich mal wirklich damit (so wie die CTTE-Mitglieder) und dann urteile erneut.
Systemd ist auf Linux einfach ein Muss. Und es ist gut, dass es ein Muss ist. Sich jetzt gegen Systemd zu entscheiden, hat nur aufschiebende Wirkung und man muss die ganze Arbeit zwei mal machen.
Ich hoffe, dass sich die Wogen bald wieder glätten.
Viele Grüße und weiterhin alles Gute für meine Lieblingsdistro!!!
Ich befürchte eher ein abwandern von Entwicklern. Wer sollte sich auch noch die Mühe machen wenn der Pöbel nach den Linux@X86 und Systemd ruft.
Debian musst selbst wissen wo sie hingehören.
Systemd ist nicht auf x86 Prozessoren beschränkt, sehr wohl aber aktuell auf Linux.
Bezüglich Debian und nicht-Linux Kernel sei gesagt, das auch das aktuelle SysVInit z.B. bei Hurd nicht ohne größere Anpassungen nutzbar ist. Die Anpassungen zu den cgroups und co. werden bereits durchgeführt, vor allem da sie auch für andere Anwendungen notwendig sein werden. Insofern ist es den Debian-Hurd Leuten - soweit ich bisher gelesen habe - relativ egal, für was sich Debian entscheidet.
Bei kFreeBSD dürfte es sicher nicht anders aussehen.
Zudem ist systemd durchaus bei vielen Entwicklern beliebt, einige der Funktionen können das Leben durchaus erleichtern.
Genauso gut kann man sagen, das Debian Entwickler verlieren würde, wenn sie bei SysVInit bleiben. Sie würden auch Entwickler verlieren, wenn sie Upstart wählen. So ist das nun einmal, wenn kein Konzens bei einer Sache besteht.
Und für KDBus werden dann auch noch nachgereicht? Wie wir alle wissen ist Lennart scharf auf eine Integration.
Und hättest du mein geschriebenes auch richtig verstanden, wäre die aufgefallen dass das eine Kritik am Demokratieprinzip war. Die Masse hat kein Interesse was Minderheiten wollen. Klar gibts wenig die abseits des Mainstream auf dieses Exoten setzen. Nun gibts für sie auch weniger Gründe auf Debian zu setzen.
Und wieso sollen Entwickler verschwinden wenn man SysV Init verwendet? Klar ist das nicht mehr zeitgemäß aber es erfüllt seinen Zweck verletzt nicht die Schichtenarchitektur und beschränkt sich aufs nötige.
"Und hättest du mein geschriebenes auch richtig verstanden, wäre die aufgefallen dass das eine Kritik am Demokratieprinzip war."
Hier sei angemerkt, das du das zwar gemeint haben magst, das aber aus deinem Text nicht wirklich ersichtlich wird. Er ist ziemlich knapp, und dabei durchaus missverständlich. Wenn du richtig verstanden werden willst, führe deine Argumente einfach das nächste mal etwas klarer aus, dann missversteht man dich auch nicht.
Nebenher haben die "Minderheiten" bei Debian bisher gar keinen Einfluss auf die Entscheidung verlangt. Ich lese viel davon, das man doch gefälligst Rücksicht auf Hurd und co. nehmen soll, doch bisher sind mir aus dieser Richtung gar keine Anforderungen bekannt geworden. Nur Aussagen, nach dem auch die bisherige Lösung einen bedeutenden Aufwand erforderte, und sich das mit keiner Wahl ändern wird.
Die Aussagen, das man keine Rücksicht auf die kleinen Projekte nimmt, scheinen mir inzwischen mehr als künstlich, und gehen an der Realität der Projekte völlig vorbei.
Zum Thema:
"Und wieso sollen Entwickler verschwinden wenn man SysV Init verwendet?"
Hast du dir bereits geantwortet:
"Klar ist das nicht mehr zeitgemäß"
Das hat weitreichende Folgen. Vor allem wenn immer mehr andere Distributionen auf systemd setzen, und dessen Vorteile nutzen, wird Debian Probleme bekommen, wie auch Ubuntu. Solch einen Ärger wollen nicht alle Nutzer, dann werden einige Wechseln. Es ist also nicht so, das ein verbleib bei SysVInit - der Zudem absolut keine Option irgendwo in der Diskussion aktuell ist - ein Problem vermeiden würde.
Nebenher sei gesagt, das auch systemd keinerlei "Schichtenarchitekturen" verletzt. Zum einen weil es dafür gar keine Vorgaben gibt, zum anderen weil systemd durchaus logisch und sinnvoll geplant ist.
Vielmehr trennt es die einzelnen Ebenen weit sauberer, als dies aktuell der Fall ist. Diverse Hacks bei SysVInit um mit der Abarbeitung der fstab in einem Modernen System klar zu kommen sind grässlich, und in systemd weit sauberer gelöst.
SysVInit ist eine Sammlung unschöner Scripte und wenig tauglicher Hacks, die nur mit Spucke zusammen gehalten werden. Darüber gibt es eigentlich gar keine echte Diskussion.
Man versucht dieses System seit Jahren los zu werden, nicht erst mit systemd. Selbst upstart ist schon seit 4 Jahren in der Entwicklung.
Noch einmal sei zudem klar gesagt, das Systemd kein großer Dienst ist, sondern zwei Dinge zugleich:
1. Ein schlanker Pid-1 Dienst, der nur das nötigste tut (Dienste starten/stoppen, Abhängigkeiten beachten usw., was ein moderner Startdienst eben können muss)
2. Der Name für ein Projekt, der diesen Dienst und viele weitere umfasst.
Viele haben Angst vor Punkt 1, und kritisieren diesen dann mit Punkt 2, der damit aber wenig zu tun hat.
Ach, bevor ich es vergesse: Bitte immer auch daran denken, das wir alle einen Kernel als Basis nutzen, der so ziemlich jede Regel für sauberes Softwaredesign verletzt, die in den letzten 30 Jahren entwickelt wurden. Und es stört niemanden, denn er funktioniert.
Gute güte, es gab schon Webserver für den Kernel!
Systemd ist um einiges ordentlicher als der Linux-Kernel, dennoch werden an systemd Anforderungen gestellt, die kaum ein normales Projekt erfüllen kann.
Dabei wird oft ignoriert, das systemd bereits weit sauberer umgesetzt ist als alles, was es ersetzen soll.
Persönlich habe ich immer noch ein Herz für upstart, aber realistisch betrachtet hat das keine Zukunft.
Linux-Entwickler müssen Linux-Funktionen für andere Kernel "nachreichen"? Hab ich das gerade richtig verstanden?
Ich habe das Gefühl, die ganze Debatte hat sich bereits schon zu stark von der Wirklichkeit entfernt und dreht sich nur noch um Befindlichkeiten.
Absolut. Am Anfang ging es durchaus noch stark um die technischen Vor- und Nachteile.
Das Problem dabei: Während am Anfang viele noch uninformiert waren (das trifft auch auf mich zu), wird es mit der Zeit schwerer die fakten zu ignorieren. Wenn man also etwas ablehnt, bleiben irgendwann nur noch Gefühle und Befindlichkeiten.
Aktuell auch gut auf der Debian Mailingliste zum Thema zu beobachten. Eigentlich traurig, aber das ganze wird sich wieder beruhigen.
In 2 Jahren werden alle den Kopf schütteln, wie man über so etwas so lange diskutieren konnte.
Keine Ahnung ob du mich bewusst missverstehen wolltest. Er schrieb, dass Kernel Features in Hurd integriert werden damit systemd damit funktioniert. Das ist ja wohl kaum eine Lösung auf Dauer, wie ich bereits schrieb in Hinblick auf weitere Features wie KDBUS. Mal von FreeBSD abgesehen, dass aktiver in der Entwicklung ist und keiner würde sich das antun wollen seinen Code im Sync zu halten.
"Das ist ja wohl kaum eine Lösung auf Dauer"
Wird es sein müssen, denn auch aktuell haben die Debian/Hurd Entwickler bereits Linux-Eigenheiten implementiert, anders lässt sich das System mit SysVInit, wie es Debian nutzt, gar nicht booten.
Solange Hurd ein so kleines Projekt innerhalb von Debian ist, wird es sich an das größere Projekt anpassen müssen. Soweit ich sehe ist das auch für die Debian/Hurd Entwickler kein großes Problem.
Warum ein kFreeBSD das nicht umsetzen sollte kann ich nicht nachvollziehen, zumal die Anforderungen von systemd durchaus sinnvoll sind. Ebenso ist KDBUS einen sinnvolle Entwicklung.
Da bei Hurd ohnehin die Entwicklung langsamer vonstatten geht, ist die Wahrscheinlichkeit das die Lösung eine Weile bestand hat größer als bei FreeBSD.
Und deshalb warum sollte jemand den FreeBSD Kernel anfassen wollen? Technisch sind das schon andere Größenordnungen. Bei FreeBSD ist jedenfalls kein cgroups, systemd oder KDBUS in Planung.
"Und deshalb warum sollte jemand den FreeBSD Kernel anfassen wollen?"
Weil es notwendig wäre, um systemd als PID-1 eines Debian/kFreeBSD nutzen zu können.
Technisch wäre es nichts anders als bei Hurd auch. Wohlgemerkt, die Anpassungen bei Hurd sind nur bei Debian zu finden, es sind dort eigene Module (es hat eigentlich einen anderen Namen, die Bezeichnungen bei Hurd wollen wir aber gerade nicht einfallen) für diesen speziellen Fall.
Fakt ist: Debian war zuerst eine Linux Distrie, und ist davon auch nicht abgewichen. Hurd und FreeBSD als Kernel sind Spielwiesen, die daneben dazu gekommen sind. Entsprechend passen sich diese Unterprojekte dem Hauptprojekt an, und nicht umgekehrt.
Noch einmal klar: Es geht nicht um FreeBSD, es geht um Debian/kFreeBSD. Das ist ein wichtiger Unterschied. FreeBSD ist ein großes, in sich vollständiges Projekt, von dem Debian/kFreeBSD nur einen Teil nimmt, um ihn im Debian/GNU Userland zu nutzen.
Im Grunde ein kleines Monster
Nebenher, wie ich inzwischen gesehen habe, haben die Debian/HURD Entwickler wohl bisher kein sysvinit verwendet, sie wollen dies vielmehr für die Zukunft tun. Möglichweis wird man zu openrc wechseln.
Insofern ist die Diskussion über systemd für Debian Hurd damit eh irrelevant, sie werden tun und lassen was sie wollen.
Und auch kFreeBSD, laut deren Mailingliste, wird wohl schlicht etwas eigenes Pflegen. Das Thema ist dort aber eher klein, niemand scheint sich darüber aufzuregen.
Aktuell haben wir hier wohl mehr Posts zu dem Thema produziert, als die betroffenen
Wie gesagt, künstliche Diskussion.
Die exakten Anpassungen sind mir auch nicht alle bekannt, aber ein cgroup Equivalent sollte doch im Kernel sein, den hat FreeBSD definitiv nicht. Und einfach die Teile herauspatchen die der Kernel nicht hergibt, ist ebenso aufwendig wie ein komplett eigene Lösung auf Basis etwas anderes zu nehmen.
Fakt ist aber auch Debian wollte sich nie als reine Mainstream Distro sehen nur den aktuellsten Trends und Plattformen folgend. Der Sinn solcher Spielwiesen ist ja nicht nur der Proof-of-Concept sondern auch Abhängigkeiten zu verringern, Fehler zu finden, flexibler zu sein. Aus zwei komplett unterschiedlichen Init zieht man nicht viel raus. Da spielts auch keine Rolle wie groß das ganze ist.
Wie gesagt ist die Diskussion eher künstlicher Natur. Auf den betroffenen Mailinglisten findet sie in dieser Form gar nicht statt.
Die Diskussionen dort gehen klar in die Richtung eigener Init-Lösungen, die von Debian abweichen, egal ob man sich dort für Upstart oder Systemd entscheidet.
Das sorgt dort auch für kein Kopfzerbrechen, einzig weiter gepflegte Init-Scripte wünscht man sich, weil diese von allen alternativen Verstanden werden.
Das ist sicherlich ein tragbarer Kompromiss, da diese ja sowieso bereits vorliegen, und sich zudem selten ändern.
Es sei zudem angemerkt, das Debian/Hurd wie gesagt bereits jetzt ein anderes Init-System nutzte, und das ganze bewusst. Man wechselt wohl gerade zu sysVInit, aber das ist wohl eher ein Übergang.
Dafür wiederum wurden eigene Erweiterungen entwickelt, damit dies überhaupt möglich ist. Den SysVInit ist bei Debian Linux-spezifisch implementiert, laut eines Beitrags vor allem in Bezug auf die Erkennung von verfügbarer Hardware (was auch logisch ist).
Solche Erweiterungen sind bei kFreeBSD natürlich auch möglich, und vermutlich auch bereits implementiert, wobei der FreeBSD Kernel dem Linux-Kernel allgemein ähnlicher ist, als dies beim Hurd-Microkernel-System der Fall ist.
Das man mit einem kFreeBSD jedoch wirklich Abhängigkeiten verringert... das ist wohl eher ein Wunsch als den Realität. Damit das der Fall ist, müsste es auch praktisch voll nutzbar sein, was mir nicht so zu sein scheint.
Aktuell sind Debian/kFreeBSD und Debian/Hurd Spielwiesen und Proof-of-Concept, aber ganz sicher keine tatsächlich genutzen Projekte.
Und viel wichtiger: Diese Projekt scheinen auch nicht den Anspruch zu erheben, den restlichen Debianern vorzuschreiben, wie sie ihre Entscheidungen fällen.
Es scheint mir eher so zu sein, das sie die Vorteile von Unterschieden und passenden Lösungen zu schätzen wissen, und die Wahl eines passenden Systemdienstes für Linux durchaus nachvollziehen können.
Die Mailinglisten bei diesen Projekten sind jedenfalls mit Diskussionen zur praktischen Seite gefüllt, negatives zu der Änderung habe ich nicht finden können.
Ist aber auch nur eine Vermutung.
Ich nutze auch gerne den PPC-Port von Debian und das ist auch ein Grund, warum ich Debian so klasse finde. Allerdings muss ich als einfacher User akzeptieren, dass es immer Leute geben muss, die Arbeit und Zeit investieren - im Falle von Debian meist ehrenamtlich. _Wenn_ sich jemand darum kümmert, war es bei Debian allerdings auch immer so, dass es auch gemacht wurde, siehe z.B. Emdebian, verschiedene Betriebssystem-Kerne, verschiedene Plattformen - Projekte mit einer Zielgruppe von teilweise weit unter 1% der gängigen x86-User.
Ich kann jetzt also lamentieren, dass Vielfalt kaputt geht - oder ich engagiere mich für Zweige, die mich interessieren und die ich für erhaltenswert erachte. Siduction hat schon vor Monaten ein Debian auf systemd-Basis errichtet - umgekehrt kann jemand aus Debian-Quellen ein System auf VSysInit weiterführen (ein Debian-System mit Upstart gibt's ja schon). Du willst es? Mach es! Debian steht Dir nicht im Weg!
Grüße!
Es mag dir vielleicht nicht bewusst sein aber die freie Zeit eines jeden ist
begrenzt. Was nützt einem eine halboff. Version deren Fortbestand fraglich ist, wenn der Hauptzweig sich komplett anders entwickelt.
Dieses Problem gab es immer und wird es immer geben.
Dagegen kann das Debian Projekt auch wenig tun. Wenn zu wenig Leute in den kleinen Projekten sind, um diese sinnvoll weiter zu entwickeln, hilft auch die größte Sympathie nichts.
Noch einmal: Auch der aktuelle Bootprozess ist für die kleinen alternativen Kernel ein Problem, an dem sie arbeiten. Festhalten hilft denen auch nicht weiter.
Was sie brauchen sind Leute, die ihnen helfen. Wenn aber nicht genug Interesse daran haben, dann ist es eben auch nicht relevant darauf groß Rücksicht zu nehmen.
Das ist keine moralische Frage, anders als z.B. Sexuelle Orientierung, Hautfarbe und Herkunft von Menschen, ist die Wahl des Kernels eine rein persönliche Wahl, und Luxus noch dazu.
Die gleiche Begründung gab's auch bei Gnome oder DBUS zu hören. Es gibt doch Alternativen und forke doch, wenn du willst. Das Ergebnis ist bekannt, keiner mit Verstand benutzt Gnome außerhalb von Linux und ohne systemd.
Tatsächlich wurde GNOME ja nun auch geforkt, was nun einmal ein gültiger Weg ist. Ob ein Fork überlebt, hängt vom Einsatz der Leute ab. Und dieser hängt davon ab, ob die großen Worte ernst gemeint sind, oder doch nur heiße Luft
Nebenher hat die schwierige Entwicklung bei GNOME, meiner Beobachtung nach, vor allem kleinen Desktops wie LXDE und co. etwas aufwind gegeben. Eine durchaus positive Entwicklung.
Ob aktuelle GNOME-Versionen nun aktuell groß außerhalb von Linux genutzt wird oder nicht, dürfte relativ gleichgültig sein. Zum einen gibt es die älteren, die ihren Dienst tadellos verrichten (ich selbst nutze noch immer die 2.x Linie), zum anderen gibt es genug Alternativen.
Und auch wenn es hart klingt: Die Entwicklung bleibt nicht stehen, wenn kleine Systeme nicht schritt halten können, ist das nicht der Fehler der schnellen.
FreeBSD und co. auf dem Desktop sind die Nische der Nische. Selbst Linux ist auf dem Desktop in der Masse unbedeutend.
Nebenher, Linux geringe Bedeutung auf dem Desktop ist durchaus vergleichbar:
Solange die Schnittstellen bekannt sind, ist doch eigentlich alles in Butter.
Gestern habe ich mir einen neuen Drucker gekauft, für den es keine Linux-Treiber vom Hersteller gibt. Aber: Er spricht diverse Standard-Druckersprachen, womit ich ihn dennoch nutzen kann. Der Hersteller verbaut also nichts, unterstützt nur auch nicht direkt, dafür ist Linux als Markt zu klein.
Systemd ist nicht viel anders. Es hat eine Reihe von (sinnvollen) Anforderungen, die es für den eigenen Betrieb braucht. Diese können Problemlos von anderen Kernelns implementiert werden. Systemd selbst tut dafür nichts, hindert aber auch niemanden daran.
Das ist das beste, was eine Nischenlösung erwarten kann.
Dann wird aus Gnu/Linux also Red Hat/Lennux. Bislang war es sehr einfach möglich, Pulse Audio, die *kits, usw. loszuwerden. In großen Umgebungen mögen systemd, journald und Konsorten ihren Nutzen haben. Davon habe ich als Desktop-Nutzer aber nichts. Auf der einen Seite habe ich einen egozentrischen Millionär, der mit Amazon-Werbung unterjubeln will, auf der anderen Seite habe ich ein technisch sicherlich durchdachtes Monstrum, für das ich keine Verwendung habe und keinen Nutzen daraus ziehe. Es geht für mich nicht darum, sich neuen Entwicklungen aus Prinzip entgegen zu stellen. Nach anfänglicher Skepsis hat mich etwa Wayland überzeugt. Ich hege auch keinerlei Abneigungen gegen Poettering. Nur ist sein Weg nicht der meine. Das wird er gewiss verkraften.
Wenn ich das Bedürfnis haben sollte, mich auf einem unixoiden Desktop-Betriebssystem diktatorischen Vorgaben zu unterwerfen, bleibt konsequenterweise nur noch der Biss in den (sauren) Apfel.
Ich habe jetzt seit ein paar Wochen meinen Desktop auf ArchLinux umgestellt. Ich glaube, dass es den meisten Desktopnutzern ziemlich egal ist welches Init-System ihre Distribution nutzt, da sie eh kaum selbst Hand anlegen (gut, bei ArchLinux wird empfohlen netctl für die Netzwerkkonfiguration zu nutzen, das intensiv von systemd Gebrauch macht - von daher braucht man dort schon die Grundlagen). Andererseits ist im Fall der Fälle journalctl für den Desktopnutzer definitiv einfacher zu bedienen als das greppen von Logdateien. Ausgenommen natürlich ein Crash von systemd selbst, das wäre unschön zu Debuggen für einen Anfänger. Das ist aber hoffentlich die absolute Ausnahme. Wir werden es sehen.
systemd hat auch Vorteile für Desktopsysteme.
Die verbesserte Handhabung dynamischer Anforderungen sind speziell für den Desktop- bzw Laptopgebrauch interessant.
Auch eine leichtere machinelle Interaktion mit dem Basissystem hilft Deskoptbenutzern, weil damit die Einflussnahme auf Systemeinstellungen und ähnliches leichter über Endbenutzerwerkzeuge möglich ist.
"durchdachtes Monstrum"
Tatsächlich scheinen mir die einzelnen Elemente des Systemd Projekts eher einfacher Natur zu sein. Es sind recht viele, aber das ist eher der sauberen Trennung zu verdanken.
Am Ende täuscht man sich auch schnell: Bisher waren viele Projekte getrennt, aber eben doch im Einsatz. Aber wird es einfacher, nur weil es 10 Projekte sind, anstatt eines einzelnen?
> Wenn ich das Bedürfnis haben sollte, mich auf einem unixoiden
> Desktop-Betriebssystem diktatorischen Vorgaben zu unterwerfen,
> bleibt konsequenterweise nur noch der Biss in den (sauren) Apfel.
Wo es den 'launchd' gibt, welcher für SystemD-Ideen Pate gestanden hat.
Bingo! Genau das meinte ich.
Wenn jemand trotz Computer gerne seine mechanische Schreibmaschine nutzen will kann er das ja gerne tun, aber bitte nicht bei den Computernutzern beschweren.
Mechanische Schreibmaschinen sind hochkomplexe Geräte, deren Funktionsweise aber gleichzeitig sehr leicht von jedem verstanden werden kann, der bereit ist, sich ein wenig damit zu beschäftigen. Zudem ist die Funktion einer mechanischen Schreibmaschine für den Benutzer transparent. Genau das waren die ausschlaggebenden Gründe, die mich zu Linux gebracht haben.
Systemd folgt nun einer anderen Philosophie: Die Funktionsweise soll bewusst vom Benutzer ferngehalten werden. Gnome 3 schlägt in die gleiche Kerbe. Ich beschwere mich also nicht bei den Computernutzern, sondern darüber, dass die Entwickler einen bewährten Pfad verlassen. Deshalb auch mein Hinweis auf den sauren Apfel. Das angebissene Obst richtet sich seit jeher an Nur-Nutzer, die nicht wissen wollen un dmüssen, wie ihre Maschine arbeitet.
Gerade das stimmt aber überhaupt nicht, denn genau aus dem Grund hat systemd eine sehr umfangreiche Dokumentation.
Es ist natürlich richtig, dass man C können sollte um verstehen zu können wie systemd arbeitet und aufgebaut ist. Sich ein bisschen in Shell Skripte einzuarbeiten ist natürlich einfacher.
Dennoch würde ich hier zum Beispiel nicht übereinstimmen, dass sysvinit irgendwie transparenter war und von jedem verstanden werden konnte.
Die Skripte waren teilweise so komplex, dass man sehr lange Zeit damit verbringen konnte um herauszufinden, was wie funktioniert.
Meinst Du das ernst? Ich sollte C-Programmierer sein, wenn ich geschwind einen eigenen Dienst ins System einklinken will? Ich kann mir ehrlich gesagt nicht vorstellen, dass so einfache Dinge mit systemd komplizierter werden.
Da dürfte eine einfache Service-Datei genügen.
Du findest im Internet reichlich Beispiele, mal ein eher zufälliger Treffer von Google:
https://wiki.archlinux.org/index.php/Systemd/Services
Die Beispiele sind relativ leicht zu durchschauen. Man hat typische Defaults in den "EnvironmentFile"-Dateien, Regeln für Start und Verhalten des Service sowie Abhängigkeiten.
Nett ist vielleicht auch das Beispiel für XBMC in diesem Wiki, das zeigt wie ein Socketabhängiges starten aussieht.
Eine einfache Konfiguration, kein C. C brauchst du nur, wenn du etwas machen willst, das hierüber hinaus geht. Für einen normalen Dienst dürfte das praktisch nie der Fall sein.
Nein, natürlich nicht, aber genau das "Problem" wurde ja sogar von systemd angegangen. Eine systemd Service Datei (wie von LH_ ja schon netterweise verlinkt) kann nun wirklich jeder schreiben der ein paar Gehirnzellen zur freien Verwendung besitzt.
Ein Startup-Skript für sysvinit hingegen erfordert wesentlich Einarbeitung in die Materie und zumindest ein Grundverständnis von Shell Skripten, was längst nicht jeder hat.
Mir kommen die Tränen - wirklich. Dann raus mit den Komponenten aus dem System, die aus dem SystemD-Sourcetree stammen. Wech mit udev. Und logind braucht eh kein Mensch.
apt-get purge udev
Was wird alles gekillt? Eigentlich interessant, so ziemlich alles, was mit xserver-xorg anfängt ist weg, kein network-manager mehr, kein libsane, kein fuse*, kein gvfs*, kein hplip,* kein ntfs*, kein sysvinit. Alsa-base* und acpi-support werde ich auch nicht mehr brauchen, sysvinit auf der Installtion auch nicht mehr. Klasse, vielleicht etwas zu radikal, spart aber jede Menge Plattenplatz.. Systemd ist gleich mit entsorgt worden. Wenn ich jetzt noch eine Idee hätte, wie ich schmerzfrei mit dem System arbeiten soll, dann wäre alles Wölkchen.
Udev und systemd sollen ja auch weiterhin separat eingesetzt werden können. Dennoch ist die Zusammenführung der beiden eine dieser für mich bedenklichen Entscheidungen. Es ist gewiss purer Zufall, dass beide Entwickler bei Red Hat angestellt sind.
Wie scherzte andernorts ein Forist:
A: "Welchen Kernel setzt du ein?"
B: "Weiß ich nicht, aber hier läuft systemd x.y.z. Das macht doch heute eh alles"
Wenn ich die Texte in den Mailinglisten und im IRC lese, bin ich froh, dass ich eine erwachsene Distribution mit erwachsenen Entwicklern/Usern nutze.
Haben die alle kein Privatleben?
Die meisten Debianuser sind sehr vernünftig, aber es ist ein sehr "trolliges" Thema, einige Menschen scheint es besonderen Spaß zu machen, bei dem Thema unpassende Kommentare in der Mailingliste abzusetzen.
Erkennbar daran, dass es dann jeweils die ersten und einzigen Wortmeldungen dieser Leute sind.
Wobei auch ein paar erfahrene Mitglieder aktuell etwas emotional reagieren, aber selten in wirklich unpassender weiße.