bugs++

Kernel

Dave Jones (davej at redhat) a Red Hat kernelfejlesztője (a Fedora kerneleinek karbantartója) egyetért Andrew Mortonnal abban, hogy a Linux kernel kiadásról kiadásra egyre bugosabb lesz. Andrew azt mondta, hogy nincs statisztikai adata arra, hogy alátámassza kijelentését, csak a beérkező levelek számából következtet erre.

Dave állítását a Fedora Bugzilla adataival próbálja igazolni.

A Fedora Core 4-ben a 2.6.14-re átállás idején (2.6.14-1.1637_FC4 rebase) 356-ről 376-re nőtt a nyitott bugok száma egy hét alatt. Egy héttel később már 388 volt. A 2.6.15-re váltáskor (2.6.15-1.1830_FC4) a Fedora Core 4 már 488 nyitott bugnál járt, és kb. egy héttel később ez a szám 500 fölé emelkedett.

Davej blogjában megpróbál magyarázatot találni a tendenciára.

( buran | 2006. 05. 09., k – 11:25 )

Úgy tűnik, mégis van olyan opensource fejlesztés, ami csak központosítva tud jól működni. Remélem, a kommunikáció hiányán és az elosztott hibajavítás nehézségein hamar túllendülnek, különben erősen meg fog torpanni a linux kernel fejlesztése. :-(

;-(

Hmm. Szerintem nem (csak) errol van szo. A kozpontositott fejlesztest eleve lehet tobbfelekeppen is erteni, olyasfajta kozpontositasra igenis szukseg lenne, ami maga a source es pl a hibak kezeleset illeti, hiszen anelkul mindenki csak a vakvilagba dolgozik ... Az elobbire ugye anno nem volt semmi, forraskod kezelesnel Linus megnezte a patch-eket, kezzel merge-elte stb. Aztan jott ugye BitKeeper, amit persze sokan kritizaltak hogy nem open source. Na akkor jot a git. Ami azota nagyobb nepszeruseget ert el (pl XOrg-nal is fogjak hasznalni ugy tunik). Szoval ami anno "pampogasnak" tunt sok embernek ("miert maniaja egyeseknek hogy free megoldas legyen mindenre, jo a BitKeeper") az vegulis hosszu tavon jol sult el. Nade, a masik kerdes pl a hibakezeles, na erzesem szerint ez kb most tart ott ahol anno a forraskod kezeles tartott ... Tehat nyilvan ezt is meg kell oldalni valahogy, kell valami "kozponsitott" infrastruktura, ami jelenti a hibak kezeleset, elfogadast, ahhoz hasznalt software-t vagy barmit. Mert ahogy en tudom/erzem/latom jelen esetben itt tenyleg komoly hianyossagok vannak. A masik az, hogy a fejlesztes menete (hogy regen volt devel meg stable sorozat, most maskepp van stb) az jelenleg nem tul kiforrott, de remelhetoleg (marmint en pl remelem) ez viszonylag atmeneti csak es elobb-utobb vmi ertelmes dolog csak kisul belole, mint ugye a fenti forras verzionalis kezelesenek kerdese, ami regen ugyanugy nem volt kvazi semmilyen ertekelheto szinten, mint manapsag par dolog. Megoldando feladat persze mindig lesz, ez nyilvanvalo ...

( sb | 2006. 05. 09., k – 11:26 )

Hmmm...lehet, hogy van valami ebben a bugs++ dologban. Csak az a nagy kerdes, hogy ennek mi az oka:

  • egyszeruen azert tobb a bug, mert a 2.6-os szeria kodja "nagyobb"
  • hanyagabb lett a fejlesztoi garda
  • esteleg mindketto

Sajnos ma ennek nincs idom utanajarni, de kivancsi lennek az atlag hupper velemenyere.

Vagy csak egyszerű emberi tulajdonság? Mint írja (ő és már más is írta), az egyik ok az lehet, hogy az emberek jobban szeretnek új dolgokat implementálni (okok ismertek), mint unalmas bugvadászattal foglalkozni. Az utóbbival lényegesen kevesebben foglalkoznak, mint az előbbivel.

--
trey @ gépház

Ez nyilván így van, bár ha már megírok valamit, akkor azt szeretném ha hibátlan lenne. Persze más, esetleg undorító kódjában én sem szívesen játszanék Bug Hunting-ot.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Ahogy a fenti cikkben is van, hetente tobb mint 1000 sor valtozik a kernelben. Csomo bug eltunik, vagy nem reprodukalhato az ujban. Viszont uj bugok jelennek meg. Kivadaszni, hogy melyik patch tuntette el a bugot, szinte remenytelen feladat;) Raadasul az alrendszerek fejlesztoi sokszor nem valaszolnak az ilyen levelekre. (dude, ugyan mondd mar melyik patched tuntette el ezt a bugot.)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( Gabucino | 2006. 05. 09., k – 11:34 )

Mellesleg baromi egyszeru, hogy az ilyen tendenciat miert csak "erzesre" tudjak kimutatni... Mert egyszeruen nincsenek felkeszulve barminek az eszrevetelere... Lassan nekik is kezd leesni a huszfiller :)

Siman. Semmire nincs automatikus csodaszer, az open source sem az semmire megfelelo elokeszulet nelkul :) Gondolok itt arra hogy a linux kernel fejlesztesenek (egyik) gyenge pontja eddig is a hibakezeles volt szerintem: sokan panaszkodtak regebben is, hogy pl veszelyes security hole-ok jelentesere nincs semmi "standard" email cim akarmi, ahova lehet contact-olni. Vmi bugtracking, hibajegykezelo rendszer sem artana, es akkor maris korrekt statisztika is lenne mindenre (vagy lehet van ilyen csak en nem tudok rola?). Azonban _szerintem_ legalabbis pont azert is jo az open source mert az ilyenekre feny kerul, pl paran elkezdenek ramutatni a hibakra. Mig egy closed source fejlesztesnel te SOSE fogod megtudni hany ezer bug van, meg milyen a bugok szamanak alakulasa az ido fuggvenyebe, mivel ezt nem kotik az orrodra, max akkor tudod ha developer vagy abban a projectben akkor meg valszeg' nem mondhatod el viszont masnak.

Ha mar a closed source szoba kerult.
En azt nem ertem, hogyha a linux kernelnel csak a fedoranal 600 folott van a nyitott bugok szama, ubuntunal meg tobb, es meg van par disztro. A bugok joresze nincs is atfedesben.

Akkor pl. a windows heti javitasai, ahol osszesen 1-2 bugot javitanak (mindenesetre <10 alatt), az eletben nem fixaljak (ilyen utemben) a naluk levo (gondolom) szinten jopar bugot. Gondolom ott is tevednek a programozok, es ott is vannak bugok.
Ebbol 2 dologra tudok kovetkeztetni: a) nem valljak be a javitott bugok szamat b) nem tudjak javitani csak <10bug/het utemben.

Most nehogy flame legyen ebbol is.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ehh :) Szoval: ugy, hogy az open source fejlesztesnek vannak hatranyai is, de ketsegtelen elonye hogy kiderulnek a hatranyai, tekintve hogy mindenki "belelathat" aki akar, ami nem all ugye a closed source-ra. Ez kerlek osszehasonlitas volt, nehez valamirol beszelni ha nem probalod valami mashoz hasonlitani, ugy hoztam ide a closed source-t, remelem mar erted :)

Elsosorban szerintem ez nem technikai kerdes ("nincs mit hasznalni"), hanem az, hogy el kene donteni, hogy KELL hasznalni valamit, es pl ezt meg azt. A Linux kernel fejlesztesenek menete (es annak kapcsan hasznalt folyamatok, eszkozok, stb) nehany szempontbol erzeseim szerint kisse lasabban fejlodik mint amilyen gyorsan "terjed", azaz fel kell noni a megnovekedett igenyekhez. Na persze ez megintcsak amolyan "IMHO" velemeny volt ...

Na latod, itt valaszoltal magadnak, hogy jon ide a closed source, bar nem mondtad ki, itt hasonlitattad ossze a kvazi kontrol nelkuli open source fejlesztest valami centralizalt, zart modellel. Erre ohajtottam csak ramutatni hogy a nyiltsagnak nyilvan vannak hatranyai is, olyan biztos nem letezik sehol a vilagon legyen barmilyen fogalom aminek _csak_ elonyei vannak.

Azt is hasznaljak...
http://bugzilla.kernel.org
Hasznalom is.
peldaul, bekuldom a bugreportot. Andrew ir ra valalmit. A valaszt beragasztom a bugzillaba, mer az gyorsabb (eppen nyitvan volt az oldal)

Erre o:
------- Additional Comment #7 From Andrew Morton 2006-04-20 03:03
Yes, it makes CONFIG_DEBUG_SPINLOCK_SLEEP work better.

Please let's continue this discussion via email. Just do reply-to-all to my earlier email - the email thread will get copied into bugzilla. The scsi guys work better via email and it's hard enough to get them to look at bugs at the best of times :(

Umm...
Hat erre nincs sok mondanivalom. Egyebkent a bug miatt visszakuldtem 3 db Adaptec 39320R SCSI kartyat.

Szoval az opensource neha eleg draga tud lenni :)

Próbáltad esetleg FreeBSD-vel is?
Hátha jobb azon az OS-en, amelyben a SCSI middle layert, a drivert, illetve a kártya firmware-jét is ugyanaz az ember írta. :)

Ha megvan még a cucc, kíváncsi lennék, mire jutsz vele.

Qlogic adapterrel 120TB-os diszktömböt használtam már FreeBSD alól minden gond nélkül. Sőt, ha jól emlékszem két ilyet RAID0-ba is tettem, bár az már más tészta.

1. SCSI nem fibre channel. (az arkulonbseg $1000 korul van sajnos.)
2. A kartya nem tud LBA64-et. Nem lat tul 2TBon. Ezzel nincs mit kezdeni OS szinten.
3. Oprendszer csere-bere nem kiraly. Nem novelem meg az admin overheademet a 2 szeresere a 61. szerverrel. (60-on debian fut :-D)
Akkor inkabb SCSI kartyat cserelek.

( anr | 2006. 05. 09., k – 16:18 )

a megoldas egyszeru. a sok ceg, aki a linuxbol nagy penzeket szakit at kell allitson fizetett fejlesztoket a feature irasrol bugjavitasra.
eszement mennyisegu uj dolgot nyomtak bele az utobbi idoben. a tempo maradhat, de a foleg bugjavitassal foglalkozok szamat kell novelni. nem az a problema, hogy nincsenek megtalalva a bugok, tehat tesztelok vannak tomegevel, hanem az, hogy a bejelentett bugok kozul csak az igazan fontosakra keszul el a patch. na ez baj.

egyebkent egyetemistaknak jo kernelfejlesztoi betanulas, hogy a lejelentett bugokat kijavitjak. ;)

Anr - http://andrej.initon.hu

A cég, ahol melóztam anno gyártott saját ketyerét, amit linuxszal kellett meghajtani. Nosza, csináltunk hozzá kernel modult, príma. Persze derültek ki vele kapcsolatban bugok, semmi gond, javítottuk is.
Mondhatni karbantartottuk, amit írtunk, söprögettünk a portánk előtt, kialmoztunk a disznaink alól, stb., dolgoztunk a fizetésünkért. Ez a cégnek is megérte, mert volt normális rendszer a ketyeréhez.
Node:
1.,
Miért fizetne nekem a cég azért, hogy más szemetét takarítsam?
Ahányan gányolják összevissza, a világ pénze nem lenne elegendő elég programozónak, hogy azt takarítsa kifelé, másrészt meg a gittegylet elit szakmánya hajlamos nem befogadni patch-eket egyszerű földi halandótól, azaz hiába is javítanám, messze nem biztos, hogy bekerülne.

2., Miért nem az javítja a hibát, aki a hibás kódot írta?
Azt hiszem, valahol itt lenne a különbség a 'programozok' és a 'gányolászok, amíg érdekesnek találom' között...

2., Miért van ennyi bug? Mert lényegi tesztelés nélkül megy bele az ún. 'stabil'-ba. Egyrészt nem feltétlen kéne a fél világot belevonni a tesztelésbe, aki nem akarja, annak lehetőséget kéne adni a tényleg stabil verzióra (régen is volt, aki a páratlant használta = tesztelte), másrészt meg nem kéne egy még félig sem kitesztelt dologra rögtön ráépíteni negyven másikat, amiket majd szintén át kell írni, ha az eredeti bug csak inkompatibilitással javítható.

3., "Az egyetemistáknak jó betanulás a bugok javítása." Hm. Hát, szerintem egy bugot levadászni egyrészt nehezebb, mint elkövetni, úgyhogy akkor most a profi kernel haxxorok a nehezebbjét hagynák a kezdőknek? És vajon hány bugot hoznának be a kezdők által beadott javítások? Hiszen (elvileg) többet hibáznak, mint a profik, ugye...

>Miért fizetne nekem a cég azért, hogy más szemetét takarítsam?
azert mert szuksege van arra a jol mukodo modulra. a Montavista/Redhat/IBM nagy penzeket szakit a linuxbol. nem csak azon a reszeibol, amiket a sajat programozoi irtak, hanem a tobbibol is. a redhat-nek dragabb lenne "kidobni" a sajat vendor kernelebol azokat a reszeket, amiket nagyon nem ok irtak, mint bugokat javitani benne. a penz megvan hozza.

>2., Miért nem az javítja a hibát, aki a hibás kódot írta?
pl: a devfs-t megirta eggy ausztral CSIRO-s(ottani MTA) faszi, majd massal kezdett foglalkozni, es 1 evig nem is olvasta a kernel listat. senki nem javitott bugokat, ki kellett dobni, lett helyette az udev. az opensource fejlesztes (foleg a linux) nem csak allando emberekkel dolgozik, hanem sok az olyan, aki 1-2 evig vesz reszt a munkaban aktivan. a BSD-knel az ilyen embereket ltalban elzavarjak.
ezek az emberek lehetnek rendkivul jo szakemberek, de nem ajanljak fel eletuket es veruket a linux kernel fejlesztesere. szerintem az altaluk magara hagyott modulok bugjaibol van a legtobb. (ez csak tipp, nem vegeztem reszletes elemzest, bar valoszinuleg nem lenne nehez).

>Miért van ennyi bug?
az ok szerintem abban van, hogy a -mm fat
kevesebben hasznaljak, mint pl. a 2.5.x-et, ahol x>80 ;) ha tomegek hasznalnak az -mm fat, akkor a bugok mar az elott meg lennenek fogva, mielott bekerulnek linus fajaba.

>És vajon hány bugot hoznának be a kezdők által beadott javítások?
leellenorizni a egy bugot javito (altalaban kicsi) patch-et leellenorizni gyorsabb konyebb, mint levadaszni/megirni.
egyebkent te nem talaltal/javitottal kicsi bugot nagy opensource programban? egy idoben JBOSS-oltam. abban is talaltam/javitottam hibat. nem bonyi. a hibakereses modszerei barmire mukodnek, projektol fuggetlenul. a kernelben is javitotam mar aprosagot, jo moka.;)

Anr - http://andrej.initon.hu

>>Miért fizetne nekem a cég azért, hogy más szemetét takarítsam?
>azert mert szuksege van arra a jol mukodo modulra. a Montavista/Redhat/IBM nagy penzeket szakit a linuxbol.
Lehet, hogy azért, mert én csak egy egyszerű vidéki versenyző vagyok, de be kell hogy valljam, hogy eddig csak ezeknél sokkal kisebb cégeknél dolgoztam, és ezeken a helyeken csak olyan dolgokra fizettek, aminek
- köze van a céghez
- látható, mérhető az előrehaladás
Nem fizetett a cég főállású kerneltaknyasztót, hanem ha kellett valami, akkor valamelyikünk megcsinálta, aztán ült vissza a dolgához, ui. nálunk az a kernelmodul nem cél volt, hanem csak eszköz. Gyakorlatilag az volt a hozzáállás, hogy inkább maradtunk a régebbi verziónál, minthogy beszálljunk ebbe soha véget nem érő ringlispílbe.

>>2., Miért nem az javítja a hibát, aki a hibás kódot írta?
>(a fejlesztő kiszállt, más nem állt a helyére)
Némiképp visszajutottunk oda, hogy ha a javításnak prioritása lenne az új dolgok beleírása előtt, akkor egy fejlesztő _le tudná zárni, be tudná fejezni_ a kódjának egy-egy verzióját. Ezek a 'lezárt' verziók, mivel új dolog nem kerül beléjük (az az újabbakba megy), csökkenő bugszámmal stabilizálódnának.
Ha ehhez hozzáveszed az API-k stabilitását (csak bővül, idejétmúlt cucc csak minor-váltáskor kerül ki belőle), akkor vígan ellehet egy kód évekig is, mire egyáltalán hozzá kéne nyúlni! Nem fejlődik, ez igaz, de stabil és működik. Sok fejlesztő szerintem pont azért hagyta ott az egészet, mert a napi nyolc óra meló után inkább foglalkozott a családjával esténként, mintsem hogy azzal szenvedjen, hogy aznapra épp mi és hogyan változott a kernelben, ami miatt megint túrni kell a kódot...

>>Miért van ennyi bug?
>az ok szerintem abban van, hogy a -mm fat
Ezek szerint akkor az '-mm' fa a 'testing'? Akkor miért nem úgy hívják? Ha én, mint egységsugarú luser szeretnék segíteni azzal, hogy tesztelek, hadd ne kelljen már vizsgáznom kerneltörténelemből, miért nem lehet a krumplit az egyszerűség kedvéért pl. 'krumplinak' hívni :) ?

>egyebkent te nem talaltal/javitottal kicsi bugot nagy opensource programban
Fordult elő, a kernelben is. Ellenben a levadaszni/megirni szerintem gyakran könnyebb, mint leellenőrizni. Pl. van valahol egy puffer-túlcsordulás, egy struktúrában char q[42] áll, kiderül, hogy ez nem elég. Nosza, legyen belőle char *q, nagy barátunk a malloc/free, hadd szóljon. Mármint a malloc, és a free hová is kell? Hoppá, nem csak a struktúra lebontásakor, hanem potenciálisan mindenhol, ahol ez a q balértékként szerepel, mert ott megbújhat egy realloc, tehát legyenek inkább függvények erre. "rgrep ha mondom, segít a gondon"... Aha, és mi van, ha valaki kivett pointert erre a q-ra, mi meg realloc-oljuk alatta? Innentől marad a MamaKedvence típusú szemantikus elemző, aki vagy elnéz valamit, vagy nem...
Amúgy az eleje tényleg jó móka :), az ellenőrzés már nem annyira. Ki is hagyják sokan...

"Sok fejlesztő szerintem pont azért hagyta ott az egészet, mert a napi nyolc óra meló után inkább foglalkozott a családjával esténként, mintsem hogy azzal szenvedjen, hogy aznapra épp mi és hogyan változott a kernelben, ami miatt megint túrni kell a kódot..."
Hogyha benne van a cucc a kernelben, akkor az esetleges interface változások miatt nem az egyszerű fejlesztő túrja majd a kódot, hanem az, aki az interface-t megváltoztatta. Lásd a híres-hírhedt stable_api_nonsense.txt-t.

"Ezek szerint akkor az '-mm' fa a 'testing'? Akkor miért nem úgy hívják? Ha én, mint egységsugarú luser szeretnék segíteni azzal, hogy tesztelek, hadd ne kelljen már vizsgáznom kerneltörténelemből, miért nem lehet a krumplit az egyszerűség kedvéért pl. 'krumplinak' hívni :) ?"
Szerintem pedig előbb mindenképpen nem árt tájékozódni.. Akinek már ez is sok, az nem hiszem, h érdemi bugreportot lenne képes írni...

> Akinek már ez is sok, az nem hiszem, h érdemi bugreportot lenne képes írni...

No szerintem te itt tévedsz egy hatalmasat. El tudok képzelni (gy. k. ismerek nem is egy) olyan embert, aki qrvára nincs otthon a Linux-kernel-fák sajátos szövevényében, de ha fog egy bugot, akkor azt képes _korrekt_ hibajeggyel jelezni.