Boycott Systemd

[goblin]

In Anbetracht der Featuritis von systemd […]

Danke, dass dies auch endlich mal von einem der systemd-Verfechter zu hören ist

Welche Alternativen für das Session Management hätte GNOME denn gehabt?

Was ist denn mit policykit/polkit? Das haben wir doch genau dem freedesktop.org/GNOME/Red Hat-Dunstkreis zu verdanken.
Jetzt gibt es nach policykit-polkit einen weiteren API-Bruch.
Gut, dass den GNOME-Leuten alle anderen Entwickler und Admins vollkommen egal sind, sollte inzwischen den meisten klar geworden sein, aber das ständige Neuschreiben elementarer Schnittstellen erscheint mir aus Entwicklerperspektive wenig produktiv.

Angeblich sind keine Kapazitäten da, andere Backends zu pflegen. Aber die Kapazitäten, des öfteren Jahre neue Backends zu schreiben, die hat man?

 

[Yamagi]

Selbst im traditionell sehr IBM-lastigen Finanzsektor gibt es aufgrund der in vielen Bereichen indiskutablen Software- und Support-Qualität reichlich Migrationsprojekte weg von IBM - ich arbeite gerade als Softwareentwickler in einem (inklusive Migration von AIX V7.1 zu voraussichtlich RHEL 7, ich hatte es mal angedeutet). Das wird sich durch den personellen Kahlschlag von IBM nur noch verschärfen.

Nun, IBM und HP sind im Moment auch die Paradebeispiele dafür, wie eine kurzfristige Fokussierung auf Quartalszahlen ein Unternehmen langsam aber stetig zu Grunde richten kann. Beide waren mal große IT-Konzerne, heute bestehen sie zu großen Teiler aus heißer Luft.

Bei uns ist gerade im Rahmen des obigen Migrationsprojekts die Verprobung von RHEL 7 (dementsprechend systemd v208) als unternehmensweiter Server-Plattform im Gange.

Red Hat hat die Kinderkrankheiten (wie z.B. unzuverlässig startendes Netzwerk) inzwischen gut im Griff. Allerdings ist der Punkt hier die v208. Es war die letzte Version, die man als reinen Service-Manager betrachten kann. Eine Sache, die systemd gar nicht so schlecht macht. Und ich glaube, wenn die Entwickler bei dem Feature-Set geblieben wären und es lediglich weiterentwickelt bzw. verfeinert hätten, gäbe es auch diese ganze Diskussion nicht. Das Problem liegt viel mehr darin, dass die in den folgenden Versionen begannen frei zu drehen und ohne erkennbare Strategie immer größere Teile des Linux-Userland zu assimilieren. Wobei alte, stabile Komponenten oft durch Implementierungen ersetzt wurde, die oft nur einen Bruchteil des Funktionsumfangs implementieren und zudem fehlerhaft sind. Das systemd v218 in Archlinux wirkt zum Beispiel so unfertig wie eine späte Alpha-Version.
Und wie ich schrieb, mag es daran liegen, dass Red Hat im Moment keine stabile Version benötigt. RHEL 7 hat die v208 und ein RHEL 8 ist noch in weiter Ferne. Also wird experimentiert. Irgendwann rechtzeitig vor RHEL 8 wird man schon beginnen, die dann aktuelle Version zu stabilisieren, sich als falsch herausgestellte Features wieder zu eliminieren und so weiter. Ein Großteil der Diskussion um systemd entsteht darum, dass hier eine große Zahl an Distributionen als Beta-Tester missbraucht werden bzw. ihre Nutzer missbrauchen. Und, das muss man klar sagen, sie es auch mit sich machen lassen.

 

[chaos]

Und wie ich schrieb, mag es daran liegen, dass Red Hat im Moment keine stabile Version benötigt. RHEL 7 hat die v208 und ein RHEL 8 ist noch in weiter Ferne. Also wird experimentiert. Irgendwann rechtzeitig vor RHEL 8 wird man schon beginnen, die dann aktuelle Version zu stabilisieren,

So hatte ich das noch nicht gesehen, hört sich aber sehr schlüssig an.

Ein Großteil der Diskussion um systemd entsteht darum, dass hier eine große Zahl an Distributionen als Beta-Tester missbraucht werden bzw. ihre Nutzer missbrauchen. Und, das muss man klar sagen, sie es auch mit sich machen lassen.

und es nichteinmal merken.

 

[Athaba]

Aber irgendwie trennt man damit sogar ein wenig den Spreu vom Weizen. Gentoo und Slackware folgen dem nicht. Bei Arch Linux hat mittlerweile fast jeder User eine eigene Implementierung von init herausgebracht. Man mag es kaum glauben, aber es gibt da echt Leute, die das zum Anlass nehmen Systemprogrammierung zu lernen. Hat also auch was Gutes.

 

[mrtonik]

... Bei Arch Linux hat mittlerweile fast jeder User eine eigene Implementierung von init herausgebracht. ...

Der erster Antwortpost dort hat schon wieder einen Hut verdient:

That's actually kind of awesome… Really tempted to put this on my laptop and see how fast of a boot I can manage…

 

[TCM]

Ja, nichts wünsche ich mir sehnlicher, als dass essentielle Systemsoftware von Leuten geschustert wird, die es als "Lernprojekt" verstehen. Denn wenn man alle naselang etwas braucht, dann sind es frische Ideen, wie man Sachen von Grund auf neumacht. Die Anderen haben ja eh keine Ahnung.

:>

 

[goblin]

Ja, nichts wünsche ich mir sehnlicher, als dass essentielle Systemsoftware von Leuten geschustert wird, die es als "Lernprojekt" verstehen. Denn wenn man alle naselang etwas braucht, dann sind es frische Ideen, wie man Sachen von Grund auf neumacht. Die Anderen haben ja eh keine Ahnung.

Der Unterschied ist aber, dass er keine Distro betreut, die geschlossen alle ihre Benutzer zu unfreiwilligen early-adoptern macht...
Und der Post klang jetzt nicht so, als sei alles andere "deprecated" und nur epoch sei die einzige valide Wahl.

 

[Athaba]

Ging mir mehr darum, dass es Nachschub an Entwicklern gibt, was ich gut finde. Nicht, dass es irgendwann nur noch Web- und App-Entwickler gibt.

 

[goblin]

Ging mir mehr darum, dass es Nachschub an Entwicklern gibt, was ich gut finde. Nicht, dass es irgendwann nur noch Web- und App-Entwickler gibt.

Siehst du, ich bin zu faul und anstatt was Eigenes zu bauen hab ich auf FreeBSD umgesattelt...

Edit: Andererseits hatte ich auch keine Sehnsucht nach einem neuen, sondern nach einem stabilen Init-System.

 

[Azazyel]

Ich brauche Logs auch, wenn wenig Tools zur Verfügung stehen und sie sollen textbasiert sein, sonst werde ich wahnsinnig damit.

Das ist problemlos mit systemd möglich - und man kann das beste beider Welten haben: indizierte und einfach auswertbare Binär-Logs ohne grep-Orgien und Text-Logs gleichzeitig.

Ein Dienst soll abstürzen und das System soll mir sagen, dass er nicht mehr läuft

Das kann SysVinit/BSDinit leider nicht zuverlässig und wird es auch nie können.

Ich betrachte gerne die Essenz aus der Sache und gucke, ob ich mehr Probleme habe als zuvor.

Dito. Meine Anwendungsfälle bringen die vielen Defizite von SysVinit/BSDinit zum Vorschein. Für mich löst systemd reichlich Probleme und macht das Gesamtsystem insgesamt zuverlässiger und besser administrierbar.

Danke, dass dies auch endlich mal von einem der systemd-Verfechter zu hören ist

Ich hatte es schon einmal erwähnt. Wobei man mich die vielen Projekte unter dem systemd-Mantel nicht stören, davon beschäftigt sich ja nur ein Teil mit dem init-System. Ich sehe unter dem systemd-Mantel nur deutlich interessantere Projekte als systemd-readahead.

Was ist denn mit policykit/polkit?

Das beherrscht kein Session-Management und deckt nur einen Bruchteil der benötigten Features ab (vgl. "How does systemd relate to Plasma").

Gut, dass den GNOME-Leuten alle anderen Entwickler und Admins vollkommen egal sind, sollte inzwischen den meisten klar geworden sein, aber das ständige Neuschreiben elementarer Schnittstellen erscheint mir aus Entwicklerperspektive wenig produktiv.

In einem (im Linux/BSD-Umfeld) bislang sehr unausgereiften Gebiet wie dem Session Management hat man halt die Wahl:

1. Alles lassen wie es ist und damit leben, dass es beschissen funktioniert.
2. Das alte Zeug mit enormen Aufwand auf aktuelle Bedürfnisse umbiegen und trotzdem nicht einmal 70% abdecken, aber weiterhin Workarounds an allen Ecken und Enden mitschleppen - im Backend und in den Anwendungen.
3. Eine neue Schnittstelle anbieten, die ohne Probleme 90% der Anforderungen abdeckt und den Anwendungen ermöglicht, abertausende von Zeilen dann unnützen Code zu entfernen und die Pflege und Wartung der Anwendungen und des Backends deutlich zu vereinfachen. Dafür müssen die Anwendungen auf die neue Schnittstelle umsteigen.

Welchen der Tode möchte man sterben?

Angeblich sind keine Kapazitäten da, andere Backends zu pflegen. Aber die Kapazitäten, des öfteren Jahre neue Backends zu schreiben, die hat man?

Wenn sich die Voraussetzungen, Anforderungen und Rahmenbedingungen stark gewandelt haben, ist das Neuschreiben in vielen Fällen weniger Aufwand als auch nur moderate Anpassungen am alten Backend vorzunehmen. Zumal man in letzterem Falle dann immer noch schwer wartbaren Code an der Backe hat.

Der Unterschied ist aber, dass er keine Distro betreut, die geschlossen alle ihre Benutzer zu unfreiwilligen early-adoptern macht...

Bei Arch Linux kann man nicht von unfreiwillig reden - genau dafür setzt man es ein.

 

[darktrym]

Hab ich was nicht mitbekommen, Systemd benutzt doch Binary-Logs? Es bringt nur seine Tools mit um den Stream dann mit grep abzuarbeiten. Ohne Systemd ist man aufgeschmissen.

 

[nakal]

Das ist problemlos mit systemd möglich - und man kann das beste beider Welten haben: indizierte und einfach auswertbare Binär-Logs ohne grep-Orgien und Text-Logs gleichzeitig.

Ich kann mir nur schwer vorstellen, solche Binärlogs nach logischen Ausdrücken durchzusuchen, die Negationen, Verundungen und Veroderungen beinhalten. Sowas wie schnelle Infos in der Form: "ich brauche alle Zeilen, die auf URL-Substring /cgi zugreifen, aber nicht mit URL "/cgi" anfangen" oder "ich brauche alle Usernamen der IMAP-Nutzer, die sich per IMAP aus Netz 192.168.1 oder 192.168.2 angemeldet haben im letzen und laufendem Monat". Wenn Text-Logs stets vorhanden sind, ist OK. Ich verstehe dann allerdings nicht, die ganzen Posts von aufgeregten Nutzern, die kein systemd auf einer Live-CD haben und die Logs inspizieren wollen von Systemen, die sich nicht mehr starten lassen.

Das kann SysVinit/BSDinit leider nicht zuverlässig und wird es auch nie können.

Ein Dienst stürzt ab, dann sehe ich in den Logs einen Core-Dump, eventuell mit vorhergehenden protokollierten Fehlern falls der Dienst sauber genug implementiert ist. Schon zig mal gesehen. Es ist auch ganz einfach sich eine Übersicht von laufenden Diensten zu besorgen. Es ist keine Wissenschaft da ein Diff drüber zu machen.

Dito. Meine Anwendungsfälle bringen die vielen Defizite von SysVinit/BSDinit zum Vorschein. Für mich löst systemd reichlich Probleme und macht das Gesamtsystem insgesamt zuverlässiger und besser administrierbar.

Als ich systemd ausprobiert habe, wurde ich erstmal von Race-Conditions gegrüßt (NFS-Mount-Versuche vor Netzwerk-Schnittstelle "up" usw). Workarounds in fstab haben nicht funktioniert, weil in systemd die Funktionen entfernt worden sind, um solche Race-Conditions zu regeln. Fakt ist, ich konnte nicht einmal den PC ausschalten, der ging immer wieder an... es sei denn ich hab den ATX-Switch hinten auf AUS geschaltet. Zuverlässigkeit ist da keine. Administrierbar ist es erst, wenn ich zum Beispiel weiß, wie ich 2 DNS-Server Instanzen auf einem Host laufen lassen kann und zwar so, dass mir die Distribution beim nächsten Update meine Konfiguration nicht wieder zerschnibbelt.

 

[TCM]

Das ist problemlos mit systemd möglich - und man kann das beste beider Welten haben: indizierte und einfach auswertbare Binär-Logs ohne grep-Orgien und Text-Logs gleichzeitig.

Ja, problemlos, solange Klein-Lennys Machwerk sich nicht besabbert und die Logs kaputtmacht und Klein-Lenny dann nur meint "*schulterzuck* fixen wir nicht".

https://bugs.freedesktop.org/show_bug.cgi?id=64116

Nicht wahr? Sowas brauch ich auf dem Server. NOT.

 

[Azazyel]

Hab ich was nicht mitbekommen, Systemd benutzt doch Binary-Logs?

ForwardToSyslog in Verbindung mit Storage=none reicht Meldungen ausschließlich an syslog durch und erzeugt keine Binär-Logs. Selbst erzeugt systemd aber keine Text-Logs.

Es bringt nur seine Tools mit um den Stream dann mit grep abzuarbeiten.

Siehe Journal File Format. Mit grep wäre [123] als PID und [123] als Logtext nur mit Verrenkungen zu unterscheiden.
Mit journalctl -o verbose kann man alle Felder anzeigen; default ist journalctl -o short, was verdächtig an den syslog-Output erinnert.

Ohne Systemd ist man aufgeschmissen.

Mit strings /var/log/journal/<file> | grep ^MESSAGE= bekommt man das Äquivalent des syslog-Outputs.

"ich brauche alle Usernamen der IMAP-Nutzer, die sich per IMAP aus Netz 192.168.1 oder 192.168.2 angemeldet haben im letzen und laufendem Monat"

Mit z.B. journalctl --since 2015-01-01 --until now _SYSTEMD_UNIT=dovecot.service kannst du zwei Drittel davon erschlagen und den Rest immer noch durch die üblichen verdächtigen Tools jagen. Klartext-Output semantisch analysieren kann natürlich auch systemd nicht.

Ein Dienst stürzt ab, dann sehe ich in den Logs einen Core-Dump, eventuell mit vorhergehenden protokollierten Fehlern falls der Dienst sauber genug implementiert ist.

Nicht jeder Dienst verabschiedet sich mit einem Core-Dump. Manche verabschieden sich ganz sang- und klanglos. Die will man als Admin aber auch mitkriegen - und vielleicht sogar automatisch neustarten lassen.

Administrierbar ist es erst, wenn ich zum Beispiel weiß, wie ich 2 DNS-Server Instanzen auf einem Host laufen lassen kann.

Mit Service-Instanzen.

und zwar so, dass mir die Distribution beim nächsten Update meine Konfiguration nicht wieder zerschnibbelt.

Klingt mehr nach einer Eigenheit der Distribution, die Konfigurationsdateien ohne Vorwarnung überbügelt. Arch Linux lässt grüßen.

 

[Athaba]

Also ich weiß nicht. Ich gehe in letzter Zeit ziemlich viel über systemd service files und ich verstehe nicht was da einfacher, besser oder sonst was dran ist. Ich finde das eher recht komplex, weil man halt noch einen neuen Weg hat, quasi wie eine neue Sprache. Und wenn es trivial ist, dann ist es auch mit einem RC-Script recht trivial. Es sind ein paar Zeilen weniger, aber den großen Vorteil sehe ich nicht.

Auch andere Dinge, wie Zeit/NTP/... sind zum Beispiel relativ komplex. Entweder man verwendet das systemd eigene System und es ist relativ schwer draufzukommen welche Peers funktionieren. Das Tool timedatectl mit dem man es aktiviert und das angeblich auch alles an Status ausgibt scheinbar nicht. Oder man nimmt das gute alte OpenNTPD (yay, ntpctl, kein SIGINFO mehr), schreibt das Unitfile um, damit es arbeitet wie (per default) gedacht, aber scheinbar mag es kein driftfile anlegen, wenn man systemd verwendet.

Und wenn man dann noch schaut, wie man die Hardwareclock auch anpasst findet man raus, das dann erst wieder mit einem Hack... quasi Shell-Hack geht Startkommando auf /bin/true und beim Exit eben dann das Syncen. Man verliert also Flexibilität, behält aber die Hacks, kombiniert also die Vorteile.

Bin aber auch kein Profi. Habe nur geschaut, was die Profis so vorschlagen.

Shell-Scripts kennt man doch als Admin, warum was neu erfinden, wo man dann erst wieder die alten Hacks verwenden muss? Habe ja nichts dagegen was neues zu lernen, aber ein Sinn dahinter hat sich mir noch nicht wirklich erschlossen.

Und überschreiben von Configs. Puh, das ist ein Grund für BSDs. Aber das macht Systemd zumindest von dem was ich so gesehen habe eher weniger. Nochmal Glück gehabt.

Sag ja nicht, dass alles an systemd schlecht ist und alles an RC-Scripts gut, aber zumindest dort wo ich die Wahl habe und vor allem dort wo ich verantwortlich bin wenn was nicht rund läuft schau ich zumindest, dass ich auch die Kontrolle darüber habe.

Oh und ich glaube mittlerweile mehr, als zu Beginn, dass man sowas wie systemd auch besser machen könnte, auch wenn ich denke, dass es da eigentlich Dinge gäbe, die wichtiger wären. Die init-Systeme, vor allem die auf BSDs oder auch OpenRC funktionieren. Auch die die extrem minimalen Inits funktionieren recht gut. Irgendwie werden Dinge, die vielleicht nicht absolut perfekt sind und mit denen es in Jahrzehnten kaum Probleme gab gesucht und relativ schnell kaputt gemacht.

Eine Theorie dazu wäre, dass die Linuxcommunity in letzter Zeit extrem konsolidiert wurde. Es gibt quasi nur noch Ubuntu, mit auf der einen Seite Debian und auf der anderen Seite Linux Mint. Daneben dann noch Fedora und RedHat und dann eben noch Arch Linux das eine mittlerweile recht beachtliche Userbase hat, während all die anderen ernsthafteren Distributionen irgendwie ziemlich an Usern verloren haben, was vielleicht daran liegt, dass es da viel Sourcebasiertes gab oder binären, wo trotzdem viel selbst kompiliert wurde und mittlerweile alle auf viel zu heißen Laptops arbeiten.

Vielleicht ist dieses Konsolidieren und Wachen der selbe Effekt wie bei IBM, Microsoft, Apple, Google, etc.?

Oder es ist eine Kommerzialisierung von Open Source, die da was ausmacht. Das würde vielleicht aber bedeuten, dass es nach der nächsten Blase in der wir jetzt sind es wieder bergauf geht. Das ist aber jetzt schon weit hergeholt. Das gebe ich zu.

PS: Das war wieder ein Posting mit vielen Gedanken, persönlichen Erfahrungen, Theorien und wenigen Überzeugungen. Aber wahrscheinlich wäre es wohl besser nicht so viel drüber zu philosophieren und die Zeit in eben die wichtigeren Dinge und Probleme zu investieren.

 

[darktrym]

Noch ein Zusatz, Systemd speichert binär. Aber wie jeder gute Syslog-Demon kann der auch seine Nachrichten weiterleiten. Das Format wurde recht spät überhaupt dargestellt und ist nach wie vor nicht fest und spezifiziert. Letztendlich entscheidet der Code von Systemd was richtig ist, somit gibts für die binäre Speicherung keine Alternative zu Systemd.
Deine Unterscheidungsbeispiele klingen für mich nach keinen ernsthaften Problem. Wenn ich ein Spaltenformat habe kann ich die Struktur nicht einfach ignorieren. Beziehen sich diese Verrenkungen auf die Nutzung von awk? Ich bin kein Admin aber traue mir zu in 5min ein Python Skript zu hacken was dieses Problem löst.

 

[goblin]

Ich sehe unter dem systemd-Mantel nur deutlich interessantere Projekte als systemd-readahead.

Es geht ja auch nicht um systemd-readahead an sich, sondern im Umgang der Entwickler mit den Usern.
Dich stört der ganze Kram jetzt nicht, weil du bislang nicht betroffen warst. Da ist es natürlich einfach, alles gut zu finden.
Die systemd-Entwickler interessieren sich aber vermutlich genausowenig für dein aktuelles Projekt, und wenn sie irgendwann mal Komponenten zu „Legacy“ und „Deprecated“ erklären, auf denen dieses basiert, dann hast du den Aufwand und musst alles anpassen. Wenn auch noch Zertifizierungen dran hängen, dann wird es erst Recht interessant.
Ich weiß nicht wie es dir geht, aber in meinen Augen ist das ein Risiko, das sich vermeiden lässt.

Das beherrscht kein Session-Management und deckt nur einen Bruchteil der benötigten Features ab (vgl. "How does systemd relate to Plasma").

Sorry, aber es waren doch beide für Session-Management da. Dann wenn sie nun kein Session-Management beherrschen, wozu gab es sie denn dann?

In einem (im Linux/BSD-Umfeld) bislang sehr unausgereiften Gebiet wie dem Session Management hat man halt die Wahl:

1. Alles lassen wie es ist und damit leben, dass es beschissen funktioniert.
2. Das alte Zeug mit enormen Aufwand auf aktuelle Bedürfnisse umbiegen und trotzdem nicht einmal 70% abdecken, aber weiterhin Workarounds an allen Ecken und Enden mitschleppen - im Backend und in den Anwendungen.
3. Eine neue Schnittstelle anbieten, die ohne Probleme 90% der Anforderungen abdeckt und den Anwendungen ermöglicht, abertausende von Zeilen dann unnützen Code zu entfernen und die Pflege und Wartung der Anwendungen und des Backends deutlich zu vereinfachen. Dafür müssen die Anwendungen auf die neue Schnittstelle umsteigen.

Welchen der Tode möchte man sterben?

Ich würde es verstehen, wenn das einmal vorkommt, aber nach polkit ist es der dritte Bruch. Und angeblich haben die anderen beiden noch nichtmal ihre Aufgabe erfüllt. Da ist doch was fischig.

Wenn sich die Voraussetzungen, Anforderungen und Rahmenbedingungen stark gewandelt haben, ist das Neuschreiben in vielen Fällen weniger Aufwand als auch nur moderate Anpassungen am alten Backend vorzunehmen. Zumal man in letzterem Falle dann immer noch schwer wartbaren Code an der Backe hat.

Aus Sicht der Entwickler hast du sicherlich Recht, jedoch gibt es eben auch die Nutzer. Und denen sind solche Brüche nicht immer egal. Und da das hier nicht Windows oder OS X ist akzeptieren viele Nutzer eben nicht alles.

Bei Arch Linux kann man nicht von unfreiwillig reden - genau dafür setzt man es ein.

Naja, wenn vorher versprochen wurde, es wird eine Wahlmöglichkeit bestehen, und dann ist systemd auf einmal doch der einzige Standard, dann nenne ich das Verarsche. Es war für sehr viele Nutzer unfreiwillig, für experimentelle Software ohne Wahlmöglichkeit gibt es Fedora.

 

[-Nuke-]

Naja, wenn vorher versprochen wurde, es wird eine Wahlmöglichkeit bestehen, und dann ist systemd auf einmal doch der einzige Standard, dann nenne ich das Verarsche.

Das ArchLinux-Team hat nie versprochen, dass es eine Wahlmöglichkeit gibt. Man sagte nur, dass man Anfang wählen kann, als Übergangsphase, der Weg aber klar Richtung systemd geht.

Und ArchLinux ist bleeding edge. ArchLinux setzt man nicht für LTS-Systeme ein. Bei ArchLinux weiß man als Nutzer, dass man immer den heißesten und neusten scheiß, frisch aus dem letzten stable-commit des Entwicklers bekommt. Wer das nicht mag, der ist da falsch

 

[Azazyel]

Die systemd-Entwickler interessieren sich aber vermutlich genausowenig für dein aktuelles Projekt, und wenn sie irgendwann mal Komponenten zu „Legacy“ und „Deprecated“ erklären, auf denen dieses basiert, dann hast du den Aufwand und musst alles anpassen.

Das gehört zur IT dazu. Alte Bibliotheken fallen aus dem Support, neue Bibliotheken werden eingebunden - Alltagsgeschäft.

Wenn auch noch Zertifizierungen dran hängen, dann wird es erst Recht interessant.

Dafür gibt es Distributionen wie RHEL, die mindestens 10 Jahre Support anbieten. Für entsprechend Kleingeld auch noch länger.

Ich weiß nicht wie es dir geht, aber in meinen Augen ist das ein Risiko, das sich vermeiden lässt.

Ich habe für solche Komponenten wie das Session-Management lieber alle paar Jahre einen Generationswechsel als das Festhalten an alten Komponenten, die ihrer Aufgabe in einem geänderten Umfeld nicht mehr gerecht werden.

Sorry, aber es waren doch beide für Session-Management da. Dann wenn sie nun kein Session-Management beherrschen, wozu gab es sie denn dann?

Zitat Wikipedia: "Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems."
ConsoleKit und PolKit haben sich gegenseitig ergänzt. ConsoleKit hat das Session-Management übernommen.

Ich würde es verstehen, wenn das einmal vorkommt, aber nach polkit ist es der dritte Bruch.

Wie kommst du auf drei? Ich komme auf einen, bestenfalls zwei (logind ersetzt ConsoleKit und PolKit).

Und angeblich haben die anderen beiden noch nichtmal ihre Aufgabe erfüllt. Da ist doch was fischig.

Ihre Aufgabe haben sie zu ihrer Zeit erfüllt. Die Welt hat sich weitergedreht. Wer nicht mit der Zeit geht, wird mit der Zeit gegangen.

Aus Sicht der Entwickler hast du sicherlich Recht, jedoch gibt es eben auch die Nutzer. Und denen sind solche Brüche nicht immer egal. Und da das hier nicht Windows oder OS X ist akzeptieren viele Nutzer eben nicht alles.

Wenn "der alte Weg" wichtig genug ist, findet sich entweder ein Maintainer für die alte Bibliothek oder Nutzer, die einen Maintainer bezahlen. Wenn sich beides nicht findet, ist es für die Nutzer zwar bedauerlich, aber dann kann der Verlust so schlimm nicht sein.

 

[goblin]

Das ArchLinux-Team hat nie versprochen, dass es eine Wahlmöglichkeit gibt. Man sagte nur, dass man Anfang wählen kann, als Übergangsphase, der Weg aber klar Richtung systemd geht.

Und ArchLinux ist bleeding edge. ArchLinux setzt man nicht für LTS-Systeme ein. Bei ArchLinux weiß man als Nutzer, dass man immer den heißesten und neusten scheiß, frisch aus dem letzten stable-commit des Entwicklers bekommt. Wer das nicht mag, der ist da falsch

Sehe ich anders, aber ich habe Arch aber selber auch nie eingesetzt, sondern nur den Ärger derer mitbekommen, die auf einmal gegen ihre Willen Systemd hatten.
So zentrale Systemkomponenten tauscht man nicht einfach so ohne Vorwarnung aus, auch nicht bei Arch. IMO liegt der Unterschied darin, dass die Nutzer gerne Bleeding Edge-Versionen der Software ihrer Wahl hätten, und die Maintainer (und ihr, Nuke&Azazyel) Bleeding Edge von allem.
Da scheint jemand voll diesem „Linux is not about choice.“ von Red Hat/Fedora auf den Leim gegangen zu sein. Ich weiß aber, wie der Hase läuft, jetzt wird behauptet werden, das war vorher doch auch schon nicht so, genauso wie behauptet wurde „Bei Systemd ging es noch nie um schnellere Bootzeiten“. Von dem her brauchen wir darüber auch nicht mehr weiterdiskutieren.

Das gehört zur IT dazu. Alte Bibliotheken fallen aus dem Support, neue Bibliotheken werden eingebunden - Alltagsgeschäft.

IMO eine Frage der Zeitspanne. Aber wenn deine Kunden das mitmachen -- bitte.
Für das nötige Kleingeld garantiert Red Hat natürlich Stabilität… Microsoft aber auch, irgendwie fehlt da das Alleinstellungsmerkmal. So langsam wird mir jetzt auch klar, warum die Windows-Büchsen nicht totzukriegen sind…

Ich habe für solche Komponenten wie das Session-Management lieber alle paar Jahre einen Generationswechsel als das Festhalten an alten Komponenten, die ihrer Aufgabe in einem geänderten Umfeld nicht mehr gerecht werden.

Dass sich die Anforderungen zwischenrein so sehr geändert haben bezweifle ich.
Dass das Session-Management nicht funktioniert hat sehe ich auch so, allerdings war die Software, die damit tatsächlich Probleme hatte doch eben genau die Ranzsoftware aus dem freedesktop-Bereich, allem voran Pulse-Audio und gstreamer, wenn ich mich Recht an den C3-Vortrag von diesem Datenwolf oder so erinnere. Da kam aber auch nur wieder ein „Was? Ist doch alles super, auf meinem Telefon funktioniert das!“.
Für die meiste Desktop-Software hat der X-Hack funktioniert, und wenn dann sollte man das doch sowieso in X11 (oder vielleicht mal X12, nach wieviel Jahrzehnten?) richten.

Zitat Wikipedia: "Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems."
ConsoleKit und PolKit haben sich gegenseitig ergänzt. ConsoleKit hat das Session-Management übernommen.

Ach, die funktionieren nur in Verbindung mit consolekit. Wie dem auch sei, anscheinend hat dann consolekit ja nicht funktioniert, oder die oben genannte Software hat es umgangen. Ist die Frage, ob ich wirklich eine Korrektur von genau den Leuten haben möchte, die das ursprüngliche Konzept augenscheinlich schon vergeigt haben.
Aber nein, die wollen ja lieber alles schon vorhandene wegschmeißen und neu schreiben.
Dass dabei die Portabilität auf der Strecke bleibt ist für dich der Lauf der Dinge, ich sehe dahinter allerdings eine Agenda.

Wie kommst du auf drei? Ich komme auf einen, bestenfalls zwei (logind ersetzt ConsoleKit und PolKit).

Das ist einem Editierfehler geschuldet, tut mir Leid. Drei Frameworks (policykit, polkit, systemd-logind) → zwei API-Brüche (policykit → polkit, polkit → systemd-logind). Hab an meiner Antwort gefeilt und da ist mir offensichtlich diese Mengenangabe durch die Lappen gegangen.

Mich würde ja mal interessieren, inwiefern sich die Anforderungen tatsächlich geändert haben, wie du ständig behauptest. Ich habe nämlich nicht den Eindruck, dass sich da so viel geändert hat und die einzige Quelle für „geänderte Anforderungen“ ist Poetterings Blog… dessen Schilderungen empfinde ich aber eher als gruselige Machtphantasien der Fedora-Elite, allen anderen Linux-Distributionen ihren Weg aufzuzwingen.
Dass da neue Anforderungen ans Session-Management definiert werden kann ich aber beim besten Willen nicht erkennen.

 

[-Nuke-]

So zentrale Systemkomponenten tauscht man nicht einfach so ohne Vorwarnung aus, auch nicht bei Arch. IMO liegt der Unterschied darin, dass die Nutzer gerne Bleeding Edge-Versionen der Software ihrer Wahl hätten, und die Maintainer (und ihr, Nuke&Azazyel) Bleeding Edge von allem.

Nein, das stimmt aber einfach nicht. Debian war die Distribution mit der Wahl. ArchLinux war die Distribution mit dem KISS-Prinzip. Das Core-Repo war schon immer zugenagelt und ein "Friss oder stirb" (ein Kernel, eine libc, ein Init-System, ...). Und bei der Sache mit systemd... ja es hat nicht jedem gefallen, aber das Forum war voll mit Anfragen "wo bleibt systemd"? Ein Großteil der Nutzer wollte es einfach haben, warum auch immer.

Und ArchLinux hat systemd auch nicht ohne Vorwarnung eingeführt. Der Umstellungsprozess lief über Monate (!). Glaub mir, ich war aktiv dabei

 

[darktrym]

Ich versteh nicht warum man jetzt noch ArchLinux nutzen will? Man hat sich doch von allem getrennt das es exklusiv machte. Übrig geblieben ist eine generische Rolling Release Distro mit aktuellen Paketen und einen eigenen Paketmanager. Das bekommt man doch heute überall und einen Installer noch obendrauf

 

[-Nuke-]

Ich versteh nicht warum man jetzt noch ArchLinux nutzen will? Man hat sich doch von allem getrennt das es exklusiv machte. Übrig geblieben ist eine generische Rolling Release Distro mit aktuellen Paketen und einen eigenen Paketmanager. Das bekommt man doch heute überall und einen Installer noch obendrauf

Hauptsächlich:
- aktuelles Rolling Release
- Binärpakete
- schreibt einem keinen Standard Desktop vor
- wenig politisch (-free, -purefree, -freeerthanfree, -nonfree und so ein Blödsinn) und hat deswegen auch Steam, Skype, Nvidia Treiber in den normalen Repos
- im AUR sind viele Pakete im Angebot, fast immer aktuell (Android-Dev, JDK 8, Windows 8 Fonts Installer)
- einfaches Paketmanagement mit einfacher Paketbeschreibung (keine Pakete die in -dev, -libs, -man, -bla aufgeteilt sind)

Gibt nicht viele Distributionen die dem entsprechen, außer es sind ArchLinux Abkömmlinge. Von daher: "Warum will ich etwas anderes als ArchLinux nutzen?" Und jetzt komm nicht mit FreeBSD, ich hab kein Bock auf einen VESA-Treiber Server? Ja, absolut FreeBSD... Desktop? Ne, echt nicht.

Das Einzige von dem sie sich getrennt haben, ist die "FreeBSD-like" rc.conf... das war's dann aber auch schon.

 

[darktrym]

Die ersten drei Punkte gibts für Ubuntu, Fedora, Suse, Debian. Sicher die Kombination machts aber viele der Punkte wirst du anderswo auch finden. Betriebssysteme die bei Fehlern in Paketen ein komplettes Upgrade von allem empfehlen sind meine Meinung nach nicht sehr weit von dem Klassiker format und neuinstallieren entfernt.

 

[-Nuke-]

Die ersten drei Punkte gibts für Ubuntu, Fedora, Suse, Debian.

Sicher, nur ist apt-get einfach eklig, meiner Meinung nach. Bisher nur Probleme mit gehabt.

Sicher die Kombination machts aber viele der Punkte wirst du anderswo auch finden.

Eben, die Kombination machts. Das ist übrigens auch genau das was die großen Linux-Distributionen ausmacht. Wenn man sie nur in "Kernel+Init-System" einteilt, dann ist klar, dass man keine Unterschiede sieht.

Betriebssysteme die bei Fehlern in Paketen ein komplettes Upgrade von allem empfehlen sind meine Meinung nach nicht sehr weit von dem Klassiker format und neuinstallieren entfernt.

Recht philosophische Diskussion an dem Punkt. Klar, wenn nur ein Startup-File gefixt wird, installiert der das ganze Paket neu. Und? Wie groß ist so ein Paket im Normalfall... 1MB? 10MB?... den Unterschied merkt man nicht mal auf der langsamsten Festplatte. Dafür muss ich, wenn ich PostgreSQL installieren will nicht "apt-get/yum install postgresql-server, postgresql-contrib, postgresql-plperl, postgresql...." installieren sondern einfach pacman -S postgresql und gut. So eine krass blöde Einteilung macht nicht mal FreeBSD...

Klar gibt es Wege über Meta-Pakete. Macht ja ArchLinux an einigen Punkten auch. Aber die Struktur ist wesentlich einfacher. Es heißt ja nicht umsonst "Keep it simple _and stupid_". Man will einfach keine größtmögliche Flexibilität und das ist das was es so einfach macht. FreeBSD macht das doch nicht allzu viel anders. Oder tauscht hier jeder wild sein Init-System, Kernel oder sonstwas aus?

Das ist doch auch genau der Grund warum ich FreeBSD auf Servern nutze. Diese ganze Debian/CentOS/RHLE Scheiße ist mir einfach viel zu komplex geworden.

Wer das nicht mag kann sich ja gerne andere Distributionen angucken. Wird einem ja nun nicht ArchLinux aufgezwungen.