Hver fjerde dag opstår ny fejl i Linux-kernen

Det anslåes nemlig, at der hver fjerde dag bliver tilføjet en ny bug til kernen.

I min verden er det da også dumt at tilføje bugs til kernen...

Det store spørgsmål er vel hvor mange bugs der bliver rettet hver dag...
Øger de det samlede antaled med 1/4 bugs hver dag, eller tilføjer de f.eks. 1/4 bug, men retter 10, så det samlede antal falder?
Uden den information er nyheden absolut intet værd.

Ret mig hvis jeg tager fejl, men jeg forstår det således:
Hver dag rettes 65 ting / fejl (Patch = rettelse, såvidt jeg ved)
Hver 4. dag er der i blandt disse rettelser én ny fejl.
65 * 4 = 260
Altså kommer der en ny fejl for hver 260. rettelse. Det er da en acceptabel fejlrate, omend det kommer meget an på hvor alvorlige en 'bug' er i forhold til det der rettes med en 'patch'.

#3
Patches er for det meste tilføjelse af nye funktioner, support for nyt hardware eller optimering af gammel kode.

#3

En patch behøver ikke nødvendigvis rette en fejl. Du kan også indsende en patch, der gør at en SCSI driver kan klare endnu et chipset.

#3
Du glemmer at en patch også kan komme med nye funktioner og altså ikke kun fejlrettelser.

hmmm... jeg synes generelt at den debat er begyndt at blusse op op til flere steder og det er absolut kun relevant at få trukket gardinerne fra. Jeg synes debatten har været meget hård mod Microsoft - de er stort set altid blevet klandret for at være bug-befængte. Om ikke andre OS-udviklere har samme problemer men lever i det skjulte (fx Apple) så er det rart at se at nogle i det mindste vil ha sænket hastigheden på udviklingen for at komme bugs til livs. Men selvfølgelig - jo færre udviklere, desto mere kontrol.

Det er måske også lige værd at nævne at det der tales om her er udviklingsversionen af kernen - så et overvældende flertal af de bugs vil blive rettet inden kernen havner på f.eks. min computer...

Hah, kun hver fjerde dag? Med så mange programmører? Det lyder da rigtigt godt. Når jeg koder alene laver jeg over fire kritiske sikkerhedsfejl i timen :)

Hvis det udviklingsversionen som #8 siger - så forsatan, så er det da virkelig noget at flæbe over?
Og når de nu kan lave denne statistik så betyder det jo at de finder 100% så er det jo fint :)

#7

Så er det rart at se at nogle i det mindste vil ha sænket hastigheden på udviklingen for at komme bugs til livs

Det er vist en misfortolkning. Det handler bare om at de vil lave workflowet lidt om. Ved ikke lige hvordan det blev en nyhed.
#7

Men selvfølgelig - jo færre udviklere, desto mere kontrol.

Ah, det kan du vist ikke sige. Med flere udviklere er der ganske vist flere til at lave fejl, men der er jo også flere til at læse koden i gennem.

Det er vel ikke noget nyt - er det ikke 2-3 fejl per KLOC (kilo linjer af kode) man plejer at regne med? De graverende fejl bliver naturligvis fanget under test, mens de obskure nogen gange bliver til exploits :-)

[url=#9]#9[/url] KaW

Når jeg koder alene laver jeg over fire kritiske sikkerhedsfejl i timen :)

Nu fik du mig til at tænke på dengang jeg var instruktor på uni i et kursus om operativsystemer. Jeg sad med en stak besvarelser jeg skulle rette, ikke den mest spændende beskæftigelse, men det skal jo gøres. Opgaven gik ud på at tilføje et systemkald til Linux, som kunne hente nogle specifikke oplysninger ud fra vm. Så jeg tog fat i den første opgave, og kiggede på den første side. Det tog mig kun et sekund før jeg havde fundet et sikkerhedshul. Så satte jeg mig foran computeren og skrev et root exploit til deres kode.

De havde glemt at bruge copy_to_user, i stedet lavede de bare indirection gennem den pointer der var blevet givet som parameter til systemkaldet. Den bug skulle så bare misbruges to gange for at få root, den første process ville crashe sig selv for at tvinge kernen til at lave et registerdump. Den næste process kunne kigge på registerdumpet for at finde sin egen placering i hukommelsen og dernæst udnytte hullet igen for at overskrive sit eget uid med nul.

Så vidt jeg husker lavede jeg en slide med den sårbare kode og præsenterede den for hele holdet. Jeg håber der i det mindste var nogen af dem, der lærte noget af det. Desværre gør uddannelsen ikke særligt meget ud af de sikkerhedsproblemer der ligger i dårlig kode. Der er kurser i sikkerhed på lidt højere niveauer som f.eks. kryptering, signaturer, javas sikkerhedsmodel og teorier til at lave beviser om den slags modeler.

Men et kursus i hvad kvaliteten af kode har at sige for sikkerheden er der ikke. Lav et kursus hvor de studerende får hver deres virtuelle computer, hvortil de skal skrive hver deres webserver i C. Dernæst kan de få lov at hacke hinandens webservere. Jeg tror sådan et kursus kunne blive meget lærerigt. For de vil blive overrasket over, hvor mange fejl man kan begå, når man blot skal implementere en webserver til at servere statiske sider.

#2 Siden linus thorvalsen skriver mailen må han jo betragte det som et problem. Den situation du beskriver hvor der rettes 10 bugs for hver gang der tilføjes en kan vel næppe kaldes et problem, så din logik knækker der.

Det er naturligvis et problem når patches så hurtigt. Linux skal leve af at være et godt alternativ til windows, ikke bare et gratis. Det øjeblik hvor antallet af bugs bliver et problem for stabilitet og sikkerhed, så er linux ikke længere et godt alternativ men kun et gratis alternativ, og så dør det hurtigt.

Derfor er linus thorvalsens bekymring yders realt!

øh... hvor er det dog imponerende tydeligt at ikke ret mange læser nyheden... det det handler om, er at der sker så meget nyt, at det kan være svært at fange alle fejlene i farten... Linus siger bl.a. at med så mange ændringer hele tiden, vil der ske fejl (og ja, det er "udviklingsversionen" det handler om)... man kan se det som en slags advarsel om at man lige børe være lidt mere opmærksom...

"Even by the most *stringent* reasonable rules, we add a new bug every four days. That's just something that people need to accept. The people who say 'we must never introduce a regression' aren't living on planet earth, they are living in some wonderful world of Blarney, where mistakes don't happen, developers are perfect, hardware is perfect, and maintainers always catch things."

synes i øvrigt Bartlomiej's historie er ret skræmmende (noget med noget kode han havde til review og gav kommentarer på, men blev ignoreret efter det, og dette kode endte til sidst i kernen)...

#14 jo, det er noget med at der rettes flere fejl end der laves nye... det er da stadig noget skidt at introducere nye/fremprovokere gamle fejl uanset om det er færre end der bliver rettet eller ej...

*Offtopic*
#13
Det lyder faktisk som en rigtig god idé og utrolig lærerigt. Det vil jeg foreslå min underviser, så ville bare lige sige tak til dig for den pragtfulde inspiration, inden jeg selv løber af med al æren.