1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Technisches Komitee: Debian beharrt…

Nicht immer gegen Neuerungen sein. Systemd ist sehr gut.

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Nicht immer gegen Neuerungen sein. Systemd ist sehr gut.

    Autor: Unix_Linux 02.08.14 - 09:14

    Gut bei Server Systemen die nur sehr selten gebootet werden oder schon seit Jahren laufen wird das keine grosse Auswirkung haben.

    Aber speziell wenn es Desktop Systeme sind die öfter mal gebootet werden ist das ein Segen. Wenn der Bootvorgang nur noch 7 Sekunden dauert statt 1 min.

    Ausserdem kann sysv Dienst stati nicht sauber erkennen. Meist werden die Prozesse mit killall getötet das ist aber mehr als schlecht gelöst. Systemd kennt den Status der Prozesse genau. Und kann evetbasiert sauber beenden.

    Ich finde die Bewegung in Richtung systemd schon längst überfällig.

  2. Re: Nicht immer gegen Neuerungen sein. Systemd ist sehr gut.

    Autor: Bigfoo29 02.08.14 - 11:13

    "Nicht immer gleich alles in den grünen Klee loben" kann ich da gern erwiedern.

    Das Problem mit Systemd ist nicht, was es als Init-System kann sondern das, was es nebenher alles noch miterledigen will. Das beißt sich halt massiv mit dem Thema "Do one thing and do it right!". Und wenn ich mir anschaue, was die Entwickler von Systemd früher so verbrochen haben...

    Regards.



    1 mal bearbeitet, zuletzt am 02.08.14 11:13 durch Bigfoo29.

  3. Re: Nicht immer gegen Neuerungen sein. Systemd ist sehr gut.

    Autor: LH 02.08.14 - 11:18

    Bigfoo29 schrieb:
    --------------------------------------------------------------------------------
    > Das beißt sich halt massiv
    > mit dem Thema "Do one thing and do it right!".

    Keineswegs. Dies ist auch bei systemd sauber umgesetzt. Leider verwechseln viele systemd, den Dienst, mit dem gleichnamigen Projekt, welches eine reihe von Entwicklungen des gleichen Teams bündelt.
    Diese nutzen natürlich die Vorteile der jeweils anderen Lösung, sind aber eigenständige Dienste, Libs und Anwendungen.

    Zumal der Anspruch "Do one thing and do it right!" speziell bei einem Dienst rund um Linux mehr als skuril. Als ob der Kernel sich daran halten würde...

  4. Re: Nicht immer gegen Neuerungen sein. Systemd ist sehr gut.

    Autor: Bigfoo29 02.08.14 - 12:43

    Das mit dem Kernel ist ein Thema für sich (und ich bin auch eher ein Microkernel-Fan). Da gebe ich Recht.

    Trotzdem ist es schwer, einen reinen "init" des Systemd von den restlichen Diensten zu entkoppeln. Dazu greift Systemd viel zu sehr in die Eigenheiten der einzelnen Distributionen ein. Je nach Distribution gibt es Gründe, warum man eine Tastaturkonfiguration eben beispielsweise unter /etc/sysconfig/keyboard direkt konfigurieren kann und in anderen Distributionen dafür Helferlein benötigt.

    Die Frage, die sich mir stellt ist: Wollen die Admins diese Änderungen? Woher weiß Systemd denn, welche Dienste voneinander abhängen? Man sieht an Debian ja ganz gut, wie schwer man sich tat... wobei man letztlich nur die Wahl zwischen einem alten Greis, inkompatibler Pest und eben Cholera hatte...

    Zumal Systemd damit - neben dem Kernel - zum zentralen Angriffsszenario wird. Immerhin muss da per default erstmal alles durch und kann so abgefangen werden.
    Das herkömmliche Init-System hat in dieser Sicht deutlich weniger Code (und damit Anfälligkeiten) und auch Verantwortungen. Mit Systemd kann ein Apache-Prozess lustig systemfehler werfen. Solange Systemds "Journal" das rausfiltert (weil es kompromittiert wurde), fällt das in den Logfiles noch nichtmal auf. (Man muss also nichtmal mehr bis auf Kernel-Ebene hinunter um deutlich schlechter aufspürbar zu sein.)

    Regards.

  5. Re: Nicht immer gegen Neuerungen sein. Systemd ist sehr gut.

    Autor: Wander 02.08.14 - 14:41

    Bigfoo29 schrieb:
    --------------------------------------------------------------------------------
    > Trotzdem ist es schwer, einen reinen "init" des Systemd von den restlichen
    > Diensten zu entkoppeln.

    Wieso ist das schwer? Man kann nahezu alle Komponenten beim Kompiliervorgang deaktivieren.

    > Dazu greift Systemd viel zu sehr in die Eigenheiten
    > der einzelnen Distributionen ein. Je nach Distribution gibt es Gründe,
    > warum man eine Tastaturkonfiguration eben beispielsweise unter
    > /etc/sysconfig/keyboard direkt konfigurieren kann und in anderen
    > Distributionen dafür Helferlein benötigt.

    Dan beschwere dich bei deinem Distributor. Dieser entscheidet sich für oder gegen systemd und dessen Konfiguration.

    > Die Frage, die sich mir stellt ist: Wollen die Admins diese Änderungen?

    Die mir bekannten Umfragen fielen eigentlich ziemlich positiv gegenüber systemd aus. Ich denke auch nicht, dass man bei RedHat, Canonical und SUSE ein großes Interesse daran hat die Kunden zu verärgern. Aber letztendlich wird es die Zeit zeigen wie systemd im professionellen Umfeld ankommt.

    > Woher weiß Systemd denn, welche Dienste voneinander abhängen?

    Woher wissen denn andere Init-Systeme welche Dienste voneinander abhängen? Bei systemd ist dies im Vergleich zu allen anderen Lösungen jedenfalls sehr einfach gelöst:

    http://www.freedesktop.org/software/systemd/man/systemd.service.html

    > Man sieht an
    > Debian ja ganz gut, wie schwer man sich tat... wobei man letztlich nur die
    > Wahl zwischen einem alten Greis, inkompatibler Pest und eben Cholera
    > hatte...

    Die Entscheidung war innerhalb der Community eigentlich ziemlich eindeutig (pro systemd) nur stellte sich die Besetzung des Kommitees also nicht wirklich optimal für eine derartige Entscheidung heraus.

    > Zumal Systemd damit - neben dem Kernel - zum zentralen Angriffsszenario
    > wird. Immerhin muss da per default erstmal alles durch und kann so
    > abgefangen werden.

    Hast du ein konkretes Beispiel?

    > Das herkömmliche Init-System hat in dieser Sicht deutlich weniger Code (und
    > damit Anfälligkeiten) und auch Verantwortungen.

    Das kann man so und so sehen. systemd ist im Kern wesentlich komplexer, dafür ist aber dessen Konfiguration weitaus einfacher. Bei SysVinit hat man zwar ein ziemlich einfaches Programm aber dafür quält man sich eben mit riesigen und fehleranfälligen Init-Skripten herum die gleiche oder ähnliche Probleme immer wieder aufs neue lösen müssen während die entsprechende Logik bei systemd für jeden Dienst nur genau einmal implementiert werden musste - im Kern .

    > Mit Systemd kann ein
    > Apache-Prozess lustig systemfehler werfen. Solange Systemds "Journal" das
    > rausfiltert (weil es kompromittiert wurde), fällt das in den Logfiles noch
    > nichtmal auf.

    Meinst du das wirklich ernst? rsyslog kann genauso kompromitiert werden und im Gegensatz zu den meisten bisherigen Lösungen ist die Manipulation von Log-Dateien nahezu unmöglich.

    > (Man muss also nichtmal mehr bis auf Kernel-Ebene hinunter um
    > deutlich schlechter aufspürbar zu sein.)

    Muss man das bei bisherigen Lösungen? Ist rsyslog udgl. im Kernel implementiert?

  6. Re: Nicht immer gegen Neuerungen sein. Systemd ist sehr gut.

    Autor: Schnarchnase 02.08.14 - 20:45

    Unix_Linux schrieb:
    --------------------------------------------------------------------------------
    > Aber speziell wenn es Desktop Systeme sind die öfter mal gebootet werden
    > ist das ein Segen. Wenn der Bootvorgang nur noch 7 Sekunden dauert statt 1
    > min.

    Dafür brauchst du kein neues Initsystem sondern nur eine SSD, damit bootet auch ein Debian mit Sysvinit in unter 10 Sekunden. Wenn die HDD der Flaschenhals ist, bringt dir umgekehrt das neue Initsystem auch nur wenig. Die Vorteile von Systemd ist nicht die Geschwindigkeit, das ist nur ein netter Nebeneffekt.

  7. Re: Nicht immer gegen Neuerungen sein. Systemd ist sehr gut.

    Autor: jaykay2342 03.08.14 - 09:55

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Unix_Linux schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Aber speziell wenn es Desktop Systeme sind die öfter mal gebootet werden
    > > ist das ein Segen. Wenn der Bootvorgang nur noch 7 Sekunden dauert statt
    > 1
    > > min.
    >
    > Dafür brauchst du kein neues Initsystem sondern nur eine SSD, damit bootet
    > auch ein Debian mit Sysvinit in unter 10 Sekunden. Wenn die HDD der
    > Flaschenhals ist, bringt dir umgekehrt das neue Initsystem auch nur wenig.
    > Die Vorteile von Systemd ist nicht die Geschwindigkeit, das ist nur ein
    > netter Nebeneffekt.

    Ich kann dir sagen SSD+Systemd geht noch mal fixer. Auch das parallele Booten ist super. Auf meinem Laptop habe ich eine verschlüsselte /home Partition. Die Passwort abfrage hierfür kommt nach 1.5 Sec im Bootprozess und während ich das Passwort tippe bootet der Rest dank Systemd schon mal durch.

    Auf meinen Desktop/Laptop Systemen habe ich Arch Linux, also Systemd seit einer weile, dass war ganz schön Schmerz am Anfang. Ich finde gut dass Debian weiter Sysvinit unterstützen will denn ich kann gut und gerne auf diese Schmerzen bei meinen Serversystem verzichten. Die müssen auch nicht super schnell booten da sie eigentlich nur bei kritischen Kernelpatches neu gebootet werden. Da hab ich lieber ein ultra abgehangenes Initsystem was auch garantiert wieder hoch kommt. Systemd ist zwar mittlerweile echt besser als vor 2 Jahren aber ich würde es gern noch ein paar Järchen weiter abhängen lassen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Senior Consultant Network Security (m/w/d)
    operational services GmbH & Co. KG, Dresden, Berlin, Frankfurt am Main, München
  2. Consultant (m/w/d) Software Engineering
    J.M. Voith SE & Co. KG | DSG, Heidenheim
  3. DevOps Engineer (w/m/d)
    Statistisches Bundesamt, Wiesbaden
  4. Gruppenleiter*in Industrie 4.0
    Fraunhofer-Institut für Integrierte Schaltungen IIS, Nürnberg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. Teilnahmeschluss 28.09., 19 Uhr
  2. (u. a. Dandara: Trials of Fear Edition für 4,99€, King of Dragon Pass für 3,60€, Strategy...
  3. 9,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de