RadioTux

Sehr gute Folge, vielen Dank!

SystemD löst meiner Meinung nach leider nicht das Problem von Abhängigkeiten, was ja gerade die besondere Stärke von Linux (und Unix) ist. Die Hauptarbeit einer Distribution liegt meiner Meinung nach nicht darin, Programme zusammenzustellen, sondern die Abängigkeiten so aufzulösen, dass nur eine Version einer Bibliothek vorhanden sein muss.

Wenn mehrere Versionen unterstützt werden, sind wir wieder bei der DLL-Hell von Windows oder benutzen statisch übersetzte Programme. Beide Varianten führen dazu, dass Unix und Linux einen Grossteil ihrer Eleganz verlieren.

Nein auf Mikrocontroller soll nicht automatisch die gleiche Software laufen wie auf dem Desktop. Es kann aber. Ein Image das nicht nur einen sondern mehrere Mikrocontroller dank des Image Konzepts und btrfs subvolumes unterstützt ist dann die Idee. Ein Image kann so ARM libs und MIPS libs mitbringen und je nach Plattform, das richtige booten.

Hauptzweck ist aber erst einmal der Desktop und nicht minimale Mikrocontrollersysteme.

@Leszek

Wenn ich die Bibliothek in unterschiedlichen Versionen zwei Mal auf dem Rechner und - fast noch spannender - zwei Mal im Speicher habe, dann nutzt mir weder Deduplikation noch eine andere Massnahme, da die beiden ja unterschiedlich sind.

Das Konzept von Shared Libraries ist ja gerade deswegen so toll, weil ich nur eine Bibliothek im Speicher halten muss, die mehrere Programme brauchen können (Nachteil ist, dass ich den Speicherverbrauch eines Programmes nur sehr ungenau bestimmen kann).

Dedup funktioniert nur dort, wo mehrere Programme die gleichen Bilbliotheken einsetzen.

So ein Fall wie Heartbleed führt im schlimmsten Fall sogar dazu, dass ich alle verschiedenen Inkarnationen von OpenSSL patchen muss und nicht nur eine, die systemweit eingesetzt wird.

(Das Threading der Kommentare funktioniert nicht mehr, ist das gewollt?).

Leszek, dass es geht, steht für mich völlig ausser Frage und ich finde den Ansatz auch gut, Linux einmal ganzeheitlich anzuschauen und alle Möglichkeiten auszuschöpfen, inklusive Kernel, SystemD, Filesystem und Volumemanager. Ich bin mir nur nicht sicher, wie viel Performance das frisst (BTRFS ist noch ziemlich am Anfang und auch ZFS war am Anfang noch nahezu unbenutzbar).

Bezüglich Steam gebe ich Dir Recht. Kommerzielle Hersteller gehen diesen Weg, um nicht für jede Distribution ein eigenes Paket zu schnüren.

Ich bin in jedem Fall gespannt, was die Entwicklung bringen wird.

@Dirk; Eine DLL Hölle sehe ich nicht. Da die Programme ja gekapselt sind ist das dann wie bei Mac OS dass jedes Programm seine eigenen Teilwelt hat und nicht auf ein gemeinsames Verzeichnis zugreift in dem unterschiedliche DLLs mit Versionen rumliegen um die sich keiner kümmert. In Zeiten wo Festplatten und RAM groß genug sind ist es auch kein Problem wenn Daten doppelt vorhanden sind. Problematisch ist natürlich dass dann verschiedene Libs mit unterschiedlichen Sicherheitslücken rumliegen um die sich keine zentrale Instanz kümmert. Das ist bei jetzigen Distros natürlich viel besser.

PS: Keine Ahnung warum das mit dem Einrücken der Kommentare nicht geht.

Ich kenne mich nicht so gut mit SystemD und internen Mechanismen von Linux aus. Aber aus der Sicht von einem Linux Fan (auf Hobby-Ebene):

Linux fehlt Automatismus oder bessere Kompatibilität mit älteren Versionen. Aus meiner Erfahrung: Wenn eine Migration von Ubuntu 10 auf Ubuntu 14 gemacht wird, funktionieren viele Programme nicht mehr, weil "ein Paket xy ist nicht kompatibel mit Ubuntu 14 " oder "In Ubuntu 14 gibt es eine Funktion nicht mehr, in einem Script soll deswegen eine neue Funktion verwendet werden, die ganz anders implementiert ist".

Upgrades, Migration, etc. - immer viel Aufwand, weil alte Pakete mit neuen nicht kompatibel sind und sich Funktionen ständig ändern.