longterm bei kernel.org
longterm bei kernel.org
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?
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?
Re: longterm bei kernel.org
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."
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."
Zuletzt geändert von owl102 am 20.03.2017 11:18:21, insgesamt 1-mal geändert.
Re: longterm bei kernel.org
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?
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?
Re: longterm bei kernel.org
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.guennid hat geschrieben:Kann mir mal jemand die Philosophie dieser Klassifizierung erklären.
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.
Re: longterm bei kernel.org
...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.hikaru hat geschrieben:Zwischen zwei Minor-Versionen des Kernels kann es schon mal zu einem API-Bruch kommen.guennid hat geschrieben:Kann mir mal jemand die Philosophie dieser Klassifizierung erklären.
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!
Re: longterm bei kernel.org
@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?
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?
Erwartet hatte ich gar nichts, na ja, doch: eine Antwort halt, sonst hätte ich nicht gefragt.owl102 hat geschrieben:guennid, mir ist auch überhaupt nicht klar, was du erwartest.
Was mir jetzt klar ist. https://de.wikipedia.org/wiki/%C3%9Cber ... beim_Redenowl102 hat geschrieben:Wie soll jemand Support für einen Kernel leisten, wenn er keine Bugfixes tätigen und keine Sicherheitslücken stopfen darf?
Re: longterm bei kernel.org
Ja. Es hat sich mehr oder weniger dieses Versionsschema etabliert, das auch der Kernel nutzt (siehe auch: [1]):guennid hat geschrieben:Mit minor ist die zweite Zahl gemeint - richtig?
Major.Minor.Patch.Build
Meinem Verständnis nach, ja.guennid hat geschrieben: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
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
Re: longterm bei kernel.org
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.hikaru hat geschrieben:Warum baust du überhaupt eigene Kernel?
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 hat geschrieben: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.
Re: longterm bei kernel.org
Also doch Spaß an der Freude?guennid hat geschrieben:Ich mag Minimalismus. Ein angepasster Kern ist bei mir um den Faktor 10 kleiner als der Debian-Standard.
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.
Nein, natürlich nicht. Aber vielleicht würde es sich lohnen, die Motive dafür zu überprüfen.guennid hat geschrieben:Muss ich jetzt das Kernel-Bauen drangeben?
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.
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 hat geschrieben:Den Ehrgeiz, ein Nerd zu werden, hab' ich nicht, auch nach ca 15 Jahren nicht.
Re: longterm bei kernel.org
Aber sicher doch!Also doch Spaß an der Freude?
Der Spruch gefällt mir!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.
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.
Re: longterm bei kernel.org
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.guennid hat geschrieben:Wollen wir's damit bewenden lassen?
Wir sind doch hier eh in "Smalltalk".guennid hat geschrieben:Ich hätt' Lust, noch was zur IKEA-Analogie zu sagen, aber dann landen wir wieder mehr bei der allgemeinen Philosophie.
Vielleicht auch ein bisschen Stockholm-Syndrom. Aus Konsistenzgründen würde ich das aber lieber im ursprünglichen Thread fortsetzen.guennid hat geschrieben: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.
Re: longterm bei kernel.org
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.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.
Re: longterm bei kernel.org
Kernel backen ist ziemlich so wie die Waschmaschine nutzen. Einmal in Gang gesetzt, beschaeftigt man sich mit anderen Dingen.hikaru hat geschrieben: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.guennid hat geschrieben:Wollen wir's damit bewenden lassen?
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"
Re: longterm bei kernel.org
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.
Ach ja, hatte ich noch vergessen: Ich komme bis heute ohne udev aus. Muss man nicht, ok. Mir gefällt's trotzdem.
Re: longterm bei kernel.org
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?
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
- Beiträge: 3163
- Registriert: 07.05.2005 13:52:55
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Altomünster
-
Kontaktdaten:
Re: longterm bei kernel.org
Ja sicher geht das.
Und sollte sich irgendwo eine neue Option eingeschlichen haben, dann wirst du eh zu einer Auswahl aufgefordert.
Und sollte sich irgendwo eine neue Option eingeschlichen haben, dann wirst du eh zu einer Auswahl aufgefordert.
Versuchungen sollte man nachgeben. Wer weiß, ob sie wiederkommen!
Oscar Wilde
Mod-Voice / My Voice
Oscar Wilde
Mod-Voice / My Voice
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: longterm bei kernel.org
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?hikaru hat geschrieben: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.
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: longterm bei kernel.org
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 hat geschrieben: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?
Re: longterm bei kernel.org
Hmmm ...Würde Dir fürs Bauen ohnehin die localmodconfig empfehlen
Gemeint ist wahrscheinlich: Diese Module werden beim make nicht kompiliert, also in der .config wahrscheinlich auf "is not set" gesetzt.es werden darauf aufbauend automatisch alle Module deaktiviert die aktuell nicht geladen sind.
scheint mir unter dieser Annahme auch nicht ganz unproblematisch zu sein insbesondere, wenn im System kein udev benutzt wird.
-
- Beiträge: 5529
- Registriert: 30.12.2004 15:31:07
- Wohnort: Wegberg
Re: longterm bei kernel.org
Hallo
Meinen letzten Kernel hab mit Kernel 2.4 selbst kompiliert (unter Debian), seitdem nutze ich meine Zeit besser.
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
Meinen letzten Kernel hab mit Kernel 2.4 selbst kompiliert (unter Debian), seitdem nutze ich meine Zeit besser.
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.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?
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
Re: longterm bei kernel.org
Hab ich auch nicht gesagt. Ich sagte nur, dass der Speicherplatz nicht der einzige Grund sein sollte.breakthewall hat geschrieben:Sich einen eigenen Kernel zu bauen, ist keineswegs nutzlos noch Zeitverschwendung.hikaru hat geschrieben: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.
Und ich erhöhe um: Zeitersparnis ist auch kein ausreichender Grund, denn:
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.breakthewall hat geschrieben: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?
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.
Re: longterm bei kernel.org
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.
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.