Ich will kein systemd ... Sollte das der default werden, muss ich mir nach >15 Jahren mit Debian dann bald 'ne neue Distri suchen... :x Sch... GNOME...
Systemd ist technisch gesehen, dass eindeutig bessere System. Würde man sich bei Debian trotzdem für Upstart entscheiden wäre dass eine durch die Canonical Vertreter bei Debian herbeigeführte politische Entscheidung.
Ich könnte mir sogar vorstellen, dass Debian erstmal für Linux basierende Distributionen auf systemd wechselt und die Hurd und BSD Plattform erst einmal auf sysvinit lassen (wie siehts da eigentl mit upstart support aus ?)
Systemd ist technisch gesehen, dass eindeutig bessere System.
Darüber besteht keine Einigkeit.
Es ist doch vielmehr so: Wenn systemd das default init system wird, dann eher weil man es von GNOME aufgezwungen bekommt als das die Mehrheit es wirklich möchte.
Eine (unwahrscheinliche) Möglichkeit wäre es ja auch, GNOME rauszuschmeißen. Bei Debian geht es ganz viel um Freiheit; die Freiheit der User, selbst entscheiden zu können, welche Software man wie einsetzen möchte. GNOME zwingt dem User seinen Willen auf, und das stößt bei den freiheitsliebenden Usern nicht auf Gegenliebe. Ganz zu schweigen davon das auch die DM davon betroffen wären, weil sie ihre init scripte anpassen müssten...
"Systemd bietet allerdings auch die Möglichkeit, mit den bisherigen Init-Skripten arbeiten zu können, was eine Lösung für diese Architekturen bieten könnte."
Ich würde gern diesen Gedankengang verstehen. Soweit klar benutzt doch systemd eine Menge Linux Kernelfeatures bspw. cgroups, die es bekanntlich nicht unter Hurd und BSD etc. gibt. Wie soll das eine Lösung darstellen?
Mein Arch Linux mit systemd bootet um Welten schneller als ein Debian mit sysvinit. Natürlich habe ich darauf geachtet, dass bei Debian der ganze Quatsch wie exim und co nicht gestartet wird, um das vergleichen zu können.
Klar ist systemd etwas komplexer für den User, aber dafür ist meiner Meinung nach mehr gewonnen durch diese Umstellung.
Aber es ist wohl der Debian-way ewig gestrig zu sein, und ein "das machen wir schon 15 Jahre so" ist natürlich ein gutes Argument, um technische Dinge zu diskutieren.
Am besten ist natürlich dann jetzt die Variante, kein Systemd einzusetzen, damit man noch weiter zur Fragmentierung beiträgt - am besten a la Canonical mit einer Eigenentwicklung
Mal abgeseheh von debian-spezifischen Nachteilen (kFreeBSB/Hurd). Was sind denn technische Gründe, die gegen den Einsatz von systemd sprechen?
Mir gefällt z.B. die Abhängigkeit von dbus nicht. Ich weiß nicht, warum ein Init-System dbus überhaupt braucht. Außerdem will ich einen *desktop*-bus nicht unbedingt auf einem Server laufen lassen?
Außerdem habe ich was gegen den Autor. Aus seiner Feder kommen z.B. auch avahi und pulseaudio. *brrrr*
Gnome 3 aus Debian entfernen und durch Mate oder Cinnamon ersetzen, dann kann man auch die Frage nach dem Init System auf unbestimmte Zeit verschieben und wie gehabt fortfahren.
Der Hintergrund ist, dass in Debian Sid seit kurzem das Paket gnome-settings-daemon von Systemd abhängt.
"Upstart hat das Problem, eine Insellösung von Canonical zu sein"
Das Paket ist doch in Debian und kann ohne weiteres benutzt werden. Einige Distri's sind schon gewechselt, wenn auch nur kurzzeitig, bis Redhat/Fedora mit IHRER Insellösung kamen und das über komische Kanäle versuchen allen aufs Auge zu drücken.
Immer diese blöde Ausdrucksweise, die suggeriert das Ubuntu wegen NIH upstart reingedrückt hat obwohl systemd existiert. Die Reihenfolge ist aber durchaus andersrum (upstart ist jetzt 7-8 Jahre alt - systemd Politik)
Von Arne Babenhauserheide am Do, 21. November 2013 um 09:13 #
Nach den aktuellen Diskussionen auf der Mailing-Liste erschließt sich mir die Aussage nicht, dass OpenRC keine Chance haben soll. Technisch gesehen geht es den saubersten Weg:
OpenRC löst die Probleme von sysinit, ohne die Entwickler zu zwingen, neue Methoden zu lernen: Erarbeitete Fachkenntnis und bereits im Projekt verbreitetes Wissen bleiben nützlich. Verfahren: Minimal invasive Änderungen, die das Ziel erreichen.
Einige der erreichten Ziele:
- Einfachere Init-Skripte (kaum boilerplate). - Statusinformationen zu Diensten (Dienste nicht zweimal starten). - Flexibel auf kernelevents reagieren - via udev (es gibt bereits ein Programm, das das kann, warum also die Features neu implementieren? — stattdessen lieber mit dem Programm interagieren). - Flexible und einfache Abhängigkeiten von Diensten, die automatisch aufgelöst werden und auch paralell laufen können (need X, use Y, provide Z ; after Q, before N).
Ich will kein systemd ... Sollte das der default werden, muss ich mir nach >15 Jahren mit Debian dann bald 'ne neue Distri suchen... :x
Sch... GNOME...
Systemd ist technisch gesehen, dass eindeutig bessere System.
Würde man sich bei Debian trotzdem für Upstart entscheiden wäre dass eine durch die Canonical Vertreter bei Debian herbeigeführte politische Entscheidung.
Ich könnte mir sogar vorstellen, dass Debian erstmal für Linux basierende Distributionen auf systemd wechselt und die Hurd und BSD Plattform erst einmal auf sysvinit lassen (wie siehts da eigentl mit upstart support aus ?)
Es ist doch vielmehr so: Wenn systemd das default init system wird, dann eher weil man es von GNOME aufgezwungen bekommt als das die Mehrheit es wirklich möchte.
Eine (unwahrscheinliche) Möglichkeit wäre es ja auch, GNOME rauszuschmeißen.
Bei Debian geht es ganz viel um Freiheit; die Freiheit der User, selbst entscheiden zu können, welche Software man wie einsetzen möchte. GNOME zwingt dem User seinen Willen auf, und das stößt bei den freiheitsliebenden Usern nicht auf Gegenliebe. Ganz zu schweigen davon das auch die DM davon betroffen wären, weil sie ihre init scripte anpassen müssten...
"Systemd bietet allerdings auch die Möglichkeit, mit den bisherigen Init-Skripten arbeiten zu können, was eine Lösung für diese Architekturen bieten könnte."
Ich würde gern diesen Gedankengang verstehen. Soweit klar benutzt doch systemd eine Menge Linux Kernelfeatures bspw. cgroups, die es bekanntlich nicht unter Hurd und BSD etc. gibt. Wie soll das eine Lösung darstellen?
Mein Arch Linux mit systemd bootet um Welten schneller als ein Debian mit sysvinit.
Natürlich habe ich darauf geachtet, dass bei Debian der ganze Quatsch wie exim und co nicht gestartet wird, um das vergleichen zu können.
Klar ist systemd etwas komplexer für den User, aber dafür ist meiner Meinung nach mehr gewonnen durch diese Umstellung.
Aber es ist wohl der Debian-way ewig gestrig zu sein, und ein "das machen wir schon 15 Jahre so" ist natürlich ein gutes Argument, um technische Dinge zu diskutieren.
Am besten ist natürlich dann jetzt die Variante, kein Systemd einzusetzen, damit man noch weiter zur Fragmentierung beiträgt - am besten a la Canonical mit einer Eigenentwicklung
Mal abgeseheh von debian-spezifischen Nachteilen (kFreeBSB/Hurd). Was sind denn technische Gründe, die gegen den Einsatz von systemd sprechen?
Mir gefällt z.B. die Abhängigkeit von dbus nicht. Ich weiß nicht, warum ein Init-System dbus überhaupt braucht. Außerdem will ich einen *desktop*-bus nicht unbedingt auf einem Server laufen lassen?
Außerdem habe ich was gegen den Autor. Aus seiner Feder kommen z.B. auch avahi und pulseaudio. *brrrr*
Gnome 3 aus Debian entfernen und durch Mate oder Cinnamon ersetzen, dann kann man auch die Frage nach dem Init System auf unbestimmte Zeit verschieben und wie gehabt fortfahren.
Versucht einmal ein systemd System zu rebooten oder herunterzufahren, wenn man versehentlich /run/systemd gelöscht hat. Da fängt der Spaß erst an.
"Upstart hat das Problem, eine Insellösung von Canonical zu sein"
Das Paket ist doch in Debian und kann ohne weiteres benutzt werden. Einige Distri's sind schon gewechselt, wenn auch nur kurzzeitig, bis Redhat/Fedora mit IHRER Insellösung kamen und das über komische Kanäle versuchen allen aufs Auge zu drücken.
Immer diese blöde Ausdrucksweise, die suggeriert das Ubuntu wegen NIH upstart reingedrückt hat obwohl systemd existiert. Die Reihenfolge ist aber durchaus andersrum (upstart ist jetzt 7-8 Jahre alt - systemd Politik)
Nach den aktuellen Diskussionen auf der Mailing-Liste erschließt sich mir die Aussage nicht, dass OpenRC keine Chance haben soll. Technisch gesehen geht es den saubersten Weg:
OpenRC löst die Probleme von sysinit, ohne die Entwickler zu zwingen, neue Methoden zu lernen: Erarbeitete Fachkenntnis und bereits im Projekt verbreitetes Wissen bleiben nützlich. Verfahren: Minimal invasive Änderungen, die das Ziel erreichen.
Einige der erreichten Ziele:
- Einfachere Init-Skripte (kaum boilerplate).
- Statusinformationen zu Diensten (Dienste nicht zweimal starten).
- Flexibel auf kernelevents reagieren - via udev (es gibt bereits ein Programm, das das kann, warum also die Features neu implementieren? — stattdessen lieber mit dem Programm interagieren).
- Flexible und einfache Abhängigkeiten von Diensten, die automatisch aufgelöst werden und auch paralell laufen können (need X, use Y, provide Z ; after Q, before N).