Ubuntu "LTS" – und warum man sich die Bedingungen genau durchlesen sollte

[sia]

Hallöchen,

Inspiriert durch diesen Thread mit dem Hinweis auf einen Artikel von Heise.de/ct über den Long Term Support von Ubuntu 16.04 würde ich hier gerne etwas über die Stabilität und den Support von Linux-Distributionen sprechen.

Ich nutze auf Serversystemen gerne Debian, wobei da auch die Softwareversionen selbst mit "LTS" nicht das Gelbe vom Ei sind. Beispielsweise sind dort uralte Versionen von bspw. Web-Libraries wie jQuery und Webanwendungen in den Repositories, die faktisch nicht mehr gepflegt werden. Die Maintainer antworten teilweise nicht auf eMails, der gesamte Build-Prozess von Debian ist wahnsinnig komplex.

Von daher verstehe ich die Stimmen nicht, die Ubuntu und dessen Derivate (Mint) als wahnsinnig schlecht abstempeln, nur weil sie sich nicht um manche Pakete kümmern. Richtig schlecht finde ich aber Mints Strategie, wichtige Kernelupdates zurückzuhalten... das ist bei OpenSuSE und Fedora weitaus besser gelöst, obwohl sie nicht kommerziell unterstützt werden. Da spielt vermutlich auch die Nähe zu SLES/RHEL eine Rolle.

Was haltet ihr davon? Ist das symptomatisch für Debian-basierte Distributionen? Wo liegt die Update-Politik noch im Argen?

 

[mathmos]

Wo liegt die Update-Politik noch im Argen?

Nehmen wir mal an eine Distribution wird 5 Jahre unterstützt. Die eine oder andere Distribution neigt dann dazu innerhalb dieses Zeitraums bestimmte Pakete nicht zu upgraden. Es werden "lediglich" Sicherheitsupdates eingespielt. In so manchem Fall wäre aber ein Upgrade auf eine höhere Version wünschenswert, da dort teilweise unschöne Bugs behoben wurden oder nützliche (oft unkritische) Features hinzukommen.

 

[virtus]

Bei Linux-Distributionen gibt es zwei wesentliche Tendenzen.

Aktuelle Pakete:
Die Distributionen bieten stets aktuelle Pakete. Wenn du immer auf neuste Features angewiesen bist, dann sind das die Distributionen, die du nutzen willst. Dafür sind die Pakete nicht immer ganz ausgereift und teilweise instabil.
Vertreter sind beispielsweise Fedora oder Ubuntu.

Stabile Pakete:
Hier wird ein großer Wert darauf gelegt, dass die zur Verfügung stehenden Pakete stabil und ausgereift sind. Sie bieten häufig eine sehr hohe Zuverlässigkeit, dafür musst du unter Umständen ewig auf neue Features warten. Diese Distributionen eignen sich häufig für den Einsatz als Server, wenn du auf Zuverlässigkeit und Sicherheit angewiesen bist.
Vertreter sind beispielsweise Debian und CentOS

Verschiedene andere Distributionen versuchen einen Mittelweg zwischen stabilen Paketen und aktuellen Paketen zu gehen. Die Wahl für eine Distribution sollte sich also besonders an deinen Anforderungen orientieren.


Wieso lädst du jQuery aus den Paketquellen für dein Betriebssystem?
Installiere dir z.B. npm und verwalte deine Web-Libs darüber.

 

[sia]

Wieso lädst du jQuery aus den Paketquellen für dein Betriebssystem?

Weil sie drin sind

Wenn Debian die Libs nicht aktuell halten kann, sollten sie die doch einfach raus nehmen. Sonst installiert noch einer die veralteten Dinger.

 

[virtus]

Weil es geht ist kein gutes Argument.

 

[sia]

Klar, deswegen nutze ich die auch nicht. Aber wenn man roundcube installiert, ist zwar roundcube in der neusten Version drauf, jQuery macht es aber unbenutzbar.

Natürlich nutze ich Webapps i.d.R. in der neusten Version, aber diese alleine schon auf diese Art und Weise anzubieten grenzt an Fahrlässigkeit.

 

[Abul]

Sehe ich auch so. Ist ja kein Sourcecode von irgend einem Programm das man selbst compilieren müsste um die neuste Version zu haben. Das ist Javascript ffs, das kann man sich auf der Herstellerseite runter laden ... Und andere Programme die diese auf diese Quelle von jQuery zurückgreifen sind auch nicht besser. roundcube? Wieso wird die jquery.js nicht einfach mit in das Paket integriert und liegt dann mit neuster bzw zu dem Zeitpunkt mindestens benötigter Version mit im Programmordner?

 

[theSplit]

Also ich fahre mit meinem Debian ganz gut und ich entwickele darauf auch mehr oder weniger. Aber das was ich brauche kann ich installieren und ist auch aktuell.

Was mich persönlich eher stört, das die ganze Software oder Spiele nur für Ubuntu verfügbar gemacht sind, selbst wenn sie auf Debian auch laufen bzw. laufen würden. So ganz hab ich das noch nicht geblickt.

Aber daher bin ich auch jemand der sich absichtlich und bewußt für die Debian Popularity Contest, also dem zur Verfügung stellen der Information über genutzte Pakete entscheidet. Das ist für mich persönlich das Signal das ich den Maintainer geben kann etwas aktuell zu halten bzw. das etwas auch genutzt wird.

Wo keine Abnehmer, da kein Bedarf. So denke ich dabei.

Und wer bleeding Edge immer und überall braucht, lebt zwar auf dem Turm von Babel, droht aber auch damit unterzugehen. Bleeding Edge ist nicht immer nur gut und schon gar nicht ausgereift oder fertig. Oft bestehen Probleme die spät oder fast gar nicht gefunden werden durch die Entwickler selbst. Oder? - So "stelle ich es mir vor".

[Ironie]Also bisher hab ich mit Debian nichts vermisst. Ich arbeite vielleicht dann auch mit der falschen Software.[/ironie]

 

[virtus]

Was mich persönlich eher stört, das die ganze Software oder Spiele nur für Ubuntu verfügbar gemacht sind, selbst wenn sie auf Debian auch laufen bzw. laufen würden. So ganz hab ich das noch nicht geblickt.

Wo würdest du sie den gerne nutzen?

Viele Linuxdistributionen sind eher für den professionellen Bereich gedacht. Debian, CentOS, RHEL, etc sind nicht zum Spielen gemacht. Die Zielgruppe sind eher Administratoren/ Servernutzung/ Businesscomputing/ Entwicklung/ wissenschaftliche Nutzung.
Andere Distributionen haben nicht ansatzweise die manpower oder die finanziellen Möglichkeiten, um überhaupt an Spiele denken zu können. Da ist man froh, wenn man einigermaßen mit den Entwicklungszyklen der Elterndistribution Schritt halten kann und die Modifikationen des Ablegers einigermaßen hinbekommt. Das betrifft vor allem die kleineren Distributionen.

Ubuntu genießt in der Hinsicht einige Vorteile:
1. freie Basis (Debian)
Hier kann man sich kostenlos bedienen und braucht sich nur selbst noch um den Aufbau zu kümmern.
2. riesige Community
Sowohl hinter Debian als auch hinter Ubuntu stehen riesige Communities, die die Projekte am Leben halten.
3. kommerzielles Unternehmen
Canonical setzt immerhin 65,7 Mio USD im Jahr um, wenn gleich die Ausgaben den Einnahmen überwiegen. Das zeigt, wie aggressiv man sich auf den Markt drängt.
4. Klicki-bunti Ubuntu
Ubuntu ist seit jeher für seine Klicki-bunti Oberfläche bekannt und gerade unter Umsteigern eine beliebte Distribution. Umsteiger sind aber häufig die, die aus der Windows Welt mit ihren ganzen Spielen, kommen und diese auch gerne weiter nutzen wollen.
5. SteamOS
SteamOS ist, wenn ich mich nicht irre, ein Ubuntu-Ableger. Setzt Steam mit SteamOS auf Ubuntu, dann ist die Portierung für Steam-Spiele naheliegend und ein Spiel, das unter SteamOS läuft, läuft mit wenig Aufwand dann auch unter Ubuntu.


Andererseits konnte ich ohne großen Aufwand bereits sehr frühe Linux-Versionen der Steamsoftware unter anderen Linux-Distributionen nutzen.

Natürlich nutze ich Webapps i.d.R. in der neusten Version, aber diese alleine schon auf diese Art und Weise anzubieten grenzt an Fahrlässigkeit.

Nein. Wenn du eine stabile Version von jQuery möchtest, kannst du diese aus den Paketquellen beziehen. Dafür ist sie dort aufgenommen. Wenn du den neusten geilen Scheiß brauchst, dann ist die Version, die über die Paketquellen angeboten wird, nicht die richtige für dich.

Ich muss sagen, dass ich gerade für mein Entwicklungssystem auch ein Up-To-Date-System bevorzuge.
Da kann man sich dann für eine Distribution entscheiden, die prinzipiell immer den neusten Scheiß mitbringt und alle 3 Tage ein neues Release bringt oder man nimmt eine defensivere Distribution und baut die Software, die nicht mehr aktuell genug ist, dann eben selbst. Das schöne ist ja, dass man sich nicht nur aus den Paketquellen bedienen kann, sondern auch Source-Files vom Entwickler laden und bauen kann.

Logischer Weise ist letzteres mehr Aufwand, wobei

[src=bash]
wget <application>
tar xvzf <application.tar.gz>
cd <application>/
./configure
make
sudo checkinstall[/src]

auch nicht die Welt und in vielen Fällen schon die Lösung ist.

 

[sia]

@virtus: in der Webwelt braucht man aber meistens den "neusten Scheiß", bspw. weil Sicherheitsfixes nicht zurück portiert werden. Willst du ein monatealtes WordPress wirklich nutzen?

Abgesehen davon dass die Softwareversionen nicht mal zusammenpassen. So hängt wie erwähnt Roundcube von jQuery ab, da die angebotene Version von jQ aber zu alt ist, können Mails nicht versendet werden.

Die Pakete sind auch nicht absichtlich "stabil", sondern einfach unmaintained.

 

[ynbl]

@virtus: Das Problem mit der selbstkompilierten Variante ist aber, dass du, wenn du nicht wirklich gruendlich arbeitest, in wenigen Monaten ein System voller verschiedener Libraries und Dependencies, die neben der Paketverwaltung herlaufen. Dependency Hell, ole!

 

[virtus]

@virtus: in der Webwelt braucht man aber meistens den "neusten Scheiß"

Quatsch, in den meisten Bereichen ist es vollkommen egal, welche Softwareversion du nutzt. Klar Security-Fixes sind natürlich wichtig, aber bes kommt nicht wirklich darauf an, ob du die Libre Office 5.0.2, 5.0.5 oder 5.1.1 nutzt spielt z.B. keine Rolle. Nur weil in deinem Repository eine 5.x.y liegt, heißt das auch nicht unbedingt, dass dort nicht die neusten Security-Updates vorhanden sind.

Willst du ein monatealtes WordPress wirklich nutzen?

Das kommt u.U. auf die Einsatzzwecke an. Nehmen wir mal ein internes Netz, solange die Wordpressversion zuverlässig arbeitet, kannst du sie intern einsetzen. Nur wenn du sie öffentlich betreiben willst oder auf die neusten Editor-Features angewiesen bist, musst du updaten. Wordpress lässt sich auch wunderbar ohne Paketverwaltung installieren und updaten! Es sollte aber ebenfalls kein Problem sein, ein über die Paketverwaltung installiertes Wordpress zu updaten.

Abgesehen davon dass die Softwareversionen nicht mal zusammenpassen. So hängt wie erwähnt Roundcube von jQuery ab, da die angebotene Version von jQ aber zu alt ist, können Mails nicht versendet werden.

Ich sehe gerade das Problem nicht.

Die Pakete sind auch nicht absichtlich "stabil", sondern einfach unmaintained.

Klar, um manuell installierte Pakete musst du dich kümmern. Aber wenn du so dringend immer den neusten Shit brauchst, dann wirst du ja sowieso immer die aktuellste Version fahren.

 

[theSplit]

Wo würdest du sie den gerne nutzen?

Viele Linuxdistributionen sind eher für den professionellen Bereich gedacht. Debian, CentOS, RHEL, etc sind nicht zum Spielen gemacht. Die Zielgruppe sind eher Administratoren/ Servernutzung/ Businesscomputing/ Entwicklung/ wissenschaftliche Nutzung.[...]


Andererseits konnte ich ohne großen Aufwand bereits sehr frühe Linux-Versionen der Steamsoftware unter anderen Linux-Distributionen nutzen.

Sagen wir mal so, es ist nicht die Notwendigkeit alles überallhin portiert haben zu wollen, es wäre halt nur schön wenn es auch für eine größere Distribution wie Debian Pakete von Gog.com/Steam Spielen geben würde. Aber nur noch kurz dazu, wenn man Steam installieren kann, heißt es nicht das man automatisch auch alle Spiele dadurch spielen kann.

Nur ist Debian an sich ja keine "Minor"-Distribution. Auch wenn ich dir recht geben mag, dass diese eigentlich nicht zum spielen gedacht sind. Halt nur nice to have. Aber oft ist wohl zu wenig Druck der User / Marktwert dahinter.

Linux wird aber vermutlich auch da eingesetzt, wo ein "teures" (relativ) Betriebssystem nicht taugen würde. Nicht umsonst gibt es von Google Android und nicht überall nur Windows Phones, würde ich spontan mal einwerfen wollen. Ist natürlich auch der "Geiz" und die "Gier" von Google ein eignenes OS zu vermarkten, aber ich könnte mir vorstellen das die Lizenzen Android auf ein Smartphone zu verwenden doch deutlich unter dem einer Windows-Geräte Lizenz liegen. Vom iOS mal fern ab.


-----------
Auch @ phre4k:
Was heißt "man braucht immer das neuste vom Neusten in der Web-Entwicklung" - würde ich schon anzweifeln, da manch einer noch IE8 im Einsatz hat oder manch ein mobiles Gerät bei einer BrowserVersion "eingefroren" zu sein scheint.

Natürlich macht "neuer" Sinn wenn man die Features benötigt - aber dadurch wird man auch unweigerlich Leute ausschließen die halt nicht das neuste installieren wollen oder schlichtweg gar nicht können. Und was Screenreader oder ähnliches angeht, wenn man auf Seiten kommt wo man ohne Javascript nicht mal wirklich Inhalte sieht, das ist für mich schon schlecht. Auch wenn ich jemand von der Fraktion bin der JS noch aktiviert wenn es nötig ist aber doch eher generell versuche ohne die Services zu nutzen.

 

[sia]

Quatsch, in den meisten Bereichen ist es vollkommen egal, welche Softwareversion du nutzt. Klar Security-Fixes sind natürlich wichtig, aber bes kommt nicht wirklich darauf an, ob du die Libre Office 5.0.2, 5.0.5 oder 5.1.1 nutzt spielt z.B. keine Rolle.

Guck dir noch mal an, was du zitiert hast:

in der Webwelt braucht man aber meistens den "neusten Scheiß"

Ist LibreOffice eine Webapp?

Das kommt u.U. auf die Einsatzzwecke an. Nehmen wir mal ein internes Netz, solange die Wordpressversion zuverlässig arbeitet, kannst du sie intern einsetzen.

Ah, wusste nicht, dass Wordpress auf Debian nur in internen Netzen eingesetzt wird.

Es sollte aber ebenfalls kein Problem sein, ein über die Paketverwaltung installiertes Wordpress zu updaten.

Doch. Schon mal versucht?

Ich sehe gerade das Problem nicht.

Nunja, du installierst eine Webanwendung über die Paketverwaltung und sie funktioniert mit den Libraries nicht, die als Abhängigkeiten definiert sind. Wie kann man da das Problem nicht sehen?


Ich schiebe das einfach mal auf die späte Uhrzeit, sonst redest du nämlich nicht so einen Stuss

 

[virtus]

Deine Entwicklungsumgebungen müssen nicht stets den neusten Scheiß bieten.
Sind wir mal ehrlich, HTML, JavaScript und CSS Standards ändern sich nicht allzu häufig. Da reicht es theoretisch, wenn du deine IDE ein mal im Jahr updatest.
Oder nehmen wir mal apache2, auch hier wirst du in nächster Zeit nicht die mega Neuerungen erwarten. Du wirst kaum jeden Morgen auf den letzten nightly build angewiesen sein. Sollte eine Sicherheitslücke entdeckt werden, wird die Debian-Community erwartungsgemäß zeitnahe einen Patch für die in ihren Repos stehende Version zur Verfügung stellen. Auch dafür braucht es nicht den letzten nightly build, sondern nur irgendeine Version, die von der Community gewartet wird.

Ah, wusste nicht, dass Wordpress auf Debian nur in internen Netzen eingesetzt wird.

phre4k hat die Aussage gelesen: check
phre4k hat die Aussage verstanden: fail
Schade, versuche es bitte erneut.

Doch. Schon mal versucht?

Nein, weil ich wget auf wordpress.com/... machen kann und danach über Wordpress selbst die Updates verwalte. Wieso sollte ich die Debian Paketquellen bemühen?

Nunja, du installierst eine Webanwendung über die Paketverwaltung und sie funktioniert mit den Libraries nicht, die als Abhängigkeiten definiert sind.

Wer hat die Software in die Paketquellen gestellt? Wer hat die Software geschrieben? Bugreport einreichen, Tee trinken und währenddessen die App so installieren, wie es normale Menschen tun.

 

[sia]

phre4k hat die Aussage gelesen: check
phre4k hat die Aussage verstanden: fail
Schade, versuche es bitte erneut.

Erklär mal, wie veraltete (!) Versionen von Wordpress auf Debian irgendeinem nützen.

Nein, weil ich wget auf wordpress.com/... machen kann und danach über Wordpress selbst die Updates verwalte. Wieso sollte ich die Debian Paketquellen bemühen?

Gute Frage! Die habe ich mir ja auch gestellt

Wer hat die Software in die Paketquellen gestellt? Wer hat die Software geschrieben? Bugreport einreichen, Tee trinken und währenddessen die App so installieren, wie es normale Menschen tun.

Das hilft Newbies leider nicht. Debian sollte keine auf absehbare Zeit unsichere Software liefern, fertig. Wordpress und ähnlich "unsichere" Apps zu paketieren, grenzt schon an Fahrlässigkeit. Bugreports einreichen bei Debian ist ein Prozess, der extrem nervig ist. Mache ich trotzdem, kommt aber selten was bei rum.