News Linux-Kernel 3.0 veröffentlicht

[TheK]

Fangen die auch schon mit den Versionssprüngen an, ist ja wie ne Seuche in letzter Zeit.

Seit inzwischen 8 Jahren hieß das Ding stets 2.6.X. Diese Nummerierung soll jetzt – passend zum dritten Jahrzehnt der Linux-Geschichte – mal geändert werden. Darum eben jetzt 3.X, welches voraussichtlich irgendwann 2021 mit einem 3.40 sein Ende finden wird und dann als 4.X weiter laufen wird. Also alles noch lange hin.

 

[Eisenfaust]

Also bleiben viele Altlasten aus den Anfangstagen erhalten? Klingt für mich nicht gerade fortschrittlich. Immerhin haben sie den Mut, mal was "Finales" zu präsentieren. Die Angst ist aber wohl berechtigt. Das soll so fertig sein? Haha!

Welche "Altlasten" wären das denn, zum Beispiel?

 

[Wolfsrabe]

Fangen die auch schon mit den Versionssprüngen an, ist ja wie ne Seuche in letzter Zeit.

Oh ja! Der Kernel ist gerade mal zwanzig Jahre alt, und schon trägt er die Versionsnummer 3.0!!! Das ist wirklich eine Frechheit! Wo soll das bloß hinführen?! Wenn dieses wahnwitzige Versionssprungtempo beibehalten wird, würde im Jahre 2031 bereits Version 6.0 erscheinen! Das geht wirklich zu weit...

Wenn Du Ironie findest, darfst du die behalten.

 

[masslet]

Neue Realtek Treiber? Ob dann bei Realtek Gigabit LAN auch mal mehr als 4-5MB/s rausspringt? Bin ich ja mal gespannt...

 

[FreddyMercury]

Was feur ein Problem hast du mit den Realtek treibern? Bei mir geht im 1gbit netzwerk knapp 60 - 80MB/s raus.
Hab den Kernel up and running. Hab sofern keine einzigen Probleme gemerkt.

 

[masslet]

War bei mir halt nicht so, nicht mal Fast Ethernet wurde erreicht...

Hab jetzt eine Intel Gigabit LAN PCIe Karte drin, die leistet was sie verspricht.

 

[guillome]

Hatte bis vor kurzem (vor Linus Ankündigung) nicht gedacht das ich 3.0 erlebe

 

[kayron]

der artikel sagt nicht, dass der "neue kernel" eine ganz normale aktualisierung ist. an dem 3.0-kernel ist NICHTS besonders außer der versionsnummer.... die news hätte über die versionsnummer und nicht über die änderungen im kernel sein sollen, denn die sind alles andere als besonders.

 

[Mike-o2]

Oh darauf freue ich mich. Dann werde ich meine Ubuntu LTS Version ersetzen.
Ich frage mich wie lange es dauert bis Android den neuen Kernel bekommt.

 

[Sensei21]

schon geschehen bzw. in Entwicklung:

kernel/linux-2.6.git / summary

 

[1st_john]

es war ja früher so das eine ungerade 2. Zahl eine entwicklerversion markierte.
darum gab es 2.2.x, 2.4.x und 2.6.x (Schema: a.b.c)

2.3.x und 2.5.x gab es ebenfalls, die waren jedoch entwicklerkernel, welche nie offiziell erschienen
bis version 2.6.8 war die versiosnummer dreistellig. dann schlich sich ein schwerer bug ins release ein, und es gab eine gefixte version 2.6.8.1 (Schema: a.b.c.d)


das übernahm man dann als offizielles schema, um die geupdateten kernel einer version unterscheiden zu können

seit 2004 entwickelt man direkt am kernel, die 2. Zahl war seither unnötig, weil es nichts mehr zu unterscheiden gab !


Nun geht der Kernel ins das 3. Jahrzehnt seiner entwicklung, linus entschied sich daher, das der kernel sich die 3 "verdient" habe (bzw. es war ein vorschlag von ihrgendwem auf der mailingliste).

und wenn man grade bei den änderungen ist, dann kann man diese 2. zahl, die man seit 7 jahren grundlos mit rumschleppt, auch rausschleißen
so entsteht nun 3.0.0 (Schema: a.c.d)

Legende:
a: sehr große, grundlegende Änderung, zb ein 3. Jahrzehnt, in das man geht

b: Majorrelease bzw. entwicklerkernel hatte immer ungerade zahl

c: die eigendliche Version, zuletzt 39, nun wohl 0

d: da man ab 2.6.11 (2005) auch für alte kernel regelmässig (sicherheits-)updates herausbrachte konnte man hier die unterschiedlichen kernel einer version unterscheiden.

edit: gute grafik http://upload.wikimedia.org/wikipedia/de/timeline/c1d632721b176ead0b298902978b91aa.png

 

[Photon]

Ist schon irgendeine Lösung bezüglich des Problems mit dem ASPM von PCIe-Geräten in Sicht?
Der erhöhte Stromverbrauch ist ja nun wirklich nicht mehr feierlich.

Bei Webupd8 gibt es einen Workaround: http://www.webupd8.org/2011/06/linux-kernel-power-issue-fix.html Ein Fix würde einige Geräte mit fehlerhaftem Bios "aussperren", man hat sich hier für Stabilität auf Kosten der Leistung bzw. des Energieverbrauchs entschieden.

 

[Zedar]

Also bleiben viele Altlasten aus den Anfangstagen erhalten?

Als da wären?

Klingt für mich nicht gerade fortschrittlich. Immerhin haben sie den Mut, mal was "Finales" zu präsentieren.

"Finales" und OpenSource passen nicht zusammen. Linux ist im stetigen Wandel begriffen und das ist auch gut denn wo wäre dann der Fortschritt? Wer das nicht versteht(en) (will?) muss ja Linux nicht benutzen sondern kann schön bei Windows bleiben wo ja alles so Toll ist, gelle?

Genieße doch lieber die Vorzüge des Wählens. Für mich wäre es unbefriedigend auf meinem Heim PC ein OS nutzen zu müssen das Jahre auf dem Buckel hat. Oder geschweige denn nur eins benutzen zu können mangels Alternative.

Das soll so fertig sein? Haha!

Nein, das ist nicht fertig und das ist auch gut so und ein Vorteil von OpenSource. Wenn man sich mal die Mühe macht und sich tatsächlich ganz Objektiv mal vor Augen hält was hier in den letzten Jahren verbessert wurde und im Gegensatz zu anderen OS keine Milliardenschwere Konzerne hinter der Entwicklung stehen würde ich sagen das OpenSource recht gut funktioniert.

Gut, Canonical und Novell buttern kräftig in ihre Projekte und ganz von Luft und Liebe ensteht auch keine gute Software aber ich sehe keinen Grund hier so unmotiviert Halbsätze loszulassen und - wie üblich - Argumente schuldig zu bleiben.

 

[PrometPheus]

Wow, 2 Stunden pro Server zum Kompilieren hat es gebraucht Oo, um 4:00Uhr war ich fertig damit.

 

[Sensei21]

make -jn

(n == die anzahl deiner CPU-Kerne + 1, damit sollte es schneller gehen)


und um beim Thema zu bleiben:

3.0.0 fühlt sich um einiges stabiler als 2.6.39 an

mit 2.6.39 hatte ich dutzende hardlocks mit dem offenen radeon treiber, die jetzt wohl der Vergangenheit angehören (kann natürlich auch an der hardened toolchain liegen, die ich momentan deaktiviert hab)


insgesamt fühlt sich das system weniger anfälliger für Leistungseinbrüche an, z.B. beim synchronisieren von großen Datenmengen (mehrere hundert GiB oder TiB) via rsync

das rcu boosting trägt hierbei sicher auch seinen Teil dazu bei



geht bei euch übrigens zcache ?

zcache, zram und cleancache sind reinkompiliert, dennoch seh ich nix in dmesg und den üblichen Pfaden zu zcache

 

[Kampfkeks]

@Talian: Besonders performant sind die Server dann anscheinend aber nicht. Was jetzt aber nicht negativ gemeint ist, schließlich können alte Kisten durchaus noch für diverse Aufgaben eingesetzt werden. Bei mir auf dem Notebook (Core2Duo 2,8GHz / Gentoo) hat es ca. 9 Minuten gedauert. Es ist allerdings auch nur das aktiviert was an Hardware im Notebook ist, und via USB hin und wieder angeschlossen wird (DVB-T, ...). Auf deinem Server dürftest du wahrscheinlich noch etwas weniger an Hardware haben.

 

[PrometPheus]

@Talian: Besonders performant sind die Server dann anscheinend aber nicht. Was jetzt aber nicht negativ gemeint ist, schließlich können alte Kisten durchaus noch für diverse Aufgaben eingesetzt werden. Bei mir auf dem Notebook (Core2Duo 2,8GHz / Gentoo) hat es ca. 9 Minuten gedauert. Es ist allerdings auch nur das aktiviert was an Hardware im Notebook ist, und via USB hin und wieder angeschlossen wird (DVB-T, ...). Auf deinem Server dürftest du wahrscheinlich noch etwas weniger an Hardware haben.

Server 1:
Komponenten
RAM 4x 8 GB DDR3-RAM ECC
HDD 2x 1500 GB SATA
Barebone 1x Fujitsu PRIMERGY RX100 S6
CPU 1x Intel Xeon X3440 Quadcore

Server 2:
Intel Core i7-920/950
6 GB DDR3 RAM
2 x 500 GB SATA II HDD

Ich denke ich hätte doch mit -jn kompilieren sollen. Beim nächsten mal merk ich es mir ^^

Was mir auch noch aufgefallen ist, das ich beim installieren keine Fehlermeldung mehr bekomme:

W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module r8169

das ist gänzlich verschwunden.

 

[Kampfkeks]

Ja, da steckt schon ordentlich Leistung dahinter. Mit der Ausnutzung aller Cores sollte das deutlich schneller gehen. Allerdings sind 2 Stunden doch schon viel, selbst wenn nichts parallel lief.

Ich habe gerade eben zum Testen bei mir auf dem Webserver den 2.6.39er kompiliert (ich will da bei der stabilen Version bleiben). In dem Server sind zwei Opteron 2352 drinnen. Also insgesamt 8 Cores á 2.1GHz mit 24GB Ram. Ohne "-jn", also nur mit einem job, hat es 25m 40s gedauert. Und einer deiner Xeon-Cores und auch der Core i7 sollten da auch noch mehr Leistung haben.

Hast du den Kernel selbst konfiguriert, und benötigst auch alles was aktiviert ist? Eventuell kannst du ja noch einiges deaktivieren, was künftige updates nochmal deutlich beschleunigen sollte. Ist natürlich auch eine Frage, wie stark deine Server zu dem Zeitpunkt anderweitig ausgelastet waren.

 

[PrometPheus]

Hast du den Kernel selbst konfiguriert, und benötigst auch alles was aktiviert ist? Eventuell kannst du ja noch einiges deaktivieren, was künftige updates nochmal deutlich beschleunigen sollte. Ist natürlich auch eine Frage, wie stark deine Server zu dem Zeitpunkt anderweitig ausgelastet waren.

Ich habe den Kernel per cp -vi /boot/config-`uname -r` .config übernommen, also nichts verändert, außer den Prozessortypen entsprechend eingestellt. Aber was mein Vorredner schon sagte, es läuft wirklich flüssiger und stabiler an als zuvor. Htop zeigt kaum noch Ressourcenverschwendung an. Sound und Diverse könnte ich eigentlich deaktivieren.

 

[enteon]

hoffe auch, das die Treiber für ATI-Karten endlich aufhört bei mir Grafikfehler zu verursachen.

Schon mal eine aktuelle git-version gebastelt? Hatte ich früher mal automatisiert, für debian lenny, mag sich also was an der vorgehensweise geändert haben ^^

#!/bin/sh
cd /tmp
git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
cd xf86-video-ati/
./autogen.sh --prefix=/usr
make
rm /home/enteon/Misc/drivers/ati/old/*.deb
mv /home/enteon/Misc/drivers/ati/*.deb /home/enteon/Misc/drivers/ati/old/
echo 'ati driver built from git on debian lenny' > description-pak
sudo sh -c "apt-get remove xf86-video-ati ; checkinstall -D --nodoc --pkgversion=`eval date +%Y.%m.%d.%H%M` --pkgname='xf86-video-ati' --pakdir=/home/enteon/Misc/drivers/ati/ make install ; rm -rf /tmp/xf86-video-ati ; chown enteon:enteon /home/enteon/Misc/drivers/ati/*.deb"

wenn die version nicht tut tut die im kernel schon gar nicht.

Ergänzung (24. Juli 2011)

mit 2.6.39 hatte ich dutzende hardlocks mit dem offenen radeon treiber, die jetzt wohl der Vergangenheit angehören (kann natürlich auch an der hardened toolchain liegen, die ich momentan deaktiviert hab)

2.6.39.3 läuft bei mir auf desktop mit radeon grafik stabil, auch nachdem ich die radeon-karte ausgebaut habe und die onboard radeon nutze.
dafür krieg ich mit dem notebook mit intel beim booten manchmal ein panic, noch vor X.
wir können uns ja künftig zusammentun