Selbst kompilierter Kernel

[Isoroku]

Moin, ich hätte da mal eine Frage an die Fachleute!

Eigentlich auf der Suche nach einer bestimmten apt-get option bin ich hier auf folgende Zeilen gestoßen:

Da Ubuntu möglichst viel Hardware unterstützen soll, ist der Standard-Kernel extrem überladen. Das kann das System langsam und instabil machen. Mit einem selbst gebauten Kernel umgeht man diese Probleme, indem man den Kernel genau auf sein System zuschneidet.

Das klingt einleuchtend, und da ein schnelleres OS nie verkehrt sein kann begann ich mich zum Thema Kernel - Kompilierung zu belesen. Leider sind die aufgeführten Pro- und Contras sehr widersprüchlich, weswegen ich hier nochmal nachfragen will:
1. Stellt sich Ubuntu (im Vgl. zu anderen Distris) im Umgang mit selbst kompiliertem Kernel wirklich "zickiger" an, also ist ein von Canonical erstellter Kernel ausdrücklich erwünscht?
2. Wie groß ist der Geschwindigkeitsvorteil zwischen Standard und selbst-kompiliert denn nun wirklich?

Danke und MfG!

Iso.

 

[dot]

Fuer 99,9% der Anwender ist ein eigens konfigurierter Kernel voellig uninteressant, da der Performanceunterschied vermutlich im nicht fuehlbaren Bereich liegt und ob der Kernel nun aufgrund von mehr unterstuetzten Geraetetreibern/Funktionen beim Booten 5 Sekunden laenger braucht oder nicht ist relativ. Man koennte zwar bei Ubuntu die ganzen geladenen Module aus dem Autostart entfernen die man nicht benoetigt, aber ob sich das lohnt? Zusaetzlich muss man natuerlich wissen was man tut. Ich wuerds einfach lassen und das System nutzen so lange man keine Probleme hat oder man nicht bestimmte Funktionen benoetigt um etwas nutzen zu koennen.

 

[Jimini]

Es gibt meines Erachtens zwei wesentliche Gründe für einen selbst konfigurierten und kompilierten Kernel:
- Sicherheit (alles nicht benötigte raushauen, den Rest fest einkompilieren und das Laden von Modulen deaktivieren)
- ein schlankes System
Wie dot schon schreibt, muss man natürlich wissen, was man tut, man sollte also sein System kennen. Wenn das nicht der Fall ist, bringt ein selbst gebauter Kernel eher neue Probleme mit sich. Wenn man sein System verschlanken und beschleunigen will, kann man sich mal an den Kernel setzen, es gibt aber wesentlich lohnenswertere "Baustellen". Eine IP-Adresse beispielsweise fest zuzuweisen anstelle sie beim Bootvorgang mittels DHCP zu holen, dürfte hinsichtlich Bootdauer mehr bringen als am Kernel herumzudoktern.

Ich selber halte es so, dass ich alles weglasse, was ich nicht benötige. Das mache ich aber nicht deswegen so, damit der Quadcore und die 4GB RAM weniger ausgelastet werden, sondern weil ich meine Systeme generell von nicht benötigtem Ballast frei halte - je weniger Software, desto weniger Fehlerquellen.

MfG Jimini

 

[Bauer87]

Den größten Vorteil bring die Entsorgung der initial Ramdisk, wenn man sich nen Kernel selber baut. Aber das bringt auch nur was beim Bootvorgang. Danach ist es eigentlich recht egal, ob der Kernel modular oder streng monolithisch geladen wurde – er liegt eh komplett im RAM. Da Canonical Ubuntu schon sehr stark optimiertwirst du eher etwas kaputt machen, weil du beispielsweise irgendeine Kompressionstechnik nicht anwendest oder ähnliches. (Komprimiertes Zeug von der Festplatte laden und dann entpacken ist u.U. schneller als etwas unkomprimiertes aber größeres zu laden.)

Vor allem wichtig bei selbst kompilierten Kernels: Es funktioniert nicht mehr alles genau so, wie es bei den anderen. Hast du eine AMD-Grafikkarte und verzichtest daher auf den Nouveau-Treiber, wird deine Linuxinstallation nach nem Grafikkartentausch oder in nem anderen Rechner (mit Nvidia-Grafikkarte) nicht hochfahren. Wenn du weiter den Standard-Ubuntukernel benutzt, wäre das kein Problem. Gleiches gilt für deine neue Soundkarte: Erst mal nen neuen Kernel kompilieren. Ohne wäre es Plug&Play&Listen gewesen.

@Jimini: DHCP-Anfragen verzögern die Zeit zum Login-Screen nicht (mehr). Es gibt keinen Deamon, der auf funktionierenden Netzwerkzugriff wartet. Im Gegenteil wird der Network-Manager meist erst nach dem Login aktiv.

 

[Jimini]

@Jimini: DHCP-Anfragen verzögern die Zeit zum Login-Screen nicht (mehr). Es gibt keinen Deamon, der auf funktionierenden Netzwerkzugriff wartet. Im Gegenteil wird der Network-Manager meist erst nach dem Login aktiv.

Hm, ich nutze zwar kein Ubuntu, bei mir ist es aber so, dass schon während des Bootvorgangs NFS-Shares eingebunden werden, wofür ich natürlich eine Netzwerkverbindung benötige. Aber natürlich kann man das auch so hinbiegen, dass erstmal das GUI geladen wird.

MfG Jimini

 

[Bauer87]

OK, es gibt Sonderfälle. Neben fest eingebundenen Netzwerkshares könnte man auch Booten über das Netzwerk dazu zählen. Afaik kann man auch das stückweise einrichten, sodass nicht vom BIOS aus sondern erst von einem Linux auf das Netzwerk zugegriffen wird. Aber wir werden hier immer exotischer. Im Regelfall ist der Bootvorgang heute dank Abhängigkeitenauflösung der Deamons sehr Robust geworden und lässt sich nicht so leicht verzögern. Damit sinkt dann natürlich auch der Optimierungsbedarf.

 

[Jimini]

OK, es gibt Sonderfälle. Neben fest eingebundenen Netzwerkshares könnte man auch Booten über das Netzwerk dazu zählen. Afaik kann man auch das stückweise einrichten, sodass nicht vom BIOS aus sondern erst von einem Linux auf das Netzwerk zugegriffen wird. Aber wir werden hier immer exotischer. Im Regelfall ist der Bootvorgang heute dank Abhängigkeitenauflösung der Deamons sehr Robust geworden und lässt sich nicht so leicht verzögern. Damit sinkt dann natürlich auch der Optimierungsbedarf.

Das stimmt ja auch. Ich meinte damit ursprünglich nur, dass es in der Regel mehr bringt, den Bootprozess selber auf Bremsen hin zu untersuchen als den Kernel Ricer-mäßig halbtot zu optimieren.

MfG Jimini

 

[riedochs]

Ich hatte auch schon selbst kompilierte Kernel. Bin wieder weg davon. Bei neuen Kernelversionen jedesmal die gesamte Prozedur von vorne.

 

[Jimini]

Ich hatte auch schon selbst kompilierte Kernel. Bin wieder weg davon. Bei neuen Kernelversionen jedesmal die gesamte Prozedur von vorne.

Hm, dann hast du eventuell etwas falsch gemacht - ich nutze den Rechner hier seit 2.6.32-r7 und bin momentan bei 2.6.39-r1; bisher habe ich immer mit "make menuconfig && make && make modules_install && make install" die alte .config auf den neuen Kernel anwenden können. Es würde mich wundern, wenn das Gentoo-spezifisch wäre, weil sonst wäre das wirklich ein riesiger Umstand - vor allem, weil ich nicht nur die stable-Versionen mitnehme.

MfG Jimini

 

[dot]

die alte .config auf den neuen Kernel anwenden können.

Und Eintrage/Funktionen die vorher noch nicht in der Kernelversion vorhanden waren werden dann sogar noch einmal explizit abgefragt, ob sie nun aktiviert werden sollen oder nicht. Mit einem kleinen Script ist das eigentlich relativ automatisch loesbar (inklusive des Kopierens in das /boot Verzeichnis und das Hinzufuegen von moeglichen Bootloader Eintraegen).

Bei Distributionen wie Gentoo kann man ja verstehen das man einen eigenen Kernel bauen muss, aber da ist es auch Teil des Konzepts. Bei vielen Anderen finde ich es hingegen zu 99,9% oversized

 

[Jimini]

Bei Distributionen wie Gentoo kann man ja verstehen das man einen eigenen Kernel bauen muss, aber da ist es auch Teil des Konzepts. Bei vielen Anderen finde ich es hingegen zu 99,9% oversized

Naja, auch genkernel wird immer beliebter

MfG Jimini