Boycott Systemd

Status
Für weitere Antworten geschlossen.
Mir scheint das ein Hauptproblem von Lennart zu sein, daß er Probleme damit hat das Wichtige vom Unwichtigen zu unterscheiden und dann bastelt er und bastelt er und bastelt er ...
Theo als vermutlich extremer Gegenpart, schaut erst mal, was er alles wirklich braucht und den Rest wirft er einfach weg. Seien es Ideen oder auch schon vorhandenes.

Generell scheint es mir schon sinnvoll zu sein, OS-übergreifende Schnittestellen zu definieren. Es würde vieles einfacher und kompatibler machen, auch wenn es viel Arbeit wäre, die Entwickler einzelner OS dazu zu bewegen, diese Schnittstellen dann auch genau so zur Verfügung zu stellen.
 
Und das ist für mich die entscheidende Frage, welche Features gehören wirklich in ein Init-System und welche nicht. Prinzipiell halte ich die "arm an Features" Variante von FreeBSD, also wirklich nur das nötigste zu implementieren, für "richtiger" als den alles aufsaugenden Bloat den systemd produziert. Wie runit, s6, nosh .. etc zeigen, geht es auch deutlich schlanker und übrigens auch plattform-übergreifender.

Sind die denn schlanker als systemd? Du darfst ja nun auch nicht den Init-Daemon systemd mit allen anderen "Dach-Projekten" wie systemd-logind, timesyncd, networkd usw. in einen Topf werden. Sie mögen zwar systemd- als Anfangsnamen haben, aber haben mit dem Initd systemd so gar nichts zu tun. Bei mir läuft auch nur udevd, logind und journald. Der ganze andere Kram _nicht_.

Das es komplexer als FreeBSDs Init-System ist, ist klar. Aber darum hatte ich auch mal den Vergleich vor ein paar Seiten gebracht. So ein Start-Skript unter FreeBSD braucht halt mal gerne >100 Zeilen Shell Code. Unter systemd wären das <10 Zeilen mit in der Summe deutlich mehr Features (Limits, Sandboxing, Überwachung, Lazy-Start, ...)
 
ich denke die ganz Diskussion um für und wieder von SystemD ist müssig. Ein Großteil der Linux Distributionen setzt es schon heute ein, weil man dort die Vorteile erkannt hat und über die Nachteile (die gibt es, keine Frage) hinwegsieht - die Vorteile überwiegen für die Entscheider. Da etwa auch Debian auf SystemD wechselt sind das also nicht nur kommerzielle Hintergründe die da zum tragen kommen!

In dem verlinkten CRE spricht Poettering u.a. über die längst überfällige Standardisierung die man mit POSIX einfach nicht weit genug tragen konnte. Das sind so Banale Dinge, wie das man sich nicht mal darauf einigen konnte, in welcher Datei der Hostname gespeichert wird. Da gibt es /etc/hostname (Debian), /etc/HOSTNAME (Suse), /etc/sysconfig/hostname (Red Hat) und sicher noch einige mehr. Keiner kann hier behaupten, dass es etwa bei diesem Beispiel um technische belange geht. Da wird einfach an dem festgehalten, was seit Jahrzehnten schon so ist.

Als Softwareentwickler, würde ich auch nur noch auf die SystemD APIs setzen, weil ich mich eben darauf verlassen kann, dass es auf jedem System so ist und ich eben nicht viele Unterscheidungen einbauen muss. Da braucht sich niemand wundern, dass SystemD vor allem bei Entwicklern auf so großen Zuspruch führt. Solche Abstraktionen sollten eben möglichst an einer Stelle gemacht werden und nicht von jedem Programm selbst. Das gilt übrigens auch für diverse Init-Skripte. Die meisten Programme müssen einfach nur, ggf. mit ein paar Optionen, gestartet werden. Irgendwer muss sich die Prozess ID merken und am Ende eben jene Beenden - im Idealfall mit allen Child Prozessen. Warum man dafür jedes mal ein ganzes Skript braucht, wenn die Angabe des Programms mit Optionen ausreichen würde, ist mir einfach schleierhaft. Für die vielleicht 5% aller Software für die das nicht ausreicht, kann man ja gerne Skripte schreiben, aber doch nicht für alles. Ich denke hier im Forum können alle mit Shell Skripten arbeiten und selbst welche erstellen. Das können viele, vor allem Neulinge aber nicht und warum sollte man für diese die Lernschwelle höher legen als nötig?

Letztlich ist es aber so, dass SystemD gesetzt ist. Klar wird es immer Distributionen ohne geben, aber die werden eben vieles Patchen müssen oder Shims implementieren. Wenn das unter BSD nicht geht, etwa weil Kernelfeatures nicht da sind, wird die schon jemand schreiben. Ob man cgroups haben will - da kenne ich mich nicht aus. Aber einen Mechanismus, mit dem ich alle Prozesse erkennen kann, die direkt oder indirekt von einem anderen gestartet wurden, der ist doch sinnvoll (sagen wir einfach mit einem "Tag"). SystemD nutzt cgroups um eben genau das zu erkennen, damit ein Dienst eben sauber mit allen Childs zu beenden.

SystemD selbst hat übrigens nur zwei Abhänigkeiten: einmal das Journald, das aber die Logs nachdem es sie verarbeitet hat auch an einen Syslog Dienst weitergeben kann, der dann Textfiles speichert. Als zweites dann DBus das wenn es nach Poettering geht in den Kernel wandern soll. Weil das alle modernen OS so machen, behaupte ich mal, dass IPC im Kernel durchaus Sinnvoll ist. Alle anderen SystemD Komponenten sind optional, abstrahieren aber auch hier vieles und werden daher gerne genutzt.

Inwiefern das nun die Freiheit von irgendwem einschränkt die Software seiner Wahl zu nutzen kann ich nicht nachvollziehen. Erstmal ändern sich nur die Init-Skripten die durch Unit-Dateien ersetzt werden. Ich denke aber dass gerade wer im IT-Umfeld tätig ist, in dem sich quasi täglich alles ändert, sollte so flexibel sein sollte damit umzugehen. Wenn ich für komplexe Angelegenheiten weiterhin Skripte brauche, lasse ich die einfach von SystemD starten. Wenn ich einen anderen NTP-Daemon starten möchte, kann ich auch das tun. Nur darf ich mich nicht wundern, wenn irgendwelche Software dann nicht rund läuft weil der andere Daemon kein - sagen wir - DBus spricht. Aber das ist doch jetzt auch schon so: ersetze ich ein Stück Software, durch welche die nicht default ist, kracht es eben irgendwo.

Kurzum: ich sehe das wie @-Nuke-

Edit: ich kann den CRE nur empfehlen. Da wird so einiges an Entscheidungen mit Hintergründen gefüttert. Ob die immer sinnvoll sind, darüber kann man sicherlich streiten. Es ist aber nicht so, dass aus Prinzip alles anders gemacht wird....
 
Mir scheint das ein Hauptproblem von Lennart zu sein, daß er Probleme damit hat das Wichtige vom Unwichtigen zu unterscheiden und dann bastelt er und bastelt er und bastelt er ...
Ich denke dem Mann hört niemand zu weil er für viele nur noch ein rotes Tuch ist. Beispiel Logging: Er begründet recht plausibel warum das im InitProcess notwendig ist und warum er das so macht wie er es macht. Natürlich könnte man das auch anders machen: 3 Programmierer, 4 Meinungen. Derjenige der faktisch daran arbeitet und das dann entscheidet ist offenbar am Ende immer der Idiot! Ich war wirklich offen für alle Argumente als ich angefangen habe mich damit zu beschäftigen, aber das hat mit einer auch nur halbwegs rationalen, technischen Diskussion nichts zu tun.

So, und jetzt klinke ich mich aus diesem thread aus, ich will mich nicht weiter über sowas ärgern. :rolleyes:
 
Jaha, Logging. Was der Goldjunge halt einfach nicht rafft ist, dass einem Binary-Logs nichts bringen, wenn der eigene Daemon auf die Schnauze fliegt und man die Logs dann wegschmeißen kann, weil es nicht vorgesehen ist, den Binärmüll zu retten.

Das hat selbst mit rational technisch nichts zu tun. Das ist einfach nur Bullshit. Sowas kann man nur verteidigen, wenn man keine Ahnung oder keine Erfahrung hat.

Poettering leidet extrem an Ich-komm-mal-daher-und-weiß-alles-besser-weil-ich-das-Bewährte-nicht-verstehe-Hipsteritis, s. den sudo-Schwachsinn, den er abgelassen hat. Wenn man etwas nicht rafft, sollte die erste Reaktion nicht sein, alles erstmal wegzuwerfen, sondern zu gucken, _warum_ die Dinge so sind und welche Schmerzen durchlebt wurden, damit sie so sind. Danach sollte man nochmal doppelt so lange nachdenken, ob man es wirklich besser kann. Der Junge frickelt an tausend halbgaren Ecken und zerrt diese noch dazu in Abhängigkeiten, die einfach nicht zu sein haben.
 
Bescheidenheit und Zugewandtheit hört halt leider auf, wenn der andere den Elefanten im Porzellanladen raushängen lässt und wiederholt demonstriert, dass er keine Ahnung hat. Dafür ist die Zeit zu schade, sich mit jedem Lausebengel rumzuplagen, der meint, die Weisheit mit Löffeln gefressen zu haben.

Keiner hat Anspruch darauf, mit wertlosen Meinungen ernstgenommen zu werden. Ich genausowenig wie jeder Andere.
 
Keiner hat Anspruch darauf, mit wertlosen Meinungen ernstgenommen zu werden. Ich genausowenig wie jeder Andere.

Das hat nur noch bedingt was mit dem Thema zu tun, aber jeder Mensch hat bei mir den Anspruch ernstgenommen zu werden und wenn seine Meinung noch so wertlos und sein Benehmen noch so rüpelhaft ist.
Ich ziehe mir allerdings nie den Schuh an, für die Lösung seiner Probleme zuständig zu sein oder mich nach seiner Meinung richten zu müssen.

Ich halte Lennart nicht für dumm und nicht für unfähig und es stünde ihm sicherlich gut, wenn er sein Benehmen da etwas ändern würde.
Man mag nun sagen, daß Theo und Linus auch nicht gerade für ihr Benehmen gerühmt werden, aber ich habe trotz allem Gepolter immer den Eindruck gehabt, daß sie immer erst zuhören und die konträre Meinung hinterfragen und verstehen.
 
Einfach mal die Liste von Bugreports durchgehen, die mit NOTABUG oder NOTOURBUG geschlossen wurden. Sie zeigt sehr gut, wie man beim systemd denkt: https://bugs.freedesktop.org/buglis...anced&resolution=NOTABUG&resolution=NOTOURBUG
Ich hab mal 2 Dutzend von den Reports durchgelesen (du auch?) Eine Menge Upstream und Distro Kram, Kernel, einzelne Compiler-Probleme. Nichts weiter auffällig. Der Ton ist moderat und sachlich. Ich sehe da nichts furchtbares. Der Typ wird wohl hier für alles verantwortlich gemacht was bei Linux nicht so recht läuft...;)
 
Ich glaube das Problem für viele ist eher, dass die Bugs einfach zu gemacht werden, ohne noch mal die Meinung vom Autor einzuholen.
###
Aktuelles Verhalten:
Reporter: Ich habe hier ein Problem
Maintainer: Das ist nicht unser Problem, das liegt am Kernel <Begründung> <closed>

von vielen eher gewünschtes verhalten:
Reporter: Ich habe hier ein Problem
Maintainer: Das ist nicht unser Problem, das liegt am Kernel <Begründung>, richtig?
Reporter: Da magst du recht haben / Nein, ich denke nicht...
###

Es kommt halt in einer gewissen Anzahl an Fällen halt dazu, dass Bugreports verführt geschlossen werden, teilweise auch ohne tiefere Begründung. Das vermittelt halt eine starke "Bugs sind und scheiß egal"-Mentalität. Und dort gab es auch eine handvoll Fälle wo es halt doch ein Bug in systemd war und der Report schon zig mal geschlossen wurde. Natürlich werden aber auch genug Bugs "normal" behandelt. Aber über die Sonderfälle schreit man halt lauter. Schönreden will ich das trotzdem nicht. Man sollte eigentlich immer noch mal die Bestätigung vom Autor einholen, bevor man seinen Report abschmettert.

Es gibt halt genug Mailinglisten wo es halt problemlos läuft. Aber das ganze wird halt auch dadurch beeinflusst, dass systemd halt eine recht kontroverse Komponente ist und vielen es jetzt aufgezwungen wurde.

Aber die Kernel Mailingliste sieht da auch nicht besser aus. Wenn Linus mal einen schlechteren Tag hat, dann werden dir auch Beleidigungen um die Ohren geworfen. Und wenn jetzt natürlich eine Diskussion ist, ob ein Bug im Kernel oder in systemd vorhanden ist, dann schaukelt sich das natürlich auf.
 
Vieleicht sollte man den Spieß einfach mal umdrehen, und Lennart und sein Team einfach intensiv helfen und Code comitten, damit der Jung das richtig macht :-)
Der Podcast auf cre mit Lennart hört sich nach einem normalen Entwickler an, der aus Linux ein user-friendly system machen will ala Windows.

Was ich mich nur frage ist, wieso geht man die Sache nicht mal etwas Akademischer an.
Erstmal Konzept machen usw....
Das ständige rum hacken ist keine Lösung, wie wir alle wissen.
Schließlich gibt es Forschungen zu Betriebssystem, warum nicht den Servicelevel teil mit einbeziehen, anstatt immer nur auf classic machen (Threads, Interrupts und co...)
 
Betriebssystemforschung ist halt wirklich vermehrt Kernel-Forschung. Bei dem was ich so kennengelernt habe geht es meist nur um verschiedene Variationen von Mikrokerneln und die haben ganz andere "Sorgen" als ein Init-Dienst.

Und der Init-Dienst ist ja auch relativ transparent vom Rest der Softwareumgebung. Nur wenn du selbst mit dem System interagieren willst, dann kommt man nicht drum rum (shutdown, reboot, suspend, logins verwalten, ...).
 
Es kommt halt drauf an, was man als Betriebssystem definiert.
Klar sollte der Init Dienst transparent sein, aber letztendlich verzahnt das system immer mehr mit dem Kernel (auf systemd bezogen).
Und ja es ist schon schwer genug die Forschung auf den Kernel an sich zu machen, da stört jeder zusatz aus dem "User-Space"

<Meinung>
Aber auch die klassische Trennung (Kernel/User Space) ist (wenn wir ehrlich sind) schon etwas angestaubt.
Und dann die immer wiederkehrende Frage: Was ist besser: Micro oder Monolith.
Beides ist gut, aber keines ist besser als das andere.

Man kann heute auch die Frage stellen, warum braucht man überhaupt mehrere Unixartige Systeme neben Linux ?
Linux kann immer mehr und welche Diskussiongrundlage existiert überhaupt noch irgend ein anderes System zu nehmen ?
ZFS, DTrace und co, sind für Unternehmen keine Entscheidungsgrundlage FreeBSD anstatt Linux zu nehmen (mal als Beispiel).
Wenn Systemd mal funktioniert wie bei Windows, kann man auch Fragen wozu man noch Windows braucht wenn alles GLEICH ist ?

Ich denke/glaube das bei Linux die Zielgruppe gleich ALLE sind. Bei FreeBSD ist es noch eher Server/Workstation als Desktop und ALLE.
ALLE = (Server, Workstations, Clients, Embedded, ...)
</Meinung>
 
Weißt du Goblin, bei aller Wertschätzung, gerade deiner Person, solche Unterstellungen die weder mit dem was ich gesagt noch gmeint habe das geringste zu tun haben verleidet einem jede ernsthafte Diskussion. Ich habe etwas kritisiert mit Gründen die nicht deine sind mögen, aber eben meine. Entweder setzt man sich also mit Gründen auseinander, oder läßt es bleiben.

In deinen Beiträgen hast du dich teilweise ziemlich negativ über unixoide System ausgelassen, aber OpenSource als wichtige Bedingung genannt, also habe ich eine OpenSource-Implementierung der Windows-Schnittstellen vorgeschlagen. Das ist in meinem Augen die logische Folge: die OpenSource-Aspekte beibehalten, aber die ungeliebte Unix-basis hinter sich lassen, wenn sie denn wirklich so furchtbar ist und nervt.

PS: Ich habe das "nachzujagen" 2 Beiträge oben nach wenigen Minuten korrigiert, das war ein kleiner Fehler der mir beim Umstellen des Satzes unterlaufen ist. Was soll das also?

Ich habe das noch so gesehen, als ich ca. 6 Minuten das erste Mal darauf geantwortet habe, und nach meiner späteren Bearbeitung war es auch nocht so. Mich hat der Ausdruck gestört, und das habe ich zum Ausdruck gebracht.

Ich meine nur dass eigentlich weitere Baustellen - wie z.B. das was jetzt systemd macht - in einem ähnlichen Prozess definiert werden sollten. Aber so etwas ist auf dem Unix-Bazaar nicht möglich.

Dir ist bekannt, das POSIX der Standard ist, der UNIX zugrunde liegt? Das definiert sich darüber, wie soll es also nicht möglich sein, gemeinsame Schnittstellen für unixoide Systeme festzulegen? Standards entwickeln sich nunmal langsam und bestehen aus Kompromissen, aber gescheitert ist es deswegen noch lange nicht.

Ich stimme -Nuke- zu, POSIX und systemd haben erstmal nichts miteinander zu tun. Nur dass sich die mentalen Modelle massiv unterscheiden, auf der einen Seite höchstmögliche Portabilität, auf der anderen Seite völlige Ignoranz und Respektlosigkeit gegenüber allem, was anders ist. Wie würde sich der Poettering fühlen, wenn die OpenSSH-Leute auf einmal exklusiv die Crypto-Funktionen von OpenBSD nutzen würden? Dann wäre das Gejammer groß und die Forderungen nach einem Fork laut, aber wenn er sowas macht, dann hat das auf einmal in Ordnung zu sein?
 
Was ich mich nur frage ist, wieso geht man die Sache nicht mal etwas Akademischer an. Erstmal Konzept machen usw....
Im Podcast hat er ganz klar gesagt, dass er und sein Team alle vorhandenen Init-Systeme angeschaut haben (Mac OS, Windows, Solaris, Upstart etc.). Er hat auch überlegt, bei Upstart weiter zu machen aber sein Ansatz war einfach zu extrem. Ich glaube ihm, dass er es wirklich gut meint aber ja. Es war halt auch zu viel in so kurzer Zeit. Da wurde an allen Enden gleichzeitig geschraubt.

Was ist persönlich gut finde, ist das vereinheitlichen der Dist-Vielfalt! Jede ... Distribution muss ihr eigenes Süppchen kochen. Ich will doch einfach nur ein Paket erstellen für Linux und nicht 1000 Varianten. "FreeBSD like" halt :) Was bin ich froh, gibt es hier nicht auch X Varianten.
 
In deinen Beiträgen hast du dich teilweise ziemlich negativ über unixoide System ausgelassen, aber OpenSource als wichtige Bedingung genannt, also habe ich eine OpenSource-Implementierung der Windows-Schnittstellen vorgeschlagen. Das ist in meinem Augen die logische Folge: die OpenSource-Aspekte beibehalten, aber die ungeliebte Unix-basis hinter sich lassen, wenn sie denn wirklich so furchtbar ist und nervt.
Versuch es mal zu lesen, dann brauchst du mir nichts hineizulesen. Wenn du allerdings die Kritik eines einzelnen Aspektes nicht von der am Ganzen untescheiden kannst, wird es schwierig. Alter rhetorische Trick: Erst jubelt man dem Kontrahenten etwas unter was er weder gesagt noch gemeint hat, dann kann man ohne jede Hemmung drauflosreden und steht selbst immer im rechten Licht.
Dir ist bekannt, das POSIX der Standard ist, der UNIX zugrunde liegt? Das definiert sich darüber, wie soll es also nicht möglich sein, gemeinsame Schnittstellen für unixoide Systeme festzulegen? Standards entwickeln sich nunmal langsam und bestehen aus Kompromissen, aber gescheitert ist es deswegen noch lange nicht.
Auf Posix oder einen ähnlichen Prozess im Unix-Lager zu warten um die Probleme der heutigen Zeit zu lösen heißt auf Godot zu warten.:) Aber nichts liegt mir ferner als jemandem die heiligen Zeilen seiner Vorväter ausreden zu wollen...
 
Wie würde sich der Poettering fühlen, wenn die OpenSSH-Leute auf einmal exklusiv die Crypto-Funktionen von OpenBSD nutzen würden? Dann wäre das Gejammer groß und die Forderungen nach einem Fork laut, aber wenn er sowas macht, dann hat das auf einmal in Ordnung zu sein?

Aber systemd hat doch anderen Systemen nichts weggenommen. Die Entscheidung dass Projekte jetzt plötzlich systemd benötigen hat doch nicht systemd getroffen.
 
Aber systemd hat doch anderen Systemen nichts weggenommen. Die Entscheidung dass Projekte jetzt plötzlich systemd benötigen hat doch nicht systemd getroffen.
Wie ich geschrieben habe, es ging mir dabei primär um die Einstellung der Beteiligten, natürlich ist der nachträgliche Auschluss anderer Systeme etwas anderes, als sie von Anfang an außen vor zu lassen.

Sie haben aber sehr stark propagiert, dass systemd alle diese Funktionen übernehmen soll. Der Poettering hatte da mal so eine schöne Seite, in der er der Welt erklärt was alles “deprecated” ist. Ganz kann man die systemd-Leute da also nicht aus der Verantwortung entlassen, auch wenn die Schuld natürlich nicht alleine bei ihnen liegt. Aber ich wiederhole es jetzt zum dritten Mal: mein Hauptproblem ist deren Einstellung, dass außer Linux nichts mehr relevant ist.
 
Aber ich wiederhole es jetzt zum dritten Mal: mein Hauptproblem ist deren Einstellung, dass außer Linux nichts mehr relevant ist.

Ja klar. Aber versetze dich in die Lage von denen mal. Du willst etwas umsetzen was alles auf ein neues Level hebt... der Linux Kernel bietet alles nötige, der Rest nicht... willst du jetzt für alle anderen Systeme, die dein Projekt wahrscheinlich eh nicht nutzen, auf den Knien rumrutschen und drum bitten, dass sie die Features auch in ihre Kernel einbauen und dann noch mal 5 Jahre warten bis das mal passiert ist?

Und das systemd nur unter Linux läuft ist ja auch keine böse Absicht, sondern schlicht darin geschuldet, dass der Linux Kernel eben Features bietet, die die anderen Kernel nicht bieten.

Und selbst wenn systemd jetzt plötzlich über Nacht unter den *BSDs laufen würde... wer würde es denn einsetzen? Nach den ganzen Diskussionen kriegst du systemd bestimmt nicht in die BSDs ;)

Das siehst du auch woanders überall. Soll FreeBSD jetzt aufhören ZFS zu unterstützen, weil Linux es nicht in den Kernel aufnehmen kann? Sollen sämtliche Konsolen-Spiele jetzt scheiß Grafik haben, weil die Hardware der Wii U scheiße ist und es unfair wäre, wenn man die Spiele dafür nicht veröffentlicht? Soll ich meine Anwendung nicht für Android und iOS veröffentlichen, weil sie unter Windows Phone nicht laufen würde?

Es läuft doch ganz einfach: Der Verlierer wird ignoriert und ist auch sich allein gestellt. Da ist doch systemd nicht das erste Projekt, was sagt: "Bietet die Features von Linux und dann laufe ich auch bei dir". Großer Vertreter Xorg, wo die BSDs erst mal Linux-Kernelfeatures nachbauen mussten und noch müssen. Oder wird hier jetzt auch Xorg boykottiert? Alle mit nem Terminal-Browser unterwegs?
 
Ja klar. Aber versetze dich in die Lage von denen mal. Du willst etwas umsetzen was alles auf ein neues Level hebt... der Linux Kernel bietet alles nötige, der Rest nicht... willst du jetzt für alle anderen Systeme, die dein Projekt wahrscheinlich eh nicht nutzen, auf den Knien rumrutschen und drum bitten, dass sie die Features auch in ihre Kernel einbauen und dann noch mal 5 Jahre warten bis das mal passiert ist?

Und das systemd nur unter Linux läuft ist ja auch keine böse Absicht, sondern schlicht darin geschuldet, dass der Linux Kernel eben Features bietet, die die anderen Kernel nicht bieten.

Und selbst wenn systemd jetzt plötzlich über Nacht unter den *BSDs laufen würde... wer würde es denn einsetzen? Nach den ganzen Diskussionen kriegst du systemd bestimmt nicht in die BSDs ;)

Das siehst du auch woanders überall. Soll FreeBSD jetzt aufhören ZFS zu unterstützen, weil Linux es nicht in den Kernel aufnehmen kann? Sollen sämtliche Konsolen-Spiele jetzt scheiß Grafik haben, weil die Hardware der Wii U scheiße ist und es unfair wäre, wenn man die Spiele dafür nicht veröffentlicht? Soll ich meine Anwendung nicht für Android und iOS veröffentlichen, weil sie unter Windows Phone nicht laufen würde?

Es läuft doch ganz einfach: Der Verlierer wird ignoriert und ist auch sich allein gestellt. Da ist doch systemd nicht das erste Projekt, was sagt: "Bietet die Features von Linux und dann laufe ich auch bei dir". Großer Vertreter Xorg, wo die BSDs erst mal Linux-Kernelfeatures nachbauen mussten und noch müssen. Oder wird hier jetzt auch Xorg boykottiert? Alle mit nem Terminal-Browser unterwegs?

Und welches neue Level haben wir durch systemd erreicht? Die Unportabilität ist ja nur ein Teilproblem, das Ding hat ja noch einige Andere, so dass ich unter dem Strich eben keinen Vorteil mehr erkennen kann. Unter dem Strich, ich sage nicht dass es garnichts nütliches macht! Übrigens gibt es auch unter den Linux-Distributionen einige Holdouts, die mehr Vor- als Nachteile sehen. Wenn systemd über Nacht lauffähig wäre, dann wäre es nach wie vor eine optionale Komponente, im Unterschied zu den meisten Linux-Distributionen. Das wäre eben *nicht* das gleiche.

Der Unterschied zur Situation mit ZFS besteht für mich darin, dass es nicht zwingend vorausgesetzt wird. Das Dateisystem ist doch deutlich stärker entkoppelt als logind und Konsorten. Xorg ist im Gegensatz zu systemd wirklich alternativlos, und es war vorher schon dort.
 
Und welches neue Level haben wir durch systemd erreicht?

Komplettes Dienst-Management inkl. Abhänigkeitsverwaltung, Sandboxing, automatische Neustarts, Limits über Prozessgrenzen hinweg, verzögertes Starten, pi pa po...

Klar, kann man jetzt alles (wie so oft hier) mit "brauch ich nicht", "will ich nicht", "geht auch wenn ich die zwölf Tools hier in FreeBSD nachinstalliere" abschmettern, aber das ist genauso ein Tunnelblick wie den Entwicklern von systemd vorgeworfen wird. Und wurde auch schon zig mal hier im Thread durchgekaut ;)

Die Unportabilität ist ja nur ein Teilproblem, das Ding hat ja noch einige Andere, so dass ich unter dem Strich eben keinen Vorteil mehr erkennen kann. Unter dem Strich, ich sage nicht dass es garnichts nütliches macht! Übrigens gibt es auch unter den Linux-Distributionen einige Holdouts, die mehr Vor- als Nachteile sehen.

Ja und sämtliche Kritikpunkte die ich immer lese beziehen sich oft auch gar nicht auf systemd sondern auf irgend ein Teilprojekt. Ja journald ist mit seinen Binärlogs scheiße... Und ich lasse einfach weiterhin rsyslogd laufen und journald schickt fleißig alles da hin und ich habe die Logs als Text.

-timesyncd, -networkd, -whateverd ist Mist? Na und? Läuft bei mir nicht. Ich nutze weiterhin die vernünftigen Dienste. Niemand zwingt hier einem den Kram auf. Und der Kram ist auch oft nur für VMs und Container gedacht.

Wenn systemd über Nacht lauffähig wäre, dann wäre es nach wie vor eine optionale Komponente, im Unterschied zu den meisten Linux-Distributionen. Das wäre eben *nicht* das gleiche.

Auch unter Linux ist systemd eine optionale Komponente... auch unter Debian kannst du von systemd wieder weg gehen. Es ist halt nur der Standard. Gentoo nutzt es gar nicht und trotzdem kriege ich dank Open Source ein aktuelles GNOME drauf.

Hier im Thread wird einfach viel zu viel durcheinandergewürfelt und einfach falsch wiedergegeben. Gerade das mit der Portabilität hat ganz andere Ursachen und hat es wie gesagt, genau so mit Xorg auch schon gegeben. Und Xorg wurde den *BSDs quasi weg genommen. Aber das hab ich ja schon gesagt. Der Feature-Vorteil vom Linux-Kernel ist das Problem, nicht systemd.
 
Hallo zusammen

Ich gesteh; war sehr skeptisch zu dem "neuem Ding" eingestellt, und bin auch jetzt noch überzeugter
Gentoo openrc User. Verfolge diesen Thread ja sehr genau. Neulich hab ich mir einen neuen vServer gemietet
und mir nix dabei gedacht; Debian 8 angeklickt. :-) hoppla, hehe.
Also das "neue Ding" lauft, rennt sogar, noch nie abgeschmettert, Logs lese ich mittlerweile wie unter
Gentoo flüssig, selbst die Administration lief geschmeidig,,, etc.
Ich bin nicht auf eurem Level und versteh Computer auch nicht so bis ins Detail wie andere von euch
deren Meinungen ich gern lese. Also mein Eindruck kurz geschrieben: als User und Zweck-Admin;
es funktioniert. Und das sogar sehr angenehm.
Werde wohl mein Nickname überdenken müssen. Habt ein schönes Wochenende.
 
Niemand bestreitet, dass es problemlos ist, wenn alles funktioniert. Der Wert misst sich daran, wie gut man damit zurechtkommt, wenn etwas _nicht_ funktioniert.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben