Interessanterweise geht es ja momentan an einigen Fronten in eine andere Richtung als man es bei Linux mit den Paketverwaltungen gewohnt ist.
Snappy Ubuntu Core wurde hier schon erwähnt, gleiches gilt auch für Ubuntu auf den Handys (Ubuntu Touch, Phone, wie auch immer es jetzt heißt): Apps kommen in Form von Click Packages, die nur genau eine Abhängigkeit haben, nämlich zu einem Grundsystem/-framework, das aus einer Sammlung von Bibliotheken besteht. Werden darüber hinaus andere Bibliotheken benötigt, sind diese statisch zu linken oder in der Click Package als private Kopie einzufügen. Für Sicherheitsupdates dieser Bibliotheken ist dann der App-Autor zuständig, dafür gibt es weniger Inkompatibilitäten. Ein ähnlicher Ansatz wurde vor einigen Monaten als Vision von Lennart Poettering vorgestellt, im Zusammenhang mit stateless systems und BTRFS.
Ein hier angesprochener theoretischer Vorteil von "aufgesplitteten" Paketen, dass bei einem OpenTTD-Update das Paket mit den Grafikdaten nicht erneut heruntergeladen werden muss, kann bei üblichen Paketerstellung leider nicht so wirklich ausgespielt werden. Da alle OpenTTD-Pakete aus einem gemeinsamen Quellpaket gebaut werden, besitzen auch alle OpenTTD-Pakete die gleiche Versionsnummer. Ändert man eine Zeile Code, muss die Nummer des Quellpakets erhöht werden. Dadurch erhöht sich auch die Nummer der deb-Pakete, und es werden sowohl die ausführbaren Dateien als auch die Grafikdaten erneut heruntergeladen, auch wenn sich nur ein kleiner Teil einer ausführbaren Datei geändert hat. Ist natürlich nur ein praktisches Problem, das lösbar wäre, wenn man es wollte.
Trotzdem hat die Unterteilung den Sinn, dass auf den Mirrors Platz gespart wird. Der Kern von OpenTTD existiert in einer eigenen Version für i386, amd64, armhf, mipsel, … – das Paket mit den Grafikdateien muss jedoch nur ein Mal vorgehalten und auch nur einmal gebaut werden, da dieses für jede Architektur gleich ist.
Bei anderen Paketen findet die Unterteilung auch oft statt, damit man als Nutzer nicht alle Dateien auf der Platte haben muss. Boost (C++-Bibliothek) ist ein sehr gutes Beispiel, das war bei Arch früher immer ein riesiges Paket (ich glaube einige hundert MB), weil alle Header installiert wurden, auch wenn man als Anwender nur eine kleine .so-Datei von einigen KB gebraucht hätte. Inzwischen haben die das auch aufgesplittet, aber ich glaub nur in 2 Pakete (headers für die Entwickler und der Rest für alle Anwender oder so). In Debian/Ubuntu ist die Unterteilung aber noch deutlich feiner, so hat man wirklich fast nur die Teile auf der Platte, die das System aktuell auch braucht.
Natürlich kann man es mit der Unterteilung auch übertreiben, keine Frage.
Noch zum OT:
Damit ist systemd verdammt mächtig
cool! Endlich ist der ganze Unterbau des Systems aus einem Guss, und man muss sich nicht für jede Kleinigkeit mit andersartigen Manpages, Configs und Konzepten auseinandersetzen. Ein relativ einheitliches Bedienkonzept hat viele Vorteile. Noch besser, wenn es bald in fast allen Linux-Distros gleich gehandhabt werden kann.
und damit gefährlich
… ? Okay. Ist ja jetzt nicht so, dass systemd ein closed-source-BLOB ist. Was daran gefährlich sein soll, verstehe ich nicht. Die Entwicklung liegt in der Hand von sehr vielen Mitwirkenden vieler Distributionen, das wird nicht nur im Hinterzimmer von Red Hat entwickelt. Es ist ein Gemeinschaftsprojekt. Linux (also der Kernel) ist ja auch verdammt mächtig, aber nicht "gefährlich" für uns.
So waren die Programme übersichtlich und weniger Fehlerträchtig.
Das Zusammenwirken der Programme allerdings schon. InitScript-Debugging, CronJob-anflehen und /var/log verzweifelt durchgreppen macht nicht so viel Spaß wie die "alles aus einer Hand"-Lösung von systemd.
Man sieht es schon heute systemd meldet seit Jahren, glaube 1,5 Jahre, div. Fehler
So schlimm kann der ja wirklich nicht sein. Habe systemd bestimmt schon 1,5 Jahre am Start mit Arch (Hauptrechner aber noch mit Ubuntu 14.04 und damit upstart) – einziges Problem, das ich wahrgenommen habe: Einige Monate war die Bash completion von systemctl kaputt und Arch wollte den Patch dafür nicht einspielen. Gibt schlimmeres, und bei Ubuntu wäre das sicher nicht passiert. [Edit: Und ich erledige die Netzwerkeinrichtung über systemd-networkd, habe eigens erstellte unit files, nutze ausschließlich journalctl für das syslog, die Zeit wird per systemd-timesyncd synchronisiert, und statt per cronjob werden meine eigenen service units regelmäßig per timer unit aktiviert. Auch die Boot-Analyse-Funktionen von systemd habe ich schon genutzt. Das ist jetzt sicher nur ein Bruchteil der systemd-Funktionen, aber ich gehe davon aus, dass ich solche Dinge intensiver nutze als der durchschnittliche Ubuntu-User, und trotzdem keinerlei Probleme habe, jedenfalls viel weniger als damals mit den klassischen Werkzeugen.]
