staging.inyokaproject.org

Systemd und SysVinit sind mir ziemlich egal, aber Hyouka ist sehr, sehr gut.

Systemd ist einfach sehr viel schneller als SysVinit und kann, soweit ich es sehe, alles was sysVinit kann. Es ist außerdem leicht, z.b den standard Display Manager zu ändern.

Deswegen bin ich auch sehr zufrieden mit Systemd.

Und Hyouka ist ganz gut.

skull-y schrieb:

Es gibt und gab keine Versuche, da der BSD-Kernel keine cgroups kennt. Zu dem ist es seitens der Nutzer nicht gewollt, weil Linux doof und BSD grundsätzlich besser als alles andere ist.

Die *BSD-Leute mögen einfach die GPL nicht.

skull-y schrieb:

Es gibt und gab keine Versuche, da der BSD-Kernel keine cgroups kennt.

FreeBSD bietet Resource Limits: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security-resourcelimits.html Ob es nun cgroups bei Linux sind, oder Resource Limits bei FreeBSD, beides erfüllt im jeweiligen System seinen Zweck. Was das init System angeht, bei FreeBSD gilt POLA: http://en.wikipedia.org/wiki/Principle_of_least_astonishment Innerhalb eines Zweiges (Beispielsweise 9x) behält FreeBSD auch eine stabile ABI, also die RELEASE 9.0, 9.1 und das kommende 9.2 bleiben kompatibel. Ohne Not werden die FreeBSD Entwickler diese über viele Jahre bewährten Prinzipien wohl nicht aufgeben wollen. Die FreeBSD User genießen das. Es muss ja auch nicht auf allen Betriebssystemen jedes Jahr ein anderes init System sein. Zumal das bestehende funktioniert. Ein Diagnose Werkzeug für das FreeBSD init System gibt es auch: rcorder

giygas

skull-y schrieb:

Es gibt und gab keine Versuche, da der BSD-Kernel keine cgroups kennt. Zu dem ist es seitens der Nutzer nicht gewollt, weil Linux doof und BSD grundsätzlich besser als alles andere ist.

Die *BSD-Leute mögen einfach die GPL nicht.

Ich weis, das ist ja auch kein Beinbruch. Ab hier beschreibe ich einen Eindruck, der bei mir entstanden ist:

Es wird aber viel gemeckert, dass viele Projekte ihre Software mehr an Linux anpassen und *BSD aussen vor gelassen wird (was nicht heißt, dass ich das gut finde). Das wird aber auch den Nutzern angelastet, was ich für falsch halte. Der einfache Nutzer, der sein System mit ein paar Klicks installiert und dann laufen sehen will, wird oft nicht mal wissen, wie es mit den Lizenzen aussieht. Er wird sich auch, verständlicher Weise, einen Dreck darum scheren. Was Allgmein fehlt, ist ein gemeinsamer Nenner in Sachen Lizenz und einigen anderen Dingen nötig. Da werden jedoch weder die Entwickler von Linux, noch die von BSD darauf eingehen, denn dann müsste man Kompromisse eingehen.

Eindruck beendet.

@ trollsportverein

Du hast Recht, es muss nicht auf allen OS immer ein neues init-System verwendet werden. Das wollte ich damit auch nicht sagen.

Developer92 schrieb:

Ich muss mir echt mal ansehen, was SysV-Init noch für Nachteile hat, ausser, dass ein aus dem Rahmen fallender Prozess nicht sauber beendet werden kann.

Das halte ich in der Praxis eigentlich eher für weniger wichtig. Schwerwiegendere Nachteile von SysV Init sind meiner Meinung nach:

• In SysV Init kann ich Abhängigkeiten nur innerhalb eines Runlevel definieren. Wenn ich so was wie "Starte immer X, bevor du Y startest" haben will, muss ich dafür entweder einen eigenen Runlevel definieren, oder das von Hand in meinem Init-Skript machen.

• Mit SysV Init werden alle Jobs strikt nacheinander ausgeführt. Das ist ungünstig für Jobs, die länger brauchen können, z.B. weil sie auf Netzwerk-Ressourcen o.ä. warten. Es kann z.B. dazu führen, dass man bei Ausfall des Netzwerks mehrere Minuten zusätzlich warten muss, bis man sich anmelden kann. Und ich kann damit nicht sinnvoll auf Bedingungen warten, die möglicherweise gar nicht eintreten.

• In SysV Init kann ich nur SysV Init-Jobs als Abhängigkeiten benutzen, aber nicht z.B. "Dateisystem XY ist eingehängt" oder "Netzwerk-Schnittstelle XY ist bereit" (solange ich dafür nicht eigene Init-Skripte schreibe)

• Es ist umständlich und unübersichtlich, in jedem Init-Skript den gleichen Code für die Auswertung der Parameter usw. zu haben.

• SysV Init ist für die Diensteverwaltung zur Laufzeit des Systems weitgehend unbrauchbar, obwohl ich da meistens den gleichen Code, Abhängigkeiten usw. wie beim Systemstart verwenden möchte.

Systemd übernimmt immer mehr Aufgaben, ob das im Sinne des Erfinders ist bezweifle ich mal. In 2 JAhren kontrolliert Systemd das ganze System und bestimmt alles siehe auch hier Da ist mir Upstart schon lieber nur wie lange kann sich das halten?

pitt-admin schrieb:

Systemd übernimmt immer mehr Aufgaben, ob das im Sinne des Erfinders ist bezweifle ich mal.

Das ist doch genau der Sinn eines guten Start-Systems.

In 2 JAhren kontrolliert Systemd das ganze System und bestimmt alles siehe auch hier

Oh je, da hat tatsächlich mal jemand einen Weg implementiert, um Netzwerkinterfaces ohne überrraschende udev-Regeln, die ungefragt automatisch am Nutzer vorbei erstellt werden (also kein fester Bestandteil eines Paketes sind) und Probleme nach jedem Board-Wechsel machen (ich sag nur /etc/udev/rules.d/70-persistent-net.rules) nach ihrer physikalischen Quelle zu benennen und man kann gar nichts dagegen tun (außer es wie in der Dokumentation erwähnt abzuschalten 😈 ) http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Da ist mir Upstart schon lieber nur wie lange kann sich das halten?

Wenn es so weiter macht und nicht mal den Start von lightdm sauber hinbekommt (oder dafür so lustige Würgarounds wie https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1066410/comments/44 nötig bleiben) dann hoffentlich nicht mehr allzu lange...

seahawk1986 schrieb:

Wenn es so weiter macht und nicht mal den Start von lightdm sauber hinbekommt (oder dafür so lustige Würgarounds wie https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1066410/comments/44 nötig bleiben) dann hoffentlich nicht mehr allzu lange...

Was mein System betrifft, so läuft der Displaymanager sauber und brauche nicht würgen. ISt das Problem mit dem DM vielleicht nur unter Unity?!

Meine Meinung ist immer noch ein Programm für eine Sache, so etwas läuft immer noch am besten!

Angeblich soll das neue systemd nun auch in der Lage sein Festplatten selbst einzubinden. Sollten die OS darauf abgestimmt werden, so ist SysVinit meiner Meinung nach tot, so wie upstart auch.

Nicht angeblich:

http://www.golem.de/news/init-system-systemd-207-macht-fstab-optional-1309-101587.html

Eine vorhandene fstab-Datei wird aber immer noch benutzt, da systemd z.B. (noch) nicht mit Netzwerkfreigaben und anderen Spezialfällen umgehen kann. Dazu kommt, dass viele Benutzer eigene Vorstellungen davon haben in welches Verzeichnis ihre zusätzlichen Partitionen eingebunden werden sollen. Das kann systemd nämlich nicht erraten.

Schon, aber die fstab ist da nicht wirklich nötig, sondern optional.

pitt-admin schrieb:

Schon, aber die fstab ist da nicht wirklich nötig, sondern optional.

Was ich persönlich nicht als so toll erachte. Was ist, wenn ich eine Swap-Partition habe, die nicht eingebunden werden soll? Keine Ahnung, was Systemd in dem Fall macht, wobei das bestimmt irgendwo steht...

mfg

Developer92 schrieb:

pitt-admin schrieb:

Schon, aber die fstab ist da nicht wirklich nötig, sondern optional.

Was ich persönlich nicht als so toll erachte. Was ist, wenn ich eine Swap-Partition habe, die nicht eingebunden werden soll? Keine Ahnung, was Systemd in dem Fall macht, wobei das bestimmt irgendwo steht...

mfg

Ganz meine Meinung, es steht geschrieben das die fstab beachtet wird, was nicht in dieser steht macht systemd. Da swap wie auch / normal immer gemountet werden wird das dann systemd übernehmen. So sieht es zumindest im moment aus. Vielleicht gibt es dann auch so eine Art Blacklist für systemd, abwarten. Wenn die fstab erhalten bleibt wird es wohl keine frickellei in upstart geben.

Das Ubuntu-Init-System ist eine Insellösung.

Ubuntu setzt auf systemd ☺

Na, wenn wir den Thread schon ausbuddeln, dann richtig. 😉

glasenisback schrieb:

Eine vorhandene fstab-Datei wird aber immer noch benutzt, da systemd z.B. (noch) nicht mit Netzwerkfreigaben und anderen Spezialfällen umgehen kann.

Update: Ab Version 208 verfügbar (Abschnitt remote-fs.target).

Dazu kommt, dass viele Benutzer eigene Vorstellungen davon haben in welches Verzeichnis ihre zusätzlichen Partitionen eingebunden werden sollen. Das kann systemd nämlich nicht erraten.

Die fstab aber auch nicht. Und ob du das in der fstab festlegst oder in der entsprechenden mount-unit, ist dann doch reine Gewöhnungssache.

Developer92 schrieb:

Was ist, wenn ich eine Swap-Partition habe, die nicht eingebunden werden soll? Keine Ahnung, was Systemd in dem Fall macht, wobei das bestimmt irgendwo steht...

Dann sollte ein

1

systemctl disable $swap_partition.swap

helfen. Mehr zu dem Thema "systemd und Swap-Partitionen" weiß das Handbuch.

Gruß
DonKrawallo