Boycott Systemd

Status
Für weitere Antworten geschlossen.
Sind ja echt tolle Aussichten. dbus als Bestandteil von systemd. D.h. ich kann dann davon ausgehen, daß dbus dann nicht mehr weiterentwickelt wird. Was wird dann aus Programmen wie der chineisschen Texteingabe, die dbus immer noch braucht?
 
Als ich letztens ein aktuelles Linux auf nem Rechner mit ner S3 Virge PCI-Graka booten wollte, kam nur Grafikmüll, schon direkt auf der Konsole. Googlen, irgendwelchen Dreck im GRUB deaktivieren, schon gehts. S3 Virge, seit wievielen Jahren sollte dieser Chip quasi komplett verstanden sein? Knapp 20? War den Hipster-Kindern wohl nicht mehr hip genug, muss man mal einfach kaputtspielen.

So geht das doch dauernd da drüben. Wie lange dümpelt z.B. btrfs unbenutzbar vor sich hin? Die stecken doch alle in irgendwelchen Sackgassen. Dann kommt der Nächste, siehts, blickt nicht durch, also wird alles über den Haufen geworfen und neu angefangen. Diese Tretmühle geht da doch schon ewig so. Wieviele Filesysteme haben die? Audio-Subsysteme? Irgendwann wirds den nächsten systemd-Verschnitt geben - jetzt aber wirklich mal von Grund auf echt voll durchdacht und so! Ach nee, war wieder nix. Sollte man mal wegwerfen und es jetzt aber nu wirklich echt sauber von vorne machen!

Die haben doch alle den Schuss nicht gehört.
 
Das will ich aber in einer 32-Bit-VM gar nicht können, verflucht!

Danke für den Link.
 
Dieses Abschießen von allen Prozessen in einer cgroup also bei logind auch beim Ausloggen aller Anwendungen, die ein Nutzer offen hat, gefällt mir nicht so (immerhin ist es optional). Bei Diensten (systemd) ist das sogar tödlich. Das führt meistens zu Datenverlusten. Außerdem ist das mal wieder so eine Sache, die fast nie vorkommt. Wo ein System am meisten hängt ist vielleicht bei Netzwerkproblemen und NFS oder squid, wenn er seinen Riesen-Cache auf Platte sichert. Aber das alles hat ja einen Sinn! Eben Datenkonsistenz, darum geht es überhaupt auf einem Server!
 
Heute habe ich gelernt, dass logind eine API hat, um Dateideskriptoren als stale markieren zu können (oder gar direkt freigeben?). Das soll beim Benutzerwechsel dazu führen, dass wohl Musik aufhört zu spielen und andere Ressourcen/Geräte transparent freigegeben werden können. Habt ihr irgendein Szenario wo das sinnvoll wäre? Ehrlich gesagt habe ich das nicht verstanden was das Problem dabei ist.
 
Ich kann mich dunkel daran erinnern, dass als ich mal KDE auf Linux benutzt habe, hat sich oft der Sound-Daemon nicht mitausgeloggt und belegte diese ärmliche Linux-Sound-Gerät, welches anscheinend nur ohne Multiplexing kommt und alles blockiert, wenn es mal offen ist. Dann konnte sich ein anderer Nutzer auch nicht einloggen, weil der Sound-Daemon den Start-Sound von KDE nicht abspielen konnte (Timeout von 30 Sekunden oder so).

Geht es etwa um solche Geschichten? Aber das würde eher zeigen, dass das Konzept mit den Sound-Daemons eher ... ähm... im Popo ist, und nicht mit der Geräteverwaltung an sich. Ach... ich weiß es nicht... ich hoffe, Ihr könnt's mir sagen.
 
nakal schrieb:
Heute habe ich gelernt, dass logind eine API hat, um Dateideskriptoren als stale markieren zu können (oder gar direkt freigeben?). Das soll beim Benutzerwechsel dazu führen, dass wohl Musik aufhört zu spielen und andere Ressourcen/Geräte transparent freigegeben werden können. Habt ihr irgendein Szenario wo das sinnvoll wäre? Ehrlich gesagt habe ich das nicht verstanden was das Problem dabei ist.
Zum Vergrößern anklicken....

Ist doch einfach zu verstehen - Lennart hat den Audiokrams schon verfuckelt und versucht das jetzt mit systemd zu retten ...
 
Ich denke die Strategie ist eher das er versucht mit systemd Linux in den Abgrund zu reissen, damit der Murks den er mit pulseaudio gebaut hat, nicht mehr auffaellt. :P

Es ist natuerlich immer einfach zu meckern, besonders von Leuten, die es noch nie ausprobiert haben, aber schon offensichtlich ist das hier wohl konzeptionell was falsch laeuft. Ich hab RHEL 7 mal getestest bevor wir anfangen das zu deployen und meine Erfahrung viel eher gemischt aus. Es hat das was ich wollte mit den klassischen Kommandos, die man seit Jahren kennt, erst mal funktioniert, aber was genau passiert weiss keiner bei den wrappern fuer den wrapper um systemctl. Starten klassischer Dienste war zumindest nicht das Problem (, was auch ziemlich peinlich waere), interessanter ist aber die Frage, wie man geschickt alten selbstgeschrieben Dienste integriert und da gabs dann die ersten Probleme. Also um die Sache kurz zu machen: Das wird erst mal nicht ausgerollt.
 
Der Linux-Kernel ist ja auch monolithisch - One kernel to rule them all!

Da kann er schlecht meckern wenn Andere monolithische Software bauen.
 
Linus hat in der Vergangenheit nur sehr selten eine Meinung dazu gehabt, was die Welt mit seinem Kernel machen darf. Und wahrscheinlich ist das ein Teil des Erfolgsrezepts.
 
Hmmm, wenn die *.service falsch geschrieben sind (im sinne von "Dienst startet nicht da etwas angenommen wird was so nicht stimmt), weiß jemand ob das an der distri liegt, und man da einen bug aufmachen sollte, oder ob die von dem jeweiligen Projekt beigesteuert werden?
 
Da müsstest Du echt selbst reingucken und anhand Deiner Glaskugel schätzen, ob die Service-Beschreibung auch wirklich (so wie eigentlich gedacht) generisch für alle Distributionen ist oder ob irgendein Paketpfleger da seine Mad Skillz beweisen wollte.
 
Die Lösung ist natürlich den WPA-Supplicant in systemd zu integrieren! ... Oder haben sie das schon etwa gemacht?
 
"ifconfig" wurde schon vor sehr langer Zeit in vielen Distributionen durch "ip" ersetzt.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben