Das Problem ist eher, dass (wenn der Code tatsächlich aus dem Kernel rausfliegt) alle Benutzer die systemd aus welchem Grund auch immer nicht benutzen dann kein VT mehr haben. Und so wie man die systemd-Macher kennt, wird dieses Terminal natürlich nicht ohne systemd funktionieren (obwohl es dafür eigentlich keinen Grund gibt).
Allerdings erst, nachdem Systemd auch einen eigenen Display-Server und ein eigenes Desktop-Environment mitliefert. So eigenes GUI-Toolkit wäre auch nicht übel. Dann wäre endlich alles fein und ordentlich in einem großen Paket vereint. Nebenher wäre auch ein Bash-Ersatz in Systemd nicht übel. Auch einen Browser und eine Textverarbeitung könnte ich mir dort gut vorstellen.
"Allerdings erst, nachdem Systemd auch einen eigenen Display-Server und ein eigenes Desktop-Environment mitliefert. So eigenes GUI-Toolkit wäre auch nicht übel. Dann wäre endlich alles fein und ordentlich in einem großen Paket vereint. Nebenher wäre auch ein Bash-Ersatz in Systemd nicht übel. Auch einen Browser und eine Textverarbeitung könnte ich mir dort gut vorstellen."
fehlt noch systemd-steamd, steuerbar über steamctl. oder einfach systemd-linux durch linuxctl um endlich dieses kerneldings in den userspace zu kriegen
"Was sind eigentlich genau die Argumente gegen systemd?"
"Das Problem ist eher, dass (wenn der Code tatsächlich aus dem Kernel rausfliegt) alle Benutzer die systemd aus welchem Grund auch immer nicht benutzen dann kein VT mehr haben" ... und vieles andere Zeugs was in systemd ist.
Die Entwickler haben kein Interesse daß es portabel ist, daher läuft es nicht unter z.B. FreeBSD. Ist z.B. für Debian ein Problem, da es Debian auch mit FreeBSD-Kernel gibt. Falls sie sich für systemd entscheiden muß jedes Paket zwei Startscripts haben, eins für systemd und eins für sysv-init oder was auch immer unter FreeBSD verwendet wird.
Die Anzahl derer, die Debian mit diesem Kernel benutzen dürfte sich aber im Sub-Promille-Bereich bewegen. Und nur wegen einer Handvoll Benutzer auf ein nützliches Feature verzichten?
Auch unter Linux nutzen nicht alle Distributionen systemd. Das ist dir aber natürlich bekannt :) Und das ist kein Sub-Promille-Bereich, sondern ein wichtiger Teil der Desktop-Linuxuser.
Upstart ist älter als systemd, und entspricht eher den Vorstellungen eines solchen Systemteils nach Ansicht von Canonical. Und da es ihre Distrie und ihr Aufwand ist... bleiben sie eben dann dabei
Wenn eine Distribution sowohl Linux als auch BSD als Kernel unterstützt wird sie *immer* solche Spezialisierungen implementieren müssen. Da spielt es auch überhaupt keine Rolle, ob es unter Linux nun systemd gibt oder nicht.
Albern ist es nur zu glauben, dass Debian GNU/Linux und Debian GNU/BSD identisch sein sollten. Wenn sie das wären, dann bräuchte man das ja nicht. Natürlich gibt es da Unterschiede und das ist auch gut so. Es sind zwei Betriebssysteme, die unter einem Dach (Debian) verwaltet werden, nicht mehr und nicht weniger. Nur, weil sowohl ein Golf als auch ein Passat das VW Logo tragen müssen nicht beide den gleichen Motor haben. Oder die gleichen Reifen (weil man den Motor evtl. als den Kernel ansehen würde), das gleiche Lenkrad, das gleiche Radio oder was auch immer. Einzelne Komponenten können natürlich gleich oder ähnlich sein (ist ja beim Auto auch so), aber eben nur einzelne Teile.
Debian sollte für den BSD Port ein entsprechendes Init System wählen, welches dazu passt, genauso wie für den Linux Port. In letzterem Fall kann das systemd, upstart oder sysvinit sein, für BSD eben derzeit nur sysvinit. Die Implementation von systemd für Debian ist übrigens mit sehr wenig Aufwand verbunden, da im Gegensatz zu sysvinit fast alles distributionsneutral gehalten ist und die spezifischen Anpassungen nur sehr gering sind. Bei sysvinit ist der Aufwand natürlich etwas größer, aber es gibt ja auch noch andere BSD Distributionen, die das ohnehin schon machen. Im Endeffekt ist doch allen gedient, wenn man sich mit denen zusammen tut und für den BSD Port die Skripte gemeinsam entwickelt, so profitieren alle davon. Noch besser wäre es evtl. man würde sich mal launchd anschauen und anstreben, das als BSD Äquivalent von systemd weiterzuentwickeln, gemeinsam mit den anderen Distributoren natürlich.
In dieser Thematik ist diese Argumentationsweise gegen systemd in diesem Fall aber ohnehin totaler Schwachsinn, denn wir reden hier schließlich von einem Teil des *Linux*-Kernels, der ersetzt werden soll. BSD ist da schlicht und einfach irrelevant, wenn ein Teil vom Linux Kernel in einen Teil eines Programms, welches nur auf Linux-Systemen verwendet werden kann, übertragen wird. Aber die Beißreflexe waren bei den systemd-Gegnern wohl wieder größer als der Wille frei zu denken, oder?
Nur, weil sowohl ein Golf als auch ein Passat das VW Logo tragen müssen nicht beide den gleichen Motor haben. Oder die gleichen Reifen (weil man den Motor evtl. als den Kernel ansehen würde), das gleiche Lenkrad, das gleiche Radio oder was auch immer. Einzelne Komponenten können natürlich gleich oder ähnlich sein (ist ja beim Auto auch so), aber eben nur einzelne Teile.
In Autoflotten macht es aber sinn, wenn alle den gleichen Treibstoff tanken und nicht der eine Diesel und der andere Benzin.
Von blablabla233 am Mo, 2. Dezember 2013 um 15:14 #
Debian/Gnu ist das betriebsystem....Hurd/Linux der Kernel...also doch er ist schoen wenn beide identisch sind. Bei Autos ist es auch so...die aufhaengung ist fuer die Benzin und die Dieselversion meist identisch.....jaja der Tank..aber autvergleiche sind daemlich
Prinzipiell finde ich das ne gute Idee, allerdings ust systemd unter Linux nicht das einzige Init-System und ich fände eine vom Init-System unabhängige Lösung besser. Distributionen wie Debian die es auch mit FreeBSD als Kernel gibt können systemd nicht verwenden (wobei das soweit ich weiß noch diskutiert wird) weil die systemd-Entwickler anscheinend kein Interesse daran haben, es portabel zu gestalten.
ich frage mich, warum die ganzen systemd-"Module" (logind, steamd, ...) nicht generischer entwickelt werden damit sie auch einfach in alternative init Systeme eingebunden werden können.
Warum kann ich journald nicht mit jedem init System benutzen? Da kann doch gar keine so starke Abhängigkeit sein...letztendlich gehts doch nur um logs
Doch ist es. Wenn man auf eine Funktion setzt die auf anderen Plattformen nicht unterstützt wird, dann hat man das Problem mit der Portierbarkeit selbst verursacht. Wenn jemand ein Spiel mit DirectX entwickelt, dann wird man es ihm auch anlasten es selbst verursacht zu haben, es nicht portieren zu können.
Diese Technik zu nutzen ist sicher nicht Voraussetzung für einen Port von systemd. Dennoch wird sich mittelfristig auch die Grundlage dafür unter BSD bilden, wenn es nicht schon ähnliche Konzepte gibt.
Das Problem ist eher, dass die Entwickler von systemd kein Interesse daran haben, einen Port, an dem sie selbst kein Interesse haben zu entwickeln, der auf Features verzichtet, die sie selbst als wichtig ansehen (und genau genommen ist das cgroups-basierte Handling von services sehr wichtig, da erst dadurch sichergestellt wird, dass ein Prozess samt *aller* Childs getrackt werden kann, auch wenn irgendeine Routine oder ein Skript noch so oft forkt).
Finde es schon strange, dass man den systemd Entwicklern ständig vorwirft, dass sie sich nicht um BSD kümmern. Microsoft wirft doch auch keiner vor, dass sie ihren Internet Explorer nicht auch für Linux entwickeln...
Für das Debuggen des Kernels sieht er eine serielle Konsole als hilfreicher und zuverlässiger an
In Zeiten in der fast jeder auf seinem NB programmiert und sogar schon Desktop Mainboards ohne Seriellen Anschluss herauskommen, frage ich mich, wer da eine serielle Konsole noch nutzen soll? Es ist auch sicherlich nicht ergiebig neue Kernelentwickler zu gewinnen, wenn man ihnen erstmal die Hürde auferlegt, das sie sich einen Computer mit seriellem Anschluss zulegen sollen.
Und ein echtes Serielles Terminal aus C64er Zeiten haben sowieso die wenigsten, weswegen das ganze letzten Endes mit einem Zweitrechner als I/O Gerät emuliert werden muss. Dies erfordert dann zumindest beim Zweitrechner schonmal einen USB zu Seriellen Adapter, denn auch für den Zweitrechner dürfte es schwierig werden, dafür einen seriellen Anschluss zu finden.
Weder mein NB noch mein aktueller Rechner haben einen seriellen Anschluss.
Es ist auch sicherlich nicht ergiebig neue Kernelentwickler zu gewinnen, wenn man ihnen erstmal die Hürde auferlegt, das sie sich einen Computer mit seriellem Anschluss zulegen sollen.
Schon einmal etwas von der Netconsole gehört? Die schiebt die Debugging-Daten einfach als UDP-Stream auf einem frei konfigurierbaren Port übers Netzwerk.
[..] weswegen das ganze letzten Endes mit einem Zweitrechner als I/O Gerät emuliert werden muss.
Eine echtes serielles Terminal hatten und haben wohl die wenigsten zu Hause stehen. Der Zweitrechner war schon immer das Mittel der Wahl um die serielle Konsole zu benutzen. Dazu reicht dann sogar ein uralter XT-Laptop auf dem MS-DOS läuft.
Schon einmal etwas von der Netconsole gehört? Die schiebt die Debugging-Daten einfach als UDP-Stream auf einem frei konfigurierbaren Port übers Netzwerk.
Wenn dir der Kernel absemmelt, dann schickt der gar nichts mehr. Genauso anfällig sind daher Seriel zu USB Adapter die auf der Maschine laufen, deren Kernel absemmelt.
Von Karl Käfer am Sa, 30. November 2013 um 14:13 #
Das geht mit fblog auch weiterhin, dafür besuchst du keinen kompletten Terminal Emulator im Kernel (der dir bei einer Kernel Panik auch nichts mehr nützt)
.. ist es nur ratsam alten Ballast loszuwerden
+1
leider werden dadurch wieder die Gerüchte "systemd macht/kann zu viel" angefacht
Das Problem ist eher, dass (wenn der Code tatsächlich aus dem Kernel rausfliegt) alle Benutzer die systemd aus welchem Grund auch immer nicht benutzen dann kein VT mehr haben. Und so wie man die systemd-Macher kennt, wird dieses Terminal natürlich nicht ohne systemd funktionieren (obwohl es dafür eigentlich keinen Grund gibt).
Es gibt ja bereits das KMSCON, welches ohne systemd verwendet werden kann
Gewöhn Dich dran, Systemd wird Kernel 3.x noch komplett ersetzen.
Allerdings erst, nachdem Systemd auch einen eigenen Display-Server und ein eigenes Desktop-Environment mitliefert.
So eigenes GUI-Toolkit wäre auch nicht übel. Dann wäre endlich alles fein und ordentlich in einem großen Paket vereint.
Nebenher wäre auch ein Bash-Ersatz in Systemd nicht übel.
Auch einen Browser und eine Textverarbeitung könnte ich mir dort gut vorstellen.
"Allerdings erst, nachdem Systemd auch einen eigenen Display-Server und ein eigenes Desktop-Environment mitliefert.
So eigenes GUI-Toolkit wäre auch nicht übel. Dann wäre endlich alles fein und ordentlich in einem großen Paket vereint.
Nebenher wäre auch ein Bash-Ersatz in Systemd nicht übel.
Auch einen Browser und eine Textverarbeitung könnte ich mir dort gut vorstellen."
fehlt noch systemd-steamd, steuerbar über steamctl.
oder einfach systemd-linux durch linuxctl um endlich dieses kerneldings in den userspace zu kriegen
David Herrmann ist kein Systemd-Entwickler sondern trägt bisher in aller Stille einiges zum Grafik-Stack bei.
Was sind eigentlich genau die Argumente gegen systemd?
"Was sind eigentlich genau die Argumente gegen systemd?"
"Das Problem ist eher, dass (wenn der Code tatsächlich aus dem Kernel rausfliegt) alle Benutzer die systemd aus welchem Grund auch immer nicht benutzen dann kein VT mehr haben" ... und vieles andere Zeugs was in systemd ist.
Es gibt ja auch KMSCON?
Die Entwickler haben kein Interesse daß es portabel ist, daher läuft es nicht unter z.B. FreeBSD. Ist z.B. für Debian ein Problem, da es Debian auch mit FreeBSD-Kernel gibt. Falls sie sich für systemd entscheiden muß jedes Paket zwei Startscripts haben, eins für systemd und eins für sysv-init oder was auch immer unter FreeBSD verwendet wird.
Auch unter Linux nutzen nicht alle Distributionen systemd. Das ist dir aber natürlich bekannt :)
Und das ist kein Sub-Promille-Bereich, sondern ein wichtiger Teil der Desktop-Linuxuser.
Warum eigentlich?
Upstart ist älter als systemd, und entspricht eher den Vorstellungen eines solchen Systemteils nach Ansicht von Canonical.
Und da es ihre Distrie und ihr Aufwand ist... bleiben sie eben dann dabei
FreeBSD ist ja auch nicht das Problem.
Debian wurde für GNU/Hurd entwickelt, dass muss sich also auch für den Hurd Kernel noch eignen.
Wenn eine Distribution sowohl Linux als auch BSD als Kernel unterstützt wird sie *immer* solche Spezialisierungen implementieren müssen. Da spielt es auch überhaupt keine Rolle, ob es unter Linux nun systemd gibt oder nicht.
Albern ist es nur zu glauben, dass Debian GNU/Linux und Debian GNU/BSD identisch sein sollten. Wenn sie das wären, dann bräuchte man das ja nicht. Natürlich gibt es da Unterschiede und das ist auch gut so. Es sind zwei Betriebssysteme, die unter einem Dach (Debian) verwaltet werden, nicht mehr und nicht weniger.
Nur, weil sowohl ein Golf als auch ein Passat das VW Logo tragen müssen nicht beide den gleichen Motor haben. Oder die gleichen Reifen (weil man den Motor evtl. als den Kernel ansehen würde), das gleiche Lenkrad, das gleiche Radio oder was auch immer.
Einzelne Komponenten können natürlich gleich oder ähnlich sein (ist ja beim Auto auch so), aber eben nur einzelne Teile.
Debian sollte für den BSD Port ein entsprechendes Init System wählen, welches dazu passt, genauso wie für den Linux Port. In letzterem Fall kann das systemd, upstart oder sysvinit sein, für BSD eben derzeit nur sysvinit. Die Implementation von systemd für Debian ist übrigens mit sehr wenig Aufwand verbunden, da im Gegensatz zu sysvinit fast alles distributionsneutral gehalten ist und die spezifischen Anpassungen nur sehr gering sind. Bei sysvinit ist der Aufwand natürlich etwas größer, aber es gibt ja auch noch andere BSD Distributionen, die das ohnehin schon machen. Im Endeffekt ist doch allen gedient, wenn man sich mit denen zusammen tut und für den BSD Port die Skripte gemeinsam entwickelt, so profitieren alle davon. Noch besser wäre es evtl. man würde sich mal launchd anschauen und anstreben, das als BSD Äquivalent von systemd weiterzuentwickeln, gemeinsam mit den anderen Distributoren natürlich.
In dieser Thematik ist diese Argumentationsweise gegen systemd in diesem Fall aber ohnehin totaler Schwachsinn, denn wir reden hier schließlich von einem Teil des *Linux*-Kernels, der ersetzt werden soll. BSD ist da schlicht und einfach irrelevant, wenn ein Teil vom Linux Kernel in einen Teil eines Programms, welches nur auf Linux-Systemen verwendet werden kann, übertragen wird.
Aber die Beißreflexe waren bei den systemd-Gegnern wohl wieder größer als der Wille frei zu denken, oder?
In Autoflotten macht es aber sinn, wenn alle den gleichen Treibstoff tanken und nicht der eine Diesel und der andere Benzin.
An solchen Kommentaren sieht man wieder einmal, dass Autovergleiche praktisch nie Sinn ergeben.
Debian/Gnu ist das betriebsystem....Hurd/Linux der Kernel...also doch er ist schoen wenn beide identisch sind. Bei Autos ist es auch so...die aufhaengung ist fuer die Benzin und die Dieselversion meist identisch.....jaja der Tank..aber autvergleiche sind daemlich
CONFIG_VT wird nicht aus dem Kernel entfernt. Durch die besagten Änderungen wird es lediglich optional.
... der alte Ballast wird nicht losgeworden, sondern nur in systemd eingepflegt
Prinzipiell finde ich das ne gute Idee, allerdings ust systemd unter Linux nicht das einzige Init-System und ich fände eine vom Init-System unabhängige Lösung besser. Distributionen wie Debian die es auch mit FreeBSD als Kernel gibt können systemd nicht verwenden (wobei das soweit ich weiß noch diskutiert wird) weil die systemd-Entwickler anscheinend kein Interesse daran haben, es portabel zu gestalten.
ich frage mich, warum die ganzen systemd-"Module" (logind, steamd, ...) nicht generischer entwickelt werden damit sie auch einfach in alternative init Systeme eingebunden werden können.
Warum kann ich journald nicht mit jedem init System benutzen? Da kann doch gar keine so starke Abhängigkeit sein...letztendlich gehts doch nur um logs
"weil die systemd-Entwickler anscheinend kein Interesse daran haben, es portabel zu gestalten."
Gibt es denn eine Möglichkeit so etwas wie cgroups unter BSD zu nutzen? Wenn nicht, kann man systemd schlicht nicht vernünftig portieren.
Gibt es denn eine Möglichkeit so etwas wie cgroups unter BSD zu nutzen? Wenn nicht, kann man systemd schlicht nicht vernünftig portieren.
Das ist wohl genau das Problem.
Aber kein Problem, dass durch systemd verursacht wird.
Doch ist es. Wenn man auf eine Funktion setzt die auf anderen Plattformen nicht unterstützt wird, dann hat man das Problem mit der Portierbarkeit selbst verursacht. Wenn jemand ein Spiel mit DirectX entwickelt, dann wird man es ihm auch anlasten es selbst verursacht zu haben, es nicht portieren zu können.
"Wenn jemand ein Spiel mit DirectX entwickelt, dann wird man es ihm auch anlasten es selbst verursacht zu haben, es nicht portieren zu können."
Wenn jemand auf DirectX setzt statt auf OpenGL ist er selbst schuld, wenn es nicht portierbar ist. Weil es eine portable Alternative gibt.
Für cgroups gibt es aber keine portable Alternative. (Es gibt nichtmal eine funktionale Alternative unter BSD.)
Jails unter FreeBSD kommt dem recht nahe.
Nein, Jails sind etwas vollkommen anderes als cgroups.
Diese Technik zu nutzen ist sicher nicht Voraussetzung für einen Port von systemd. Dennoch wird sich mittelfristig auch die Grundlage dafür unter BSD bilden, wenn es nicht schon ähnliche Konzepte gibt.
Das Problem ist eher, dass die Entwickler von systemd kein Interesse daran haben, einen Port, an dem sie selbst kein Interesse haben zu entwickeln, der auf Features verzichtet, die sie selbst als wichtig ansehen (und genau genommen ist das cgroups-basierte Handling von services sehr wichtig, da erst dadurch sichergestellt wird, dass ein Prozess samt *aller* Childs getrackt werden kann, auch wenn irgendeine Routine oder ein Skript noch so oft forkt).
Finde es schon strange, dass man den systemd Entwicklern ständig vorwirft, dass sie sich nicht um BSD kümmern. Microsoft wirft doch auch keiner vor, dass sie ihren Internet Explorer nicht auch für Linux entwickeln...
In Zeiten in der fast jeder auf seinem NB programmiert und sogar schon Desktop Mainboards ohne Seriellen Anschluss herauskommen, frage ich mich, wer da eine serielle Konsole noch nutzen soll?
Es ist auch sicherlich nicht ergiebig neue Kernelentwickler zu gewinnen, wenn man ihnen erstmal die Hürde auferlegt, das sie sich einen Computer mit seriellem Anschluss zulegen sollen.
Und ein echtes Serielles Terminal aus C64er Zeiten haben sowieso die wenigsten, weswegen das ganze letzten Endes mit einem Zweitrechner als I/O Gerät emuliert werden muss.
Dies erfordert dann zumindest beim Zweitrechner schonmal einen USB zu Seriellen Adapter, denn auch für den Zweitrechner dürfte es schwierig werden, dafür einen seriellen Anschluss zu finden.
Weder mein NB noch mein aktueller Rechner haben einen seriellen Anschluss.
Wenn dir der Kernel absemmelt, dann schickt der gar nichts mehr.
Genauso anfällig sind daher Seriel zu USB Adapter die auf der Maschine laufen, deren Kernel absemmelt.
Das geht mit fblog auch weiterhin, dafür besuchst du keinen kompletten Terminal Emulator im Kernel (der dir bei einer Kernel Panik auch nichts mehr nützt)