longterm bei kernel.org

[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.