systemd, der nächste Horror für BSD?

[Rakor]

Es ist halt ein Bastelsystem... Schon immer gewesen.

[-Nuke-]

Problem (für mich zumindest) ist ja auch nicht was systemd sein soll, sondern was es aktuell ist.C-Programme, statt Shell-Skripte, nur um den Systemstart ne Sekunde zu beschleunigen? Binäre Logdateien? Aufnehmen von udev und syslog in einen fetten Dienst? Linux-Only-Philosophie? So gut wie keine Dokumentation?

Haben die schon mal was von Portabilität, Dokumentation und Sicherheit gehört?

Ne, so nicht...

[darktrym]

Der gute Lennart hat ja einen Weg aufgezeigt, wie man die Bootzeit auf 2s verkürzen kann.
Irgendwie hab' ich doch das Gefühl, dass für die Ich-hasse-Windows-und-MacOS-Nutzer dieses ein wichtiges Argument ist.
Wobei das sicher lustig ist, wenn etwas beim Booten schiefgeht den Fehler zu finden. Funktioniert systemd so wie gedacht oder fehlt eine Option oder gar unglückliche Reihenfolge?

[-Nuke-]

Naja, die Bootzeit ab systemd meint der Gute Herr da aber und nicht "Bootzeit ab Knopfdruck".

Bei meinem ArchLinux vergehen ab dem Init-Prozess auch nur 5-10s bis X11 startet und das auf einem Netbook mit Atom-CPU...

Und Bootzeit ist echt sooooooo irrelevant (zumindest für mich)... ich meine, ich boote meine Rechner ein mal am Tag und das meist auf dem Weg zum Klo oder sonst was. Danach ist das Teil den Rest des Tages entweder an oder im Standby.

[thorwin]

Aus irgendeinem - für mich nicht nachvollziehbaren - Grund scheint das aber von zentraler Bedeutung zu sein. Bei neuen Windows-Versionen wird die verkürzte Bootzeit auch immer gerne als zentrale Neuerung angeprießen.

Vielleicht gibt's ja irgendwann eine Teilung zwischen Server-Linux (mit sysv-init) und Desktop-Linux (mit systemd und allen neuen Schweinereien, die sonst noch so kommen...)

[xbit]

Bei Windows ist eine kurze Bootzeit ja auch sinnvoll. Das System muss man ja oefters rebooten.

Wobei -wie auch schon geschrieben- ArchLinux recht schnell bootet, ohne dass der systemd verwendet wird. Es geht also anscheinend auch ohne.

[thorwin]

Arch verfolgt ja auch eine recht minimalistische Philosophie iirc. Boote mal Ubuntu 12.04, das ist selbst auf fetter Hardware irgendwie deutlich zäher. Ist ja auch kein Wunder, wenn ich sehe, wie viele Dienste da laufen, bevor sich auch nur ein Benutzer angemeldet hat...

[mark05]

moin
boot zeit ist irrelevant weil es augenwischerei ist.

was bring es mir das meine gui schneller zu sehen ist aber das ganze system damit beschaefftigt ist die ganzen parallel gestarteten hintergrundproccesse abzuarbeiten
und somit fast nicht auf eine eingabe etc reagiert.

der boot proccess wird doch nicht schneller oder langsamer durch sytemd simplein sysv init etc.

schneller , subjektiv und optisch , wird es ja nur durch das parallel starten der dienste.

wenn da jetzt zufaellig eine mysql db dabei ist mit fetter datenbank drin und dort ein
table check gemacht wird nutzt keine software der welt was um denn vorgang zu beschlaeunigen nur hardware

wie schon gesagt ,da wird eine baustelle aufgemacht die vollkommen unnoetig und sinnlos
ist.

fuer ein 5-10 sekunden optischer , subjektiver bootbeschleunigung.

holger

[jmt]

Teilweise dauern Dinge bei Parallelisierung auch länger.

[solarix]

Zitat von mark05

moin
boot zeit ist irrelevant weil es augenwischerei ist.

was bring es mir das meine gui schneller zu sehen ist aber das ganze system damit beschaefftigt ist die ganzen parallel gestarteten hintergrundproccesse abzuarbeiten
und somit fast nicht auf eine eingabe etc reagiert.

der boot proccess wird doch nicht schneller oder langsamer durch sytemd simplein sysv init etc.

schneller , subjektiv und optisch , wird es ja nur durch das parallel starten der dienste.

wenn da jetzt zufaellig eine mysql db dabei ist mit fetter datenbank drin und dort ein
table check gemacht wird nutzt keine software der welt was um denn vorgang zu beschlaeunigen nur hardware

wie schon gesagt ,da wird eine baustelle aufgemacht die vollkommen unnoetig und sinnlos
ist.

fuer ein 5-10 sekunden optischer , subjektiver bootbeschleunigung.

holger

Vor allem ist es völlig wumpe wenn ich mehr als 100 Platten hinten dran hab, wie lang die Büchse beim hochfahren dauert und ein reconfigure reboot wird durch Parallelisierung auch nicht wirklich schneller.

Das ist vielleicht für Desktops interessant, aber nicht große für Laster.

[Yamagi]

Auch für Desktops stellt sich allerdings die Frage, weshalb man das RC-System gleich in C schreiben muss. Das ist sozusagen die Kanone, mit der man auf einen armen, kleinen Spatzen schießt. Nichts gegen C, aber es ist in meinen Augen einfach nicht das richtige Tool für den Job. Viel zu schwer zu schreiben, zu schwer zu debuggen (und wenn es dank endloser Makro-Orgien einfacher zu schreiben wird, wird es noch schwerer zu debuggen), prinzipbedingt vergleichweise fehleranfällig (beim Systemstart natürlich besonders lustig), etc. Das RC-Scripte meist saulahm sind, hat zwei simple Gründe:
- Zum Interpretieren der Scripte wird meist eine fette, interaktive Shell (Bash, zsh) genutzt, die einfach kein guter Interpreter ist und nicht sein soll. Diese Shells brauchen relativ lange zum Starten, forken sich etliche Male in Subshells und Kommandos, interpretieren die Scripte anstatt sie durch einen JIT-Compiler zu jagen, etc.
- Die meisten Leute zu blöd brauchbare Shellscripte zu schreiben, fallen auf höchst ineffiziente Konstrukte zurück. Man kann ihnen aber keinen Vorwurf machen, da der Bourne-Syntax nun einmal sehr krude ist.
Wenn man die ganze Sache beschleunigen will, ergeben sich da direkt gleich mehrere Möglichkeiten. Erst einmal eine schlankere Shell, zum Beispiel die ash, die in unterschiedlichen Varianten in FreeBSD und Debian als /bin/sh dient. Wobei auch die noch jede Menge nicht genutztes Optimierungspotential [1] hat. Die nächste Option wäre es, einen brauchbaren und vor allem zeitgemäßen Interpreter zu schreiben. Oder man spart sich das ganze und nimmt gleich eine moderne Scriptsprache. Es gab ja durchaus für Linux RC-Systeme in Python und ähnlichem. Zuerst sollte man sich allerdings die Frage stellen, ob die RC-Scripte am Ganzen, unter Linux bereits 10x optimierten Prozess überhaupt noch einen nennenswerten Anteil haben, oder ob inzwischen der Punkt erreicht ist, an dem die Kosten für jede weitere Nanosekunde den Nutzen bei Weitem übersteigen.

Wie dem auch sei, ich hoffe wirklich, dass Herr Poettering mit seinem systemd inkl. Binärlogging den Bogen überspannt hat. Realistisch gesehen werde ich damit allerdings falsch liegen.

1: http://lists.freebsd.org/pipermail/f...ry/037581.html

[christian83]

Ich bin ja der Meinung das der Systemstart so lange dauern sollte wie es notwendig ist um ein System sauber zum laufen zu bekommen.

Wenn beim booten etwas schief geht hat man meist die Brille auf, vor allem wenn man als normaler User keine Möglichkeit mehr hat das ganze nachzuvollziehen.

Es ist jetzt ja schon je nach Distribution kaum noch sinnvoll möglich Netzwerkfreigaben richtig einzuhängen. Meine wichtigen Daten sind mit EncFs verschlüsselt und sollen direkt nach dem starten in meinem home eingebunden werden... Das dumme ist nur das man nicht weiß ob und wann das eingebunden Netzlaufwerk überhaupt verfügbar ist... Das System startet jetzt zwar 3 Sekunden schneller, aber ich brauchst 30 Minuten länger um mir einen sicheren Autostartscript zu schreiben...

Aber das ist es ja was man will...

Grüße

[marmorkuchen]

Zitat von christian83

Es ist jetzt ja schon je nach Distribution kaum noch sinnvoll möglich Netzwerkfreigaben richtig einzuhängen. Meine wichtigen Daten sind mit EncFs verschlüsselt und sollen direkt nach dem starten in meinem home eingebunden werden... Das dumme ist nur das man nicht weiß ob und wann das eingebunden Netzlaufwerk überhaupt verfügbar ist... Das System startet jetzt zwar 3 Sekunden schneller, aber ich brauchst 30 Minuten länger um mir einen sicheren Autostartscript zu schreiben...

Aber das ist es ja was man will...

Grüße

Hallo,

dafür sind ja die Targets gedacht, ähnlich der Milestones unter Solaris.

Systemd ist eh nur ein müder SMF-Abklatsch...

Gruß

marmorkuchen

[christian83]

dafür sind ja die Targets gedacht, ähnlich der Milestones unter Solaris.

Schon, aber um solche Probleme erst einmal zu lösen muss man mehr Zeit investieren als man jemals wieder mit einem schnellen Booten rausholen kann.

Der Startvorgang ist ja eine der wichtigsten Sachen und der sollte so sicher wie möglich sein. Mann muss sein System sauber, sicher und planbar starten können. So ganz nebenbei gibt es noch genügend andere Baustellen da will ich mich als Anwender nicht noch am Systemstart abmühen müssen.

Der Unix Grundgedanke ist ja auch mache ein Programm das eine Sache richtig macht. Oder ein einfache Code der das macht was er soll ist das Ziel. Nur leider versucht man hier sich gegenseitig mit immer komplexeren Systemen zu übertrumpfen...

Wer zum Teufel braucht ein Binärlogging? Da will man wohl den normalen Anwender daran hindern zu verstehen was passiert oder was? Ich verstehe es zumindest nicht...

Grüße

[marmorkuchen]

Hallo,

wie gesagt nur ein müder SMF-Abklatsch.

SMF dagegen ist wirklich nett und vor allem durchdacht.

Gruß

marmorkuchen

p.s. Bootzeiten verkürzen, unheimlich wichtig