Starjumper schrieb
Gerry_Ghetto schriebÄpfel-und-Birnenvergleiche noch und nöcher und du wunderst dich, dass es Unterschiede gibt? Wer hätte das gedacht?
Hab ich das wo geschrieben?
Im ersten Beitrag tauchen ein paar Äpfel-Birnen-Vergleiche auf: Desktop- und Serverversionen werden da bunt miteinander vermischt. Du vergleichst auch Rolling-Release mit Stable-Release.
Starjumper schrieb
Gerry_Ghetto schriebWenn man Fremdquellen einbindet und man in der Abhängigkeitshölle landet, dann liegt die Schuld natürlich bei den Distributionen. Ist ja logisch, da kann der Administrator rein gar nichts dafür.
Wenn irgendwelche Anbieter irgendwelcher Softwares explizit bestimmte Repos/rpms/debs für bestimmte Distris zu Verfügung stellen und Anleitungen, sowie explizite Empfehlungen dazu geben, wie man das genau zu installieren hat, der Admin diese genau so umsetzt, dann kann der Admin gar nichts dafür.
Mit deiner Replik zementierst du meine These, dass es nicht die Schuld der Distributionen ist.
Was irgendwelche Anbieter für Software bereitstellen, liegt in der Verantwortung des jeweiligen Anbieters und nicht in der Verantwortung der Distribution oder der Community, die ein Repository der Distribution pflegt. Und seriöse Anbieter engagieren sich üblicherweise in der Pflege des Paketes im offiziellen Repository.
Starjumper schrieb
Das spricht absolut gegen das System, externe Repos einzubinden oder Windowsartig, sich rpms und debs runterzuladen. Rpms und debs zu bauen ist zudem im Vergleich mit Arch echt schmerzhaft umständlich.
Insofern sind die Distributionen doch verantwortlich, in dem Sinne, welche Paketmanagement-Lösung diese nutzen, wie diese teilweise das Paketmanagement outsourcen und wie diese externe Repos/rpms/debs behandeln.
Es spricht eigentlich eher gegen den Admin, da der Admin die Möglichkeiten falsch nutzt.
Das Bauen von rpm- und deb-Paketen ist eher eine Gewohnheitssache denn ein Schmerz. Normalerweise dauert das Bauen länger als das Anpassen der Konfigurationen und Changelogs, wenn man die Tools nutzt und weiss, was man tut.
Was mich mehr "stört" (im Sinne von "nervt), ist der administrative Aufwand, um ein Stable Release Update ins Repository zu bekommen.
Externe Repositories tragen sich meiner Erfahrung nach nie von selbst ein (Debian, Ubuntu, Fedora, Red Hat, Kali, Arch Linux, Oracle Linux, Gentoo). Falls dies doch so sein sollte, dann sagt das meines Erachtens mehr über die Distribution aus, als über das Paketmanagementsystem.
Starjumper schrieb
Gerry_Ghetto schriebInstallationsmedium stürzt ab? Ja, das muss die Schuld der Distribution sein, andere Erklärungen kann es dafür gar nicht geben.
Ja, natürlich ist das so, insofern ein distributionsspezifischer Installer beigeliefert ist. Das ist bei allen genannten der Fall, außer Arch. Genauso es hat Canoncial verbockt, bei Fehler der Installation den Windows Weg zu gehen, also eine maximal nichtssagende Fehlermeldung zu produzieren und die Ursachenermittlung durch einen sofortigen Neustart nach Fehlermeldung zu vereiteln.
Zwischen dem Moment, in dem du ein ISO herunterlädst und dem Moment, in dem der Installationsassistent abschmiert, können tausend Dinge schief gehen. Und bei Ubuntu gibt es ja verschiedene Installationsassistenten: Ubiquity, Subiquity, Calamares...
Ich kenne Calamares ein bisschen und meiner Erfahrung nach werden die Fehler ganz gut abgefangen und geloggt, so dass sich höchstens Calamares beendet. Nach Abschluss der Installation wird das Logfile von Calamares meines Wissens ins installierte System kopiert, so dass es erhalten bleibt. Wird dies nicht gemacht, dann ist die Logdatei infolge fehlender Persistenz prinzipbedingt nach dem Ausschalten weg.
Und es ist nicht immer einfach, eine sinnvolle Fehlermeldung anzuzeigen, wenn der Fehler irgendwo in den Untiefen einer Bibliothek passiert. Da sich Ubuntu unter anderem auch an Anfänger richtet, ist es sowieso fraglich, inwiefern ein unbedarfter Nutzer von "besseren" Fehlermeldungen profitieren würde.
Starjumper schrieb
Gerry_Ghetto schriebUnd "ur- ur - uralte Softwarestände im Repo" ist auch ganz schlimm. Es wundert mich immer wieder, wie Software X in Version Y auch nach Jahren immer noch ohne Funktion Z funktionieren kann, obwohl ich doch Funktion Z gar nicht brauche.
Kann man ja gerne insb. bei Debian haben. Aber seitdem ich Arch nutze, also seit 2007, habe ich wirklich noch NIE erlebt, dass neuere Software-Versionen schlechter als die alten waren. Im Gegenteil, lästige Bugs fliegen bei Arch viel, viel, viel schneller raus, weil nah am Upstream. Bei den anderen muss man meistens Major-Releases warten, wenn übrhaupt was passiert. Ansonsten kann man gleich selbst bauen oder wieder externe Repos nutzen.
Ich weiß ja, dass Admins aus der Debian Ecke gerne behaupten, dass "gereifte" Software besser sei, weil halt ausgereift, man kennt diese, sie sei absturzsicherer und was nicht alles. Seit ich Arch nutze, weiß ich, dass es so per se absolut nicht stimmt.
Wenn zum Beispiel ein 3er oder 4er Kernel auf einer Stable-Release Distribution läuft, heisst das noch lange nicht, dass der Kernel alt ist (und ich bewundere Distributionen, die dies während 10 Jahren tatsächlich auch schaffen Aktualisierungen anzubieten). Auch bei normaler Software heisst das nicht, dass keine Sicherheitsaktualisierungen oder Bugfixes ausgeliefert werden. Aber natürlich gibt es auch Software, die schon in Debian veraltet ist und eigentlich entfernt werden sollte, aber dennoch in die Ubuntu-Repositories gesynct wird und auch dort weiter verwahrlost.
Wenn ich einen Server einrichten muss, dann nehme ich normalerweise eine Version, die zu den bestehenden Servern kompatibel ist. Ich nehme die gleiche Distribution in der gleichen Version wie die anderen. Dann richte ich den Server so ein, dass das, was laufen muss, läuft. Ich muss sehr selten Fremdquellen aktivieren. Es kann aber sein, dass ich optionale Quellen aktivieren muss.
Einmal eingerichtet, ändern sich die Anforderungen an den Server normalerweise über Monate und Jahre hinweg nicht mehr. Da können zwischenzeitlich noch so viele tolle Funktionen in Software X hinzukommen.
Wenn ich dann beispielsweise einen Jenkins Slave offline nehme, ihn aktualisiere und wieder online nehme, dann erwarte ich, dass ich nichts bemerke, also dass alles so weiter läuft, wie vorher: keine Problem mit Jenkins, keine Probleme mit Docker, keine Probleme mit irgendwelchen Zertifikaten/Autentifizierungen.
Ich muss ehrlich sagen, sowas würde ich nicht mit Arch Linux umsetzen wollen.
Ganz anders sieht es bei den Client-Maschinen aus. Da kann ich es verstehen, wenn man gerne aktuellere Versionen benutzt. Aber ich kann es auch verstehen, wenn jemandem beispielsweise Emacs in Version 25 über Jahre hinweg reicht und er nicht unbedingt Version 26.3 braucht.
Vereinfacht kann man sich auch selber fragen: Möchte ich lieber immer neue Bugs haben oder möchte ich lieber über längere Zeit die gleichen Bugs haben? Je nach dem nimmt man dann eben Rolling Release oder nicht.
Übrigens im Falle von LXDE bist du mit Arch Linux vermutlich auch nicht viel aktueller als mit Lubuntu 18.04.