[geteilt] Die Pflegebedürftigkeit von Arch Linux

[oreissig]

(10.09.2013 22:53)winfreak schrieb:  BTW: Ich bin gewillt, mich durch Dokumentationen zu hangeln und MAL was zu frickeln, nur wenn mir das alles zu fick-fuck wird, dann lass ich's eben und bleibe Win und Mac OS treu. Mir geht's eben um die Entwicklung, und was ich alles verpasst habe - auch Videoschnitttechnisch - wenn das noch genau so schlimm is wie damals, seht ihr mich bald wieder auf Windows. Zumindest als Zweit-OS.

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.

[Commodore-Freak]

(11.09.2013 08:21)oreissig schrieb:  

(10.09.2013 22:53)winfreak schrieb:  BTW: Ich bin gewillt, mich durch Dokumentationen zu hangeln und MAL was zu frickeln, nur wenn mir das alles zu fick-fuck wird, dann lass ich's eben und bleibe Win und Mac OS treu. Mir geht's eben um die Entwicklung, und was ich alles verpasst habe - auch Videoschnitttechnisch - wenn das noch genau so schlimm is wie damals, seht ihr mich bald wieder auf Windows. Zumindest als Zweit-OS.

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.

[oreissig]

(11.09.2013 10:39)Commodore-Freak schrieb:  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.

natürlich, es ist eine bewusste entscheidung, der man sich auch als nutzer bewusst sein will. das soll keine Kritik an den Leuten sein, die sich so entschieden haben.
ich finds kacke, weil der imho paketmanager dafür da sein sollte, mir arbeit abzunehmen und keine arbeit dazuzutun. unter windows muss ich jedenfalls keine configfiles oder registry-foo von hand mergen, weil ansonsten alles um die ohren fliegt. Ehrlichgesagt hab ich alle meiner Linuxe (auch deb-basierte) kaputtbekommen durch installieren trivialer Programme und dann updaten. Insofern bin ich inzwischen zur Ansicht gelangt, dass das Konzept von Software mit Abhängigkeiten inhärent kaputt ist und nicht automatisierbar ohne Userintervention zu bewerkstelligen ist. Unter Android und iOS funktioniert der krams schließlich. Dann bringt halt jedes Programm seine Abhängigkeiten selbst mit und ich hab 10x libsdl auf der Platte liegen, is mir wayne, hab >600gb platz im notebook.

[Commodore-Freak]

(11.09.2013 13:01)oreissig schrieb:  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.

[mrshadowtux]

Wenn man lieber feste Releasezyklen wie bei Windows haben will, kann man ja eine der vielen andern Distris wählen, die kein Rolling Release haben. Zum Beispiel Ubuntu oder Fedora.

[DosAmp]

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.

[oreissig]

(11.09.2013 13:21)Commodore-Freak schrieb:  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 red nich von so monumentalen umbauten wie init=>systemd, ich red von irgendwelchem kleinscheiß.
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.

(11.09.2013 13:21)Commodore-Freak schrieb:  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.

Windows ist nicht Kernel + Userland, denn auch 3rd-Party-Foo gehört zum Userland, und der wird im Gegensatz zum Distributionsansatz nicht von den MS-Leuten bereitgestellt. (Was ich übrigens überaus gut finde. Software gehört von den Leuten verwaltet, die von dem Ding ahnung haben, also tendenziell vom Entwickler. Was dabei rauskommt, wenn irgendwelche Deppen Software frickeln, von der sie keine Ahnung haben kennt man als langjähriger Debianuser hautnah)

Windows ist natürlich insofern nicht vergleichbar, weils keinen Paketmanager hat. Bessere Beispiele sind tatsächlich Android und iOS, die vom Prinzip ähnlich wie Windows sind, aber simple Paketmanager ohne Abhängigkeiten haben, wo sich eine App nur um zwei Sachen kümmern muss: 1. sich selbst und 2. dass es auf der richtigen OS-Revision läuft

(11.09.2013 13:21)Commodore-Freak schrieb:  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.

Für sowas begrenztes wie /usr/local kann man vermutlich auch einfach blocklevel-deduplication mit vertretbarem RAM-Verbrauch fahren. Der Holzhammer löst auch Probleme

EDIT:

(11.09.2013 13:34)mrshadowtux schrieb:  Wenn man lieber feste Releasezyklen wie bei Windows haben will, kann man ja eine der vielen andern Distris wählen, die kein Rolling Release haben. Zum Beispiel Ubuntu oder Fedora.

o.g. beispiel mit distupgrade, reboot, kernelpanic hab ich sowohl auf debian, als auch ubuntu schon erlebt, und zwar ohne dass ich irgendwelchen krass lowleveligen krams geändert hätte. das waren praktisch unveränderte standardinstallationen und nicht mal das kriegen die paketmanager verlässlich hin zu updaten.

[Commodore-Freak]

(11.09.2013 13:35)oreissig schrieb:  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.

[gandro]

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.

[oreissig]

(11.09.2013 13:48)Commodore-Freak schrieb:  Zu wissen, ob das System danach noch funktioniert, liegt in der Verantwortung des Benutzers.

Der das natürlich total gut kann bei over 9000 installierten Paketen. Dass man von der automatisierten auf die manuelle Ebene gehen muss (selber auf die webseite gucken und textuell formulierten Anweisungen folgen) ist ja kein selbstzweck, weil das so übelst viel Spaß macht, sondern weil mans nicht automatisiert machen kann. Das ist genau der Punkt, den ich anspreche. 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". Kacke is beides.

(11.09.2013 13:48)Commodore-Freak schrieb:  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.

Was the Arch way is und was nich is mir eigentlich reichlich wurst, Prinzipien sind nur so gut, wie sie auch praktikabel sind. Ich stelle nur fest, dass ich die bisherigen Paketierungsansätze unter klassischen unixartigen Umgebungen für Kacke halte und ich sehe, dass es auf nichtunixsystemen (inkl. Android) die von mir festgestellten Mängel nicht gibt.

(11.09.2013 13:52)gandro schrieb:  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.

Das Ökosystem bei Linux ist doch kontrolliert, durch den Distributor.
PC-BSD macht es genau so, die PBI-Files sind Pakete, die komplett self-contained sind.