Linux' TCP/IP-code komt als beste uit kwaliteitstest

Consulting groep Reasoning heeft van verschillende besturingssystemen bekeken hoe de TCP/IP-stack in elkaar zit en hoeveel programmeerfouten daarin voorkomen. Om welke besturingssystemen het precies gaat, wil men bij Reasoning niet kwijt, maar wel dat het om bijna allemaal varianten van Unix gaat. Niet alle onderzochte systemen zijn echter lid van de Unix-familie. Er is onderzocht in welk OS de minste fouten zaten per 1.000 regels code, waarbij speciale aandacht is besteed aan fouten met betrekking tot geheugenallocatie.

Wat men bij Reasoning wél kwijt wilde, is het feit dat Linux (specifieker: de GNU/Linux 2.4.19 kernel) als beste uit de test kwam. Linux bevatte slechts 0.1 fout per 1.000 regels programmacode, terwijl de andere sytemen tussen de 0.6 en 0.7 ('gewone' besturingssystemen) of 0.1 en 0.3 (embedded besturingssystemen) fouten per 1.000 regels code zaten. Hoewel dit niet noodzakelijkerwijs een enorme triomf voor het 'open source'-concept hoeft te betekenen, is het toch wel een aardige opsteker voor de ontwikkelaars van de GNU/Linux-kernel.

Het document van Reasoning is kosteloos te downloaden op de site van het bedrijf. Hiervoor dien je wel je naam en e-mail adres af te geven.

Reacties (71)

[Verwijderd]

In het verleden heb ik met dit soort software gewerkt als ik aan os hacken was. Het kan inderdaad nuttige dingen detecteren, maar zeker niet alle bug en het detecteerd ook constructies die geen bug zijn. Als je bijvoorbeeld een hr waarde terug krijgt moet je hier volgens die software op checken of deze geen error is. Dit hoeft in de practijk niet altijd, en dat kan je alleen zien als je echt in de code zit.
Een echt code review van 100 regels code koste ons meer dan 2 uur, ik geloof niet dat zij zo veel tijd hebben besteed.
Misschien kan ik meer in de whitepaper vinden, maar totnutoe lijkt het er op dat ze niets sturen. Een nutteloos raport, en wel heel arrogant om te roepen dat ze alle fouten kunnen vinden.

[Arx]

hoewel het natuurlijk praktisch onmogelijk is om zelf alle fouten te vinden, zijn er natuurlijk wel tools die je erbij helpen om die dingen op te sporen. Ik noem maar een code-profiler

Jammer genoeg worden er inderdaad niet de ernst van de fouten opgenoemd, maar aangezien ze het specifiek over de stack hebben zal het wel met de snelheid te maken hebben van de datastream. Deze zal wel instorten na een 'foutje'.

Voor de rest trek ik het onderzoek in twijfel zolang de definitie van "fout" niet wordt uitgeschreven. Misschien was de "fout" wel een interpetatie van de programmeur.

[Verwijderd]

Kortom hoe minder code, hoe minder fouten

[Verwijderd]

Nou eerder hoe groter de codebase, hoe meer tijd je aan reviewen en compatibilty testing je moet gaan besteden.

[cablepokerface]

Hoewel de schrijver van dit artikel op tweakers er allerlei toespelingen op probeert te maken ...

Niet alle onderzochte systemen zijn echter lid van de Unix-familie

('gewone' besturingssystemen)

Hoewel dit niet noodzakelijkerwijs een enorme triomf voor het 'open source'-concept hoeft te betekenen

... wil ik er ff bij zeggen dat MS windows niet een van de getestte OS-en was.

Ik heb het gevoel nl. dat de schrijver dat bewust een beetje vrij ter interpreteren gaf aan de lezer, opdat dit dan een overwinning leek van Linux op MS.

Op zich geen crime, maar ik zeg het er ff bij.

[wzzrd]

Dan zal ik even uitleggen waarom ik het geschreven heb zoals het er staat. Ik heb bewust meerdere dagen gewacht met het plaatsen van dit artikel, omdat ik de stukken van Reasoning zoals gezegd niet te pakken kon krijgen. Vandaag, na voor de zoveelste keer dat formuliertje ingevuld te hebben en wéér geen downloadlink te hebben gekregen, heb ik uiteindelijk het artikel toch maar gepost.

De informatie die ik wél tot mijn beschikking had, gaf geen uitsluitsel over het wel of niet tot het testgebied behoren van Windows of andere proprietaire besturingssystemen. Daar er echter in ieder geval één OS niet Unix-achtig was, kon ik niet uitsluiten dat het om Windows of MacOS ging. Het er expliciet bijzetten kon natuurlijk ook niet.

Het eerste citaat van mijn artikel dat je noemt wijst dus op hetgeen ik hierboven uitleg. Ik zeg daar in principe alleen, dat het niet in alle gevallen om Unices ging. Niets meer, niets minder.

Waar ik in je tweede citaat gequote wordt met ('gewone' besturingssystemen) doel ik eigenlijk alleen op het zijn van een 'gewoon' OS in tegenstelling tot een embedded OS. Ik doelde hier nadrukkelijk niet op iets dat ook maar in de verte met Microsoft te maken heeft.

In het laatste citaat waarin je me aanhaalt, zeg ik juist nadrukkelijk dat het GÉÉN enorme triomf voor het concept 'open source' is. We hebben te maken met een magere nieuwsbron, maar er is wel zoveel duidelijk dat we kunnen zeggen dat dit onvoldoende is om te stellen dat Windows wel in kan pakken. Zo is dit citaat ook niet bedoeld.

Tweakers.net probeert een objectieve berichtgeving te faciliteren. We proberen geen partij te trekken in de strijd tussen 'free' en 'propriety' software, hoewel iedereen natuurlijk zijn eigen persoonlijke mening heeft op dit vlak. Mensen die mij persoonlijk kennen, IRL, hier of op GoT, kennen mijn voorkeur, maar die staat hier volledig buiten.

Bovenstaande nieuwspost is wellicht wat beperkt in zijn berichtgeving. Daar zijn meerdere redenen voor. Dat neemt echter niet weg dat het een objectief bedoeld stuk is. Interpreteer het hoe je wil, maar het is géén reclame vóór open source, geen reclame tégen open source. Het is überhaupt geen reclame.

[cablepokerface]

wzzrd,

Bedankt voor je uitgebreide uitleg.

Ik geloof het als je zegt het artikel geschreven te hebben met de grootst mogelijke objectiviteit ...

Echter vind ik ook dat de informatie voorhanden (zoals je dat zelf ook verschillende malen expliciet zegt) misschien tekort schoot voor het maken van het artikel.

Ik zou het namelijk van essentieel belang vinden of MS Windows erbij betrokken zou zijn. Indien dit niet zo is, is het onterecht om het uberhaubt over open-source te hebben ... maar dit is dus niet bekend.

Misschien kun je nog een Update overwegen op het artikel.

[wzzrd]

Nee, dat ben ik niet met je eens. In tegenstelling tot wat de gangbare mening is, is open source in het algemeen en GNU/Linux in het bijzonder namelijk op de hele korte termijn minder een bedreiging voor Windows dan voor andere Unices. Het gaat hier wanneer ik het heb over open source en een (heel) klein overwinninkje van ze, dus niet over de tegenstelling tussen MS en de rest van de wereld. Ik zie overigens niet in waarom het onterecht is om het over open source te hebben wanneer Microsoft niet betrokken is bij een probleem / situatie. Microsoft heeft niets met open source te maken. Mochten ze willen

Wanneer ik (eindelijk) het rapport heb kunnen zien, zal ik wellicht overwegen om een update te plaatsen, mocht daar aanleiding toe zijn. De tijd zal het leren

[cablepokerface]

In tegenstelling tot wat de gangbare mening is, is open source in het algemeen en GNU/Linux in het bijzonder namelijk op de hele korte termijn minder een bedreiging voor Windows dan voor andere Unices

Is die mening wel zo gangbaar? De slag met andere Unices is reeds geslagen. (echt waar). Wereldwijd wordt vastgehouden aan bestaande systemen (IBM AS, HP UX, Solaris) maar de bittere waarheid is dat wat functionaliteit en groei betreft verdere ontwikkeling in deze OS-en eigenlijk gelijk verwezen kan worden naar het rijk der legacy. Op dit moment (en dan praat ik expres niet over de desktop markt) is de strijd wel degelijk tussen MS en de verscheidene Linux distributies.

Ik zie overigens niet in waarom het onterecht is om het over open source te hebben wanneer Microsoft niet betrokken is bij een probleem / situatie. Microsoft heeft niets met open source te maken. Mochten ze willen

MS heeft in zoverre met Open-Source te maken als dat zij degene zijn die er lijnrecht tegenover staan. Wat ze wel degelijk een belangrijke speler maakt in hoe de Open-Source gemeenschap (met name Linux) zich verder ontwikkelt.

Het is een hele discussie geworden (niets verkeerd mee begrijp me goed) maar het is eigenlijk terug te voeren naar een eerder geplaatst comment. Er had een regel in het artikel moeten staan in iets van de volgende strekking: "Het is niet bekend of er ook een MS OS in het onderzoek is meegenomen".

Het artikel laat teveel over aan eigen interpretatie. Veel mensen zullen de conclusie trekken die ze willen trekken en daar een artikel op t.net niet een expliciete mening kan/mag bevatten maar objectief de feiten weer moet geven (althans zo heb ik het altijd begrepen maar misschien ben ik naief ) leidt dit tot discussie over de aard van het onderzoek.

[deadinspace]

Ik zou het namelijk van essentieel belang vinden of MS Windows erbij betrokken zou zijn. Indien dit niet zo is, is het onterecht om het uberhaubt over open-source te hebben ... maar dit is dus niet bekend.

Het gaat over drie proprietary kernels, en één open source kernel. Hoezo is het dan onterecht om het over open source te hebben? Omdat Windows er niet bij betrokken is?

Je moet niet alles zo als een GNU/Linux vs Windows oorlog opvatten. Relevanter is hier "proprietary vs free". En ja, er is meer proprietary software in de wereld dan Windows.

[SED]

Daarom kun je een artikel meteen editten als je beter weet.
Vooralsnog staat ondanks je "objectiviteit" de onduidelijke en sugestieve formulering er nog steeds!
Nu verwacht ik van tweakersnet geen professionele journalistiek maar dit soort gedrag is onder de maat.

[zoeloelip]

Het zal ook wel niet over MacOS gaan want dat is ook gebaseerd op Unix. Als ik mij niet vergis.

[Verwijderd]

MacOS gebaseerd op UNIX? Neu. MacOSX stamt wel van die familie af (BSD).

Over ISN/PRNG van een boel verschillende OSen (ook closed source kun je op die manier testen):
http://lcamtuf.coredump.cx/newtcp

Rete interessant imo. Concludeert u zelf, zou ik zeggen...

(laat ik mijn beargumenteerde flame over Windows -gebaseerd op bovenstaand artikel- eens voor me houden )

[mxcreep]

en wat is BSD dan....juist....ook een unix variant...!

[Juup]

MS Heeft de code van FreeBSD gebruikt voor haar tcp stack in windowsen. Je mag aannemen dat ze daar niet veel bugs bijgeprogrammeerd hebben

[Verwijderd]

Wat zeg je me nou. Je hebt weer niets geleerd zie ik

[Verwijderd]

wil ik er ff bij zeggen dat MS windows niet een van de getestte OS-en was

Bij microsoft windows is het ook veel interessanter om te meten hoeveel advocaten per regel TCP/IP-code in windows ingezet worden om alle rechtzaken te vertragen.

Het aantal bugs per 1000 regels TCP/IP code in windows kun je wel redelijk schatten. Dat is het aantal fouten per 1000 regels TCP/IP code oorspronkelijk in *BSD (dus meer dan in het huidige *BSD, omdat de opensource community geen bugs fixed in windows) plus een aantal knip en plak en aanpassingsfouten, dus laten we het houden op tussen de 0,8 en de 1,2 fouten per 1000 regels code.

[deadinspace]

... wil ik er ff bij zeggen dat MS windows niet een van de getestte OS-en was.

Zowel de t.net nieuwspost als het originele artikel reppen niet over het feit of er al dan niet met Windows vergeleken is. Wel staat in het artikel dat het om de Linux kernel gaat, twee Unices en één andere kernel. Dat kan dus een Windows kernel zijn, maar dat hoeft uiteraard niet.

Als jij kan mededelen dat Windows niet meevergeleken is, wil je dan misschien ook even met ons delen waaruit je dat opmaakt?

[dawuss]

Ik vraag me af hoe veel regels code er hiervoor wel niet doorgespit zijn. Wel een beetje vreemd dat dit onderzoeksteam beweert alle fouten te kunnen herkennen. Waarom kunnen de programmeurs van de betreffende besturingssytemen dat niet meteen doen?

[Defspace]

Het is een stuk makkelijker fouten te herkennen dan op te lossen.

[Verwijderd]

Nou nou, er is (bijna) niets zo moeilijk als andermans code lezen hoor.
Je eigen code na bv. een jaar terug lezen valt al niet mee. En dan heb je nog het voordeel dat je je eigen manier van denken kent (als het goed is )
Vooral niet als het flinke lappen code zijn.
Je bent best wel effe bezig om alle routines etc. te snappen en door te krijgen hoe ze met elkaar interacteren.

[Skyclad]

Simpelere fouten kan een buitenstaander echter makkelijker vinden, aangezien de programmeur die het gemaakt heeft weet wat er zou moeten staan, en dat dus ook leest wanneer hij er naar kijkt.

Je kan in je eigen code 100x over een missend haakje heenlezen, terwijl je dat binnen 5 seconden bij een ander ziet.

[Verwijderd]

je kent de 80/20 regel toch wel? De laatste 20 procent van een 'perfect' project kost je meer moeite en geld dan die 80 procent.
Ofwel is kwestie kosten/baten. Op gegeven moment is 'accepteren' van bugs (let wel geen kritische he) goedkoper en misschien wel verstandiger dan 'the holy grail' na proberen te streven.....

Daarbij mensen die hier roepen 'haal die fout er dan uit', das wel heel simpel.... daarbij deze lui testen de software in feite, das heel iets anders dan het schrijven van software.

[Verwijderd]

Op gegeven moment is 'accepteren' van bugs (let wel geen kritische he) goedkoper en misschien wel verstandiger dan 'the holy grail' na proberen te streven

Oh dus dat is wat ze steeds bij Microsoft doen...

(Je kon er natuurlijk op wachten he )

[SED]

Dat doet IEDER besturingssysteem en leverancier.

Open source is daar beslist geen uitzondering op!

[vso]

de 80/20 regel lijkt me een beetje waardeloos zeker in de opensource gemeenschap "many eyes make bugs shallow" m.a.w woorden met vele ogen verdwijnen de buggies.

Bedoel niet dat ze weg zijn maar ideaal van de opensource gemeenschap is dat er weinig fouten zijn dus ik denk dat je opzich wel een punt hebt betreft de kosten/baten maar welke kosten als je het gratis doet ?

vraag me inderdaad af welke fouten zij hun bevindingen baseren ?

zo ver ik weet heeft BSD de beste TCP/IP stack niet voor niks dat mac-os (darwin) en win2k hun tcp/ip stack daar ook vandaan hebben....

[Bart B]

en volgens mij zit je daar fout. De rede dat macos en win2k/xp gedeelten van hun tcp/ip stack hebben uitgehaald is de licentie.
Bij BSD mag je wel gebruiken zonder je programma closed source te maken. Bij Linux valt de stack onder andere licentie dan BSD, waardoor het niet mogelijk om deze te gebruiken zonder de broncode van het hele programma waarin je het gebruikt open te maken.

[Verwijderd]

Ik vraag me af of/hoe ze non-oss systemen hebben getest?
Aangezien ze de (twijfelachtige) methode van aantal fouten / regels code gebruiken..
Belangrijker lijkt mij is de snelheid, stabiliteit bij zware load, en nog allerlei specifiekere dingen waar ik geen weet van heb

Al met al lijkt dit me niet zo'n goede test .. maarja, ik heb 'm ook nog niet kunnen downloaden

[Juup]

Het is pas een twijfelachtige methode als je hun uitgangspunt weet. Als ze zeggen: we willen het aantal fouten per 1000 regels code weten is het achterhalen van het aantal fouten per 1000 regels code de beste methode (duh)

Als het uitgangspunt is 'wat is de beste code' dan is dit wel een slechte methode. Maar dat doen ze niet.

Je mag aannamen dat ze de fouten publiceren zodat ontwikkelaars de fouten eruit kunnen halen.

[hiostu]

Het probleem is ook nog dat niet alle talen vergelijkbaar zijn met het aantal regels code. In sommige talen kost het implementeren meer SLOC per functiepunt dan een andere. Dus zolang dezelfde programmeertalen gebruikt worden kan dit een vergelijking zijn, anders niet helemaal.

[servies]

Er zijn maar een paar programmeertalen die voor besturingssystemen worden gebruikt, dat valt dus wel mee. In 99,9% wordt er voor een programmeertaal gekozen die zeer dicht tegen machinetaal aanligt, dus tot nu toe voornamelijk C.
Verder nog de opmerking wat stabiliteit betreft, als jij een goed ontwerp hebt en je voert het ontwerp foutloos uit dan is die code ook stabiel. Juist door ontwerp/programmeerfouten krijg je die instabiliteit.

[deadinspace]

Ik vraag me af of/hoe ze non-oss systemen hebben getest?

Lees het artikel?

The comparison was done with version 2.4.19 of the Linux kernel. For the comparison products, the company had access to the source code that for proprietary software is usually a closely guarded secret.

Ze hebben van de drie andere kernels hebben ze dus inzage in (dat specifieke deel van?) de source gekregen. Onder zware NDA etc natuurlijk.

[ronny]

Hebben de onderzoekers ook gelijk mee gedeeld wat en waar de fouten zaten zodat de laatste fouten uit de kernel gehaald kan worden

[Aetje]

Ja... Dan bevat Linux' laatste update morgen exact 0.0 fouten per 1000 regels code

[Ortep]

Het is een wat vreemde manier van testen. Als je voor je stack bv 20000 regels hebt en 1 fout per 1000 regel heb je 20 fouten. Maar als je 30000 regels nodig hebt om het te programmeren en je hebt 0.8 fout per 1000 regels heb je 24 fouten. Wie is er nu beter? En wat is de ernst van de fouten?

[Forage]

Wat is hier de exacte definitie van "een fout"?
Dat wordt mij niet helemaal duidelijk.
Ik realiseer mij dat het misschien lastig te om schijven is zonder te diep op de daadwerkelijke code in te gaan maar in het algemeen valt het vast wel te beschrijven.
Gaat het hier bv om data verlies?

[momania]

Even simpel dan:

Een goed voorbeeld van een fout is wanneer en in de code een stuk geheugen geadresseerd wordt, wat na gebruik niet geleegd wordt. Hierdoor krijg je zgn. memory leaks en als je die te veel hebt kunn je je voorstellen dat een "applicatie/deel van een OS" steeds meer geheugen gaat gebruiken terwijl dat niet nodig is...

[zonoskar]

Fouten zijn gewoon code-constructies die tot een ongewenst gedrag leiden, en dat kan van alles zijn. Bijv. een 'if-then-elseif' constructie zijn zonder 'else'. Zoiets dus:

if ( getal == 1 )
{
doe_iets();
}
else if ( getal == 2 )
{
doe_iets_anders()
}

Maar wat nou als getal gelijk is aan 3? Het kan zo gedesigned zijn, maar het kan ook tot een fout leiden.

[deadinspace]

Wat is hier de exacte definitie van "een fout"?
Dat wordt mij niet helemaal duidelijk.

Misschien dat het duidelijk wordt als je het artikel leest?

Reasoning looked for programming problems such as memory that was marked as free when it was in fact still in use, memory that was being used without being properly initialized and attempts to store data that exceeded the space reserved for it. This last problem is often associated with buffer overruns, a major weakness that under some circumstances can let an attacker take over a computer.

[arjankoole]

Wat ik toch wel het meest vreemde vind is dat Linus zelf ooit heeft gezegt dat de *BSD TCP/IP stack (de moeder van alle TCP/IP stacks aangezien TCP/IP is uitgevonden op Berkeley) vele malen beter is dan de 'implementatie' die hij in Linux heeft zitten. Sterker nog, hij liep toen de programmeur die aan de stack van Linux werkte aardig af te zeiken. (nou kan Linus dat vrij goed )

Ik meende me zelfs te herinneren dat ie zei dat ie liever de BSD stack ging poorten naar Linux. Dus als nu een onderzoeksteam met een compleet andere bevinding komt is dat op z'n minst 'opmerkelijk' te noemen.

[SED]

Sterker nog, bekend is dat juist de Linux stack een zorgenkindje is.
Uit dit ongedocumenteerde rapportje ( roddel dus eigenlijk?) blijkt ineens het tegendeel.
Zul je zien dat dit bericht blijft hangen bij de Linux fans en de beeldvorming weer geen goed doet.

Wat het tendentieuze en slecht onderbouwde rapport betreft kijk even hier:
Scheelt weer een hoop spam van een luguber bedrijfje.
http://www.reasoning.com/downloads/Open_Source_White_Paper_v1.1.pdf

[deadinspace]

Sterker nog, bekend is dat juist de Linux stack een zorgenkindje is.
Uit dit ongedocumenteerde rapportje ( roddel dus eigenlijk?) blijkt ineens het tegendeel.

En jouw onbeargumenteerde mening is zoveel beter?

[reddog33hummer]

Bedankt, hierdoor wordt veel duidelijk.

Ze werken met een automatiche scan tool waarvan ze aangeven dat 2% geen false positieves zijn.

Linux
Ze vonden 8 defects, 1 daarvan klopte zeker, 3 ervan wisten ze niet.

De rest: Heel veel... maar geen resultaat over wat wel en niet klopte.

Wat ik vreemd vind is deze zin:
"For reasons of client confidentiality, we cannot disclose further information about these projects."

Volgens mij belazeren ze de boel.
De OS'en zijn vermoedelijk van 1 klant.

[deadinspace]

Wat ik toch wel het meest vreemde vind is dat Linus zelf ooit heeft gezegt dat de *BSD TCP/IP stack (de moeder van alle TCP/IP stacks aangezien TCP/IP is uitgevonden op Berkeley) vele malen beter is dan de 'implementatie' die hij in Linux heeft zitten. Sterker nog, hij liep toen de programmeur die aan de stack van Linux werkte aardig af te zeiken. (nou kan Linus dat vrij goed )

Ik meende me zelfs te herinneren dat ie zei dat ie liever de BSD stack ging poorten naar Linux. Dus als nu een onderzoeksteam met een compleet andere bevinding komt is dat op z'n minst 'opmerkelijk' te noemen.

Linus heeft dat gezegd ten tijde van Linux net1, de eerste TCP/IP implementatie van de Linux kernel ja. Maar sindsdien is de TCP/IP implementatie van de Linux kernel alweer drie keer omgegooid en sterk verbeterd (waarvan één keer iig een complete rewrite was); tegenwoordig hebben we net4, de vierde versie van Linux TCP/IP implementatie

Kun je ook zien als een GNU/Linux box boot btw:

Linux NET4.0 for Linux 2.4

komt ergens langs.

[ritsjoena]

MS windows zal niet getest zijn.

De meeste software die ik ken (zoals bv purify (www.purify.com)) compileren de source met extra debug informatie zodat de software het programma kan volgen en daarmee veel fouten eruit kan halen. (zoals geheugenlekken e.d.).

Omdat je hiervoor de source van de software nodig hebt, denk ik niet dat ze MS Windows hebben kunnen testen.

[scorpie]

Als ik me niet vergis, heeft MS de tcp/ip stack wel deels vrijgegeven, en ze zouden ook een groot deel van de *BSD tcp/ip stack hebben "gepikt".

Ik denk dus wel dat ze MS OS's hebben getest aangezien 90% van de computers op OS's draait van MS.

[deadinspace]

MS windows zal niet getest zijn.

Omdat je hiervoor de source van de software nodig hebt, denk ik niet dat ze MS Windows hebben kunnen testen.

Uit het artikel (dat heb je toch wel gelezen als je zoiets post? toch?):

The comparison was done with version 2.4.19 of the Linux kernel. For the comparison products, the company had access to the source code that for proprietary software is usually a closely guarded secret.

Reasoning had dus inzage in de source van de proprietary kernels, waarschijnlijk onder een zware NDA.

[Guru Evi]

Wel een paar jaar geleden stond er een test in ClickX over de verschillende TCP/IP stacks en die van OS/2 is gebaseerd op FreeBSD, Windows 95 en 98 hadden toen een zelf geprogrammeerde en Linux had ook een. De OS/2 TCP/IP stack was toen de snelste en die van M$ de traagste ;-)
Bugs is altijd leuk. Moeten er blijven inzitten tegen dat ik eens mijn serverke wil openmaken als die dichtgeslagen is ;-)