Boycott Systemd

Status
Für weitere Antworten geschlossen.
Ich habe ja keine Ahnung vom Init-Prozess, aber das hört sich recht interessant und zumindest nicht unplausibel an. Erklärt mal einem Dummen wo da die technischen Haken sind.
 
Meinst du mit "Resourcenverteilung/Machtverteilung" dass da zwischen Kernel und Userspace eine weitere Layer etabliert wird die den Start- und Shutdownprocess der Driver und Programme kontrolliert? Falls ja, was ist das Problem? Technisch erscheint mir so etwas notwendig zu sein. Ob es so oder anders realisiert wird ist eine ganz andere Frage.
 
Technisch gesehen ist die Kritik an der Idee eines "Plumping Layers", dass Unix so etwas konzeptionell einfach nicht vorsieht. Es gibt zwei Ebenen, unten den Kernel und oben das Userland. Anstatt nun eine saubere Lösung zu finden und z.B. ähnlich wie Windows auf die bereits vor mehr als 30 Jahren eingefügten mittleren Privilegringe von Prozessoren zurückzugreifen, fummelt man einen konzeptionell zwischen Kernel und Userland liegenden Layer ins Userland. Das ist durch mangelnde Trennung von Userland und Plumping Layer chaotisch und potentiell sehr fehleranfällig. Aber dafür kann man nicht unbedingt systemd kritisieren. Denn beim Linux gibt es wie inzwischen in (fast) allen anderen Betriebssystemen auch den ungeschrieben Konsens, das man an den dem System zugrundeliegenden Konzepten möglichst nichts (mehr) verändern sollte. systemds Entwickler haben somit gar keine andere Wahl, als entweder im Kernel oder Userland zu arbeiten.
 
Würde man diese "mittleren Privilegringe" nutzen, dürfte man bei der Portabilität wohl große Abstriche machen. Oder wie ist das mit ARM und MIPS?
 
Yamagi schrieb:
Technisch gesehen ist die Kritik an der Idee eines "Plumping Layers", dass Unix so etwas konzeptionell einfach nicht vorsieht. Es gibt zwei Ebenen, unten den Kernel und oben das Userland.
Zum Vergrößern anklicken....
Das mag so sein, verhindert aber jede konzeptionelle Weiterentwicklung und erscheint mir wenig rational.
Anstatt nun eine saubere Lösung zu finden und z.B. ähnlich wie Windows auf die bereits vor mehr als 30 Jahren eingefügten mittleren Privilegringe von Prozessoren zurückzugreifen, fummelt man einen konzeptionell zwischen Kernel und Userland liegenden Layer ins Userland. Das ist durch mangelnde Trennung von Userland und Plumping Layer chaotisch und potentiell sehr fehleranfällig.
Zum Vergrößern anklicken....
Ist das wirklich so? Die MikroKernel Leute argumentieren ja nahezu alles ins UserLand zu schieben und da ist - soweit ich das sehe - nicht von weiteren Privilegienringen die Rede. Also wird es auch andere Wege geben das zu erreichen. Dass das heikel ist steht außer Frage, aber das sind andere Bestandteile des Userlands auch.

Das Problem von Privilegienringen scheint mir zu sein dass Traps und Kontext-Switches eben komplex sind und eine Menge Laufzeit kosten.
Aber dafür kann man nicht unbedingt systemd kritisieren. Denn beim Linux gibt es wie inzwischen in (fast) allen anderen Betriebssystemen auch den ungeschrieben Konsens, das man an den dem System zugrundeliegenden Konzepten möglichst nichts (mehr) verändern sollte. systemds Entwickler haben somit gar keine andere Wahl, als entweder im Kernel oder Userland zu arbeiten.
Zum Vergrößern anklicken....
Mir erscheinen die Argumente von Poettering durchaus vernünftig. Klar laufen die auf eine Art von Standartisierung hinaus aber das ist per se ja kein Nachteil, insbesondere angesicht der vielen Linux-Distributionen. Posix allein ist zur heutigen Zeit für die Anwendungsentwicklung wirklich zu wenig...
 
Windows läuft auch auf ARM. Und laut Gerüchteküche hatten sie auch lange Zeit Windows für PowerPC in der Schublade, um die Abhängigkeit von Intel zu verringern und als Drohung gegen Apple.
 
ARM besitzt bereits seit der allerersten Architekturrevision in den tiefsten 1980ern sechs Ringe. MIPS hat allerdings tatsächlich nur zwei, was sicherlich dem Unix-Fokus in der Anfangszeit der Architektur geschuldet ist. Es ist allerdings kein Problem, man abstrahiert die Sprünge zwischen den verschiedenen Ringen ja sowie im maschinenunabhängigen Code. Der maschinenabhängige Teil wandelt einen Sprung in Ring 1 oder 2 in Ring 0 oder 1. Damit verliert man zwar die (auch unter x86 eher sinnlose) Protektion zwischen den Ringen, aber man muss am eigentlichen Code kaum etwas ändern.

Es ist sowieso immer eine schlechte Idee, sich an der "einfachsten" Architektur zu orientieren und weitergehende Features höher / besserer / weiterentwickelter Architekturen nicht zu nutzen. FreeBSD nutzt z.B. VT-d auf unterstützten CPUs im DMA-Interface, obwohl nur eine Architektur und da auch nur ein Bruchteil aller Prozessoren es kann. Oder man führt derzeit auf arch@ eine emotionale Diskussion um die Zukunft von FreeBSD/SPARC64. Da ist ein häufig vorgebrachtes Argument, dass SPARC harte Alignement-Anforderungen hat, die auf anderen Plattformen stören. Man kann sie aber auch als Vorteil sehen, da man durch sie ansonsten verdeckte Bugs im Code finden kann.

Aber diese Diskussion ist letztendlich akademisch. Die unixoiden Systeme werden auf 2 Ringen bleiben und Windows wird wo möglich 4 Stück benutzten, es auf einigen Architekturen einschränken. Und das bedeutet, dass der Plumping Layer unter Linux, sowie anderen Systemen die sich einen gönnen wollen, im Userland liegen wird. :)
 
Yamagi schrieb:
Und das bedeutet, dass der Plumping Layer unter Linux, sowie anderen Systemen die sich einen gönnen wollen, im Userland liegen wird. :)
Zum Vergrößern anklicken....
Na, dann ist ja alles klar! Man kann dazu 2 Positionen einnehmen
(1) Brauch ich nicht, will ich nicht, haben wir noch nie so gemacht. Angesichts der genannten Probleme des Init-Systems dürfte diese Position schwer zu rechtfertigen sein.
(2) Die Idee ist gut, brauchen wir, aber die Implementierung mangelhaft.

Dann könnte man eigentlich diesen thread schließen und 2 neue eröffnen: "Shame and scandal in Linux-Land" und "Implementation von systemd und alternativen". ;)

Ich glaube nicht daran dass es für komplexe Probleme wirklich einfache Lösungen gibt, das läuft dann eher auf Kastration hinaus. Auch kein Unix ist "einfach" ...
 
rubricanis schrieb:
Ich glaube nicht daran dass es für komplexe Probleme wirklich einfache Lösungen gibt, das läuft dann eher auf Kastration hinaus.
Zum Vergrößern anklicken....

Das muß nicht dringend so sein. Komplexe Probleme zerlegt man am besten in einfache und nutzt beherrschbare Lösungswege, um das Gesamtproblem in den Griff zu kriegen.

systemd erinnert mich irgendwie an Audrey ...
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

... und nicht an einen Lösungsmechanismus für irgendein Problem.
 
Sagen wir mal so: SysV-Init war der letzte Murks und musste dringend ersetzt werden. Und zwar bereits vor mindestens 15 Jahren, es traute sich nur keiner daran und die durchaus vorhandenen Ansätze wurden von niemanden übernommen. Nicht einmal Upstart, was ja durchaus einflussreiche Unterstützer hatte, konnte sich abseits von Ubuntu etablieren. systemd hatte einfach das Glück, eine von den richtigen Personen akzeptierte Lösung zu sein, die sich außerdem auf Red Hats Ressourcen stützen konnte. Es ist auch nicht so, dass systemd prinzipiell schlecht wäre. Es hat durchaus gute Ideen, nur leider auch viel Idiotismen. Zumindest aus meiner Sicht. Einige davon sind der Tatsache geschuldet, dass systemd im Großen und Ganzen der erste moderne Service-Manager war. Der Erste zu sein heißt, dass man zwangsläufig Fehler machen muss. Anderer liegen am Ego der Entwickler.

Zumindest kann man aus systemds Fehlern lernen. Es passiert ja gerade schon. Neuere Service-Manager wie nosh oder s6 wirken konzeptionell reifer und sind wieder deutlich unixoider. Damit stellt sich auch das Problem eines "Plumping Layers" nicht mehr wirklich. Wie gehabt hat man dort einfach eine Reihe weitgehend eigenständiger Services, die lediglich lose miteinander interagieren. Wenn wir es realistisch sehen, wird zumindest FreeBSD früher oder später nicht umhin kommen, eine dieser Lösungen zu integrieren. Nur das passiert halt nicht jetzt auf Krampf, sondern wenn genügend Wasser ins Meer geflossen ist und sich ein Konsens gebildet hat, wie ein Service Manager aussehen soll, welche Aufgaben er übernehmen kann und welche lieber nicht.
 
Yamagi schrieb:
Neuere Service-Manager wie nosh oder s6 wirken konzeptionell reifer und sind wieder deutlich unixoider. Damit stellt sich auch das Problem eines "Plumping Layers" nicht mehr wirklich. Wie gehabt hat man dort einfach eine Reihe weitgehend eigenständiger Services, die lediglich lose miteinander interagieren. Wenn wir es realistisch sehen, wird zumindest FreeBSD früher oder später nicht umhin kommen, eine dieser Lösungen zu integrieren. Nur das passiert halt nicht jetzt auf Krampf, sondern wenn genügend Wasser ins Meer geflossen ist und sich ein Konsens gebildet hat, wie ein Service Manager aussehen soll, welche Aufgaben er übernehmen kann und welche lieber nicht.
Zum Vergrößern anklicken....
Wenn ich Poettering richtig verstanden habe geht es (ihm) aber um mehr als nur einen Service-Manager sondern auch darum dass Anwendungsentwickler so etwas wie eine gemeinsame Platform vorfinden auf der sie aufbauen können. Das mag im Linux-Land wg. der Menge an Distributionen virulenter sein, besteht aber m.E. auch genau so im BSD-Land. Ich denke da z.B. an so banalen Sachen wie die Unterschiede bei uname etc pp. So ist jeder gezwungen sich zunächst eine platformunabhängige Layer zu schaffen um dann an die eigentliche Arbeit zu gehen, - ziemlich hirnlos das Ganze. Das geht dann natürlich weit über einen Service Manger hinaus und schafft eine ganze neue Infrastruktur. Ist es das was hauptsächlich kritisiert wird (und was du als "Idiotismus" bezeichnest) ?
 
Ja, ich denke schon. Man muss Lennart Poettering zustimmen, dass die Standardisierung abseits der Windows-Welt schwach ist. POSIX ist de facto gescheitert, weil man sich nie über mehr als die grundlegensten Dinge hat einigen können und die Entscheidungsprozesse quälend langsam sind. So sind alle Unices untereinander sehr heterogen. Ironischerweise hat ausgerechnet das eher anarchistische Linux eine Art groben Standard erzwungen, denn in der Bedienung sind die meisten unixartigen Systeme heute sehr Linux- oder vielleicht auch GNU-artig, sowie in den wichtigsten Schnittstellen zumindest ähnlich. Aber auch im Linux-Lager gibt es starke Fliehkräfte. Immer mehr Distributionen, die immer häufiger ihren eigenen Brei kochen. systemd versucht darum herum zu werkeln, indem es möglichst viel Funktionalität integriert. Und hier beginnt die Kritik:
  • Was systemd integriert, ist nur eine Sichtweise von sehr vielen anderen. Tatsächlich nicht mal die Sichtweise, die zumindest die größte Anhängerschaft hätte. Ein gutes Beispiel sind die Binärlogs. Ich habe bis heute kein sinnvolles Argument gehört, wieso es Vorteile hat Log-Daten binär zu speichern. Und ich habe noch keinen einzigen professionellen Admin getroffen, der journald nicht wie die Pest und Cholera zusammen hassen würde. Dennoch gibt es dort draußen einige wenige, die darin ein Geschenk des Himmels sehen.
  • systemd geht extrem rücksichtslos vor. Es nimmt zum Teil seit 30 bis 40 Jahren funktionierende Lösungen, tonniert sie und ersetzt sie durch oftmals schlechtere Nachbauten. Ein gutes Beispiel ist Cron. Natürlich muss man diese Nachbauten nicht nutzen, aber die Distributionen haben eine Tendenz, sie ihren Nutzern auf das Auge drücken zu wollen. Zudem werden bisher eigenständige, für Linux-Systeme grundlegende Projekte wie udev oder zuletzt Gummiboot einfach in systemd integriert und sich entsprechend nicht mehr eigenständig nutzbar.
  • Da systemd Schnittstellen bereitstellt und Anwendungssoftware diese Schnittstellen nutzt, funktioniert ein größer werdender Teil aller Software nur noch mit systemd. Beispielsweise wurde Gnome stark für seine enge Bindung an systemd kritisiert, die am Ende ein schlagendes Argument für Debians Schwenk auf systemd wurde. Diese Schnittstellen sind wiederum stark umstritten. Einige finden sie genial, andere hassen sie.
  • systemds Drang Funktionalität und Schnittstellen zu integrieren, sich dadurch selbst unabdingbar zu machen, widerspricht dem Unix-Kredo "Do one thing and do it right" und es widerspricht Linux grundlegendem Konsens "Linux is about choice". Das hat gerade bei alten Hasen zu massiven Widerständen und Frustration geführt.
Diese Kritik spaltete das Linux-Lager in zwei unversöhnliche Hälften. Die eine freute sich, dass systemd eiskalt durchgriff und seine Prinzipien durchsetzt. Die andere sah sich in einem Vernichtungskrieg. Im Moment scheint es sich etwas beruhigt zu haben, da die systemd-Beführworter sich erst einmal durchgesetzt haben und da systemd seit einiger Zeit mehr auf Stabilisierung und weniger auf die Integration von noch mehr Komponenten des Linux-Systems setzt. Aber ich glaube, dass die Sache noch nicht ausgestanden ist. Früher oder später werden die ersten Distributionen zu einer systemd-Alternativen wechseln und dann geht dann der Konflikt von vorne los.

Mit "idiotismus" meinte ich (und wirklich ich persönlich), dass systemd mit Gewalt Linux zu einem gänzlich anderen System umbaut, dessen technische Grundlagen in meinen Augen zweifelhaft sind. Konzepte, die alles mit allen integrieren, waren meiner Meinung nach nie eine gute Idee. Und systemd mit seinem etlichen, über schlecht bis gar nicht dokumentierte APIs ineinandergreifenden Binaries und Services ist genau so ein Konzept. Dazu das über aller Kritik stehende Vorgehen, was einfach jede andere Meinung und durchaus sinnvolle Erfahrungswerte als Behinderung abtut. Und nicht zuletzt die teilweise extrem fragwürdigen Implementierungsentscheidungen. libdbus in PID 1 war z.B. eine so unaussprechlich dumme Idee, dass man es kaum mit Worten beschreiben kann. Das Ding ruft u.a. eiskalt abort() auf, wenn /tmp vollgelaufen ist. Zum Glück haben sie es irgendwann selbst bemerkt.
 
Danke Yamagi, ich denke ich verstehe langsam das Problem: Da hat jemand Heilige Kühe geschlachtet und jetzt bläst ihm der Wind ins Gesicht. Ein paar Worte hierzu aus der Sicht eines wohlwollenden Außenseiters der primär an Benutzung und Anwendungsentwicklung interessiert ist.

Das wichtige Stichwort hier ist sicherlich Integration. Da hat - das muß man so sagen - Linux/BSD bislang versagt! Es gibt an der Basis ein paar wirklich geniale Konzepte: Streams/Files,Fork/exec, shell(s), shared libs. Und natürlich ist OpenSource eine wichtige Sache. Aber was darüber hinausgeht ist eine Ansammlung von tools die offenbar seit Äonen weder in Frage gestellt noch gründlich renoviert worden sind. Und das ganze wird zusammen gehalten von einer Unzahl an shell-scripts die in einer unsäglichen Sprache geschrieben sind die vor 30 Jahren vielleicht Sinn gemacht hat, heute aber nur ein Ärgernis ist. Und jedes tool setzt da seine eigene, mehr oder minder kryptische Sprache drauf auf (make, grep, cron etc). Wenn ich das Wort "einfach" in einem solchen Zusammenhang höre muss ich lachen: tools mit 20,30 und mehr Optionen sind alles andere als einfach sondern Ausdruck unzureichender Abstraktion oder schlichter Wildwuchs. BusyBox ist ein Symptom, nicht die Lösung. Natürlich kann man das als Admin alles lernen, muss man und tut es ja auch. Aber die Frage sei gestattet ob da nicht genau das Problem liegt...

Wer Unix wegen seiner starken Seiten schätzt, daran aber etwas substantielles ändern will, legt sich notwendigerweise mit nahezu allen an und bekommt entsprechend Prügel, - und schießt natürlich auch zurück. Man muss wohl ein starkes Ego und ein Stück Arroganz haben um das zu überleben. Und - das scheint mir wichtig - man muss möglichst viel an Kontrolle an sich heranziehen um nicht in den Fußangeln des "Do one thing and do it right" oder "Linux is about choice" hängen zu bleiben. Das Bazaar-Modell und Integration schließen sich m.E. aus. Insofern ist das eine ideologischer Krieg der da ausgefochten wird. Wie immer werden die mit den stärksten Truppen siegen und die anderen auf Guerilla-Taktik umstellen, - der Krieg geht also weiter...:rolleyes:
 
Vielleicht bin ich grade zu müde aber ich versteh Teile deines Postings nicht. Von welchen Skripten sprichst du, die Standardskripte beim Booten? Ich finde die rc-Skripte recht simpel, das Unitkonzept müsste ich erlernen. Und für welche Zielgruppe sind die wohl, User, Admin, von wem kann ich was erwarten, wer will da umlernen, für wen stellt das einen Fortschritt dar? Es hat begonnen mit einen launchd-Klon nun ist so ziemlich alles drin.
Und was hast du gegen 30 Optionen? Die sind doch optional und in der Regel werden nur wenige gebraucht und sind dazu recht verständlich, auch ohne ein Studium der Manpages.
BusyBox ist ein Symptom, für was? Bezieht sich das auf die Entfernung der paar Zeilen Systemd-Support?
Ich dachte immer wer Unix schätzt, der ändert nicht, sondern erweitert, so wie Solaris. Keine Zwangsintegration, klar umrandete Einsatzgebiete für neue Features. SMF ist auch nicht die neue vereinende Struktur die alles wegwirft. Aber wie schon bei Pulseaudio und Avahi, die Suche welches Feature cool wäre und man selbst neu entwickeln könnte, statt bestehende Software zu verbessern. Und die Schmerzen kommen alle zugute, auch diejenigen die nix davon wissen wollten. Wo ist da die Freiheit?
 
darktrym schrieb:
Von welchen Skripten sprichst du, die Standardskripte beim Booten? Ich finde die rc-Skripte recht simpel, das Unitkonzept müsste ich erlernen.
Zum Vergrößern anklicken....
Wo gibt es keine Skripte? Und rc-Skripte mußtets du auch irgendwann lernen, oder? Klar, jetzt kannst du es. Aber gilt das auch beim nächsten BSD/Linux? Und sind sie genau so oder nicht doch ein wenig anders, - oder sogar sehr anders. Du wirst das überprüfen müssen um es festzustellen oder lange man-pages lesen.

Als ich von FreeBSD zu DragononFly ausgewandert bin war ich sehr froh das gleiche pkg wie unter FreeBSD vorzufinden. Hat mir einiges erspart. Klar, jedes einzelne für sich ist - oft vermeintlich - einfach. Aber in der Summe ist das alles eine Menge Frickelei, - meist überflüsige wie ich meine. Das muss man lernen, Idiome und Work-Arounds um Probleme verstehen u.Ä. mehr. Und wenn man das nicht oft macht weil man kein Admin ist der das andauernt macht, hat man es bald wieder vergessen und alles fängt von vorne an.
Und für welche Zielgruppe sind die wohl, User, Admin, von wem kann ich was erwarten, wer will da umlernen, für wen stellt das einen Fortschritt dar? Es hat begonnen mit einen launchd-Klon nun ist so ziemlich alles drin.
Zum Vergrößern anklicken....
Yep! Alles was essentiell ist soll da automatisch ablaufen, das ist offenbar Poetterings Ziel. Und dann muss halt eine Menge da rein, Logging, Network, IPC etc pp. Das kann man für falsch halten, ich sehe das nicht unbedingt so, unterstellt es funktioniert wie es soll. Wie es funtioniert ist mir letztlich egal, die Hauptsache ist dass es funktioniert..
Und was hast du gegen 30 Optionen? Die sind doch optional und in der Regel werden nur wenige gebraucht und sind dazu recht verständlich, auch ohne ein Studium der Manpages.
Zum Vergrößern anklicken....
Ooooch, ich stand schon öfters vor langen Listen von Optionen und es dauert Wichtiges von Unwichtigem oder sehr speziellem zu unterscheiden.
BusyBox ist ein Symptom, für was? Bezieht sich das auf die Entfernung der paar Zeilen Systemd-Support?
Zum Vergrößern anklicken....
Das ist ein Symtom dafür dass da eine Menge drin ist was nicht notwendig ist. Und überflüssiger code ist immer ein Mangel.
Wo ist da die Freiheit?
Zum Vergrößern anklicken....
Von welcher Freiheit redest du? Von der Freiheit im OS rumzufummeln? OK, das ist deine Freiheit. Für mich ist das Unfreiheit denn ich muss mich jetzt um das OS kümmern und kann es nicht einfach benutzen, - und muss evtl. zu allem Überfluss noch das eine oder andere reparieren.[*]

Ich sagte ja oben: Integration und damit notwendigerweise verbundene Standartisierung schließen anderes aus. Die Frage ist allein was für wen wichtig ist.

[*] Ich bin von FBSD zu Dragonfly gewechselt weil die Installation 10.2. nicht funktioniert hat und ich mich darüber geärgert habe, - NTPD wenn ich mich recht erinnere. Klar kann man das mit der großzügigen Hilfe diese Forums lösen, aber ist so etwas wirklich akzeptabel? Für ein OS? Mit DragonFly bin ich jetzt recht glücklich und sehe keinen Grund zurückzukommen.
 
rubricanis schrieb:
Yep! Alles was essentiell ist soll da automatisch ablaufen, das ist offenbar Poetterings Ziel. Und dann muss halt eine Menge da rein, Logging, Network, IPC etc pp. Das kann man für falsch halten, ich sehe das nicht unbedingt so, unterstellt es funktioniert wie es soll. Wie es funtioniert ist mir letztlich egal, die Hauptsache ist dass es funktioniert..
Zum Vergrößern anklicken....

Ich bewundere deinen gnadenlosen Optimismus.
Ich will diese ganze blöde Magie nicht und ich freue mich über altertümliche noch recht übersichtliche Skripte, die seit Jahrzehnten funktionieren, auch wenn ich sie selten brauche und entsprechend blöd schaue, wenn ich daran basteln muß.
 
Warum war systemd der erste? Runit und daemontools (welche von s6 als Vorbilder angegeben werden) sind älter, und Gentoo hat laut Wikipedia seit 2007 OpenRC. Apples launchd ist auch älter als Systemd und liegt vom Design her deutlich näher bei systemd als die anderen Programme. Ich sehe das also ziemlich anders, was das aus Fehlern lernen angeht. Poettering gibt ja auch ganz offen zu, dass er ein Lock-In anstrebt, das hat nichts mit Designfehlern aufgrund von Pionierarbeit zu tun. Und das ist auch meine Hauptkritik, Standardisierung ist die eine, aber ein Software-Lock-In das andere.
 
Vielleicht habe ich mich etwas schlecht ausgedrückt. Mir ist natürlich völlig klar, dass es vor systemd andere Service Manager gab. Nicht nur runit, daemontools und launchd, sondern auch Solaris SMF und Microsofts svchost.exe. Aber systemd war der erste populär gewordene Versuch die klassischen Aufgaben eines Init-Systems, wie das Starten von Diensten, mit Dienst-Überwachung und vor allem zentralen Schnittstellen zu verbinden. Den letzten Punkt fand man meines Wissens bis dahin in Ansätzen nur in svchost.exe. Und das ist eben auch der Punkt, an dem die Hauptkritik von systemd liegt. Die Schnittstellen führen zu dem von dir genannten Lock-In, sobald man sie exklusiv nutzt, zwingt man die Nutzer seiner Anwendung zu systemd...
 
rubricanis schrieb:
Von welcher Freiheit redest du? Von der Freiheit im OS rumzufummeln? OK, das ist deine Freiheit. Für mich ist das Unfreiheit denn ich muss mich jetzt um das OS kümmern und kann es nicht einfach benutzen
Zum Vergrößern anklicken....
Das ist ein wichtiger Punkt in der systemd-Debatte (gewesen). Jemand nannte es mal beleidigend das "Zentrum der Welt"-Syndrom. Der Denkfehler ist, dass man die eigenen Ansichten und Bedürfnisse nicht auf andere Personen übertragen kann. Für einige Anwender ist beispielsweise systemds Komplexität kein Problem, im Gegenteil. Sie ist ihnen hoch willkommen, da systemd bisher von dem Nutzer zu verwaltende Komplexität bündelt und vor ihm versteckt. Für andere Anwender ist die Komplexität ein absolutes No-Go, da sie ihre Systeme bis ins Detail verstehen wollen oder sogar müssen. Da Linux "about choice" war, musste man bisher einem nicht gefallende Konzepte auch nicht nutzen. systemd brach damit, es hat sich zumindest im Moment nahezu alternativlos gemacht und zwingt damit auch viele Nutzer, denen es völlig gegen den Strich geht, es einzusetzen.
 
systemd bricht mit vielem, aber vor allem durch sich selbst. Wenn "PID 1" stirbt, stirbt das ganze OS (panic).
Es wird alles grundsaetzliche "integriert" und auch kleine Bugs bringen einen zum Reboot.

Das ist praktikabel gesehen "Zentrum der Welt" ...
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben