Login
Newsletter
Werbung

Thema: Ubuntu 18.04.4 veröffentlicht

15 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Josef Hahn xh am Sa, 15. Februar 2020 um 12:53 #

Wird https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311 mit dem nächsten LTS gefixt sein? Bisher sieht es kaum danach aus. Falls nicht, rückt die Überlegung immer näher, auf etwas Kommerzielles zu wechseln, wo nicht meine komplette Zeit dabei draufgeht, Workarounds für anderleuts Bugs zu finden (und manchmal leider auch: einfach monatelang abwarten müssen und garnicht weiterkommen).

  • 0
    Von kamome umidori am Sa, 15. Februar 2020 um 21:07 #

    Ubuntu ist doch (gibt es doch) kommerziell!

    0
    Von klopskind am Sa, 15. Februar 2020 um 23:31 #

    Ich würde sagen, dass die Überlegung immer näher rückt oder gar längst überfällig ist,

    a) auf der letzten LTS-Version von Ubuntu zu verbleiben, wo der Fehler nicht auftritt (hier 18.04), solange das nicht gefixt ist, statt vorschnell auf Version 19.10 bzw. 20.04 zu aktualisieren (siehe [0]),

    b) die Distribution zu wechseln (siehe [1]), oder aber

    c) einen der in den Kommentaren des Fehlerberichts dargelegten workaround anzuwenden.


    [0] - Die Veröffentlichungen der XY.10er-Versionszweige Ubuntus werden nur 9 (in Worten: neun) Monate unterstützt. Canonical schreibt dazu:

    Long term support and interim releases

    LTS or ‘Long Term Support’ releases are published every two years in April. LTS releases are the ‘enterprise grade’ releases of Ubuntu and are utilised the most. An estimated 95% of all Ubuntu installations are LTS releases.

    Every six months between LTS versions, Canonical publishes an interim release of Ubuntu, with 19.10 being the latest example. These are production-quality releases and are supported for 9 months, with sufficient time provided for users to update, but these releases do not receive the long-term commitment of LTS releases.

    Interim releases will introduce new capabilities from Canonical and upstream open source projects, they serve as a proving ground for these new capabilities. Many developers run interim releases because they provide newer compilers or access to newer kernels and newer libraries, and they are often used inside rapid devops processes like CI/CD pipelines where the lifespan of an artifact is likely to be less than the support period of the interim release. Interim releases receive full security maintenance for ‘main’ during their lifespan.

    Canonical bezeichnet sie zwar als "production-quality releases" aber auch als "interim release", in welche viele Neuerungen einfließen, und laut Canonical schätzungsweise nur etwa ca. 5% der Installationen aus machen. Diese Veröffentlichungen setzen einen Fokus auf Entwickler, die möglichst neue Bibliotheken, Toolchains und andere Entwicklungswerkzeuge benötigen. Sie sind also auch als wesentlicher Bestandteil des Entwicklungszyklus Ubuntus anzusehen, und daher erwartungsgemäß nicht stabiler/robuster als eine abgehangene LTS-Version.
    Als reiner Desktop-Anwender, der keine spezielleren oder enthusiastischeren Ansprüche hat, gibt es eigentlich keinen guten Grund, auf diese Zwischenveröffentlichungen zu aktualisieren. Es ist jedenfalls nicht zu empfehlen, unter Anderem wegen Fehlern wie diesem. Gut, hinterher ist man immer schlauer. ;)

    [1] - Der Fehler, der in dem Bericht beschrieben wird, ist ja laut Kommentar #23 anscheinend kein Problem von GRUB 2.04 selbst, sondern distributionsspezifisch.

    • 0
      Von Josef Hahn xh am So, 16. Februar 2020 um 11:05 #

      Solange keiner irgendwas weiß, kann jeder behaupten, es sei distributionsspezifisch. Das ist auch ein bisschen die übliche Filterblasenhygiene in der FOSS-Welt. Und wenn's das nicht ist, ist es die GPU schuld, oder die ACPI-Tabellen. :) Ich habe mir das Problem gestern nochmal angesehen, und habe festgestellt, dass mein Grub hier einfach keine Dateien laden kann, die eine gewisse Größe haben; dabei bleibt er einfach hängen, sogar mit 'cat' oder 'sha1sum' auf der Grub-Konsole. Vermutlich ist das wieder so ein Randfall, in den die meisten Leute einfach nicht laufen, oder sich dann im Stillen etwas anderes überlegt haben. Ich weiß es auch nicht, aber ich würde mich ehrlich gesagt wundern, wenn es am Ende wirklich distributionsspezifisch ist. Wie auch immer... Dass die nächste LTS das fixt, sehe ich nach derzeitigem Stand nicht kommen. Es ist wieder so eins dieser 'rare diseases', die man einfach nicht löst. Genau wie meine Freezes (vllt. https://bugzilla.kernel.org/show_bug.cgi?id=196683).

      Ich recherchiere gerade ein bisschen rum, was für und gegen Debian auf dem Desktop spricht. Aber man findet im Netz alles und nichts. Über allem schwebt bekannterweise die Behauptung, die alten Paketversionen in Debian wären sozusagen ein Feature, was zu der großartigen Stabilität führt. Das möchte ich gern glauben. Allerdings frage ich mich immer wenn ich das höre/lese, wie der Mechanismus funktioniert. Nur durch alte Pakete wird ja ein System nicht stabiler. Ich muss noch herausfinden, wie dieser QA-Prozess genau aufgesetzt ist, und ob das für die x-tausend kleinen Desktopprogrämmchen (schwer automatisiert zu testen) plausibel ist, oder nur Träumerei.

      ... und dann sehe ich mit Debian 11, wie sich grub 2.04 dort schlägt. :)

      • 0
        Von kamome umidori am Mo, 17. Februar 2020 um 00:43 #

        > die Behauptung, die alten Paketversionen in Debian wären sozusagen ein Feature, was zu der großartigen Stabilität führt.

        Das liest man oft, aber das „stable“ in der Version bezieht sich zumindest nur auf die Stabilität der Konfiguration – wenn Du so ein System einmal aufgesetzt hast, soll sich durch Updates nichts ändern, also kein Nachkonfigurieren nötig machen … Immer klappt das zwar nicht, aber so einigermaßen schon. Dazu gehört eben auch, dass kaum neue Funktionen nach einer Veröffentlichung dazu kommen.
        Ob es im Idealfall auch bedeutet, dass die Software „gut abgehangen“ ist und nicht nur neue Experimente verschlimmbessert wurde, ist von Fall zu Fall unterschiedlich (und bezweifle ich im allgemeinen).

        0
        Von klopskind am Di, 18. Februar 2020 um 22:32 #

        Solange keiner irgendwas weiß, kann jeder behaupten, es sei distributionsspezifisch. [...]
        Solange keiner irgendwas weiß, kann jeder behaupten, dass es überhaupt ein Problem gäbe...

        Mal ehrlich, gehen Sie an solche Dinge generell mit dieser Einstellung heran, den anderen nicht zu trauen? Eine gesunde Skepsis ist gerade im Netz natürlich immer angebracht, denn sicher sein, kann man sich nie. Aber hier geht es doch um Beitragende zu einem Fehlerbericht im Rahmen einer OSS-Community. Das ist ein Kontext, den man an dieser Stelle nicht außer Acht lassen sollte. Warum sollte dort jemand absichtlich lügen sollen? Wenn es etwaigen ums Trollen ginge, könnte man das an anderer Stelle einfacher haben, z.B. ohne Registrierung oder Vortäuschung technischen Fachwissens auf einem Niveau, sodass das Trollen nicht zu offensichtlich ist.

        Das ist auch ein bisschen die übliche Filterblasenhygiene in der FOSS-Welt. Und wenn's das nicht ist, ist es die GPU schuld, oder die ACPI-Tabellen. :)
        Was Sie hier im konkreten Fall wieder im Subtext unterstellen... Generell mag Ihr Eindruck einen wahren Kern besitzen. Aber hier? Wieso? Wie soll ich das verstehen?

        Oder wollten Sie eigentlich gar keine Ratschläge oder Hilfestellungen als Antwort auf Ihren Kommentar und dem darin geschilderten Problem hören?

        Ich habe mir das Problem gestern nochmal angesehen, und habe festgestellt, dass mein Grub hier einfach keine Dateien laden kann, die eine gewisse Größe haben; dabei bleibt er einfach hängen, sogar mit 'cat' oder 'sha1sum' auf der Grub-Konsole.
        Na das ist doch mal eine sinnvolle Information, die in den Fehlerbericht gehört. Schön, dass Sie eine kurze Fehleranalyse durchgeführt haben und damit einen Beitrag leisten. Jeder wie er kann.

        Vermutlich ist das wieder so ein Randfall, in den die meisten Leute einfach nicht laufen, oder sich dann im Stillen etwas anderes überlegt haben.
        Hm, Vermutungen helfen hier wenig. Der Fehlerbericht und die Kommentare darin stellen doch ein gutes Indiz dafür dar, dass es nicht nur im Stillen geschieht.
        Ein Randfall ist es definitiv: Es ist Linux bzw. GRUB in Version 2.04, es betrifft nur ein vermutlich seltenes Szenario (Loopback größerer(?) ISOs; Welcher Anwendungsfall / welches Problem wird damit gelöst?), und falls es doch distributionsspezifisch ist, betrifft es Ubuntu und wegen GRUB 2.04 nur Ubuntu 19.10 (aufwärts?). Letzteres betrifft nur 5% aller Ubuntuinstallationen laut Canonical, siehe obiger Kommentar. Und Damit dürft es im bereits Promillebereich sein.

        Ich weiß es auch nicht, aber ich würde mich ehrlich gesagt wundern, wenn es am Ende wirklich distributionsspezifisch ist.
        Ich weiß es auch nicht. Aber ich sage es mal so: Bei GRUB würde es mich nicht gerade wundern, wenn es distributionsspezifisch wäre - vor Allem im Zusammenhang mit Kommentar #23.

        Wie auch immer... Dass die nächste LTS das fixt, sehe ich nach derzeitigem Stand nicht kommen. Es ist wieder so eins dieser 'rare diseases', die man einfach nicht löst.
        Das wird sich zeigen. Bis April ist noch ein bisschen. Möglicherweise wird es erst mit 20.04.1 gefixt. Optimal wäre das wahrlich nicht.

        Genau wie meine Freezes (vllt. https://bugzilla.kernel.org/show_bug.cgi?id=196683).
        Ich würde erstmal bei einer Sache bleiben, statt vorschnell abzuschweifen. Ich kann nicht erkennen, dass das zielführend wäre, wobei ich mir noch nicht 100%-ig sicher bin, welches Ziel Sie eigentlich mit dieser Diskussion verfolgen. Von meinen (und auch anderen) Ratschlägen hier scheinen Sie jedenfalls selten etwas zu halten, wie auch in diesem Fall. Aber ich versuche immer von der positivsten Interpretation der Umstände auszugehen, womit ich, falls es mir denn tatsächlich gelingt, bisher ganz gut zurechtgekommen war.

        Ich recherchiere gerade ein bisschen rum, was für und gegen Debian auf dem Desktop spricht. Aber man findet im Netz alles und nichts. Über allem schwebt bekannterweise die Behauptung, die alten Paketversionen in Debian wären sozusagen ein Feature, was zu der großartigen Stabilität führt.
        Tja, ob das "gut" ist, hängt ganz allein von Ihrem Anwendungsfall, Kenntnissen, Konfigurations- und Wartungsbereitschaften ab.

        Debian stable funktioniert für viele. Diesen ist das Bestehen bekannter Probleme das geringere Übel als die Unwissenheit bzw. das Risiko unbekannter Probleme in neuen Versionen. Das hängt auch stark von der konkreten Software-/Paketauswahl und -komposition ab. Andere möchten oder brauchen gar aktuellere Versionen, so z.B. Entwickler. Es hat Vor- & Nachteile. Und was für das eine Szenario ein Vorteil ist, muss nicht aber kann für ein anderes einen Nachteil bedeuten.
        Was für Sie zutrifft, müssen Sie selbst am besten wissen. Oder aber, Sie lassen sich professionell beraten. Letztlich müssen Sie abwägen, testen und eine Entscheidung treffen.

        Man sollte allerdings als gegeben ansehen, dass ein Debian stable oder Ubuntu 18.04 LTS in diesem Fall vorbeugend gewirkt hätten. Und das tun sie wahrscheinlich auch in anderen Fällen.

        Für einzelne Pakete kann man unter Debian backports verwenden. Unter Ubuntu gibt es die PPAs. Man muss aber wissen, was man tut, und Vorsicht walten lassen, vor Allem bei späteren Versionszweigaktualisierungen. Mit AppImages, Snaps und Flatpak hat man inzwischen auch recht annehmbare Möglichkeiten, dem Problem veralteter Endanwenderprogramme aus dem Weg zu gehen.

        Allerdings frage ich mich immer wenn ich das höre/lese, wie der Mechanismus funktioniert. Nur durch alte Pakete wird ja ein System nicht stabiler.
        Das hängt allein von der Definition des Stabilitätsbegriffs ab.

        Ich muss noch herausfinden, wie dieser QA-Prozess genau aufgesetzt ist, und ob das für die x-tausend kleinen Desktopprogrämmchen (schwer automatisiert zu testen) plausibel ist, oder nur Träumerei.
        Meines Wissens nach beläuft sich Debians QA auf den Vorveröffentlichungsfreeze und die minor releases. In beiden Fällen werden neben Sicherheitslücken auch andere Fehler (release critical, grave) behoben. Letztlich hängt es aber wie überall von den Kapazitäten und Ressourcen ab, ob bzw. was gefixt wird.

        Automatisierte QA-Prozess kann ich bei Debian noch nicht wirklich erkennen. Einige Pakete enthalten ja selbst Tests, die bei jedem Kompilieren durchgeführt werden. Dann gibt es natürlich lintian und irgendwelche Jenkins-Instanzen. Ich glaube, es gibt sogar Ideen, die CI-Features von GitLab-Instanzen zu nutzen. Das ist meines Wissens allerdings sehr paketabhängig, was da geschieht, und was nicht. Dann gibt es noch die Tests auf Reproduzierbarkeit.
        Tests auf dem Niveau von openQA wie in openSUSE oder Fedora kann ich nicht erkennen. Auch keine Ambitionen in diese Richtung.

        Letztlich ist das auch ein Stück weit der Preis, den man für Linux auf dem Desktop zahlt, vor Allem wenn man immer aktuell haben möchte.

        ... und dann sehe ich mit Debian 11, wie sich grub 2.04 dort schlägt.
        Ich wäre mir nicht so sicher, dass Debian 11 mit GRUB in Verison 2.04 erscheinen wird.


        Insgesamt möchte ich Ihnen zu verstehen geben, dass man die Ursachen für die ganzen Problemchen gerne suchen kann. Aber wenn man mit einem gewissen Einstellung an diese Sachen geht, dann muss man sich auch mal die Frage stellen oder gefallen lassen, inwieweit man für diese Problemchen selbst verantwortlich sein könnte. Hätte man die Probleme vorbeugen können? War man sich des Risikos einer Aktualisierung auf eine eher schlecht als recht unterstützte Zwischenveröffentlichung bewusst? War die Aktualisierung tatsächlich notwendig? Wieso stellt man den ursprünglichen Zustand, mit dem es lief, nicht einfach wieder her, statt sich weiter mit diesen Problem herum zu plagen?
        Meine gut gemeinten Ratschläge dazu hatte ich ja bereits geäußert. Ich vermute, dass Sie - ggf. modulo fehlender(?) Unterstützung bestimmter Hardware - mit dem Verbleib auf 18.04(.z) deutlich besser gefahren wären.

        0
        Von Verfluchtnochmal_5987108 am Do, 20. Februar 2020 um 22:24 #

        Wann wollt ihr Kinder endlich verstehen dass "stabil" in dem Kontext ausschließlich und nur KEINE VERÄNDERUNGEN im life cycle des release bedeutet und nichts, wirklich nichts mit Stabilität im Sinn es fliegt dir was um die Ohren zu tun hat?

        Wie will jemand wie du der nicht einmal Basis Begriffe kennt irgendwelche Entscheidungen treffen und wie kommst du mit sowenig Fachwissen dazu dich bei so vielen Themen wichtig zu machen?

0
Von Oh neim! am So, 16. Februar 2020 um 18:35 #

Ubuntu ist gut und läuft, es ist stabil und nicht so fehleranfällig wie andere Distros. Aber jetzt brechen hier eh wieder die Glaubenskriege aus und jeder Debian User oder Arch Anwender bekämpfen sich bis zum letzten Tropfen Blut.

Das ist auch übrigens das Problem, warum Gnu Linux auf dem Desktop nie mehr als 5 Prozent erreichen wird.

  • 0
    Von Josef Hahn xh am So, 16. Februar 2020 um 19:15 #

    > [...] nicht so fehleranfällig wie andere Distros [...]

    Diese Glaubenskriege kenne ich im Allgemeinen gut, finde sie ausgesprochen ärgerlich (weil sie idR vollkommen unreflektiert und inhaltsleer sind) und unkonstruktiv, und halte sie auch für ein echtes Problem. Aber dein Kommentar wirkt auf mich ein bisschen so, als würdest du das gerade vermissen und einen Glaubenskrieg vom Zaun brechen zu wollen?! :)

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung