Systemd und SysVinit sind mir ziemlich egal, aber Hyouka ist sehr, sehr gut.
Systemd vs. SysVinit
Anmeldungsdatum: Beiträge: 3642 Wohnort: Köln |
|
||
Anmeldungsdatum: Beiträge: 99 |
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.
Die *BSD-Leute mögen einfach die GPL nicht. |
||
Anmeldungsdatum: Beiträge: 3412 |
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 |
||
Anmeldungsdatum: Beiträge: 960 Wohnort: Halle (Saale) |
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. Du hast Recht, es muss nicht auf allen OS immer ein neues init-System verwendet werden. Das wollte ich damit auch nicht sagen. |
||
Anmeldungsdatum: Beiträge: 5072 Wohnort: Brandenburg an der Havel |
Das halte ich in der Praxis eigentlich eher für weniger wichtig. Schwerwiegendere Nachteile von SysV Init sind meiner Meinung nach:
|
||
Anmeldungsdatum: Beiträge: 1875 |
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? |
||
Anmeldungsdatum: Beiträge: 11179 Wohnort: München |
Das ist doch genau der Sinn eines guten Start-Systems.
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/
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... |
||
Anmeldungsdatum: Beiträge: 1875 |
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! |
||
Anmeldungsdatum: Beiträge: 1875 |
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. |
||
Anmeldungsdatum: Beiträge: 1603 Wohnort: Fernwald (Gießen) |
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. |
||
Anmeldungsdatum: Beiträge: 1875 |
Schon, aber die fstab ist da nicht wirklich nötig, sondern optional. |
||
Anmeldungsdatum: Beiträge: 4101 |
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 |
||
Anmeldungsdatum: Beiträge: 1875 |
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. |
||
Anmeldungsdatum: Beiträge: Zähle... |
|
||
Anmeldungsdatum: Beiträge: 1449 Wohnort: Waterkant |
Na, wenn wir den Thread schon ausbuddeln, dann richtig. 😉
Update: Ab Version 208 verfügbar (Abschnitt remote-fs.target).
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.
Dann sollte ein
helfen. Mehr zu dem Thema "systemd und Swap-Partitionen" weiß das Handbuch. Gruß |