[geteilt] Die Pflegebedürftigkeit von Arch Linux

[Coburg-M]

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

[Commodore-Freak]

(11.09.2013 14:04)oreissig schrieb:  

(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.

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.

oreissig schrieb: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.

Coburg-M schrieb: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.

[oreissig]

(11.09.2013 14:19)Commodore-Freak schrieb:  Ob das wirklich so unmöglich ist automatisiert config-files zu mergen weiß ich gar nicht.

Das kommt darauf an.
Bei logiklosen Konfigurationen geht das sicherlich, da wäre es auch total trivial sowas zu machen, denn Code um mit den entsprechenden Files umzugehen gibt es ja, nämlich in den Programmen, die konfiguriert werden. Da einen Migrationspfad zu schreiben wär kein Hexenwerk.
Bei Konfigurationsskripten kanns theoretisch beliebig komplex werden, das wird man vermutlich nicht hinkriegen.

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

Ich seh den Konflikt nicht. Nur weil ich nicht alles selber machen muss heißt das doch nicht, dass ich nicht händisch eingreifen kann an den Stellen, wo ich das will (und nicht allen, an den ichs muss).
Arch ist doch nicht deswegen flexibel, weil du repetitiv die selben Sachen machst, die alle anderen, die das Paket auch installiert haben, auch machen müssen.

[gandro]

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.

[oreissig]

(11.09.2013 14:40)gandro schrieb:  Motivation dahinter ist es den Aufwand für die Entwickler zu minimieren.

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. Wenn man das nur einmal machen müsste (und das dann idealerweise auch direkt vom Entwickler gemacht werden würde), hätten die Distributoren mehr Zeit für spannendere Sachen, aber das geht natürlich nicht, weil die Landschaft dafür zu vielfältig ist.

[gandro]

(11.09.2013 14:52)oreissig schrieb:  

(11.09.2013 14:40)gandro schrieb:  Motivation dahinter ist es den Aufwand für die Entwickler zu minimieren.

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.

[thosch97]

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