So wie ich das verstanden habe, sind die Kernel mit nur drei Zahlen (2.6.10, 2.6.11) "halb"-stabile Kernel, die durch die Kernel mit vier Zahlen (2.6.8.1, 2.6.11.2) stabilisiert werden sollen. Unstabil (im ursprünglichen Sinne) sind dann wohl eher die Patchreihen (mm) und RC-Kernel. So ganz steig ich da allerdings auch noch nicht durch. Vor allem nicht, wie schnell man auf eine neue Version (mit drei Ziffern) umsteigen sollte, wenn sie erscheint (vor allem wegen Sicherheitsfixes).
Die unstable Kernel sind die mit -RC und die mit -mm haben momentan die Aufgabe der alten 2.3er und 2.5er Reihe um komplett neue Funktionen zu testen bis irgendwann mal eine echte 2.7er Reihe gestartet wird.
Stabil ist es offiziell ab 2.6.X und im Idealfall kommt kein 2.6.X.1 mehr. Falls doch was schief geht und wirklich ein schwere Fehler drin sein sollte kommen noch die 2.6.X.Y. Für Server und andere Kritische Systeme sollte man wie immer nach dem erscheinen des neuen Kernels ein oder zwei Wochen abwarten um sicher zu gehen das keine Fehler im Kernel sind oder diese mit einem 2.6.X.Y behoben wurden. Wer wirklich sicher gehen will sollte den Kernel seiner Distribution nehmen, da diese meistens nur kleinere Sicherheitsupdates bekommen und daher im Laufe der Zeit durch die kleinen Änderungen recht sicher und stabil werden.
2.6.X ist stable 2.6.X.y ist testing und 2.6.X.Y-[rc,mc] ist unstable
Und bei kritischen Fehlern wird eine 2.6.X.1 rausgebracht was nichts mit 2.6.X.y zu tun hat. Oder wie? Das würde ja heißen 2.6.9 wäre stable. Würde ich für ein Gerücht halten.
Die Ungerade = Unstable Regel trift nur auf die 2. stelle zu 2.5.x ist unstable, 2.6.x ist stable. Das einzige was geändert wurde ist das falls kritische Fehler in einem stable Kernel 2.6.x gefunden werden kleine updates in form von 2.6.x.y rauskommen.
So wie ich die Meldung verstanden habe, soll es in Zukunft heißen:
2.6.n ist stabil 2.6.n.[1..n] ist stabil und identisch im Funktionsumfang, es sind aber ernste Fehler berichtigt. 2.6.n+1 ist stabil, enthält aber gegenüber 2.6.n auch unwichtige Fehlerberichtigungen, Schönheitsreparaturen und Funktionsänderungen.
Hintergrund dürfte wohl vor allem sein, dass man 2.6.n.m-Kernel ohne langes Testen einspielen können soll. Wichtig vor allem für Server. 2.6.n+1-Kernel sollen vor dem Einspielen in den Arbeitsbetrieb sorgfältig auf reibungslose Zusammenarbeit mit dem Rest des Systems getestet werden.
Die Firma Mandrake arbeitet schon einige Zeit nach diesem Muster. (Bei anderen wird es auch so sein, nur da fehlt mir die Kenntnis.)
Also bei mir ist 2.6.x genauso wie 2.5 unstable. Dagegen sind die 2.3'er Reihe und die 2.1'er Reihe richtig stabil. So oft wie mit meinen Versuchen mit 2.6 bei einem Rechner mußte ich alle meine Rechner zusammen noch nicht neu booten! Mal iss es ne Ops Meldung, mal friert ein Subsystem, mal der ganze Kernel ein. Und das zieht sich durch die gesammte 2.6'er-Serie durch. Mir scheint es, daß 2.6 nur deswegen so nummeriert wurde, weil 2.5 schon zu lange unstable war und mal wieder nen (angeblicher) stable-Zweig hermußte.
Das heißt jetzt also, man patcht seinen Kernel mit den aktuellen Stable-Patches (4-stellige Nummer), patcht das Teil nach einer Weile wieder zum 3-stelligen zurück, patcht auf die neue 3-stellige Version, macht danach wieder einen stabilen 4-stelligen draus.
Einfach: Grundsätzlich ist ein dreistelliger 2.6er Kernel stabil. Sollte es dabei Probleme geben, gibt es Patches, die daraus einen vierstelligen Kernel machen. Diese Patches ändern keinerlei Funktionalität, sondern sind ausschließlich Fehlerbehebungen und machen dadurch den Kernel stabiler. Sprich: 2.6.11.2 ist besser/sicherer/stabiler als 2.6.11. 2.6.12 wird aktueller sein als 2.6.11 und auch als "stabil" gelten. _Sollten_ Probleme auftauchen, dann (und nur dann) gibt es eine 2.6.12.x-Reihe.
Damit wir uns richtig verstehen: Ich finde die Idee der Stabilisierungen gut und hoffe, es wird reger Gebrauch davon gemacht. Die Meldungen über Sicherheitslecks und Fehler im Kernel, die Verweise auf Distributionskernel und nicht zuletzt einige Abstürze (wovon aber auch einige auf schlechten RAM zurückzuführen waren) gefielen mir gar nicht.
Nun hat man nur das Problem, daß man bei einem Update von Kernel 2.6.x.y auf Kernel 2.6.x+1 erstmal y Mini-Patches zurückdrehen muß, da der richtige Patch sicher von 2.6.x auf 2.6.x+1 updatet. Tust du das nicht, läuft der neue Patch nicht sauber durch. Spätestens beim Patch auf 2.6.x+2 geht dann wohl nichts mehr.
Hab wenig Zeit, muß für ne Prüfung lernen (sonst würd ich evtl. einen Kurztip schreiben). Daher nur: Schau mal hier.
Du solltest noch wissen, daß Patches mit diff hergestellt werden (wohl (fast?) immer mit der Option -C 1 für das Kontext-Format: Eine Zeile davor und danach werden mitgespeichert - korrigiert mich, wenn dies falsch ist). patch kann nun die beiden Versionen mit dem *.diff (oder auch umbenannt in *.patch) ineinander überführen.
CVS und Konsorten setzen auf diff und patch auf.
Außerdem sehe ich gerade, daß ich mir mal das Script /usr/src/linux/scripts/patch-kernel ansehen muß.
Läßt sich übrigends auch alles einfach automatisieren, z.B. mit happypatching.sh :
#!/bin/bash # happypatching v0.1 # im aktuellen Verzeichnis stehen der erste Kernel und die Patches # sollte mit root-Rechten aufgerufen werden # der Linux-Kernel muß in /usr/src/linux liegen # Irgendwas wichtiges haendisch geaendert? Ist danach alles weg PWDIR=`pwd` BASISNUMMER="3" # Mein erster 2.6er ist der linux-2.6.3.tar.bz2 cd /usr/src rm -rf "linux-2.6.$BASISNUMMER" # Der Plan ist, alles neu zu erzeugen # Einstellungen sollten aber erhalten bleiben echo Kernel auspacken tar xjf "$PWDIR/linux-2.6.$BASISNUMMER.tar.bz2" cp linux/.config "linux-2.6.$BASISNUMMER/" # Hoffe, es reicht, die .config zu sichern? rm -rf linux mv linux-2.6.$BASISNUMMER linux i=$((BASISNUMMER+1)) cd linux while [ -e "$PWDIR/patch-2.6.$i.bz2" ] ; do echo patch 2.6.$i bzip2 -dc "$PWDIR/patch-2.6.$i.bz2" | patch -p1 -s i=$(($i+1)) done i=$(($i-1)) j=1 while [ -e "$PWDIR/patch-2.6.$i.$j.bz2" ] ; do echo patch 2.6.$i.$j bzip2 -dc "$PWDIR/patch-2.6.$i.$j.bz2" | patch -p1 -s j=$(($j+1)) done cd "$PWDIR" # viel Spass bei einem kontrollierendem make xconfig
Von BufferOverflow am Do, 10. März 2005 um 20:27 #
Also im Moment ist das ein ganz schoenes Hin und Her...
Was ist an der 4. Nummer besser? Wenn man die 3. Zahl einfach inkrementiert,reicht das doch auch, wozu also eine 4. Zahl einfuehren?
Was ist aus der Idee geworden, den 2.6er grundsaetzlich fuer neue Features zu oeffnen und die Distributionen die Arbeit an der Stabilitaet zu ueberlassen?
Die Idee kam nicht so gut bei den Nutzern an. Die neue Vorgehensweise soll einen Kompromiss zwischen hoher Entwicklungsgeschwindigkeit und Stabilität darstellen.
Es wird ja, waehrend der 2.6.11er der aktuelle Kernel ist, weiter an Features und anderen Neuigkeiten gearbeitet, dadurch wird der Kernel ja vom Zeitpunkt wo er 2.6.11 war wieder instabiler (2.6.12.rc1 ist instabiler als 2.6.11). Wenn jemand aber einen kritischen Fehler findet, der in den Release-Kandidaten nicht entdeckt wurde, sollte der ja behoben werden, und zwar nicht erst im 2.6.12er (weil der hat warscheinlich wieder andere Fehler) sondern bereits im 2.6.11er, und das generiert den 2.6.11.1er Kernel. Das fuehrt dazu, dass die Fehler die in einem stable Kernel immer noch drinnen sind mit der Zeit weniger werden, nicht konstant bleiben. Das Patchen durch Distributionen hat den Nachteil, dass die Kernelentwickler leichter den Blickwinkel "wir muessen ein Produkt herstellen" zu "wir brauchen eh nur einen Prototypen bauen" aendern wuerden, was wiederum zu noch groesseren Unterschieden zwischen den Distributionen fuehren wuerde. Zunehmende Inkompatibilitaeten wuenscht aber niemand, nicht einmal die Distributoren selbst (UNIX war ein warnendes Beispiel).
Endlich funktionieren meine USB-Geräte einwandfrei doch nun gibt es ein neues Problem :-( Seit ich den 2.6.11er installiert habe ist die NFS-Performance zum verrecken schlecht. Wenige 100kB/s über ein 100MBit-Netz. Mit den Kernelversionen 2.6.10 und älter liegt die Übertragungsrate bei über 10MB/s. Hat vielleicht noch jemand ähnliche Probleme?
Oder heißt das stable ists ab 2.6.X.2 oder so?
Allo
Sebastian
Stabil ist es offiziell ab 2.6.X und im Idealfall kommt kein 2.6.X.1 mehr. Falls doch was schief geht und wirklich ein schwere Fehler drin sein sollte kommen noch die 2.6.X.Y. Für Server und andere Kritische Systeme sollte man wie immer nach dem erscheinen des neuen Kernels ein oder zwei Wochen abwarten um sicher zu gehen das keine Fehler im Kernel sind oder diese mit einem 2.6.X.Y behoben wurden.
Wer wirklich sicher gehen will sollte den Kernel seiner Distribution nehmen, da diese meistens nur kleinere Sicherheitsupdates bekommen und daher im Laufe der Zeit durch die kleinen Änderungen recht sicher und stabil werden.
2.6.X ist stable
2.6.X.y ist testing
und 2.6.X.Y-[rc,mc] ist unstable
Und bei kritischen Fehlern wird eine 2.6.X.1 rausgebracht was nichts mit 2.6.X.y zu tun hat. Oder wie?
Das würde ja heißen 2.6.9 wäre stable. Würde ich für ein Gerücht halten.
Das einzige was geändert wurde ist das falls kritische Fehler in einem stable Kernel 2.6.x gefunden werden kleine updates in form von 2.6.x.y rauskommen.
2.4.X ist stable
2.6.X[.Z] so das es ein Y gibt das ein kernel 2.6.Y mit Y>X existiert, ist testing
2.6.X und 2.6.X.Y ist unstable
*g*
2.6.n ist stabil
2.6.n.[1..n] ist stabil und identisch im Funktionsumfang, es sind aber ernste Fehler berichtigt.
2.6.n+1 ist stabil, enthält aber gegenüber 2.6.n auch unwichtige Fehlerberichtigungen, Schönheitsreparaturen und Funktionsänderungen.
Hintergrund dürfte wohl vor allem sein, dass man 2.6.n.m-Kernel ohne langes Testen einspielen können soll. Wichtig vor allem für Server.
2.6.n+1-Kernel sollen vor dem Einspielen in den Arbeitsbetrieb sorgfältig auf reibungslose Zusammenarbeit mit dem Rest des Systems getestet werden.
Die Firma Mandrake arbeitet schon einige Zeit nach diesem Muster. (Bei anderen wird es auch so sein, nur da fehlt mir die Kenntnis.)
Klingt doch ganz einfach und logisch.
Gruß Falk
Einfach:
Grundsätzlich ist ein dreistelliger 2.6er Kernel stabil. Sollte es dabei Probleme geben, gibt es Patches, die daraus einen vierstelligen Kernel machen. Diese Patches ändern keinerlei Funktionalität, sondern sind ausschließlich Fehlerbehebungen und machen dadurch den Kernel stabiler. Sprich: 2.6.11.2 ist besser/sicherer/stabiler als 2.6.11. 2.6.12 wird aktueller sein als 2.6.11 und auch als "stabil" gelten. _Sollten_ Probleme auftauchen, dann (und nur dann) gibt es eine 2.6.12.x-Reihe.
Grüße,
matthes
Ich finde die Idee der Stabilisierungen gut und hoffe, es wird reger Gebrauch davon gemacht. Die Meldungen über Sicherheitslecks und Fehler im Kernel, die Verweise auf Distributionskernel und nicht zuletzt einige Abstürze (wovon aber auch einige auf schlechten RAM zurückzuführen waren) gefielen mir gar nicht.
Nun hat man nur das Problem, daß man bei einem Update von Kernel 2.6.x.y auf Kernel 2.6.x+1 erstmal y Mini-Patches zurückdrehen muß, da der richtige Patch sicher von 2.6.x auf 2.6.x+1 updatet. Tust du das nicht, läuft der neue Patch nicht sauber durch. Spätestens beim Patch auf 2.6.x+2 geht dann wohl nichts mehr.
Sind das 'dumme' textuelle ersetzungen, oder kann man die intelligent
konfigurieren; z.B. irgendwie:
"Suche die Konfigurationsmarke für das subsystem blablabla und
alle beeinflussenden Patchmarken und ersetze sie durch ..."
Falls nicht, wäre das doch sicher ne gute Idee... so ne art Versionskontrolle.
Daher nur:
Schau mal hier.
Du solltest noch wissen, daß Patches mit diff hergestellt werden (wohl (fast?) immer mit der Option -C 1 für das Kontext-Format: Eine Zeile davor und danach werden mitgespeichert - korrigiert mich, wenn dies falsch ist). patch kann nun die beiden Versionen mit dem *.diff (oder auch umbenannt in *.patch) ineinander überführen.
CVS und Konsorten setzen auf diff und patch auf.
Außerdem sehe ich gerade, daß ich mir mal das Script /usr/src/linux/scripts/patch-kernel ansehen muß.
Läßt sich übrigends auch alles einfach automatisieren, z.B. mit happypatching.sh :
#!/bin/bash
# happypatching v0.1
# im aktuellen Verzeichnis stehen der erste Kernel und die Patches
# sollte mit root-Rechten aufgerufen werden
# der Linux-Kernel muß in /usr/src/linux liegen
# Irgendwas wichtiges haendisch geaendert? Ist danach alles weg
PWDIR=`pwd`
BASISNUMMER="3"
# Mein erster 2.6er ist der linux-2.6.3.tar.bz2
cd /usr/src
rm -rf "linux-2.6.$BASISNUMMER"
# Der Plan ist, alles neu zu erzeugen
# Einstellungen sollten aber erhalten bleiben
echo Kernel auspacken
tar xjf "$PWDIR/linux-2.6.$BASISNUMMER.tar.bz2"
cp linux/.config "linux-2.6.$BASISNUMMER/"
# Hoffe, es reicht, die .config zu sichern?
rm -rf linux
mv linux-2.6.$BASISNUMMER linux
i=$((BASISNUMMER+1))
cd linux
while [ -e "$PWDIR/patch-2.6.$i.bz2" ] ; do
echo patch 2.6.$i
bzip2 -dc "$PWDIR/patch-2.6.$i.bz2" | patch -p1 -s
i=$(($i+1))
done
i=$(($i-1))
j=1
while [ -e "$PWDIR/patch-2.6.$i.$j.bz2" ] ; do
echo patch 2.6.$i.$j
bzip2 -dc "$PWDIR/patch-2.6.$i.$j.bz2" | patch -p1 -s
j=$(($j+1))
done
cd "$PWDIR"
# viel Spass bei einem kontrollierendem make xconfig
while [ -e "$PWDIR/patch-2.6.$i.$j.bz2" ] ; do
j=$(($j+1))
done
j=$(($j-1))
echo patch 2.6.$i.$j
bzip2 -dc "$PWDIR/patch-2.6.$i.$j.bz2" | patch -p1 -s
cd "$PWDIR"
Was ist an der 4. Nummer besser? Wenn man die 3. Zahl einfach inkrementiert,reicht das doch auch, wozu also eine 4. Zahl einfuehren?
Was ist aus der Idee geworden, den 2.6er grundsaetzlich fuer neue Features zu oeffnen und die Distributionen die Arbeit an der Stabilitaet zu ueberlassen?
mfG
Die neue Vorgehensweise soll einen Kompromiss zwischen hoher Entwicklungsgeschwindigkeit und Stabilität darstellen.
Dann hätten wir nach all den Sicherheitslücken und "kleinen" Bugs bereits nen 2.6.167.
Wenn jemand aber einen kritischen Fehler findet, der in den Release-Kandidaten nicht entdeckt wurde, sollte der ja behoben werden, und zwar nicht erst im 2.6.12er (weil der hat warscheinlich wieder andere Fehler) sondern bereits im 2.6.11er, und das generiert den 2.6.11.1er Kernel. Das fuehrt dazu, dass die Fehler die in einem stable Kernel immer noch drinnen sind mit der Zeit weniger werden, nicht konstant bleiben.
Das Patchen durch Distributionen hat den Nachteil, dass die Kernelentwickler leichter den Blickwinkel "wir muessen ein Produkt herstellen" zu "wir brauchen eh nur einen Prototypen bauen" aendern wuerden, was wiederum zu noch groesseren Unterschieden zwischen den Distributionen fuehren wuerde. Zunehmende Inkompatibilitaeten wuenscht aber niemand, nicht einmal die Distributoren selbst (UNIX war ein warnendes Beispiel).
Seit ich den 2.6.11er installiert habe ist die NFS-Performance zum verrecken schlecht. Wenige 100kB/s über ein 100MBit-Netz. Mit den Kernelversionen 2.6.10 und älter liegt die Übertragungsrate bei über 10MB/s. Hat vielleicht noch jemand ähnliche Probleme?