Adrian Bunk: A 2.6.16.x hosszú kernelsorozat lesz

Kernel

Tavaly decemberben Adrian Bunk (korábbi Debian fejlesztő) egy RFC-t postázott az LKML-re, amelyben azt javasolta, hogy a 2.6.16-os kernel megjelenése után indítsanak el egy hosszú stabil kernelsorozatot. Ennek az volt az oka, hogy szerinte a felhasználók szemszögéből nézve több probléma is van a jelenlegi kernelfejlesztési modellel.

Milyen problémákra gondolt? Például minden új kiadáskor visszafejlődések lehetőségével kell számolnia a felhasználóknak, vagy éppen a kernel frissítés új userland programok használatát (udev, pcmcia utils) követelheti meg.

A frissítés túl nagy munkával jár, és ennek a vonzata az lehet, hogy felhasználók inkább régi kernelkiadásokat használnak, amelyeknek nyilvánvalóan biztonsági kockázatai vannak. Adrian szerint ez a probléma a fejlesztési modellból fakad.
Az utolsó stabil kernelsorozat, amely mentes ettől a gondtól, a 2.4-es. A fejlesztő szerint azzal is baj van, például az új hardverekhez már nem nyújt támogatást.

Szerinte a megoldás erre a problémára az lehet, hogy a 2.6.16-os kernelre alapozva egy hosszú, stabil kernelsorozatot indít. Ez azt jelenti, hogy a 2.6.17-es kernel megjelenésével nem követi az abban bekövetkező változásokat, hanem folytatja a 2.6.16.x stabil kernelsorozatot a szokásos Hartman/Wright stabilizáció után.

Erról egy rövid FAQ-t is postázott levelében. Eszerint:

- patchek elfogadási policy-je hasonlítani fog ahhoz, amilyen a 2.4-es kernelé volt a 2.6.0 megjelenése után volt (driverek jöhetnek)
- a munkája a szokásos 2.6.16.y karbantartás (-stable) után indul, mert az egy relatív stabil, jól tesztelt alap lesz a hosszú 2.6.16.x-hez
- a 2.6.16.x sorozat olyan hosszan fog tartani, amilyen hosszan az embereknek szüksége lesz rá, és amilyen hosszan a patchek jönnek majd hozzá
- nem lesz stabil API/ABI a külső modulok felé

A bejelentést itt olvashatod.

( snq- | 2006. 03. 20., h – 20:37 )

>> a felhasználók szemszögéből nézve több probléma is van a jelenlegi kernelfejlesztési modellel
>> ez a probléma a fejlesztési modellból fakad
>> Az utolsó stabil kernelsorozat, amely mentes ettől a gondtól, a 2.4-es

ha ezt csak a 2 hubi és az üveg bor miatt látom, már akkor is egy szép este volt

Igaza van ezek a kernelnácik mindig variálnak. Pl a 2.6.15-ben bejött egy új RTC és ettől az ALSA szépen dobott egy csomó hibát a konzolra. Szép volt amikor 20 nyitott terminál ablakot szemetelt tele minden egyes számváltáskor.

--
Az élet harc. Délelőtt az éhséggel, délután az álmossággal.

( Csigaa | 2006. 03. 20., h – 21:30 )

VÉGRE VALAKI GONDOLKOZIK!!
Sajna valszleg süket fülekre talál... A Linux ha így folytatja, halott. _Újra_ használni akarom a USB kütyümet :(
2.4-essel már nem megy nálam a két USB HID (egér, gamepad), szal a downgrade sajnos nem megoldás...

( vomberg | 2006. 03. 20., h – 22:43 )

Nem értem a morgás tárgyát már magával a 2.6-os kernelfejlesztési modellel kapcsolatban sem. Pont ez a dolog szépsége. Kipróbáltak egy új modellt, ami bizonyos szempontok szerint működik, de bizonyos szempontok szerint nem jó.

Most jött valaki aki bevezet egy más modellt. Ha beválik akkor használni fogják a népek. Ami összezavarja a tisztánlátást az az, hogy 5 millió sor kódnak és több ezer fejlesztőnek bizony van egy bazi nagy tehetetlensége, ha egyszer megindul a projekt valamilyen irányba, akkor bezony az eltart egy darabig, hogy kanyarodni kezdjen.

Az nem baj, hogy egy időszakban rossz irányba mennek a dolgok, mert a változás lehetősége benne van magában a rendszerben és a jelek szerint élnek is vele amikor erre megérett a helyzet.

Minden szabályozáshoz kell a hibajel, hát most itt van, a 2.6-os kernel körüli problémák alakjában. Szemmel láthatóan működik az önszabályozó rendszer, nekem ez speciel tetszik. De legalábbis jobban, mint más elterjedt fejlesztési modellek.:-)))))

a kiserletezgetes egeszen addig remek, amig pistike es 30 baratja fejleszti a cuccot a koliba'. onnantol kezdve, hogy kb. iparagak epulnek erre, ez mar kicsit sem vicces.

"Ami összezavarja a tisztánlátást az az", hogy mr kroah-hartman, morton, a fo-fo-foisten torvalds es a tobbi majer kisse elrugaszkodtak mar a talajtol. ideje, hogy valaki pofanvagja oket es magukhoz terjenek.

egyebkent amig itt az egygepes expertek elrohogcselnek a "mas elterjedt fejlesztesi modellekkel" kapcsolatban (amirol mondjuk a tobbseguknek tul sok fingja nincs, de legalabb el lehet vele utni az idot dolgozas meg tanulas helyett), addig szepen telik az ido es tortennek dolgok az enterspajzba', ami esetleg meglepetest fog okozni.

Ez az egyik kedvenc ervem. "Nem tetszik? Forkold!" "Kijukadt az autod gumija? Zuzasd be azt a rohadek autot."

Nem am problemara kell koncentralni, az tul egyszeru ;)

Szerintem az alternativ idovonalak is ugy keletkeztek hogy Isten forkolta a main tree - t...

---
pontscho / fresh!mindworkz

Szabad szabad kicsit flémelni?
Az ilyenek kezdenek egyre inkább a FreeBSD felé téríteni.
Persze csak addig, míg rá nem jövök, hogy ott is adódnak némi fejetlenségből elkövetett bugok ;-)

--------------------------------------------------------

Kéretik némi kétkedéssel fogadni mindent amit leírok.
Jelszavam - Sándor Györgytől kölcsönözve: "A hülyeség, ha nem is xylofonozik - FOSZFORESZKÁL!!"

Nem lévén kernelmágus, csak halkan rebegném a tudatlanságból fakadó kérdést, miszerint: a kísérletezgetésnek feltétlen a stabil ágon kell zajlania? Értem én, hogy a páros/páratlan verzió különbségének megszűntetése is része a kísérletezgetésnek, de nem lehetett volna ezt a lépést hagyni a végére, amikor már kiderült (volna), hogy működik a dolog?

( MGy v | 2006. 03. 21., k – 09:00 )

El tudja nekem valaki érthetően magyarázni, hogy miért nem volt jó az a modell, hogy a x.y.z verziószámból ha y páros az stabil sorozat és nincs benne csak javítás és ha páratlan az fejlesztői darab amiben ha API változik akkor sem szabad túl hangosan sírni, hanem hozzá kell alakítani a többi progit, mert előbb-utóbb az lesz a stabil.

( willy v | 2006. 03. 21., k – 09:36 )

Butasag.
Alapvetoen van benne igazsag, de imho az forditson kernelt aki ert hozza, ezert vannak a disztribuciok, aki meg koveti a valtozasokat, annak konnyeden mennek ezek a modositasok.
Azonban, tenyleg elszaladt a lo. Viszont az a problema amit Linus allandoan kifogasolt, hogy szeles tomegek nem tesztelik a fejlesztoi kerneleket az megoldodott..

Attól függ mit értünk széles tömegeken. Egységsugarú júzer aki feltolja az összes frissítést és utána bugos lesz a rendszere (mondjuk pont a kernel miatt) szerinted ír egy normális bugreportot vagy utána néz, hogy mi is történt? Egyszerűen szar a linux felkiáltással törli és meg is oldotta a problémát.

--
Az élet harc. Délelőtt az éhséggel, délután az álmossággal.

Én általában kernelcsere után ha valami nem kerek rögtön szétnézek, hogy mi lehet a hiba oka. Így találtam meg az ALSA oldalán is a leírást, hogy kell az új verzió ha nem szeretném, hogy szemeteljen a kernel a konzolra.

--
Az élet harc. Délelőtt az éhséggel, délután az álmossággal.

( uid_228 | 2006. 03. 21., k – 10:23 )

Na végre, valaki gondolkodik! :I

Tegnap éjjel fordítottam egyet; a 2.6.16-os az első általam kipróbál 2.6-os kernel, ami az itthoni (már viszonylag régi, Tualatin P3-as) gépemen hozza ugyanazt a funkcionalitást, amit a 2.4-es. Éles szervereken még mindenhol a 2.4-est használom.

Azért a dologról az is elmond valamit, hogy Spenglerék is várni akartak a .16-osig, mondván annyi minden változik még a .15-ben is, hogy nem érdemes erőfeszítéseket tenni a GRsec fejlesztésére abban az ágban.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( nevergone v | 2006. 03. 21., k – 18:30 )

Az lenne a célszerű, ha a kernelt a disztribútorok patchelnék úgy, ahogy szükséges, és ők fordítanák le. Az emberek pedig azt használnák. Elvégre a legtöbb rendszer (teljesen érthető okokból) csak arra a kernelváltozat működésére vállal garanciát, melyet ő szállított...

Úgy őszintén: belegondoltál te már ennek a következményébe?

Ugyanarra a problémára lesz millió különböző patch, ami ugyan be is kerülhetne mainline kernelbe, de minek, pecseljen a disztribútor.
Másrészt ha minden juzer pecselt disztrib kernel használ, akkor mennyi idő alatt fognak a hibák kijönni? Mennyi anyázás után?

A másik dolog a "stabil" kiadás vs. változó API. Mondja már meg nekem valaki, hogy a 2.x.y.z -nél z változásakor MINEK kell az apit változtatni???? Vagy egyáltalán x vagy y változásako? Ettől lesz stabil?

Pl. ittvan az nvidia bináris driver esete. 2.6.16 -tal nem megy. Okés, ki fog (?) adni nvidia egy újabb verziót, ami jórészt csak ezt hivatott javítani. Sokan mondják hogy ez az nvidia hibája. Én nem csak az ő nyakukba varrnám. Helyükben én hagynám az egész linuxos drivert a fenébe és hagynám úgy ahogy van. Lenne belőle nagy zúgolódás, az biztos...

A másik dolog a "stabil" kiadás vs. változó API. Mondja már meg nekem valaki, hogy a 2.x.y.z -nél z változásakor MINEK kell az apit változtatni???? Vagy egyáltalán x vagy y változásako? Ettől lesz stabil?

Ezzel maximálisan egyetértek én is. Van egy kis scannerkám (Genius GeniScan 4500 ) amihez vki kiadott egy drivert - még a 2.2.28-as kernelhez. A driver már 2.4-es kernelen se forog, pedig állítólag ott még nem változott sokat az API. Mondjuk, mivel nincs rá kereslet, a driver developere monta, hogy ő már nem supportálja, kezdjek vele amit akarok, őt nem érdekli ez a kérdés. Yó, persze régi HW-hez nem muszály driver, de itt nem is erről van szó.

Hanem hogy ha a nagyobb cégek kiadnak egy linuxos drivert, akko fel kell vállalniuk azt, hogy minden z, y vagy x váltáskor ki kell adni egy új release-t vagy egy patchet.

Én is amondó vagyok, hogy ha kiadnak egy stabil ágat, azt tessék úgy hagyni, ahogy van, oda mondjuk csak secu patchek, és ha valakinek van hozzá kedve,hackelje bele azt ami a fejlesztői verzióból neki kell. Azaz szerintem ilyenkor egy freeze-féle kellene a stabilnak mondott fára.