Greg KH: Linux 2.6.16.13

Kernel

Greg Kroah-Hartman a -stable csapat nevében bejelentette a 2.6.16-os Linux kernel 13. javítását. Benne egyetlen fix található, amely az iptables SCTP conntrack kódjában levő DoS sebezhetőséget javítja. Változások listája itt.

( Misi | 2006. 05. 03., sze – 09:26 )

LOL. Most már teljesen biztos, hogy minden 2. patch egy hibára ad majd javítást :).

( gsimon | 2006. 05. 03., sze – 10:54 )

Na, kiszámoltam az aktuális KTM-eket (Kernel Taknyolási Mérőszám):
- a két kiadás bejelentése között eltelt 96340 sec
- az új kernel tömörített mérete 40837424 byte
- a kernel (az én kb. átlagos konfig-ommal) 683.386 sec alatt fordult egy 3039.23 bogomips-es gépen
- a reboot ideje 94 sec

Ebből:
- a full kernelnek az kiadási időpontok között való lehozatalához szükséges sávszélesség: KTM0 = 3391.1 baud
- a kernel ugyanennyi idő alatti lefordításához szükséges gépteljesítmény: KTM1 = 21.56 bogomips
- a reboot által kiesett idő miatti rendelkezésreállási arány: KTM2 = 99.902 %

Szóval:
- 4800-as modem alatt nem érdemes elkezdeni lehozni
- 486DX-25 alatt nem érdemes elkezdeni lefordítani
- irodai szervernél kritikusabb üzemben nem érdemes váltani rá

Tudom, ezek a KTM-ek csak a 'megfontoltságot' mérik, legfeljebb szokatlan formában :). Amúgy is tudjuk, a statisztikák 78.41%-a semmitmondó adat :)...

Az viszont elgondolkodtató, hogy ha ilyen tempóban jönnek ki az egyes hibák javításai, az azt is jelenti, hogy ilyen tempóban mennek is bele a hibák (pl. a belerakott új dolgokkal), ugye. Ez persze így elkerülhetetlen, csak a régi fejlesztési modellnél ez nem így volt: ott a stable nem snapshot-ot jelentett, hanem olyasmit, amit egyszer lezárnak, új cucc már nem megy bele, ezzel hiba sem, így amit javítanak, az csak stabilizál, és nem pedig még jobban belekavar a lecsóba.
Hát ez ugye itt 2.7-en nincs, itt nem tudom megtenni, hogy lemondok a naprakészségről a stabilitásért: ha meg akarok szabadulni a kritikus hibáktól, nosza, frissítgessem, csak épp pont ezzel hozom be az új, még észre nem vett bugokat, amik azokkal az 'új feature'-ökkel és 'teljesen újraírt' részekkel szivárognak be, amik persze jók, _ha működnek_, de amik nélkül igazából ellennék, _amíg bugosak_.
Ez persze így nem teljesen igaz, mert elképzelhető, hogy van olyan 2.7.x.y.z.v.w verzió, ami "egészen stabil" (kösz.szép...), mert pont sikerült jól megcsinálni a friss ropogós új cuccokat benne, csak épp ezt _nem lehet előre becsülni_, mondván "a 15-ös, 20-as minornál már érdemes kipróbálni", mert a bugosság nem monoton csökken (mint a régi séma stabil ágánál), hanem összevissza rángatózik, mint hoppárézimi az ipari áram alatt...
Ez így komolytalan. Lehet, hogy nagyon gyorsan száguld, csak épp semmi garancia, hogy a fékje is működni fog... GKH-ék biztos nagy örömüket lelik a fejlesztésben, mert hát mindenki jobban szeret programozni, mint tesztelni és bugot vadászni, csak épp én meg Uram bocsá' _használni_ szeretném ezt a kócerájt, mondjuk valami komoly helyen, és hiába jobb pl. a dev mapper, ha az egészet lőhetem, mert mondjuk az ip stack meg még egy bitgettó...
Tudom, akkor használjak disztrib kernelt. És abban nem lesznek benne ugyanazok a bugok? A disztrib kernel karbantartója is csak abból főz, ami előtte van az asztalon, ha az egésznek nincs stabilizálódó folyamata, csak átmenetileg többé-kevésbé üzemkész állapotai, akkor abból ő sem tud jobbat kiválogatni.

Egy szó, mint száz, nekem úgy tűnik, hogy a kernel szépen átment egy stabil verzióval is rendelkező rendszermagból egy elitista gittegylet különbejáratú hobbiprojektjébe. De hát ez már az ő dolguk, nekem szerverre jó a bsd is, asztali gépre meg a 2.4-es...

GKH-ék biztos nagy örömüket lelik a fejlesztésben, mert hát mindenki jobban szeret programozni, mint tesztelni és bugot vadászni

Szerencsére nem mindenki, de aki az utóbbi nehezebb melót űzi jobban szeretne inkább megélni belőle, mintsem ingyen küldözgetni a javításokat a sztár-fejlesztő uraknak... És így lesznek a '0day for partners' security cégek. ;)

Tudom, akkor használjak disztrib kernelt. És abban nem lesznek benne ugyanazok a bugok? A disztrib kernel karbantartója is csak abból főz, ami előtte van az asztalon, ha az egésznek nincs stabilizálódó folyamata, csak átmenetileg többé-kevésbé üzemkész állapotai, akkor abból ő sem tud jobbat kiválogatni.

Így van. Ez az amelyet sokan nem értenek meg.

azt erdemes lenne belevenni, hogy mivel letoltes kozben nem lehet forditani (illetve lehet ilyent? toltod le, pipeolod tar-ba, es fordit folyamatosan, ahogy jon az uj file?), ezert a kiadasok kozott eltelt ido alatt valami optimumot kell talalni => gyorsabb gep && modem kell, de most lusta vagyok szamolni.

( Steelman | 2006. 05. 03., sze – 11:38 )

Hát ez azért nem túl szívderítő... Eddig is tudtam, hogy a 2.6-os kernel széria enyhén szólva nem a legstabilabb, de ezek a napi (lassan napi 2-3) frissítések nem győznek meg arról, hogy érdemes kipróbálnom. A jó öreg 2.4-es egyelőre még elég amire nekem kell. :-)

Asztali gépre (grafikus felület, játék, webezgetés, zenehallgatás) linux, mert kicsit emberbarátibb, 2.4-es kernel, mert rendesen megy vele a gyári nvidia driver. Igazából csak egy komoly dolgot csinálok ezen, az áramkör-tervezgetést (már amikor jut időm hobbira...), mert ahhoz kell normális grafikus felület, meg mert az eagle-t csak x86-ra adták ki.
Szervernek (semmi grafika, mail-, adatb-, webszerver) netbsd, mert nem kell hetente frissíteni. Jó, bevallom, van fenn w3m, azaz néha a hup-ot is onnan olvasom :).
Bár, (mint annyi minden máshoz is,) még eléggé laikus vagyok a bsd terén, gyakorlatilag csak próba-szinten üzemeltem be a fentieket, mindazonáltal működnek.

Félreértés ne essék, nem én fújom a passzátszelet, de tényleg:
Trey, te használsz-e éles környezetben 2.6-os kernelt, és ha igen, hogy döntöd el, hogy mikor frissíted?

"Trey, te használsz-e éles környezetben 2.6-os kernelt, és ha igen, hogy döntöd el, hogy mikor frissíted?"

A notebookom az éles környezet? Akkor igen. Mikor frissítek?

Előbb eldöntöm, hogy kell-e nekem frissíteni. Tudom, hogy ez némelyeknek nehéz feladat (mármint ha MIPS javítások vannak jó barátságban ARM és Alpha dolgokkal a patchben akkor az nem vonatkozik rá, ha i386-ot használ), de nekem bevált. :-)

--
trey @ gépház

Köszi a választ! Viszont rosszul kérdeztem, arra lettem volna kíváncsi, hogy olyan szerveren, ahol nem szeretnél gyakran bootolni, mert pl.:
- nem sűrűn akarod a rendelkezésre állást megszaggatni
- fizikailag macerás a géphez odajutni, ha netán mégsem bootol fel, ill. felbootol, csak valamitől lefagy,
szóval ilyesmi helyen használsz-e 2.6-os kernelt, és ha igen, sacc/kb. milyen gyakran kellett frissítened?

(Nagyobb gyakorlatod van a dologban, mint nekem :), úgyhogy tényleg érdekelne, ilyen szempontból mennyire érdemes próbálkozni a 2.6-tal, ne szívjak fölöslegesen, ha más tapasztalatából is lehet okulni.)