Boycott Systemd

Status
Für weitere Antworten geschlossen.
-Nuke- schrieb:
"systemd Befehl lernen"? Ich will ja jetzt nicht böse klingen, aber "systemctl start sshd" ist jetzt auch nicht viel anders als "service sshd start" ;)
Zum Vergrößern anklicken....
War ja nur ein Beispiel. Manche Befehle gehen halt in Fleisch und Blut über, die tippt man blind, und wenn man ständig auf unterschiedlichen Systemen arbeiten muss, will man nicht jedesmal nachdenken "was muss ich hier jetzt wieder eingeben?". Wir haben hier in unserem Haushalt ungefähr ein Dutzend Laptops/Netbooks, 2 Desktop-Rechner, 4 Raspberry Pi, 2 Odroid, und einen gemieteten vServer. Da werd ich ja wahnsinning wenn die alle anders zu administrieren sind.
 
Naja, da die Anzahl der Linux-Distributionen ohne systemd eher gering sind, fährst du mit dem Weg "Ich benutze die systemd-Befehle für Linux" sicherlich homogener, als wenn du bei Ubuntu die Upstart Wrapper Skripte nimmst und bei Debian die SysVInit Wrapper usw. ;)
 
-Nuke- schrieb:
Naja, da die Anzahl der Linux-Distributionen ohne systemd eher gering sind, fährst du mit dem Weg "Ich benutze die systemd-Befehle für Linux" sicherlich homogener, als wenn du bei Ubuntu die Upstart Wrapper Skripte nimmst und bei Debian die SysVInit Wrapper usw. ;)
Zum Vergrößern anklicken....
Falls du es noch nicht gemerkt hast, der Titel dieses Threads ist "Boycott systemd" ;) Und genau das tu ich auch. Bei mir läuft alles mit Devuan, außer den Raspberry Pis. 2 davon werden demnächst durch Odroid C2 mit Devuan ersetzt, und die verbleibenden 2 dienen nur zur Steuerung 2er Ladegeräte, da muss ich in der Regel nix dran ändern.
 
Naja, aber scheinbar hast'e ja doch noch Systeme mit systemd, sonst hättest du ja nicht vom verkrüppelten "debian-systemd-networkd" berichten können. ;)

Ich mein klar, du kannst nutzen was du willst. Ich selbst habe FreeBSD, CentOS, Ubuntu, Debian und ArchLinux laufen. Ohne jetzt polemisch klingen zu wollen, hab ich aber auch kein Problem damit mir 5 Befehle zu merken. Nur das eben CentOS, Ubuntu, Debian und ArchLinux halt quasi identisch zu bedienen sind, da sie alle auf systemd laufen, mittlerweile.
 
-Nuke- schrieb:
Naja, aber scheinbar hast'e ja doch noch Systeme mit systemd
Zum Vergrößern anklicken....
Wie gesagt, nur die Pis mit Raspbian. Bis letzte Woche war da überall Raspbian Wheezy drauf (ohne systemd!). Wegen Wechsel meines Internetproviders in der Zweitwohnung, mit Umstellung auf DS-Lite, war ich gezwungen IPv6 zu nutzen. Bei Raspbian Wheezy ist ipv6 per default deaktiviert. Das so zu aktivieren, dass es auch einen boot überlebt, das klappte irgendwie nicht. Deswegen habe ich auf diesem einen Pi das Raspbian Jessie installiert. Das machte aber andere Probleme, indem es sich eine nicht nachvollziehbare IPv6-Adresse erzeugt. Der wird aber jetzt durch einen Odroid C2 ersetzt. Ist schon auf dem Postweg.
 
Ja, würde auch nicht systemd (oder sonst irgendjemanden) dafür die Schuld geben, dass etwas anders funktioniert. Das ist einfach nur unfair. Bei neuen Systemen muss man umlernen. Da kann man höchstens sagen, dass man ein System will, was relativ gleich bleibend ist. Das halte ich für einen validen Standpunkt, auch wenn es nicht meiner ist. Slackware und manch anderes funktioniert ja genau so.

Auch, dass in Debian und dessen Derivaten immer mal Uralt-Software drin ist, ist jetzt nichts, was man systemd anlasten könnte.

Ist ja nicht so als gäbe es keine Probleme die direkt mit systemd (bzw. dessen Tools oder wie man den Anhang nennt) in Zusammenhang zu bringen sind und nicht mit der Unkenntnis der Man Page oder einfach nicht portierter Software zusammenhängt.

Klar, man kann sagen, das systemd zu komplex ist, aber was die ganz grundsätzlichen Dinge, wie start/stop/restart/reload/... betrifft ist das Umelernen für viele Nutzer vom Lernaufwand kleiner, als andere Themen aus dem "Ökosystem". Das soll jetzt natürlich nicht dem widersprechen, dass ich Lernaufwand grundsätzlich für schlecht halte, sondern soll eher die Komplexität einzelner Komponenten als Ziel der Kritik haben, weil ich schon die Meinung vertrete, dass gute Software und gute Systeme die Eigenschaft haben sollten möglichst wenig haben sollte, was ständig im Hinterkopf sein muss oder man immer nachschlagen muss. Admins, DevOps und Co. haben bei jedem ernsthaften Projekt genug davon.

Komplexität entsteht (fast) von alleine. :)

EDIT: Hab Übrigens auch nachdem ich am Desktop endlich wieder mit BSD fahre auch noch, allem voran arbeitsmäßig viel mit systemd zu tun, drum weiß ich auch, dass vieles was da oft an systemd kritisiert wird Humbug bzw. Inkompetenz des Admins ist.

Wie erwähnt, soll nicht heißen, dass systemd ein super System ist. Man kann ja in einer Diktatur (nur mal als Beispiel für was, womit sich die meisten hier wohl nicht anfreunden können) nicht beschweren, dass es Kriminalität, Krankheit oder Stau auf den Straßen gibt. Heißt nicht, dass es deshalb nicht bessere Modelle gibt. Und ich hab jetzt absichtlich was politisches genommen, weil "gutes/schlechtes X", also "gutes/schlechtes Init-System" schon ziemlich ins Philosophische abgleitet, weil es sehr stark vom Anwendungsfall, von Unternehmens- und Arbeitsstrukturen, von Leute, von Technik, etc. abhängt.

Die Behauptung, dass systemd für niemanden gut funktioniert oder sinnvoll ist, ist genauso falsch, wie dass sie für alles perfekt. Ist auch bei keiner Programmiersprache so. Trotzdem versuchen alle einen Konsens zu finden, was so im Großen und Ganzen Sinn macht und da bin ich halt der Meinung, dass systemd im Großen und Ganzen gegenüber Manchen anderen Systemen für die meisten Anwendungsfälle eher schlecht abschneidet. Und ich glaube halt, dass viele Leute praktisch nur init.d, wie es meist unter Linux verwendet wird als Alternative sehen und Entscheidungen da eher auf Hype und vielleicht auf Politik passiert sind, als nach Maßstäben, die eher zu sinnvollen Entscheidungen führen.

Und dann gibt's da noch ganz untechnische Aspekte, rund um die Kritik daran, wie das Projekt gemanaged wird (wurde?), an dem sich viele, wie ich meine aus guten Grund stoßen. Das verstehen auch viele Leute, die systemd als die paradiesische Zukunft sehen so.
 
Zuletzt bearbeitet:
Hallo,

um richtig "fair" über systemd motzen zu können, braucht es also am besten eine aktuell gehaltene Arch-Installation :D

Ich werde mir wohl mal ein Antergos neben FreeBSD auf meinem Notebook installieren (es kann trotz Pros und Contras zu den jeweiligen Systemen sicher auch einem FreeBSD-Nutzer nicht schaden, bei GNU/Linux auf dem Laufenden zu bleiben).

Viele Grüße,
Holger
 
Außerdem musst du noch schnell ein laufendes Bügeleisen anfassen, sonst kannst du beim Thema Verbrennungen gar nicht sinnvoll mitreden.
 
CrimsonKing schrieb:
Außerdem musst du noch schnell ein laufendes Bügeleisen anfassen, sonst kannst du beim Thema Verbrennungen gar nicht sinnvoll mitreden.
Zum Vergrößern anklicken....

Sorry, Dein Vergleich lässt mich zwar schmunzeln, er hat aber eine andere logische Struktur, bezogen auf meinen Satz zu systemd würde ich in puncto Bügeleisen sagen: Um sich über Bügeleisen auszulassen, sollte man sich schon mit Bügeleisen befasst haben, sei es theoretisch und/oder praktisch.

Davon abgesehen finde ich es etwas eigentümlich, wenn an systemd Sachen kritisiert werden, die sich als "distributionsgemacht" heraus stellen. Das ist ähnlich ungereimt, wie bei Unzulänglichkeiten eines FreeBSD-Derivats, die es beim Original nicht gibt, dann auf den qualitativen Zustand von FreeBSD zu schließen.

Ist nicht böse gemeint, peace, please :)

Viele Grüße,
Holger
 
Scheint aber nun nicht gerade ein generelles Problem zu sein, da es bei mir auf 3 PCs funktioniert. Aber ist natürlich unschön, wenn FireFox jetzt pulseaudio zwingend voraussetzt. Aber gut, FireFox hat noch ganz andere Sorgen...
 
fefe benutzt Adobe Flash? :eek:

Nun weiß ich nicht mehr, was ich schlimmer finden soll, systemd, pulsaudio, oder fefe als Adobe Flash Fan? *Helau*
 
Nur damit ich mal nicht dumm sterbe, geht die folgende evtl. überspitzte Behauptung an der Realität vorbei oder nicht.

Systemd is ein großer Batzen Code, der viel macht und sich auf diverse interne und externe Abhängigkeiten stützt, die sich je nach Mondphase etc. auch ändern. Früher wie ich noch Systeme administriert habe, war das schöne an Unix (und den Shellscripten zum Initialisieren), daß
a) klar definiert war, was welches Script macht
b) das Ganze mehr oder weniger sauber granuliert war
c) ein Top-Down Entwurf gemacht wurde
d) sich man zur Not entlang der Skripte durchhangeln konnte, um Problemsituationen freizulegen
Systemd ist also das Gegenteil von einem sauberen Microkernel Entwurf

Serie300
 
Naja, systemd ist näher an der Funktionsweise eines Microkernels als die alten Init-Systeme. Ein Microkernel ist ein System was auf einem minimalen Kernel aufbaut, welcher seine Dienste (Treiber, Anwendungen und Co.) überwacht und im Fehlerfall oder Deadlock neu starten kann. Das kann systemd leisten.

Die alten Init-Systeme sind Fire&Forget Systeme. Das Skript wird ausgeführt und dann ist hinterher das Programm gestartet oder nicht. Das Init-System kann von sich aus nicht sagen ob ein Dienst noch läuft oder nicht. Genauso gut kann es diese auch nicht überwachen. Diese Funktionsweise entspricht eher einem System wie DOS.
 
Ich bin kürzlich über sndio gestolpert (es einfach in den Optionen des FreeBSD Ports von Firefox gesehen). Ein weiteres Teil von OpenBSD, das ich super finde. :)

Finde, dass Cantrill die Probleme so richtig auf den Punkt bringt, auch wenn ich ihn jetzt nicht für objektiv halte, auch wenn das Setting jetzt nicht eines ist, wo er so tun würde, als ob er vollkommen objektiv spricht.

EDIT: Zu Microkernels.. Man mag von Mikrokernels halten was man will, aber ich glaube, dass viele Leute die hinter Mikrokernel entweder im Grabe rotieren, oder in Ohnmacht fallen würden, wenn sie diese These zu hören bekämen. Vielleicht nicht alle, aber so manche.
 
-Nuke- schrieb:
Ein Microkernel ist ein System was auf einem minimalen Kernel aufbaut, welcher seine Dienste (Treiber, Anwendungen und Co.) überwacht und im Fehlerfall oder Deadlock neu starten kann.
Zum Vergrößern anklicken....
Das geht m.E. schon weit über die Idee eines Mikrokernels hinaus. Dessen Aufgaben sind nur Speicher- und Prozessverwaltung, sowie Grundfunktionen zur Synchronisation und Kommunikation, also IPC etc. Alles andere wird darauf aufgebaut. Ein Mikrokernel braucht also auch so etwas wie ein InitSystem das außerhalb des Kernels realisiert wird, wie immer das aussieht. Dazu gehört dann u.A. die Einrichtung eines Filesystems sowie die Überwachung der Prozesse des OS.

Hier mal die Definition von SEL4:
A microkernel therefore does not provide high-level abstractions over the hardware (files, processes, sockets etc) as most modern operating systems such as Linux or Windows do. Instead it provides minimal mechanisms for controlling access to physical address space, interrupts, and processor time. Any higher-level constructs are built on top of the microkernel, using those mechanisms. Such higher-level services inevitably encapsulate policy. Policy-freedom is an important characteristic of a well-designed microkernel.
Zum Vergrößern anklicken....
 
Es ging ja nur um die Prinzipien. Speicherverwaltung wird in der Regel übrigens auch im Userspace gemacht und nicht im Kernel, es verbleiben Scheduling, IPC und Prozessverwaltung. Darum hat so ein "ideeller" Microkernel so seine Problemchen mit asynchronen Sachen, da man dort nicht weiß wie viel Speicher eigentlich gebraucht wird. Wobei das hier ja jeder Microkernel anders macht. So ein MiniX Kernel ist fetter als ein L4.

Anyways, hat weniger mit dem Init-System zu tun. Es ging nur um den Vergleich und ein Microkernel macht mehr als Prozesse in den Raum zu schießen und sie hinterher zu vergessen ;)
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben