Debian war schon LTS bevor es LTS als Begriff unter Linux gab und Ubuntu hat mit den festen Releasezyklen Maßstäbe gesetzt. Der Wartungszustand der sehr umfangreichen Paketquellen lässt aber zunehmend zu Wünschen übrig. Vielleicht ein Grund für die häufig vorgetragene Ablehnung von LTS?
Ich empfehle eigentlich nur LTS-Distributionen und zwar sowohl für den (semi)professionellen als auch den privaten Einsatz und bin auch der Ansicht, dass die Mehrheit der Linux-Anwender LTS-Distributionen nutzt. Das ist also ein sehr relevantes Thema. Es gibt unterschiedliche LTS-Distributionen, wirklich intensiv nutze ich allerdings nur openSUSE Leap.
Momentan befasse ich mich wegen eines anderen Projekts mit GrapheneOS. Für die Installation gibt es dort eine ziemlich umfassende Anleitung. Folgende Zitate finden sich dort:
Debian and Ubuntu do not have a usable package for fastboot. Their packages for these tools are both broken and many years out-of-date. Follow the instructions below for platforms without a proper package.
The udev rules on Debian and Ubuntu are very out-of-date but the package has the rules needed for Pixel phones since the same USB IDs have been used for many years.
On Debian-based distributions, the
signifypackage and command are an unmaintained mail-related tool for generating mail signatures (not cryptographic signatures). Make sure to installsignify-openbsd.
Das hat nichts mit dem Release-Modell von Debian zu tun, sondern mit dem streckenweise schlechten Zustand der Debian-Paketquellen. Die Versionen sind meist schon vor Beginn des Freezes sehr alt und wurden teilweise jahrelang nicht angefasst. Zum Vergleich kann man die Releasedaten der Android-Tools mit den Versionsständen bei Debian vergleichen. Halbwegs aktuelle Versionen sind mitnichten erst während des Freeze herausgekommen.
Die mit Debian ausgelieferten Versionen von fastboot und adb sind allerdings schon chronisch veraltet. Das könnte man inzwischen zum Markenzeichen von Debian erklären. Vermutlich ist das auch nur für die kleine Gemeinde der Custom ROM Szene ein wirkliches Problem. Andere Sachen wiegen da schwerer. Dazu ist das Paket signify als Beispiel geeignet, da es nahezu funktionslos und laut Debian Entwicklerinformationen als „orphaned and needs a maintainer“ markiert ist. Wohlgemerkt seit 2014.
Das ist jetzt nur zwei Beispiele. Vermutlich fallen den meisten Debian oder Ubuntu (das ja letztlich den Paketbestand und Zustand erbt) Beispiele aus ihren eigenen Nutzungsszenarien ein. Das reicht von Kleinigkeiten bis zu riesigen Problemen. Ein Beispiel für eine Kleinigkeit wäre FeedReader. Das Programm wurde auch in der neuesten Version veraltet ausgeliefert, obwohl seit Mai 2020 eine neue Version bereitsteht. Ein Beispiel für ein deutlich größeres Problem ist Chromium. Debian schleppt hier hartnäckig veraltete Versionen mit zig offenen Sicherheitslücken mit sich rum.
Zur Wahrheit gehört natürlich auch, dass die meisten anderen LTS-Distributionen keine so umfassenden Paketquellen wie Debian haben und Software, die sie – aus welchen Gründen auch immer – nicht warten können, gar nicht erst anbieten. Besagte Android-Tools kann man bei openSUSE Leap oder RHEL nur über Dritt-Repositorien hinzufügen. Chromium hat openSUSE aus der stabilen Variante geschmissen.
Die Frage ist, ob das nicht einfach ehrlicher ist. Was hat der Anwender von >35.000 Paketen, wenn vieles davon unbenutzbar ist.
Debian (und damit zwangsläufig auch Ubuntu und Mint) fehlt ganz offenkundig ein Mechanismus, um die Paketquellen von solchen Altbeständen zu bereinigen. Wenn die zuständigen Maintainer nichts machen, passiert da schlicht nichts. Einzige Ausnahme sind RC-Bugs im Vorfeld eines Releases. Das Kriterium „ist funktions- bzw. sinnlos“ ist nur halt kein RC-Bug. Die Android-Tools funktionieren ja theoretisch: Man braucht nur uralte Android-Versionen und uralte Geräte.
Zum Problem wird so etwas, wenn es den Ruf von LTS-Distributionen insgesamt belastet. Da heißt es dann gerne, die Software ist zu alt oder zu ungepflegt und man solle lieber auf ein Rolling Release setzen. Dabei ist auch Testing oder Sid nicht aktueller, weil das Problem eben nicht im LTS-System liegt, sondern die Qualitätssicherung bei Debian das Problem ist.
Glücklicherweise ist es nicht immer notwendig, jede Software aus dem jeweiligen Repository zu installieren, sondern kann sie beim Entwickler downloaden und nutzen, oder als Flatpak/Snap. Also nicht anders als bei Windows. So z.B. die fastboot/platform tools direkt von Google; aber das weißt du ja, steht auch bei GrapheneOS beschrieben. Mit signify wäre da natürlich immer noch das Problem bei Debian… Graphene-webinstaller funktioniert übrigens ganz hervorragend ohne irgendwas zu installieren. Ändert natürlich nix an den vergammelten Paketen einiger Ditributionen. Ich nutze auch Leap, das ist momentan recht aktuell, und durch die Neuausrichtung und den professionellen Anspruch mache ich da (noch) keine Sorgen.
Nach Überschrift und Einleitung wollte ich erst ein wütendes Kommentar schreiben, weil du mal wieder gegen Linux wetterst.
Leider musste ich am Ende des Artikels akzeptieren, dass die Fakten für dich sprechen. Debian ist halt eine Distribution von Maintainern, die den Maintainern sehr viel Freiheit und gewissermaßen „Macht“ gibt. Leider eben auch die Freiheit schlechte Entscheidungen zu treffen. Debian hat es nie geschafft hier Grenzen zu ziehen und Mechanismen zu etablieren, um die Gemeinschaft und die User vor solchen Fehlentscheidungen zu retten.
Aber ob da ein schlechtes Licht auf LTS insgesamt wirft wag ich doch zu bezweifeln.
Als ich vor gut einem Jahr von Windows auf Linux gewechselt bin, war ich nach verschiedenen Tests bei Debian Buster hängen geblieben. Es hat mich durch sein Konzept uns Stabilität überzeugt. Aber Deine Artikel, nicht nur dieser, haben mich dan schon auch ins Grübeln gebracht. Die schiere Anzahl an Paketen in Form von Masse statt Klasse bringt im Endeffekt wirklich nichts.
Suse hätte mir auch zugesagt, aber da bin ich wohl zu blöd, meinen Multifunktionsdrucker (HP Envy 5540) einzurichten, also Drucker und auch Scanner.
Generell bin auch ein Freund von LTS-Versionen, ich kann dann auch mit älteren Versionen (zB. Libre Office) leben, sofern keine Sicherheitslücken existieren. Aber seit 2014 verwaiste Pakete ist dann schon sehr heftig!
Im Grunde genommen mag ich das Konzept von Debian auch und es spricht nichts gegen Stabilität.
Debian ist nur irgendwie stecken geblieben. Man kann eine LTS heute nicht mehr nach dem Zufallsprinzip bauen. Frei nach dem Motto „Was zu Zeitpunkt x in den Quellen ist wird stabilisiert und fertig“.
Stattdessen müssten sich Debian mal fragen, für welche Software es keinen sinnvollen Support bieten kann, welche Software zu rasante Releasezyklen hat und vielleicht auch mal evaluieren, welche Software seit Jahren ohne Updates mitgeschleppt wird. Es wird sicher noch genug für eine stattliche Distribution übrig bleiben, aber vielleicht eher 25.000 als 35.000 Pakete.
Wie Carl oben richtig kommentierte, passiert das halt nicht, weil Debian seinen Maintainern (sobald man diesen Status mal erreicht hat) sehr viel Macht und Freiheit gibt.
Bei Debian kommt, wie Du ja auch geschrieben hast, auch noch dazu, dass man auch noch versucht, es allen Recht zu machen. Also 7 verschiedene Desktopoberflächen, Funktionen alternativ auch ohne Systemd usw.
Das wird den Aufwand ja nochmals vergrößern. Und wenn man dann noch mitbekommet, wie es z.B. beiUnbuntu um die Pakete im Universe-Repository bestellt ist, kommt man schon ans überlegen, ob der Preis der Stabilität nicht sehr teuer erkauft wird manchmal.
Hallo zusammen,
ich habe mir mals die ADB Version angeschaut bzw. die Android Plattform Tools zwischen Ubuntu 20.04, Manjaro, Debian Bullseye und openSUSE Tumbleweed verglichen:
Manjaro
1.0.41
ubuntu 20.04
1.0.39
debian bullseye
1.0.41
tumbleweed
1.0.41
Aktuell kann ich das geschilderte Problem anhand von ADB nicht nachvollziehen, gleichwohl ich es ähnlich sehe, dass die reine Quantität der verfügbaren Debian Pakete nichts über deren inneren Wert bzw. Qualität aussagt.
@Gerrit: Wie bist Du anhand von ADB auf diese Schlussfolgerung gekommen?
VG
Michl
Du scheinst falsche Versionsangaben zu haben Android-Tools bei openSUSE (d. h. adb und fastboot) liegen in Version 31.0.2 vor. Kann man mit „adb version“ und „fastboot –version“ abfragen. Kommt das bei dir bei Debian und Ubuntu auch?
Ich habe das heute morgen mal verifiziert, schließlich möchte ich keinen Quatsch verbreiten:
Die Android Tools liegen im aktuellen Debian mit Release aus diesem Sommer in der veralteten Version 28.0.2 vor. Wenn ich nicht falsch recherchiert habe, sind das Tools mit einem Veröffentlichungsdatum von August 2018. Selbst unter Berücksichtigung der Debian Releasezyklen hätte man eine der unterschiedlichen 30er-Versionen von 2020 locker mitnehmen können.
Bei ADB hat sich weniger getan, die Version in den Android Tools 28.0.2 scheint 1.0.41 zu sein und damit identisch zu jener Version in den aktuellen Android-Tools. Fastboot ist damit bereits jetzt laut Dokumentation zu alt für GrapheneOS. Das wird sich die nächsten 2-3 Jahre bis zum kommenden Debian naturgemäß nicht mehr verbessern. ADB scheint weniger kritisch zu sein, aber das Problem ist identisch.
Debian installiert die Tools außerdem in komische Pfade (bzw. andere als Fedora, openSUSE & Co), aber das sind Spitzfindigkeiten.
Ich bezog das explizit auf ADB, da die Toolkits, wie Du es auch feststelltest, schwerer vergleichbar sind.
Auch als Debian Nutzer stolpere ich auch manchmal über alte Versionen. Da wird irgendwo ein neues Release einer Software vorgestellt und wenn ich prüfe welches Release ich aus den Debian Quellen habe wundere ich mich welche alte Version man hat. Nun ist ja alt nicht erstmal schlecht. Wenn es kein Sicherheitsrisiko oder Fehler gibt, erstmal okay. Wenn die Software erstmal ihren Dienst tut arbeite ich damit. Wenn aber ich eine aktuelle Version einer Software benötige um mein Handy
anzusprechen die Software aber nicht in den Paketquellen ist aus welchen Günden auch immer stört mich das schon. Oder halt der Webbrowser nur mit Rückstand auf den aktuellen Stand gebracht wird.
Dann installiert man an den Paketquellen vorbei um einen aktuellen und sichern Stand zu haben. Mit all seinen Vor- und Nachteilen. Ich habe auch einige Programme die ich nicht über die Paketquellen installiert habe. Ob nun nicht in den Paketquellen, oder wenn vorhanden zu alt.
Das ist ein Punkt der mich bei Debian stört, es hört sich gut an wenn man über die große Auswahl an Programmen in den Quellen spricht. Aber effektiv halbiert sich die Auswahl weil Alt Bestände mitgeschleppt werden. Sei es weil einfach nicht eine neue Version aufgenommen wird oder es Software gibt die seit Jahren nicht mehr gepflegt worden ist. Man ist bei Debian in vielen sehr rigoros.
Würde Debian gut zu Gesicht stehen wenn man es bei den Inhalten in den Quellen auch ist.
Ich muß aber auch sagen, jeder muß prüfen welche Arbeit er mit welchen Werkzeug er verrichten will. Und wenn es halt mit Debian nicht geht, dann ist das so. Dann muß das Werkzeug nehmen was geht. Wenn das dann halt nicht Debian ist, dann ist das auch so.
Als Belastung für den Ruf von LTS? Es ist halt ein Punkt der Verbesserung würdig ist. So wie wir es bei jeder Distro oder OS was haben was besser geht. Jeder kann sich das suchen was einem am wenigsten Bauchschmerzen bereitet. Ich glaube aber nicht das sich bei Debian kurzfristig hier was ändert.
Und zum Abschluß noch gefragt? Wer hält allen anderen den Spiegel vor und zeigt hier geht es.
Ich finde RHEL und SLE/openSUSE Leap machen es besser. Kleinere aber gepflegte Paketauswahl und die Bereitschaft nach vorheriger intensiver QS auch mal eine neue Version in das stabile Release zu schieben, anstelle dogmatisch an Positionen wie „Stabilität von Versionen“ festzuhalten. Bei openSUSE dann noch ergänzt durch ein echtes RR.
OpenSUSE als Projekt zeigt auch was man besser machen kann. Intensive Arbeit an Tools wie OBS und openQA haben den Aufwand für die Paketierung deutlich gesenkt. Das gilt ebenso für das Red Hat-Ökosystem. Fedora hat viel weniger Entwickler als Debian und liefert eine höhere Schlagzahl. Natürlich hat Fedora andere Ziele, aber dass Debian hunderte Maintainer braucht, um die Qualität zu halten, hat etwas mit den Werkzeugen zu tun. Debian arbeitet hier mit Steinzeit-Technik. Aber die Debian-Entwickler liefern sich ja auch lieber ideologische Grabenkämpfe. Gerade heute gelesen: https://linuxnews.de/2021/10/debians-diskussion-ueber-which/
MIt RHEL hatte ich noch gar nichts am Hut. Suse habe ich zwar in einer VM getestet, bin aber nicht so richtig warm geworden. Bisher ist auch nicht der nötige Leidensdruck bei mir von Debian zu wechseln. Fedora habe ich immer mal im Auge, aber ehrlich. Auch da
habe ich nicht den nötigen Leidensdruck mich damit mehr zu beschäftigen. Bei der Debian Diskussion über which ist mein erster Impuls, ja muß diskutiert werden, aber wenn mit dem Aufwand schon bei which diskutiert wird weiß man warum Debian ist wie ist. Hier wird viel Zeit verschenkt für wenig Ertrag. Wenn es regnet diskutiert man nicht ob ich einen Blauen oder Roten Regenschirm benutzte um nicht nass zu werden, da nehme einen und gut. Je länger ich diskutierer je nasser werde ich. Und irgendwann es ist egal, dann bin ich nass. Dann auch egal. Ich sehe aber bei Debian das man in die Köpfe der Personen rein muß um eine Änderung zu erzielen. Werkzeuge und oder Steinzeittechnik mag ein Hinderungsgrund sein, aber wenn Mensch nicht will kommst du auch mit dem besten Werkzeug nicht weiter. Aber wie du auch geschrieben hast wenn Maintainer nicht will dann passiert nichts. Und Debian ist von seinen Weg überzeugt.
Und ja ich bin mit Debian zufrieden. Auch wenn ich Firefix und Thunderbird zb. nicht aus den Debian Quelle nutze.
Dass es in einem Open-Source-Projekt zu wenig ehrenamtliches Engagement gibt, gilt wohl für so ziemlich jedes und ist nichts wirklich Neues. Hat auch mit dem Konzept der langen Releasezyklen wenig zu tun. Man kann über Debian in einem Blogpost herziehen oder einfach hingehen und sich einem nicht gewarteten Paket annehmen und es aktualisieren oder alternativ jemanden dafür zu bezahlen.
Dein Totschlagargument (sorry, aber das ist es) verfängt nicht, weil man das eben bei Debian nicht kann. Es gibt dort keine Struktur, in der ein Außenstehender in irgendeiner Form ein Paket übernehmen kann. Man hat ja bei Norbert Preining gesehen, was das für ein Affentheater ist. Debian erstickt an seiner Struktur und an Bürokraten, die mehr Zeit in diese Struktur stecken als in die Arbeit an Debian.
Selbst wenn man 100 ehrgeizige Entwickler dazu bewegen könnte auf Teufel komm raus Software für Debian bereitzustellen, verpufft das gerne mal an den Paketbauern (Maintainern), wenn die die Pakete nicht bereitstellen, geht da gar nichts.
Ist leider so. Fedora ist da tatsächlich weitaus vitaler und schlagkräftiger. Immerhin bietet openSUSE Leap Unterstützung für alle Pakete, anders als das z.B. bei Ubuntu der Fall ist. Also ja, ich habe in letzter Zeit auch mehr Blicke auf Leap und Fedora geworfen als die Jahre zuvor.