# Nutzt schon jemand systemd?

## Klaus Meier

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

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

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

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

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

----------

## py-ro

Ja.

----------

## franzf

 *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

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

 *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 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  :Smile: 

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

 *disi wrote:*   

> Normal geht das so:
> 
> 1. etwas einstecken
> 
> 2. wirre popups und notifications
> ...

 

Also bei mir geht "Normal" so:

1. Stick einstecken/CD einlegen

2. Doppelklick/Einfachklick auf Popup

und fertich   :Wink: 

----------

## mrsteven

 *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.  :Confused: 

----------

## musv

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.Last edited by musv on Wed Jul 18, 2012 12:09 pm; edited 1 time in total

----------

## franzf

 *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  :Wink:  (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

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

 *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

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

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

 *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

 *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

 *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.

 *Quote:*   

> Zum automatischen Auswerten des Logs

 

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

 *Quote:*   

> 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

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

 *astaecker wrote:*   

> Hier mal eine Zusammenfassung der hier genannten Vorteile und der Kritik zu systemd.

 

Alle genannten Kritikpunkte hast Du vorsichtshalber mal weggelassen.

 *Quote:*   

> 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.

 *Quote:*   

> systemd Login Manager - ConsoleKit Ersatz:

 

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

 *Quote:*   

> 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.

 *Quote:*   

> Lennart (war nie ein CK Entwickler)

 

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

 *Quote:*   

> 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.ä.).

 *Quote:*   

> 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.

 *Quote:*   

> 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.

 *Quote:*   

> 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

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

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

----------

## astaecker

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:*   

>  *Quote:*   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:*   

>  *Quote:*   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:*   

>  *Quote:*   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:*   

>  *Quote:*   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:*   

>  *Quote:*   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:*   

>  *Quote:*   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.

----------

## astaecker

 *bell wrote:*   

> 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!.

 

Differenzierung macht Sinn, wenn es was zu differenzieren gibt. Wenn viele Distros exakt gleiche Sachen machen, ist es doch sinnreich, ein Gemeinschaftsprojekt daraus zu machen und sich viel Arbeit zu ersparen. Als Paradebeispiel für ich hier mal den Linux Kernel an. Als Beispiel für sinnvolle Differenzierung Portage.

 *bell wrote:*   

> Hier gebe ich @mv Recht. Gut konzipierte Software ohne Dämonen die gestartet werden müssen, würden den Boot-Vorgang noch mehr beschleunigen.

 

Daemonen werden häufig für systemweite Dienste genutzt, die erweiterte Rechte brauchen, so dass der Benutzer sie nicht selber starten kann. Mit den Sockets hat systemd schon eine gute Methode gefunden, viele Daemonen nur bei Bedarf zu starten.

 *bell wrote:*   

> Wenn einem der schnelle Bootvorgang wichtig ist, der bearbeitet ihn zusätzlich mit e4rat.

 

Kein init Daemon ist bisher so schnell wie systemd. Und man sollte diesen Vorteil auch nicht herunterspielen, da es immernoch massenweise Benutzer gibt, die ihren PC herunterfahren anstatt S3 oder S4 zu nutzen.

 *bell wrote:*   

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

 

Es gibt es etliche Anwendungsfälle, die nur durch Software wie ConsoleKit ermöglicht werden.

 *bell wrote:*   

> 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.

 

Wie gesagt, ist das Binär-Format quelloffen und damit bekannt, und nach einer Beta-Phase wollen sie es auch ausführlich dokumentieren (was sie wohl auch gewissentlich tun werden, da systemd hervorragend dokumentiert ist). Die berechtigten Vorbehalte vor der Closed-Source Welt treffen daher einfach nicht zu.

 *bell wrote:*   

> 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.

 

Anderen Konzepte haben eine Chance, z.B. hat sich busybox mit mdev als Alternative zu udev & Co entwickelt. Nur fehlt es oft an Entwicklern, die die anderen Konzepte auch realisieren, was aber nicht die Schuld von udev & Co Entwicklern ist.

----------

## franzf

 *astaecker wrote:*   

> Differenzierung macht Sinn, wenn es was zu differenzieren gibt. Wenn viele Distros exakt gleiche Sachen machen, ist es doch sinnreich, ein Gemeinschaftsprojekt daraus zu machen und sich viel Arbeit zu ersparen.

 

Lol? systemd stammt von EINER Person, die für EINE Firma arbeitet. Da andere Projekte dieser EINEN Person sich dermaßen tief in aktuelle Desktops gefressen haben, ist es ihm problemlos möglich, allen sein system aufs Auge zu drücken. Das hat nix mit Gemeinschaft zu tun, das ist Diktatur! (Evtl. das "D" in SystemD?)

 *Quote:*   

> Als Paradebeispiel für ich hier mal den Linux Kernel an.

 

Ohne Linux-Kernel hätte man kein Linux, damit auch keine Linux-Distribution. Nur weil viele Firmen sich an der Kernel-Entwicklung beteiligen, heißt das nicht dass sie das als "sinnvolles Gemeinschaftsprojekt" sehen und ansonsten einen eigenen Kernel schreiben würden. Der Kernel ist deren (nicht ausschließliche) Einnahmequelle.

----------

## mv

 *astaecker wrote:*   

> Die Dateisystem-Rechte sind eine gute Grundlage, bieten aber keine feingliedrigere Rechtevergabe.

 

Es wäre billig, beim Einloggen und Ausloggen in X die Rechte passend zu ändern. Für die wenigen Szenarien, die noch feinere Rechte benötigen gibt es ACL.

Die richtige Lösung wäre, mit diesen Mitteln zu arbeiten statt Ressourcen zu verpulfern.

 *Quote:*   

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

 

Eben. Zwei parallel laufende Root-Dämonen, die an der selben Sache herumpfuschen und somit vermutlich hervorragende Angriffsvektoren (race conditions u.ä.) bieten.

 *Quote:*   

> Beides macht ihn für mich nicht zu einem Kernentwickler.

 

Wer letztlich die Programmierarbeit macht, ist in diesem Zusammenhang ziemlich egal. Das Hauptproblem ist die zugrundeliegende Fehlkonzeption, und die klingt gerade nach dem üblichen Lennart-Zugang ("Um es sauber hinzubekommen, müsste man viele Programmen ändern - nö, machen wir nicht. Statt dessen hacken wir mal einen Daemon hin, mit dem es auf die Schnelle geht, auch wenn es Ressourcen frisst. Hmmm, jetzt muss man es doch in vielen Programmen ändern. Naja, dann ändern wir halt doch die Programme. Aber natürlich nicht so, dass sie es sauber machen, sondern den Daemon-Hack benutzen.")

 *Quote:*   

>  *mv wrote:*    *Quote:*   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.

 

Genauso würde es Sinn machen, die Lokalisierung überall unter /etc/conf.d zu finden. Warum sollte man - wenn man distributionsabhängig vereinheitlichen will - gerade die hackischste Lösung (Daemonen) nehmen, wenn es funktionierende gute gäbe?

 *Quote:*   

> Das Journal ist optinal.

 

Wie oben beschrieben: Noch.

Und implizit stimmst Du also auch zu, dass das Geraffel vielleicht gerade dann noch akzeptabel ist, wenn man es ausschalten kann. Dann sollte es zuallererst einmal gar nicht programmiert werden.

 *Quote:*   

>  *mv wrote:*    *Quote:*   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. 
> ...

 

Das hat mit der Tatsache, dass das Programm gegen den Willen des Administrators überall herumpfuscht genau was zu tun?

 *Quote:*   

>  *Quote:*   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.

 

Das hatte ich schon mehrmals beschrieben: Durch sauberes Konfigurieren - das allerdings aufwändig sein kann und u.U. das Patchen mehrerer Programme bedeutet - kann man praktisch alle Daemonen vermeiden. Aber anstatt an einer solchen sauberen Lösung zu arbeiten, konzentriert sich systemd ausschließlich auf die Pfusch-Lösung.

----------

## astaecker

 *franzf wrote:*   

> Lol? systemd stammt von EINER Person, die für EINE Firma arbeitet. Da andere Projekte dieser EINEN Person sich dermaßen tief in aktuelle Desktops gefressen haben, ist es ihm problemlos möglich, allen sein system aufs Auge zu drücken. Das hat nix mit Gemeinschaft zu tun, das ist Diktatur! (Evtl. das "D" in SystemD?)

 

Schön, dass ich deinen Morgen mit einem Lacher versüßen konnte  :Smile: 

Lennart hat nur Avahi, PulseAudio und systemd initiiert. Bei anderer Middleware - udev, udisks, upower, ConsoleKit, PolKit - ist nicht sein "Mist". Außerdem ist es schon ziemlich dreist, ihn als Diktator zu bezeichnen, nur weil er Code schreibt und andere (wer auch immer) nicht.

 *franzf wrote:*   

> Ohne Linux-Kernel hätte man kein Linux, damit auch keine Linux-Distribution. Nur weil viele Firmen sich an der Kernel-Entwicklung beteiligen, heißt das nicht dass sie das als "sinnvolles Gemeinschaftsprojekt" sehen und ansonsten einen eigenen Kernel schreiben würden. Der Kernel ist deren (nicht ausschließliche) Einnahmequelle.

 

Es gibt noch andere Distributionen (BSD, Solaris, usw.), so dass Linux als Kernel schon eine Entscheidung der jeweiligen Distribution ist.

----------

## schmidicom

Ich glaube hier verrennen sich einige in etwas.

Das Problem ist doch eigentlich weniger das systemd diese Funktionalitäten anbietet sondern eher das manche andere Entwickler zu faul (oder was auch immer der Grund sein mag) sind dem Enduser die Wahl zu lassen ob er davon auch Gebrauch machen will oder eben nicht.

[ACHTUNG: Persönliche Behauptung]

Bestes Beispiel ist ja udisks das zwingend polkit (und somit auch consolekit und und und...) erfordert obwohl viele Enduser die daraus resultierend Möglichkeiten zur Feingliederung der Rechte gar nicht benötigen würden. Viele wollen doch einfach nur die Möglichkeit ein Volumen per Mausklick zu mounten ohne eine Konsole aufrufen zu müssen.

Die Entwickler hätten ja udisks so programmieren können das es auch ohne polkit funktionieren wurde und dann wenn es denn so installiert würde einfach alle darin enthaltenen Aktionen jedem User erlaubt der beispielsweise in der UNIX-Gruppe "disk" Mitglied ist.

[/ACHTUNG: Persönliche Behauptung]

----------

## mv

 *schmidicom wrote:*   

> Bestes Beispiel ist ja udisks das zwingend polkit (und somit auch consolekit und und und...) erfordert obwohl viele Enduser die daraus resultierend Möglichkeiten zur Feingliederung der Rechte gar nicht benötigen würden. Viele wollen doch einfach nur die Möglichkeit ein Volumen per Mausklick zu mounten ohne eine Konsole aufrufen zu müssen.
> 
> Die Entwickler hätten ja udisks so programmieren können das es auch ohne polkit funktionieren wurde und dann wenn es denn so installiert würde einfach alle darin enthaltenen Aktionen jedem User erlaubt der beispielsweise in der UNIX-Gruppe "disk" Mitglied ist.

 

Genau das ist der Punkt: Die vermeintlich freie Software ist nämlich nicht wirklich frei. Zwar steht es theoretisch jedem frei, udisks umzuprogrammieren, aber in der Praxis ist ohne dauerhafte Geldgeber ein solcher Versuch sinnlos, weil man diese Software dann dauerhaft warten müsste, denn kein großes Projekt setzt auf ungewartete Software.

Dass udisks die obige Lösung nicht wählt, liegt ziemlich wahrscheinlich nicht an der "Faulheit" der udisks-Programmierer oder dass sie keine Patches für diese Änderung bekämen, sondern an der Politik. Ob jetzt Poettering persönlich dahintersteckt oder irgendjemand anderes von Redhat kann ich nicht sagen, aber es ist seit geraumer Zeit offensichtlich, dass Möglichkeiten, die Poettering-Daemonen zu umgehen, politisch sehr geziehlt ausgeschaltet werden.

----------

## mv

 *astaecker wrote:*   

> Lennart hat nur Avahi, PulseAudio und systemd initiiert. Bei anderer Middleware - udev, udisks, upower, ConsoleKit, PolKit - ist nicht sein "Mist".

 

Das ist nicht so klar. Die ausführenden Programmierer sind nicht unbedingt die Initiatoren. Aber ich will durchaus zugestehen, dass es möglich ist, dass nicht Poettering selbst sondern irgendjemand anderes (oder gar eine Programmierer-"Kommission" bei Redhat) diese Fehlkonzepte verbrochen hat. Allerdings vertritt Poettering sie öffentlich ziemlich massiv und scheint deshalb der richtige "Ansprechpartner" dafür zu sein.

----------

## schmidicom

Ich wollte mal systemd antesten (um noch besser darüber jammern zu können  :Wink:  ) doch installiert bekomme ich es nicht wirklich wegen einem udev update mit einem seltsamen block:

```
# emerge --update -av udev

                                                                                                                   

These are the packages that would be merged, in order:                                                              

                                                                                                                       

Calculating dependencies... done!                                                                                          

[ebuild     U ~] sys-fs/udev-194 [171-r6] USE="acl%* gudev hwdb openrc%* -doc% -introspection -keymap (-selinux) -static-libs% (-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%*) (-floppy%) (-rule_generator%*) (-test%)" 1,378 kB                 

[ebuild  N    ~] sys-fs/udev-init-scripts-16  5 kB

[blocks B      ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-16)

Total: 2 packages (1 upgrade, 1 new), Size of downloads: 1,383 kB

Conflict: 1 block (1 unsatisfied)

!!! Multiple package instances within a single package slot have been pulled

!!! into the dependency graph, resulting in a slot conflict:

sys-fs/udev:0

  (sys-fs/udev-171-r6::gentoo, installed) pulled in by

    <sys-fs/udev-185 required by (net-wireless/bluez-4.99::gentoo, installed)

  (sys-fs/udev-194::gentoo, ebuild scheduled for merge) pulled in by

    >=sys-fs/udev-187 required by (sys-fs/udev-init-scripts-16::gentoo, ebuild scheduled for merge)

It may be possible to solve this problem by using package.mask to

prevent one of those packages from being selected. However, it is also

possible that conflicting dependencies exist such that they are

impossible to satisfy simultaneously.  If such a conflict exists in

the dependencies of two different packages, then those packages can

not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man

page or refer to the Gentoo Handbook.
```

Wie kann man das lösen?

----------

## franzf

bluez aus testing installieren.

----------

## Dr. Strangelove

 *schmidicom wrote:*   

> ... doch installiert bekomme ich es nicht wirklich wegen einem udev update mit einem seltsamen block:
> 
> [blocks B      ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-16)
> 
> ...
> ...

 

Der erste Block löst sich mit einem zwischenzeitlichen "emerge -C udev", da du udev-171-r1 installiert hast und das udev-194 will nun das paket udev-init-scripts, aber erst ab der Version udev-186 wurden diese scripts herausgelöst. Dieser Block vermeidet file-collisions.

Der zweite Block löst sich mit dem emerge von bluez-4.101-r3, du hast bluez-4.99 installiert, das will aber ein udev kleiner als 185.

Ach ja, weil ich es mir nicht verkneifen kann, der Oberlehrer im Fach Gentoo (eher wohl Englisch und Mathe) würde sagen: "Sechs, setzen bitte!"  :Very Happy: 

Anekdotisch dazu, unser Lehrer in Mathe hatte tatsächlich Karten mit den Zensuren 1-6 in der Brusttasche seines Hemdes, und musste er einmal diese böse Zensur vergeben, zog er sie heraus und sagte "Sie wissen, welcher Spruch jetzt kommt!"

----------

## Josef.95

 *Dr. Strangelove wrote:*   

>  *schmidicom wrote:*   ... doch installiert bekomme ich es nicht wirklich wegen einem udev update mit einem seltsamen block:
> 
> [blocks B      ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-16)
> 
> ...
> ...

 

Hm nein, das deinstallieren von udev sollte nicht nötig sein (ich würde auch davon abraten). Sofern die geforderten Abhängigkeiten bezüglich bluez erfüllt werden können nimmt portage das udev Upgrade selbst vor, da dann der Block gar nicht erst entsteht.

Sprich, geforderte Abhängigkeiten erfüllen - und dann ganz normal aktualisieren sollte problemlos funktionieren.

Edit sagt, das schaut dann zb so aus: 

```
# emerge -av1 udev bluez

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] sys-apps/kmod-10  USE="tools zlib -debug -doc -lzma -static-libs" 0 kB

[uninstall     ] sys-apps/module-init-tools-3.16-r1  USE="-static" 

[blocks b      ] sys-apps/kmod ("sys-apps/kmod" is blocking sys-apps/module-init-tools-3.16-r1)

[blocks b      ] sys-apps/module-init-tools ("sys-apps/module-init-tools" is blocking sys-apps/kmod-10)

[ebuild  N     ] sys-fs/udev-init-scripts-16  0 kB

[ebuild     U  ] sys-fs/udev-194 [171-r6] USE="acl%* gudev hwdb keymap openrc%* -doc% -introspection (-selinux) -static-libs% (-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%*) (-floppy%) (-rule_generator%*) (-test%)" 0 kB

[blocks b      ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-16)

[ebuild  N     ] net-wireless/bluez-4.101-r3  USE="alsa consolekit cups gstreamer readline -debug -pcmcia (-selinux) -test-programs -usb" 0 kB

Total: 4 packages (1 upgrade, 3 new, 1 uninstall), Size of downloads: 0 kB

Conflict: 3 blocks

Would you like to merge these packages? [Yes/No] n

Quitting.
```

----------

## schmidicom

Das mit bluez hat geholfen, sorry habe das irgenwie übersehen, und das neue udev ist nun drauf zusammen mit systemd.

Leider bootet mein Gentoo damit nicht vollständig, ein par dinge scheinen da noch unzufrieden zu sein.

```
#systemctl --all --full

UNIT                        LOAD    ACTIVE    SUB

auditd.service              error   inactive  dead

display-manager.service     error   inactive  dead

plymouth-quit-wait.service  error   inactive  dead

plymouth-start.service      error   inactive  dead

syslog.service              error   inactive  dead

systemd-logind.service      loaded  failed    failed

dbus.socket                 error   inactive  dead
```

Das grösste Problem hier dürfte wohl der dbus sein da dieser heutzutage ja von so ziemlich allem gebraucht wird.

EDIT:

Nach einem neubauen von dbus ist es nur noch das:

```
#systemctl --all --full

UNIT                        LOAD    ACTIVE    SUB

auditd.service              error   inactive  dead

display-manager.service     error   inactive  dead

plymouth-quit-wait.service  error   inactive  dead

plymouth-start.service      error   inactive  dead

syslog.service              error   inactive  dead
```

----------

## franzf

Dann schau mal, wer diese ".service" files installiert (sollten in /usr/lib64/systemd/* liegen), und bau die Pakete neu - vielleicht geht es ja dann wie nach dem dbus-Neubau.

 *Quote:*   

> Das grösste Problem hier dürfte wohl der dbus sein da dieser heutzutage ja von so ziemlich allem gebraucht wird.

 

Allerdings, vor allem baut systemd selber auf dbus auf, weshalb mMn. gar nichts funktionieren dürfte ohne gestartetem dbus. (aus dem Grund lass ich auch die Finger von systemd...)

----------

## schmidicom

Das mit dem displaymanager habe ich nun auch hinbekommen womit nun eigentlich alles da ist was ich zum Arbeiten normalerweise brauche.

Somit kann ich schon mal mein erstes Fazit abgeben zu systemd:

Es wird wohl einige Zeit brauchen um sich daran zu gewöhnen aber in Sachen Schnelligkeit wurden scheinbar keine leeren Versprechungen gemacht. Alles was ich jetzt noch sehe beim einschalten des Laptops ist das Lenovo Logo vom UEFI und 1 Sekunde später springt mir auch schon der KDM entgegen.   :Shocked: 

 *franzf wrote:*   

> Dann schau mal, wer diese ".service" files installiert (sollten in /usr/lib64/systemd/* liegen), und bau die Pakete neu - vielleicht geht es ja dann wie nach dem dbus-Neubau.
> 
>  *Quote:*   Das grösste Problem hier dürfte wohl der dbus sein da dieser heutzutage ja von so ziemlich allem gebraucht wird. 
> 
> Allerdings, vor allem baut systemd selber auf dbus auf, weshalb mMn. gar nichts funktionieren dürfte ohne gestartetem dbus. (aus dem Grund lass ich auch die Finger von systemd...)

 

Diese ".service"-Dateien die von "systemctl --all --full" als fehlerhaft aufgelistet werden existieren gar nicht. Plymouth habe ich nie installiert und werde ich auch nicht, keine Ahnung wieso diese auf der Liste auftauchen.

"display-manager.service" existiert in inzwischen aber auch nur wegen dem hier http://en.gentoo-wiki.com/wiki/Systemd#KDM.

EDIT:

Ich glaube ich weis jetzt wieso er auf der Liste nach nicht existierenden ".service"-Dateien schreit. Diese finden sich in anderen bereits existierenden ".service"-Dateien wie in dem vom KDM weiter oben.

EDIT2:

Jetzt ist es nur noch das:

```
UNIT                           LOAD   ACTIVE   SUB       JOB DESCRIPTION

auditd.service                 error  inactive dead          auditd.service

plymouth-quit-wait.service     error  inactive dead          plymouth-quit-wait.service

plymouth-quit.service          error  inactive dead          plymouth-quit.service

plymouth-start.service         error  inactive dead          plymouth-start.service
```

Da ich Plymouth nicht habe und auch nicht brauche ignoriere ich diese in Zukunft einfach aber das mit Audit muss ich noch genauer ansehen.

EDIT3:

Der Geist der rund alle 5 Sekunden lesend auf meine Festplatte zugegriffen hat scheint nun auch das weite gesucht zu haben, schon über eine Minute und der Systemmonitor vom KDE zeigt keinen Lesezugriff an.

EDIT4:

So mein kleiner Ausflug in die Welt von systemd ist nun nach fast zwei Tagen vorbei.

Schneller als OpenRC ist systemd auf jeden Fall und so weit ich das feststellen konnte funktioniert es auch genau so wie sollte. Unangenehm sind jedoch die Abhängigkeiten wie zum Beispiel dbus aber da eben selbiger sowieso bei den meisten installiert sein dürfte ist das wohl kaum so tragisch. Und das systemd mit seinem Journal auch gleich das syslog an sich reist ist wohl Geschmacksache funktioniert aber ebenfalls genau so wie es wohl gedacht ist. Schön ist das hier das jedem aufgezwungene consolekit weiterentwickelt wird und das es weder die Leistungsfähigkeit von systemd noch vom Rest negativ beeinflusst.

Am Ende muss ich sagen das ich mit systemd leben könnte aber aufgrund mangelnder Unterstützung seitens der ebuild-Schreiber oder Devs der Softwarepakete ist es im Moment unter Gentoo kein brauchbares init.

----------

## franzf

 *schmidicom wrote:*   

> Am Ende muss ich sagen das ich mit systemd leben könnte aber aufgrund mangelnder Unterstützung seitens der ebuild-Schreiber oder Devs der Softwarepakete ist es im Moment unter Gentoo kein brauchbares init.

 

Und genau das darf ich gerade erleben.

Hintergrund: https://bugs.gentoo.org/show_bug.cgi?id=463172

Es ist übel wenn man dem schlafenden Laptop den Stecker zieht und der nach dem Resume immer noch das "AC" Profil verwendet, obwohl mittlerweile auf Battery (fängt bei der Bildschirmhelligkeit an und endet beim ausbleibenden automatischen suspend)

Bei meinem letzten Versuch mit systemd gingen die alten initscripts noch - net, ssh etc. wurden automatisch gestartet. Diesmal: Nix!

```
# /etc/init.d/net.net0 start

 * WARNING: net.net0 is already starting

```

Ich musste einen anderen Rechner bemühen um herauszufinden, wie ich das Problem löse. Dazu hab ich ersmal schauen müssen, wie ich manuell per ifconfig + route mein Netzwerk aktiviere (hab ich mich nie drum geschert - Gentoo Doku, config anpassen -> Netzwerk mit static IP steht).

Jetzt hab ich Netzwerk aber immer noch kein sshd - dafür muss ich natürlich einen eigenen service schreiben, schauen wie man sshd startet usw.

pm-utils laufen nicht (k.A. wie und ob und vllt. gibts ja auch Konflikt mit systemd - das kümmert sich nämlich schon teilweise um PM-Sachen...) Einen service geschrieben, der mir "/sbin/hdparm -B 255 /dev/sda" ausführt damit meine hdd nicht so schnell kaputt geht... (wichtig: ExecStart erwartet absolute Pfadangaben, bei relativen Pfaden sagt er nur "Service erwartet ExecStart - und das fehlt hier!" - irreführende Meldung, 6, setzen...) Funktionieren tut es aber nur nach "Suspend" (Ich hätte ehrlich gesagt ein resume.target erwartet und nicht ein "After=suspend.target" - unintuitiv);  nach dem Systemstart geht's nicht - aber da macht scheinbar systemd selber was, denn standardmäßig stellt sich die Platte auf "-B 128", nach dem Systemstart sagt es "254", ich will "255".

Nächstes Problem "Customization". Mit initscripten hat man immer schöne configs. Passen einem die Defaults nicht, ändert man die configs. In systemd muss man jetzt das anzupassende service-file von /usr/lib/systemd nach /etc/systemd kopieren und anpassen. Toll... Wenn sich das system-service-file ändert darf ich jetzt mit diff schauen wo (falls ich die Änderung überhaupt mitbekomme) und die Änderungen übertragen.

Größtes Problem: Abhängigkeiten.

Ich muss mir überlegen was mein service alles braucht. Noch schlimmer: ohne passender Anweisung in [Install] lässt er sich gar nicht aktivieren. Und an dem Punkt versteh ich auch die Doku nicht mehr :/ Ich kann mir z.B. irgend einen Fantasie-Alias überlegen, den angeben und mein service startet. Ist das sauber? k.A., ich denke nicht.

Bei network ist es klar (Alias=network.target) was mach ich aber mit ssh? Alias "telnet" ausdenken? Mein service "openssh.service" nennen und nach "ssh" aliasen? WantedBy/RequiredBy/Also machen einfach keinen Sinn, ICH bin es der das Ding braucht, kein anderer Service...

Und scheinbar ist die Fehleranalyse in [Unit]->After etc. ungenügend falls überhaupt vorhanden. Ich kann da reinschreiben was ich will, es gibt nicht mal ein warning, dass die Abhängigkeit nicht existiert. (So geschehen bei dem kleinen Schreibfehler für mein kdm.service)

Mit openrc musste ich mich einmal hinsetzen, Doku lesen, configs bearbeiten, rc-update add und alles lief. Evtl. beim etc-update nachgeschaut, wenn größere Änderungen anstanden. Jetzt muss ich zum init-Versteher mutieren. Ich muss (syntaktisch sicher einfachere) init-scripte schreiben. Mir über Abhängigkeiten Gedanken machen.

Das ist sicher zum großen Teil der mangelnden Unterstützung in Gentoo zu verdanken. Trotzdem wäre ein minimum an alltäglich benötigten services in einer vanilla-systemd-Installtion nicht schlecht. Oder braucht Poettering kein ssh? network kommt bei ihm sicher von NetworkManager, sollte aber nicht vorausgesetzt werden.

Ich würde systemd sofort wieder runterschmeißen! Aber ohne funktionierendem PM in kde komm ich aktuell nicht aus. Deshalb werde ich jetzt mit fehlender Funktionalität leben bis ich Zeit&Lust habe mich mit den fehlenden Sachen zu beschäftigen.

Danke, Lennart. Danke, KDE. Danke, Gentoo. Werden lustige und spannende Wochen...

----------

## schmidicom

Also bei mir werden Abhängigkeiten sauber aufgelöst, allerdings benutze ich auch keine initscripte aus openrc innerhalb von systemd. Und Netzwerkeinstellungen werden bei meinen Installationen tatsächlich mit dem networkmanager umgesetzt weil alles andere nicht oder nur mangelhaft funktionierte.

Aber mit all dem kann ich leben solange systemd auch wirklich schneller ist als das alte init.

----------

## franzf

 *schmidicom wrote:*   

> Aber mit all dem kann ich leben solange systemd auch wirklich schneller ist als das alte init.

 

Ist es hier nicht, bereits auf dem zweiten System (i3 SNB, ebenso auf dem i7 SNB)

Ich hab immer den Eindruck (jedenfalls liest es sich so) dass eine Umstellung auf SSD zum Anlass für eine Neuinstalation + Wechsel zu systemd genommen wird, und der schnellere Boot dann sysemd zugeschoben wird  :Wink: 

https://plus.google.com/u/0/107663298003289209275/posts/9XKaRKqsPY9

20 Sekunden von grub bis login. Auf ner SSD. Da bin ich hier gleich schnell (vllt. sogar schneller), mit HDD (5400rpm) + openrc - obwohl mein kernel unerklärlicherweise 9 Sekunden zum Starten braucht.

----------

## Beelzebub_

 *franzf wrote:*   

>  *schmidicom wrote:*   Aber mit all dem kann ich leben solange systemd auch wirklich schneller ist als das alte init. 
> 
> https://plus.google.com/u/0/107663298003289209275/posts/9XKaRKqsPY9
> 
> 20 Sekunden von grub bis login. Auf ner SSD. Da bin ich hier gleich schnell (vllt. sogar schneller), mit HDD (5400rpm) + openrc - obwohl mein kernel unerklärlicherweise 9 Sekunden zum Starten braucht.

 

Haha das ist ja mal witzig:

Das Testsystem mit Systemd befindet sich auf einer virtuellen Maschine. Jedes OS bootet in einer VM viel schneller - habe die Erfahrung mit WindowsXP auf meiner VM gemacht - Also bietet die Demonstration eh keine vergleichs relevanten Ergebnisse.  :Wink: 

----------

## schmidicom

 *franzf wrote:*   

> Ich hab immer den Eindruck (jedenfalls liest es sich so) dass eine Umstellung auf SSD zum Anlass für eine Neuinstalation + Wechsel zu systemd genommen wird, und der schnellere Boot dann sysemd zugeschoben wird 

 

Auch wenn das in einigen Fällen den Tatsachen entsprechen mag ist es doch ziemlich dreist dies jedem zu unterstellen der eine solche Aussage macht...

Ich persönlich habe lange vor dem ausprobieren von systemd auf SSD umgestellt und war damals schon ziemlich genervt davon das selbst Windoof auf der SSD schneller startete als Gentoo mit OpenRC. Damals versuchte ich sogar über rc.conf (rc_parallel) OpenRC dazu zu bringen mehrere Dienste gleichzeitig zu starten damit es endlich mal etwas schneller geht doch das Ergebnis war das Gentoo meistens gar nicht mehr startete. Und als ob das hochfahren mit OpenRC nicht schon lange genug dauern würde, wird man beim abschalten gleich nochmal auf die Geduldsprobe gestellt.   :Evil or Very Mad: 

EDIT:

Ich kann es kaum erwarten das ein offizielles baselayout erscheint welches openrc nicht mehr länger als Abhängigkeit drin hat.Last edited by schmidicom on Mon Apr 15, 2013 9:39 am; edited 1 time in total

----------

## py-ro

Und das die Systeme gefühlt in VMs schneller starten dürfte eher an den fehlenden BIOS Routinen liegen, Contorller initialisieren etc., das sparen die VMs sich.

----------

## franzf

@schmidicom:

Ich habe nicht behauptet dass es so wäre, sondern dass ich das Gefühl habe. Zusammen mit dem Smiley sollte es klar sein, dass die Aussage höchstens provokant gemeint war. Vor allem wollte ich meinen Frust abbauen...

Ich hab auch schon unterschiedliche Erfahrungen gehört. Manchen ging es so wie mir - kaum wahrnehmbare Steigerung, wenn überhaupt. Andere sprechen von Quantensprung. Liegt sicher an der Zahl der Dienste die man startet. network, ssh, cups, alsa, kdm. Keine Datenbanken oder sonstwas.

Mittlerweile geht übrigens alles. Ich schiebs auf den hohen Adrenalinspiegel... Wenn einem der nicht schlafen wollende (weil falsches Power-Profil) Laptop fast kurz vorm Blackout steht (alle Daten gespeichert - trotzdem geht da die Pumpe ganz schön), dann installiert man systemd, werkelt ewig rum und soll dann mal schnell was ausdrucken - und nix geht, während nach jedem boot/resume die Festplatte zum Klackern anfängt (nie wieder WD...) - puh  :Wink: 

Lösungen:

* stable openssh bringt ein systemd unit mit. Hab ich mich scheinbar vergreppt und die autocompletion hat nicht geklappt

* cups muss man sich aus testing ziehen.

* systemd-overlay bringt ein baselayout-systemd-2 mit, das NICHT openrc braucht.

Und jetzt läuft alles  :Smile: 

----------

## Erdie

Also wenn mich KDE zukünftig zwingt eine zentrale Systemkomponente zu installieren, die keine Textbasierten logs schreibt, werde ich KDE auch auf meinem letzen Rechner durch XFCE ersetzen. Und das alles nur um eine paar Sekunden Zeit zu sparen? Lächerlich  :Sad: 

----------

## firefly

 *Erdie wrote:*   

> Also wenn mich KDE zukünftig zwingt eine zentrale Systemkomponente zu installieren, die keine Textbasierten logs schreibt, werde ich KDE auch auf meinem letzen Rechner durch XFCE ersetzen. Und das alles nur um eine paar Sekunden Zeit zu sparen? Lächerlich 

 

Moment, bis jetzt ist AFAIK das "journal" von systemd nicht pflicht sondern eine optionale Komponente.

Und scheinbar lässt es sich auch deaktivieren (aktuell nur das logging an sich aber nicht den service, soll aber auf der TODO für journal stehen)

Reference: 

https://bbs.archlinux.org/viewtopic.php?id=149884

http://lists.freedesktop.org/archives/systemd-devel/2012-March/004773.html

----------

## franzf

KDE hat mich nicht gezwungen, systemd zu verwenden. Das ist "nur" ein bug der sicher gefixt werden kann.

Ich hab mir den Code kurz angeschaut und für mich entschieden, dass der switch zu systemd weniger aufwändig ist (was vllt. am Ende doch eine Fehleinschätzung war...).

Was passieren kann ist dass consolekit durch systemd-login ersetzt wird (gnome-3.8 hat nur noch Unterstützung für systemd/logind). Das soll aber auch ohne systemd als init funktionieren. (Da bin ich gespannt wie lange das gültig bleibt)

Übrigens bist du auch mit xfce oder lxde vor solchen Problemen nicht sicher, da systemd mittlerweile zu weit verbreitet ist und viele Entwickler nicht mehr schauen ob es ohne systemd auch noch geht. (so wird es jedenfalls bei meinem Problem sein  :Sad: )

----------

## schmidicom

Hätten die Devs vom alten init nicht geschlafen und währen auf die Bedürfnisse der DE's eingegangen wäre systemd nie so weit gekommen. Haben sie aber nicht, also ist ein anderer in die Bresche gesprungen. Und auch wenn dessen Umsetzung an einigen stellen "fragwürdig" ist so ist es dennoch nicht seine Schuld das andere seine Software als zwingende Abhängigkeit einsetzen.

Jetzt heißt es eben, überspitzt gesagt: Friss oder stirb!

----------

## franzf

Das Problem (Powermanagement vs openrc) kommt nur deshalb zustande, weil upower den Support für suspend als deprecated markiert hat. Stattdessen müssen dafür externe Tools verwendet werden - und das ist im aktuellen Fall systemd. Ich hab mir zwei Fragen gestellt: Warum existiert upower, wenn dann doch wieder jeder client im eigenen Code nach systemd/... fragen darf (macht die Abstraktion unsinnig, wenn am Ende doch die Arbeit beim Consumer hängen bleibt). Und warum muss suspend im init-system verankert sein? Früher gings doch wunderbar auch ohne...

Die Probleme, die auftauchen, wenn man nur noch gegen systemd entwickelt, haben nichts damit zu tun, dass die "alten init devs" geschlafen hätten (btw.: an welche Bedürfnisse hast du da gedacht?), sondern dass systemd alles mögliche an services implementiert und damit bisherige Lösungen (in meist inkompatibler Weise) ersetzt - und dem User nur in wenigen Fällen einen Weg zurück anbietet (z.B. beim Logging).

----------

## schmidicom

 *franzf wrote:*   

> Die Probleme, die auftauchen, wenn man nur noch gegen systemd entwickelt, haben nichts damit zu tun, dass die "alten init devs" geschlafen hätten (btw.: an welche Bedürfnisse hast du da gedacht?), sondern dass systemd alles mögliche an services implementiert und damit bisherige Lösungen (in meist inkompatibler Weise) ersetzt - und dem User nur in wenigen Fällen einen Weg zurück anbietet (z.B. beim Logging).

 

Ich hatte mal einen Link zu einer Seite wo ganze zwei A4 Seiten gefüllt wurden mit Gründen aber leider finde ich diesen nicht mehr (vermutlich war dieser Link in meiner alten Linksammlung vom Firefox die mir mal abhanden gekommen ist). Aber diese Seite hier ist auch nicht schlecht und sogar auf Deutsch:

http://ikhaya.ubuntuusers.de/2012/09/22/systemd-das-init-system/#Die-Vor-und-Nachteile-von-systemd

Es wurde doch z.B. immer wieder darüber geklagt das sogar die Unterschiede zwischen allen sysvinit basierenden Distributionen einfach so groß sind das es nahezu unmöglich sei ein Script für alle zu schreiben. Darüber hinaus ist sysvinit alleine scheinbar schlicht ungenügend (init kann ja nicht einmal Abhängigkeiten auflösen, siehe Link) weshalb noch solche Softwarepakete wie OpenRC drüber gestülpt werden müssen.

Ich vermute das eben solche Brüche unter anderem auch ein Grund darstellen warum manche Softwarefirmen keine allzu große Lust haben ihre Produkte auch auf Linux anzubieten da sie diese für jede Distribution (welche es ja so viele wie Sand am mehr gibt) einzeln anpassen müssten. ESET ist hier ein gutes Beispiel, die haben eine Antivirensuit für Firmen die aber unter vielen Distributionen (wie auch Gentoo) nicht funktioniert weil eben der entsprechende Hintergrunddienst vom jeweiligen init nicht gestartet wird. Und als Admin habe ich für meinen Teil echt besseres zu tun als den Initscripten hinterherzujagen.

----------

## Yamakuzure

 *schmidicom wrote:*   

> Aber diese Seite hier ist auch nicht schlecht und sogar auf Deutsch:
> 
> http://ikhaya.ubuntuusers.de/2012/09/22/systemd-das-init-system/#Die-Vor-und-Nachteile-von-systemd

 Vielen Dank dafür, sehr interessant zu lesen. Vor Allem der Abschnitt "Vergleich".  :Wink: 

----------

## mrsteven

 *firefly wrote:*   

> Moment, bis jetzt ist AFAIK das "journal" von systemd nicht pflicht sondern eine optionale Komponente.
> 
> Und scheinbar lässt es sich auch deaktivieren (aktuell nur das logging an sich aber nicht den service, soll aber auf der TODO für journal stehen)
> 
> Reference: 
> ...

 

Muss ich daheim gleich mal testen, vielleicht geht der Systemd-Logger auf meinem Raspberry Pi dann wenigstens etwas sparsamer mit dem Hauptspeicher um. Idealerweise sollte man den Journal-Daemon aber komplett deaktivieren können. Dass das momentan nicht geht, ist halt eine Folge des Alles-in-einem-Ansatzes von systemd.

----------

## schmidicom

Nur so als Info: Seit der Version 200 ist udev und systemd nun auch im ebuild vereint (heißt also das bei der Installation von systemd auch gleich ein udev drauf ist).

Schön ist auch das diese Vereinigung keine Meldung in "eselct news" wert war und erst nach dem Studium von virtual/udev ersichtlich wird, und ja das war gerade Sarkasmus.

----------

## Jean-Paul

 *schmidicom wrote:*   

> Nur so als Info: Seit der Version 200 ist udev und systemd nun auch im ebuild vereint (heißt also das bei der Installation von systemd auch gleich ein udev drauf ist).
> 
> Schön ist auch das diese Vereinigung keine Meldung in "eselct news" wert war und erst nach dem Studium von virtual/udev ersichtlich wird, und ja das war gerade Sarkasmus.

 

Verstehe ich jetzt irgendwie nicht.

Es sollte doch hinlänglich bekannt sein dass sytemd und udev eines ist (systemd == udev). Warum sollte man also udev aus sytemd extrahieren um es dann als Depends zu systemd wieder installieren ? Auf eine Meldung kann ich da verzichten.

Es zeigt vielmehr, dass der Spaß ein udev ohne systemd haben zu können auch bei Gentoo bald vorbei sein könnte. Wir werden dieses Zeug benutzen müssen, zumindest die Leute die einen DE verwenden (KDE, Gnome, ...).

Ich hoffe deshalb, dass eudev noch weiter gepflegt wird.

Jean-Paul

----------

## musv

Trotz meiner Lennart-Vorbehalte hab ich Systemd mal installiert. Hatte es zuvor ein paar Monate auf Arch getestet und stehe dem Teil eigentlich ziemlich positiv gegenüber. Die Gründe:

Es ist sauschnell. Auf meinem Atom-Notebook bootet es etwas schneller als OpenRC. Auf meinem Xeon seh ich praktisch das Starten der Services nicht mehr. Da kommt gleich nach dem Laden des Kernels der Login-Prompt.

Die System-Units sollten distributionsunabhängig funktionieren. Das sollte auch ein Vorteil für proprietäre Hersteller sein.

Es könnte stabiler als Scripte sein. Unter OpenRC hatte ich ab und zu mal den Fall, dass sich irgendwelche Sachen beim Runterfahren nicht beenden ließen und das System dann hängen blieb. Ich hab zumindest die Hoffnung, dass Systemd da etwas konsequenter ist. 

Nachteile bisher:

Wenn das System mal kracht und man sich mit einem Live-USB-Stick Zugang verschafft, hat man keinen Zugriff auf die Logs, da die von Systemd verwaltet werden. Hab noch nicht rausgefunden, wo Systemd die Dinger speichert. Und zusätzlich sind die auch in einem Binaryformat gespeichert und nicht als Text verfügbar.

Das System ist komplexer und erst mal schwerer zu durchschauen. Es gibt schon in der Basisausstattung eine Unmenge an Units. Bis man mal durchblickt, wofür das alles zuständig ist, vergeht einige Zeit.

Meiner Meinung nach könnte Systemd das erste Lennart-Programm werden, was bewusst auf meinem Rechner bleibt. Ein Problem unter Gentoo ist allerdings, dass man sich die Unit-Files (Socket-, Servicedateien), die die Start-Stop-Scripte ersetzen, mühsam aus irgendwelchen Wikis zusammenklauben muss. Bei anderen Distris, z.B. Arch sind die Dinger nach der Paketinstallation vorhanden. Weiß noch nicht, ob Gentoo die rausfiltert oder ob die anderen Distris die reinbasteln.

----------

## schmidicom

 *musv wrote:*   

> Wenn das System mal kracht und man sich mit einem Live-USB-Stick Zugang verschafft, hat man keinen Zugriff auf die Logs, da die von Systemd verwaltet werden. Hab noch nicht rausgefunden, wo Systemd die Dinger speichert. Und zusätzlich sind die auch in einem Binaryformat gespeichert und nicht als Text verfügbar.

 

Die Logs liegen in "/var/log/journal" und wenn die Live-CD ebenfalls ein systemd hat kann man sie mit "journalctl -D /path/to/journal" auch auslesen.

 *musv wrote:*   

> Das System ist komplexer und erst mal schwerer zu durchschauen. Es gibt schon in der Basisausstattung eine Unmenge an Units. Bis man mal durchblickt, wofür das alles zuständig ist, vergeht einige Zeit.

 

Jeder grundlegende Wechsel bringt eine grössere Umgewöhnung mit sich aber es stimmt schon bei einigen Units bin ich mir auch nicht ganz sicher wofür sie gut sind.

 *musv wrote:*   

> Ein Problem unter Gentoo ist allerdings, dass man sich die Unit-Files (Socket-, Servicedateien), die die Start-Stop-Scripte ersetzen, mühsam aus irgendwelchen Wikis zusammenklauben muss. Bei anderen Distris, z.B. Arch sind die Dinger nach der Paketinstallation vorhanden. Weiß noch nicht, ob Gentoo die rausfiltert oder ob die anderen Distris die reinbasteln.

 

Ich glaube nicht das Gentoo die herausfiltert aber eigentlich sollten ja die Devs der zu installierenden Software solche Units liefern und nicht die Distribution erst recht jetzt wo jede Distribution das selbe Unit verwenden kann.

----------

## cryptosteve

 *schmidicom wrote:*   

> Die Logs liegen in "/var/log/journal" und wenn die Live-CD ebenfalls ein systemd hat kann man sie mit "journalctl -D /path/to/journal" auch auslesen.

 

dann wäre es ja schön, wenn journalctl statisch gebaut wäre und man es ansonsten direkt aufrufen könnte ... irgendwie irritiert mich dieses binäre Log trotzdem.  :Smile: 

----------

## schmidicom

 *cryptosteve wrote:*   

> dann wäre es ja schön, wenn journalctl statisch gebaut wäre und man es ansonsten direkt aufrufen könnte ... irgendwie irritiert mich dieses binäre Log trotzdem. 

 

Wenn die Live-CD ein eigenes systemd hat muss das doch nicht statisch sein um die logs zu lesen?

----------

## cryptosteve

Stimmt, und wenn es auf dem System statisch ist, dann ist es völlig egal, um was für eine LiveCD es sich handelt ...

LiveCDs mit systemd dürften sich derzeit noch in Grenzen halten.

----------

## mrsteven

Man kann diesen systemd-Logger ja auch irgendwie dazu bringen, die Logmeldungen an einen vernünftigen Logger durchzureichen. Wird z.B. bei Arch auf dem Raspberry Pi so gemacht. In die Bloblogs habe ich bisher auch noch nie reingeschaut.

----------

## Yamakuzure

 *musv wrote:*   

> Nachteile bisher:
> 
> Wenn das System mal kracht und man sich mit einem Live-USB-Stick Zugang verschafft, hat man keinen Zugriff auf die Logs, da die von Systemd verwaltet werden. Hab noch nicht rausgefunden, wo Systemd die Dinger speichert. Und zusätzlich sind die auch in einem Binaryformat gespeichert und nicht als Text verfügbar.
> 
> Das System ist komplexer und erst mal schwerer zu durchschauen. Es gibt schon in der Basisausstattung eine Unmenge an Units. Bis man mal durchblickt, wofür das alles zuständig ist, vergeht einige Zeit.
> ...

 Ich würde da gerne noch einen hinzufügen:

Wenn ein Service automatisch neustartet, sollte etwas schiefgehen, ist man am Ar*ch wenn das X11 betrifft. 

So geschehen mit Arch-Linux unter VMWare. Die SVGA-VMWare Treiber sind dort FUBAR und der xdm service startet, xorg-server stürzt ab, der service startet neu, xorg-server stürzt ab, der service startet neu, xorg-server stürzt ab, der service startet neu, xorg-server stürzt ab, der service startet neu, xorg-server stürzt ab, der service startet neu, ...

... Das gab ein hübsches geblinke...

----------

## schmidicom

Im jedem Unit kann festgelegt werden ob systemd versuchen soll den Dienst neu zu starten oder nicht und daraus ergibt sich logischerweise das wohl weniger systemd und viel mehr der Unit-Schreiber Mist gebaut hat.

----------

## franzf

 *schmidicom wrote:*   

> Im jedem Unit kann festgelegt werden ob systemd versuchen soll den Dienst neu zu starten oder nicht und daraus ergibt sich logischerweise das wohl weniger systemd und viel mehr der Unit-Schreiber Mist gebaut hat.

 

So pauschal würde ich das jetzt nicht aburteilen.

Dass X crasht kommt nicht so oft vor. Falls es wirklich passiert ist es natürlich gut wenn der entsprechende Service (meist Login-Manager) automatisch neu startet - vor allem wenn man bedenkt dass dieser Service nicht von Otto-Normal-User gestartet werden kann und im schlimmsten Fall der User ausgesperrt wird, bis der Admin das repariert hat - meist nur weil irgend ein Programm (compositor z.B.) was unvorhergesehenes macht.

Ich denke systemd könnte da tatsächlich intelligenter sein. Wenn ein Service ohne manuellem Eingreifen (systemctl restart/stop/...) in einem bestimmten (konfigurierbaren) Zeitraum mehr als X-mal (konfigurierbar) crasht, soll er sich nicht mehr neu starten. z.B. 3 restarts in 15 Sekunden.

----------

## schmidicom

 *systemd.service auf freedesktop.org wrote:*   

> Restart=
> 
> Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. The service process may be the main service process, but also one of the processes specified with ExecStartPre=, ExecStartPost=, ExecStopPre=, ExecStopPost=, or ExecReload=. When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted. Timeouts include missing the watchdog "keep-alive ping" deadline and a service start, reload, and stop operation timeouts.
> 
> Takes one of no, on-success, on-failure, on-abort, or always. If set to no (the default) the service will not be restarted. If set to on-success it will be restarted only when the service process exits cleanly. In this context, a clean exit means an exit code of 0, or one of the signals SIGHUP, SIGINT, SIGTERM, or SIGPIPE, and additionally, exit statuses and signals specified in SuccessExitStatus=. If set to on-failure the service will be restarted when the process exits with an nonzero exit code, is terminated by a signal (including on core dump), when an operation (such as service reload) times out, and when the configured watchdog timeout is triggered. If set to on-abort the service will be restarted only if the service process exits due to an uncaught signal not specified as a clean exit status. If set to always the service will be restarted regardless whether it exited cleanly or not, got terminated abnormally by a signal or hit a timeout.
> ...

 

Damit müsste dann doch das gewünschte Verhalten erreicht werden können?

```
Restart=on-failure

StartLimitInterval=0

StartLimitBurst=3
```

----------

## musv

Hab grad ein paar neue Probleme mit systemd entdeckt:

Suspend hab ich in der logind.conf deaktiviert (HandleSuspendKey, HandleHibernateKey, HandleLidSwitch auf ignore). Trotzdem versucht systemd im KDE in den Sleep-Modus zu schalten.

cups läuft, zeigt mir den Druckdialog an und mindestens cups-pdf funktioniert (ausprobiert). Aber in die Administration komm ich nicht mehr rein. localhost:613 bleibt einfach ewig in der Ladeschleife.

pdnsd wird gestartet, aber das Netz (Networkmanager) bekommt trotzdem keine DNS-Einträge geliefert.

----------

## Finswimmer

Cups ist localhost:631

War das ein Tipfehler, oder hattest du wirklich den falschen Port?

----------

## schmidicom

Unter systemd wird cups normalerweise nur gestartet wenn ein Druckauftrag ansteht weshalb das Webinterface auch nur dann läuft. Mit "systemctl enable cups" kann man aber dafür sorgen das er nach dem hochfahren dauerhaft läuft.

----------

## musv

 *Finswimmer wrote:*   

> Cups ist localhost:631
> 
> War das ein Tipfehler, oder hattest du wirklich den falschen Port?

 

War ein Tippfehler. Hatte schon 631.

Und ja, cups ist gestartet

```
systemctl status cups

cups.service - CUPS Printing Service

   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled)

   Active: active (running) since Di 2013-05-14 00:24:01 CEST; 19min ago

 Main PID: 1679 (cupsd)

   CGroup: name=systemd:/system/cups.service

           └─1679 /usr/sbin/cupsd -f

Mai 14 00:24:01 miniding systemd[1]: Started CUPS Printing Service.

Mai 14 00:27:02 miniding systemd[1]: Started CUPS Printing Service.

Mai 14 00:27:32 miniding systemd[1]: Started CUPS Printing Service.

Mai 14 00:28:00 miniding systemd[1]: Started CUPS Printing Service.

Mai 14 00:30:14 miniding systemd[1]: Started CUPS Printing Service.

Mai 14 00:43:03 miniding systemd[1]: Started CUPS Printing Service.
```

----------

## schmidicom

Welche Version von CUPS hast du?

Wenn es "1.5.2-r4" ist versuch es mal mit der nächst grösseren "1.5.3", die hat neu ein USE Flag für systemd, und bei mir funktioniert "1.5.3" bis jetzt fehlerfrei.

----------

## fuchur

Hi

 *musv wrote:*   

> ...
> 
> ...
> 
> Nachteile bisher:
> ...

 Gerade gelesen, gibt noch ein paar bis zu schrotten der Hardware.

Das Teil gefällt mir auch immer besser (natürlich nur auf andern Leuten Rechnern  :Smile: )

http://www.linux-magazin.de/NEWS/Fedora-19-20-Logfile-Explosion-dank-Systemd-Syslog-und-Journald

MfG

----------

## musv

Cups hab ich zum Laufen bekommen. Hab das Fedora-Unit-File hergenommen. Der Rest funktioniert eigentlich auch soweit mittlerweile. Inzwischen nach ca. 1 Monat bin ich an dem Punkt angelangt, dass ich Systemd auch weiterhin verwenden werde. Konnte in meinem Nutzungsverhalten bisher keinen Nachteil gegenüber OpenRC feststellen. 

Tricky war das Schreiben der VDR-Unit. Das Gentoo-Init-Script ist eigentlich eine ganze Script-Orgie mit haufenweise Sicherheitsprüfungen. In der Unit hab ich dann nur die für mich notwendigen Befehle und Parameter reingepackt. Läuft soweit ganz stabil. 

NFS, Squash_Portage, Distcc, Pdnsd klappen auch.

Und um mal zur Abwechslung einen Vorteil von Systemd gegenüber OpenRC herzunehmen:

Vor ca. 2-3 Jahren nutzte ich noch rege Wake On Lan. "Irgendwann mal" funktionierte das einfach nicht mehr. Sämtliche Versuche, das wieder in Gang zu kriegen, blieben erfolglos. Ich schob die Schuld fälschlicherweise auf den Kernel. Als ich dann Systemd am Laufen hatte, funktionierte auch Wake On Lan wieder. Weiß nicht, was damals in OpenRC verschlimmbessert wurde.

Was ich nicht geschafft hab, ist denyhosts. D.h. ich hab es starten können. Aber da denyhosts auf /var/log/ssh.log zugreift, konnte es seine Funktion nicht mehr erfüllen. Und Syslog ans Systemd-Journal ranhängen wollte ich nicht. Lösung: Ich hab den SSH-Eingangs-Port in meiner Fritzbox auf 222 geändert und die Portleitung auf 22 erstellt. Damit hörten dann die SSH-Attacken auch auf. Denyhosts benötige ich nicht mehr.

----------

## schmidicom

Dieser Bug tritt nur auf wenn man mehr als einen Logdienst verwendet was meiner Meinung nach wenig sinn macht. Aber egal, der Bug wird sicher noch geschlossen werden und bis dahin ist er einfach zu umgehen.

Anderes Thema:

Hat schon mal jemand den Display Manager sddm aus dem qt Overlay ausprobiert?

Mir persönlich gefällt er sehr gut, er ist klein sieht gut aus und funktioniert mit systemd fehlerfrei. Schade ist nur das der KDE scheinbar noch nicht in der Lage ist den Computer über eine systemd-Session herunter zu fahren oder neu zu starten.

https://github.com/sddm/sddm/issues/3

----------

## fuchur

Hi

 *schmidicom wrote:*   

> Dieser Bug tritt nur auf wenn man mehr als einen Logdienst verwendet was meiner Meinung nach wenig sinn macht. Aber egal, der Bug wird sicher noch geschlossen werden und bis dahin ist er einfach zu umgehen.
> 
> ...
> 
> 

 Das siehst du glaube ich falsch. Wenn du denn Links in diesem Artikel zu den Bugreports folgst 

ist für mich eigentlich ersichtlich das dieses von systemd kommt und zwar von dem internen binarylogs.

Wenn ich das noch richtig in Erinnerung habe file defekt usw. Damit wird eine Fehlquelle aufgemacht die

es so noch nie gegeben hat, und was passiert eigentlich bei Festplatten Fehler oder ähnliches. Das ist 

nichts womit ich mich anfreunden kann, kenne auch noch ganz andere Fehler von Fedora oder Suse,

will das nicht und brauche das nicht.    

MfG

----------

## schmidicom

@fuchur

Ich habe den Artikel nochmal gründlich gelesen inklusive der beiden Updates und auch wenn systemd oder journald die Quelle des Problems sind so lässt sich das Problem dennoch temporär umgehen (Workaround) wenn neben journald kein weiterer Loger aktiv ist.

Hier wird wieder mal aus aus einer Mücke ein Elefant gemacht wie man so schön sagt, denn man kann wohl kaum erwarten das eine Software von solchem Umfang 100% fehlerfrei ist. Nicht mal die alte Geschichte mit init und OpenRC war immer zu 100% fehlerfrei also ist es wohl nicht zu viel verlangt hier etwas Verständnis aufzubringen und den Devs etwas Zeit zu geben um das Problem zu lösen.

----------

## mrsteven

 *schmidicom wrote:*   

> Hier wird wieder mal aus aus einer Mücke ein Elefant gemacht wie man so schön sagt, denn man kann wohl kaum erwarten das eine Software von solchem Umfang 100% fehlerfrei ist.

 

Der Umfang ist ja das eigentliche Problem. Ich weiß nicht, warum mir ein Init-System einen eigenen Logger aufzwängen muss. Da passiert dann genau so etwas.

----------

## fuchur

Hi

 *mrsteven wrote:*   

> 
> 
> Der Umfang ist ja das eigentliche Problem. Ich weiß nicht, warum mir ein Init-System einen eigenen Logger aufzwängen muss. Da passiert dann genau so etwas.

 

Genau so sehe ich das auch.

 *schmidicom wrote:*   

> 
> 
> ... denn man kann wohl kaum erwarten das eine Software von solchem Umfang 100% fehlerfrei ist. Nicht mal die alte Geschichte mit init und OpenRC war immer zu 100% fehlerfrei also ist es wohl nicht zu viel verlangt hier etwas Verständnis aufzubringen und den Devs etwas Zeit zu geben um das Problem zu lösen.

 

Erste einmal ob OpenRC oder andere gut getestete init alte Geschichten sind wird die Zukunft zeigen. Richtig andere init haben bugs, genauso wie Logger und

Displaymanager usw. und werden sie auch zukünftig habe. Wieso man das alles in ein Programm packen muss damit der eine das andere "mitreist" wenn eines nicht 

funktioniert oder bugy ist ist grossen quatsch. Ein init hat schlank zu sein und dienst zu starten und nicht mehr.

Und das booten abzubrechen wenn mal ein Dienst nicht starte oder etwas bugy ist macht natürlich auch sehr viel Freude auf fern gewarteten Systemen .... 

Wollte die die systemd benutzen mit dem Link auch nur auf das Problem aufmerksam machen diskutieren wollte ich systemd eigentlich nicht und klinke mich auch wider

aus.

MfG

----------

## schmidicom

Auch auf die Gefahr hin das ich hier jetzt was lostrete aber mich wundert es irgendwie das sich hier über das folgend verlinkte Thema noch keiner beschwert/ausgelassen hat, oder ist das einfach an mir vorbeigegangen?

http://www.golem.de/news/init-dienst-systemd-macht-kernel-vt-ueberfluessig-1311-103016.html

http://www.pro-linux.de/news/1/20526/patch-fuer-systemd-soll-kernel-vt-ueberfluessig-machen.html

Blogeintrag von David Herrmann selbst: http://dvdhrm.wordpress.com/2012/08/12/killing-off-config_vt/

EDIT:

Gut das Gentoo noch nicht ohne ein VT auf Kernelbasis auskommen muss denn die in Portage enthaltene Version 7 von kmscon stolpert noch über den Bug 98.  :Wink: 

https://bugs.gentoo.org/show_bug.cgi?id=490798

----------

## musv

Der Herr Herrmann mag ja mit allem Recht haben, was er als Argumente so anführt. 

Aber noch eine Komponente ins Systemd zu verlagern, kommt mir irgendwie bald so vor, als hätten wir 2 Kernel. Warten wir erst mal ab, was dabei rauskommt.

Ich hoffe nur, die lassen da irgendwas drin, wo man eine Art Notfallkonsole hat, auf die man kommt, wenn das X grad mal wieder meckert. Hatte mal ein zerschrottetes Arch-Linux zum Testen, bei dem ich es irgendwie hinbekommen hab, dass mit dem Start von X die Konsolen nicht mehr erreichbar waren. Tja, wenn dann mal X noch hängt, hat man damit ein ernstes Problem.

----------

## schmidicom

 *musv wrote:*   

> Aber noch eine Komponente ins Systemd zu verlagern, kommt mir irgendwie bald so vor, als hätten wir 2 Kernel. Warten wir erst mal ab, was dabei rauskommt.

 

Nun es könnte ja auch jemand agetty so erweitern das ähnlich wie kmscon ohne VT's aus dem Kernelspace in der Lage ist ein Terminal anzubieten. Dieses agetty könnte man dann auch in ein initrd packen falls ein Terminal vor dem Zugriff auf die HD unbedingt erforderlich ist. Aber vermutlich werden einige Devs, jetzt wo die Umsetzung dieser Idee als erstes bei systemd einfließt, eine solche Erweiterung von agetty aus Protest und Trotz ablehnen.

Das zumindest ist meine Befürchtung.

 *musv wrote:*   

> Ich hoffe nur, die lassen da irgendwas drin, wo man eine Art Notfallkonsole hat, auf die man kommt, wenn das X grad mal wieder meckert. Hatte mal ein zerschrottetes Arch-Linux zum Testen, bei dem ich es irgendwie hinbekommen hab, dass mit dem Start von X die Konsolen nicht mehr erreichbar waren. Tja, wenn dann mal X noch hängt, hat man damit ein ernstes Problem.

 

Wäre in so einem Fall der Zugriff über COM nicht die bessere Wahl, so wie es Herrman selbst auch vorschlägt?

----------

## Jean-Paul

 *schmidicom wrote:*   

> ... das sich hier über das folgend verlinkte Thema noch keiner beschwert/ausgelassen hat, ...

 

Weil es mittlerweile zu spät ist sich über irgendetwas zu beschweren.

 *musv wrote:*   

> Warten wir erst mal ab, was dabei rauskommt. 

 

Das war und ist das Problem. Eine handvoll "Upstream-Dev's" und 2-3 Distris haben sich praktisch Linux unter den Nagel gerissen indem sie Fakten schaffen und der Rest wartet mal ab, was so passiert. Und das jetzt schon seit mehr als 3 Jahren. Dabei ist doch sonnenklar was passiert. 

Ich warte eigentlich auch ab: bis mir Gentoo sagt ich muss es jetzt installieren - das unaussprechliche Ding mit dem "d" am Schluss.

----------

## cryptosteve

Was sollte man als Nicht-Entwickler auch tun als stillschweigend daneben zu stehen und abzuwarten? Selbst wenn ich persönlich etwas anderes nutze und versuche, mein ganzes Umfeld zu missionieren, so wird das nichts aufhalten. Und schon gar nichts, was technisch unterm Strich ja sogar ganz passabel tut.

Leid tun mir vor allem die Jungs drüben bei BSD ...

----------

## musv

 *cryptosteve wrote:*   

> Leid tun mir vor allem die Jungs drüben bei BSD ...

 

Wobei da ja nicht Systemd die Schuld hat. Vielmehr sehe ich das Problem da bei Projekten wie Gnome, die halt Systemd zur zwingenden Voraussetzung deklarieren.

----------

## Jean-Paul

 *cryptosteve wrote:*   

> Was sollte man als Nicht-Entwickler auch tun als stillschweigend daneben zu stehen und abzuwarten?

 

Na ich weiß nicht, ob man da so machtlos ist wie allgemein angenommen.

Das Einzige was eine Distri wirklich braucht, sind User. Ohne User, keine Distri. Man kann z.B. als Nicht-Entwickler eine Distri konsequent meiden.

Zu viele User konsumieren einfach nur (noch). Alles wird hingenommen, alles ist egal - es wir schon irgendwer, irgendwas machen und funktionieren tut ja auch alles.

Ja, und genau das passiert. 

 *cryptosteve wrote:*   

> Leid tun mir vor allem die Jungs drüben bei BSD ...

 

Ja BSD ist so eine Sache. Wegen systemd tun sie mir nicht leid. *BSD und Linux sind verschieden und die Init-Systeme müssen nicht zwingend kompatibel sein.

Dass ihnen bei mehr und mehr Projekten (Gnome, bald KDE?, ...) praktisch das Wasser abgegraben wird, weil dort nur noch Linux-Only entwickelt wird ist schlicht eine Schweinerei.

Aber ich befürchte, auch hier wird die Erkenntnis dann zu spät kommen.

----------

## Jean-Paul

 *musv wrote:*   

> Wobei da ja nicht Systemd die Schuld hat.

 

Ja das hat er schön eingefädelt, der Herr Pöttering. Bei allen möglichen und unmöglichen Anlässen erzählt er, dass systemd gut ist, dass (bisher nicht vorhandene) Probleme nur aufgezeigt werden und dass systemd ganz bestimmt an nichts die Schuld hat.

Der Einzige schuldige IST systemd. Kein systemd, keine Linux-Only Entwicklung, keine Probleme.

----------

## cryptosteve

 *musv wrote:*   

>  *cryptosteve wrote:*   Leid tun mir vor allem die Jungs drüben bei BSD ... 
> 
> Wobei da ja nicht Systemd die Schuld hat. 

 

Mir fehlt leider das Detailwissen um beurteilen zu können, ob man das nicht von Anfang an auch entsprechend portabel hätte bauen können. Es gab Zeiten, zu denen Portabilität mal ein Qualitätsmerkmal freier Software war.

----------

## ulenrich

Apropos "portabel"

Wer von euch (ge)braucht BSD? Andersrum wird ein Schuh: 

Wer hat sich nicht schon gewundert über die tausend Möglichkeiten des Linux Kernels. Aber auf der Benutzerseite kommt sowenig davon an, dass Windows immer noch überlegen ist? Portabilität führt halt dazu, dass nur der kleinste gemeinsame Nenner an Möglichkeiten eingesetzt werden kann. Wenn Linux gegenüber Windows und OsX glänzen soll, darf man keine Rücksichten auf das langsame Bsd nehmen, dass doch auch ganz andere Ziele hat?

Apropos "Einheitsbrei"

"Lsb" ist der Versuch eine kleinste gemeinsame Grundlage zu schaffen, auf der sich kommerzielle Hersteller bewegen können. LP schafft mit systemd eine breitere und performantere kleinste (hier vielleicht sogar größte) gemeinsame Grundlage. Das ist der Grund, warum Automotive und andere embedded Branchen auf den Zug springen.

Apropos "vertikalen Integration"

Vor genau einem Jahr war das Hauptargument gegen systemd sein Versuch der vertikalen Integration, was gegen die Unix Philosophie gerichtet sei. Es war hier im englischen Forum gemeint als Todesurteil gegen systemd. Ich aber sagte, dass diese Integration, die mit einer effektiven Erweiterung der kleinsten gemeinsamen Grundlage einhergeht, der Zündfunke sein wird für die allgemeine Annahme und  Benutzung durch Anwendungsentwickler.  Und diese bestimmen, wann systemd zwingend wird.

Apropos "Sicherheit"

Moniert wird die Vergrößerung der Angriffsfläche durch ein aufgeblähtes Initsystem. Dies ist aber eine Verkennung der Tatsache, dass heutige Linuxsysteme meist genauso große Angriffsflächen bieten, weil sie ähnliche Systemfunktionalitäten anbieten. Meist sind sie dann auch noch schlecht verkonfiguriert. Das soll sich durch systemd verbessern. Spannend wird es aber ab Mitte des Jahres 2014, wenn der Linux Kernel kdbus anbieten wird: die nötigen policies, die die erweiterten Einfallstore schließen sollen, sind noch nicht geschrieben!

Apropos "Technik"

Die technischen Meriten von systemd seien gar keine, weil man doch alles was systemd erreicht auch mit herkömmlichen Methoden bewerkstelligen könne. Der Debian Entscheidungsprozess hat festgestellt, dass es kein anderes Gpl Service System gibt, was systemd technisch überragt. Die Hauptargumente für Canonicals upstart waren nur von der Art "leichtere Pflege", weil es doch schon Ubuntu gibt kann man doch alles ohne viel Portierarbeit übernehmen... Das schlagende Argument für systemd war nicht Gnome. Es war die Möglichkeit mittels pthreads den systemd Ablauf debuggen zu können. 

Apropos schlechter Entwickler LP

Er hat anscheinend eine steile Lernkurve durchgemacht: Wenn man sich zur Zeit die Beurteilungen seiner "Peers" anschaut, erfährt man, dass er ein hervorragender "engineer" sein soll. Was über LP in unseren Foren steht, interessiert nichtmal eine relevante Minderheit von Gentoo Usern.

LP muss keine Tricks und Taktiken anwenden um systemd "durchzustechen". Zu ihm kommen die Entwickler, die auf systemd aufbauen wollen. Und es kommt der Linus Nachfolger in Spe, um kdbus als neuen Linux ipc Standard zu entwickeln. Auch die ersten Bedenken gegen ein orthogonales cgroups-v1 System im Linux kernel, wurden anscheinend erstmal mit LP besprochen vor einem Jahr. Davor hatten sich Sievers und LP gerade den Faupax geleistet Linus aufzuregen um die Firmware systematischer vom Kernel direkt laden zu lassen. (Gibt es eine höhere Weihe als den Zorn des Linus empfangen zu haben und zwar mit gewolltem Resultat?).  Im übrigen hat LP eine noch recht jugendliche Charakteristik seiner Persönlichkeit, die ausbaufähig ist. Seine Verteidigungsversuche erscheinen mir meistens ungeschickt und auch sowieso unnötig. Und wenn diese Verteidigungen auch noch sachlich ganz schräg liegen, ist das für systemd dann eher kontraproduktiv. Da ist sicherlich ein jugendliches Ungestüm am Werke, doch nicht eine allgemeine und ausgefuchste Konspiration. 

Opensource ist docracy. Daher ist LP im Moment der King. Und wer gegen den King aufbegehrt ist ein Rebell ? 

Der sollte aber im Gentoo Dschungel einen Platz finden ! 

Viele, die sich als Rebellen gebärden, sind es nur in ihrer Sprech ...

----------

## schmidicom

 *cryptosteve wrote:*   

> Leid tun mir vor allem die Jungs drüben bei BSD ...

 

Wieso sollte man ausgerechnet mit denen Mitleid haben?

Sie verweigern sich ständig neuen Technologien und blockieren dadurch immer wieder das vorankommen jener Projekte die wegen der Portabilität gezwungen sind ebenfalls darauf zu verzichten. Ich begrüsse es das einige Devs, darunter eben auch LP, da nicht nicht mehr länger mitmachen und diese neuen Technologien, unabhängig davon was die BSD'ler machen oder eben nicht machen, erfolgreich umsetzen.

Ein kleines Beispiel: Würde man immer und überall auf BSD Rücksicht nehmen gäbe es auch keinen Wayland denn der braucht KMS was BSD ja auch nicht hat.

----------

## cryptosteve

Hi ulenrich,

na, das war ja mal ab Abriß. Auch wenn ich Deine Einordnung in King und Rebellen nicht so recht nachvollziehen kann (für mich brauchts schon deutlich mehr, bis für mich jemand der King ist und wenn ich mal 'ne andere Meinung vertrete, sehe ich mich noch lange nicht als Rebell), so stimme ich Dir in den meisten Punkten zu.

Die Einschätzung, die BSDler würden sich fortlaufend neuen Technologien verweigern, kann ich hingegen nun gar nicht teilen. Zudem ist dabei auch immer das Problem, dass mit dem Durchsetzen einer neuen Technik nicht nur die neue Technik voranschreitet, sondern der bisherige Standard oft auch komplett verfällt. Ich denke allerdings, dass das Designkonzept von systemd hier nicht aufzuhalten ist und das sich die BSDler mittelfristig von Gnome und KDE auf dem "Desktop" verabschieden können.

----------

## SkaaliaN

Ich werde mir dieses Monster niemals auf meine Clients installieren. Der Preis meiner Freiheit ist mir in dem Fall egal.

----------

## Jean-Paul

 *ulenrich wrote:*   

> Daher ist LP im Moment der King.

 ...und er wird Kranke heilen, übers Wasser laufen und die Fluten teilen. Amen.

Dieser Messias und seine Helfer werden Linux an die Wand fahren.

 *metal1ty wrote:*   

> Der Preis meiner Freiheit ist mir in dem Fall egal.

  dto. Diese Einstellung und Reaktion hätte von viel viel mehr Usern kommen müssen.

----------

## frank9999

http://www.heise.de/open/meldung/Upstart-ade-Linux-Distribution-Ubuntu-wechselt-auf-Systemd-2114268.html

Somit stellt sich die Frage wie lange wir unter Gentoo noch die Möglichkeit haben NICHT auf systemd wechseln zu müssen...

----------

## franzf

 *schmidicom wrote:*   

> [Ein kleines Beispiel: Würde man immer und überall auf BSD Rücksicht nehmen gäbe es auch keinen Wayland denn der braucht KMS was BSD ja auch nicht hat.

 

Eine kleine Anwort:

Wayland läuft aktuell auch noch nicht auf Systemen mit proprietärem nvidia-driver. (kein KMS...)

Andererseits hat BSD seit über einem Jahr funktionierende intel-KMS-Treiber, nouveau und radeon wurden mittlerweile ebenfalls portiert. Und das alles (weit) bevor überhaupt ein einziger Desktop ordentlich mit Wayland läuft...

Und was bitte können die BSDs dafür, wenn sich die inux Grafik-Devs was neues einfallen lassen und die Entwickler der Grafiktreiber voll drauf stürzen? Es sind letztere, die nicht portabel programmiert haben...

Und bevor hier noch jemand über die rückschrittlichen, doofen, trolligen BSDs aufregt, sollten alle mal schauen, was auf ihrem Linux an Software läuft, die eigentlich aus dem BSD-Lager kommt... (also - abseits vom kernel).

Wg. KDE: Solange die ihre Abstraktionsschicht(en) (naja, eigentlich ist es ja nur solid...) beibehalten wird es möglich sein alternative Stacks jenseits von systemd zu verwenden.

----------

## cryptosteve

 *frank9999 wrote:*   

> http://www.heise.de/open/meldung/Upstart-ade-Linux-Distribution-Ubuntu-wechselt-auf-Systemd-2114268.html

 

Unglaublich!

Damit dürfte es allen weiteren Debian-Diskussionen dazu auch so ziemlich den Wind aus den Segeln nehmen.

Auch, wenn es mir grundsätzlich nicht passt, so muss man systemd hier doch eine allumfassend führende Rolle zusprechen. 

Glückwunsch, LP!  :Smile: 

----------

## ulenrich

 *metal1ty wrote:*   

> Ich werde mir dieses Monster niemals auf meine Clients installieren. Der Preis meiner Freiheit ist mir in dem Fall egal.

 

Einerseits: Viele werden die leichtere Verfügbarkeit von erweiterten Linux Fähigkeiten durch systemd als mehr Freiheit empfinden.

Andererseits: Wenn deine Anwendungsentwickler (und Desktop zB das kommende lxqt) auf systemd verzichten, wirst Du nie zu etwas gezwungen sein in Richtung systemd.

... Warum auch - jemals - sollte sich Gentoo als Meta Distribution die Freiheit selbst nehmen auch ohne systemd auskommen zu können. In der Endsumme gibt es durch systemd insgesamt mehr Freiheit, auch wenn von dir persönlich kleinere Freiheiten genommen werden, denn Du musst auf bestimmte Sachen verzichten, die vorher auch ohne systemd möglich waren.

----------

## cryptosteve

Naja, ein Einsatz ohne systemd ist wohl noch sehr lange möglich. Die Frage ist, wie aufwendig das auf Dauer wird, denn alle anderen Wege werden wohl zunehmend ungewarteter werden, init-Skripte werden fehlen, etc.

Ich bin nicht grundsätzlich Freund von systemd, aber wenn's denn funktioniert und sich durchsetzt, dann stört es mich auch nicht so sehr, dass ich ein Politikum daraus mache.

Sei's drum, ich denke, spätestens mit dem Wechsel von Ubuntu ist der Drops endgültig gelutscht.

----------

## ulenrich

 *cryptosteve wrote:*   

> Hi ulenrich,
> 
> na, das war ja mal ab Abriß. Auch wenn ich Deine Einordnung in King und Rebellen nicht so recht nachvollziehen kann (für mich brauchts schon deutlich mehr, bis für mich jemand der King ist und wenn ich mal 'ne andere Meinung vertrete, sehe ich mich noch lange nicht als Rebell), so stimme ich Dir in den meisten Punkten zu.

  Ja, 

dieses Bild hinkt natürlich wie jedes Bild. Und sowieso ist nicht unser User King gemeint, sondern alles bezieht sich auf die Entwicklergemeinde. Unsere Kings als User, die uns beherrschen, sind natürlich Gentoo Entwickler wie der kürzlich abgetretene ZacMedico, dessen Name wohl aber kaum einem einfachen User bekannt ist.

 *Quote:*   

> Die Einschätzung, die BSDler würden sich fortlaufend neuen Technologien verweigern, kann ich hingegen nun gar nicht teilen. Zudem ist dabei auch immer das Problem, dass mit dem Durchsetzen einer neuen Technik nicht nur die neue Technik voranschreitet, sondern der bisherige Standard oft auch komplett verfällt. Ich denke allerdings, dass das Designkonzept von systemd hier nicht aufzuhalten ist und das sich die BSDler mittelfristig von Gnome und KDE auf dem "Desktop" verabschieden können.

  Vielleicht haben die BSDler auch ganz andere Prioritäten und Ziele. Ich kenne mich mit BSD überhaupt nicht aus, außer dass es sich mehr wie aus einem Guß anfühlen soll, worauf ich neugierig wäre.

----------

## schmidicom

 *franzf wrote:*   

> Wayland läuft aktuell auch noch nicht auf Systemen mit proprietärem nvidia-driver. (kein KMS...)

 

Muss er auch nicht denn sonst könnte man auch gleich wieder zum X11 zurückkrebsen.

 *franzf wrote:*   

> Andererseits hat BSD seit über einem Jahr funktionierende intel-KMS-Treiber, nouveau und radeon wurden mittlerweile ebenfalls portiert.

 

Bist du dir sicher das diese portierten Treiber dem KMS von Linux ähnlich sind? So weit ich weiß läuft die ganze Grafik Geschichte bei BSD fast vollständig im Userspace über X11 ab.

 *franzf wrote:*   

> Und was bitte können die BSDs dafür, wenn sich die inux Grafik-Devs was neues einfallen lassen und die Entwickler der Grafiktreiber voll drauf stürzen? Es sind letztere, die nicht portabel programmiert haben...

 

Das ist wohl Ansichtssache.

Ich finde die Entwickler handeln richtig wenn sie diese neuen Möglichkeiten, unabhängig davon ob BSD jetzt mitmacht oder nicht, nutzen. Denn zuviel Portabilität kann auch sehr schnell kontraproduktiv sein/werden.

 *franzf wrote:*   

> Und bevor hier noch jemand über die rückschrittlichen, doofen, trolligen BSDs aufregt, sollten alle mal schauen, was auf ihrem Linux an Software läuft, die eigentlich aus dem BSD-Lager kommt... (also - abseits vom kernel).

 

Ich rege mich nicht über BSD auf und sage auch nicht das sie alles komplett falsch machen aber sie dürften gegenüber neuen Ideen und Entwicklungen aus der Linuxwelt etwas offener sein. Nur habe ich das Gefühl das manche von ihnen in Linux nach wie vor nicht anderes sehen als die Raubkopie von UNIX.

EDIT:

Ok scheinbar ist der KMS bei FreeBSD 9 angekommen aber so weit ich lesen konnte nur für Intel, erst ab Version 10 ist da auch Radeon drin. Doch bei den anderen BSD Systemen scheint es mit KMS noch ziemlich düster aus zu sehen, aber zumindest gibt es Hoffnung für sie.Last edited by schmidicom on Sat Feb 15, 2014 6:15 pm; edited 1 time in total

----------

## Jean-Paul

Also zunächst mal, Wayland läuft unter BSD.

 *schmidicom wrote:*   

> Ich finde die Entwickler handeln richtig wenn sie diese neuen Möglichkeiten, unabhängig davon ob BSD jetzt mitmacht oder nicht, nutzen. 

 Ich finde, Entwickler die glauben dass eine Abhängigkeit zu einem Init-System "neue Möglichkeiten" bedeuten, nicht ganz verstanden haben um was es eigentlich geht. Zu einem Init-System sollte rein gar kein Abhängigkeit bestehen - schon gar nicht, wenn es sich um Grafik-Bibliotheken handelt.

 *schmidicom wrote:*   

> ...aber sie dürften gegenüber neuen Ideen und Entwicklungen aus der Linuxwelt etwas offener sein. Nur habe ich das Gefühl das manche von ihnen in Linux nach wie vor nicht anderes sehen als die Raubkopie von UNIX.

  Aber das müssen sie doch gar nicht. systemd muss, soll und wird nicht unter BSD laufen. Die haben ihre eigenen Init-Systeme. Das Einzige was man erwarten kann ist, dass die "Linuxwelt" jetzt nicht anfängt alles, aber auch alles "Linux-Only" zu programmieren, weil es schlicht nicht nötig ist. 

Mit deinem letzten Satz gebe ich dir voll Recht. Weil das UNIX in Linux mehr und mehr verschwindet, kann man bestimmt nicht mehr von einer Raubkopie sprechen.

----------

## cryptosteve

Wenn man es mal objektiv betrachtet, haben wohl auch die großen Environments wie Gnome und KDE auch kein echtes Interesse mehr an alternativen unixoiden Systemen. In dem Moment, wo man sich für eine Bindung an systemd entscheidet, entscheidet man sich indirekt auch für Linux.

Ich sehe das Problem hier weniger bei LP und systemd (die machen jeweils das, was ihnen aufgetragen wird), sondern eher bei Gnome und KDE, die da bereitwillig folgen.

----------

## schmidicom

@Jean-Paul

Mein letzter Kommentar bezüglich BSD hatte eigentlich wenig mit systemd an sich zu tun und es ging mir eher um allgemeine Sachen die im Linux Kernel schon seit etlichen Versionen enthalten sind aber bei BSD nur zögerlich oder gar nicht angenommen werden, war also etwas OT. Aber das Wayland, oder besser der mitgelieferte Referenz-Compositor Weston (und scheinbar auch kwin gemäß Google-Suche), ab Version 1.4 zwingend systemd voraussetzen werden wusste ich bis jetzt noch gar nicht.

http://www.golem.de/news/displayserver-wayland-1-4-mit-subsurfaces-1401-104142.html

Das dürfte sich für denjenigen die systemd nicht nutzen wollen in Zukunft ziemlich negativ auswirken...

----------

## Jean-Paul

@schmidicom,

ich denke, ich habe dich schon verstanden. 

Der Punkt ist nur, dass sich die beiden Systeme die letzten 20 Jahre mehr oder weniger den Code geteilt hatten (ssh, xorg, gnome, kde, ...) und dies keine Probleme bereitet hat. Diese gemeinsame Code-Basis ist durch systemd extrem gefährdet und das völlig grundlos. BSD interessiert es nicht, ob Linux systemd oder sonstwas einführt. Es betrifft sie aber, wenn hier alle anfangen zu spinnen und jede noch so unwichtige *lib glaubt künftig systemd als Depends haben zu müssen.

Was ich nicht verstehe; warum bist du der Meinung, dass BSD irgendetwas aus Linux, Kernel oder was auch immer, übernehmen sollte ?

BSD und Linux sind unterschiedliche Systeme. Sollte man das dann nicht auch von Microsoft oder Apple verlangen ?

Wenn ich es richtig verstanden habe, ist Weston der Compositer (Referenz) von Wayland, aber nicht DER Compositer der nötig ist um Wayland zu nutzen.

Und sollte es wirklich keinen Compositer geben der systemd-frei ist, ja dann gibt es halt kein Wayland auf meinem System.

----------

## schmidicom

 *Jean-Paul wrote:*   

> Was ich nicht verstehe; warum bist du der Meinung, dass BSD irgendetwas aus Linux, Kernel oder was auch immer, übernehmen sollte?

 

Weil durch das nicht aufnehmen von nützlichen Funktionen Devs, welche Software für beide Systeme programmieren, unter Umständen gezwungen werden kontraproduktive Kompromisse einzugehen die sich dann wiederum negativ auf alle auswirken die von deren Software Gebrauch machen.

Oder anders gesagt: "Man kann/sollte nicht auf allen Hochzeiten gleichzeitig tanzen."

----------

## Dorsai!

Das Problem ist doch, dass hier von den BSD Leuten nicht nur eine einfache Schnittstelle oder Lib implementiert werden müsste, die einen gewissen Funktionsumfang an KDE, Gnome oder eine beliebige andere Anwendung der oberen Schicht bereitstellt. Es müsste dieses ganze monolithische Monstrum systemd (von den BSD Downstream Devs!) portiert werden und mit was auch immer man selbst arbeiten möchte, müsste verworfen werden.

Dazu kommt, dass selbst das von den systemd Leuten nach Kräften erschwert würde, weil man sich in Richtung der unteren Schicht ja schon fest mit dem Linux Kernel verzahnt.

Ich verstehe einfach nicht wieso man das ganze nicht einfach so modular wie möglich gestaltet, nach der GNU Philosophie oder eigenen, aber festgeschriebenen Schnittstellen. Ich habe in meinem Studium und meiner Technikerausbildung gelernt, dass das einfach nur guter Programmierstil ist wenn man einzelne Teile so austauschbar macht wie möglich. Aber so wie das läuft kann ich für den Kurs von Poettering, RHEL und Co. nur politische Gründe vermuten.

----------

## ChrisJumper

Also ich bin immer noch sehr verwirrt was das Thema und den ärger um Systemd betrifft aber..

 *Dorsai! wrote:*   

> 
> 
> Ich verstehe einfach nicht wieso man das ganze nicht einfach so modular wie möglich gestaltet, nach der GNU Philosophie oder eigenen, aber festgeschriebenen Schnittstellen. Ich habe in meinem Studium und meiner Technikerausbildung gelernt, dass das einfach nur guter Programmierstil ist wenn man einzelne Teile so austauschbar macht wie möglich. Aber so wie das läuft kann ich für den Kurs von Poettering, RHEL und Co. nur politische Gründe vermuten.

 

..hier glaube ich halt das der Ansatz und Wunsch eben der ist, eine Einheitliche Administrationslösung zu bieten. Wenn man etwas über eine bestimmte Schnittstelle zusammen fassen möchten, müssen sich die Modularen austauschbaren Teile eben einem gewissen Rahmen unterordnen. Das ist hier halt einfach das was Systemd vorschreibt. Warum das alte Initsystem mit seinen Initscripten so anders und besser sein soll verstehe ich immer weniger.

Der aktuelle Grund meiner Meinung nach warum hier sich viele beklagen ist das andere Dienste, z.B. Syslog-ng und Co, sich noch nicht an Systemd angepasst haben und daher zu einem Mangel in der Bequemlichkeit, aber auch Risiken der Administration führt. Für Unstable Software ist das aber doch normal. Wie dem auch sei, das ist auch alles ärgerlich, aber eigentlich kein direkter Grund für mich dagegen zu sein.

 *Jean-Paul wrote:*   

> Wenn ich es richtig verstanden habe, ist Weston der Compositer (Referenz) von Wayland, aber nicht DER Compositer der nötig ist um Wayland zu nutzen.

 

Naja, aktuell glaube ich aber der einzige.. und auch der einzige der bisher unter Gentoo verfügbar ist. Heißt nicht das es so bleibt. Doch generell ist Wayland auch noch sehr in den Kinderschuhen. Ich hab ja einen anderen Thread aufgemacht weil ich auch neugierig bin ob ich mein Xorg so langsam lösen kann.

----------

## Dorsai!

Die Leute haben kein Problem mit der Diensteverwaltung systemd. Die Leute haben ein Problem damit, dass sich systemd zum einzigen möglichen monolithischen Systemunterbaublob entwickelt und versucht alles unmodular und unaustauschbar in sich zu vereinen was auch in irgendeiner Form zur Userland Systemseite gehört.

Ich finde es einfach sehr bedenklich, dass systemd diese starken Abhängigkeiten in beide Richtungen der Abstraktion forciert.

Wenn systemd nur ein Dienstestarter wäre, dann müssten sich wohl kaum Gnome, KDE, Wayland, etc. von systemd abhängig machen.

Auch im umgekehrten Fall... was wenn eine Distro nur udev, policykit, consolekit aus systemd verwenden will? Bei udev geht es ja noch es aus den systemd Quellen herauszulösen, aber bei consolekit und policykit ist man auf die uralten versionen angewiesen die vermutlich etliche sicherheitslücken aufweisen, weil die aktuellen versionen bereits so fest mit systemd verdrahtet sind.

Mein Blick in die Zunkunft:

-Alle Linux Distros nützen entweder systemd oder keine grafische Oberfläche und dynamische Hardwareverwaltung (also maximal ein verzicht auf systemd im Embedded Bereich möglich)

-BSDs und andere Unixe vewenden weder Wayland noch moderne DEs und werden dadurch auf dem Desktop vollständig unbenutzbar

----------

## Fijoldar

Ein einheitliches Init-System in Linux Distriubtionen wäre in meinen Augen aber eher erstrebenswert. Ich fand es früher furchtbar, wenn man mal eine andere Distribution bedienen musste und wusste nicht welches Init System gerade läuft und wie man es bedient. Jetzt, da sich Systemd durchgesetzt hat, kann man in allen Linux Distributionen die gleichen Befehle nutzen.

Mich stört da eher die Komplexität und die damit auftretenden Bugs. Siehe z.B. hier https://bugzilla.redhat.com/show_bug.cgi?id=1023820 (da ich davon selbst betroffen bin, Version: 208-r2 und 208-r3). Das hat mich wochenlang genervt. Die Tage habe ich dann endlich einen Patch gefunden, den ich manuell einspielen musste. Jetzt scheint es wieder ganz gut zu laufen. Von einem Init-System erwarte ich etwas mehr Stabilität.

----------

## musv

 *Dorsai! wrote:*   

> Auch im umgekehrten Fall... was wenn eine Distro nur udev, policykit, consolekit aus systemd verwenden will?

 

Ich hab noch dunkel in Erinnerung, dass das *kit-Geraffel die HAL-Light-Version war, weil HAL niemand so richtig wollte und das Ding zu schwerfällig war. Und speziell Consolekit war und ist eh nur ein Workaround für genau die Funktionalität, die in Systemd geplant war.

----------

## Jean-Paul

@musv,

@Fijoldar,

das ist sie wieder, die Diskussion um und über die Technik von systemd.

Aber genau darum geht es NICHT.

Dorsai hat es genau richtig erklärt.

systemd ist ein unkontrollierbares Monster das alles frisst was ihm in den Weg kommt.

Linux, und wir als User, werden unsere Freiheit verlieren. Wenn die Entwicklung der letzten 3 Jahre so weiter geht, wirst du in 3 Jahre vielleicht noch deinen Windowmanager wählen können - aber nur vielleicht! Vielleicht muss du auch Gnome oder KDE nehmen, weil nichts anderes mehr läuft.

Viel Spekulation, ich weiß. 

Man sollte aber nicht nur an die Technik denken, sondern auch daran, was es uns systemd letztlich kostet.

----------

## cryptosteve

Stimmt, und genau da sehe ich das Problem mit bei systemd, sondern bei den Diensten, die es als Abhängigkeit zwingend einbinden. Solange es auch ohne geht, bleibt alles gut.

----------

## ulenrich

 *cryptosteve wrote:*   

> Stimmt, und genau da sehe ich das Problem mit bei systemd, sondern bei den Diensten, die es als Abhängigkeit zwingend einbinden. Solange es auch ohne geht, bleibt alles gut.

 Und solange es minimalistische Projekte gibt, wie lxqt, werden wir auch nicht unserer Freiheiten beraubt. Die Applikationsentwickler bestimmen ob es Alternativen geben wird, nicht LP. 

Feststellen kann man in den öffentlich einsehbaren Threads und Fedora Bugs, dass LP von Redhat Entwicklern des öfteren gebremst werden muss. Ich sehe auch die Gefahr, dass sich systemd an übergroßen Ansprüchen selbst aufhängt. Durch Übermut. Aber Leute, lasst euch nicht kirre machen durch die einschlägigen englischen Threads: Es wimmelt von Selbst- Widersprüchen. Aber es dort ist nur LP Bashing angesagt... (*)

Heute kam systemd-209: riesig lange NEWS Liste ...

PS(*) Es hat noch jemand gemerkt: https://forums.gentoo.org/viewtopic-p-7502876.html#7502876

----------

## cryptosteve

 *ulenrich wrote:*   

> Und solange es minimalistische Projekte gibt, wie lxqt, werden wir auch nicht unserer Freiheiten beraubt. Die Applikationsentwickler bestimmen ob es Alternativen geben wird, nicht LP.

 

Solange nicht Xorg (oder zukünftig Wayland) direkt an systemd hängen, stimme ich Dir zu. Aber es würde mich nicht wundern, wenn es da auch noch jemand schafft, Abhängigkeiten zu generieren.

----------

## ulenrich

 *cryptosteve wrote:*   

>  *ulenrich wrote:*   Und solange es minimalistische Projekte gibt, wie lxqt, werden wir auch nicht unserer Freiheiten beraubt. Die Applikationsentwickler bestimmen ob es Alternativen geben wird, nicht LP. 
> 
> Solange nicht Xorg (oder zukünftig Wayland) direkt an systemd hängen, stimme ich Dir zu. Aber es würde mich nicht wundern, wenn es da auch noch jemand schafft, Abhängigkeiten zu generieren.

 

Eher nicht. Haben die englischen Threads auch schon bei Dir abgefärbt? Dazu ein interessanter Hinweis:

Ganz allgemein kannst Du dir ziemlich genaue Vorhersagen über die Zukunft machen, wenn Du die Aussagen von Anon-E-Moose mit minus eins multiplizierst: Der Linux Desktop Bereich ist genau nicht das eigentliche Ziel der Entwicklungsanstrengungen.

----------

## franzf

 *ulenrich wrote:*   

> Ganz allgemein kannst Du dir ziemlich genaue Vorhersagen über die Zukunft machen, wenn Du die Aussagen von Anon-E-Moose mit minus eins multiplizierst:

 

Und das ist leder nur eine völlig unnötige Provokation, die genauso wenig Wahrheit enthält wie alle anderen "Vorhersagen", die nur die persönlichen Wünsche und Wertvorstellungen transportieren.

Dass du LPs Art als "jugendlichen Überschwang" abtust finde ich auch problematisch. Jemand, der vom eigenen überkochenden Testosteron getrieben ist sollte keine dermaßen mächtige Stellung in einer solch zentralen Komponente haben. Auch wenn er mittlerweile akzeptablen Code produziert (diese deine Aussage impliziert übrigens, dass seine bisherigen Projekte durchaus kritikwürdig sind und überdacht werden sollten) bedeutet es noch lange nicht, dass er auch den Charakter besitzt, die Bedürfnisse der systemd-Konsumenten über sein eigenes EGO zu stellen.

----------

## ulenrich

Oh, Gott Franz! Jetzt hier auch im deutschen Forum genauso schräge?

Jeden Satz von Dir muss ich richtig stellen:

 *franzf wrote:*   

>  *ulenrich wrote:*   Ganz allgemein kannst Du dir ziemlich genaue Vorhersagen über die Zukunft machen, wenn Du die Aussagen von Anon-E-Moose mit minus eins multiplizierst: 
> 
> Und das ist leder nur eine völlig unnötige Provokation, 

 

Es ist nicht nur eine Provokation. Es ist eine Provokation, aber nicht nur: Ich kann so ziemlich jede Aussage von Anon-E-Moose des letzten halben Jahres in ihr Gegenteil verkehren und komme zur Warheit. Wenn Du willst, kann ich das leisten und Dir hier aufzeigen?

 *Quote:*   

> die genauso wenig Wahrheit enthält wie alle anderen "Vorhersagen", die nur die persönlichen Wünsche und Wertvorstellungen transportieren.

  Vorhersagen sollen eigentlich das treffen, was eintreten wird, nicht das Aussagen, was man sich wünscht. Gut, ich liege auch manchmal leicht daneben. Wenn ich irgendwo im letzten Jahr gesagt habe, dass Canonical zum nächsten Ubuntu Longterm auf systemd umsteigt, weil es den Interessen ihrer Großkunden entspricht, stimmt es nur fast genau: Trusty+1 

Aber wenn man sagt, systemd wird von selbst wieder verschwinden, weil es so schlecht ist?

 *Quote:*   

> Dass du LPs Art als "jugendlichen Überschwang" abtust finde ich auch problematisch. Jemand, der vom eigenen überkochenden Testosteron getrieben ist sollte keine dermaßen mächtige Stellung in einer solch zentralen Komponente haben. 

 Folgendes macht Deine Aussage schräge:  "mächtige Stellung"

Ansonsten habe ich genau das gesagt! 

Aber warum meinst Du, ich tue etwas ab ???

Das finde ich von Dir schon eine fast böswillige Unterstellung. Ich will mit "jugendlicher Überschwang" nichts am Charakter von LP beschönigen. Aber ich glaube fest, dass opensource Mechanismen die Auswirkungen eines Charakters neutralisieren. Mein "religiöser" Aspekt. Und ich hasse Konspirationstheorien, die im letzten Jahrhundert 100 Millionen Menschen das Leben kosteten. Ich finde es obzön eine "Redhat Verschwörung" auch nur anzunehmen. 

 *Quote:*   

> Auch wenn er mittlerweile akzeptablen Code produziert (diese deine Aussage impliziert übrigens, dass seine bisherigen Projekte durchaus kritikwürdig sind und überdacht werden sollten) bedeutet es noch lange nicht, dass er auch den Charakter besitzt, die Bedürfnisse der systemd-Konsumenten über sein eigenes EGO zu stellen.

  Genau das habe ich gemeint!

Aber was ich schon wieder schräge finde an Deiner Aussage: Es ist nirgendwo ein Gesetz erlassen worden, noch gibt es eine moralische Verpflichtung ein kleines EGO zu haben, wenn man systemd programmiert.

Zusammenfassend:

Deine Aussagen sind so ziemlich die gleichen wie meine, aber Du bist von Deiner Haltung her auf dem halben Weg ein Mitglied der Anti-LP-Church zu werden. "Schräge" in der ersten Zeile oben meine ich in dem Sinne, dass ich Deine Wertvorstellungen für unagemessen halte, sie auf den Opensource Bereich so anzuwenden. Ich meine, du kannst auch Bitcoin opensource programmieren und es für Mafia Geldwäsche benutzen.

----------

## franzf

 *ulenrich wrote:*   

> Oh, Gott Franz! Jetzt hier auch im deutschen Forum genauso schräge?
> 
> Jeden Satz von Dir muss ich richtig stellen:

 

Hiermit bin ich draußen aus der Diskussion. Ich hab keine Ahnung, wann und wo du in einem anderen Forum von mir "schräge" Ansichten gesichtet hast, an eine Antwort von dir kann ich mich auch nicht erinnern. Dass du Ansichten als korrekturwürdig erachtest - nein, das sag ich jetzt nicht...

Punkt.

----------

## ulenrich

 *franzf wrote:*   

>  *ulenrich wrote:*   Oh, Gott Franz! Jetzt hier auch im deutschen Forum genauso schräge?
> 
> Jeden Satz von Dir muss ich richtig stellen: 
> 
> Hiermit bin ich draußen aus der Diskussion. Ich hab keine Ahnung, wann und wo du in einem anderen Forum von mir "schräge" Ansichten gesichtet hast,

 Sorry, ich dachte es ist im Diskussionszusammenhang klar, gemeint war allgemeiner:

Jetzt hier auch im deutschen Forum genauso schräge über systemd diskutieren wie im englischen Forum

----------

## cryptosteve

Ich konnte bis vor kurzem nichts schräges an der Diskussion erkennen. Ich lese den englischsprachigen Thread nur unregelmäßig und Maße mir nicht an, alle Details zur systemd-Entwicklung zu kennen. Sollte ich falsch liegen, darf man mich gerne korrigieren.

Auf eine Diskussion mit gewollten Provokationen und Herablassungen habe ich allerdings in der Tat keine Lust. Eigentlich hatte ich den "interessanten Hinweis" vermisst, aber jetzt, wo ich drüber nachdenke, möchte ich es eigentlich lieber gar nicht wissen.

----------

## Dorsai!

Ich versuche diese Diskussion eigentlich auch wo ich sie führe so unemotional zu führen wie möglich.

Systemd als Init-Dienst würde ich vermutlich sogar benutzen, aber die ganzen anderen Eigenschaften sollten eben meiner Meinung nach aus der Unix Philosophie heraus modular oder auch einzeln verwendbar, zu-/abschaltbar oder durch andere alternative Implementierungen ersetzbar sein.

Bei Console- und Policykit war es aber nicht so (wie ich weiter oben gelesen habe), dass systemd jetzt einfach deren Aufgabe besser und sicherer macht, sondern die Projekte wurden einfach ab einem gewissen Punkt der Benutzbarkeit in systemd integriert ohne dass eine Chance besteht diese wieder herauszulösen (wie es bei udev eben jetzt noch der Fall ist). Anfangs als die *kits noch separat standen haben alle DEs diese angenommen (genauso wie udev) und dann nur mit der Schulter gezuckt, als diese in systemd integriert und die Entwicklung der Einzelkomponenten eingestellt wurde.

Diese Strategie erinnert mich schon irgendwie stark an Embrace Extend Extinguish von Microsoft.

PS: Lese gerade nochmal die oben verlinkte Seite durch... systemd verstößt da meiner Meinung nach gegen jede einzelne Richtlinie die der Unix Philosophie nach für hochwertige Software gelten sollte.

----------

## schmidicom

Das folgende wurde zwar schon einmal gesagt aber angesichts des Gejammers das jetzt erneut zelebriert wird ist eine Wiederholung wohl wieder mal nötig:

"Wenn euch systemd oder das Verhalten der Devs die dafür verantwortlich sind so extrem missfällt dann schlisst euch doch zusammen und nutzt eure gemeinsame Energie dafür das Ding zu forken und nach euren Vorstellungen weiter zu entwickeln/verbessern."

Und bevor jemand sagt das es dafür nicht genug Leute gibt, muss ich hier ganz klar sagen das ich euch das nicht mehr glaube. Zumindest nicht dann wenn tatsächlich so viele Leute mit systemd unzufrieden sind wie immer wieder behauptet wird.

Und mit eudev hat es ja auch geklappt also kann es so unmöglich ja nun wirklich nicht sein oder?

----------

## cryptosteve

Auch nach all den Jahren ändert sich am Sinngehalt einer Aussage durch fortlaufende gebetsmühlenartige Wiederholung nichts.

----------

## cryptosteve

Interessant und zum Thema:

http://www.pro-linux.de/news/1/20795/clasen-gnome-3-nicht-von-systemd-abhaengig.html

----------

## ChrisJumper

heise.de: Systemd regelt jetzt Netzwerkverbindungen

Nun also es ist seltsam. Gut die Init-Skripte haben auch meine Netzwerke verwaltet, warum sollte Systemd das nicht auch machen? Aber das dies wohl auch dhcp, VLAN oder Bridges machen darf stößt mir auch ein wenig unwohl aus. Bisher trug ich ja die Ansicht das Systemd sich ebenso konfigurieren lässt wie die Init-Skripte und lediglich der Ort der Konfigurationsdateien sich ändert. Aber so langsam reicht es doch. Das aktuelle Systemd kann doch schon mit Netzwerkschnittstellen umgehen. Ich will da keine Autokonfiguration haben. Nun ja mal schauen wie das umgesetzt wird.

 *cryptosteve wrote:*   

> Solange nicht Xorg (oder zukünftig Wayland) direkt an systemd hängen, stimme ich Dir zu. Aber es würde mich nicht wundern, wenn es da auch noch jemand schafft, Abhängigkeiten zu generieren.

 

Nun wo wenn nicht bei OpenSource haben wir denn die Möglichkeit den Code anzupassen? Natürlich werden die Beruflichen OpenSource Programmierer ihren Code so gestalten (evtl müssen) das die Konkurrenz es nicht zu einfach hat andere und bessere Lösungen mit einzubringen -wobei das selbe auch für Schadcode gilt-, aber an dieser Stelle bin ich sehr zuversichtlich. Ich halte es immer für möglich eine Light Version oder Fork zu machen. Wenn es nicht wie bei Google auf Serverdienste beruht die nur Extern angeboten werden.

Bezüglich der Systemd, aber auch dem Linux-Kernel betreffend habe ich immer weniger das Gefühl es handelt sich um Garagencode oder das Privatleute da überhaupt die Chance haben "mit zu entwickeln" oder gar demokratisch bestimmen könnten welcher Code jetzt wo einfließt. Das ganze ist einfach so komplex geworden das es zwar im besten und effizientesten Rahmen wächst und sich weiterentwickelt aber eben gleichzeitig bleiben auch die romantischen Vorstellungen auf der Strecke. Dennoch ist es das beste was wir aktuell erwarten können. Auch wenn viele hier Systemd verteufeln, es ist Open Source und wird ganz bestimmt an einigen Stellen dazu führen das der Leidensdruck wieder groß genug ist um einen Fork zu betreuen.

Aber das ganze geflame an allen Ecken und Enden finde ich mehr als unnötig und auch da ist so viele verschwendete Energie die sich viel besser konstruktiv nutze ließe.

----------

## musv

 *Dorsai! wrote:*   

> Bei Console- und Policykit war es aber nicht so (wie ich weiter oben gelesen habe), dass systemd jetzt einfach deren Aufgabe besser und sicherer macht, sondern die Projekte wurden einfach ab einem gewissen Punkt der Benutzbarkeit in systemd integriert ohne dass eine Chance besteht diese wieder herauszulösen (wie es bei udev eben jetzt noch der Fall ist). Anfangs als die *kits noch separat standen haben alle DEs diese angenommen (genauso wie udev) und dann nur mit der Schulter gezuckt, als diese in systemd integriert und die Entwicklung der Einzelkomponenten eingestellt wurde.

 

Der Punkt ist an der Stelle, dass, wie ich oben schon geschrieben hab, ConsoleKit eigentlich ein häßlicher Workaround war, um die xorg-Sessions irgendwie zu verwalten. Die Funktionalität war in HAL drin. Hätte man auch anders lösen können, aber da es nun schon mal da war, wurde es eben weiter verwendet. 

Bei PolicyKit war es ähnlich. Das tauchte irgendwann mal auf mit der Begründung, dass halt die normalen Unix-Rechte (User, Gruppe, Andere) und Udev-Scripte nicht ausreichen würden. Standardbeispiel: Unterscheidung zwischen lokalem und entfernten Benutzer. Der lokale soll den Rechner runterfahren dürfen, der entfernte nicht. Oder halt das Mounten von Wechseldatenträgern. Kann man sich bis heute darüber streiten, ob man PolicyKit als 2. Rechtesystem wirklich braucht, was die Unix-Rechte einfach so aushebeln kann. PolicyKit finde ich insofern häßlich, dass ich ohne größere Anstrengungen keine Regel zusammenbasteln kann. Es ist meiner Meinung nach unnötig komplex. 

Sowohl ConsoleKit als auch PolicyKit und vermutlich auch Udisks stammen irgendwie alle aus der HAL-Entwicklung. Ich mag das ganze Zeug nicht sonderlich. ConsoleKit wurde dann als logind im Systemd umgesetzt. Betrachtet man die Aufgabe von ConsoleKit (sinnloser Daemon, der einfach beobachtet, von wo aus sich eingeloggt wurde), ist das durchaus sinnvoll. 

Zumindest nach dem, was ich in den letzten Jahren so mitbekommen hab, ist nicht Systemd das erste Übel. Die "Fehlentwicklung" ging mit HAL los. Als das Ding nach gut 10 Jahren endlich zu Grabe getragen wurde, wurden diverse Komponenten unter den Namen *kit als schlanke Nonplusultra-Nachfolger präsentiert. Das Kind war aber zu diesem Zeitpunkt schon in den Brunnen gefallen. Systemd war dann halt einfach nur die (vorerst?) finale Lösung, in der das ganze Zeug wieder vereinigt wurde. 

Trotz alledem muss man zugeben, dass System bei mir bisher ziemlich gut funktioniert.

----------

## ulenrich

Danke musv, dass Du hier tiefer gegraben hast: Ich selbst bin wohl 2-3 Jahre zu spät zu Linux gestoßen, als dass ich diese Workaround Geschichte der Kits auf Deine Art beurteilen könnte. 

Natürlich fängt jemand wie LP ein solches Projekt an mit dem Anspruch, jetzt endlich der "Weisheit letzter Schluß" zu genügen. Ich persönlich wäre auch froh, wenn nicht in zwei Jahren wieder "eine neue Sau durchs Dorf getrieben" würde, weil es dann wieder umlernen heisst. Aber wer weiss ...

Analog dazu allgemein zur C++ Klassen Entwicklung hatte einmal jemand behauptet: 

Es bräuchte schon mindestens drei grundsätzliche Neuanfänge, ehe man zu einem Abstraktionsniveau käme, das auch der Benutzbarkeit durch Entwickler genügt. Und jetzt sind wir bei den Qt Klassen bei v5 ....

Schräge finde ich an der Diskussion in unseren Foren, wenn alles auf eine Kritik des persönlichen Charakters von LP hinausläuft. Oder, wenn mir als User nahegelegt wird, ich würde doch auch zugeben, dass LP ein schlechter Entwickler ist oder war. Das haben wir als einfache Benutzer beides nicht zu beurteilen, denn es läuft nur auf eine Verletzung des Gebots "du sollst kein falsch Zeugnis über andere ablegen" hinaus. Auch wenn ich Gott-Ignorant eingestellt bin, sage ich dies jetzt mal so mit der Bibel ...

----------

## schmidicom

Ich habe HAL noch voll miterlebt und es war schon auf der User-Seite kein Vergnügen, um es milde auszudrücken. Schlechte Dokumentation, grauenhafte Konfigurationmöglichkeiten und als User wusste man nie so recht wo es überall seine Finger drin hatte.

systemd mag ein großer Klotz sein aber zumindest funktioniert dieser und hat eine saubere Dokumentation die auch relativ leicht zu verstehen ist. Und innerhalb von systemd folgt auch alles der selben Logik wodurch man sich schnell zurecht findet wenn man das auch will.Last edited by schmidicom on Tue Feb 25, 2014 2:21 pm; edited 1 time in total

----------

## Dorsai!

Ja, HAL war anstrengend und damit hat wohl alles angefangen.

Damals zu HAL Zeiten hatte ich dann versucht einen HAL-freien KDE-Desktop zu betreiben, was nicht wirklich gelang und nun habe ich versucht einen systemd/*kit freien Desktop zu betreiben. Funktionieren tut das schon, zumindest mit Gentoo. Leider ist aber z.b. die einzige alternative Software zum mounten mit Userrechten (pmount-gui) alles andere als komfortabel.

Es zeigt aber, dass es geht viele dieser Aufgaben in kleine, kompakte in sich abgeschlossene Anwendungen und Libs zu verpacken. Also als Gegentrend zu dem was mit HAL da losgetreten wurde. Nichts anderes hätte ich mir von systemd gewünscht, leider schlägt dieses finde ich leider einfach in die selbe Kerbe wie HAL, nur dass die Entwickler und Distros es nicht merken aufgrund des psychologischen "nach-was-schlechtem-kommt-was-gutes" Effekts (Windows Versionen, Star Trek, etc.) nicht merken. Irgendwann werde ich wohl auch umsteigen, aber ich werde es irgendwie vermeiden so lange ich KDE auch komfortabel und sicher ohne systemd nutzen kann.

----------

## ulenrich

Ich habe gerade bei phoronix einen Link gesehen, dass das neue Gnome jetzt auch auf FreeBsd läuft. Natürlich wird Kde ohne systemd auch in Zukunft gehen: Die Frage ist aber, ob es ohne viel Aufwand für einen normalo-nur-user möglich ist. Dafür wird es vielleicht nötig werden gute Ebuilds mit Wahlmöglichkeiten zu basteln. Das Gentoo Kde Team ist dazu wahrscheinlich in der Lage.

Das Gentoo Gnome3 Team besteht nur aus zwei ziemlich unbedarften Maintainern, die sich einen leichten Umbau des updstream-default Gnome3 zu_Gnome3_ohne_systemd nicht zugetraut haben. Und allgemein scheinen Gnome Benutzer eine rein konsumptivere Haltung zu haben, als dass sie Bugs schreiben würden. Auch die ärgsten LP Hasser im Gentoo Forum sind nur Laber-Heinis, die den konstruktiveren User depontius ins Leere laufen lassen .... dann kann man noch mehr Hasstiraden und Konspirationstheorien absondern.

----------

## Jean-Paul

Hass ist ein starkes Gefühl, aber doch immerhin ein Gefühl. Wenn ich an Pöttering, Sievers, Red Hat und Konsorten denke, fühle ich rein gar nichts.

Ich bin gegen systemd, weil es es unehrlich ist. Die ganzen "Erungenschaften" und "Innovationen" hätte man ohne Zwang und als einzelne Pakete einführen können. Wenn man denn gewollt hätte.

Wer systemd will (das Init-System) kann es sich installieren.

Wer udev will, dto

Wer logind will, dto

Wer Binär-Logs will, dto.

Und das alles ohne gegenseitige Abhängigkeiten, was vielleicht 3-Nano-Sekunde Zeit gekostet hätte.

Das wäre ehrlich gewesen. Aber soweit denken die Fanboy's (Heini ist ein schlimmes Wort) nicht - Hauptsache es läuft.

Btw: ich werde mir alle Finger anhacken, bevor ich jemals einen Bugreport für systemd schreibe. Egal ob ich es benutzen muss, oder nicht.

----------

## schmidicom

Das sowohl Gnome als auch KDE weiterhin keine zwingende Abhängigkeit zu systemd mitbringen werden mag für einige eine willkommene Nachricht sein aber es gibt da etwas wichtiges das beachtet werden sollte, nämlich wie sie laufen/funktionieren werden. Bereits jetzt ist klar das unter KDE das mounten eines einfachen USB-Sticks ohne udisks; policykit und consolekit/systemd nicht mehr ohne weiteres möglich ist. Man kann also davon ausgehen das noch weitere Funktionalitäten beim Verzicht auf diese Dinge bald nicht mehr zur Verfügung stehen werden.

Deshalb sollte irgendwann besser die Frage gestellt werden: "Was ist schlimmer, ein KDE/Gnome mit systemd oder ein KDE/Gnome ohne systemd?"

systemd mag in Konzept und Entwicklung umstritten sein aber im Moment ist es auch nur halb so schlimm wie viele behaupten.Last edited by schmidicom on Wed Feb 26, 2014 12:37 pm; edited 1 time in total

----------

## Jean-Paul

 *schmidicom wrote:*   

> "Was ist schlimmer, ein KDE/Gnome mit systemd oder ein KDE/Gnome ohne systemd?"

  Für mich ist daran gar nichts schlimm, ich nutze es nicht.

Ein einfacher WM ist mir genug. 

 *schmidicom wrote:*   

> systemd mag in Konzept und Entwicklung umstritten sein aber im Moment ist es auch nur halb so schlimm wie viele behaupten.

  Die Wahrheit ist, dass nichts was jemals unter Linux gelaufen ist auch nur annähernd so polarisiert wie Pöttering und systemd. Von Verehrung bis zur totalen Ablehnung findest du alles. Und das geht quer durch alle Distris und in einer Dimension die ich nie für möglich gehalten habe.

----------

## ulenrich

 *Jean-Paul wrote:*   

> Die Wahrheit ist, dass nichts was jemals unter Linux gelaufen ist auch nur annähernd so polarisiert wie Pöttering und systemd. Von Verehrung bis zur totalen Ablehnung findest du alles. Und das geht quer durch alle Distris und in einer Dimension die ich nie für möglich gehalten habe.

 

Mein Eindruck ist: Vor allen Dingen unter Usern ist systemd umstritten, während es unter Entwicklern meistens  durchgewunken wurde als eine Implementation von "best practices". Dagegen ließ der Streit zwischen ffmpeg und libav die Benutzer eher kalt, aber die Entwickler in interessierten Kreisen stritten heftig. War es so? (Ich glaube nicht, dass man nach der Debian Diskussion, die auf hohem technischen Niveau stattfand, noch behaupten kann, systemd sei umstritten unter Fachleuten.)

----------

## ChrisJumper

 *ulenrich wrote:*   

> 
> 
> Das Gentoo Gnome3 Team besteht nur aus zwei ziemlich unbedarften Maintainern, die sich einen leichten Umbau des updstream-default Gnome3 zu_Gnome3_ohne_systemd nicht zugetraut haben. Und allgemein scheinen Gnome Benutzer eine rein konsumptivere Haltung zu haben, als dass sie Bugs schreiben würden. Auch die ärgsten LP Hasser im Gentoo Forum sind nur Laber-Heinis, die den konstruktiveren User depontius ins Leere laufen lassen .... dann kann man noch mehr Hasstiraden und Konspirationstheorien absondern.

 

Schreibe doch mal weniger pauschalisierend. Auch wenn es mich nicht betrifft fühle ich mich hier zu unrecht in eine Ecke geschoben. Es ist schade das du einem Gnome 3 Nutzer oder gar einem Systemd Nutzer nicht zutraust etwas anders zu Konsumieren. Wahrscheinlich hast du recht, aber vielleicht arbeiten sie in anderen Softwarebereichen und haben auch keine Zeit so viel Energie in Gnome , KDE und Co zu stecken?

Bei Software muss man immer vertrauen. Bug Reports würde ich auch nur melden wenn ich mit der Funktion überhaupt nicht klar komme und bisher habe ich eher den Eindruck das es einfach funktioniert. Vielleicht sind die unbedarften Gnome Nutzer mit ihrer marginalen Nutzung und Einstellungsmöglichkeit einfach zufrieden?

Ich finde es schade das dies so herablassend klingt und ich glaube auch das nur durch solche pauschalen Missverständnisse sich die Situation in den Foren entsprechend hoch kocht und das dann Hasstiraden auslöst. Das selbe bei Systemd, die eine Seite erklärt nicht richtig, die andere versteht es nicht. Auf beiden Seiten verhörten sich die Fronten und jeder glaub die andere würde ihnen etwas weg nehmen. Was in meiner naiven Meinung aber totaler Quatsch ist.

Ihr wollt andere Open Source Software? Dann Entwickelt sie! Ausdrücke wie "Laber-Heinis" sind einfach fehl am Platz. Ich bin mir sehr sicher das jemand den ich als "Laber-Heini" bezeichnen würde, würde noch nicht einmal Gentoo installiert bekommen. Das ist als würde ich Analphabeten vorwerfen das sie so schlechte Bücher schreiben. Daher Appelliere ich an beide Parteien sich nicht so viel Emotionalen und Sozialen Stress zu machen. Das hat niemand hier nötig oder verdient und kostet nur Energie die wir als Gemeinschaft an anderer Stelle konstruktiver einsetzen könnten.

----------

## ChrisJumper

Eins noch:

Das Problem mit Gentoo und Systemd sind eher die Abhängigkeiten, es lässt sich zwar parallel zu openrc testen und verwenden aber die wenigsten unterziehen der Software dann einen Test. Vielleicht aus ganz unterschiedlichen Gründen. Daher gibt es eine Gruppe die den Aufwand scheut und dann mit möglichst wenig Zeit in die Konfigurationsmöglichkeiten aber auch in Informationen zu Systemd stecken.

Es sollte aber ganz klar und selbstverständlich eine duale Lösung angeboten werden... kann man da nicht einfach ein Kickstarterprojekt starten in das Gelder fließen für die Pflege von gnome3/KDE ebuilds mit Useflags ohne Systemd? Oder wenn es besser ist Spenden an den Gentoo Verein? Ich halte Geld zwar für eine Seuche bei Open Source Projekten auf der anderen Seite, aber vielleicht hilft es eine Situation zu entspannen.

----------

## ulenrich

@Chris, hast Recht, ich nehme alles zurück, weil ich zu pauschalisierend bin und auch nicht den Ton in den englischen Foren hier einführen will. Auch meine ich mit Laberheini sowieso nur einen einzelnen:

https://forums.gentoo.org/viewtopic-p-7502880.html#7502880

Den ich aber beleidigen darf, weil er mich schon lange Sycophant nennt.

Apropos Gnome3 ohne systemd:

Eigentlich müsste man doch nur die Erkenntnisse übers Packen von Gnome3 aus der Freebsd Ecke nehmen und hätte sofort ein lauffähiges System. Keine allzu große und unlösbare Aufgabe für einen engagierten und fähigen Menschen.

Nur weil das aber niemand macht, legt es mir den Verdacht nahe, dass die Motivation nicht groß ist und der Anlaß über systemd zu meckern wichtiger sein mag.

----------

## schmidicom

Für alle systemd fans und hater gibt es hier eine Umfrage  :Wink: 

----------

## Klaus Meier

Tja, ich bin da so ein Fan vom Poettering. Mir gefällt pulseaudio, mir gefällt systemd. Darf man ja eher nicht laut sagen, weil da mehrheitlich bashing angesagt ist. Auch, wenn ich mit systemd und KDE meine Probleme hatte.

Mir gefallen diese Sachen.

----------

## cryptosteve

 *Klaus Meier wrote:*   

> Darf man ja eher nicht laut sagen, weil da mehrheitlich bashing angesagt ist.

 

Das stimmt doch gar nicht. Wie die Umfrage zeigt, ist systemd mehrheitlich akzeptiert.

Ich freu mich nach wie vor über OpenRC und nutze es gerne, weil ich es kann.

----------

## Finswimmer

 *cryptosteve wrote:*   

> Das stimmt doch gar nicht. Wie die Umfrage zeigt, ist systemd mehrheitlich akzeptiert.

 

Naja, bei 68 Stimmen von mehrheitlich zu sprechen, ist etwas gewagt. 

Um auf alle Linux-Nutzer zu schließen, braucht man da doch eindeutig mehr Stimmen.

Zumal ich meine Antwort nicht abgeben konnte, da ich dort nicht registriert bin...

----------

## cryptosteve

Wäre systemd nicht mehrheitlich akzeptiert, würde die nahezu alle Distributionen wie wild auf systemd wechseln. Gentoo ist doch eine der wenigen Ausnahmen, die den Wechsel nicht unverzüglich vollzogen haben. Sogar das erzkonservative Debian hat sich letztlich zu systemd durchgerungen. Und in solchen Communities hat systemd einen durchaus guten Stand.

----------

## Klaus Meier

Wenn du Gnome nutzt, dann wirst du auch bei Gentoo zu Systemd gezwungen. Und ich sehe das eher so, dass man bei Gentoo die Wahl hat. Ist ja nicht so, dass es nicht unterstützt wird. Du kannst es nutzen, wenn du willst, musst es aber nicht. Einer der großen Vorteile bei Gentoo. Bei Ubuntu bekommst du irgend etwas vorgesetzt, ob es dir passt oder nicht. Na die meisten, die Ubuntu nutzen, wissen ja nicht mal, das es so etwas gibt und für was man es braucht.

Ändert aber nichts an der Tatsache, dass es von vielen Anwendern rundweg abgelehnt wird. In den Kommentaren auf ProLinux zu diesem Thema wird berichtet, dass deswegen schon einige zu BSD gewechselt sein sollen.

----------

## cryptosteve

Achja, BSD .. ich bin schon sehr lange im BSD-Lager unterwegs und von denen, die ihren endgültigen Wechsel auf BSD vollmundig verkündet haben, sind nach 3 Monaten nur noch geschätzte 3% an Board. Mittelfristig fehlt es den meisten dort dann doch an Hard- und Softwareunterstützung (inkl. mir) - das gilt aber natürlich nur für den Desktopbereich.

Naja, wir werden es sehen. Ich denke, der Trend zu systemd ist nicht aufzuhalten und ich sehe das auch nicht uneingeschränkt positiv. Das mag aber daran liegen, dass ich mich schwer tue, in Richtung init-System neu zu lernen, weil meine bisherige Variante einfach tut, was sie soll. Ich habe keinen Bedarf für mehr und auch keinen Bedarf für was neues. Von daher ist meine Ablehnung da möglicherweise auch meiner geistigen Unflexibilität in diesem Bereich geschuldet.

----------

## schmidicom

Weil es Thematisch gerade passt:

Pulseaudio wird wohl einer der ersten sein welcher sich die Funktionalitäten von systemd auch auf Userebene zu nutze macht.

 *http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Running/ wrote:*   

> Since PulseAudio v6, the preferred method of launching and running PulseAudio is via systemd.

 

----------

## cryptosteve

 *schmidicom wrote:*   

>  *http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Running/ wrote:*   Since PulseAudio v6, the preferred method of launching and running PulseAudio is via systemd. 

 

Magst Du für mich als Nicht-systemd-Kenner kurz den Vorteil erläutern?

----------

## schmidicom

 *cryptosteve wrote:*   

>  *schmidicom wrote:*    *http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Running/ wrote:*   Since PulseAudio v6, the preferred method of launching and running PulseAudio is via systemd.  
> 
> Magst Du für mich als Nicht-systemd-Kenner kurz den Vorteil erläutern?

 

1. Schon mal bei einem Crash von pulseaudio (was seit Version 4 zugegeben ziemlich selten geworden ist) versucht herauszufinden warum es passiert ist. Das war jetzt nur ein Beispiel denn eigentlich ist das auf jeden Hintergrund-Dienst übertragbar der auf Userebene gestartet wird. Und durch das bessere Logging wird die Fehlersuche im Gegensatz zur ".xsession-errors"-Deponie um einiges einfacher.

2. Ist dann endlich auch ein zuverlässiger Verwalter von Hintergrund-Diensten da der nebenbei auch noch Socketaktivierung beherrscht, ohne das die Desktopumgebungen das Rad alle 5 Meter neu erfinden müssen.

----------

## franzf

 *schmidicom wrote:*   

> 1. Schon mal bei einem Crash von pulseaudio (was seit Version 4 zugegeben ziemlich selten geworden ist) versucht herauszufinden warum es passiert ist. Das war jetzt nur ein Beispiel denn eigentlich ist das auf jeden Hintergrund-Dienst übertragbar der auf Userebene gestartet wird. Und durch das bessere Logging wird die Fehlersuche im Gegensatz zur ".xsession-errors"-Deponie um einiges einfacher.

 

Warum muss logging immer als Totschlagargument herhalten? Warum implementiert pulseaudio als userspace-daemon nicht logging nach ~/.local/share/pulse.log? (wie jeder ordentliche daemon/service ein eigenes Logfile verwendet!)

 *Quote:*   

> 2. Ist dann endlich auch ein zuverlässiger Verwalter von Hintergrund-Diensten da der nebenbei auch noch Socketaktivierung beherrscht, ohne das die Desktopumgebungen das Rad alle 5 Meter neu erfinden müssen.

 

xinetd. Keine Ahnung wie das mit Userspace ausschaut, wär mal interessant zu eroieren.

Wobei ich nicht verstehe, warum jeder Dienst socket-aktiviert werden muss, und das dann als grandiose Errungenschaft herhalten muss. IMHO ist Sound für nen normalen Desktop-Rechner schon was essenzielles. Irgendwann machts "piep" und von da weg läuft das Ding, kann dann auch direkt beim Login gestartet werden. Ordentlicher asynchroner Start von Diensten ist da schon ein besseres Argument. Login-Skripte, die synchron abgearbeitet werden (und dann noch sleep einbauen um sicher zu gehen dass darauffolgende Sachen auch garantiert gut gehen -> startkde) sind ne Qual. Wobei das bei mir nur awesome und compton startet und gleich gar keine Zeit braucht  :Wink: 

----------

## schmidicom

Diese Login-Scripte kranken meiner Meinung nach, genau wie die init-Scripte, nicht nur an der Art und Weise wie sie abgearbeitet werden sondern leider auch daran das sie unter Umständen von einem ganz bestimmten Shell-Interpreter abhängig sein können. Auch können sie, je nach Größe und Schreibweise, im Fehlerfall die Problemanalyse erheblich verkomplizieren.Last edited by schmidicom on Fri Jan 30, 2015 7:56 am; edited 1 time in total

----------

## dekoding

also ich bin kein fan von systemd drum bin ich zu gentoo gegangen, da kann man es ja aus wählen, und so dolle is systemd nicht sah ich bei einigen systemd distros.

----------

## Klaus Meier

So, es geht weiter, ich weiß jetzt, warum plasma-desktop crahst. Wenn ich nur kde-apps-meta installiere (dachte, das ist analog zu kde-meta), dann fehlt der Plasa Desktop. Leider kann man dann nicht mehr updaten. kcontrol blocks plasma-desktop. Der muss noch weg, dann läuft es.

----------

## SkaaliaN

Was ist dir denn so extrem negativ aufgefallen, dass du auf systemd verzichten möchtest?

Ist eine ernst gemeinte Frage.

LG

----------

