Wander schrieb:
Noch mal, die meisten Funktionen sind optional und werden genauso wie vorher auch in separaten Prozessen ausgeführt. Was kritisierst du also konkret?
Steht in meinem ersten Post und in dem von dir gequoteten. Werde es nicht wiederholen.
Wie willst du ein für heutige Zwecke sub-optimales Protokoll wie X11 ersetzen ohne "die halbe Wert drumherum" zu beeinflussen? Man muss das Protokoll brechen um es besser zu machen und somit auch die darauf basierenden Technologien ändern; siehe GTK+, Qt, EFL, diverse Fenstermanager, ... Ähnlich verhält es sich mit systemd; will man möglichst frühes Logging im Bootprozess muss man ein Init-System entwickeln, dass dafür auch konzipiert wurde und der entsprechende Logging-Dienst auch diese Möglichkeiten nutzt.
Das von dir stets propagierte Feature steht in uberhaupt keinem Verhaeltnis zum Aufwand, den alle damit haben sich darauf anzupassen. Exakt das gleiche jetzt mit /etc. Was war jetzt noch einmal das Killerargument, um das zu rechtfertigen? Achso, man will agnostic machines haben, wie docker es fuer services bietet. NA DANN ist es ja total abwegig einfach docker fuer applikationen zu etablieren ohne gleich nahezu alle Pakete zu aendern.
Und systemd tut das? Wer zwingt dich systemd zu nutzen? Und FreeBSD ist eben mehr als nur "bis zum Userland", es ist ein komplettes Betriebssystem inkl. Userland.
Ja, systemd will vorschreiben, wo/wie services in deinem OS laufen. Das ist die Quintessenz von dem Artikel. Deine Ausfuehrungen zu FreeBSD sind irgendwie nicht das, was ich als Erfahrung habe. Installier dir einfach mal freebsd auf dem Pi und erzaehl mir dann nochmal, dass das komplett ist. Minimalistischer gehts kaum und genau das ist auch der Grund, wieso ein freebsd-update laengst nicht so anfaellig ist, wie ein apt-get dist-upgrade.
Wenn du keinen Bedarf für systemd hast steht es dir frei etwas anderes zu nutzen, niemand zwingt dich dazu.
Mit der Logik zwingt mich auch keiner rc.d in bsd zu nutzen. Joah, ausser ich hab kein Bock alles selber zu machen. Was glaubst du denn, was aus apache2 aus debian wird, wenn conf nicht mehr in /etc liegen soll? Natuerlich wird dadurch VON SYSTEMD erzwungen, dass Pakete sich umstellen und wer es nicht tut, darf mit alten Paketen leben.
Du implizierst aber, dass systemd generell Schwachsinn ist und somit die Mehrheit der Distributoren und Entwickler an Realitätsverlust leiden.
Wo sage ich, dass systemd Schwachsinn ist? Wo spreche ich von Realitaetsverlust? Nur so am Rande: Die Mehrheit von unixoiden OS im Einsatz nutzt alles, aber nicht systemd.
systemd löst einfach viele Probleme die vorher nicht lösbar waren und ist nicht umsonst so erfolgreich.
Kleine Analogie: check_mk loest auch Probleme wie z.B. dass es damit moeglich ist mehrere Tausend hosts zu monitoren. Wird auch immer mehr genutzt und das ist loeblich. Aber ist das der Freibrief dafuer, dass sie jetzt cmdb einbauen? Mit Sicherheit nicht.
Quellen? Und abgesehen davon ist also nur das was die Masse benötigt sinnvoll? Ist dementsprechend nicht auch systemd sinnvoll weil die Masse dies eindeutig bevorzugt; siehe RHEL, Debian, Ubuntu, Arch Linux, openSUSE, Fedora, Sailfish OS, Tizen, ...
Eindeutig? Debian war knappe Mehrheit, Shuttleworth wills nur, weil er offensichtlich kein Bock mehr auf upstart hat und bei Sailfish und Tizen musste ich hart lachen. Und ja, solche Veraenderungen wie systemd sie etablieren moechte sind nur sinnvoll, wenn die Masse auch den business-value daran erkennt.
Ich kenne eigentlich keinen Adminstrator der damit bisher keine Probleme hatte. Wie können bisherige Init-Systeme z.B. ein System herunterfahren in dem ein Prozess beim Beenden Helfer-Prozesse startet? Mit systemd ist dies aufgrund der Nutzung von cgroups kein Problem.
Ka, ich hab Environments mit vierstelliger Anzahl von Maschinen administriert und kenn sowas nur von kaputten init-scripten bei node-Anwendungen (z.B.). Wenn man es da genau nimmt, liegts da halt auch nicht an den init-systemen, weil es sowohl unter sysvinit als auch upstart passiert. Aber das is bestimmt auch nur uber-systemd, was das kann...
Wo werden dort automatisch Abhängigkeiten aufgelöst? Das schöne an systemd ist doch gerade, dass man diese Abhängigkeiten in der Regel nicht explizit definieren muss; systemd macht dies automatisch mithilfe von Socket Activation.
Zeilen 3-6. Automatisch dependencies aufzuloesen kann auch nur auf einem Konzept basieren: Annahmen. Assumptions sind scheisse fuer Geschaeftsprozesse, aber das lernt man anscheinend erst, wenn man grad mal tausende User ausgelogt hat, weil irgendeine Annahme dafuer gesorgt hat, dass der session-storage durchstartet.
Nur so am Rande: Ich mach seit ueber nem Jahr mittlerweile beruflich groessenteils engineering mit provisioning-Loesungen (chef, ansible) und ich versicher dir, dass jede Automatik mit ihren Annahmen an Grenzen schneller stoest als klare, manuell definierte Abhaengigkeiten. Das ist auch der Grund, wieso z.B. MaaS funktioniert.
Wie gesagt, wenn du keine Bedarf für systemd hast nutze es nicht. Oder willst du anderen vorschreiben was sie nutzen und/oder entwickeln sollen?
Siehe oben.
Wenn du ein Tool für eine Aufgabe möchtest, dann nutze doch einfach auch diese Tools. Wie besuchst du eigentlich diese Webseite? Holst du dir mit wget (obwohl das ja eigentlich auch schon bloat ist, da es mehrere Protokolle unterstützt) sämtliche Inhalte und lässt darauf etliche Parser, Interpreter und Renderer laufen? Wie editierst du Text oder schreibst Code? Doch wohl nicht mit Bloatware wie vi, vim, emacs, nano oder gar einer IDE? Genauso wie du womöglich vim odgl. damit rechtfertigst, dass es alles für das effiziente Bearbeiten von Text-Dateien bereitstellen soll, definiere ich den Zweck von systemd einfach so, dass es alles tun soll um ein Userland unter Linux hochzufahren und zu verwalten; somit ist es für mich auch kein Bloat sondern erfüllt einfach seinen Zweck.
Clown gefruehstueckt? War nicht witzig. Emacs ist bloated. vim ist bloated. Kennste surf? Das ist nen guter browser, weil er genau das tut, was ein browser tun soll und eben nicht mehr. Deine Definition ist nicht das, was systemd sich da vorstellt und journald ist das offensichlichste Beispiel dafuer, dass systemd eben nicht nur ein init-system sein moechte, sondern eben der Diktator der unix-Welt.
Falls du immernoch nicht siehst, was ich an systemd kritisiere:
Zehkul; schrieb:
Und? Cat -v ist auch schon Bloatware.
Da wuerde ich gerne einen dicken roten Pfeil an das "Und?" machen. Genau das ist das Problem.
Das glaubst Du doch selbst nicht, oder?
