Ubuntu: Kernel-Inkonsistenzen

Das muß mir mal jemand erklären…

PackagePPAReleaseUpdatesProposed
bionic/linux4.15.0-44.474.15.0-20.214.15.0-43.464.15.0-44.47
bionic/
linux-hwe
4.18.0-14.15
~18.04.1
4.18.0-13.14
~18.04.1
4.18.0-14.15
~18.04.1
cosmic/linux4.18.0-14.154.18.0-10.114.18.0-13.144.18.0-14.15
disco/linux4.18.0-11.124.19.0-11.12

…nicht wirklich.

Nach dem Desaster vor einem Jahr (1, 2, 3), bei dem Canonical (sicherlich nicht nur) bei mir jegliche Reputation verloren hat (Unbrauchbarmachung von Hardware – nur wer auf CSM only gesetzt gehabt hat, ist auf entsprechenden Boards dem GAU entgangen – und vor allem der Umgang mit dem massiven Problem), ist man dort seitdem von Konservatismus beseelt, sozusagen ins Gegenteil verfallen (wenn man mal annimmt, bislang seien sie up-to-date gewesen, zumindest in ihrem Rahmen).

Obige Angaben sind aus heutigem kernel.ubuntu.com/sru/versions.html entnommen.

18.04 Bionic ist mit Kernel 4.15 released worden. Das jeweils erste Pointrelease behält Kernel und XServer in den Hauptversionen bei, es bleibt also in 18.04.1 bei Kernel 4.15. Soweit wie gehabt.

Ein zweites Pointrelease liefert man mit HWE aus, es wäre demnach bei 18.04.2 der Cosmic-Kernel 4.18 (und der ist schon nicht gerade wahnsinnig aktuell und längst aus dem Vanilla-Support). Das ist laut Release Schedule für 2019-02-07 geplant, also in zwei Wochen.

Das heutige lbionic-desktop-amd64.manifest listet 4.15.0-44.47, gleichzeitig proposed für Bionic ohne HWE, also immer noch 4.15. Wann will Canonical anfangen, 4.18 einzupflegen? So kurz vor der Angst machen sie’s dort ja eh nicht (mehr).

Und 19.04 Disco? Dort sieht es noch übler aus. Mit 4.18.0-11.12 hängt man zwei Unterversionen hinter 18.10 Cosmic und – unfaßbar – Long Term Sleeping mit nachinstalliertem HWE. Für Daily Builds absolut unverständlich. Weshalb sollten interessierte Ubuntu-User alten Mist testen? Im falschen Glauben, man hätte in dieser Entwicklungsversion was (für Ubuntu) aktuelles. Denn das dort lange bis ~anderthalb Monate vor Release unzählige völlig veraltete Pakete herumgammeln, habe ich schon oft angeprangert. Wer also von Anfang an einen aktuell gültigen Versionsstring durch devel ersetzt, um ein quasi-Rolling-Release erhalten zu wollen, erweist sich einen Bärendienst.

Proposed für Disco ist 4.19 (und 4.19.0-11.12 ist von gestern, also nicht etwa abgehakt). Schläft man bei Canonical komplett? 4.20 ist aktuell und zwar bereits in 4.20.4 (wovon auch der Mainline-Kernel noch nichts weiß, nur .3). Man wird im April ja wohl kaum einen jetzt schon Alteisen-Kernel bringen wollen (mal davon abgesehen, daß dann längst 5.0, derzeit rc3, final ist und 5.1 bei den letzten RCs). Oder schielt man plötzlich auf longterm von 4.19 Vanilla?

Apropos Mainline-Kernel. Das ist ja für Ubuntu-User, die wenigstens beim Kernel aktuell sein wollen, eine praktikable Möglichkeit. Wenn, ja, wenn. Rund zehn Tage lang und x Kernel-Versionen, wenn man die Dailies mitzählt, hat man nicht mitbekommen, daß das automatische Kernel-Bauen bei x86_64 fehlgeschlagen ist. Das hat ja sogar im Klartext dagestanden. Wie ist das gleich noch mit angeblich automatischem QA gewesen?

Wenn man nur mal diese Stories sieht, verwundert es mich nicht, daß Redmond mit London so herzlich zusammenarbeitet. Qualität ist da sicher nicht ausschlaggebend, sondern Verbreitung in jeweiliger Sparte. Und was so getönt wird. Oder mag noch jemand die penetrante Eigenwerbung des einstigen Pioniers Mark Shuttleworth selbst auf übergreifenden Entwicklerkonferenzen, wo sowas verpönt ist, hören?