Kilátások a Linux 2.6.19-re, a fejlesztési folyamat finomítása

Kernel

Andrew Morton, a 2.6-os Linux kernel karbantartója, elküldte az LKML-re a jelenlegi patch várólistáját. A listán a beolvasztásra váró foltok szerepelnek. A fejlesztő magyarázatokat mellékelt az egyes patchek mellé, amelyekből kiderül, hogy mely patch-ek kerülnek várhatóan beolvasztásra a közeljövőben, és melyek azok, amelyek várhatóan elvetésre kerülnek. A levélben levő megjegyzésekből az is kiderül, hogy Reiser 4 filerendszer nem fog megjelenni a 2.6.19-es kernelben. Ennek az az oka, hogy még mindig problémákat okozna a beolvasztása. A megjelenése a 2.6.20-ban sokkal valószínűbb.
Andrew levele egy hosszabb vitát indított a jelenlegi kernelfejlesztési folyamatról. Andrew aggodalmát fejezte ki jelenlegi helyzet miatt.

Elmondta, hogy az emberek jelenleg úgy kezelik a kernel stabilizálására kijelölt szakaszokat, mint nagyszerű csendes időszakokat arra, hogy előreszaladjanak, és új funkciókat, szolgáltatásokat fejlesszenek a kernelhez ahelyett, hogy résztvennének a stabilizációt szolgáló törekvésekben. Ennek az eredménye: 1. a kiadási ciklusok hosszabbodnak, 2. a kernel egyre bugosabb, 3. gyorsabban nyomják a kernelbe az új funkciókat, mint azt egyébként tennék (lásd. 2-es pont).
Alan Cox előállt egy olyan ötlettel, amely szerinte segítene kezelni ezt a problémát. Szerinte hívják a páratlan fejlesztői kiadásokat stabilizációs kiadásoknak, amelyekben semmi sem mehet be áttekintés és a linux-kernel ellenjegyzése/elfogadása nélkül. Linus kedvezően fogadta a javaslatot, és egy kicsit továbbfűzte: legyen a 2.6.<páratlan> legyen a nagy, kezdeti dolgok beolvasztásának sorozata, és mellette olyan javításoké, amelyek biztosítják, hogy az egész kernel működjön. Emellett a 2.6.<páros> kernelek legyenek a "semmi nagy beolvasztás, csak körültekintő javítások" kiadásai.

Bővebben itt.

( dikki | 2006. 09. 24., v – 08:08 )

tehát tulajdonképpen a 2.x páros/páratlan helyett legyen 2.6.x páros/páratlan, ha jól értem.

( wauf | 2006. 09. 24., v – 09:00 )

Akkor Reiser4 most csak a 2.6.21-ben jelenik meg?

( bra | 2006. 09. 24., v – 09:48 )

Ez valóban jól átgondolt fejlesztési modell. :)

Nem is értem a nagy cégek hogy bírják ki röhögés/menekülés nélkül. Lehet, hogy hasznosabb lenne először kitalálni valami rendszert és utána nekiállni fejleszteni.
Szerintem lenne némi marketing értéke.

Lehet, hogy eredményesebb, hiszen én is gyorsabban kódolok és érek el látványos eredményeket, ha úgy tehetem, ahogy akarom és nem kötnek szabályok (stílusbeli, programozásbeli, fejlesztésbeli előírások, rendes hibakezelés/ellenőrzés, elvárt minimum, hasonlók).

A Linux halad a leggyorsabban, ez kétségtelen, de ha valaki jobban mögénéz, láthatja, hogy kapkodás van, átgondoltság pedig nincs (stable API pld).

Szerintem a gyártók is utálják ezt a helyzetet, persze mikor nekik kell fejleszteni, ők is azt fogják nézni, hogy miként lehet a legkisebb pénzbefektetéssel (programozó emberóra) a legnagyobb eredményt (működő driver) elérni, nem pedig azt, hogy milyen módon lehet jól és korrektül megcsinálni, hiszen maga a környezet sem törekszik erre.

Kb. olyannak érzem, mikor 100 embert kizavarnak és azt mondják nekik, hogy építsetek irodaházat, de minden előzetes terv nélkül. Lehet, hogy gyorsan fognak haladni, felosztják maguk közt az egyes területeket és mindenki megcsinálja úgy-ahogy a sajátját, de hogy a végeredmény pocsékabb lesz, mint ha előzetesen átgondolták volna az egészet, az tuti.

Unos-untalan kibeszéltük már ezt. A vendorok disztribúciókra (SLES, RHEL) készítenek termékeket, amelyeknek az életciklusa hosszú (évek). Azokban nem változnak a kernelek havonta. Az meg sehol sincs előírva ezeknek a disztribútoroknak, hogy a mainline kernel legutolsó verzióit szállítsák, mint ahogy nem is teszik. Az én ubuntu desktop-om még mindig a 2.6.15-nél tart hivatalosan (kiadás dátuma: 2006. január 3.), és valószínűleg még egy darabig ott is fog tartani (az más kérdés, hogy én ha akarom belepörgethetem a 2.6.18-at, aztán úgy szopatom magam, ahogy akarom). Tehát, az ISV egy kvázi "stabil" felületre fejleszthetnek.

--
trey @ gépház

Nem disztribútorokra, hanem a gyártókra (hardver) gondoltam -szerintem ez elég egyértelmű is volt-.

De jó, hogy felhoztad, tökéletesen példázza a gondot az, amit írsz:
a disztribútorok lényegében saját kernelt készítenek, mindegyik a saját belátása szerinti verzióból.

Ezek az idő múlásával kezdenek eltérni a "stock" kerneltől, a gyártóknak pedig erre is kell drivert adniuk, meg a másik disztribútoréra is, meg a mainline kernelre is, amelyben ugye napról-napra változik az a parancs, amivel mondjuk a SCSI rendszerbe lehet eszközt regisztrálni. Ezt követni meg macerás, ráadásul a driverből nem tudnak linuxos verziót készíteni, mert olyan, hogy Linux már nincs. Van 2.6.16.1-es Linux, amely eltér API-ban a 2.6.16.2-estől (saját magam tapasztaltam, igaz nem biztos, hogy ezekkel a verziókkal), van Red Hat X Linux, Red Hat Y Linux, van SuSE X, Y és így tovább.

Nyilván más OS-eknél is kellene ifdefek a kódba, amelyek *API verzió* szerint illesztik az adott környezetbe a drivert, viszont a Linuxnál az API verzió jelenleg a kernel verziója, beleértve a subminor (negyedik) verziót is.

Mint említettem, ezerszer kitárgyaltuk már. Ennek a fejlesztési modellnek is megvannak a maga bajai, mint ahogy a többinek is van baja, csak lehet, hogy éppen mások. Ők deklarálták, hogy nem céljuk a stabil API. Ez az ő választásuk, ezen lehet lovagolni, de nem igazán érdemes. Az eladásokból az látszik, hogy a piac elfogadta ezt, a gyártók nagy része elfogadja (lásd nVIDIA, akinek nem okoz néha egy sort módosítani a kódján (az esetek 90%-ban ennyiben ki is merül az "új API" hozta változás)). Aki nem képes vagy nem akar, annak nem kötelező, de ahogy a trendeket nézem, előbb utóbb ezzel a döntésével egy meglehetősen erős piactól fog elesni. Nekem nem fog fájni, eddig is ki tudtam válogatni azokat a vasakat, amik jól működtek, meg ezután is ki fogom tudni.

--
trey @ gépház

Igazad van, ez kb. az a vita, amit az amigás táborral szoktál vívni PC/PPC témakörben.

Mindig a tökéletlenebb, műszaki szempontból gyengébb terjed el, ezt minden velem korabeli tudja a VHS térnyerése óta. :)

Elfogadom. Cserébe nézhetem hülyének azt, aki azt mondja, hogy a Windows nem operációs rendszer, a Linux pedig az? Csak azért kérdezem, mert műszakilag a Windowst többre tartom sok területen. Ettől még persze a hátam borsózik tőle, de ez teljesen más kérdés.

"Mindig a tökéletlenebb, műszaki szempontból gyengébb terjed el, ezt minden velem korabeli tudja a VHS térnyerése óta. :)"

A gyengébb sok esetben azt jelenti, hogy megfizethetőbb a végfelhasználónak vagy gazdaságosabb a gyártása a gyártónak. Vannak, akiknek még ma is megváltás lenne egy VHS magnó. Persze ennek most nem sok köze van a Linuxhoz.

"Cserébe nézhetem hülyének azt, aki azt mondja, hogy a Windows nem operációs rendszer, a Linux pedig az?"

Azt nézel hülyének akit csak jólesik :) Nem tudom emlékszel-e még, amikor először találkoztunk (errge, gyu, gaab, te és én (és talán alex)) a Kandón, akkor milyen jókat röhögtünk ketten a Windows szidókon? Már akkor elmondtam, hogy halálra kacagom magam rajtuk. Pedig az se ma volt (2002?)

"Csak azért kérdezem, mert műszakilag a Windowst többre tartom sok területen."

Van ahol több, van ahol kevesebb. Ezzel sem mondok azt hiszem újat.

"Ettől még persze a hátam borsózik tőle, de ez teljesen más kérdés."

Nekem nem :) Használom és támogatom már olyan régen, hogy megismertem a háklijait. Ettől még ha nem muszáj, nem használom. Viszont megélek belőle. HAHA. :)

--
trey @ gépház

Nem vagyok meggyőződve arról, hogy Linuxra fejleszteni gazdaságosabb, mint mondjuk -akár- Windowsra, ahol jó esetben egy Windows 2000-hez kiadott driver még a két következő Windowson (szerver és desktop) is használható.

Ja, emlékszem, mondjuk gyu és Gergő is tipikusan ilyen. ;)

"Nem vagyok meggyőződve arról, hogy Linuxra fejleszteni gazdaságosabb, mint mondjuk -akár- Windowsra, ahol jó esetben egy Windows 2000-hez kiadott driver még a két következő Windowson (szerver és desktop) is használható."

A fenti megállapításomnak semmi köze sem volt operációs rendszerekhez. Kizárólag hardverekről beszéltem :)

--
trey @ gépház

Próbáltam és pont ezért hányok a Linuxtól mostanában.
Subminor, vagy minek hívják (a negyedik) verzióváltáskor tűntek el, vagy alakultak át a SCSI "réteggel" való kommunikációhoz szükséges hívások.
Némelyik tényleg csak annyi volt, hogy a-ról b-re változott a neve (na ezt hívom agyatlanságnak), másoknál viszont a működés változott meg, amihez a kódot is módosítani kellett.

>Ezek az idő múlásával kezdenek eltérni a "stock" kerneltől, a gyártóknak pedig erre is kell drivert adniuk, meg a másik disztribútoréra is, meg a mainline kernelre is...

Adjanak a mainline kernel-re, a többi már az adott disztribúció feladata.

Mert ezzel a driver licencet a kernel licence alatt kene kiadni. Nem minden gyarto szereti, ha latjak az emberek a takolmanyuk lelki vilagat, biztos felnek hogy napvilagot latnak tervezesi hibak es a gany megoldasok :)... Sok driver forraskodjat meg a felhasznalt technologiak licence is megkotheti.

Ugye te nem vagy ennyire naiv, csak szimplan provokalod a nepet?
Gondolom azt is olvastad mostanaban, hogy idonkent hiaba kuldenek be dolgokat, az istennek se kerul bele a Linux-az-istenkiraly-n.m.x.y.u.v.z kernelverzioba. (Nezz utana esetleg, hogy miert nincs Reiser4, meg tan grsec, meg meg egy halom masik dolog a hivatalos mainline kernelben.)
Ja es igen, ezen kivul meg lehetnek licence problemaik is bizonyos gyartoknak.

Volt ilyen több is, sokszor kioktató, eléggé hitvány stílusban, arra hivatkozva, hogy "szar" a kód, amit írtak (ami akár igaz is lehet, illetve abban az esetben, amire emlékszem ránézésre az is volt, részben azért, mert a fejlesztők képtelenek egy jól működő, saját magukon belül szabványos megoldást adni a SCSI rétegre). Nézegesd az lkml archívumát.