# Poetterings (nächste?) Vision

## schmidicom

Gerade ist auf www.pro-linux.de ein interessanter Artikel zur nächsten Poettering-Idee aufgetaucht.

Bitte korrigiert mich wenn meine folgende Annahme dazu falsch sein sollte, aber wenn ich das richtig verstanden habe sollte es damit zum Beispiel doch möglich sein "app-crypt/mit-krb5" und "app-mobilephone/heimdall" gleichzeitig zu installieren (also jedes in seinem eigenen btrfs-subvolume) und beim Start eines Programm sorgt dann systemd dafür das dieses Programm die eine oder andere Lib bekommt?

Was meint ihr dazu? Ich finde die Idee an sich ja gar nicht schlecht aber das Chaospontenzial macht mir doch ein bisschen "Angst".

----------

## kernelOfTruth

Chaospotenzial kommt dem ganzen schon ganz nahe, wenn man die Diskussion auf Phoronix (http://www.phoronix.com/forums/showthread.php?105607-Lennart-Poettering-Talks-Up-His-New-Linux-Vision-That-Involves-Btrfs ) verfolgt

die wichtigste Frage die sich für mich in dem Zusammenhang auch stellt ist: wie werden Sicherheitsupdates für alle Unterversionen gehandhabt ?

Wird alles auf einmal geupdatet ?

Wer ist für die Kompilierung der Binärdateien zuständig ? eine zentrale Anlaufstelle ? (Missbrauchspotenzial, Sicherheit, Angreifbarkeit, etc.)

Dependency-Hell nur auf einem höheren Niveau ?

auf der anderen Seite ist die Steigerung des Komforts natürlich nicht zu leugnen: das System kümmert sich um alle parallel installierbaren Versionen und alles "läuft einfach" - zumindest in der Theorie

und wird damit natürlich, in der maximalen Komfort-Variante, Schluss sein mit dem platzsparenden Linux-System   :Laughing: 

Wie das ganze in der Praxis ausschaut ist natürlich ein ganz anderes Tier   :Wink: 

----------

## Jean-Paul

Die "technischen" Belange interessieren mich hier gar nicht.

Nach systemd soll uns jetzt noch btrfs aufgezwungen werden - alles Red Hat "Produkte".

Danach kommt die Gesamtübernahme in Form einer Einheits-Distri, denn das was Poettering da beschreibt ist nichts anderes.

Wenn alle Distri's gleich funktionieren machen sie sich überflüßig.

----------

## Klaus Meier

Hatte bislang noch nicht die Muße, mich mit diesem Thema zu beschäftigen. Aber warum darf keiner Visionen haben? Muss alles für immer so bleiben wie es 1975 mal war? Wenn btrfs Vorteile hat, warum soll man die nicht nutzen? Ich muss sagen, ich bin schon seit einiger Zeit bei btrfs und bin begeistert. Und dann kommt so ein Totschlagargument: "Gesamtübernahme in Form einer Einheits-Distri".

Aktuell zwingt uns die EU ja zu Staubsaugern, die jetzt bei halber Leistungsaufnahme die gleiche Saugleistung haben. Leuchtmittel dürfen maximal einen Wirkungsgrad von 5% haben usw. Und die Leute kreischen, als würde man ihnen sonst etwas antun und wollen am liebsten deswegen die EU abschaffen. Wobei ich sie vorher immer nur jammern gehört habe, dass die Strompreise zu hoch sind.

Kann man sich nicht mehr sachlich mit einem Thema beschäftigen, wenn es vom Poettering kommt? Ich hab keine Ahnung, um was es geht, will das auch gar nicht wissen, aber ich bin auf alle Fälle dagegen.

----------

## Jean-Paul

 *Klaus Meier wrote:*   

> Aber warum darf keiner Visionen haben? 

  Natürlich darf man Visionen haben, solange man sie anderen nicht aufs Auge drückt.

 *Klaus Meier wrote:*   

> Muss alles für immer so bleiben wie es 1975 mal war?

 Natürlich nicht. Wüßte auch nicht was das mit dem Thema zu tun hat. Alle 14 Tage eine neue Sau durch's Dorf treiben, kann aber auch nicht die Lösung sein. Was LP vorschwebt, hat nicht mehr viel mit Linux zu tun - erinnert mich stark an Windows.

 *Klaus Meier wrote:*   

> Wenn btrfs Vorteile hat, warum soll man die nicht nutzen?

 Jeder der will darf btrfs nutzen - die Betonung liegt auf "will". Ein System aufbauen das auf die Fähigkeiten eines Filesystems beruht, verdrängt alle anderen Filesysteme bis es nur noch eines gibt - und das kontrolliert Red Hat. Diese Vorgehensweise wird gerade mit systemd getestet und scheint auch zu funktionieren.

 *Klaus Meier wrote:*   

> Und dann kommt so ein Totschlagargument: "Gesamtübernahme in Form einer Einheits-Distri".

 Das ist kein Totschlagargument, das ist das Ziel von LP und Red Hat. Und du wirst sehen die Einheitsdistri wird kommen, wenn Red Hat so weiter machen darf.

 *Klaus Meier wrote:*   

> Kann man sich nicht mehr sachlich mit einem Thema beschäftigen, wenn es vom Poettering kommt? Ich hab keine Ahnung, um was es geht, will das auch gar nicht wissen, aber ich bin auf alle Fälle dagegen.

 Das sollte sich Poettering mal fragen. Alle Diskussionen die er nicht mag lehnt er ab. Alle kritischen Einwände bezeichnet er unsachlich als Haßkampanien (fängt da schon der Größenwahn an ?). Alle Codevorschlage und Patches die ihm nicht passen, lehnt er unsachlich ab.

Wie man hört kann man nur sachlich mit ihm reden, wenn man seiner Meinung ist.

----------

## Klaus Meier

Ah ja, also das entscheidest du jetzt, was mit Linux zu tun hat. Soso. Hm, und darf ich dann mal fragen, wo das definiert ist, was mit Linux zu tun hat?

Darf ich fragen, an welchen Kriterien du festmachst, dass es wie Windows ist? Mir ist im Artikel absolut nichts derartiges aufgefallen. Mir ist aber auch nicht klar, an welchen Kriterien man erkennt, das ein OS wie Windows ist.

Darf ich fragen, wie die beiden anderen Säue hießen, die wir im August hatten, wenn alle 14 Tage eine neue Sau durchs Dorf getrieben wird?

Und noch etwas zur Einheitsdistri: Da wird erwähnt, wie mehrere Distributionen auf den gleichen Bestand von Anwendungen zugreifen können. Das würde den Einsatz von mehreren Distributionen auf einem Computer und auch das Updaten erleichtern. Ich sehe absolut nichts, wieso uns dieser Mechanismus eine Einheitsdistri bringt. Auch wenn jede Distribution systemd und btrfs nutzt, dann sind es immer noch unterschiedliche Distributionen. Die Tatsache, dass jede Distribution den Linux-Kernel und X benutzt ist doch in dieser Hinsicht vergleichbar. Warum stört dich das nicht?

Also wenn ich Poettering wäre, so einen Beitrag wie den von dir, den würde ich auch als Hasskampagne bezeichnen. Ich kann da absolut nichts sachliches finden. Wie soll man denn darauf eingehen?

Ok, ja, ich habe mir den Artikel jetzt durchgelesen. Irgendwie ist es zu umfangreich, als dass man es so einfach bewerten kann und auch die Frage der Realisierbarkeit ist nicht so ganz einfach. Aber einige Sachen sind schon nicht schlecht. Z.B., ein System ist auf zwei Subvolumes. Eins wird upgedatet, wenn etwas schief geht, dann läuft es auf dem anderen, welches nicht upgedatet wurde, weiter. So etwas mache ich aktuell manuell. Vor jedem Update ein Snapshot vom System, wenn etwas schief geht, wird das zurückgespielt. Ok, das ist jetzt nicht von ihm sondern gibt es schon bei CoreOS, aber es geht in eine gute Richtung.

----------

## schmidicom

@Jean-Paul

Ich glaube nicht das systemd einen dazu zwingen wird die Pakete in irgendwelche btrfs-subvolumes zu installieren aber es gibt sicher einige Distributionen die das mit Handkuss aufnehmen werden, und vermutlich gäbe es auch unter Gentoo genug Leute die davon Gebrauch machen würden wenn sie könnten (Portage müsste dafür wohl angepasst werden).

----------

## musv

Klaus:

Um das Mistrauen gegenüber Lennard Poettering (und Kai Sievers) etwas nachvollziehen zu können, lies Dir einfach mal diesen Thread hier etwas durch:

http://www.reddit.com/r/linux/comments/221irz/linus_blocks_all_code_from_kay_sievers_from_linux/

Soweit ich das wohl in Erinnerung hab, ging es darum DBus in den Kernel zu integrieren, was jetzt auch passiert. Linus Torvalds hatte die Integration abgelehnt, da der Kernel im Debug-Modus einfach nicht mehr gebootet hatte, weil KDBus wohl zuviel Output hatte. 

Daraufhin entbrannte ein Streit. Und die Philosophie von Sievers/Poettering scheint zu sein, dass die halt eine "Vision" haben, diese Umsetzen, per Redhat-Marktmacht zum Quasistandard und zwingende Abhängigkeit in Linux erheben und sich dann der nächsten "Vision" zuwenden. Debuggen und Pflegen der Software sehen sie weniger als ihr Aufgabengebiet an. Das mag im User-Space möglich sein. Beim Kernel hört dann das Verständnis auf. 

Pulseaudio (anderer Thread) scheint wohl mittlerweile halbwegs zu laufen, nistet sich aber böse ins System ein. Systemd ist mittlerweile Quasistandard, nur noch wenige Distris bieten Alternativen an. Avahi/Zeroconf ist auch schwierig, aus dem System fernzuhalten. 

Systemd mag ich mittlerweile sogar und benutze es auf sämtlichen Rechnern. Nur ist das angekoppelte Journald noch nicht ganz ausgereift. Wenn ein Logfile korrupt wird, kann es passieren, dass Journald permanent neustartet und scheitert. Und die Logfiles werden manchmal bei einem normalen Reboot beschädigt, bei einem System-Crash / Hard-Reset passiert das fast zuverlässig. Das beobachte ich jetzt schon seit einigen Monaten auf meiner Nas. Und dann läuft die IO-Last auf 99%, was interessanterweise dazu führt, dass ich mich nicht mehr per SSH einloggen kann. Die vorgeschlagene "Lösung": 2x neubooten, was manchmal sogar klappt. Sowas erinnert mich eher an Redmond-OS.

----------

## py-ro

Was btrfs mit Redhat zu tun hat ist mir auch nicht klar, wenn er jetzt Oracle gesagt hätte, aber selbst das passt nicht. Aktuell könnte man noch am ehesten Facebook sagen.

So ist das nur ein Rant ohne sachliche Aussage.

@musv Das mit dem Output hatte nicht mit kdbus zutun, da hast du was missverstanden. Im Grunde ging es "nur" um die Kernel Cmdline. Systemd hat das selbe Debug Flag genutzt wie der Kernel und dann den Puffer vollgeschrieben. Das ablehnen der Patches kam dann daher, dass Herr Sievers Aussage im Grunde war "Nicht mein Problem."

Bye

Py

----------

## Klaus Meier

@musv: Ich habe niemals gesagt, das ich dem Poettering hörig bin. Aber ich erwarte schon Argumente, die etwas mit der Sache zu tun haben. Und wenn dann jemand seinen Beitrag mit folgenden Worten beginnt: "Die "technischen" Belange interessieren mich hier gar nicht.", was soll man dann dazu sagen?

Ist ja mein Reden seit langem. Wenn die Diskussionen in Bezug auf den Poettering zu 90% nur aus "Poettering ist Scheiße" bestehen, dann darf sich keiner beschweren, dass er nicht Ernst genommen wird. Meinst du, solche Beiträge wie der von Jean-Paul verbessern die Sache?

Ich war auch angepisst, als mir Pulseaudio vorgesetzt wurde. Ich war auch angepisst, als mir Systemd vorgesetzt wurde. Aber ich habe mich mit der Materie beschäftigt und bin inzwischen sehr glücklich mit beidem.

Ja, da ist vieles nicht optimal, aber daran wird sich nichts ändern, wenn man nicht auf die Fakten eingeht sondern von Weltherrschaft und sonstigem faselt.

----------

## Jean-Paul

Die technische Belange interessieren mich hier deshalb nicht, weil es schon lange nicht mehr um die Technik geht. Und LP macht da auch kein Geheimnis daraus. Sein ausgesprochenes Vorhaben ist, dass jeder systemd nutzen muss.

systemd ist schon lange kein Init-System mehr das man nutzen kann oder nicht, sondern ein ausgewachsenes Linux-Core-System.

Immer mehr Kernfunktionen wie udev, cron, login, syslog, net, ... wird von systemd erledigt. Alternativen werden zurückgedrängt, Linux wird zur Monokultur.

Ich kann mich angesichts dieser Aussichten nicht "nur" mit der Technik auseinander setzen. Das möchte ich jenen überlassen, die so von LP eingenommen sind, dass sie in schon in Schutz nehmen bevor sie seine Artikel gelesen haben.

Ich möchte auch in fünf Jahren noch ein freies, im Sinn von Freiheit, Linux nutzen dürfen. Ein von LP und Red Hat aufdiktiertes System ist nicht frei. Ich möchte auch nicht auf den Messias warten der dann irgendwann auftaucht und nach guter alter Art einen Fork aufmacht und alles wird gut. Diese Zeiten sind vorbei. Denn die Systeme sind mittlerweile so komplex, dass dieser Messias schon mit ordentlich Kohle - sprich Manpower - ausgestattet sein muss um etwas zu bewegen. So jemand ist weit und breit nicht in Sicht, was zur Folge hat dass über kurz oder lang jeder ein LP/Red Hat System nutzen wird.

Und natürlich ist das ein Rant, weil ich LP und Red Hat nicht mag - besonders wie sie ihr Zeug durchdrücken. Mir schwillt jedes Mal der Hals wenn ich wieder über eine neue Idee von LP lesen muss.

----------

## kurisu

Ich sehe das ziemlich genauso wie Jean-Paul. Zwar kann ich dem ganzen Bashing gegenüber LP nur wenig abgewinnen, seinen „Produkten“ jedoch ebenso wenig. Insbesondere wichtig ist mir die Wahlfreiheit, die LP mitsamt Anhang nun offenkundig wie nie zu untergraben gedenkt. Vor diesem Hintergrund war die Idee, udev mittels eudev zu forken, vielleicht doch nicht so verkehrt. Ob das Bestand hat, steht natürlich wieder auf einem anderen Blatt.

----------

## Klaus Meier

@musv: Hab jetzt erst mal deinen ganzen Beitrag gelesen. Was für ein FS nutzt du? Wie bekommst du dein Journal kaputt? Damit hatte ich noch nie Probleme. Ich bin auf btrfs und hatte da jetzt ein paar heftige Aussetzer, weil mein Laptop bei 36 Grad Temperatur, emerge und Flash dann einfach abgeschaltet hat. Und nie auch nur ansatzweise etwas kaputt.

Kann es sein, dass es eher ein Problem vom FS ist als von Journald? Eventuell mal ein fsck drüber laufen lassen, bevor du es nach einem Crash wieder mountest. Bei btrfs hatte ich dank cow manchmal alte Dateien nach einem Crash, aber nie eine kaputte.

----------

## AmonAmarth

 *Klaus Meier wrote:*   

> @musv: Hab jetzt erst mal deinen ganzen Beitrag gelesen. Was für ein FS nutzt du? Wie bekommst du dein Journal kaputt? Damit hatte ich noch nie Probleme. Ich bin auf btrfs und hatte da jetzt ein paar heftige Aussetzer, weil mein Laptop bei 36 Grad Temperatur, emerge und Flash dann einfach abgeschaltet hat. Und nie auch nur ansatzweise etwas kaputt.
> 
> Kann es sein, dass es eher ein Problem vom FS ist als von Journald? Eventuell mal ein fsck drüber laufen lassen, bevor du es nach einem Crash wieder mountest. Bei btrfs hatte ich dank cow manchmal alte Dateien nach einem Crash, aber nie eine kaputte.

 

journald ist ein syslogger und hat nichts mit dem FS zu tun....

----------

## schmidicom

@AmonAmarth

Und was glaubst du wo diese Logs gespeichert werden? Die liegen wie alles andere auf der Festplatte und können demzufolge bei einem Abstutz auch genauso beschädigt werden.

PS: Wenn der journald kaputte Logdeiten vorfindet löscht er sie, normalerweise.Last edited by schmidicom on Wed Sep 03, 2014 1:25 pm; edited 1 time in total

----------

## musv

 *Klaus Meier wrote:*   

> @musv: Hab jetzt erst mal deinen ganzen Beitrag gelesen. Was für ein FS nutzt du? Wie bekommst du dein Journal kaputt?

 

Dateisystem auf der NAS ist ext4. Daran liegt's nicht. 

In den Defaulteinstellungen darf, soweit ich weiß, Journald 10% der Platte vollschreiben. Das hat zur Folge, dass das Logfile bei höhere Plattengröße ungeahnte Größen annehmen kann. Versucht man dann im Logfile zu navigieren, ist das auf einer Nas schier unmöglich. Das Teil ist unter Volllast für ein paar Stunden nur am Rödeln. Also hab ich mal nachgeforscht, was man in Sachen Logrotate und Begrenzung der Logfilegröße unternehmen kann. Journald bietet dazu ein paar Einstellungsmöglichkeiten:

```
[Journal]

SystemMaxUse=100M

SystemMaxFileSize=10M

RuntimeMaxUse=100M

RuntimeMaxFileSize=10M
```

Und jetzt hab ich eben den Effekt, dass beim Logrotate die IO-Last nach oben schießt und ein Login per SSH nicht mehr möglich ist (keine Ahnung warum, nfs-mount geht komischerweise noch). Und bei einem Neustart der Nas krieg ich eben ab und zu mal die Logfile corruptions. Was man übrigens gar nicht machen sollte, ist das Löschen eines Logfiles ohne den Journald vorher zu beenden.

Und bei einer Corruption schaltet der Journald eben gern mal in den "Crazy-Modus", d.h. journald versucht zu starten, scheitert, versucht zu starten, scheitert ...

Die Startinfos zu Journald kannst du ausgeben mit:

```

Jan 01 01:00:04 Nas systemd-journal[87]: Journal started

Jan 01 01:00:06 Nas systemd-journal[87]: Permanent journal is using 56.0M (max allowed 100.0M, trying to leave 1.4G free of 45.8G available → current limit 100.0M).

Jan 01 01:00:06 Nas systemd-journal[87]: Time spent on flushing to /var is 115.059ms for 355 entries.
```

Nicht wundern bei der Zeit. Die Nas hat keine Hardware-Clock. 

Und checken kannst du die Logfiles mit:

```
PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/system.journal

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/user-1000.journal

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/system@22d6497a83c14ef9a0c00913993b21dd-0000000000000001-00000000003e6846.journal

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/user-1000@36aa49c231224b66b24d23b461dfccd0-00000000000001c7-0000000000ae4a6a.journal

074a78: unused data (entry_offset==0)░░░░░░░░░░░░░░░░░░░░░░░   0%

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/system@0004fe875fe20650-17bd954513c8859c.journal~

30bf70: unused data (entry_offset==0)░░░░░░░░░░░░░░░░░░░░░░░  39%

30bfd8: unused data (entry_offset==0)

30bfd8: invalid hash (d10e0c2a85454de2 vs. 4bc3ab3a54d92c30

Invalid object contents at 30bfd8: Ungültige Nachricht

File corruption detected at /var/log/journal/e4b5dad211aa4a41920893d218a05e68/system@00000000005ffdb6-d01db628950014ac.journal~:30bfd8 (of 8388608 bytes, 38%).

FAIL: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/system@00000000005ffdb6-d01db628950014ac.journal~ (Ungültige Nachricht)

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/system@ccd939e1e25b44dd9709db907bb6cc01-0000000000000001-00000000003e6b97.journal

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/user-1000@0004ff627d335829-a3bc86109f4cdb6b.journal~

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/system@ccd939e1e25b44dd9709db907bb6cc01-00000000000001f2-0004ff433f362a3d.journal

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/user-1000@a4eff8036d654bb5ad994578b70c9caf-000000000000021d-0004ff627d353337.journal

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/user-1002@bddf0c99c9ff49319857fd3de97aa6dc-000000000000145a-0005013ebac754bb.journal

PASS: /var/log/journal/e4b5dad211aa4a41920893d218a05e68/system@ef49062663b04356a2647dd64ea262b5-0000000000000001-00000000003d9fc4.journal
```

Und wie man sieht, hab ich hier schon wieder 'ne Corruption drin. D.h. vorm nächsten Neustart sollte ich erst mal den Journald beenden und das kaputte Logfile löschen. Sonst darf ich wieder mit dem Tiny-Breakout über die serielle Konsole ran. 

Mit einem Logger, der ins Init-System integriert ist, sollte sowas einfach nicht passieren. Dafür ist diese Komponente zu systemrelevant.

----------

## mv

 *Klaus Meier wrote:*   

> Kann es sein, dass es eher ein Problem vom FS ist als von Journald? Eventuell mal ein fsck drüber laufen lassen, bevor du es nach einem Crash wieder mountest. Bei btrfs hatte ich dank cow manchmal alte Dateien nach einem Crash, aber nie eine kaputte.

 

In einer Datenbank kann eine alte Datei eine kaputte sein, wenn die Operationen nicht "atomic" implementiert werden. Das erfordert exaktes Arbeiten und eine bedachte Implementation, etwas mit einem eigenen journal (im Sinne von Filesystem-Journal, nicht im Sinne von journald).

Wenn ich mir den Stiefel ansehe, den Poettering bislang zusammenprogrammiert hat, bezweifle ich, dass er in der Lage ist, die journald-Datenbank korrekt zu implementieren.

----------

## mv

 *Klaus Meier wrote:*   

> Darf ich fragen, an welchen Kriterien du festmachst, dass es wie Windows ist? Mir ist im Artikel absolut nichts derartiges aufgefallen.

 

Es läuft absolut der Linux-Philosophie entgegen - noch wesentlich mehr als systemd es bislang schon tut:

Anstatt die Aufgaben in kleine Teilafugaben in  Bibliotheken zu unterteilen, die jede für sich unabhängig gewartet werden können und sollen, werden in diesem "genialen" Kozept Bibliotheken mit jedem Programm gebündelt. Es passiert also genau das, was insbesondere die Gentoo-Entwickler seit Jahren bemängeln - und soweit möglich - upstream drängen, es zu fixen: Wenn sich dieses §$/&-Konzept durchsetzt, wird sich Upstream nicht mehr um Entbündelung kümmern - schließlich können Sie ja dem Benutzer ihre jeweils geliebete Bibliotheksversion aufzwingen. Einige werden vielleicht Sicherheitspatches für diese Bibliotheken einspielen, anderen ist das gerade Wurst. Der Benutzer jedenfalls ist nicht mehr Herr der benutzten Bibliotheken, sondern Upstream oder die Distribution ist es. Eine Bibliothek zu patchen oder auszutauschen ist faktisch nicht mehr möglich.

Das ist vielmehr genau die Windows/Apples-Philosophie: Jedes Programm bringt seine DLLs mit; es gibt keine Intention und ist gar nicht gewünscht, Bibliotheken global auszutauschen.

Poetterings "Neuerung" ist i.W. nichts anderes. Wenn man ein de-duplikating Filesystem fordert, könnte man einfach alle Daten eines Programms (einschließlich all dessen benutzer Bibliotheken) in einem eigenen Directory speichern, aber diese Konzept hätte man ohne systemd realisieren können. Natürlich wäre eine Implementation, die ohne systemd-Zwank auskäme von Poettering nicht gewünscht.

Zusammenfassend kann man sagen, dass das Ganze die schlechteste Idee ist, die ich in den letzten Jahren gelesen habe - die anderen Poettering Machwerke eingesclossen.

Edit: Fix typosLast edited by mv on Sun Sep 07, 2014 9:53 am; edited 1 time in total

----------

## mv

 *Klaus Meier wrote:*   

> Ich war auch angepisst, als mir Pulseaudio vorgesetzt wurde. Ich war auch angepisst, als mir Systemd vorgesetzt wurde. Aber ich habe mich mit der Materie beschäftigt und bin inzwischen sehr glücklich mit beidem.

 

Ich habe mich auch mit der Materie beschäftigt, fahre seit geraumer Zeit systemd parallel zu openrc und bin inzwischen dadurch erst richtig angepisst: Der Dreck ist sowas von buggy und undurchdachtes ad-hoc-Gewurstel (siehe einige Threads, die ich mit Fragen zu systemd eröffnet habe und zu denen es keine vernünftige Antwort gibt - das Systemd-Konzept ist einfach kaputt). Über die Latenzen von pulseaudio, die es auf den meisten älteren Systemen unbrauchbar macht und auch auf neueren Systemen nur Resourcen schluckt für Features, die kaum jemand braucht, müssen wir gar nicht erst reden. Den avahi/zeroconf-Müll hat Gentoo glücklicherweise mit USE-Flags entsorgen können. Hast Du seinerzeit den hal-Schwachsinn mitmachen müssen?

Jemand, der bislang nur Unbrauchbares und schlechte Ideen produziert hat: In der Tat, man muss in Zukunft wohl nicht mehr anschauen, ob er technisch irgendetwas zu sagen hat - davon versteht er offensichtlich nichts. Was er versteht, ist mit politischem Agitieren seinen Müll allen aufzudrängen.

----------

## franzf

 *mv wrote:*   

> Jemand, der bislang nur Unbrauchbares und schlechte Ideen produziert hat:

 

Uuuuh Vorsicht! Da bin ich im englischen Forum (AFAIR) mal gaaanz böse angefahren worden. Wäre kein Argument. Nur weil hal etc. Mist war (hat er ja selbst erkannt uswusf.) heißt das noch lange nicht, dass er auf dem Niveau weitergemacht hat. Er hat ja so viel gelernt und systemd ist richtig klasse und ich sollte das Maul halten. Poettering hat auf alle Fälle eine Chance verdient und soll unbedingt weitermachen. (Kann sein dass das nicht alles wörtlich gesagt wurde, aber es kam so an  :Wink: ).

----------

## mv

 *franzf wrote:*   

> Uuuuh Vorsicht! Da bin ich im englischen Forum (AFAIR) mal gaaanz böse angefahren worden. Wäre kein Argument

 

Ist auch im Prinzip kein Argument. Es gibt aber halt eine Toleranzgrenze. hal alleine wäre kein Thema für mich, auch wenn der Hype, mit dem es einem schon damals aufs Auge gedrückt wurde, schon andeutete, was noch folgen würde. Aber das Ganze hat sich inzwischen 5-6 mal wiederholt, ist dabei jedesmal technisch schlechter und politisch agressiver geworden. Mit diesem letzten schwachsinnigen Konzept ist jetzt bei mir das Fass übergelaufen: Bei mir ist jetzt LP auch als Person untendurch.

----------

## schmidicom

Ihr scheint zu vergessen das es hier nicht um Pulseadio, HAL oder was auch immer geht sondern um ein optionales Feature von systemd welches mit dem klassischen sysvinit wohl nur sehr schwer (wenn überhaupt) möglich wäre. Und nur weil Poettering bei dem einen oder anderen Projekt ein eher fragwürdigeres Ergebnis ablieferte heißt das noch lange nicht das jetzt automatisch alles schrott ist was von ihm kommt oder von ihm mitentwickelt wird/wurde.

Und noch etwas in manchen Bereichen ist diese übertriebene splitterei auch schlicht und einfach fehl am Platz, wie zum Beispiel im Bug 517714. Würde man die beiden Pakete "dev-qt/qthelp" und "dev-qt/assistant-tools" wie vom upstrem empfohlen zu einem machen wäre der Bug und damit auch all seine Blocks (welche immer länger werden) schon längstens behoben und Qt5 könnte (meinetwegen auch als masked) in das offizielle Portage Einzug halten.

----------

## mv

 *schmidicom wrote:*   

> Ihr scheint zu vergessen das es hier nicht um Pulseadio, HAL oder was auch immer geht sondern um ein optionales Feature von systemd welches mit dem klassischen sysvinit wohl nur sehr schwer (wenn überhaupt) möglich wäre.

 

Quatsch. Es geht um ein Aufzwingen eines Standard in der Handhabung von BTRFS, das Upstream, nicht aber dem Computerbesitzer, die Kontrolle das System geben soll.

systemd hat mit dem Ganzen nur soviel zu tun, als Poettering bestrebt ist, auch mit dieser vollkommen dijsunkten Schnapsidee eine beiderseitige künstliche Kopplung zu erzwingen.

 *Quote:*   

> Und nur weil Poettering bei dem einen oder anderen Projekt ein eher fragwürdigeres Ergebnis ablieferte

 

Nur weil Poetteriing bei bislang allen Projekten nur schlechte Ergebnisse ablieferte...

 *Quote:*   

> heißt das noch lange nicht das jetzt automatisch alles schrott ist was von ihm kommt oder von ihm mitentwickelt wird/wurde

 

aber es gibt auch keinen Anlass, auf eine zukünftige Ausnahme zu hoffen

 *Quote:*   

> wie zum Beispiel im Bug 517714

 

Das ist jetzt ein vollkommen anderes Thema. Eine Abhängigkeit an eine Entwicklungsumgebung, die die meisten nicht brauchen, wäre schon extrem schlecht. Für mich klingt das wie eine Limitierung von cmake oder eine schlechte Implementierung von cmake-Regeln. Da ich mich mit cmake aber nicht auskenne, kann ich dazu nicht wirklich etwas sagen.

Edits: Fix TyposLast edited by mv on Thu Sep 11, 2014 9:11 am; edited 2 times in total

----------

## fuchur

Hi

Bin auch mal wieder hier. Habe mir das Thread mal durchgelesen und da viel mir ein

nettes Ereignis vom Sonntag ein. Habe nach etwas längere zeit am Sonntag mal wieder

mein Fedora 20 gebootet bzw. wollte booten. Hatte vor 3 bis 4 Wochen mal eine Partition

neu formatiert die auch in der fstab von Fedora stand. Beim formatiert hatte sich natürlich

die UUID geändert. Was systemd dann macht ist der absolute Hammer, da hilft nur noch

alt strg entf. Einfach mal eine nicht vorhanden UUID in der fstab eingeben und versuchen

zu booten, traumhaft.

Überlaufende logfiels nicht bootend Rechner usw. wsw. und alles nur wegen so einem Scheiß

Programm, so etwas hat es noch nie gegeben. Und das war nicht irgend eine dist sonder

Fedora also Redhat. Nein nein so wird das nichts mit dem Jahr des Linuxdesktop

MfG

----------

## franzf

@fuchur:

Wg. mounten hatte ich ebenfalls gelegentlich Probleme. Allerdings stehen da keine UUIDs in der fstab, sondern ganz normale devices. Es wurde auch nichts neu formattiert.

Das Problem war, dass irgend etwas verhindert hat, dass die Partitionen gemountet werden. Services kamen nicht hoch (wie auch). Ich war geschockt! Mein erster Verdacht: Platte (non-SSD) kaputt. Schweiß auf der Stirn - weil der Rechner grad (natürlich) extrem dringend gebraucht wurde. Also Stoßgebet, beide Daumen gedrückt und Reboot. Ging alles glatt als wäre nichts gewesen.   :Shocked: 

Das hat sich dann in unregelmäßigen Abständen wiederholt. Seit ich wieder bei openrc bin gab es das nie mehr.

On Topic:

Mir ist dieses neue "Feature" irgendwie bekannt vorgekommen:

http://lwn.net/Articles/562138/

Ich zitiere:

 *Quote:*   

> Step five would involve extending GLib and related GNOME libraries to support the sandboxed apps. In particular, the desktop needs to be able to recognize when a new app is uncompressed and mounted to the system, and treat its executables like a system-wide program, making it available in the application launcher, search framework, and so on. Step six would involve deploying a sandbox-aware display manager, presumably Wayland. Among other things, the display manager would need to support cut-and-paste and drag-and-drop, between sandboxed apps and the system. Step seven would involve defining a configuration scheme in dconf for sandboxed apps. 

 

Wohoo! Glück gehabt dass Lennart nicht schon dieses Konzept durchgedrückt hat. DAS hätte wirklich alles infiziert...

----------

## mv

 *franzf wrote:*   

> Das Problem war, dass irgend etwas verhindert hat, dass die Partitionen gemountet werden.

 

Das hatte ich auch schon etliche Male mit systemd.

Das kommt halt wegen der "tollen" Parallelisierung, die nachvollziehbares Verhalte und damit Debuggen prinzipiell unmöglich macht. Genau deswegen ist systemd für Rechner, die unbeaufsichtigt hochkommen müssen, prinzipiell ungeeignet.

Aber das ist ja nur einer von vielen fundamentalen Dilettantenfehlern im Konzept von systemd.

----------

## schmidicom

Wenn der Schreiber eines Units im selbigen die Abhängigkeiten nicht sauber hinterlegt kann systemd auch nichts dafür wenn etwas nicht in der richtigen Reihenfolge gestartet wird.

----------

## mv

 *schmidicom wrote:*   

> Wenn der Schreiber eines Units im selbigen die Abhängigkeiten nicht sauber hinterlegt kann systemd auch nichts dafür wenn etwas nicht in der richtigen Reihenfolge gestartet wird.

 

Es ist alleine die Schuld des Konzepts, dass es trotz eines Bugs beim Testen x-mal geht und dann, wenn es darauf ankommt, doch nicht geht - eben, dass es prinzipiell unmöglich ist, das Teil so zu testen, dass man sich irgendwann darauf verlassen kann.

Davon ab, ist es sehr wahrscheinlich sogar eine der mitgelieferten Units, die eine fehlende oder falsche Abhängigkeit hat, und zwar schon über etliche systemd-Versionen hinweg: Die aus der fstab generierten mount-Units schlagen manachmal schon fehl!

----------

## Klaus Meier

 *schmidicom wrote:*   

> Wenn der Schreiber eines Units im selbigen die Abhängigkeiten nicht sauber hinterlegt kann systemd auch nichts dafür wenn etwas nicht in der richtigen Reihenfolge gestartet wird.

 Ich dachte immer, es ist ein Feature von systemd, dass man keine Abhängigkeiten angeben muss wie noch bei sysVinit.

Das ist ja eines der am meisten beworbenen Vorteile von systemd, dass es das alleine regelt.

Aber ich finde es schön, dass wir es doch geschafft haben, das Ganze auf eine sachliche Ebene zu bringen und nicht über die Weltherrschaft und sonstige Dinge fabulieren.

----------

## schmidicom

Das systemd sowas automatisch erkennen kann ist mir neu, aber in der Unit-Sektion einer service-Datei lassen sich Abhängigkeiten, Konflikte und einiges mehr definieren.

http://www.freedesktop.org/software/systemd/man/systemd.unit.html

EDIT:

Wenn aber tatsächlich mal was schiefgeht könnte "systemd-analyze" helfen den Fehler zu finden.

Das Tool ist allerdings auch ohne ein Problem ziemlich interessant, einfach mal "systemd-analyze plot >> info.html" machen und im Webbrowser ansehen.

----------

## cryptosteve

Wie soll der normale User da noch durchsehen, welche Alternative die bessere bzw. richtigere ist. Da kann man echt nur hoffen, dass der Distributor für einen die bessere Wahl im default trifft.

----------

## py-ro

Den "normale" User (hat da nicht) Interressiert das nicht. Da soll es einfach nur funktionieren.

Bye

Py

----------

## Jean-Paul

 *py-ro wrote:*   

> Den "normale" User (hat da nicht) Interressiert das nicht. Da soll es einfach nur funktionieren.
> 
> Bye
> 
> Py

 Genau. Alle meine benutzten Init-systeme (sysvinit, bsd-init, ruint) haben einfach nur funktioniert. Erst mit systemd wurde das Ganze "Interessant", denn jetzt muss ich mir Gedanken machen was für ein Mammut ich installiert bekomme.

 *cryptosteve wrote:*   

> Da kann man echt nur hoffen, dass der Distributor für einen die bessere Wahl im default trifft.

  Sobald sich udev nicht mehr aus systemd extrahieren läßt, ist mittelfristig die Wahl für den Distributor gefallen.

----------

## mv

 *schmidicom wrote:*   

> Wenn aber tatsächlich mal was schiefgeht

 

Also im schwer nachvollziehbaren zufälligen Fall...

 *Quote:*   

> könnte "systemd-analyze" helfen den Fehler zu finden.

 

Es würde eher helfen, wenn man im nichtbootenden Fall die Logfiles anschauen könnte. Das wird aber durch ein weiteres Fehlkonzept von systemd - das binäre Logformat - erfolgreich verhindert. Auf den graphischen Firlefanz zur Aufbereitung der Logfiles würde ich liebend gerne verzichten, wenn ich in der Situation statt dessen auf logfiles zugreifen könnte.

Auch vor den binären Logfiles ist natürlich von den erfahrenen Leuten lange abgeraten worden.

Ähnliches Spielchen hatte ich gerade für jemandem, dem ich den Rechner "fernwarte": systemd ging nicht, openrc sehr wohl. In dem Fall kam systemd zwar noch so weit, dass man noch eine root-Shell starten konnte, aber lies dann mal die Logfiles über Telefon! Von openrc lesen geht ja nicht, weil die Logs ja unbedingt in einem #!"$§% Binärformat sein müssen. Weil dieses viel nützlicher ist, gerade für ein Boot-System   :Rolling Eyes: 

----------

## Pro_metheus

 *cryptosteve wrote:*   

> Wie soll der normale User da noch durchsehen, welche Alternative die bessere bzw. richtigere ist. Da kann man echt nur hoffen, dass der Distributor für einen die bessere Wahl im default trifft.

 

Also ich fühle mich als „normaler User“ 

Seit langem verichtet hier Gentoo seinen Dienst zufriedenstellend. Ich wüsste keinen Grund warum ich ein alternatives Init-System zu openrc bräuchte. Glücklicherweise setzt ja Gentoo NOCH auf openrc als default. Die Frage nach „Welches ist die bessere Alternative?“ stellt sich für mich gar nicht. Mit Grausen stelle ich mir aber vor, dass einem auch hier irgendwann systemd alternativlos vor die Nase gesetzt wird. Dann wäre für mich wohl nur noch ein anderes Betriebssystem eine Alternative.

 *py-ro wrote:*   

> Den "normale" User (hat da nicht) Interressiert das nicht. Da soll es einfach nur funktionieren.

 

Genau und Gentoo i.V.m. openrc funktioniert doch. Wozu als „normaler User“ also etwas verändern?

 *Jean-Paul wrote:*   

> Genau. Alle meine benutzten Init-systeme (sysvinit, bsd-init, ruint) haben einfach nur funktioniert. Erst mit systemd wurde das Ganze "Interessant", denn jetzt muss ich mir Gedanken machen was für ein Mammut ich installiert bekomme.

 

Bezieht sich das auf andere Linux-Distributionen oder auf Gentoo? Bei Gentoo musst du dir doch eigentlich nicht zwingend Gedanken machen, welches Init-System du nutzen möchtest. Es sei denn, du bist „Gnome-Nutzer“.

 *Quote:*   

> Sobald sich udev nicht mehr aus systemd extrahieren läßt, ist mittelfristig die Wahl für den Distributor gefallen.

 

Naja, da gäbe es ja noch das EUDEV Projekt, zumindest für Gentoo. Solange sich Entwickler darum noch kümmern, gibt es ja eine Wahl. Ich benutze eudev auf meinem Desktop-PC und habe (bei meinen zugegebenermaßen vielleicht nicht so hohen Ansprüchen) keine wirklichen Probleme/Einschränkungen damit.

Gruß

Pro_metheus

----------

## schmidicom

@Pro_metheus

Zum einen behauptest du das es dir egal ist und zugleich kannst du mit systemd nicht leben? Widerspruch lässt grüssen.

Scheint im übrigen eine weit verbreitete Krankheit in der "Freie Wahl um jeden Preis und egal wie lächerlich"-Fraktion zu sein.

----------

## py-ro

Ich behaupte einfach mal Gentoo Anwender sind keine gewöhnlichen Benutzer.

Persönlich setze ich beides ein OpenRC und Systemd, beides hat Vor- und Nachteile.

Notfalls wird halt der BSD Kompatibilitätslayer zu Systemd adaptiert. Es gibt jedenfalls keinen Grund sich über die Integration von Systemd zu beschweren. 

Im Endeffekt greift immer das Totschlagargument von OSS, wenn es dir nicht gefällt mache es selber oder änder es.

Bye

Py

----------

## Jean-Paul

 *Pro_metheus wrote:*   

> Bezieht sich das auf andere Linux-Distributionen oder auf Gentoo? 

 Unter Gentoo verwende ich openrc. Die angesprochenen Init-Systeme hatte ich unter CRUX am Laufen - ist aber schon wieder ein paar Tage her.

 *py-ro wrote:*   

> Persönlich setze ich beides ein OpenRC und Systemd, beides hat Vor- und Nachteile. 

 Da ist was dran.

 *py-ro wrote:*   

> Im Endeffekt greift immer das Totschlagargument von OSS, wenn es dir nicht gefällt mache es selber oder änder es. 

 Nein, das greift nicht (mehr). Du kannst dies nur ändern, wenn du genug Kohle == Manpower mitbringst. Hast du das nicht, musst du fressen (auf Deutsch gesagt) was sie dir vorsetzen. Hast du es, kannst du jedes Opersource-Projekt aushebeln.

 *schmidicom wrote:*   

> Scheint im übrigen eine weit verbreitete Krankheit in der "Freie Wahl um jeden Preis und egal wie lächerlich"-Fraktion zu sein.

 Warum wirst du hier jetzt persönlich ?

----------

## schmidicom

 *Jean-Paul wrote:*   

>  *schmidicom wrote:*   Scheint im übrigen eine weit verbreitete Krankheit in der "Freie Wahl um jeden Preis und egal wie lächerlich"-Fraktion zu sein. Warum wirst du hier jetzt persönlich ?

 

Ich wollte hier ein neues und OPTIONALES Feature von systemd diskutieren aber offensichtlich ist nicht einmal mehr das möglich ohne gleich eine Hexenjagd loszutreten.

----------

## cryptosteve

Ich kann keine Hexenjagd erkennen ...

----------

## Jean-Paul

 *schmidicom wrote:*   

> ... ohne gleich eine Hexenjagd loszutreten.

 Fühlst du dich verfolgt ?   :Very Happy: 

Musst du nicht. systemd wird mit aller Gewalt durchgedrückt, also freue dich.

Nur solltet ihr akzeptieren, dass nicht jeder diesen Dreck haben will. Weder freiwillig noch zwangsweise.

Und allen Haß und Hetze zu unterstellen die systemd nicht haben wollen, ist Größenwahn.

----------

## AmonAmarth

 *Jean-Paul wrote:*   

> 
> 
>  *py-ro wrote:*   Im Endeffekt greift immer das Totschlagargument von OSS, wenn es dir nicht gefällt mache es selber oder änder es.  Nein, das greift nicht (mehr). Du kannst dies nur ändern, wenn du genug Kohle == Manpower mitbringst. Hast du das nicht, musst du fressen (auf Deutsch gesagt) was sie dir vorsetzen. Hast du es, kannst du jedes Opersource-Projekt aushebeln.

 

Wenn man sich als Entwickler entsprechend der Unix Philosophie "Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen." hält, werden die Module selten zu groß. Das gleiche gilt ja auch für die klassische Softwareentwickung: Keiner will mit monolithischen Gott-Klassen arbeiten und diese erweitern. Dies ist ein bekanntes Anti-Pattern.

Mit ein wenig Erfahrung im Programmieren, konnte man bislang immer etwas beitragen, so lange das Projekt nicht unübersichtlich wurde. Jetzt kommt aber die Anti-Strömung mit den Gott-Subsystemen ins Spiel, wodurch ein unbezahlter Hacker nur noch schwerer durch die Materie kommt. Das heisst der Fall, dass man mit genug Manpower und Geld ein OpenSource-Projekt aushebeln kann, funktioniert nur wenn das Projekt selbst schon ein zu komplexer Haufen war. Auch wenn ich paranoid erscheine: IMHO wird gerade im Fall von SystemD das forciert.

----------

## Klaus Meier

Nun ja, 99% aller Poettering-Kritiker kommen mit Welt, Gott, Jesus. Sie wollen kein btrfs, weil es und von Red-Hat aufgezwungen wird. Na und so weiter.

Es ist schön, das es auch noch 2 gibt, die etwas zur Sache beitragen.

----------

## mv

Bewusst gelöscht.Last edited by mv on Sun Sep 14, 2014 2:50 pm; edited 1 time in total

----------

## Klaus Meier

Hei, mv, du bist nun mal genau jemand, der damit nicht gemeint war. Wieso fühlst du dich angesprochen? Wieso antwortest du darauf? Von dir kamen doch nachvollziehbare Argumente.

----------

## mv

 *Klaus Meier wrote:*   

> Wieso antwortest du darauf?

 

Stimmt; ich hätte es per PM schreiben solllen, nicht öffentlich - ist jetzt wieder gelöscht: Du warst längere Zeit nicht in den Foren und hast daher einige diesbezüglilche Diskussionen verpasst.

----------

## musv

 *mv wrote:*   

>  Von openrc lesen geht ja nicht, weil die Logs ja unbedingt in einem #!"$§% Binärformat sein müssen. Weil dieses viel nützlicher ist, gerade für ein Boot-System  

 

Ich hab nicht ausprobiert, ob man journald aus openrc heraus aufrufen kann. Sollte aber möglich sein. 

```
       -D DIR, --directory=DIR

           Takes a directory path as argument. If specified, journalctl will

           operate on the specified journal directory DIR instead of the

           default runtime and system journal paths.

       --file=GLOB

           Takes a file glob as an argument. If specified, journalctl will

           operate on the specified journal files matching GLOB instead of the

           default runtime and system journal paths. May be specified multiple

           times, in which case files will be suitably interleaved.
```

Damit sollte es möglich sein, über ein Rettungssystem, was ebenfalls eine systemd-Installation beinhalten muss, die Logfiles abzurufen.

 *Pro_metheus wrote:*   

> Ich wüsste keinen Grund warum ich ein alternatives Init-System zu openrc bräuchte. Glücklicherweise setzt ja Gentoo NOCH auf openrc als default.

 

2 Argumente:

WOL: Vor ein paar Jahren (2010, 2011 oder 2012) wurde bei OpenRC was an den Netzwerkscripten geändert. Seitdem funktionierte bei mir WOL nicht mehr. Mit ethtool konnte ich die Settings testen, war alles ok. Aber die Kiste wollte einfach nicht mehr hochfahren per WOL. Ich zweifelte am Treiber, versuchte sämtliche sonstigen Settingsstrohhalme. Der Bug wurde jahrelang nicht gefixt. Ich zweifel daran, dass es mittlerweile wieder funktioniert. Als ich dann auf Systemd umstieg, funktionierte es wieder out of the box. 

Boot- und Shutdownzeit: Ich weiß, dass das bei vielen Rechnern keine Rolle spielt. Bei meinem HTPC spielt es eine Rolle. Das Ding in den Suspendmodus zu schicken, ist mir nicht ganz so sympathisch. OpenRC im Parallelbootmodus funktionierte mal eine Zeit lang. Irgendwann klappte es nicht mehr. Und da ist halt Systemd wesentlich schneller und zuverlässig. Da ist mir auch egal, ob jetzt MySQL vor oder nach dem X-Server gestartet wird.

 *Pro_metheus wrote:*   

> Mit Grausen stelle ich mir aber vor, dass einem auch hier irgendwann systemd alternativlos vor die Nase gesetzt wird. Dann wäre für mich wohl nur noch ein anderes Betriebssystem eine Alternative.

 

Gut, du hast zur Auswahl: Apple, Windows, *BSD, irgendwelche Unixe, z.B. Solaris

Selbst Ubuntu und Debian steigen auf Systemd um. 

Einer der handwerklichen Fehler bei Systemd sind u.a. die schlecht geschriebenen Units für diverse Programme. Z.B. bei Pyload oder Pdnsd wurden die Dienste über umständliche Parameter in den Daemon-Dienst geschickt. Hatte damit so einige Probleme. Irgendwann hab ich dann die Systemd-Units selbst geschrieben und starte die Anwendungen einfach als simple Vordergrundanwendungen - und schon funktionierts.

Systemd und Journald haben noch viele Probleme (hab im anderen Thread über die permanent korrputen Journald-Logfiles geschrieben). Auch bleibt die Kiste bei mir beim Runterfahren selten hängen. Das Problem hatte ich mit OpenRC aber auch schon. 

Generell finde ich aber Systemd mittlerweile besser als OpenRC und die anderen Init-Systemd. Es fehlt aber durchaus noch einiges an Reife. 

Bei Journald seh ich das kritischer. Das Ding empfinde ich auch als Fehldesign. Da wurde die Featuritis über die Stabilität gestellt. Und Binärlog geht gar nicht. Ich hoffe, da wird noch nachkorrigiert.

----------

## Klaus Meier

Niemand wird zu journald gezwungen. Man kann auch unter systemd weiter mit syslog-ng arbeiten.

----------

## cryptosteve

 *Klaus Meier wrote:*   

> Man kann auch unter systemd weiter mit syslog-ng arbeiten.

 

Tatsächlich? Ich dachte, es sei der journald, der hier an syslog-ng durchreicht?

----------

## Klaus Meier

Man hat dann aber wieder die gewohnte Ausgabe. Ok, selber ausprobiert habe ich es noch nicht.

----------

## musv

 *Klaus Meier wrote:*   

> Niemand wird zu journald gezwungen. Man kann auch unter systemd weiter mit syslog-ng arbeiten.

 

Das ist die halbe Wahrheit. 

Journald läuft immer! 

Du kannst aber einstellen, dass die Ausgabe von Journald an Syslog durchgereicht wird. Nur finde ich die Vorstellung nicht besonders prickelnd, permanent 2 Logger am Laufen zu haben.

----------

## Klaus Meier

Stimmt, hatte ich etwas ungenau formuliert. Aber die Ausgabe von syslog-ng liegt dann doch wie gehabt in Textform vor, d.h., das Problem mit der Log-Datei im Binärformat könnte man damit schon mal umgehen.

----------

## mv

 *Klaus Meier wrote:*   

> Niemand wird zu journald gezwungen. Man kann auch unter systemd weiter mit syslog-ng arbeiten.

 

Leider hilft das in der Praxis nicht. Bei keinem der (nichttrivialen) Probleme mit Systemd kam es bisher so weit, dass metalog (das ist mein bevorzugter Log-Daemon) schon irgendwelche Daten geschrieben hätte; vermutlich wurde er bis zum Zeitpunkt des Hängens/Crashs/was-auch-immer noch gar nicht gestartet oder die Partition war noch readonly o.ä.

----------

## ulenrich

systemd-216 NEWS  :

* journald will no longer forward all local data to another

          running syslog daemon. This change has been made because

          rsyslog (which appears to be the most commonly used syslog

          implementation these days) no longer makes use of this, and

          instead pulls the data out of the journal on its own. Since

          forwarding the messages to a non-existent syslog server is

          more expensive than we assumed we have now turned this

          off. If you run a syslog server that is not a recent rsyslog

          version, you have to turn this option on again

          (ForwardToSyslog= in journald.conf).

Ich würde sagen: systemd ist noch lange nicht so gereift, dass die Benutzung in Sonderfällen über mehrere Versionen hinweg stabil und unverrückbar erscheint. Ich, normalo User, der sich kaum mit etwas beschäftigt, wenn es läuft, merke allerdings nichts davon. Bei mir löppts ...

Übrigens habe ich Ähnliches in den letzten Jahren bei Pulsaudio gemerkt: Die Einfachbenutzer, die nie etwas an Alsa Einstellungen geschraubt hatten, hatten auch weniger Probleme als die Profi Benutzer.

Zu Linus mit Zwinkern: Bei dem Vortrag von Linus auf der Debian Versammlung, kam mir auch die Idee, dass LP vielleicht nur das Guinea Pig von LT ist. Die LP Vision von differenzierteren Distributionen, die in Containern laufen, um den Applikationsentwicklern ihren ausgewählten und sicheren Rahmen zu geben, kommt ja ganz den Wünschen von Linus entgegen, die er dort auf der Versammlung geäußert hat. Und außerdem: Kann mir jemand erklären, wieso Linus dazu kommt, dorten bei den Debianesen zu behaupten, dass Pid 1 auch nichts allzu besonderes sei hinsichtlich Sicherheit ?

----------

## mv

 *ulenrich wrote:*   

> systemd-216 NEWS

 

Falls sich das auf meine Antwort beziehen sollte: Selbstverständlich habe ich besagte Option angestellt. Bei Gentoo bekommt man solche Default-Änderungen ja per etc-update (oder was immer man benutzt) automatisch mit...

----------

## mv

 *ulenrich wrote:*   

> Die Einfachbenutzer, die nie etwas an Alsa Einstellungen geschraubt hatten, hatten auch weniger Probleme als die Profi Benutzer.

 

Man schraubt nicht aus Spaß an der Freude an Alsa-Einstellungen, sondern weil z.B. die Hardware es benötigt; und mit systemd ist man dann halt angesch...

Ganz analog zu Windows: In 65% der Fälle geht es out-of-the-box, und der Rest hat halt Pech gehabt und kann nichts daran ändern.

Ich zumindest benutze Linux u.a., weil ich genau diesen Bochmist-Zustand ("plug and pray") nicht haben will, sondern Zuverlässigkeit schätze. Poettering-Software ist konzeptionell das genaue Gegenteil von Zuverlässigkeit.

----------

## mv

Die (für mich) jüngste Unverschämtheit der Systemd-Maintainer hat für mich jetzt endgülitig das Fass zum überlaufen gebracht.

systemd ist jetzt in hohem Bogen von der Platte geflogen, weil es offensichtlich nicht in der Lage ist, seinen Zweck zu erfüllen.

Ich werde auch keine Support-Anfragen bzgl. Systemd zu meiner Software mehr behandeln: Wer Support von mir will, soll ein vernünftiges Init-System benutzen.

Natürlcih ist mir klar, dass das kaum mehr als ein Symbol ist.

Ich habe inzwischen übrigens einen Bekannten, der sich nach jahrzehntelanger Fedora/Redhat-Treue nach der letzten Release zu einem Distributionswechsel genötigt sah.

Das hat mich schon einigermaßen überrascht, und daher vermute ich, dass er damit für eine nicht unbeträchtliche Anzahl von Nutzern steht.

Vielleicht bringt diese Abstimmung mit den Füßen Redhat tatsächlich zur Vernunft - sie können nicht wirklich daran interessiert gegen ihre eigene Community zu arbeiten.

----------

## SkaaliaN

 *mv wrote:*   

> Die (für mich) jüngste Unverschämtheit Vielleicht bringt diese Abstimmung mit den Füßen Redhat tatsächlich zur Vernunft - sie können nicht wirklich daran interessiert gegen ihre eigene Community zu arbeiten.

 

Ob das für sie wirklich relevant ist? Man weiß es nicht. Ich habe selten solch verbohrte Leute gesehen. 

Es kommt für die meisten immer auf den persönlichen Nutzen an. 

Bisher bin ich glücklicherweise komplett ohne systemd ausgekommen. Ich hoffe das es noch eine ganze Zeit so bleiben wird. Ich habe weder Lust, noch Interesse oder Zeit mich mit dem Monster zu beschäftigen.

Kollegen ging es im übrigen ähnlich. Die meisten haben keinerlei Interesse an Poetterware. Sie würden sogar Yosemite bevorzugen.

----------

## mv

 *metal1ty wrote:*   

> Ob das für sie wirklich relevant ist?

 

Ich meine die Entscheidungsträger bei Redhat, nicht die systemd-Maintainer. Was letztere herumstümpern, ist in dem Moment sofort egal, wenn Redhat den Eindruck hat, dass es ihren Geschäftsinteressen schadet. Und der Wegbruch der eigenen Community könnte zum Ziehen der Notbremse den Ausschlag geben.

Natürlich kann ich nicht beurteilen, inwiefern mein Bekannter ein Einzelfall ist.

----------

## SkaaliaN

 *mv wrote:*   

>  *metal1ty wrote:*   Ob das für sie wirklich relevant ist? 
> 
> Ich meine die Entscheidungsträger bei Redhat, nicht die systemd-Maintainer. Was letztere herumstümpern, ist in dem Moment sofort egal, wenn Redhat den Eindruck hat, dass es ihren Geschäftsinteressen schadet. Und der Wegbruch der eigenen Community könnte zum Ziehen der Notbremse den Ausschlag geben.
> 
> Natürlich kann ich nicht beurteilen, inwiefern mein Bekannter ein Einzelfall ist.

 

Naja...Redhat hat genug Enterprise Kunden. Die Frage ist, inwieweit sie überhaupt Wert auf ihre Com legen. Man kennt die Hintergründe nicht. Man kann nur spekulieren.

----------

## Klaus Meier

Wie wäre es denn, wenn man mal zielführend denkt und nicht immer nur schimpft und sich zurückzieht? Mein Fazit, nachdem ja nun wirklich Fakten auf den Tisch gekommen sind, sehe ich bei Pulseaudio als Hauptproblem, es ist von Poettering. Bei systemd kann ich die Aversionrn inzwischen verstehen.

Ok, systemd ist Scheiße. Kann man jetzt so sagen. Und was nun? Mit der nächsten Version von Debian und Ubuntu sind dann alle alle relevanten Distributionen auf systemd. Red Hat ist da natürlich schon ein Faktor. systemd kommt aus ihrem Haus und die Gruppe, von der Red Hat lebt, lehnt systemd am meisten ab. Nett für den Desktop, nicht geeignet für Server.

Aber es bringt jetzt nichts, den Kopf in den Sand zu stecken und zu sagen, dann gehe ich zu BSD. Die arbeiten nämlich auch schon dran. Und es bringt auch nichts, überall Gehhilfen dran zuschrauben, damit es irgendwie ohne systemd geht. Bei jeder Kleinigkeit einen Fork oder eine Insellösung ist auch nicht zielführend. Das musste Ubuntu schmerzhaft erleben.

Die Businesskunden von Red Hat könnten der Schlüssel zum Erfolg sein.

----------

## cryptosteve

Naja, (Open-)BSD baut an einem Kompatibilitätslayer, nicht an systemd. Dort sehe ich zunächst keine Gefahr, dass Logfiles nur noch in krudem Binärformat daher kommen.

----------

## franzf

Ein weiteres Problem (an das ich heute eher zufällig wieder erinntert wurde):

Wayland wird in dein meisten Fällen ebenfalls systemd voraussetzen. Martin Grässlin (kwin) hat das bereits so angekündigt. Bei Enlightenment wird es auch so sein. Für weston wurde es SWIW auch angekündigt.

Ich hoffe das ist dann auch keine direkte Abhängigkeit zu systemd sondern zu launchd, so dass man mit nem entsprechenden wrapper auch auf non-systemd-Systemen wayland verwenden kann.

----------

## ulenrich

 *Klaus Meier wrote:*   

> Ok, systemd ist Scheiße. Kann man jetzt so sagen. 

 

Kann man nicht so sagen. Ich weiss, dass Debians Entscheidung für systemd mit seiner debugging Fähigkeit zu tun hat. Auch wenn das hier bestritten wird. Die Entscheidung von Debian für systemD hatte nicht viel mit Gnome  zu tun. 

Wenn mv jetzt scheitert unter systemD Sachen zu machen, die systemD verbieten will, kann er nicht gleichzeitig behaupten, das systemD nicht funktionieren kann vom Konzept her. Mv's Link über die jüngste Unverschämtheit von LP zeigt das Jahr 2013, in dem die Kernel Entwickler LP vorgeschickt hatten das zurück zu nehmen, was sie selbst jahrelang mit den cgroups falsch angedacht hatten. Das ist wieder ein Argument für meine steile These, das LP nur das Guinea Pig der Altvorderen von kernel.org ist. Es stecken die Kernel Entwickler selbst hinter LP. Anders ist auch gar nicht zu erklären, wie er dazu kommt sich immer genau das Projekt als nächstes vorzunehmen, was anliegt von Seiten kernel.org

Zu Redhat ist zu sagen, dass Fedora nur das Spielfeld der Praktikanten ist. Die wichtigen Communities benutzen das Redhat Release, das auch umsonst als CentOS und Scientific Linux verbreitet wird mit offizieller Unterstützung seit neuerem. Wenn diese Communities sich gegen systemD entscheiden würden, dann erst wäre das ein Markstein. Redhat ist ein red herring hier im Forum. Es werden ganz banal-falsche Behauptungen gegen Redhat eingetrichtert, wie zB btrfs: Redhat hat sich für xfs mit Lvm Verwaltung der Speichereinheiten entschieden.

----------

## mv

 *ulenrich wrote:*   

> Kann man nicht so sagen.

 

Doch. Muss man sogar so sagen. Es ist schlecht konzipierter Unfug, von vornherein auf kaputten Ideen basierend.

 *Quote:*   

> Ich weiss, dass Debians Entscheidung für systemd mit seiner debugging Fähigkeit zu tun hat.

 

Du meinst, die tolle Fähigkeit, garantiiert kein reproduzierbares Verhalten zu erzeugen? Jeder mit ein bisschen Erfahrung weiß, dass das Grundkonzept von systemnd Debugging extrem erschwert. Ich habe es bereits erfahren dürfen und bin garantiert nicht der einzige.

Die Erklärung, die hier im Forum geeben wurde, klingt für mich wahrscheinlicher: Das Durchdrücken von systemd in Debian war ein Coup einiger Weniger unter geschickter Aushebelung der domakratischen Strukturen von Debian. Das ist nämlich die Fähigkeit, die Poettering tatsächlich hat - im Programmieren und erst recht im Konzipieren liegen seine Stärken definitiv nicht.

 *Quote:*   

> Wenn mv jetzt scheitert unter systemD Sachen zu machen

 

So unverschämte Sachen, wie sich auf einen Rehcner einzuloggen, etwas mit nohup zu starten und sich auszuloggen, ohne den nohup-Task zwingend abzuschießen.

 *Quote:*   

> die systemD verbieten will

 

Die sind ja nur aufgrund der Unfähigkeit der Entwickler "verboten".

Es ist ja wunderbar zu sehen, wie das Ganze zustande kam: Da haben die Entwickler "entdeckt", dass man mit cgroups ganze Prozessgruppen abschießen kann.

Das ist natürlich so toll, dass das zwingend für alles gemacht wird, ob sinnvoll oder nicht - schließlich hat man ja mit pam einen Gegenhack gefunden.

Dass Unix die Fähigkeit von Prozessgruppen und ihrer gemeinsamen Handhabung schon längst hatte - wen kümmert's, wenn es jetzt Linux-only und hackisch geht: Die Programme, die das bisher benutzt haben, werden einfach als fehlerhaft erklärt.

Das ganze ist ein so extrem dilettantisches Herumgestümpere - es wird einem einfach schelcht, wenn man die Unfähigkeit dieser Idioten sieht.

Und wie oft im Leben, kommen Dummheit und Frechheit halt zusammen: Die Entwickler sind nicht fähig oder willens ihre Fehler zu erkennen, sondern reagieren nur aggressiv, weil sie sie nicht wegleugnen können.

----------

## mv

 *ulenrich wrote:*   

> das zurück zu nehmen, was sie selbst jahrelang mit den cgroups falsch angedacht hatten.

 

Experimentelle Features heißen so, weil sie experimentell sind, und nicht von Idiioten in Kurzschlusshandlungen als Basis des gesamten Systems ohne Durchdenken der Folgen benutzt werden sollten.

Davon ab: War nicht sogar Kay Sievers von systemd die treibende Kraft hinter den cgroup (Fehl-)Entwicklungen?

 *Quote:*   

> Das ist wieder ein Argument für meine steile These, das LP nur das Guinea Pig der Altvorderen von kernel.org ist.

 

Für mich klingt es eher so, als wenn sich die Kernel-Entwickler genauso wie Debian von Kay Sievers und L.P. haben überrumpeln lassen und den fatalen Fehler begangen haben, den Unfug aufzunehmen. Wie gesagt: Das ist die tatsächliche Fähigkeit von L.P.

----------

## Yamakuzure

So wütend habe ich dich selten erlebt, mv. Schon starker Tobak, und ich müsste schmunzeln, wenn es nicht so verdammt wahr und traurig wäre.

Was kommt als nächstes? Werden alle meine Screen sessions beendet wenn ich mich vom Server abmelde? Mannmannmann so viel Unfug auf einmal...

----------

## musv

 *mv wrote:*   

> Das Durchdrücken von systemd in Debian war ein Coup einiger Weniger unter geschickter Aushebelung der domakratischen Strukturen von Debian.

 

Versuch der Sache mal was Positives abzugewinnen: 

Die Leute von Debian schätzt man ja eher konservativ ein. Debian ist nicht umsonst für seine Stabilität und das Pflegen schon längst eingemotteter Software-Pakete bekannt. Wenn als Debian jetzt Systemd übernimmt, könnte ich mir durchaus vorstellen, dass die Systemd mal etwas genauer durchleuchten. Und ich hab die Hoffnung, dass die Debian-Leute dann so einige Verbesserungen, Bugfixes, Diskussionen einbringen werden. Wird sich in der Hinsicht nichts tun, kann ich mir auch einen Fork vorstellen. 

Zumindest ich hab die Hoffnung, dass durch Debian Systemd durchaus qualitativ profitieren könnte. Mal sehen, was die Zukunft so bringt.

----------

## cryptosteve

Wäre es nicht sinnvoll gewesen, systemd erst ordentlich zu durchleuchten und sich dann dafür zu entscheiden?

----------

## mv

 *Yamakuzure wrote:*   

> Werden alle meine Screen sessions beendet wenn ich mich vom Server abmelde?

 

Ja, genau das ist der Fall.

tmux, screen, nohup benutzen alle die selben POSIX Mechanismen, die von systemd ausgehebelt wurden.

Falls es bei Dir nicht eintritt, dann benutzt Du pam, und Dich rettet nur ein sytemd-spezielles pam-Modul das möglicherweise von screen beim Starten aufgerufen wird, und das mit Rootrechten und Zugriff auf /proc die cgroups umsortiert, so dass das Abschießen der cgroup beim Ausloggen Dein screen nicht betrifft.

----------

## Jean-Paul

 *ulenrich wrote:*   

> Es werden ganz banal-falsche Behauptungen gegen Redhat eingetrichtert, wie zB btrfs

  Ja ich weiß, es wahr falsch zu behaupten Red Hat hätte btrfs verbrochen - Asche auf mein Haupt.

Nach meinen Informationen hat sich Debian nicht generell für systemd entschieden, sondern zunächst nur für das nächste Release. Und schon gar nicht einstimmig, sondern haarscharf "pro-systemd". Manche sagen auch per Dekret.

Ubuntu ist noch nicht umgestiegen und ob es in Release 14.10 kommt ist auch noch nicht klar.

----------

## ulenrich

Bei Debian war am Anfang des Entscheidungsprozesses jeder davon überzeugt, dass das technische Komitee aufgrund seiner Zusammensetzung sich für upstart entscheiden würde. Und die ersten Wochen der Diskussion zeigten auch diese Tendenz:

https://lists.debian.org/debian-ctte/2013/12/

Aber dann kam  Bdale Garbee

https://lists.debian.org/debian-ctte/2014/01/threads.html#00067

obwohl er starke Bedenken äußerte, hier zB:

https://lists.debian.org/debian-ctte/2013/12/msg00018.html

aber auch an anderen Stellen der Diskussion Unix philosophisch. Ich konnte in der ganzen Diskussion damals keine Einflußnahme von LP entdecken. Den Abstimmungsvorgang könnt ihr im darauf folgenden Februar, transparent offengelegt, selbst betrachten bis in alle Debian Ewigkeiten:

https://lists.debian.org/debian-ctte/2014/02/

 *Bdale Garbee wrote:*   

> There are things about OpenRC that I find really appealing, but I agree
> 
> that it seems too immature to even evaluate well, and thus I don't think
> 
> it is a credible alternative to be the default for Debian GNU/Linux. 
> ...

 

----------

## mv

Danke für die Geschichte und das Zitat. Das war mal interessant zu sehen, und das Zitat ist wirklcih ein Lehrstück in Rhetorik.

 *Bdale Garbee wrote:*   

> OpenRC [...] seems too immature to even evaluate well

 

Bei der Unsachlichkeit bleibt einem glatt die Spucke weg: Ein System, das auf praktisch allen Gentoo-Systemen seit Jahren in Einsatz ist, ist zu unreif um überhaupt in Betracht gezogen zu werden, aber ein frisch herausgekommenes sich ständig änderndes systemd ist es. Vor allem ist systemd deswegen so gut, weil es sogar Teile der Dependencies unterstützt, die das Grundkonzept von openrc sind...

Sehr geschickt, wie hier die Vorlieben der Gegner in Vorlieben auf systemd uminterpretiert und damit eine ganze Reihe von Argumenten als scheinbar ungültig interpretiert werden.

Weitere bekannte rhetorische Tricks: Bedenken der Gegner werden vorwegenommen (anti-portability rhetoric from Lennart, et al, particularly grating): Es werden also vermeintich Bedenken gegen den Portabilitätsverlust als gültig anerkannt. Dann ist es ja gar nicht so schlimm, dass in Wirklichkeit trotzdem die Portabilität auf den Mond geschosssen wird. Was für ein Kompromiss!

Auch die Einleitung ist natürlich wichtig: Dass man zu dem Ergebnis durch wochenlange objektive Analyse gekommen ist - nicht dass jemand meinen könnte, man wäre nicht objektiv und unabhängig.

Debian ist ganz offensichtlich auf einen guten rhetorischen Blender hereingefallen und hat sich über den Tisch ziehen lassen.

Auf jeden Fall ist das Zitat auch ein schöner Beleg für meine These, dass systemd nur durch Machtspielchen und Rhetorik durchgedrückt wird: Technische Argumente gab es in diesem "technischen" Kommitte für systemd praktisch keine.

----------

## ulenrich

 *mv wrote:*   

> Auf jeden Fall ist das Zitat auch ein schöner Beleg für meine These, dass systemd nur durch Machtspielchen und Rhetorik durchgedrückt wird: Technische Argumente gab es in diesem "technischen" Kommitte für systemd praktisch keine.

 

Ich habe oben das Ende der Diskussion angegeben. Die Argumente begannen hier:

https://lists.debian.org/debian-devel/2013/10/thrd2.html#00651

Auch openRC wurde ausgiebiger analysiert, zB ein Absatz in:

https://lists.debian.org/debian-ctte/2013/12/msg00234.html

----------

## mv

 *ulenrich wrote:*   

> Auch openRC wurde ausgiebiger analysiert, zB ein Absatz in:
> 
> https://lists.debian.org/debian-ctte/2013/12/msg00234.html

 

Das klingt vernünftiger als "too immature": Das sind die Schwächen von openrc. Schade, dass die hier in den Foren diskutierten Ansätze zur Lösung dieser Schwächen wie s6 damals nicht disktuiert wurden; vielleicht gab es das aber zu diesem Zeitpunkt noch nicht

----------

## ulenrich

 *mv wrote:*   

>  *ulenrich wrote:*   Auch openRC wurde ausgiebiger analysiert, zB ein Absatz in:
> 
> https://lists.debian.org/debian-ctte/2013/12/msg00234.html 
> 
> Das klingt vernünftiger als "too immature": Das sind die Schwächen von openrc. Schade, dass die hier in den Foren diskutierten Ansätze zur Lösung dieser Schwächen wie s6 damals nicht disktuiert wurden; vielleicht gab es das aber zu diesem Zeitpunkt noch nicht

 

Genau. Für Debian hätte ich mir gewünscht openrc wäre zumindest als Übergang genommen worden, weil es für alle Architekturen geht. Dann hätten wir ein fortschrittliches common ground openrc für alle Architekturen gehabt, und vielleicht später dann ein ausgereifteres systemD.

Dass Du mich nicht falsch verstehst, ich bin für systemD und halte Dein Scheitern in Punkto tmux für einen Erfolg bezüglich Sicherheit von systemD, was Du ja immer bezweifelt hattest schon vom Konzept her. Aber eben Dein UseCase zeigt auch, dass alternative init Mechanismen weiterhin ihre Berechtigung behalten.

----------

## mv

 *ulenrich wrote:*   

> und halte Dein Scheitern in Punkto tmux für einen Erfolg bezüglich Sicherheit von systemD, was Du ja immer bezweifelt hattest schon vom Konzept her.

 

Die beiden Punkte haben nichts miteinander zu tun:

Ob ich etwas "regulär" nicht machen kann, ist etwas völlig anderes, als ob ich das durch Ausnützen einer race-condition o.ä. bekommen kann. Nach Letzterem habe ich natürlich gar nicht gesucht, well ich eine saubere Lösung will und keinen Hack.

Ganz im Gegenteil: Dass die Hacks mit pam möglich sind, ja sogar als "normales" Verhalten vorgesehen werden, zeigt, dass die Komplexität schon wieder unnötig erhöht wurde, und die Zahl der möglcihen Exploits weiter enorm angewachsen ist.

----------

## fuchur

Hi

Gerade drüber gestolpert und passt hier rein:

http://www.zdnet.com/linus-torvalds-and-others-on-linuxs-systemd-7000033847/

MfG

----------

## Pro_metheus

 *ulenrich wrote:*   

> Genau. Für Debian hätte ich mir gewünscht openrc wäre zumindest als Übergang genommen worden, weil es für alle Architekturen geht. Dann hätten wir ein fortschrittliches common ground openrc für alle Architekturen gehabt, und vielleicht später dann ein ausgereifteres systemD.
> 
> 

 

Das ist eine sehr interessanter Ansatz. Ich sehe das eigentlich genauso und wundere mich warum man bei Debian nicht mal für eine Übergangszeit OpenRC eine Chance gegeben hat. 

Wenn ich diesen Beitrag richtig verstanden habe - https://wiki.debian.org/Debate/initsystem/openrc -

lässt sich ja eigentlich daraus schließen, dass es gar nicht mal einen so großen Aufwand bedeutet hätte, OpenRC + sysv-init unter Debian zu verwenden. Auch im Hinblick auf die Portierbarkeit zu GNU/kFreeBSD und GNU/Hurd.

Natürlich hätte noch einiges an Arbeit geleistet werden müssen aber letztendlich wäre es (aus meiner Sicht) doch ein zu vernachlässigender Aufwand gegenüber der sofortigen Integrierung von systemd gewesen.

Das es für OpenRC hinsichtlich der Weiterentwicklung einen zusätzlichen Anschub bedeutet hätte, kann man sich ja auch ausrechnen (Wenn man bedenkt das sich eine viel größere Community damit auseinander gesetzt hätte).

Aus meiner Sicht hat die sofortige Abkehr von OpenRC dann doch einen faden Beigeschmack. Man könnte annehmen, dass das Ganze doch eher politische (z.B. zurück zu Gnome als Standard Desktop) als rational sachliche Gründe hatte.

http://www.linux-community.de/Internal/Nachrichten/Gnome-als-Standard-Desktop-fuer-Debian-Jessie-noch-nicht-aus-dem-Rennen

Schade, dass hier OpenRC keine wirkliche Chance gegeben wurde. 

Grüße

Pro_metheus

----------

## franzf

Und dann ist es doch passiert...

http://uselessd.darknedgy.net/

----------

## mv

 *franzf wrote:*   

> Und dann ist es doch passiert...
> 
> http://uselessd.darknedgy.net/

 

Das klingt sehr gut! Da hat sich jemand wirklich Gedanken und eine Menge Arbeit gemacht:

Keine binären Logs, kein eigenmächtiges Interpretieren der fstab, kein kaputter fsck-wrapper, kein Setzen der lokalen Zeit (was auch so ein Krampf für sich war, der hier noch nicht angesprochen wurde), keine Zwangskopplung mit anderer Software wie cron, dhcp, automounter, usw. - der ganze Schwachsinn aus systemd wurde entschlackt, und zurück bleibt nur das, was sinnvoll ist.

uselessd+eudev klingt nach einer guten Kombination.

----------

## musv

 *ulenrich wrote:*   

> Für Debian hätte ich mir gewünscht openrc wäre zumindest als Übergang genommen worden, weil es für alle Architekturen geht. Dann hätten wir ein fortschrittliches common ground openrc für alle Architekturen gehabt, und vielleicht später dann ein ausgereifteres systemD.

 

Warum sollte man das? Welchen Vorteil hat es, ein "Zwischen-Init-System" einzuführen, um dann später sowieso auf Systemd zu wechseln? Da kann Debian auch gleich bei Sys-V bleiben. 

 *franzf wrote:*   

> Und dann ist es doch passiert...
> 
> http://uselessd.darknedgy.net/

 

Na huch, eine Seite vorher hab ich noch philosophiert, dass bei der Einführung von Systemd sowas passieren könnte. Und dabei gibt's dass dann sogar schon. Find ich klasse!

----------

## mv

 *musv wrote:*   

> Warum sollte man das? Welchen Vorteil hat es, ein "Zwischen-Init-System" einzuführen, um dann später sowieso auf Systemd zu wechseln?

 

Nicht auf systemd, sondern z.B. auf openrc+s6:

openrc hätte gegenüber Sys-V zunächst mal die klaren Vorteile, dass man Dependencies angeben kann, statt diese "händisch" durch nummerierung auflösen zu müssen: Dies war ja letztlich das Hauptargument, weshalb systemd gewählt wurde.

Der zweite Punkt ist die Kontrolle der Daemonen: Hier setzt openrc mit start-stop-daemon noch auf die PID-File-Technik, und das ist nicht gut. Dies ist die Schwäche von openrc. Aber gemäß der Unix-Philosophie - one job, one tool - sollte der "bessere" start-stop-daemon auch ein separates Projekt sein: Ein Tool, das tatsächlich die Daemonen überwacht und einen "Überblick" über alle hat. s6 ist so ein Projekt - vielleicht gibt es auch andere.

Es ist ein Klacks, statt start-stop-daemon das entsprechende Projekt (s6 oder was auch immer) in openrc aufzurufen; ggf. kann man sogar Support für mehrere solche Projekte anbieten.

Diese Lösung würde mir sogar noch wesentlich besser gefallen als uselessd, weil es die letzte unangebrachte Zwangskopplung aus systemd ebenfalls entfernt und - wichtiger: Man hat ein reproduzierbares Bootverhalten. Wenn man einmal erfolgreich bootet, kann man sich quasi darauf verlassen, dass das nächste Booten ebenfalls erfolgreich ist (zumindest weitestgehend: [e]udev ist noch so Unsicherheitsfaktor). Diese Reproduzierbarkeit ist gerade für Server oder ferngewartete Maschinen extrem wichtig.

----------

## Yamakuzure

 *franzf wrote:*   

> Und dann ist es doch passiert...
> 
> http://uselessd.darknedgy.net/

 Nett!

Passt irgendwie ein wenig dazu: http://boycottsystemd.org/

----------

## Randy Andy

Bin Heute Morgen auch schon recht früh durch Pro-Linux auf uselessd aufmerksam geworden:

http://www.pro-linux.de/news/1/21537/uselessd-erste-abspaltung-von-systemd.html

Bisher steht ja wohl nur ein aktiver Entwickler dahinter, würde mir aber wünschen dass sich dem noch viele anschließen und dass es, sobald es benutzbar ist, ein ebuild in den offiziellen tree gelangt.

Wäre doch eine sinnvolle Ergänzung zu eudev und unserer Gentoo-Philosophie bzgl. der Wahlfreiheit.

Über besagte uselessd Seite http://uselessd.darknedgy.net/ die ich übrigens recht konstruktiv finde, bin ich u.a. auch auf nosh gestoßen.

@mv als s6 Befürworter, wäre das was für Dich? http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html

Gruß, Andy.

----------

## mv

 *Randy Andy wrote:*   

> @mv als s6 Befürworter

 

Mit s6 speziell bin ich zu wenig vertraut, als dass ich dazu eine Meinung hätte. Ich hatte es halt als Beispiel genannt und ja gleich bemerkt, dass es durchaus Alternativen dazu geben könnte. Auf der nosh-Seite werden (neben nosh und s6) ja auch tatsächlich noch zwei weitere Alternativen genannt: runit und perp.

----------

## SkaaliaN

http://www.golem.de/news/lennart-poettering-systemd-gruender-kritisiert-furchtbare-linux-community-1410-109649.html

Da ist er wieder  :Smile: ......

 *Quote:*   

> 
> 
> Dass es viele Verwirrte im Internet gebe, also auch in der Open-Source-Community, würde gegen solche Ausführungen vorgebracht. Doch dem widerspricht der Hacker vehement, denn einige Dinge beförderten ein derart schlechtes Verhalten. Zum einen gebe es Gemeinschaften, so Poettering weiter, die das "Ablassen von Hass" akzeptierten und bestimmte Menschen anzögen, wie etwa Gentoo.
> 
> 

 

----------

## Klaus Meier

Ach... Ein Schlachter beschwert sich über die Schweine, die einfach nicht stillhalten wollen...

----------

## SkaaliaN

Wieso auch? Es gibt keine vertretbaren, plausiblen Gründe.

----------

## schmidicom

Er hat auch recht!

Einige in der Community benehmen sich tatsächlich so als ob sie auf einem heiligen Kreuzzug wären, vor allem dann wenn sie ihre alteingesessenen und auswendig gelernten Abläufe/Traditionen in Gefahr sehen.

----------

## cryptosteve

Wie ja bekannt ist, mag ich mein OpenRC und lehne systemd ausschließlich deshalb ab, weil ich keine Lust habe, mich in ein neues Initsystem einzuarbeiten und einige Grundideen daran nicht mag. 

Aber sowas muss nun wirklich nicht sein und gehört in meine wie auch immer geartete Community dieser Welt:

 *Quote:*   

> So bekomme der Entwickler Hass-Mails, es würden Petitionen gestartet, die Poettering zum Beenden seiner Arbeiten bewegen sollten, es seien sogar Bitcoins gesammelt worden, um einen Auftragsmörder zu engagieren. Darüber hinaus werde zum Boykott seiner Projekte aufgerufen, sehr häufig mit "persönlichen Angriffen". Per IRC erhalte er anstößige Nachrichten, die Verweise auf "Illustrationen im 4chan-Stil" enthielten.

 

Das Gentoo übermäßig viele Arschlöcher anzieht kann ich hingegen nicht bestätigen. Bei anderen Distributionen sind mir im deutschsprachigen Raum weit mehr komische Nasen begegnet und ich habe in allen Lagern auch viele gute Erfahrungen gemacht. 

Der Vorwurf speziell gegen Gentoo erwirkt etwas den Geschmack, als würde ihm Gentoo als eine der letzten Nicht-systemd-Bastionen nicht passen.

----------

## Klaus Meier

 *schmidicom wrote:*   

> Er hat auch recht!
> 
> Einige in der Community benehmen sich tatsächlich so als ob sie auf einem heiligen Kreuzzug wären, vor allem dann wenn sie ihre alteingesessenen und auswendig gelernten Abläufe/Traditionen in Gefahr sehen.

 

Aber da hat der Poettering ja wohl auch seinen Teil dazu beigetragen. Wer Wind sät, der wird Sturm ernten. Das steht so in der Bibel.

Das ist das größte Problem von Linux. Geniale Programmierer haben in den meisten Fällen Null soziale Kompetenz. Und deshalb platzen viele Projekte. Oder werden geforkt. Weil es da jemanden erst mal ums eigene Ego geht. Das beste Beispiel ist Schily. An sich ein genialer Kopf, aber in kein Projekt zu integrieren.

Nichts gegen pulseaudio und systemd, ich sehe beides positiv. Aber die Art und Weise, wie der Poettering da seinen Egotrip durchziehen wollte, da darf er sich jetzt nicht beschweren. Nicht jede Kritik an seinen Projekten ist ein heiliger Kreuzzug.

----------

## SkaaliaN

 *cryptosteve wrote:*   

> Wie ja bekannt ist, mag ich mein OpenRC und lehne systemd ausschließlich deshalb ab, weil ich keine Lust habe, mich in ein neues Initsystem einzuarbeiten und einige Grundideen daran nicht mag. 
> 
> Aber sowas muss nun wirklich nicht sein und gehört in meine wie auch immer geartete Community dieser Welt:
> 
>  *Quote:*   So bekomme der Entwickler Hass-Mails, es würden Petitionen gestartet, die Poettering zum Beenden seiner Arbeiten bewegen sollten, es seien sogar Bitcoins gesammelt worden, um einen Auftragsmörder zu engagieren. Darüber hinaus werde zum Boykott seiner Projekte aufgerufen, sehr häufig mit "persönlichen Angriffen". Per IRC erhalte er anstößige Nachrichten, die Verweise auf "Illustrationen im 4chan-Stil" enthielten. 
> ...

 

Das Thema auf einzelne Distributionen zu differenzieren ist äußerst fragwürdig und stellt die geistige Reife eines Poettering in Frage.

Aber vielleicht ist das wirklich die Ursache:  Als würde ihm Gentoo als eine der letzten Nicht-systemd-Bastionen nicht passen.

Sorry...aber das ist Kinderkram....Anders kann man es nicht nicht nennen. Er jammert vor sich hin, wie ein trotziges Kind, welches seinen Willen nicht bekommt.

Die gehen dann auch bei Mami knatschen.

----------

## mv

 *metal1ty wrote:*   

> Sorry...aber das ist Kinderkram....Anders kann man es nicht nicht nennen

 

Wenn das mit den Morddrohungen und der Bitcoin-Aktion simmt, ist das kein Kinderkram. Eine solche Aktion (ob Ernst gemeint oder nicht) gegen die Person ließe wirklich jegliches Maß vermissen.

Zum Hass von L.P. auf Gentoo: Ich glaube, er hat hier im Forum mal ein paar Tage unter einem Pseudonym übel herumgetrollt, und ist dafür ziemlich kräftig abgewatscht worden.

----------

## Klaus Meier

Nun ja, aber mit so einem Beitrag kocht er die Stimmung doch wieder hoch. Er tut das, über was er sich beschwert.

Und sein Hass auf Gentoo? Wo gibt es denn sonst noch Anwender, die überhaupt wissen, was ein init-System ist, was es tut und welches sie haben? Meinst du, bei Ubuntu wird es jemanden auffallen, wenn sie von Upstart zu Systemd wechseln? Gentoo ist die einzige Distribution, wo sich die Anwender mit dem Thema beschäftigen.

----------

## Erdie

Laut  Golem schreibt er, die Linux Community bestehe "überwiegend aus westlichen, weißen und heterosexuellen Männern".  Und was soll das nun? Was hat das eine mit dem anderen zu tun? 

Übrigens werden solche Schubladen gern in radikalfeministischen hate - speech Seiten und Büchern ausgezogen. Wem das hier evtl nichts sagt. Das sind z. B. "literarische" Werke in denen die weltweite Reduzierung aller Männer bis auf 10% als Allheilmittel gegen die Problem unserer Welt propagiert werden - garniert mit diversen Literaturpreisen. Interessant, dass der gute Mann sich solcher Floskeln bedient ..

Irgendwie wird er mich immer unsympatischer  :Wink: 

----------

## l3u

Schöner als Kino …

----------

## fuchur

Hi

 *cryptosteve wrote:*   

> 
> 
> Aber sowas muss nun wirklich nicht sein und gehört in meine wie auch immer geartete Community dieser Welt:
> 
>  *Quote:*   So bekomme der Entwickler Hass-Mails, es würden Petitionen gestartet, die Poettering zum Beenden seiner Arbeiten bewegen sollten, es seien sogar Bitcoins gesammelt worden, um einen Auftragsmörder zu engagieren. Darüber hinaus werde zum Boykott seiner Projekte aufgerufen, sehr häufig mit "persönlichen Angriffen". Per IRC erhalte er anstößige Nachrichten, die Verweise auf "Illustrationen im 4chan-Stil" enthielten. 

 

Erst einmal ist das nur eine Behauptung ohne beweise nicht mehr und nicht weniger.

Des weiteren, ich habe vor Jahren mal ein Video gesehen wo er bei einem Vortag unter den Zuschauern wahr, und in einer

für mich sehr großkotzigen und Klugscheißer Art Kommentare und/oder Fragen abgegeben hat die seine (soziale) Kompetenz

sehr gut zum Ausdruck brachte. Ich denke mal es würde ihn weiter bringen wenn er erst einmal an seine Verhalten arbeiten

(wofür es aber jetzt wohl schon zu spät ist).

MfG

----------

## Fijoldar

Warum er jetzt ausgerechnet Gentoo erwähnen muss, verstehe ich auch nicht. In der Arch Linux Community gibt es mindestens genauso viele, denen systemd nicht passt. Man muss sich nur mal in deren Foren umschauen, da findet man genauso Diskussionen wie hier.

Ansonsten finde ich persönliche Angriffe absolut unangemessen. Man kann systemd finden wie man will, aber unter dem Strich hat L.P mehr erreicht als so manch anderer. Wenn dann Angriffe auf die Person stattfinden, schießt das definitiv über das Ziel hinaus. Dass er sich jetzt aber wundert, warum es in der Linux Community genauso Arschlöcher gibt wie überall sonst auf der Welt, ist schon etwas naiv.

----------

## cryptosteve

Das dürfte dann wohl dieses Video gewesen sein: https://www.youtube.com/watch?v=ZTdUmlGxVo0

Ja, das ist eine sehr zweifelhafte Sache gewesen und so ist der Poettering halt. Von daher darf er schon keine zarte Behandlung erwarten. Tut er ja aber auch nicht. 

Poettering ist ja auch nicht das Problem. Würde keine weitere Distribution auf systemd aufsteigen, gäbe es gar kein Problem. Das Problem haben ja die, die um ihr liebgewonnenes (altes) Initsystem fürchten, weil sich systemd viral überall breit macht.

----------

## AmonAmarth

Ich bin passenderweise heute auch noch auf folgendes gestoßen:

http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI

Den unteren Abschnitt (und die Originalquellen) muss man sich mal auf der Zunge zergehen lassen: Er stellt das so dar, dass kdbus bald in den kernel gemerged wird und danach keinen support mehr für udev mit nicht-systemd installationen geben wird.

Also wenn das nicht mal ein Versuch ist, den Rest der Linuxwelt zu zwingen auf den systemd-Zug aufzuspringen ("Gentoo folks, this is your wakeup call.").

EDIT: 

Das Zitat ist ja auch scharf:

"The Linux community is dominated by western, white, straight, males in their 30s and 40s these days. I perfectly fit in that pattern, and the rubbish they pour over me is awful. I can only imagine that it is much worse for members of minorities, or people from different cultural backgrounds, in particular ones where losing face is a major issue." 

Soll das implizieren das die Gentoo User Neonazis sind? Das hat er zwar nicht direkt geschrieben, aber das ist es doch was jetzt der Rest der Welt denken soll... In Rhetorik ist der Typ gut, aber das wars auch schon

----------

## franzf

Im OTW hat tatsächlich einer den Bitcoin-Auftragsmord ausgegraben:

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

Irgendwie hab ich mir ja schon gedacht, wie ernst die Sache ist. War ihm wohl wichtig möglichst fundiert und ernst über Gentoo herzuziehen, nachdem von da zum systemd-Boycott aufgerufen wurde und schlussendlich systemd geforkt wurde.

----------

## l3u

 *AmonAmarth wrote:*   

> Er stellt das so dar, dass kdbus bald in den kernel gemerged wird und danach keinen support mehr für udev mit nicht-systemd installationen geben wird.

 

Die Entscheidungsgewalt, was wann wie in den Kernel kommt, hat Herr Poettering ja glücklicherweise noch nicht. Und nach allem, was ich gelesen habe, ist Herr Torvalds ja auch nicht immer zu 100 % einverstanden mit dem, was er macht.

Bleibt zu hoffen, dass es zu all dem eine vernünftige Lösung geben wird. Ich für meinen Teil lebe ja ganz gut mit dem, was Gentoo derzeit macht. Und ich sehe auch derzeit nicht die unbedingte Notwendigkeit, etwas daran zu ändern …

----------

## forrestfunk81

Und da kommt auch schon der nächste Schritt zum SystemD OS: add user console daemon

 *Quote:*   

> This adds a first draft of systemd-consoled.

 

Mal schaun, wann ein Bootmanager auch noch integriert wird. Bald braucht man nur noch drei Sachen für ein funktionierendes Linux*: Kernel, Systemd und Gnome. Und die Distributionen merken nicht, dass sie sich durch den Schwenk auf Systemd bald obsolet machen.

*Ja ich weiß, dass Linux=Kernel ist und der Rest 'nur' Userspace.

----------

## schmidicom

Die Gründe warum die Console im Userspace besser aufgehoben wäre wurden doch schon mit "sys-apps/kmscon" deutlich gemacht, was jetzt also daran so schlimm sein soll verstehe ich echt nicht.Last edited by schmidicom on Thu Oct 09, 2014 1:23 pm; edited 1 time in total

----------

## mv

 *schmidicom wrote:*   

> Die Gründe warum die Console im Userspace besser aufgehoben wäre

 

Es geht doch nicht um Userspace vs. Kernelspace. Es geht darum, dass schon wieder ein Programm, das naturgemäß ein unabhängiges Binary sein sollte (ebenso wie dhcp, mount, ntp, ...), künstlich und nur aus politischen Gründen nach systemd verschoben wird, damit man es auch ja nicht unabhängig von systemd installieren/nutzen/patchen kann.

----------

## schmidicom

Ja und, das betrifft dann doch sowieso nur jene die systemd auch benutzen. Alle anderen die lieber OpenRC, uselessd oder den kommenden systemd-Kompatibilitätslayer von BSD verwenden sind davon doch sowieso nicht betroffen. Wozu also die Aufregung?

EDIT:

Das ganze Vorhaben scheint schon länger in Planung zu sein:

http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html

----------

## forrestfunk81

In anderen Threads dieses Forums sieht man ja schon, wie schwer man sich tut bash durch andere Shells zu ersetzen. Viele Skripte setzen Bash vorraus indem sie Bash-spezifische Erweiterungen nutzen. Was denkst Du passiert wohl, wenn sich consoled entsprechend weit verbreitet. Es bahnt sich an, dass man irgendwann keine Wahl mehr hat.

Ich nutze Systemd auch auf zwei (von fünf) Systemen und finde es hat durchaus auch Vorteile. Aber wie dort alles einverleibt wird und Alternativen unterbunden werden geht mir ordentlich auf die Nerven.

----------

## schmidicom

Ich müsste mich jetzt grausam irren aber consoled soll doch nur ein Ersatz für CONFIG_VT werden und keine eigene Shell.Last edited by schmidicom on Fri Oct 10, 2014 8:07 am; edited 1 time in total

----------

## musv

Ist korrekt. Btw. von kmscon hab ich bisher noch gar nichts gehört. 

Nutzt das schon jemand? Ist das empfehlenswert?

----------

## schmidicom

Ich habe es mal eine Zeit lang ausprobiert aber abgesehen von einer gefühlt leicht sanfteren Darstellung der Schrift ist mir kein Unterschied zu agetty aufgefallen. Wirklich testen kann man kmscon vermutlich eh erst wenn CONFIG_VT im Kernel nicht mehr, aufgrund diverser Abhängigkeiten, zwangsweise aktiviert sein muss.

----------

