Code: Alles auswählen
apt-cache search kernel-patch
Die meisten Patches gibt's geordnet nach Autoren auf http://www.kernel.org/pub/linux/kernel/people/, allerdings ist da keine Übersicht dabei.kox666 hat geschrieben:Gibt es irgendwo eine Archiv im Internet, wo es die gängigsten Patches gibt, oder muss ich zu jeder einzelnen Herstellerseite wandern und jeden Patch einzeln "sammeln"
Code: Alles auswählen
grep -ir fuck /usr/src/linuxBin ich nicht ganz mit einverstanden. Wenn man spezielle Features haben will oder neuere Treiber braucht um Hardware richtig benutzen zu koennen, koennen einzelne Patches *sehr* nuetzlich sein.pdreker hat geschrieben:Wenn man etwas mehr "on the bleeding edge" sein will, kann man z.B. erstmal damit anfangen die -pre Releases [1] zu verfolgen. Bei Kernel 2.6 sind auch die -mm Patches [2] interessant.
Einzelteile lohnt sich meistens nicht...
Die Frage des OP war aber sehr allgemein gestellt. Wenn man natürlich ein Feature braucht, dass im Standardkernel nicht drin ist, kommt man ja gar nicht um einen Patch herum.Bin ich nicht ganz mit einverstanden. Wenn man spezielle Features haben will oder neuere Treiber braucht um Hardware richtig benutzen zu koennen, koennen einzelne Patches *sehr* nuetzlich sein.
Aber so ein bisschen "ranten" hat ja Tradition in der Szene Da kann ich wenig sinnvolles drueber sagen, ich habe schon laenger keine Vendor Kernel wirklich benutzt (ausser fuer's Installationssystem.) Gehoert habe ich allerdings auch recht haarstraeubende Sachen ... Dass sehr weites Testen ausserordentlich wichtig ist, stimmt natuerlich. Aber ein Kernel den ich fuer genau eine Maschine erstelle, braucht lang nicht all diese Anforderungen erfuellen. Es ist mir z.B. egal, ob manche Features auf irgendwelchem NUMA oder SMP Kisten moeglicherweise Oopsen, solange ich mich hier noch mit einen Singleprozessor rumschlagen muss.pdreker hat geschrieben:Die Frage des OP war aber sehr allgemein gestellt. Wenn man natürlich ein Feature braucht, dass im Standardkernel nicht drin ist, kommt man ja gar nicht um einen Patch herum.Bin ich nicht ganz mit einverstanden. Wenn man spezielle Features haben will oder neuere Treiber braucht um Hardware richtig benutzen zu koennen, koennen einzelne Patches *sehr* nuetzlich sein.
Die Vanilla Kernel sind aber mit Sicherheit die Stabilsten (ob auch die Besten, darüber kann man sicherlich streiten), da sie die mit Abstand grösste Testbasis haben. Selbst die meisten Distri Kernel sind oft mit soviel Beta Kram vollgestopft, dass man es gar nicht glauben will. Debian ist in der Hinsicht eher die rühmliche Ausnahme.
Mit "kleinster gemeinsamer Nenner" meinte ich genau das, erprobte Standards, die auf allen moeglichen Architekturen, Systemen und Konfigurationen stabil laufen muessen. Hier liegen wir also nicht sehr weit auseinander. Von Developern wie Andrew Morton und Con Kolivas erwarte ich uebrigens _absolut_ dass sie mit derselben Sorgfalt arbeiten, die auch fuer Mainline Sachen erwartet wird. (Nicht umsonst kommen die meisten Sachen aus diesen Trees frueher oder spaeter auch in Vanilla.) Die meisten Interactivity und Scheduler Sachen kamen z.B. direkt aus dem -ck Tree in 2.6.Die Vanilla Kernel sind auch ganz und gar nicht "der kleinste gemeinsame Nenner" sondern es sind halt die offiziellen Kernel und in diesen müssen einfach bestimmte Standards eingehalten werden, was die Erprobung und die Qualität des Codes angeht. Diese werden von den meisten Patches einfach nicht erfüllt: die separaten Patches sind normalerweise sozusagen die Brutstätten neuer Ideen. Dort wird herumprobiert, gebastelt und getestet ohne dass man sich die teilweise sehr strengen Regeln des Vanilla Kernel auferlegen muss. In Patches kann man Hacks, Tweaks und Experimente machen. Dass diese Kernel dennoch oftmals stabil laufen, ist eher ein Zeichen für die allgemein hohe Codequalität in diesem Bereich. Der eigentliche Orientierungspunkt für die periphäre Kernelentwicklung sind die Patches und nicht der Vanilla Kernel. Diese zeigen nämlich, was "in der Mache" ist, während der Mainline (Vanilla) Kernel nur die Rosinen rauspickt, und dabei sehr konservativ gehalten ist.
Du hast natuerlich Recht, dass der -ck sehr experimentell ist, reiserfs4 [1] benutze ich auch noch nicht, z.B., auf einer Produktionsmaschine wuerde ich das auch vorerst nicht machen. (Obwohl ich zugegebenermassen damit spiele es mal auszuprobieren. Die groessten Vorteile haette man wohl mit reiser4 als / - fs, und das mache ich sicherlich nicht auf einem System was ich im Moment lieber nicht neuinstallieren.)Gerade auf einem Desktop Produktionssystem würde ich eher Abstand vom ck Patchset halten, da dieser teilweise doch sehr experimentell ist. ReiserFS4 würde ich noch keine wichtigen Daten für die tägliche Arbeit anvertrauen, auch wenn NameSys bisher exzellente Arbeit geleistet hat, was die Codequalität angeht. Auch die Scheduler Patches sind aus einem einfachen Grund nicht in Mainline enthalten: sie sind sehr speziell, d.h. sie funktionieren bei bestimmten Workloads sehr gut, während sie bei anderen übel degradieren. Wenn man diese Workloads vermeiden kann, sind sie natürlich ein willkommener Bonus. Auf der anderen Seite: Ich kann mit dem Vanilla 2.6.4 der hier läuft, während eines Kernel-Compiles und während gleichzeitig Dateien von meiner externen USB2 Platte auf die Systemplatte kopiert werden problemlos MP3 hören, ohne dass es aussetzt...
), war das Auslagerungsverhalten wesentlich schlechter, wenn ich nach ein paar Stunden idle z.B. einem Mozilla von einem anderen Virtual Desktop aktiviert habe, musste das erstmal aus dem Swap gelesen werden, obwohl genug RAM da war. Als ich gestern mein System prelinkte, habe ich davon kaum was gemerkt, bis auf die Tatsache, dass Diskreads leicht langsamer waren, auch das war beim Vanilla lang nicht so angenehm (obwohl traumhaft im Vergleich mit 2.4).Andererseits hat man im Idealfall sowieso mehrere Kernels installiert, und kann immer auf einen stabilen zurueckfallen, wenn man Probleme bemerkt. Wenn man einen Stapel kaputte libs hat, oder gar der Desktop komplett b0rken ist, ist das wesentlich aufwendiger als eben zu rebooten. (Probleme mit dem Filesystem sind natuerlich was anderes ...)Ich habe nichts dagegen Bleeding Edge zu sein... Ich habe monatelang KDE CVS benutzt, ich verwende seit Jahren SID, aber was den Kernel angeht bin ich dann eher konservativ: Da gehe ich nur so weit, wie ich gehen muss... Wenn der Kernel Macken hat, kann die ganze Kiste unbrauchbar sein. Wenn's im Userland hakt funktioniert halt eine Anwendung nicht. Schlimmstenfalls funktioniert eine Lib nicht, und alle Anwendungen, die darauf basieren sind unbrauchbar.
Klar, nichts geht ueber eine gut gefuehrte Diskussion, und hier gibt's (imho) eh viel zu wenig Leute die sich mal ein paar Minuten Zeit nehmen fuer eine Reaktion. Zum Thema rant las ich gestern noch eine sehr nette Diskussion, ist zwar in diesem Zusammenhang vollkommen offtopic (tm), aber das Lesen hat trotzdem sehr viel Spass gemacht, auch wegen des "historischen Hintergrundes", check [2]Umpf... Ist ganz schön lang geworden
Ja, das ist genau der Punkt, der verhindert dass man sich in die Haaere bekommen sollte. Schoen, dass wir die Wahl haben.Aber das kann ja zum Glück jeder für sich selbst entscheiden.
Das würde ich auch zugernepdreker hat geschrieben: Ich kann mit dem Vanilla 2.6.4 der hier läuft, während eines Kernel-Compiles und während gleichzeitig Dateien von meiner externen USB2 Platte auf die Systemplatte kopiert werden problemlos MP3 hören, ohne dass es aussetzt
Warum sollte er? Der Kernel ist dafür da, die Hardware an die Programme zu verteilen. Wenn ein Programm volle Last zieht, woher soll die CPU wissen, ob das ein Bug , oder gewollt ist? Der Kernel verhindert aber, dass ein solches Programm die ganze Kiste killt.g-henna hat geschrieben:Obwohl ich auch schon als User Prozesse hatte, die durchgedreht sind und dann die ganze Zeit bei 95% CPU-Last rumhingen. Warum verhindert denn der Kernel sowas nicht? War das nur früher so oder war das überhaupt nie so?
