Hallo zusammen, Am 05.05.2013 19:17, schrieb David Haller:
Hallo,
Am Sun, 05 May 2013, Sebastian Siebert schrieb:
Hierfür ist eine eigene systemd-Implementierung mit dem entsprechenden Dienst verantwortlich:
Eierlegendewollmilchsau halt. Nix funktioniert mehr... Nein, es mußten ja unbedingt neue/andere Config-Dateien sein. Ich hasse Systemd! (siehe andere Mails. Ich verwende systemd nicht. Warum auch!)
Das ist natürlich kein Geheimnis, dass du systemd nicht magst. Hast ja auch schon in der englischen ML ausführlich durchblicken lassen. :-)
Ich würd ja gern mal den Poettering und die Verantwortlichen, die das in die Distributionen einbauen zum Gespräch mit "Reason" bitten.
Hallo? Geht's noch? Für ein paar ms beim booten alles über Bord werfen und so ein Ungetüm wie systemd?
An der Unix-Philosophie ist was dran: "Mache nur eine Sache und mache sie gut." [1] ;-) Ich muss ehrlich gestehen, dass ich die Idee hinter systemd nicht schlecht finde. Jedoch wegen der Langsamkeit von SysVinit auszutauschen, halte ich eher für vorgeschoben. Eher wollte man die Ressourcen an einer Sache bündeln. Nur ein Feature ist für mich interessant, die eigentlich systemd verkörpern sollte: Dienste werden nur gestartet, wenn man sie tatsächlich braucht (ähnlich wie xinetd). Nun ja, bisher ist recht wenig zu sehen bzw. überhaupt umgesetzt. Im Moment werkelt systemd mehr oder weniger wie SysVinit. Dafür hätte man nicht unbedingt SysVinit abschaffen müssen. Ja, auch systemd musste man erst mal beibringen, was es heißt die SuSE-like Init-Skripte korrekt zu verarbeiten. Man nennt sowas auch zurechtbiegen. Wenn ich mir die ganzen (teilweise echt makaberen) Patches für systemd in unserem OBS anschaue, dann wird mir davon immer noch schlecht. [2] SysVinit hat längst nicht soviele Patches wie systemd. [3] Dies spricht schon eher für ausgereift. :-)
Nurmal so nebenbei (beides mit sysvinit): Alte Kiste (Athlon 500 / 500 GB IDE HDD / 768 MB RAM): Einschalten-Grub Grub-Login Konsole-X <10s <10s <6s Neue Kiste (Athlon II X2 250/3GHz / 128G SSD / 4GB RAM): Einschalten-Grub Grub-Login Konsole-X >>30s ~15s >>6s
beim Einschalten-Grub hat die alte Kiste allerdings wesentlich weniger LW abzuklappern (4 IDE Platten (davon 1 DVD) vs. 8 SATA + 2 IDE (davon 1 DVD)). Aber: ohne SSD war z.B. Konsole-X locker über 12s. Und das mit ner schnellen SATA HDD vs. der lahmen IDE-HDD.
Also, Schema (nur Grub-X): erstmal fügen wir massig Bloat hinzu und dann versuchen wir an der falschen Stelle (init) ein paar ms einzusparen? Seehr clever. Denn die Zeit von Grub-Login kann ich recht gut einzelnen Verzögerungen zuordnen, und einige hab ich durch angepasste initscripts auch schon vermieden ( durch ein '{ ... } &'). Speziell smartd + hddtemp derart zu entkoppeln hat locker mal 10-20s gebracht zwischen "Grub" und "Login". Die Sekunden hab ich dann für's login, damit nach dem 'startx' gkrellm aber mit den hddtemp-Sensoren startet sollte ma beim login nicht zu schnell sein ;)
Nun ja, in der Performance tun sich beide Init-Systeme nicht wirklich viel, wenn man dies mal genau nimmt. :-) Ich halte systemd immer noch für jungfräulich und müsste noch länger abhängen. Da einige Dienste noch nicht an systemd angepasst wurden, so bleibt das Potenzial von systemd auf der Strecke. Sprich: Schnelles hochfahren mit wenigen Diensten und der Rest wird bei Bedarf gestartet.
Verantwortlich ist die Konfiguration unter /usr/lib/tmpfiles.d/tmp.conf
# sed -n '/^[^#].*/p' /usr/lib/tmpfiles.d/tmp.conf
==== /usr/local/bin/delcomments [LIZENZ: GPLv2] ==== #!/usr/bin/sed -f /^[[:space:]]*#/d /^[[:space:]]*$/d ====
Oh, kein Einzeiler heute? Schade. :-) [1] http://de.wikipedia.org/wiki/Unix-Philosophie#McIlroy:_A_Quarter_Century_of_... [2] https://build.opensuse.org/package/show?package=systemd&project=openSUSE%3AFactory [3] https://build.opensuse.org/package/show?package=sysvinit&project=openSUSE%3AFactory -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: http://www.sebastian-siebert.de Wichtiger Hinweis zur openSUSE Mailing Liste: http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org