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

[darktrym]

Also wenn ich den Artikel auf wikipedia lese, muss man ja fast weinen für wie blöd Lennart einen hält.
Aber ich will auch nicht hier auf Unix herumreiten, Linux ist angetreten als ein Unix Klon und nun haben sie sich wieder entfernt. Muss ja nicht alles Unix sein.

 

[worldi]

ZFS ist zum Beispiel ein extrem komplexes Stück Software im krassen Widerspruch zur Unix-Philosophie (https://blogs.oracle.com/bonwick/entry/rampant_layering_violation)

Herr Morton scheint mir etwas betriebsblind zu sein. Vermutlich hält er die Verwendung eines Speichercontrollers auch für eine "rampant layer violation". ZFS ist für Festplatten, was ein Speichercontroller für RAM ist: genau die Abstraktionsebene, die man eigentlich haben will (und schon immer haben wollte).

Man will keine block devices. Man will ein flinkes, zuverlässiges Dateisystem mit X Bytes Kapazität! Und RAID-Controller und Volume Manager sind nur Krücken, mit denen man dahin kommt (wenn man könnte, würde man stattdessen einfach eine einzige X Foobyte große, ausfallsichere Platte kaufen).

ZFS ist ein Treiber für Massenspeicher: auf der einen Seite die Hardware mit ihren hässlichen Details, von denen man besser nichts wissen möchte, und auf der anderen Seite eine genormte Schnittstelle. Als Treiber kann es so komplex sein, wie es möchte, ohne jemals der UNIX-Philosophie zu widersprechen.

 

[goblin]

Linux ist angetreten als ein Unix Klon und nun haben sie sich wieder entfernt. Muss ja nicht alles Unix sein.

Genau deswegen bin ich bei FreeBSD gelandet. Ich mag Unix, und wenn Linux kein Unix mehr sein möchte, dann möchte ich es nicht mehr benutzen.

 

[Azazyel]

Systemd setzt auf aktuelle Kernelfeatures und gibt diese dann weiter an Anwendungsprogramme.

Jein; systemd benutzt mehr oder minder aktuelle Linux-Kernelfeatures, hat zu den Anwendungsprogrammen hin aber eine separate Schnittstelle. Vieles davon - systemd ist sehr modular aufgebaut - würde sich meines Eindrucks nach problemlos auch unter BSD nachbilden lassen; bei cgroups habe ich meine Zweifel ob eines brauchbaren Äquivalents unter BSD.

Dies macht das komplette Ökosystem von FLOSS kaputt weil damit jede Portierung bedeutet eine Lösung für Kernelfeatures zu finden.

Was passieren kann: mit systemd sind Features möglich, die sich ohne systemd nur mit viel Aufwand oder gar nicht umsetzen lassen und deswegen nur in Verbindung mit systemd funktionieren - mit entsprechenden Konsequenzen für BSD.

Welche Probleme hat ein modernes Unix?

Ich zitiere mal Debian (Hervorhebung von mir):

Sysvinit was never designed to cope with the dynamic/event-based architecture of the current Linux kernel. The only reason why we still use it today is the cost of a migration.

• Sysvinit/insserv has very little C code, but the real code size must take shell scripts into account. These scripts come in huge numbers, contain bugs and are hard to maintain.
• Debugging an init script is a tedious task. It is much faster to write a working systemd unit file than to debug an existing System V init script.
• Sysvinit is insufficient for desktops, mostly because of missing features such as the D-Bus interfaces. But the real problems arise on big server setups, where Debian is losing ground because of its antiquated init system. On these systems, you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling.

Das gilt für BSD genauso.

In der Liste finde ich "verflucht viele" Features, die Probleme loesen, die es aus meiner Sicht bei einem modernen Unix nicht gibt.

Auf der Liste sind viele Features, die es bei systemd "frei Haus" gibt und die "nice to have" sind.
Ebenso sind dort reichlich Features, die von vielen Leuten schmerzlich vermisst werden.

Was gibt es fuer ein Problem, wenn die Shell ins Booten involviert ist?

Linux läuft auch auf Embedded-Systemen, für die selbst ash zu viel CPU-Zeit und RAM benötigt.

Wo gibt es Probleme mit der gewoehnlichen Art zu mounten oder auto-zu-mounte?

Um nur mal zwei Beispiele zu nennen:
http://www.bsdforen.de/threads/kde4-hald-device-notifier-freebsd-9-x-msdos-kein-automount.28407/
http://serverfault.com/questions/28...mounter-into-little-pieces-and-boil-them-in-o

Welches Problem loest Plymouth?

Es stellt einen grafischen Boot-Prozess samt Interaktionsmöglichkeit zur Verfügung.
Nützlich u.a. für Geräte, die gar keine Tastatur haben (z.B. Passworteingabe für ein verschlüsseltes root-Dateisystem auf einem Smartphone).

Ich denke, den Grund hat Yamagi schon benannt: Wenn immer mehr Programme ohne systemd nicht mehr funktionieren, so waere jeder Distributor, der am Fortbestand seiner Distribution interessiert ist, dumm nicht auch auf den Zug aufzuspringen ...

Du hast recht, auch wenn es mir mit meiner Aussage eher um Anwendungen denn Distributionen ging. Hätte systemd solch einen Anklang gefunden, wenn der status quo zufriedenstellend wäre?

Man will keine block devices.

Das wage ich zu bezweifeln. ZFS bietet nicht umsonst ZVOLs nach außen an (u.a. für iSCSI und Datenbanken äußerst nützlich).

ZFS ist ein Treiber für Massenspeicher: auf der einen Seite die Hardware mit ihren hässlichen Details, von denen man besser nichts wissen möchte, und auf der anderen Seite eine genormte Schnittstelle. Als Treiber kann es so komplex sein, wie es möchte, ohne jemals der UNIX-Philosophie zu widersprechen.

Die Grenzziehung der "hässlichen Details" erscheint mir doch sehr willkürlich - dann hätte ZFS niemals ein Dateisystem, sondern nur block devices zur Verfügung stellen dürfen. Sonst kann man auch das Dateisystem durch eine Datenbank ersetzen und hat immer noch einen "Treiber für Massenspeicher".

Ist es nicht eher so, dass ZFS zwar deutlich komplexer als die traditionelle Kombination von jeweils separatem

• Raid-Manager
• Volume-Manager
• Dateisystem

ist, aber die Vorteile so groß sind, dass wir die Abweichung von der Unix-Philosophie billigend in Kauf nehmen? Zumal man die Komplexität von ZFS - nach den üblichen Kinderkrankheiten - inzwischen zweifelsohne im Griff hat.

 

[peterle]

"... you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling."

Ich bin ja schlicht gestrickt - was genau ist denn damit außerhalb von embedded devices, Telefonen und Kühlschränken gemeint?

 

[darktrym]

KDBUS soll, soweit ich das mitbekommen habe, auch Verwendung in systemd finden. Das wäre dann der nächste Schritt wem cgroups zu altbacken ist.

 

[Athaba]

Was haltet eigentlich von den Reaktionen in der Linux-Welt?

systemd hat zu einem Arch Linux Fork names LSD geführt. In der Gentoo-Welt gab es einen udev-Fork, weil die eher ihr OpenRC behalten wollen, welches übrigens BSD-lizensiert ist und auch auf den BSDs läuft und ständig verbessert wird. Die Leute von Slackware scheinen auch nicht gerade übermäßig begeistert, Debian will nicht, weil es die BSD-basierten Distributionen gibt und viele Arch-Linux-Leute hadern ganz generell damit. Und die Ubuntu-Community ist mit ihrem Upstart ganz zufrieden.

Das ist ja doch einiges an Widerstand. Ich glaube nicht, dass systemd so schnell der einzige Weg sein wird, zumindest nicht solange Debian und Ubuntu es nicht defaultmäßig verwenden.

 

[foxit]

Wenn man sich mal genau anschaut, wer bei dem Debian Projekt für "Upstart" stimmt, kommt man ganz schnell zurück auf den Boden der Tatsachen! Das sind oder waren alles Angestellte von Canonical (Ubuntu). Wie gross ist eigentlich die Anzahl an produktiven Debian-Hurd/kFreeBSD Installationen? Vielleicht 1% gegenüber GNU/Linux(?)! Die Frage ist doch, lohnt sich dieser Aufwand überhaupt dafür? Und der Gentoo Fork von "udev" scheint ja auch niemanden, ausser den Gentoo-Leuten zu interessieren.

 

[darktrym]

Wie war da nochmal die Aussage von Linus: "Portability is for people who cannot write new programs"

 

[peterle]

Wie war da nochmal die Aussage von Linus: "Portability is for people who cannot write new programs"

Das klingt zwar toll, aber es ist schlicht ineffizient das Rad zweimal zu erfinden und mehr Waren zu produzieren, als man eigentlich benötigt, nur weil jeder Seppel seine eigene Zutat in der Suppe möchte. Es widerspricht auch der OpenSource-Idee, die schlicht aus der Portabilität geboren wurde.

 

[grogolz]

Das klingt zwar toll, aber es ist schlicht ineffizient das Rad zweimal zu erfinden und mehr Waren zu produzieren, als man eigentlich benötigt, nur weil jeder Seppel seine eigene Zutat in der Suppe möchte. Es widerspricht auch der OpenSource-Idee, die schlicht aus der Portabilität geboren wurde.

Warum gibt es dann ZFS, das Beste seit der Erfindung des geschnittenen Brotes?

 

[darktrym]

Das ganze Buch besitzt soviele Widersprüche, da fällt der eine hier überhaupt nicht auf.

 

[Azazyel]

"... you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling."

Ich bin ja schlicht gestrickt - was genau ist denn damit außerhalb von embedded devices, Telefonen und Kühlschränken gemeint?

Dafür kann ich nur den 15-minütigen Vortrag eines Unix-Admins mit dem Titel "The Six Stages of systemd" empfehlen. Er geht auf alle obigen Punkte anhand konkreter Beispiele mit PostgreSQL, Apache und anderen Anwendungen aus der Praxis ein (die Beispiele starten bei 4:16). Den Vorspann ist aber dermaßen unterhaltsam, dass ich es auch in voller Länge empfehlen kann.

Parallel gibt's hier im Forum gerade ein Beispiel, warum man auch unter FreeBSD ein ordentliches Servicemanagement bräuchte.

Wie war da nochmal die Aussage von Linus: "Portability is for people who cannot write new programs"

Wenn schon Zitate, dann bitte mit sinnerhaltendem Kontext - Linus hatte das als Scherz gemeint ("with tongue in cheek"):

"Portability is for people who cannot write new programs"

-me, right now (with tongue in cheek)​

The fact is that linux is more portable than minix. What? I hear you
say. It's true - but not in the sense that ast means: I made linux as
conformant to standards as I knew how (without having any POSIX standard
in front of me). Porting things to linux is generally /much/ easier
than porting them to minix.

I agree that portability is a good thing: but only where it actually has
some meaning. There is no idea in trying to make an operating system
overly portable: adhering to a portable API is good enough. The very
/idea/ of an operating system is to use the hardware features, and hide
them behind a layer of high-level calls. That is exactly what linux
does: it just uses a bigger subset of the 386 features than other
kernels seem to do. Of course this makes the kernel proper unportable,
but it also makes for a /much/ simpler design. An acceptable trade-off,
and one that made linux possible in the first place.

 

[darktrym]

Linus hat das durchaus ernst gemeint.

Ich räume ein, dass Portabilität eine feine Sache ist: aber nur, wo sie wirklich Sinn
macht. Es ist wenig sinnvoll, ein Betriebssystem übertrieben portabel zu machen:
Die Einhaltung einer portierbaren API genügt. Der eigentliche Sinn eines
Betriebssystems ist es ja, die Hardware-Eigenschaften zu nutzen und hinter einer
Schicht von High-Level-Aufrufen zu verbergen. Genau das leistet Linux: Es
verwendet einfach eine größere Teilmenge der 386er-Eigenschaften als andere
Kernels es zu tun scheinen. Natürlich führt das dazu, dass der eigentliche Kernel
nicht portiert werden kann, aber dafür resultiert daraus ein wesentlich einfacherer
Entwurf. Das ist ein akzeptabler Kompromiss, der Linux überhaupt erst möglich
machte.
Ich gebe auch zu, dass Linux die Nicht-Portabilität auf die Spitze treibt: Ich habe
meinen 386er im letzten Januar bekommen und Linux unter anderem in Angriff
genommen, um ihn besser kennen zu lernen. Vieles hätte portierbarer sein müssen,
wenn Linux ein echtes Projekt gewesen wäre. Aber ich will nicht übertrieben viele
Entschuldigungen anführen: Es war eine Entwurfsentscheidung, und als ich die
Sache im letzten April begonnen habe, wusste ich noch nicht, dass jemand es
wirklich würde einsetzen wollen. Ich bin glücklich, vermelden zu können, dass ich
mich getäuscht habe, und da mein Quellcode frei zugänglich ist, steht es jedem
frei, ihn zu Portieren, auch wenn das nicht einfach sein dürfte.

Erst programmieren und dann hoffen jemand macht das Ding schon portabel.

 

[goblin]

Parallel gibt's hier im Forum gerade ein Beispiel, warum man auch unter FreeBSD ein ordentliches Servicemanagement bräuchte.

Alter Schwede, damit wurde mal wieder gezeigt, warum ich nicht mehr mit systemd-Apologeten diskutiere.
Wenn ein Prozess nicht auf ein kill reagiert, dann hilft mir systemd genau wie?
Ach, genau, garnicht!

Außer systemd nutzt nicht kill(2) sondern greift direkt auf den Kernel zu. Dann möchte ich aber erst recht nichts damit zu tun haben…

 

[darktrym]

Systemd könnte dir aber helfen, wenn dein Service nach 1h immer abraucht und diesen immer wieder schön neu startet.

 

[Yamagi]

Dann würde ich mir lieber mal den Sourcecode des Daemon anschauen oder mit alternativ den Entwickler zur Brust nehmen. Wenn der Dienst einfach kaputt ist, aus diversen Gründen nicht zu reparieren, aber gleichzeitig notwendig, meinetwegen auch 3 Zeilen sh-Script außen herum fallen lassen. Aber in all den Jahren mit tausenden Maschinen und mindestens genauso vielen unterschiedlichen Diensten war das bei mir nie notwendig, geschweige denn mir sowas wie systemd zur Dienstüberwachung ins System zu dübeln... Ich kann mich bald gar nicht mehr dran erinnern, dass mal was Missionskritisches so abgeschmiert war, dass es Ausfälle gegeben hätte...

 

[Azazyel]

Alter Schwede, damit wurde mal wieder gezeigt, warum ich nicht mehr mit systemd-Apologeten diskutiere.
Wenn ein Prozess nicht auf ein kill reagiert, dann hilft mir systemd genau wie?
Ach, genau, garnicht!

Bleib auf dem Teppich, das habe ich auch nicht behauptet. Ich meinte das hier:

Naja das übliche, er behauptet samba zu stoppen und listet dabei irgendwelche anderen PID's auf.

Gäbe es ein vernünftiges Servicemanagement, wüsste der Admin zumindest auf einen Blick, was Sache ist. Befehle wie systemctl status oder systemctl kill sind doch eine andere Hausnummer als ein Skript, das "behauptet samba zu stoppen und listet dabei irgendwelche anderen PID's auf".

 

[Yamagi]

Und das unterscheidet sich in der Praxis genau wie von

% service samba status
% service samba stop
% service samba forcestop

?

 

[Azazyel]

Und das unterscheidet sich in der Praxis genau wie von

% service samba status
% service samba stop
% service samba forcestop

?

Dadurch wird im Hintergrund immer noch das gleiche Skript aufgerufen wird, das "behauptet samba zu stoppen und listet dabei irgendwelche anderen PID's auf". Hoffen wir mal, die PIDs gehören nicht zu Prozessen, die man eigentlich nicht abschießen wollte...

 

[Yamagi]

Wieso sollten sie zu anderen Prozessen gehören?

 

[peterle]

Dadurch wird im Hintergrund immer noch das gleiche Skript aufgerufen wird, das "behauptet samba zu stoppen und listet dabei irgendwelche anderen PID's auf". Hoffen wir mal, die PIDs gehören nicht zu Prozessen, die man eigentlich nicht abschießen wollte...

Jetzt mal ernsthaft, Samba zu starten und zu stoppen heißt ein Mimöschen gießen, aber das mir irgendwann mal irgendein Script irgendeine falsche PID gekillt hat, daran kann ich mich beim besten Willen nicht erinnern und es spricht auch nichts dafür, daß systemd mir dann auch einfach irgendwas abschießt, was er eigentlich nicht sollte - selbst wenn Poettering über sich hinauswachsen sollte.

 

[lme]

Auf der FOSDEM trug Herr Poettering übrigens das hier: https://twitter.com/freebsdhelp/status/429646331938762753/photo/1

 

[darktrym]

Sind die zufällig verwandt?

 

[FreeBSDuser]

Das Konzept hinter systemd und Konsorten ist vernünftig und steht einfach an. launchd (2005), SMF (2005), upstart (2006), systemd (2010).

Leider wurde systemd mit gewalt gepusht und wurde dargestellt als wären seine features ausgereift, obwohl sie nur Proof-Of-Concept waren.
Jetzt haben wir überall systemd, aber statt die Technical Dept abzutragen und es zu stabilisieren, Dokumentieren und portabel zu machen wird der feature-hype vorangetrieben und es entwickelt sich zu einer OS middleware mit tight coupling.

Jetzt sitzen die Parteien, denen etwas an Stabilität und sauberen Schnittstellen liegt, da und müssen mitziehen oder sie verlieren Support von der meisten OSS.

Was hätte passieren sollen ist, dass RedHat eine InitCon veranstalten hätte sollen, bei der alle Stakeholder sich auf ein deklaratives Kernformat geeinigt hätten. Das wäre dann von 2-3 systemen mit verschiedenen schwerpunkten implementiert worden und alles wäre relativ gut.

Ich glaube die FreeBSD Foundation könnte die Debian situation ausnutzen und klarstellen, dass eine kompatible zweit-implementierung geschaffen werden muss, damit nicht ein Linux Monopol geschaffen wird.
Das würde eine Phase einleiten, in der sich herauskristallisiert welche Teile der neuen init's den großen umbruch der letzten Jahre tragen, und welche einfach nur frickelei sind.