Linus Torvalds: Linux 2.6.24-rc7

Kernel

Két hét telt el az -rc6 kiadása óta. Az új, inkrementális patchset elég kicsi - kb. fele akkora mint az rc5-ről rc6-ra váltásnál használatos - de Linus könyörületes és állítja, hogy ez nem annak köszönhető, hogy csaprészegen feküdtek a fejlesztők az ünnepek alatt, hanem annak, hogy a dologok stabilizálódnak. Az új rc-be kizárólag apró, egy-két soros javítások kerültek. Talán a legemlítésreméltóbb a /proc/slabinfo implementálása az "új" SLUB allokátorhoz. A bejelentés itt.

( goodbyte v | 2008. 01. 07., h – 18:55 )

Most bezzeg mélyen hallgatnak arról a bizonyos regressziós listáról... Én nem is adnám ki a véglegest amig ezt 0-ra nem redukálták. Nem értem miért olyan nagy elvárás hogy egy már működő dolog az új verzióban is működjön...
Ha valaki rákérdezne, nincs személyes tapasztalatom, de sok ilyen "működött-azt-most-nem-műxik" dologról olvastam már itt-ott.

"Nem értem miért olyan nagy elvárás hogy egy már működő dolog az új verzióban is működjön..."
...hm ez bennem is megfogalmazódott egy XP-Vista upgrade kapcsán...

Jót tenne egy korrekt minőségbiztosítási rendszer a kernel táján, olyan, amit valóban komolyan is vesz minden fejlesztő. Lehet szidni a kereskedelmi progikat, de van amelyik többek között pont azért jó, mert korrekt QA van mögötte.

Én pl SuSE-val szívtam rengeteget:

7.0: 2.2.16-os kernel - az Inicio SCSI vezérlőt nem szerette, megfagyott az install (hibás kernelmodul 2.2.17-ben javítva)

8.0: a kernelben el volt tolva valami, ezért tönkretette a rendszer az összes audio-cd-t. (nemtom melyik verzióban javították)

A 2.6.20-as verzió előtt (pl. 2.6.18) el volt fuserálva az AMD64 SMP támogatása. Simán kiadták, úgy, hogy nem megy az SMP...

De azért, hogy ne csak a kernelt kritizáljuk: az OpenSuSE projekt pl. simán kiadta a 10.1-es változatot úgy, hogy de facto használhatatlan volt az új csomagkezelő. Csóró kezdő Linuxos megveszi/letölti és mit lát? Hogy nem megy... Remek... Így lehet, sok, főleg kezdő felhasználót szerezni. Micsoda minőségbiztosítás. Utána persze patkolták veszettül, a végére már használható is volt.

Akárki akármit mond, ebben az egyben a kereskedelmi szoftverek vannak jobb helyzetben, illetve lehetnek, ha jól használják a minőségbiztosítási rendszert. Egy nyílt projektnél, pláne, ahol tényleg nincs üzleti kapcsolatban a fejlesztő semmilyen szervezettel, ami összefogja a projektet (alkalmazott, szerzősédes, alvállalkozó, stb.), elég nehéz kiverni az emberekből egy jó kis QA-t.

De az élet más területén is így van, ha egyszer elérsz egy szintet, azt tartani kell, különben k*rv.... óriási kockázata van egy jó kis piacvesztésnek. Az urak a kernel környékén mostanában kicsit lazák. Hiába zseniális koponyák, azért nem ártana némi rend és szervezettség. Ha jól tudom, egyre több a panasz, hogy csak pakolják az új funkciókat a kernelbe, de nincs kellően tesztelve a kód.

Egy szó, mint száz, vérprofi QA kellene a nagyobb linuxos projektek mögé és főleg a kernel köré. Az utóbbival kapcsolatban azért is állok értetlenül, mert elég komoly cégek (pl. IBM, Oracle) delegálnak főállású szakembereket a kernel fejlesztők közé. Ők pedig - főleg az IBM - már hallottak a QA-ról.

( Arbiter | 2008. 01. 07., h – 20:51 )

Tudtam, hogy az IBM fw-vel kapok majd a fejemre, éreztem...))))
Ok, ok ez teljesen igaz, én is szívok velük rengeteget, most pl. egy teljes Bladecentert kell leállítani egy fos fw miatt és persze a zájbíem is csak tippelni tud, hogy mi a baj!! GRRR

Az én cégemnél is sok ilyen "wtf-még soha nem láttam" hiba van és mind kereskedelmi szoftverrel.

Szóval nem védeni akarom én őket, sőt! Ott dupla égés, mert még lóvét is kérnek érte. De attól még egy kis QA jót tenne a Linuxnak. :)

Troutman programozási posztulátumai
-----------------------------------
[...]
2. A program legkártékonyabb hibájára csak akkor derül fény, ha a programot már legalább hat hónapig használták.
[...]

Gilb megbízhatatlansági törvényei
---------------------------------
1. A számítógép megbízhatatlan, de az ember méginkább.
2. Az emberi megbízhatóságra alapozott rendszerek megbizhatatlanok.
3. A felderíthetetlen hibák végtelenül változatosak, szemben a felderíthető hibákkal, amelyeknek száma a dolog természetéből következöen : korlátozott.
4. A megbízhatóság fokozására eszközölt befektetések addig fokozódnak, amíg túl nem haladják a híbák valószínű költségét, illetve amíg valaki el nem éri, hogy a munka is folyjék.

ezért kell használni a stable tree-ket (akkor long term supported) pl a 2.6.16.y és a 2.6.22.y seria-t, a többit meg akkor hadd tolják ezerrel mert egy idő után a fejlesztők is be fognak sokallni és akkor jön a 2.7-es.
Molnár Ingo hozzáállásában van valami pozitívúm, mióta átvette Thomad Gleixnerrel az x86-os arch-ot, azóta Mingo kicsit szigorított a patchek elfogadási feltételein, ez spec a régebbi karbantartóknak nem tetszik, mert, hogy neki van egy saját kódolási formája és abba ne pofázzanak bele... - ez alatt azt akartam csak érteni, hogy Ingo whitespace szintig "ellenőrzi" a beküldött patcheket és ami nem megfelelő azt visszadobja.

linux v2.6.22.14 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.15-pancs1

Ezt kéne tennie minden karbantartónak. Lényegében most akkor valaki elmagyarázná hogy hogy van most a stabil/fejlesztői verzió-jelölés?
Mert régen ugye a páros verzió volt a stabil, a páratlan meg a fejlesztői.
Más. Tud valaki linket, roadmapet a 2.7/2.8 esetleg 3.0 ágra?
Egyáltalán van ilyen "hivatalos" roadmap?

"roadmapet a 2.7/2.8 esetleg 3.0 ágra" -> nincs, nem is lesz, ha csak nem csúszik ki a kezük közül a jelenlegi fa.

mm fa -> az abszolút fejlesztői fa, van hogy le sem lehet fordítani normálisan ...

lényeg alapból:
2.6.x-rcZ -> fejlesztői alias linux-2.6 (linus által karbantartott tree)

2.6.x.y -> átkerül a stable team-hez ezek a stabil kernelek

2.6.16.y -> Adrien Bunk féle hosszan karbantartott fa (jelenleg 2.6.16.57)
2.6.22.y -> Gregh K. Hartmann és Willy Tarreau féle hosszú karbantartású fa (jelenleg 2.6.22.15)

linux v2.6.22.14 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.15-pancs1

Akkor most nincs az a páros/páratlan megkülönböztetés?
Elég rossz hogy nincs egy roadmap... kicsit olyan céltalannak tűnik.. Kinek mi jut eszébe, azt belerakja vagy működik vagy nem. Semmi tudatos vonal amit követni kéne. Linus igazán mondhatná azt hogy márpedig a 2.8 -ra ezt és ezt kéne, a 3.0 ra meg ezt és ezt ... stb. Szerintem rajta kívül más már nem is nagyon látja át ezt az egészet.

a vagy működik vagy nem, annyira nem igaz, de sajnos igaz néha, a mainline kernelbe kerülő kódokat először a főbb karbantartók és/vagy fejlesztők kapják meg, itt nézz körbe: http://git.kernel.org
itt subsysenkén meg lehet találni szinte mindent, ami a kernelben benne van vagy benne lesz.

linux v2.6.22.14 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.15-pancs1