systemd, der nächste Horror für BSD?
- Ersteller Elwood
- Erstellt am
- Status
D
das.chaos
Guest
Weil es geradeeben so schoen passt...
##
# http://www.heise.de/open/meldung/Gnome-Entwickler-planen-Linux-Apps-1797503.html
#
.
Ich ahne boeses bzgl. systemd (auch wenn dieser Artikel auf dem ersten Blick bzgl. der hier diskutierten Thematik off topic erscheint) im Hinblick auf der sich hier eroeffnenden schoenen neuen Welt des unixoiden Desktops - mir grausts. Was fuer ein Kraut rauchen denn die Gnome Entwickler?
Naja, habe mich mal gezwungenermaszen mit systemd auseinandersetzen muessen. Mir faellt dazu nur das ein: Gesehen, gelacht und geloescht!
Just my 2 ct.
##
# http://www.heise.de/open/meldung/Gnome-Entwickler-planen-Linux-Apps-1797503.html
#
.Ich ahne boeses bzgl. systemd (auch wenn dieser Artikel auf dem ersten Blick bzgl. der hier diskutierten Thematik off topic erscheint) im Hinblick auf der sich hier eroeffnenden schoenen neuen Welt des unixoiden Desktops - mir grausts. Was fuer ein Kraut rauchen denn die Gnome Entwickler?
Naja, habe mich mal gezwungenermaszen mit systemd auseinandersetzen muessen. Mir faellt dazu nur das ein: Gesehen, gelacht und geloescht!
Just my 2 ct.
kmh
Well-Known Member
Ihr könntet ja wenigstens mal versuchen das Thema etwas sachlicher anzugehen und hier nicht nur zu flamen ....
Warum reduziert ihr Systemd nur auf kürze boot Zeiten? Abgesehen davon, fand ich es schon beeindruckend, ein Fedora 19 System startete mit Systemd unter 1 Sekunde, wurde life vorgeführt mit Benchmark. Wenn man die BIOS-Initialisierung nicht mit rechnet.
Es wurde in seinem Vortrag auf der Fosdem auch ein Ausblick auf neue Funktionen gegeben und manche davon sind wirklich interessant. Das Konzept an sich ist auch durchaus interessant.
Ich finde auch das Systemd einige Nachteile hat. Nur ist die Darstellung hier sehr einseitig ...
Warum reduziert ihr Systemd nur auf kürze boot Zeiten? Abgesehen davon, fand ich es schon beeindruckend, ein Fedora 19 System startete mit Systemd unter 1 Sekunde, wurde life vorgeführt mit Benchmark. Wenn man die BIOS-Initialisierung nicht mit rechnet.
Es wurde in seinem Vortrag auf der Fosdem auch ein Ausblick auf neue Funktionen gegeben und manche davon sind wirklich interessant. Das Konzept an sich ist auch durchaus interessant.
Ich finde auch das Systemd einige Nachteile hat. Nur ist die Darstellung hier sehr einseitig ...
Zuletzt bearbeitet:
Ist doch klar. Wir alle sehen da eine Welle auf uns zukommen. Dass die Welle für irgend jemand Anderes gut sein könnte interessiert hier Niemanden.
Und weil die Medaille in den meisten Fällen mehr als nur eine Seite hat. Natürlich gibt es durchaus positives an systemd, aber es gibt auch viel was man hart kritisieren kann. Mit fallen da spontan mindestens 2 Dinge ein, die hier auch schon auf die eine oder andere Weise diskutiert wurden:
1. Herr Poettering hat ein etwas seltsames Verständnis von Softwarequalität, in der Vergangenheit hat er immer eierlegende Wollmilchsäue mit etlichen Abhängigkeiten gebaut, die maximal leidlich funktionierten und einen Berg teildefekter Abhängigkeiten mitbrachten. Nicht umsonst gibt es den auch in der Linuxwelt beliebten Begriff "Lennartware" für seine Software. Das mag bei Pulseaudio noch zähneknirschend akzeptabel gewesen sein - ich habe low-latency Soundsoftware für Linux geschrieben und mir an Pulseaudio gefühlt 12 Finger angebrochen - aber beim Systemstart ist sowas einfach inakzeptabel.
2. Das wäre alles kein Problem, wenn es auf Linux oder besser noch einige Distros beschränkt bliebe. Tut es aber nicht, denn viele dieser "Kernlinuxer" führen sich inzwischen wie Bill Gates 1997 auf drücken ihre Vorstellungen und "Standards" ohne Rücksicht auf Verluste durch. Dadurch wird das Ökosystem empfindlich gestört und jeder wird gezwungen sich mit deren Ideen zu arrangieren. Wie lange werden sich Debian und Ubuntu noch gegen systemd wehren können? Was werden wir BSDler wieder für eklige Hacks und Gefrickel einbauen müssen? Wenn wir die Welle schon nicht verhindern können, können wir wenigstens über sie lästern.
1. Herr Poettering hat ein etwas seltsames Verständnis von Softwarequalität, in der Vergangenheit hat er immer eierlegende Wollmilchsäue mit etlichen Abhängigkeiten gebaut, die maximal leidlich funktionierten und einen Berg teildefekter Abhängigkeiten mitbrachten. Nicht umsonst gibt es den auch in der Linuxwelt beliebten Begriff "Lennartware" für seine Software. Das mag bei Pulseaudio noch zähneknirschend akzeptabel gewesen sein - ich habe low-latency Soundsoftware für Linux geschrieben und mir an Pulseaudio gefühlt 12 Finger angebrochen - aber beim Systemstart ist sowas einfach inakzeptabel.
2. Das wäre alles kein Problem, wenn es auf Linux oder besser noch einige Distros beschränkt bliebe. Tut es aber nicht, denn viele dieser "Kernlinuxer" führen sich inzwischen wie Bill Gates 1997 auf drücken ihre Vorstellungen und "Standards" ohne Rücksicht auf Verluste durch. Dadurch wird das Ökosystem empfindlich gestört und jeder wird gezwungen sich mit deren Ideen zu arrangieren. Wie lange werden sich Debian und Ubuntu noch gegen systemd wehren können? Was werden wir BSDler wieder für eklige Hacks und Gefrickel einbauen müssen? Wenn wir die Welle schon nicht verhindern können, können wir wenigstens über sie lästern.
Elwood
Naiver Mutmaßlicher
3. sind solche Sachen wie udev in der Regel mehr oder weniger schlecht dokumentiert http://www.freedesktop.org/software/systemd/libudev/
@das.chaos:
Mh, hab ich das nicht schon mal irgendwo gesehen, warte... mhhh... gleich hab ich's.... jupp bei PCBSD?! Nennt sich PBI...
Klar, wenn das Distributionsübergreifend ist, dann kann sich niemand mehr dem SD entziehen.
@das.chaos:
Mh, hab ich das nicht schon mal irgendwo gesehen, warte... mhhh... gleich hab ich's.... jupp bei PCBSD?! Nennt sich PBI...
Klar, wenn das Distributionsübergreifend ist, dann kann sich niemand mehr dem SD entziehen.
Zuletzt bearbeitet:
-Nuke-
Well-Known Member
Weil das bei den Entwicklern der Hauptgrund für so gut wie alle Design-Entscheidungen ist.
Ja, mit so gut wie keinen weiteren Diensten die gestartet werden, Pre-Caches/Analysen/etc.pp, einer/zwei SSDs und einer HighEnd-CPU.
Wenn man mal etwas mehr Dienste braucht, dann startet systemd irgendwie gar nicht mehr sooooo schnell, vorausgesetzt man hat noch eine Festplatte, weil die Festplatte mit den massiv parallelen Starts einfach überfordert ist. Mit SSD kann ich es nicht beurteilen, da ich keine habe.
Prinzipiell ist das parallele Starten von Diensten ja gar nicht so schlimm. Aber so wie systemd das macht, ist das einfach nur hirntot. Auf Teufel komm raus alles starten und das blocken was jetzt eigentlich noch nicht laufen sollte, etc. pp. Und alle Nase lang fährt das System nicht hoch, weil das Blocken wegen einer Race-Condition nicht geklappt hat. Und ich spreche hier aus eigenen Erfahrungen, habe 2 ArchLinux-Systeme als Desktop laufen.
Ein weiteres Problem ist halt auch, dass systemd mit seiner "ich mache alles" Mentalität nur gut funktioniert, wenn alles darüber auch "systemd-aware" ist. Gnome schleppt z.B. noch die pm-utils mit, welche längst von systemd abgelöst wurden. Wo lege ich jetzt meine Powermanagement-Konfig an? Das führt halt dazu, dass die großen OpenSource-Desktops aus mangelnder Man-Power oder Interesse irgendwann Linux-Only werden. Und das hat der Code-Qualität noch nie in irgend einer Form geholfen.
Aufhalten kann man das eh nicht mehr... darum bleibt nur meckern. Mit Wayland ist dann alles vorbei, dann ist alles vom Init-Prozess bis zum Fenstermanager alles Linux-Only.
bofh_hannibal
THE BOFH
Auch wenn ich das project systemd bisher nur ignoriert habe, so muss ich auch mal meinen Senf dazu abgeben.
Aus meiner Berufserfahrung mit Unix und Linux sehe ich erstmal keinen Gewinn durch systemd.
Es bringt eigentlich keine neuen Features was den Bootprozess und einen System Daemon ausmacht.
Der "liebe" Lennart hat anscheinend noch nie mit Systemen wie Solaris gearbeitet.
Dann wüsste er nämlich, das boot zeiten keine Rolle im Serverbereich spielen.
Sondern andere dinge wie z.B.: Self Healing. So eine Funktion sehe ich leider nicht anhand der Feature liste von systemd. Denn gewisse Daemons sollten einfach restarted werden vom System falls diese mal Abstürzen (warum auch immer). Bei FreeBSD gibt es ja mittlerweile FSC was seinen dienst tut \o/.
Auch ein einfaches debuggen per "Console/Shell" sollte jederzeit machbar sein.
Anscheinend ist das ja auch nicht der Fall.
Eine Parallelisierung der Start routinen ist vielleicht ganz nett, aber bringt meisstens mehr probleme als gelöst werden. Denn die Abhängigkeiten aller vorhandenen start routinen auf dem Markt, wird auch systemd nicht beherrschen können.
Snapshots vom Bootprozess zu machen, um ein konstantes Bootverhalten zu erreichen ist absoluter Müll. Niemand stellt hundertfach den init Ablaufprozess um.
Wobei ich schon sagen muss, das die heutigen Linux Distos eine Menge start Skripte in den Runlevel laufen haben. Warscheinlich war das der Grund für das Snapshot feature :-)
Was mich letztendlich Stört an dem systemd sind die Falsch aussagen des Projektes.
Es heißt: "systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization"
Nur leider ist das ja nicht der Fall.
Auch die vielen Präsentationen von Lennart und der Druck auf andere Projekte wie Gnome und co. lassen mich an dem Project sehr zweifeln und hoffen das es eingestampf wird.
Prost.
Aus meiner Berufserfahrung mit Unix und Linux sehe ich erstmal keinen Gewinn durch systemd.
Es bringt eigentlich keine neuen Features was den Bootprozess und einen System Daemon ausmacht.
Der "liebe" Lennart hat anscheinend noch nie mit Systemen wie Solaris gearbeitet.
Dann wüsste er nämlich, das boot zeiten keine Rolle im Serverbereich spielen.
Sondern andere dinge wie z.B.: Self Healing. So eine Funktion sehe ich leider nicht anhand der Feature liste von systemd. Denn gewisse Daemons sollten einfach restarted werden vom System falls diese mal Abstürzen (warum auch immer). Bei FreeBSD gibt es ja mittlerweile FSC was seinen dienst tut \o/.
Auch ein einfaches debuggen per "Console/Shell" sollte jederzeit machbar sein.
Anscheinend ist das ja auch nicht der Fall.
Eine Parallelisierung der Start routinen ist vielleicht ganz nett, aber bringt meisstens mehr probleme als gelöst werden. Denn die Abhängigkeiten aller vorhandenen start routinen auf dem Markt, wird auch systemd nicht beherrschen können.
Snapshots vom Bootprozess zu machen, um ein konstantes Bootverhalten zu erreichen ist absoluter Müll. Niemand stellt hundertfach den init Ablaufprozess um.
Wobei ich schon sagen muss, das die heutigen Linux Distos eine Menge start Skripte in den Runlevel laufen haben. Warscheinlich war das der Grund für das Snapshot feature :-)
Was mich letztendlich Stört an dem systemd sind die Falsch aussagen des Projektes.
Es heißt: "systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization"
Nur leider ist das ja nicht der Fall.
Auch die vielen Präsentationen von Lennart und der Druck auf andere Projekte wie Gnome und co. lassen mich an dem Project sehr zweifeln und hoffen das es eingestampf wird.
Prost.
kmh
Well-Known Member
Du warst am Wochenende offensichtlich nicht in Brüssel
Es handelte sich bei dem Gerät um ein Thinkpad 220X oder 230X. Dass konnte ich auf die Entfernung nicht genau erkennen. Das ist wohl keine High -End-Hardware. Außerdem wurden auch keine nennenswerte Dienste beim Start entfernt oder weggelassen. Bei der Demonstration wurde so ziemlich alles gestartet was man für den Desktop-Alltag braucht. Es wird sicher bald ein Video online gestellt von der Präsentation, dann werde ich es hier mal verlinken 
Man könnte Eindruck gewinnen, hier wäre ein Haufen konservativer-old-school-muffel versammelt, die Angst vor Veränderung haben.
Edit: Soll natürlich X220 bzw. X230 heißen.
Zuletzt bearbeitet:
-Nuke-
Well-Known Member
Was nicht wirklich viel ist.
Und außerdem finde ich gerade kein ThinkPad 220x. Nur X220/230 und wenn das kein HighEnd ist...
Man könnte Eindruck gewinnen, hier wäre ein Haufen konservativer-old-school-muffel versammelt, die Angst vor Veränderung haben.
Jo, darum habe ich auch 2 Geräte mit systemd im aktiven Einsatz
Und Erfahrung mit den Schattenseiten von systemd, die totgeschwiegen werden.
D
das.chaos
Guest
@Elwood: You've got the blues...
Eben, der haken hierbei ist es, dasz der Gnome NIH Krempel auf ein klassischen Vendor Lockin hinauslaufen wird (wie hier desoefteren schon angeklungen ist) und nebenbei das Unixkonzept ruiniert (D.M. Ritchie rotiert im Grabe, yeah...).
Oder warum meinen die im Artikel zitierten Entwickler Sandboxing Techniken quasi neu zu implementieren (Erfinden?), statt auf bestehende Techniken bspw. libcapsicum aufzubauen? Nein, die groeszenwahnsinnig gewordenen Damen und Herren ruinieren die Freie Software Bewegung durch oktroyieren einer (schlecht designten) Monokultur - fuerchterlich.
Mir ensteht lansam der Verdacht, dasz diese Gnome- und Systemd-Freaks bezahlte U-Boote sind, um die Freie Software Bewegung durch FLOS zu ruinieren oder meinen das was die da Implementieren wirklich Ernst???
Systemd, Gnome... was kommt als naechstes, ein Softwareoekosystem mit Virenscanner???
Sei's drum, ich verfolge den Thread hier schon seit langen mit Interesse, weil die hier diskutierte Thematik mich auf eine (sehr) bedrohliche Entwicklung innerhalb der Freien Software Bewegung aufmerksam macht. Bei systemd geht es meineserachtens mehr um nur irgendwelcher (naiv erscheinender) Vereinheitlichung, hier geht es leider IMHO darum, dasz knallharte Wirtschaftsinteressen die Freie Softwarebewegung durch quasi Diktatur zersetzen soll.
Ich mache mir da auch keine groszen Illusionen, da es letztendlich (leider) sich immer alles um den groszen Nagus drehen wird, aber den sich durch systemd et.al. entwickelnden Trend (wohl eher Diktatur) musz definitiv entgegengewirkt werden.
Dat wollte ick mal jesacht haben wollen.
Eben, der haken hierbei ist es, dasz der Gnome NIH Krempel auf ein klassischen Vendor Lockin hinauslaufen wird (wie hier desoefteren schon angeklungen ist) und nebenbei das Unixkonzept ruiniert (D.M. Ritchie rotiert im Grabe, yeah...).
Oder warum meinen die im Artikel zitierten Entwickler Sandboxing Techniken quasi neu zu implementieren (Erfinden?), statt auf bestehende Techniken bspw. libcapsicum aufzubauen? Nein, die groeszenwahnsinnig gewordenen Damen und Herren ruinieren die Freie Software Bewegung durch oktroyieren einer (schlecht designten) Monokultur - fuerchterlich.
Mir ensteht lansam der Verdacht, dasz diese Gnome- und Systemd-Freaks bezahlte U-Boote sind, um die Freie Software Bewegung durch FLOS zu ruinieren oder meinen das was die da Implementieren wirklich Ernst???
Systemd, Gnome... was kommt als naechstes, ein Softwareoekosystem mit Virenscanner???
Sei's drum, ich verfolge den Thread hier schon seit langen mit Interesse, weil die hier diskutierte Thematik mich auf eine (sehr) bedrohliche Entwicklung innerhalb der Freien Software Bewegung aufmerksam macht. Bei systemd geht es meineserachtens mehr um nur irgendwelcher (naiv erscheinender) Vereinheitlichung, hier geht es leider IMHO darum, dasz knallharte Wirtschaftsinteressen die Freie Softwarebewegung durch quasi Diktatur zersetzen soll.
Ich mache mir da auch keine groszen Illusionen, da es letztendlich (leider) sich immer alles um den groszen Nagus drehen wird, aber den sich durch systemd et.al. entwickelnden Trend (wohl eher Diktatur) musz definitiv entgegengewirkt werden.
Dat wollte ick mal jesacht haben wollen.
Zuletzt bearbeitet von einem Moderator:
Elwood
Naiver Mutmaßlicher
...
Man könnte Eindruck gewinnen, hier wäre ein Haufen konservativer-old-school-muffel versammelt, die Angst vor Veränderung haben.
Der Eindruck kann aber auch täuschen und dieses Totschlagargument wird auch langsam langweilig.
Für Viele (hier) ist der Leidensdruck offenbar nicht so groß etwas zu ändern, das schlichtweg funktioniert und ohne Not einer vermeintlichen Verbesserung unterworfen werden müsste. Das heisst ja noch lange nicht, daß man sich grundsätzlich Neuerungen versperren würde.
Ansonsten sind hier in diesem Thread m.E. genug Argumente gebracht worden, die jetzt nicht nochmal wiederholt werden müssen.
kmh
Well-Known Member
Ich sehe schon ich stochere hier im Wespen-Nest
Es kommt ja wie immer auf den Einsatzzweck an. Ich mag mein SystemV-Init script es ist transparent und für mich einfach zu handeln. Nur auf meinem Desktop-Rechner möchte ich vielleicht doch, einen schnellen Systemstart.
Ich für mich bin jeden falls gespannt wie sich Systemd weiterentwickelt und ob es wirklich zum "Pain in the ass" wird oder ein mächtiges Tool...
Es kommt ja wie immer auf den Einsatzzweck an. Ich mag mein SystemV-Init script es ist transparent und für mich einfach zu handeln. Nur auf meinem Desktop-Rechner möchte ich vielleicht doch, einen schnellen Systemstart.
Ich für mich bin jeden falls gespannt wie sich Systemd weiterentwickelt und ob es wirklich zum "Pain in the ass" wird oder ein mächtiges Tool...
Aufwachen aus dem Suspend 5 Sekunden von Knopfdruck bis Eingabe in dieses Feld.
Der Andere Rechner braucht von Loader Prompt bis zum XDM Login ziemlich genau 35 Sekunden. Das ist zugegebenermaßen nicht rekordverdächtig aber auch alles andere als problematisch.
Nicht zu vergessen hat der Rechner auch keine SSD und ein paar Sekunden gingen für fsck drauf. Bei dem Start waren auch diverse Server-Dienste wie Samba, SQL Datenbanken, Apache mit dabei und nicht eben nur was man für den Desktop braucht. Für den Desktop braucht man nämlich so ziemlich gar keine Dienste. Bis auf powerd und ntp vielleicht.
Der Andere Rechner braucht von Loader Prompt bis zum XDM Login ziemlich genau 35 Sekunden. Das ist zugegebenermaßen nicht rekordverdächtig aber auch alles andere als problematisch.
Nicht zu vergessen hat der Rechner auch keine SSD und ein paar Sekunden gingen für fsck drauf. Bei dem Start waren auch diverse Server-Dienste wie Samba, SQL Datenbanken, Apache mit dabei und nicht eben nur was man für den Desktop braucht. Für den Desktop braucht man nämlich so ziemlich gar keine Dienste. Bis auf powerd und ntp vielleicht.
q000te
Well-Known Member
Ich verstehe die Diskussion um die Zeit für einen Kaltstart nicht. (Alle Zeitangaben sind gefühlt, ich stoppe die nicht)
Und überhaupt betrachte ich hier nur meine Inselnutzungszenarien:
Aber zurück zum Thema: Die Startzeit geht am Eigentlichen vorbei.
Es gibt einige INIT-Systeme, jedes hat Vor- und Nachteile.
Bei systemd kann ich mich der ganzen Kritik anschließen (keine Textlogs, keine `einfachen` Skripte die ich zur Not per `echo >>` bearbeiten kann, usw., usf.).
Bei den Vorteilen habe ich damit (dem anschließen) große Probleme.
Nun habe ich aber nicht die Fähigkeiten bei den komplexen init-Systemen mitzuwirken. Und die Zeit dafür auch nicht.
Aber den openSUSE Desktop migriere ich Stück für Stück zu PCBSD, der Leidensdruck und Frust den systemd in so verdammt kurzer Zeit erzeugt hat ist wahrlich enorm!
Noch vor einem Jahr war die Verteilung von Server- und Desktopbetriebssystem ganz klar: auf die Server kommt FreeBSD und auf die Desktops kommt irgend ein Linux auf dem KDE reibungslos läuft, ergo openSUSE, doch damit ist es jetzt vorbei.
Aber das ist auch nur ein Aufschub, ich meine als generelle Tendenz zu erkennen, dass OpenSource als solche zunehmend auf Linux zentralisiert wird.
systemd ist da nur ein Baustein, ein weiterer Baustein wäre z.B. wayland, aber der wird einem, zumindest noch, nicht so massiv aufgedrückt.
All die nötigen Anpassungen der Desktop Environments(als Beispiel) daran hält diese auf Trab und lässt Zeit für portable Lösungen schwinden.
So gesehen graut es mir vor den zukünftigen Entwicklungen, denn zumindest Lennartware wird mit der Zeit nicht besser
(PulseAudio ist immer noch Müll und wird es wahrscheinlich auch bleiben und ob der
udev Fork erfolg hat und sich durchsetzt wird sich erst noch zeigen)...
Aber Lennart ist sehr aktiv und hat allein dadurch im Linuxumfeld viel Gewicht, weshalb die BSDs eher früher als später etwas wie eine pseudo-systemd-Schicht bauen müssen...
EDIT(2013-07-07_08:23):
Noch ein kurzer Nachtrag zu Laptops bzw. Mobilgeräten.
Einen tragbaren Rechner zerre ich mit mir mit, wenn ich unterwegs bin:
Und überhaupt betrachte ich hier nur meine Inselnutzungszenarien:
- Meine Server laufen i.d.R. mehrere Wochen oder länger am Stück durch (bis halt ein neuer Kernel gestartet werden muss oder ein Hardwaredefekt das nötig macht). ==>> Startzeit ist volkommen irrelevant!
- Mein Desktop ist etweder aus oder ich sitze davor (Festplattenkrypto und Suspend beißt sich...)
- Wenn der Desktop-1 (PCBSD) hochfährt, dann dauert das ca. 1 Minute -> da brühe ich mir meinen Kaffee nebenbei auf.. ==>> Kaffee dauert länger, Startzeit ebenso irrelevant
- Wenn der Desktop-2 (openSUSE) hochfährt, dauert das evtl. wegen systemd etwas weniger ist aber auch egal, da ich auf den Kaffee konditioniert bin ==>> dito.
- Nur hat systemd regelmäßig, also jeden 2. bzw. 3. Tag Probleme mit sich selbst und hängt beim Starten fest, weil ein Dienst einen anderen benötigt und der noch nicht da ist -> Harter Reset und Daumen drücken, dass es beim 2. Kaltstart (Rekord waren 7 Kaltstarts am Stück, da hab ich dann tatsächlich die Hardware getestet - aber die hatte nichts...) endlich klappt ==>> Startzeit relevant! Es ist echt beschissen wegen einer Lennartware so in den Tag zu starten!
Aber zurück zum Thema: Die Startzeit geht am Eigentlichen vorbei.
Es gibt einige INIT-Systeme, jedes hat Vor- und Nachteile.
Bei systemd kann ich mich der ganzen Kritik anschließen (keine Textlogs, keine `einfachen` Skripte die ich zur Not per `echo >>` bearbeiten kann, usw., usf.).
Bei den Vorteilen habe ich damit (dem anschließen) große Probleme.
Nun habe ich aber nicht die Fähigkeiten bei den komplexen init-Systemen mitzuwirken. Und die Zeit dafür auch nicht.
Aber den openSUSE Desktop migriere ich Stück für Stück zu PCBSD, der Leidensdruck und Frust den systemd in so verdammt kurzer Zeit erzeugt hat ist wahrlich enorm!
Noch vor einem Jahr war die Verteilung von Server- und Desktopbetriebssystem ganz klar: auf die Server kommt FreeBSD und auf die Desktops kommt irgend ein Linux auf dem KDE reibungslos läuft, ergo openSUSE, doch damit ist es jetzt vorbei.
Aber das ist auch nur ein Aufschub, ich meine als generelle Tendenz zu erkennen, dass OpenSource als solche zunehmend auf Linux zentralisiert wird.
systemd ist da nur ein Baustein, ein weiterer Baustein wäre z.B. wayland, aber der wird einem, zumindest noch, nicht so massiv aufgedrückt.
All die nötigen Anpassungen der Desktop Environments(als Beispiel) daran hält diese auf Trab und lässt Zeit für portable Lösungen schwinden.
So gesehen graut es mir vor den zukünftigen Entwicklungen, denn zumindest Lennartware wird mit der Zeit nicht besser
(PulseAudio ist immer noch Müll und wird es wahrscheinlich auch bleiben und ob der
udev Fork erfolg hat und sich durchsetzt wird sich erst noch zeigen)...
Aber Lennart ist sehr aktiv und hat allein dadurch im Linuxumfeld viel Gewicht, weshalb die BSDs eher früher als später etwas wie eine pseudo-systemd-Schicht bauen müssen...
EDIT(2013-07-07_08:23):
Noch ein kurzer Nachtrag zu Laptops bzw. Mobilgeräten.
Einen tragbaren Rechner zerre ich mit mir mit, wenn ich unterwegs bin:
- Wenn ich alleine bin ist mir die Startzeit völlig egal. Gerade da zur Zeit SSDs große Verbreitung erfahren und im Mobilbereich neben der Geschwindigkeit viele Vorteile haben(vom Tisch fallen..)
- Wenn ich jemanden treffe, dann ist das nicht wirklich anders. Es geht nie direkt nach der Begrüßung hinter den/die Monitor/e. Es wird immer noch etwas besprochen und da kann auch jeder Methusalemlaptop in Ruhe hochfahren.
Zuletzt bearbeitet:
Hi
mein Lenovo X230 mit einer Samsung 830 SSD startet in 7 Sekunden.
Hoffe das systemd ein Hype ist, der schnell wieder vergeht. Würd mich
nicht wundern, wen dem Typ auch mal ne Torte ins Gesicht fliegt.
Startzeit ist mir egal, wichtiger sind für mich Laptoptypische Stromsparfunktionen.
uptime jetzt: 8 Tage.
mein Lenovo X230 mit einer Samsung 830 SSD startet in 7 Sekunden.
Hoffe das systemd ein Hype ist, der schnell wieder vergeht. Würd mich
nicht wundern, wen dem Typ auch mal ne Torte ins Gesicht fliegt.
Startzeit ist mir egal, wichtiger sind für mich Laptoptypische Stromsparfunktionen.
uptime jetzt: 8 Tage.
Zu dem „Beim Booten brühe ich meinen Kaffee auf.“ Argument muss ich mal gegensteuern.
Das ist kein Argument gegen schnellere Bootzeiten, sondern genau das Gegenteil. Nämlich ein Symptom dafür, dass die Bootzeiten so lang sind, dass ihr einen Hack anwendet um die Auswirkungen auf eure Produktivität zu maskieren.
Das es den Hack gibt, heißt nicht, dass das Problem gelöst ist.
Das ist kein Argument gegen schnellere Bootzeiten, sondern genau das Gegenteil. Nämlich ein Symptom dafür, dass die Bootzeiten so lang sind, dass ihr einen Hack anwendet um die Auswirkungen auf eure Produktivität zu maskieren.
Das es den Hack gibt, heißt nicht, dass das Problem gelöst ist.
darktrym
Fahnenträger
h^2
hat ne Keule +1
Ich wollte nurmal anmerken, dass ich überhaupt nichts gegen kurze Bootzeiten haben, im Gegenteil. Mich stört auch nicht, dass leute für mobile Geräte und Desktops ein tolles Init-System mit Parallelisierung schreiben.
Was mich stört ist, dass die Modularisierung aufgegeben wird und durch die Inkorporierung weiterer Funktionen das Init-System so aufgebläht wird, dass andere Dienste und Programme dann dieses eine Init-System voraussetzen.
Genauso wie is mir latte ist, wenn Redhat die siebente Audio-Abstraktionsschicht in ihr OS packt, wenn nur die Interfaces gleich blieben, so dass die Programme auch weiterhin mit allen anderen Audio-Interfaces (OSS) funktionierten.
Also es geht nicht darum gegen einen bestimmten Lösungsansatz zu sein, sondern nur gegen den Allgemeingültigkeitsanspruch dieses Ansatzes.
Was mich stört ist, dass die Modularisierung aufgegeben wird und durch die Inkorporierung weiterer Funktionen das Init-System so aufgebläht wird, dass andere Dienste und Programme dann dieses eine Init-System voraussetzen.
Genauso wie is mir latte ist, wenn Redhat die siebente Audio-Abstraktionsschicht in ihr OS packt, wenn nur die Interfaces gleich blieben, so dass die Programme auch weiterhin mit allen anderen Audio-Interfaces (OSS) funktionierten.
Also es geht nicht darum gegen einen bestimmten Lösungsansatz zu sein, sondern nur gegen den Allgemeingültigkeitsanspruch dieses Ansatzes.
q000te
Well-Known Member
Kaffee, jaaa... Bootzeit ist eigentlich egal und kann belibig substituiert werden und wenn es
nur dar kurze Plausch mit dem Kollegen ist..
Das war mehr angenervt von ständigen Reset bis ein Bootvorgang bis zum Ende kommt.
Da kritische bei dem ganzen Krempel ist die Zentralisierung auf ein System.
Wenn es richtig schlecht läuft übernimmt systemd immer mehr Aufgaben und
viele andere Software hängt dann von systemd ab und dann heißt es friss den Müll
oder stirb.
systemd wird auf jeden Fall bei KDE / Gnome / belibiger anderer Desktop
Zeit und Leute binden, zuerst damit es auch mit systemd funktioniert.
Später wird es dann immer aufwendiger ohne systemd klar zu kommen, da die
bereitgestellte Funktionalität es halt bequemer macht die Abhängigkeit einzugehen...
Und dann darf eine Kompatiblitätsschicht für systemd in die BSDs eingezogen werden,
was bei der wahnsinnigen Dokumentation ein reines Freudenfest wird.
nur dar kurze Plausch mit dem Kollegen ist..
Das war mehr angenervt von ständigen Reset bis ein Bootvorgang bis zum Ende kommt.
Da kritische bei dem ganzen Krempel ist die Zentralisierung auf ein System.
Wenn es richtig schlecht läuft übernimmt systemd immer mehr Aufgaben und
viele andere Software hängt dann von systemd ab und dann heißt es friss den Müll
oder stirb.
systemd wird auf jeden Fall bei KDE / Gnome / belibiger anderer Desktop
Zeit und Leute binden, zuerst damit es auch mit systemd funktioniert.
Später wird es dann immer aufwendiger ohne systemd klar zu kommen, da die
bereitgestellte Funktionalität es halt bequemer macht die Abhängigkeit einzugehen...
Und dann darf eine Kompatiblitätsschicht für systemd in die BSDs eingezogen werden,
was bei der wahnsinnigen Dokumentation ein reines Freudenfest wird.
- Status