Nutzt schon jemand systemd?

Message

Klaus Meier · Post by **Klaus Meier** » Thu Jun 14, 2012 10:43 am

Es gibt ja zur Zeit einige Artikel darüber und die meisten Kommentare dazu ziemlich negativ, ich finde es aber von der Idee her erst mal gar nicht so schlecht. Ich habe mir dass einmal angeschaut: http://en.gentoo-wiki.com/wiki/Systemd

Muss man alle dort angegebenen Konfigurationsdateien per Hand anlegen? Ist also erst mal ziemliche Handarbeit. Das elog von systemd sagt, dass noch nicht alle Pakete angepasst sind, gibt es da Wichtiges, was noch nicht funktioniert? gdm z.b. steht nicht in der Liste, nur kdm.

Wie sieht es im Betrieb aus? Die größten Unterschiede wird es wohl beim Ein- und Ausschalten geben. Hab es gestern abend mal kurz probiert, ausschalten ist wie Stecker rausziehen... Hatte dann aber keine Lust mehr, alles zu konfigurieren...

py-ro · Post by **py-ro** » Thu Jun 14, 2012 11:11 am

Auf Gentoo hab ich es noch nicht probiert, aktuell leider wenig Zeit für Basteleien, aber auf Fedora beschleunigt das den Boot-Vorgang doch schon extrem.

Jimini · Post by **Jimini** » Mon Jul 16, 2012 5:49 am

Da ich heute Nacht nicht einschlafen konnte, habe ich mich mal drangesetzt und systemd auf meinem Desktop installiert. Es hat eine Weile gedauert, bis alle benötigten Pakete demaskiert waren, da immer wieder diverse Abhängigkeiten auftauchten, die ich ebenfalls demaskieren musste. Am stärksten macht sich der Effekt beim Shutdown bemerkbar - ein "halt" aus KDE heraus schaltet die Kiste in rund 2 Sekunden ab. Der Bootvorgang dauert laut grafischer Auswertung ("systemd-analyze plot > blablubb.svg") knapp 16 Sekunden, was für eine HDD mit 5400 rpm echt nicht schlecht ist.

Ein paar Daemons (mpd, mpdscribble, cpufrequtils, uptimed...) habe ich noch nicht dazu bewegen können, sich von systemd starten zu lassen.

MfG Jimini

Klaus Meier · Post by **Klaus Meier** » Tue Jul 17, 2012 9:22 am

Irgendwie ist das mit den Zeiten für das Starten und Stoppen schon knackig, aber normalerweise macht man das ja auch nicht so oft. Aber ich denke, irgendwann wird systemd Pflicht werden, irgend wann muss man sich damit beschäftigen.

Ich habe mir folgende Anleitung angesehen: http://en.gentoo-wiki.com/wiki/Systemd

Muss ich die ganzen Dateien alle per Hand anlegen? Bekommt man sonst alles gestartet? In der c't gab es ja gerade einen Artikel über vdr und Ubuntu, da bekommt man ja den vdr nicht mit Upstart gestartet. Und naja, wenn du stable nutzt, ist vielleicht nicht unbedingt die beste Basis für solche Experimente...

schmidicom · Post by **schmidicom** » Tue Jul 17, 2012 12:35 pm

Auf einigen Webseiten behaupten die Leute systemd würde consolekit ersetzen oder zumindest überflüssig machen, stimmt das?

py-ro · Post by **py-ro** » Tue Jul 17, 2012 12:40 pm

franzf · Post by **franzf** » Tue Jul 17, 2012 1:13 pm

schmidicom wrote:Auf einigen Webseiten behaupten die Leute systemd würde consolekit ersetzen oder zumindest überflüssig machen, stimmt das?

Nicht nur ersetzen oder überflüssig machen: ConsoleKit ist schon jetzt nicht mehr unter aktiver Entwicklung:
http://www.freedesktop.org/wiki/Software/ConsoleKit
Das heißt auf kurz oder lang wird jeder der udisks verwendet (und das ist jeder, der heute auf dem Linux-Desktop einen MediaTray o.'. am Werkeln hat) auf systemd umstellen müssen, denn udisks braucht polkit was wiederum ConsoleKit/systemd braucht.

bell · Post by **bell** » Tue Jul 17, 2012 1:35 pm

Ach ja, wie schnelllebig doch das ganze ist. Dabei ist die Ablösung von "hal" durch die "*Kit's" noch gar nicht so lange her. Damaliges Argument war: All-in-One Lösungen sind nich gut wartbar, daher Aufsplittung in mehrere "*Kit's". Und wo geht es jetzt wieder hin?
Da überlege ich mir echt lieber den Weg nach Mdev zu gehen: https://wiki.gentoo.org/wiki/Mdev. Ich denke das Busybox-Projekt wird dem Trend nicht folgen, also gibt es da erstmal Ruhe.

disi · Post by **disi** » Tue Jul 17, 2012 1:59 pm

franzf wrote:
schmidicom wrote:Auf einigen Webseiten behaupten die Leute systemd würde consolekit ersetzen oder zumindest überflüssig machen, stimmt das?
Nicht nur ersetzen oder überflüssig machen: ConsoleKit ist schon jetzt nicht mehr unter aktiver Entwicklung:
http://www.freedesktop.org/wiki/Software/ConsoleKit
Das heißt auf kurz oder lang wird jeder der udisks verwendet (und das ist jeder, der heute auf dem Linux-Desktop einen MediaTray o.'. am Werkeln hat) auf systemd umstellen müssen, denn udisks braucht polkit was wiederum ConsoleKit/systemd braucht.

Das macht mir Angst, der letzte gdm hat noch consolekit als Standard und braucht es vermutlich auch?
http://en.znurt.org/gnome-base/gdm/gdm-3.4.1
Sogar auf dem Laptop bin ich kein hotplugger

Normal geht das so:
1. etwas einstecken
2. wirre popups und notifications
3. 'mount' in the Konsole eingeben, um herauszufinden wo er es evtl. bereits gemapped hat
4. auf der Konsole im Verzeichnis nach den Dateien suchen und ggf. mit rsync o.Ae. in die lokalen Ordner kopieren (e.g. Fotos, Dokumente)

Im Media-Player sollte man doch immer noch direkt /dev/sr0 adressieren koennen?!?

schmidicom · Post by **schmidicom** » Tue Jul 17, 2012 2:15 pm

disi wrote:Normal geht das so:
1. etwas einstecken
2. wirre popups und notifications
3. 'mount' in the Konsole eingeben, um herauszufinden wo er es evtl. bereits gemapped hat
4. auf der Konsole im Verzeichnis nach den Dateien suchen und ggf. mit rsync o.Ae. in die lokalen Ordner kopieren (e.g. Fotos, Dokumente)

Also bei mir geht "Normal" so:
1. Stick einstecken/CD einlegen
2. Doppelklick/Einfachklick auf Popup
und fertich

mrsteven · Post by **mrsteven** » Tue Jul 17, 2012 4:12 pm

bell wrote:Ach ja, wie schnelllebig doch das ganze ist. Dabei ist die Ablösung von "hal" durch die "*Kit's" noch gar nicht so lange her. Damaliges Argument war: All-in-One Lösungen sind nich gut wartbar, daher Aufsplittung in mehrere "*Kit's". Und wo geht es jetzt wieder hin?

Genau meine Rede. Ich hoffe nur, dass Gentoo das OpenRC-System lange unterstützt und nicht KDE irgendwann von systemd zwingend abhängt. Das letzte was ich auf der Mailingliste mitbekommen habe, ist dass zumindest ersteres auf absehbare Zeit kein Problem sein sollte. Bei KDE bin ich mir aber nicht sicher, weil ja ConsoleKit eine Abhängigkeit ist, die jetzt schon nicht mehr weiterentwickelt wird. Schon möglich, dass KDE da demnächst umfällt^H^H^H^H^Hschwenkt.

musv · Post by **musv** » Tue Jul 17, 2012 9:10 pm

Ich finde Systemd eigentlich ganz interessant. Die bisherigen Kritikpunkte, die man so liest:

Missachtung Unix-Philosophie: Für jede Aufgabe ein Tool.
Die Logs sind wohl mit Systemd nicht mehr direkt als Textdatei verfügbar, sondern müssen im systemd irgendwie abgefragt werden.
Lennart Poettering ist der Entwickler des Projekts.

Da es von Red Hat vorangetrieben wurde und diverse Projekte (KDE, Gnome) erst von Hal, dann von *kit in ihrer Funktionalität und Lauffähigkeit abhängig gemacht wurden, werden sie wohl alle nicht drumherum kommen, früher oder später auf systemd umzusteigen.

KDE läuft doch eigentlich auch unter BSD. Wie funktioniert das eigentlich da mit dem *kit-Geraffel und systemd in Zukunft?

Anmerkung: Wie macht systemd das eigentlich mit den Runlevel? Ich hab bei mir auf dem Notebook z.B. nach Runlevel abweichende Netzwerkkonfigurationen.

franzf · Post by **franzf** » Wed Jul 18, 2012 6:39 am

musv wrote:KDE läuft doch eigentlich auch BSD. Wie funktioniert das eigentlich da mit dem *kit-Geraffel und systemd in Zukunft?

http://wiki.freebsd.org/KDE4/
Die verwenden einfach noch immer hal

(gibt ja da kein udev und damit udisks)
Und so lange die kde4-Integration in systemd optional bleibt, wird es auch auf freebsd ein kde4 geben.
AFAIK kann systemd schon einiges an gnome3-Sachen vorladen, wodurch nicht nur der Boot sondern auch der Login zügiger ablaufen soll (sry, dass ich keinen Link habe, war aber irgendwo auf der Pöttering-Seite). Dafür muss man wohl nur ne kleine Lib für systemd schreiben, so könnte auch kde4 profitieren. Wobei der dickste Brocken beim Login in eigentlich das Starten von nepomuk ist, und das wird man nicht einfach so in den Boot auslagern können. Wenn kde4 das auch weiterhin als Option sieht - alles bestens - leider habe ich auch schon Kommentare gelesen, ob es sich auch für CORE-Sachen weiterhin lohnt, so offen zu bleiben, oder ob man sich nur auf Linux beschränken sollte.
Trotzdem sträube ich mich gegen systemd - alleine schon weil es von Pöttering kommt; deshalb rechne ich auch damit, dass es in zwei Jahren obsolet ist und man jetzt "Bootering" nehmen soll, natürlich mit vollkommen anderer Funktionsweise, Konfiguration, etc. OpenRC passt mir vollkommen, es startet meinen Rechner zuverlässig, deshalb gehe ich davon nicht weg.

forrestfunk81 · Post by **forrestfunk81** » Wed Jul 18, 2012 4:10 pm

Ich find einige Lösungswege von systemd (sockets, cgroups, socket-based- und bus-name-based activation) schon richtig gut und werd das sicherlich bald in einer VM mal ausprobieren. Aber wie die Integration mit KDE / Gnome Session Manager aussehen soll bzw was das bringen soll hab ich noch nicht so ganz kapiert. Spart man sich dann den Loginmanager oder geht es eher darum die Initialisierungen unter Gnome / KDE zu vereinheitlichen?

mrsteven · Post by **mrsteven** » Wed Jul 18, 2012 5:08 pm

musv wrote:Missachtung Unix-Philosophie: Für jede Aufgabe ein Tool.
Da es von Red Hat vorangetrieben wurde und diverse Projekte (KDE, Gnome) erst von Hal, dann von *kit in ihrer Funktionalität und Lauffähigkeit abhängig gemacht wurden, werden sie wohl alle nicht drumherum kommen, früher oder später auf systemd umzusteigen.

Das ist eigentlich das Hauptproblem, das ich mit systemd habe. Würde das Ding nicht vom Systemstart über Session-Verwaltung und Logging bis zum Rasenmähen alles übernehmen, dann hätte ich kein Problem mit systemd, da ich es schlicht und ergreifend nicht einsetzen muss. Aber so hängt z.B. KDE irgendwann von dem Teil ab und man kann gleich sein ganzes System umstellen.

Sonst wäre mir systemd vollkommen egal.

mv · Post by mv » Wed Jul 18, 2012 6:58 pm

Falls der Tag kommen sollte, an dem KDE eine feste Abhängigkeit an systemd hat, ist dies der Tag, an dem KDE endgültig von all meinen Rechnern fliegt.
Mal ein paar Fakten: Mag sein, dass man durch Parallelisieren ein paar Sekunden beim Booten spart. Dafür Daemonen laufen zu lassen, die im laufenden System permanent Ressourcen brauchen, ist natürlich eine Schnapsidee; schon allein wegen dieser hätte das Konzept in der Tonne landen müssen.
Aber das Parallelisieren hat ja bekanntlich weitere Nachteile (nicht umsonst ist es aus openrc herausgeflogen): Jedwede Art von Problemen kann auf einmal kaum nachvollziehbar nur sporadisch auftreten - für ferngewartete Rechner, bei denen der Bootvorgang vollkommen zuverlässig ablaufen muss, eine reine Katastrophe. Aber Lennart weiß, wie man dem Administrator noch mehr Probleme bereiten kann: Binär-Blobs statt Logdateien. Damit man im Falle echter Probleme einen Segfault statt wichtiger Informationen erhält! Spätestens jetzt sollte jeder Mensch mit echter Computererfahrung wissen: Finger weg von dieser Software-Murkserei!
Andere Schwachsinnsideen habe ich mir nur erzählen lassen: So soll z.B. die "noauto"-Option in /etc/fstab von systemd bewusst ignoriert werden. Also Lennart glaubt, besser als der Administrator zu wissen, wann ein Filesystem eingehängt werden muss. Diese Gängelei war für mich der Grund, keine MS-Produkte mehr zu benutzen.

schmidicom · Post by **schmidicom** » Wed Jul 18, 2012 6:59 pm

Wenn ich mir auf der Wikiseite den Abschnitt mit den bekannten Problemen ansehe vergeht mir ehrlich gesagt die Lust aufs ausprobieren. Allein schon die Aussicht auf eine Installation wo zwei verschiedene init-Systeme präsent sein müssen um jede Software zufrieden zu stellen bereitet mir Bauchschmerzen.

musv · Post by **musv** » Wed Jul 18, 2012 8:45 pm

mv wrote:Dafür Daemonen laufen zu lassen, die im laufenden System permanent Ressourcen brauchen, ist natürlich eine Schnapsidee; schon allein wegen dieser hätte das Konzept in der Tonne landen müssen.

Soweit ich das bisher mitbekommen hab, scheint Poettering seinen Schwerpunkt auf die Entwicklung von Daemons gelegt zu haben. Zumindest kenn ich keine anderen Projekte von ihm.

Ohne jetzt aber alles gleich verteufeln zu wollen, warten wir erstmal ab, was aus systemd wird. Vielleicht ist das Teil gar nicht so schlecht. Ach ja, wie ich das gelesen hab, soll das Teil wohl auch die Eigenschaften von inetd beinhalten. D.h. benötigte Dienste sollen bei Bedarf gestartet werden.

forrestfunk81 · Post by **forrestfunk81** » Wed Jul 18, 2012 9:23 pm

musv wrote:
mv wrote:Dafür Daemonen laufen zu lassen, die im laufenden System permanent Ressourcen brauchen, ist natürlich eine Schnapsidee; schon allein wegen dieser hätte das Konzept in der Tonne landen müssen.
Soweit ich das bisher mitbekommen hab, scheint Poettering seinen Schwerpunkt auf die Entwicklung von Daemons gelegt zu haben. Zumindest kenn ich keine anderen Projekte von ihm.

Ohne jetzt aber alles gleich verteufeln zu wollen, warten wir erstmal ab, was aus systemd wird. Vielleicht ist das Teil gar nicht so schlecht. Ach ja, wie ich das gelesen hab, soll das Teil wohl auch die Eigenschaften von inetd beinhalten. D.h. benötigte Dienste sollen bei Bedarf gestartet werden.

Ja genau, das meinte ich mit socket-based- und bus-name-based activation. Spätestens bei einer Anfrage über den Socket oder DBus wird der Dienst dann gestartet. Zwar läuft ein systemd Prozess laufend, aber wieviele Dienste laufen auf einem durchschnittlichen PC, die meist nicht oder nur sehr selten benutzt werden (cups, sshd, cron etc pp).

mv wrote:Binär-Blobs statt Logdateien. Damit man im Falle echter Probleme einen Segfault statt wichtiger Informationen erhält!

Man kann trotzdem syslog Daemons laufen lassen, welche dann die vom systemd journal gesammelten Logs (inkl STDERR, systemd und normales syslog) weitergereicht bekommen und in eine Datei, Datenbank übers Netzwerk oder sonstwohin schreiben können. Zum automatischen Auswerten des Logs ist ein um Metadaten angereichertes Binär-Log sicherlich nicht verkehrt.

Bestimmt gibt es auch Anwendungsmöglichkeiten, wo eine klassische Konfiguration sinnvoller ist und ich hoffe diese Möglichkeit bleibt weiterhin bestehen.

mv · Post by mv » Thu Jul 19, 2012 8:14 am

musv wrote:Soweit ich das bisher mitbekommen hab, scheint Poettering seinen Schwerpunkt auf die Entwicklung von Daemons gelegt zu haben.

Ein Zeichen seiner Inkompetenz: Daemonen sind prinzipiell ein hackischer Workaround, die bestenfalls für Netzwerkdienste eine Berechtigung haben. Für alle anderen Sachen sollte das entsprechende Programm nur bei Bedarf gestartet werden und nicht permanent Ressourcen fressen.

forrestfunk81 wrote:Man kann trotzdem syslog Daemons laufen lassen

Noch. Poettering hatte schon angekündigt, dass er Text-Logdateien für Teufelszeug hält und verbannen will. Er will aber wohl erst warten, bis Redhat die syslogd-Kröte schluckt, bevor er die nächste Verschlechterung durchdrückt. Das sieht wirklich so dermaßen nach System aus, dass allmählich der Verdacht aufkommt, der Mann wir von MS bezahlt, um die Konkurrenz Linux zu ruinieren.

Zum automatischen Auswerten des Logs

Vor allem Bootprobleme werden ja regelmäßig nur durch Log-Parsingscripte gelöst.

Zwar läuft ein systemd Prozess laufend, aber wieviele Dienste laufen auf einem durchschnittlichen PC, die meist nicht oder nur sehr selten benutzt werden (cups, sshd, cron etc pp).

Schön, dass wir uns über das Symptom einig sind: Wie ich schrieb, sind alle diese Daemonen eine Notlösung, die sich nur dann nicht vermeiden lassen, wenn man diese Dienste in einem Server von außen zugänglich machen muss. Die Kur kann aber nicht sein, noch einen zusätzlichen Dienst permanent laufen zu lassen.
Vielmehr sollte man seinen Rechner so konfigurieren, dass man die benötigten Dienste bei Bedarf an- und bei Nichtbedarf auch wieder abstellt. Ja, dies bedarf Einiges an Konfigurationsaufwand (und ev. Patchen einiger Programme), das sich aber auf saubere Weise bewerkstelligen ließe
Gleiches gilt für Policykit und Consolekit: Die richtige Lösung wäre es, beim Einloggen für die Devices (einmalig!) die richtigen Rechte zu vergeben. (Wenn pam dazu genutzt werden könnte, wäre es sogar ausnahmsweise sinnvoll, auf Desktops pam zu installieren.) Aber permanent Daemons mit Root-Rechten laufen zu lassen, um das traditionalle Rechte-Konzept zu unterlaufen, ist eine ressourcenverschwendende und sicherheits-katastrophale Fehlkonzeption.
Wie gesagt: Daemons zu diesen Zwecken sind nichts anderes als schmutzige Quick'n'Dirty-Hacks, die man um jeden Preis vermeiden sollte.
Wenn Poettering sich vernünftige Konzepte ausgedacht hätte, wäre ich sofort auf seiner Seite, aber seine "Lösungen" sind konzeptionell einfach katastrophale Verschlechterungen der Situation.

astaecker · Post by **astaecker** » Thu Jul 19, 2012 8:57 am

Hier mal eine Zusammenfassung der hier genannten Vorteile und der Kritik zu systemd. Ich habe noch ein paar Informationen zu Gunsten von systemd hinzugefügt. Polemik habe ich weggelassen.

systemd Vorteile

Schnellerer Bootvorgang:
Ein schnellerer Bootvorgang durch Verwendung von Parallelisierung sockets, socket-based- und bus-name-based activation. Durch *-activation spart systemd Ressourcen, solange der Daemon nicht gebraucht. Da man keine *-activation nutzen muss (andere .service Datei), ist dieses Verhalten optional.

systemd Login Manager - ConsoleKit Ersatz:
Der Login Manager bietet die Funktionalität von ConsoleKit, hat aber auch ein funktionierendes MultiSeat Management. Er lässt sich parallel zu ConsoleKit betreiben, so dass nicht umgestellte Software nicht auf der Strecke bleibt.
ConsoleKit wird nicht weiterentwickelt. Dies war schon vor dem Erscheinen von systems Login Manager der Fall, so dass man eine Schuld nicht bei systemd oder Lennart (war nie ein CK Entwickler) suchen kann.

Vereinheitlichung von init Dateien (systemd: .service Dateien):
.service Dateien sollen Teil der Upstream Software-Pakete werden. Das ist noch nicht bei allen Paketen so, so dass die Distros die .service Dateien stellen müssen. Eine gute Quelle dafür ist Fedora, bei denen die systemd Umstellung am weitesten vorgeschritten ist.

Vereinheitlichung von Konfigurationsdateien:
Dies wird eine Erleichterung für Systemadministatoren sein, die mit mehrere Distros verwalten müssen. Auch der Wechsel einer Distro wird erleichtert. Ein Teil der neuen Konfigurationsdateien werden auch schon von OpenRC genutzt.

Journal - Syslog Ersatz:
Erlaubt die Integration von Logs aus allen bekannten Quellen in systemctl start/stop/status. Die Verwendung eines bekannten/quelloffenen/dokumentierten Binär-Formats soll die Performance verbessern, zusätzliche Metadaten bieten und einiges mehr. Das Journal ist optional. Kernellogs sind im Klartext und werden nur ins Journal importiert.

systemd Kritik

All-in-One Lösung / Missachtung Unix-Philosophie:
systemd intern gut strukturiert und hat sauberern Code, so dass die Probleme z.B. von HAL im Moment nicht auftreten.

systemd nutzt Daemonen:
Der Ressourcenverbrauch ist gering, weshalb systemd auch für Embedded Hardware geeignet ist.

OpenRC muss weiterhin installiert bleiben:
Dies ist Gentoo spezifisch. OpenRC als init Daemon wird dabei nicht verwendet. Es wird - soweit ich weiß - nur die /etc/init.d/functions.sh von Portage und dessen Tools benötigt.

systemd Orakel

systemd statt ConsoleKit:
Wenn PolKit, GNOME oder KDE die ConsoleKit Unterstützung zu Gunsten von systemd entfernen, so kann man eine Schuld nicht bei systemd suchen. Eine solche Entscheidung kann dadurch begründet werden, dass man auf eine gewartete Lösung setzt.

systemd statt Session Manager
Es wurde angeregt, dass systemd den Session Manager von GNOME und KDE (ksmserver) ganz oder optional ersetzen könnte. Bei GNOME gibt es auch erste Arbeiten dazu. Bei KDE nicht.
Dazu sollte man wissen, dass der Session Manager im Prinzip die gleichen Dinge tut wie ein init
Daemon. Nur halt nicht systemweit, sondern nur für die Benutzersitzung. Der Session Manager ist damit auch etwas anderes als der Display Manager (gdm, kdm).
Das Ziel / Nutzer davon ist, die obigen Vorteile von systemd auf den Start der Benutzersitzung zu übertragen, u.a. schnellerer Login- und Login->Desktopvorgang.
Eine Vereinheitlichung von Initialisierungen ist kein bekannte Ziel.

mv · Post by mv » Thu Jul 19, 2012 1:32 pm

astaecker wrote:Hier mal eine Zusammenfassung der hier genannten Vorteile und der Kritik zu systemd.

Alle genannten Kritikpunkte hast Du vorsichtshalber mal weggelassen.

Polemik habe ich weggelassen.

Käme ja auch schlecht, wenn man wie Du diese Software verteidigen will. Schade, dass Du auch die Wahrheit (s. z.B. Poettering und Consolekit) weggelassen hast.

systemd Login Manager - ConsoleKit Ersatz:

Wie kann das unter "Vorteile" landen, dass man damit zwingend ein klaffendes Sicherheitsloch aufs Auge gedrückt bekommt?

Er lässt sich parallel zu ConsoleKit betreiben, so dass nicht umgestellte Software nicht auf der Strecke bleibt.

Achso, ja: Zwei verschiedene Libraries für die wichtigsten sicherheitsrelevanten Aufgaben, bei deren "Zusammenspiel" sich die Entwickler von Exploits schon jetzt die Hände reiben können. Damit wird es natürlich ein Vorteil.

Lennart (war nie ein CK Entwickler)

http://cgit.freedesktop.org/ConsoleKit/?h=master

Vereinheitlichung von Konfigurationsdateien:

Das ist ein Vorteil eines distributionsabhängigen Systems. Wie beispielsweise OpenRC. Oder SystemV. Oder Systemd. Oder Upstart. Wo war noch mal der spezielle Vorteil von systemd? Vermutlich, dass Lennart für ständige Änderungen der eigenen Konfigurationsfile bekannt ist (siehe das HAL-Debakel u.ä.).

Journal - Syslog Ersatz:
Erlaubt die Integration von Logs aus allen bekannten Quellen in systemctl start/stop/status.

Ja, genau: Die Vereinheitlichung, die gerade als großer Vorteil beschworen wurde und die es mit syslogd glücklicherweise distributionsunabhängig gibt, kann man natürlich in diesem Punkt kaputt machen. Und wenn man nebenbei noch dafür sorgen kann, dass eine bei einem Halb-Boot mit einem defekten Filesystem geschriebene Datei nun statt zumindest halber Information nur noch einen CRC-Fehler melden kann, ist das natürlich auch ein enormer Vorteil.

All-in-One Lösung / Missachtung Unix-Philosophie:
systemd intern gut strukturiert und hat sauberern Code

Was bitteschön hat eine interne Strukturierung eines Programms mit dem obigen Punkt zu tun? Abgesehen davon nützt bei einer Fehlplanung der Grundfunktionalität die schönste Strukturierung und Dokumentation der Details nichts.

Der Ressourcenverbrauch ist gering, weshalb systemd auch für Embedded Hardware geeignet ist.

Fakt ist: Der Ressourcenverbrauch ist bei vernünftiger Konfiguration des Gesamtsystems vollkommen überflüssig, weshalb der Einsatz schon bei Desktops vermieden werden sollte. Es kann bei einem schnell zusammengeschusterten System als Notlösung dienen, aber eine ordentliche Distribution sollte solche Hacks vermeiden.

bell · Post by **bell** » Thu Jul 19, 2012 2:11 pm

Eine nette Liste. Jedoch kann ich in den genannten Vorteilen keine wirklichen Vorteile sehen.

Erstmal ist und war die Stärke von Linux immer die Vielseitigkeit. Man erinnere sich an die Microsoft-Werbe-Kampagne mit dem mutierten Pinguin, die nach Hinten losgegangen ist. Systemd und vieles andere, was von freedesktop.org unterstützt wird untergräbt diese Stärke. Und bald landen wir bei einem Volks-Linux, die einzig wahre Linux-Distribution!. Systemd ist eine Walze, die kommerziell so gepuscht wird, dass sie jegliche Vielseitigkeit platt macht.
Aber nun zu Deinen Punkten:

- Schnellerer Bootvorgang
Hier gebe ich @mv Recht. Gut konzipierte Software ohne Dämonen die gestartet werden müssen, würden den Boot-Vorgang noch mehr beschleunigen. Der richtige Weg wäre also die einzelnen Dämonen abzuschaffen. Für das Starten von Dämonen bei Bedarf hat OpenRC den Runlevel "hotplugged" (Vielseitigkeit! Andere Konzepte!). Ich gebe zu hier stehen wir noch am Anfang. Wenn einem der schnelle Bootvorgang wichtig ist, der bearbeitet ihn zusätzlich mit e4rat.

- Login-Manager - Consolekit Ersatz
Auch Consolekit war eine Sache die man eigentlich nicht braucht. Ballast durch Ballast ersetzen ist für mich kein Vorteil.

- Vereinheitlichung x2:
Siehe Vorwort. Vereinheitlichung ist nicht gut. Jedes Projekt oder jede Distribution soll eigene Konzepte für bestimmte Dinge entwickeln die mit einander konkurieren. Wo wäre Gentoo wenn die damals gängigen Konzepte wie "RPM" oder "S01*/K01*-Init-Skripte in Gentoo übernommen wurden?

- Journal
Das bisschen Performance-Gewinn rechtfertigt nicht, dass Du spezial-Tools benötigst, falls der Rechner abgekackt ist und Du nur die Festplatte hast. Vor allem wenn der Rechner vor 10 Jahren aufgesetzt war und das Binär-Format nicht mehr mit der aktuellen systemctl-Version gelesen werden kann. Das war eine der Unix-Philosophien: Alles in Textdateien damit man diese ohne Spezial-Tools lesen kann. Auch in der Closed-Source Welt hat man es schon begriffen: Die meisten Binär-Formate gehen Richtung Text-Dateien (XML oder ähnliches). Wir gehen rückwärts. Na klar.

Ich habe nichts gegen neue Konzepte. Jedoch sollten diese nicht so gepuscht werden dass andere Konzepte keine Chance mehr haben und die User keine Wahl mehr.

schmidicom · Post by **schmidicom** » Thu Jul 19, 2012 2:21 pm

Vielleicht sollt mal jemand Lennart den Link zu diesem Forum mailen damit ihm klar wird was die Leute so von seinen Ideen halten...

astaecker · Post by **astaecker** » Thu Jul 19, 2012 2:30 pm

Ich habe mir abermals erlaubt, Polemik wegzulassen.

mv wrote:Wie kann das unter "Vorteile" landen, dass man damit zwingend ein klaffendes Sicherheitsloch aufs Auge gedrückt bekommt?

Die Dateisystem-Rechte sind eine gute Grundlage, bieten aber keine feingliedrigere Rechtevergabe. Es gibt etliche Anwendungsfälle, die nur mit ConsoleKit/Login Manager und PolKit möglich sind. Jedes Review der Software zeigt seinem Lesern solche Szenarien auf.

mv wrote:
Er lässt sich parallel zu ConsoleKit betreiben, so dass nicht umgestellte Software nicht auf der Strecke bleibt.
Achso, ja: Zwei verschiedene Libraries für die wichtigsten sicherheitsrelevanten Aufgaben, bei deren "Zusammenspiel" sich die Entwickler von Exploits schon jetzt die Hände reiben können. Damit wird es natürlich ein Vorteil.

Die beiden interagieren nicht miteinander, sondern laufen nur parallel zueinander.

mv wrote:
Lennart (war nie ein CK Entwickler)
http://cgit.freedesktop.org/ConsoleKit/?h=master

Das hat mich überrascht, da ich mich an einen Blogpost o.ä. erinnern kann, wo er eben diese gesagt (natürlich finde ich den Post nicht wieder). Dennoch wenn man nach Lennart als Autor in obigen System sucht, sieht man, dass er selber nur ein paar Patches beigesteuert hat. Die Releases hat er wohl getaggt, weil es keinen anderen mehr gab, der dies getan hat. Beides macht ihn für mich nicht zu einem Kernentwickler .

mv wrote:
Vereinheitlichung von Konfigurationsdateien:
Das ist ein Vorteil eines distributionsabhängigen Systems. Wie beispielsweise OpenRC. Oder SystemV. Oder Systemd. Oder Upstart. Wo war noch mal der spezielle Vorteil von systemd? Vermutlich, dass Lennart für ständige Änderungen der eigenen Konfigurationsfile bekannt ist (siehe das HAL-Debakel u.ä.).

Irgendwie sprechen wir nicht über die gleiche Sache. Es macht doch Sinn, wenn man z.B. in /etc/locale distributionsunabhängig die Lokalisierung einstellen kann, anstatt sie bei Gentoo unter /etc/conf.d/... , bei Fedora unter /etc/default/... und bei OpenSUSE sonstwo zu finden.

Was du mit dem HAL-Debakel meinst, musst du etwas ausführen.

mv wrote:
Journal - Syslog Ersatz:
Erlaubt die Integration von Logs aus allen bekannten Quellen in systemctl start/stop/status.
Ja, genau: Die Vereinheitlichung, die gerade als großer Vorteil beschworen wurde und die es mit syslogd glücklicherweise distributionsunabhängig gibt, kann man natürlich in diesem Punkt kaputt machen. Und wenn man nebenbei noch dafür sorgen kann, dass eine bei einem Halb-Boot mit einem defekten Filesystem geschriebene Datei nun statt zumindest halber Information nur noch einen CRC-Fehler melden kann, ist das natürlich auch ein enormer Vorteil.

Das Journal ist optinal.

mv wrote:
All-in-One Lösung / Missachtung Unix-Philosophie:
systemd intern gut strukturiert und hat sauberern Code
Was bitteschön hat eine interne Strukturierung eines Programms mit dem obigen Punkt zu tun? Abgesehen davon nützt bei einer Fehlplanung der Grundfunktionalität die schönste Strukturierung und Dokumentation der Details nichts.

Intern hat systemd etliche Module, die sauber voneinander getrennt sind. So bleibt die Software wartbar und man hat nicht die Probleme einer Fehlplanung wie HAL (All-in-One Lösung).

mv wrote:
Der Ressourcenverbrauch ist gering, weshalb systemd auch für Embedded Hardware geeignet ist.
Fakt ist: Der Ressourcenverbrauch ist bei vernünftiger Konfiguration des Gesamtsystems vollkommen überflüssig, weshalb der Einsatz schon bei Desktops vermieden werden sollte. Es kann bei einem schnell zusammengeschusterten System als Notlösung dienen, aber eine ordentliche Distribution sollte solche Hacks vermeiden.

Das musst du weiter ausführen. Ich weiß nicht, wie du das genau meinst.