Kernel 3.2 noch gepflegt
Einige Maintainer pflegen Kernel auch über längere Zeiträume, ohne dass dazu feste Regeln bestehen. Der derzeit älteste noch offiziell gepflegte Kernel ist der von Debian-Entwickler Ben Hutchins gepflegte Kernel 3.2, der im Januar 2012 veröffentlicht wurde. Vor nicht allzulanger Zeit erst wurde die Pflege des Kernels 2.6.32 von 2009 eingestellt.20 Jahre Support geplant
Das alles erscheint kurz gegenüber den Plänen einer Initiative, die Kernel über 20 Jahre pflegen möchte, über die Jonathan Corbet jetzt auf LWN berichtet. Dabei handelt es sich um die Civil Infrastructure Platform (CIP). Entwickler Yoshitake Kobayashi stellte das Konzept auf der kürzlich abgehaltenen Embedded Linux Conference 2018 in Portland, Oregon vor. Dabei geht es darum, eine stabile Tragschicht für zivile Infrastruktursysteme zu schaffen.Andere Zeitskala
Die Infrastrukturen, auf die wir uns alle verlassen, einschließlich derjenigen für Transport, Energieerzeugung und vieles mehr, basieren auf Linux. Wenn diese Systeme ausfallen, entstehen sofort ernsthafte Probleme. Diese Art von Infrastruktur läuft auf einer anderen Zeitskala als eine typische Linux-Distribution. Die Entwicklungszeit, die allein für die Inbetriebnahme eines solchen Systems benötigt wird, kann bis zu zwei Jahrzehnte betragen, und das System selbst kann dann üblicherweise 25-60 Jahre in Betrieb bleiben.»Our civilization’s infrastructure runs on Linux« – Yoshitake Kobayashi
Zuverlässigkeit, Robustheit und Sicherheit
Die Rechnersysteme, die diese Infrastrukturen unterstützen, müssen über lange Zeiträume funktionieren. Sie müssen auf industrietauglicher Software basieren, die in der Lage ist, das erforderliche Maß an Zuverlässigkeit, Robustheit und Sicherheit zu bieten. Aber auch in dieser konservativen Umgebung müssen diese Systeme stets auf dem aktuellen Stand der Technik sein. Bislang wurde die langfristige Unterstützung, die notwendig ist, um sie am Laufen zu halten, von einzelnen Unternehmen geleistet, ohne dass es zu gemeinsamen Anstrengungen kam, wie Kobayashi berichtet. Das hat diese Systeme zwar funktionsfähig gehalten, ist aber ein teurer Ansatz, der tendenziell hinter dem aktuellen Stand der Technik zurückbleibt.Gemeinsam stärker
Der Weg zu einer Zusammenarbeit besteht darin, ein kollaboratives Framework zu schaffen, das industrietaugliche Software unterstützt und dabei so weit wie möglich mit den Entwickler-Communities zusammenarbeitet. Das ist die Rolle, für die das CIP geschaffen wurde. Derzeit unterstützen sieben Mitgliedsunternehmen die Initiative. Sie supporten das Projekt, indem sie direkt zu den Upstream-Projekten beitragen und Arbeiten finanzieren, die die Ziele des CIP vorantreiben.SLTS-Kernel
CIP konzentriert sich derzeit auf die Erstellung einer Open-Source-Basisschicht, die aus einer kleinen Anzahl von Komponenten besteht, darunter der Kernel, die GNU C-Bibliothek und BusyBox. Die Distributoren sollen auf dieser Basis aufbauen können. Das Hauptprojekt im Moment ist die Erstellung des Super-Langzeit-Support-Kernels (SLTS), der hoffentlich mindestens zehn Jahre lang unterstützt werden kann. Wenn damit die Erfahrung mit extra langfristigem Support wächst, werden künftige Kernel auch längere Supportzeiten haben können. Der erste SLTS-Kernel basiert auf der 4.4 LTS-Version und wird von Ben Hutchings gewartet; die entsprechende 4.4.120-cip20-Version erschien am 9. März 2018. Im Allgemeinen sehen die Richtlinien des Projekts vor, den stabilen Upstream-Versionen zu folgen, solange sie unterstützt werden. Backports von neueren Kerneln sind explizit erlaubt, aber sie müssen in der Hauptlinie liegen, bevor sie für einen SLTS-Kernel infrage kommen. Neue Kernel-Versionen werden alle vier bis sechs Wochen veröffentlicht. Es gibt eine explizite Richtlinie, die die Unterstützung für Out-of-Tree-Treiber aus dem Staging-Bereich des Mainline-Kernel-Trees ausschließt.Anpassung an LTS-Auswahl
Alle zwei bis drei Jahre wird ein neues Major-Kernel-Release für den Super-Langzeit-Support ausgewählt. Das Projekt denkt derzeit darüber nach, welches Release die Basis für den nächsten SLTS-Kernel sein wird. Die Anpassung an die LTS-Auswahl von Greg Kroah-Hartman ergibt dabei den meisten Sinn. Bei einem Treffen auf dem Japan Open Source Summit im Juni wird diese Entscheidung getroffen werden.»Das Jahr-2038-Problem von EDV-Systemen könnte zu Ausfällen von Software im Jahr 2038 führen.« – Wikipedia
