[geteilt] Die Pflegebedürftigkeit von Arch Linux

Zitat von oreissig

Arch will immer gepflegt sein. Einmal hinfrickeln und dann ewig laufen lassen is nich. Mir sind schon 3 VMs, die ich mir irgendwann mal aufgesetzt hab den schleichenden Tod gestorben, weil ich es gewagt habe einfach so pacman -Syu aufzurufen ohne das, was dann kaputtgegangen ist wieder geradezubiegen.

Über die Monate tun sich halt einige Dinge in der Welt der Linux-Software, die bedingen dass man einige Eingriffe vornimmt wenn man solche Neuerungen in ein laufendes System einpflegt. (Prominentestes Beispiel sicher die Umstellung init -> systemd)
Klar könnte man auch bei Systemupdates jeweils Scripts mitliefern, die die entsprechenden Konfigurationsdateien anpassen, aber das ist eben nicht Archs Philosophie. Arch tut nicht ungefragt irgendwas am System, weil es dem User die volle Kontrolle darüber überlassen möchte.
Damit kommt natürlich auch eine gewisse Eigenverantwortung zu gucken, ob man mit einem Update was kaputt macht.

Allerdings findet man ja nicht zufällig raus, dass bei einem Update manuelle Intervention nötig ist, das ist auf der Arch-Homepage immer angekündigt und es wird jeweils sehr detailliert beschrieben, was zu tun ist, was schief gehen kann und wie man mit eventuellen Fehlern umgeht.
Klar ist das ein ziemlicher Mehraufwand, vor jedem Systemupdate auf einer Homepage nachgucken zu müssen ob etwas kaputt geht, aber das ist halt der Preis den man dafür zahlt, dass man sein System öfter neu aufsetzt weil eine Festplatte/SSD stirbt oder ersetzt wird, als weil das System veraltet oder kaputt wäre.

Zitat von oreissig

ich finds kacke, weil der imho paketmanager dafür da sein sollte, mir arbeit abzunehmen und keine arbeit dazuzutun.

Der Paket-Manager tut halt genau das, was er soll: Pakete verwalten.
Wenn die Distribution signifikante Veränderungen am Dateisystem oder am Init-System durchführt, muss halt mehr gemacht werden als Pakete installieren, deshalb hat Pacman da nichts mit zu tun.

Ich weiß nicht ob man den Vergleich mit Windows so ziehen kann, weil Arch halt ein Rolling-Release-System ist, das außerdem Kernel und Userland getrennt hat.
Windows ist halt direkt Kernel+Userland, und es kommt alle paar Jahre ein fest definiertes Update. Sprich es ist immer die selbe Software in der selben Version auf dem Computer installiert, wenn du ein Betriebssystem-Update durchführst, weil eh Kernel und Userland zusammen upgedatet werden und das Userland auch immer gleich aussieht.
Klar vereinfacht das vieles für den User, weil er sich halt keine Gedanken darum machen muss ob irgendwelche Pakete kaputtgehen, wenn sich was grundlegendes an seinem System ändert, aber dafür hast du weniger Flexibilität und Kontrolle über dein System.

Das Argument mit "ich hab doch eh 500GB oder mehr in meinem Laptop" Argument finde ich übrigens nicht eingeschränkt gültig. Grade dadurch, dass vermehrt endlich SSDs verbaut werden, wird der Platz grade für viele Leute eher wieder knapper. Klar ist das im besten Fall nur eine Übergangsphase, aber bis SSDs dann genau so groß sind wie Festplatten wird's schon ein wenig dauern.

Einfachere Verwaltung von Abhängigkeiten könnte man auch mit dem WinSxS-Schema von Windows (bzw. des Container-Schemas von Win8-Apps) hinbekommen – jede Anwendung hat seinen eigenen Satz an DLLs / Libraries, aber alle gleichen Bibliotheken sind auf einen zentralen Speicher hardgelinkt.

Das ist allerdings bei Linux schon partiell dadurch gegeben, dass die Shared Objects den Major-Versionsnamen im Namen tragen, Programme aber meist mit Verweis auf einen Bibliotheksnamen ohne Versionsnummer gelinkt sind, der dann als Symlink auf die einzige installierte Version ausgeführt ist. Vernünftige Paketverwaltung muss erlauben, dass ich z. B. Lua 5.1 und 5.2 parallel installieren und verwalten kann, ohne ersteres zu lua51 umbenennen zu müssen.

Zitat von oreissig

und selbst wenn monumentale umbauten sind, dann soll das teil mir halt sagen "geht nich, musste manuell machen, ich fass hier garnix an" und nich einfach sagen "alles klar, distupgrade is supi gelaufen, jetz nur noch fix neustarten" und dann kommt kernel panic. Das ist nicht die Art Verwaltung, die ich mir wünsche.

Pacman sagt dir nicht "distupgrade ist supi gelaufen, starte neu" sondern einfach nur "hab die Pakete geupdatet, die ich updaten sollte". Zu wissen, ob das System danach noch funktioniert, liegt in der Verantwortung des Benutzers.
Und einfach die Arbeit zu verweigern, weil pacman denkt du wolltest grade was machen, das nicht sinnvoll ist, ist halt nicht the Arch way, weil es Bevormundung wäre. Freiheit über dein System heißt halt auch, die Freiheit dein System kaputt machen zu können.

An richtigen "Kleinscheiß" der manuelle Intervention erfordert kann ich mich grad so nicht erinnern. Die letzten male waren es Dateisystem-Umstrukturierung, nen glibc-Upgrade und der Wechsel auf systemd, soweit ich das in Erinnerung hab.

Der Windows NT Ansatz vor Dateivirtualisierung war das totale Chaos (DLL-Abhängikeitensprobleme und Programme die überall hinschreiben) und die inzwischen eingeführte Dateisystemvirtualisierung ist ja auch nur ein gut funktionierender Hack und kein wohldefiniertes System.

Das klassische Shared-Library-System von Unix glaube ich aber ist in der Tat ein Auslaufmodell, zu schnelle Releasezyklen, zu verschiedene Zielplattformen und trotzdem relativ spezifische Anforderungen an die Abhängigkeiten.

Das App-Container-Konzept von Android/iOS hingegen ist zu isoliert für PC/Server, systemweite Sicherheitsupdates sind in einem unkontrollierten Ökosystem (wie es Windows und Linux sind) nicht umzusetzen.

Bin letztens auf Docker gestossen, und könnte mir vorstellen dass es Zukunft hat: https://www.docker.io/learn_more/
Im Grunde die Dateisystemvirtualisierung von Windows für Shared-Library Programme von Unix mit Ressourcenisolation von Android/iOS - aber trotzdem flexibles Paketmanagement für die Modifikation von Containern. Und speicherplatzeffizient mit Diff-basierten Containern.

Wieso ist Android ned unixartig? Basis ist der Linuxkernel. Paketmanager gibts auch (Google Play) und die Shelk kann man nachinstallieren.

Zitat von oreissig

Der das natürlich total gut kann bei over 9000 installierten Paketen.

Ist ja nicht so, als müsste man für alle 9000 Pakete jetzt gucken, ob was kaputt gehen könnte. Wenn manuelle Intervention irgendwo nötig ist, steht das direkt auf der Arch-Homepage. Klar ist das auch ein Mehraufwand, aber kein so extremer.

Zitat von oreissig

Natürlich will man eigentlich volle Flexibilität ohne händisch config files zu mergen, aber weil letzteres nicht in generisch automatisch durchzuführen ist, gibts halt entweder den Ansatz "Der Paketmanager überschreibt deinen Krams" oder "du musst es selber machen

Ob das wirklich so unmöglich ist automatisiert config-files zu mergen weiß ich gar nicht. Bei der systemd Umstellung wäre zumindest das meiste schon machbar gewesen, einfach kurz die entsprechende Zeile aus der rc.conf rausgreppen und in die entsprechende neue Config-Datei reinschreiben. Syntax zu übersetzen sollte auch kein Ding der Unmöglichkeit sein.
Ich glaube insbesondere bei Arch ist das in erster Linie schon die Philosophie, dass Systempflege dem Benutzer überlassen wird, um ihm die maximale Kontrolle zu geben.

Zitat von Coburg-M

Wieso ist Android ned unixartig? Basis ist der Linuxkernel. Paketmanager gibts auch (Google Play) und die Shelk kann man nachinstallieren.

Unix zeichnet sich ja schon durch mehr als den Kernel und das Vorhandensein eines Paketmanagers sowie eines Terminals aus.
Alleine dass Android erst recht spät Mehrbenutzer-Unterstützung gekriegt hat widerspricht der Natur von Unix komplett, auch Prinzipien wie "everything is a file" sind zumindest nach außen nicht überhaupt nicht erkennbar.

Die Idee hinter Arch ist es das System so simpel und transparent wie möglich zu halten. Motivation dahinter ist es den Aufwand für die Entwickler zu minimieren.

Zuviele Community-basierte Linux-Distributionen leiden unter Entwicklermangel und schwächelnden Eigenentwicklungen, die Arch Entwickler schützen sich davor in dem sie den Verwaltungsaufwand minimal halten. Alles was vom Upstream nicht mehr unterstützt wird, wird halt rausgeworfen (der AMD-Treiber war da mehrmals Opfer von). Was der Upstream nicht unterstützt (z.B. Migrationen) oder korrigiert (Bugs) machen die Arch Maintainer auch nicht.

Wichtigstes Ziel der Distribution ist es für die User eine stabile Zukunft zu bieten. Benutzerfreundlichkeit kommt erst an zweiter Stelle, denn von ersterem haben die User längerfristig mehr.

Nachtrag: Ein netter Nebeneffekt davon ist, dass für mich als Administrator das System ebenfalls relativ gut zu verstehen ist und dass der Schritt vom Administrator zum Maintainer ein sehr kleiner ist und ich selber ohne grossen Aufwand Pakete für Eigengebrauch zusammenstellen kann bzw. selber auch Hand anlegen kann, wo der Upstream oder die Arch-Maintainer sich nicht drum kümmern wollen.

Zitat von oreissig

Das Problem bei dem Distributionsansatz ist eben auch, dass die ganze Arbeit doppelt und dreifach gemacht werden muss, weil eben jede einzelne Distribution ihr eigenes GNU grep für ihre Nutzer wartet und paketiert und alles.

Daran wird sich halt nichts ändern, jedenfalls nicht solange der Leidensdruck nicht hoch genug ist.

Und selbst wenn der Leidensdruck gross genug wird: Die Motivationen hinter den Paketsystemen zu verschieden. Ich kenne die Internals von DEB und RPM nicht im Detail, es sind aber relativ komplexe und mächtige Systeme. Das Format von Arch hingegen ist simpel, so simpel dass ein normaler Linux-Admin mit Bash-Kenntnissen sich selber seine Pakete zusammenbauen oder modifizieren kann, wo die Entwickler keine Zeit für hatten. Das war für mich das Verkaufsargument was mich zu Arch gebracht hat, weil ich meinen Firefox selber packetieren wollte.

Diese Simplizität kostet dafür halt diverse Funktionalitäten, der häufigste Grund warum manuelles Eingreifen beim Updaten nötig ist, ist weil bestimmte Operationen vom Paketmanager aus technischen Gründen nicht unterstützt werden.

Sollten sich RPM und DEB irgendwann auf einen gemeinsamen Paketstandard einigen, der Binärkompatibilität zwischen den Distributionen garantiert, denke ich werden die Archer da mitgehen, weil es den Aufwand reduzieren würde.

Ich muss übrigens grad mal loswerden, ich finde das Paketsystem von Arch unflexibel wie Scheiße. Es gibt das Paket linux, das den aktuellsten Kernel beinhaltet, aber wehe du machst ein upgrade und willst dann mal ein Modul laden. Sind weg. Du hast ein altes Python2-Gedöns und musst ein Paket python2 installieren, und nicht einfach python in der Version 2. Außerdem ist natürlich /usr/bin/python direkt ein Link auf /usr/bin/python3 bzw. es ist direkt python3, für Python 2 muss exziplit python2 aufgerufen werden. Hab ewig gebraucht, bis ich Google Repo am laufen hatte. Benutzerdefinierte Update-Skripte sind unmöglich ($PAKET wird aktualisiert, also ma falls vorhanden /etc/pacman/upgrade-scripts/$PAKET ausführen, praktisches Leidensbeispiel: gummiboot vs. ESP in /boot/efi, oder rEFInd ist auch nicht wirklich besser, da braucht man dann extra Dateiüberwachungszeugs). Gibt noch ein paar andere Punkte, die mir grad nicht einfallen.
Aber gut, über APT oder yum fang ich mich besser garnicht erst an aufregen.
EDIT: Sowas wie Debians update-alternatives oder das Dings bei Gentoo, das fehlt mir eben auch, siehe oben mit python2/3