longterm bei kernel.org

[guennid]

Kann mir mal jemand die Philosophie dieser Klassifizierung erklären.

Ich baue die Kerne für meine Maschinen in der Regel selbst aus diesen Quellen, mir ist es aber eigentlich zuviel Aufwand, ständig neueren Versionen hinterherzulaufen. Ergo kam ich auf die Idee, es bei einigermaßen neuen sogenannten Longterm-Kernen zu belassen. Vor einigen Wochen hatte ich mir die Quellen 4.4.47 als "longterm" gezogen. Beim gerade anstehenden Kernelbau stelle ich fest, dass der bei kernel.org nicht mehr als longterm auftaucht, stattdessen ist es 4.4.55. Soweit ich recherchiert habe, sollte longterm ein Zeitraum von ca. zwei Jahren sein. Was 4.4. angeht, wird da aber keine dritte Zahl genannt. Erninnere ich falsch oder wird hier longterm doch im "Sekundenmaßstab" gemessen?

[owl102]

Das "long term" bezieht sich lediglich auf die 4.4. Bugfixes des 4.4er-Kernels werden getätigt, länger als bei den anderen Kernel (deswegen "long term support"), und dementsprechend wird die dritte Stelle der Versionsnummer erhöht (und wird sich mit jedem Bugfix weiter erhöhen).

Siehe auch https://de.wikipedia.org/wiki/Linux_(Kernel): "Bei neuen Versionen wird seitdem die zweite Ziffer erhöht und die dritte steht für Bugfixreleases."

[guennid]

Danke für die Info!

Heißt das jetzt, dass ich mir doch wieder für jeden Kernel (4.4) neue Quellen besorgen sollte/müsste? Dann macht das mit longterm doch eigentlich keinen Sinn, wenn ich davon ausgehe, dass die zwischen 4.4.47 und 55 getätigten bugfixes im - sagen wir - 4.6.1 doch eh enthalten sind?

[hikaru]

Kann mir mal jemand die Philosophie dieser Klassifizierung erklären.

Zwischen zwei Minor-Versionen des Kernels kann es schon mal zu einem API-Bruch kommen. Und wenn eine deiner Anwendungen auf eine Kernel-Schnittstelle zugreift, die von so einem Bruch betroffen ist, dann musst du deine Anwendung an die neue Schnittstelle anpassen.
Die Idee hinter Longtem-Kernels ist, dass du eine Kernelversion möglichst lange benutzen kannst, ohne dein restliches System ständig an neuere Kernel-APIs anpassen zu müssen.

Im Grunde ist es ähnlich wie bei Debian stable. Die Upstream-Version der Software bleibt über den gesamten Releasezeitraum gleich, um sicherzustellen, dass das Gesamtpaket der Distribution harmioniert. Das bedeutet aber nicht, dass es keine Sicherheitspatches gibt.

[owl102]

Kann mir mal jemand die Philosophie dieser Klassifizierung erklären.

Zwischen zwei Minor-Versionen des Kernels kann es schon mal zu einem API-Bruch kommen.

...und außerdem gilt die Regel: Neue Features = neue Bugs. Die Idee ist also neben der ABI-Konstanz auch, einen gut abgehangenen Kernel zu haben, der im Laufe des Supportzeitraumes immer stabiler wird, da eben nur noch Bugs gefixt (und Sicherheitslöcher gestopft) werden.

guennid, mir ist auch überhaupt nicht klar, was du erwartest. Wie soll jemand Support für einen Kernel leisten, wenn er keine Bugfixes tätigen und keine Sicherheitslücken stopfen darf? Also liegt es doch in der Natur der Sache, daß es auch bei "long term support" Kernel neue Versionen gibt, und das sogar länger als bei den anderen Kernel-Zweigen!

[guennid]

@owl102
die schließende Klammer in deinem Link steht hinter den url-tags

Ich danke auch dir, hikaru.

Mit minor ist die zweite Zahl gemeint - richtig? (Über Sinn und Unsinn dieser Klassifizierung könnte man streiten, wenn ich mir die Beispiele im wikipedia-Eintrag zu Versionsnummern anschaue , habe ich aber nicht vor.)

Was mein procedere angeht, frage ich, ob folgende Überlegung einigermaßen sinnig ist:Beim Neubau eines Kerns 4.4 sollte ich tatsächlich immer die neueste Quellen dieser Version, z.Z. also 4.4.57 verwenden (es wäre wohl eher dumm, die zwischen 47 und 55 erfolgten bugfixes zu ignorieren). Dementsprechend müsste ich, wenn ich wegen eines neu erforderlichen Moduls auf einer anderen Maschine mit 4.4.47 den Kern updaten wollte, dessen config mit oldconfig an den 55er anpassen - wobei sich der Aufwand dieser Anpassungen wohl stark in Grenzen halten würde?

guennid, mir ist auch überhaupt nicht klar, was du erwartest.

Erwartet hatte ich gar nichts, na ja, doch: eine Antwort halt, sonst hätte ich nicht gefragt.

Wie soll jemand Support für einen Kernel leisten, wenn er keine Bugfixes tätigen und keine Sicherheitslücken stopfen darf?

Was mir jetzt klar ist. https://de.wikipedia.org/wiki/%C3%9Cber ... beim_Reden

[hikaru]

Mit minor ist die zweite Zahl gemeint - richtig?

Ja. Es hat sich mehr oder weniger dieses Versionsschema etabliert, das auch der Kernel nutzt (siehe auch: [1]):
Major.Minor.Patch.Build

Was mein procedere angeht, frage ich, ob folgende Überlegung einigermaßen sinnig ist:Beim Neubau eines Kerns 4.4 sollte ich tatsächlich immer die neueste Quellen dieser Version, z.Z. also 4.4.57 verwenden

Meinem Verständnis nach, ja.
Allerdings solltest du hier auf meine Einschätzung nicht viel geben.

Mal eine grundsätzliche Frage, rein aus Interesse:
Warum baust du überhaupt eigene Kernel? Ich habe da für mich nie eine Notwendigkeit gesehen. Und wenn du es aus Spaß an der Freude machst, dann würde ich erwarten, dass du über solche Sachen wie Versionierungspolitik besser informiert wärest.


[1] https://de.wikipedia.org/wiki/Versionsnummer

[guennid]

Warum baust du überhaupt eigene Kernel?

Ich mag Minimalismus. Ein angepasster Kern ist bei mir um den Faktor 10 kleiner als der Debian-Standard. Das Bauen für eine Desktop-Maschine fällt mir Unbedarftem dank der Unterstützung, die ich in diesem Forum Forum erlebe, nicht schwer.

wenn du es aus Spaß an der Freude machst, dann würde ich erwarten, dass du über solche Sachen wie Versionierungspolitik besser informiert wärest.

Tja, da entspreche ich wahrscheinlich nicht deinen Erwartungen. Muss ich jetzt das Kernel-Bauen drangeben? Den Ehrgeiz, ein Nerd zu werden, hab' ich nicht, auch nach ca 15 Jahren nicht.

[hikaru]

Ich mag Minimalismus. Ein angepasster Kern ist bei mir um den Faktor 10 kleiner als der Debian-Standard.

Also doch Spaß an der Freude?
Ich bin auch gern "Minimalist", aber ich minimiere dann lieber meinen Zeitaufwand den ich für das Aktualisieren des Kernels habe, als die Anzahl der Sektoren, die das Ergebnis auf meinem Datenträger belegt.

Muss ich jetzt das Kernel-Bauen drangeben?

Nein, natürlich nicht. Aber vielleicht würde es sich lohnen, die Motive dafür zu überprüfen.

Ein bisschen erinnert mich das an Leute, die stolz darauf sind, wie viel Geld sie mit ihrem Ikea-Bausatz gespart haben, dessen Aufbau sie das ganze Wochehnende gekostet hat. Wenn man sie dann fragt, wie viel ihnen ihr Arbeitgeber für ein durchgearbeitetes Wochenende gezahlt hätte, dann ist der Bausatz oft nicht mehr günstiger als ein Fertigmöbel.
Das heißt nicht, dass die Entscheidung für den Bausatz falsch war, aber die Begründung für die Entscheidung sollte sich eben nicht (nur) in Euro-Scheinen (oder HDD-Sektoren) ausdrücken, sondern z.B. auch in dem Spaß den mancher vielleicht beim Aufbau hat, ein anderer aber als Zeitverschwendung ansehen würde.

Den Ehrgeiz, ein Nerd zu werden, hab' ich nicht, auch nach ca 15 Jahren nicht.

Sich in Zeiten von quasi unendlich verfügbarem billigen Speicher damit zu beschäftigen, den Speicherbedarf eines an sich gut funktionierenden Kernels um seiner selbst willen zu minimieren, klingt für mich ziemlich nerdig.

[guennid]

Also doch Spaß an der Freude?

Aber sicher doch!

ich minimiere dann lieber meinen Zeitaufwand, den ich für das Aktualisieren des Kernels habe, als die Anzahl der Sektoren, die das Ergebnis auf meinem Datenträger belegt.

Der Spruch gefällt mir!

Sich in Zeiten von quasi unendlich verfügbarem billigen Speicher damit zu beschäftigen, den Speicherbedarf eines an sich gut funktionierenden Kernels um seiner selbst willen zu minimieren, klingt für mich ziemlich nerdig.

Ich fühle mich geadelt!

Wollen wir's damit bewenden lassen?

Ich hätt' Lust, noch was zur IKEA-Analogie zu sagen, aber dann landen wir wieder mehr bei der allgemeinen Philosophie.

Im Nachhinein betrachtet würde ich meine Einschätzung der Saudi-Damen erheblich korrigieren wollen: Die. hatten nicht nur gar keine Vorstellungen von Emanzipation, sondern fühlten sich in ihrer "Diskriminierung" auch noch sauwohl - nun ja, mit dem Gelbeutel ihrer männlichen Verwandten im Hintergrund - nicht verwunderlich.

[hikaru]

Wollen wir's damit bewenden lassen?

Gerne! Ich wollte eigentlich nur wissen, ob du bei der ganzen objektiv ja nutzlosen Kernelbauerei wenigstens genug Spaß hast, um die dafür aufgebrachte Zeit als wertvoll verbracht zu betrachten.

Ich hätt' Lust, noch was zur IKEA-Analogie zu sagen, aber dann landen wir wieder mehr bei der allgemeinen Philosophie.

Wir sind doch hier eh in "Smalltalk".

Im Nachhinein betrachtet würde ich meine Einschätzung der Saudi-Damen erheblich korrigieren wollen: Die. hatten nicht nur gar keine Vorstellungen von Emanzipation, sondern fühlten sich in ihrer "Diskriminierung" auch noch sauwohl - nun ja, mit dem Gelbeutel ihrer männlichen Verwandten im Hintergrund - nicht verwunderlich.

Vielleicht auch ein bisschen Stockholm-Syndrom. Aus Konsistenzgründen würde ich das aber lieber im ursprünglichen Thread fortsetzen.

[guennid]

Wenn man sie dann fragt, wie viel ihnen ihr Arbeitgeber für ein durchgearbeitetes Wochenende gezahlt hätte, dann ist der Bausatz oft nicht mehr günstiger als ein Fertigmöbel.

Womöglich sogar teurer! Was aber wiederum davon abhängt, ob man in der gegebenen Situation real überhaupt die "Chance" auf ein sonderbezahlt durchzuarbeitendes Wochende hat. Ansonsten wird aus Selbstausbeutung sehr schnell Selbstbetrug.

[ViNic]

Wollen wir's damit bewenden lassen?

Gerne! Ich wollte eigentlich nur wissen, ob du bei der ganzen objektiv ja nutzlosen Kernelbauerei wenigstens genug Spaß hast, um die dafür aufgebrachte Zeit als wertvoll verbracht zu betrachten.

Kernel backen ist ziemlich so wie die Waschmaschine nutzen. Einmal in Gang gesetzt, beschaeftigt man sich mit anderen Dingen.

Waschmaschine fuellen, Programm auswaehlen und Start druecken.
Kernel auspacken, Config einpflegen und kompilieren.

Bei allen beiden steht man ja nicht daneben und wartet, bis die ihre Arbeit erledigen um danach erst weiter zu machen.

Des weiteren muss man nicht warten bis ein Distributor seine Pakete aktualisiert oder backports bereitstellt. Hier ist man einfach "unabhaengiger". Man kann eine "alte" Distribution so schnell auf neuer Hardware laufen lassen, was ich schon paar mal machen musste.

Und bei kleineren Kerneln gilt, "Unkaputtbar durch weglassen"

[guennid]

Schön, schön, schön!

Ach ja, hatte ich noch vergessen: Ich komme bis heute ohne udev aus. Muss man nicht, ok. Mir gefällt's trotzdem.

[guennid]

Ich spül's nochmal hoch:

Kann man die config, mit der ein 4.4.47 gebaut wurde, ohne Anpassung auf die Sourcen 4.4.55 loslassen? Allgemein formuliert: Spielt die dritte Zahl (bugfixes) beim Kernelbau eine Rolle?

[Teddybear]

Ja sicher geht das.
Und sollte sich irgendwo eine neue Option eingeschlichen haben, dann wirst du eh zu einer Auswahl aufgefordert.

[guennid]

Ok! Danke für die Klarstellung!

[breakthewall]

Ich wollte eigentlich nur wissen, ob du bei der ganzen objektiv ja nutzlosen Kernelbauerei wenigstens genug Spaß hast, um die dafür aufgebrachte Zeit als wertvoll verbracht zu betrachten.

Sich einen eigenen Kernel zu bauen, ist keineswegs nutzlos noch Zeitverschwendung. Je größer der Kernel ist, desto länger dauert es diesen zu entpacken, wie auch das System hochzufahren. Ebenso kann man auf diese Weise, nur Bestandteile integrieren bzw. laden lassen, die man effektiv benötigt. Und das wiederum spart Zeit, Platz und senkt mitunter dramatisch die Angreifbarkeit des eigenen Kernels. Die letzten Jahre gab es so viele Lücken in diversen Kernel-Bestandteilen, die Mich bspw. gar nicht betroffen haben. Und das nur weil diese Bestandteile bei Mir überflüssig sind, und in meinem Kernel erst gar nicht existieren, jedoch normalerweise vorhanden wären. Der aktuelle Debian-Kernel im Testing-Release, hat bspw. knapp 25MB an Größe, dagegen ist mein eigener nur knapp unter 5MB groß. Welcher von beiden ist wohl anfälliger für Probleme?

[breakthewall]

Ich spül's nochmal hoch:

Kann man die config, mit der ein 4.4.47 gebaut wurde, ohne Anpassung auf die Sourcen 4.4.55 loslassen? Allgemein formuliert: Spielt die dritte Zahl (bugfixes) beim Kernelbau eine Rolle?

Das ist wie schon gesagt wurde nicht erheblich. Würde Dir fürs Bauen ohnehin die localmodconfig empfehlen, um den ganzen Prozess deutlich zu beschleunigen. Somit musst selbst nichts auswählen, als Basis dient zunächst deine alte Config, und es werden darauf aufbauend automatisch alle Module deaktiviert die aktuell nicht geladen sind. Daher sollte man alle genutzten Geräte anschließen die je gebraucht werden, damit entsprechende Module geladen werden, und letztlich nur das im neuen Kernel aktiv ist.

[guennid]

Würde Dir fürs Bauen ohnehin die localmodconfig empfehlen

Hmmm ...

es werden darauf aufbauend automatisch alle Module deaktiviert die aktuell nicht geladen sind.

Gemeint ist wahrscheinlich: Diese Module werden beim make nicht kompiliert, also in der .config wahrscheinlich auf "is not set" gesetzt.

scheint mir unter dieser Annahme auch nicht ganz unproblematisch zu sein insbesondere, wenn im System kein udev benutzt wird.

[schwedenmann]

Hallo


Meinen letzten Kernel hab mit Kernel 2.4 selbst kompiliert (unter Debian), seitdem nutze ich meine Zeit besser.

Sich einen eigenen Kernel zu bauen, ist keineswegs nutzlos noch Zeitverschwendung. Je größer der Kernel ist, desto länger dauert es diesen zu entpacken, wie auch das System hochzufahren. Ebenso kann man auf diese Weise, nur Bestandteile integrieren bzw. laden lassen, die man effektiv benötigt. Und das wiederum spart Zeit, Platz und senkt mitunter dramatisch die Angreifbarkeit des eigenen Kernels. Die letzten Jahre gab es so viele Lücken in diversen Kernel-Bestandteilen, die Mich bspw. gar nicht betroffen haben. Und das nur weil diese Bestandteile bei Mir überflüssig sind, und in meinem Kernel erst gar nicht existieren, jedoch normalerweise vorhanden wären. Der aktuelle Debian-Kernel im Testing-Release, hat bspw. knapp 25MB an Größe, dagegen ist mein eigener nur knapp unter 5MB groß. Welcher von beiden ist wohl anfälliger für Probleme?

Das sagen, was die Bootzeit angeht, auch Gentoonutzer, nur ist der Unterschied in der die Bootzeit eher im ms Bereich, also absolut vernachglässigbar, da spielen dann andere Faktoren (Anzahl der Programme, Anzahl der gestarteten Prozesse) eher eine Rolle, mal abgesehen davon, das man eine PC nicht alle Stunde neu bootet, geht der Zeitgewinn beim Booten dermaßen gegen Null, bei heutiger Hardware ist das kein Argument mehr.

Zu den Sicherheitslücken, du weißt dummerweise nie, welche Bestandteile insecure sind, da du auf bestimmte Teile eben nicht verzichten kannst, die aber bugs enthalten, ist das eher eine akademische Diskussion, den reale Situation.

mfg
schwedenmann

[hikaru]

Ich wollte eigentlich nur wissen, ob du bei der ganzen objektiv ja nutzlosen Kernelbauerei wenigstens genug Spaß hast, um die dafür aufgebrachte Zeit als wertvoll verbracht zu betrachten.

Sich einen eigenen Kernel zu bauen, ist keineswegs nutzlos noch Zeitverschwendung.

Hab ich auch nicht gesagt. Ich sagte nur, dass der Speicherplatz nicht der einzige Grund sein sollte.
Und ich erhöhe um: Zeitersparnis ist auch kein ausreichender Grund, denn:

Je größer der Kernel ist, desto länger dauert es diesen zu entpacken, wie auch das System hochzufahren. Ebenso kann man auf diese Weise, nur Bestandteile integrieren bzw. laden lassen, die man effektiv benötigt. Und das wiederum spart Zeit, Platz und senkt mitunter dramatisch die Angreifbarkeit des eigenen Kernels. Die letzten Jahre gab es so viele Lücken in diversen Kernel-Bestandteilen, die Mich bspw. gar nicht betroffen haben. Und das nur weil diese Bestandteile bei Mir überflüssig sind, und in meinem Kernel erst gar nicht existieren, jedoch normalerweise vorhanden wären. Der aktuelle Debian-Kernel im Testing-Release, hat bspw. knapp 25MB an Größe, dagegen ist mein eigener nur knapp unter 5MB groß. Welcher von beiden ist wohl anfälliger für Probleme?

Bei deinem eigenen Kernel musst du jede Sicherheitsmeldung selbst beurteilen und den Kernel selbst neu bauen, selbst wenn das Neubauen nur das anschmeißen eines vorgefertigten Scripts ist. Um den Debian-Kernel musst du dich nicht kümmern. Änderungen zu verfolgen ist zwar auch hier keine schlechte Idee, aber die Gefahr, dass dir Schaden droht, wenn du dabei nachlässig bist ist praktisch Null.

In Sachen Zeitaufwand stehen sich also gegenüber:

Download des Debianpakets + Installation des Binärpakets + längere Bootzeit des größeren Kernels
vs.
Download der Kernelquellen + Beurteilen von und ggf. reagieren auf neue CVEs + Kompilieren des neuen Kernels + Installation des gebauten Kernels + kürzere Bootzeit des Selbstbaukernels

Du kannst ja spaßeshalber mal durchrechnen, wann du durch die kürzere Bootzeit des kleineren Kernels und die selteneren Updates durch weniger potenzielle Angriffsfläche den zeitlichen Mehraufwand für deine Beschäftigung mit dem Thema und die eigene Compilierung wirklich Zeit einsparst.
Meine Vermutung ist, dass du mit einer realistischen Rebootzahl nicht zu einem realistischen Break-Even-Zeitpunkt kommen wirst.

[guennid]

Also die Richtung, die die Diskussion jetzt nimmt, interessiert mich eigentlich nicht mehr.

Die Frage ob man eigene Kerne bauen sollte oder nicht, ist genau so eine uferlose politisch/philosophische Diskussion wie die entsprechende zu sudo oder dem gefährlichen "s"-Wort.

Meine Hauptintention dabei, dass ich mir meistens meine eigenen Kerne baue, ist, dass ich nicht Tausende von Einstellungen auf einer Maschine haben will, die ich auf dieser Maschine nie benutzen werde, Und da ich die Möglichkeit habe, das zu individualisieren, nutze ich sie eben. Noch geht das ja weitgehend bei Debian. Wer das für nutzlose Zeitverschwendung hält, braucht's ja nicht zu machen.

Schade nur, dass es jetzt nicht mehr darum geht, wie man denn am zweckmäßisten seine Kerne baut.