SystemD Fork, back to the roots

[Colttt]

Hallo,

es gibt anscheinend einige die das dicke fette systemd nicht gut finden und haben ein Form gebaut getreu dem Motto one tool for one job..

http://www.pro-linux.de/news/1/21537/us ... stemd.html

[TRex]

Riecht nach bullshit. Ist ja nicht so, als ob es keine anderen init-systeme gäbe... man hat sie nur wegen der fehlenden Manpower und Integration nicht auserwählt. Und dann kommt so was daher.

[Milbret]

@TRex
So einfach ist das leider auch nicht.
Der Vorteil von systemd ist auch, dass es gerde den Boot Prozess durch parallele Verarbeitung und Starts der Dienste, beschleunigt.
Leider sehe ich Systemd etwas kritisch, da es sich teilweise zu sehr in das System frist und deshalb Boot Skripte und auch andere System Dienst Skripte eben nicht mehr portierbar macht.
Wenn man also Skripte für Systemd bastelt, können diese nicht auf andere Unix artige Systeme portiert werden.

Manpower gibt es genug, nur ist die Software wie SysVInit nicht auf parallele Verarbeitung ausgelegt.
Upstart und co. versuchen dieses Problem nur zu kaschieren in dem sie die Skripte auch unabhängig von einer ander starten.

Ich finde den Ansatz von Uselessd schon interessant.
Aber auch hier gibt es noch zu viele Abhängigkeiten.
Durch solche Basis Dienste, die sich mit der Zeit aufblähen, sehe ich auch den Verlust von einigen Möglichkeiten mit Linux.
Vorallem im Embeded Bereich machen Abhängigkeiten wie Systemd und co. Probleme.

Ich hoffe immer noch, dass es eine einfachere Lösung als Systemd und abgespeckte Forks gibt.
Ansonsten werden einige Projekte bald mehr Aufwand haben um ihre Software für alle Unix artigen Systeme bereitzustellen.

Martin

[MrGerardCruiz]

Wie so vielen Frust-Forks wird denen der lange Atem fehlen, den es für sowas braucht.

Mir fällt in den letzten Jahren nur ein einziger Frust-Fork ein, der als Erfolg bezeichnet werden kann: MATE. Und auch da ist die Manpower problematisch und langfristige Zukunft (Gtk3) äußerst ungewiss.

[catdog2]

Wie so vielen Frust-Forks wird denen der lange Atem fehlen, den es für sowas braucht.

Ja… Außerdem scheint die Leistung darin zu bestehen sämtlichste Features zu entfernen. Code löschen kann ich auch, geht ganz einfach.

[NAB]

Desweiteren wird das Journal entfernt, das bei Systemd die Rolle von rsyslog zum Protokollieren von Systemmeldungen übernommen hat.

Find ich gut ^^

Ich sehe das erst mal als Machbarkeitsstudie, wie weit sich Systemd zerlegen und zurechtstutzen lässt. Und ich hätte es als schlauer empfunden, wenn sie dafür den neusten Systemd genommen hätten.

Das ist ja genau das, was Poettering "bei sich" nicht will .. dass Systemd sich in einzelne Komponenten zerlegen lässt, die sich ggf. austauschen lassen. Wo soll man es also versuchen? Halt als kleines Randprojekt. Immerhin scheint dazu "ein Mann" auszureichen ... beruhigend.