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

Status
Für weitere Antworten geschlossen.
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...
 
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?
 
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.
 
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. :p

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...) :ugly:
 
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.
 
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...
 
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
 
Zuletzt bearbeitet:
mark05 schrieb:
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
Zum Vergrößern anklicken....

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.
 
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/freebsd-hackers/2012-January/037581.html
 
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
 
christian83 schrieb:
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
Zum Vergrößern anklicken....

Hallo,

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

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

Gruß

marmorkuchen
 
dafür sind ja die Targets gedacht, ähnlich der Milestones unter Solaris.
Zum Vergrößern anklicken....
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
 
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 :)
 
Zumal bspw. portmaster oder Kamis pkg_libchk der gute Beweis sind, das man leckere und nun nicht wirklich schnarchlahme Scripte schreiben kann.
 
Weil Kamikaze und Doug Barton wissen, wie man gute Shellscripte schreibt. Und da die eigentliche Ausführung (Ports bauen, ldd(1) in Massen losschicken) um ganze Universen mehr Leistung als das Script benötigt. Beides trifft auch auf das Free/NetBSD RC-System zu, womit wir dann wieder beim Punkt "Sinn von RC-Systemen in C" sind. :)
 
Es ist schon witzig, dass sich einige wenige Linux-Entwickler wie Microsoft verhalten: Solange es von Linux auf Linux portiert werden kann, ist alles in Ordnung.

Es sehe mit großem Schrecken und gleichzeitig auch mit großem Erstauen, wie einige wenige Linux-Anwendungsentwickler den OpenSource-Gedanken ad absurdum führen. Die Programme werden durch zusätzliche Tools wie DBus, GStreamer, HAL, DeviceKit usw. immer komplexer und damit fehlerhafter. Der berühmte Ausruf "dann schau in den Quelltext, ist doch OpenSource" läuft angesichts der Komplexität und der stetig steigenden Zahl der Abhängigkeiten immer mehr ins Leere. Wie es so schön im Artikel beschrieben wurde, wird damit der Gedanke der Einfachheit und Überschaubarkeit weggeworfen.
Aber UNIX-Anwender/Anhänger haben es schon von Anfang an gesagt: Linux != UNIX

Viele Grüße

JueDan

PS: Ich bin mal gespannt, bis BIND, Apache, usw. nur noch unter Linux funktionieren...
 
Noch haben wir ja das Glück, dass Ubuntu systemd nicht nimmt, was bedeutet, dass ein Großteil der Linuxe eben ohne systemd läuft. Im Gegensatz zu der Audio-Front (Pulseaudio) gibts also noch Chancen für Pluralität...
 
Damit der Verschwörungsthread neue Nahrung bekommt, nun entwickeln Leute bei Red Hat einen Druckerspooler als Ersatz für Cups. Man, die müssen ja Resourcen ohne Ende haben.
 
Hehe, gerade als ich den Artikel bei PL gelesen habe, kam ne E-Mail rein, dass hier im Thread einer was Neues geschrieben hat. Ich war mir 100% sicher, was drin stehen würde. ;)
 
Sie brauchen ja einen neuen Druckerspooler, da die bösen Jungs von Apple in ihrer Rolle als CUPS-Entwickler Linux kurzerhand für obsolet erklärt und die Unterstützung dafür mehr oder weniger eingestellt haben. Und natürlich fluchten, schrien und keiften Teile er Linux-Community über die böse, propietäre Software, die per Vendor-Lockin und skrupellosem Ausnutzen der eigenen Marktmacht alternative Betriebssysteme aus dem Markt drängen möchte. Siehe dazu auch: http://www.heise.de/open/meldung/CUPS-1-6-unterstuetzt-Linux-schlechter-1435234.html
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben