Dette indlæg er alene udtryk for skribentens egen holdning.

Garbage In, Garbage Out

23. februar 2021 kl. 16:2823
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Hvor meget programkildetekst er der egentlig involveret i en FireFox browser ?

Jeg tyer med vilje til en meget ulden formulering med ordet "involveret" for alene grænsedragningen af hvad der skal tælles er der skrevet hele bøger om[1].

Men vi er nødt til at starte et sted, så jeg tog en helt frisk FreeBSD-Current installation og lavede en "make patch" i alle de 288 ports som "make missing" siger www/firefox manglede.

Nogen tid senere er det en smal sag at se hvad der så er dukket op på maskinen: 1047884 filer.

Artiklen fortsætter efter annoncen

Derefter tog jeg de filnavn-suffix jeg umiddelbart genkendte som kildetekster og optalte hvor mange linier der var af den type filer:

    .suf     files     lines
    ------------------------
    c       130235  74179467
    h       107991  29882215
    js       76692   8403700
    cpp      54493  20242024
    rs       42929   9240275
    ri       29173    130275
    py       17744   4108043
    s        16447   4699134
    xht      14569    571662
    rb        9939   1527856
    sh        6763   1960152
    cc        6247   2832713
    m4        5610   2188662
    pl        4047   2305113
    S         3981   1345954
    java      1961    484445
    tcl       1509    538610
    hpp       1163    191427
    cxx       1007    372144
    hh         286    132170
    sed        126      2678
    awk        107     24428
    bash        51      2613
    hxx         25      3381
    ------------------------
    Total   533095 165369141
    ========================

(De resterende 471860 filer er dokumentation, makefiles, test-cases osv. glem dem.)

Summen er naturligvis dybt problematisk på næsten alle tænkelige metoder, vi er næppe indenfor ±50% land her.

Til den ene side mangler hele det FreeBSD system som FireFox i mit tilfælde kører på (+ ca. 10%) og den X-server med "DRM" kode der laver det tunge grafiske arbejde (+ who knows?)

Artiklen fortsætter efter annoncen

På den anden side vil man utvivlsomt hurtigt og sikkert kunne dømme en masse af filerne ude med gode og sunde argumenter.

Da de stabelafløb hangarskibet CVN-75, "Harry S. Truman" udbasunerede skibsværftets PR-afdeling at der var "over en million forskellige dele i skibet", det tal gravede jeg lidt i og i bund og grund holder det[2].

Men hangarskibe er seriebyggeri, CVN 75 var nominelt magen til de ni andre i "Nimitz-klassen", så selv inden for den træskolængde vi arbejder med her er FireFox formodentlig ti gange mere komplex end alle USAs hangarskibe tilsammen.

Uanset hvilken stor ingeniørbedrift jeg sammenligner med, blegner den ved sammenligning med FireFox.

CERN's LHC, ITER, Rumfærgen, Apollo, Den Trans-iranske Jernbane, Hoover Dam, Manhattan-Projektet, eller AT&T's (planlagte) WT4 mikrobølge rør tværs over USA - ingen af dem er indenfor en størrelsesorden af FireFox i komplexitet.

»Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.«
(Antoine de Saint Exupéry)

/phk

PS: Hvis FireFox koden er af typisk kvalitet, er der er fejl for ca. hver 1000 linier kode[3].

[1] Men bare rolig: De er allesammen skrevet før 1990, så der er ingen fare for at nogen læser dem.

[2] AIrbus A380 er blevet tilsvarende udbasuneret som bestående af "over 4 mio individuelle dele", men rigtig mange af dem er helt identiske skruer, plastic-clips osv.

[3] Men jeg er i godt humør i dag, så I behøver kun finde halvtrestusinde.

23 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
23
2. marts 2021 kl. 12:07

Det er faktisk grunden til, at der findes både ingeniører og håndværkere. Arkitekten tegner oftest afkoblet fra fysikken og med fokus på oplevelsen for brugeren i første omgang, og bliver så i stigende grad i gennem byggeriet udfordret af netop spættesikring og andet bøvl.

Hvilket kan opleves som en modbydelig og krænkende proces for de frieste kunstneriske fugle, der også skal have noget at leve af. For at undgå at blive alt for indskrænket senere, bruger man så de tidligere løsninger + lidt ekstra -noget vigtigt.

En af de store forskelle på byggeri og software er, at byggeri på ingen måde kan stables uden at der er styr på tyngdekraften og synlig skimmelvækst.

Med renderinger, photoshop og snedige fotografier fra droner er vi dog på vej ud af et farligt spor, fordi det bliver svært at se forskel på ideer og virkeligheden.

Som med alt andet handler det ikke om hvad de dygtigste kan gennemskue, men snarere hvad røven af 4. division er i stand til at gennemskue.

22
28. februar 2021 kl. 19:33

Noget size bloat er af ret gode grunde – kode optimeret for hastighed fylder (nogle gange meget!) mere end kode optimeret for størrelse.

Helt rigtig, ja. Men de tabeller fylder vel ikke så meget i disk filen?

En anden ting er at linke ukrtisk til biblioteker og deres namespaces. Hvis man f.eks. skriver: using std; i sin cpp fil, får man en mere med end man måske behøver.

Så er også forskellige x86-devices, som hvis SW skal virke på dem alle sammen har betydning for exe-filen.

Men nogle gange kan da mistænke, at alt muligt l... er linket med i 4K;)

21
28. februar 2021 kl. 15:50

Hvorfor bliver et eksekverbart program pludseligt dobbelt så stort, uden at der er ændret en linje i source, bare fordi man bruger næse generation compiler?

Noget size bloat er af ret gode grunde – kode optimeret for hastighed fylder (nogle gange meget!) mere end kode optimeret for størrelse. (Man kan så diskutere om man burde have size på størstedelen at koden og nøjes speed på hotspots...)

Andet er på grund af sikkerhed. "I gamle dage" linkede man typisk win32 apps med statisk baseaddress til 0x400000, men for at få ASLR skal du outputte relocations, som fylder noget. Og fx Control Flow Guard tilføjer både tabeller og ekstra kode.

20
27. februar 2021 kl. 21:36

Og hvornår ser vi mon at nogen begynder at skære produkterne ned til det der er brug for. Hvorfor bliver et eksekverbart program pludseligt dobbelt så stort, uden at der er ændret en linje i source, bare fordi man bruger næse generation compiler? For at undgå for mange "tommel-ned", dette er set in Windows verden.

Hvornår begynder man at at dyrke "requirement scrubbing" ?

19
25. februar 2021 kl. 21:41

Har ud en idé om hvor stor en procentdel af source-filerne der er autogenererede? Det ville ikke undre mig hvis der er forskellige parsers eller OS-interfaces der er autogenererede, så de ikke følger standard "bugs per linje" metrics.

Men det er godt nok noget af en omgang, uanset!

18
24. februar 2021 kl. 22:46

Forestil Jer at arkitekter skulle designe en bygning der konstant ændrede form, var multidimentionel, og skulle overholde regler for at være rigtig... Tror ikke arkitekter kunne klare det problem. I dag har de også ingeniører til det komplekse,. Så laver de i det mindste ikke ulykker, mens de drømmer om at være kunstnere uden sans for funktionalitet og proportioner.

Er som søn af arkitekter fra den gamle skole lidt farvet, men jeg har mødt mange IT folk som får ticks når det gælder byggebranchen generelt. Tror det skyldes at IT folk er vandt til at håndtere højere kompleksitet.

16
24. februar 2021 kl. 15:37

Også for længe siden blev det sagt (af sælgere), at hvis biler havde udviklet sig som computere, så ville en Folkevogn kunne være i en tændstikæske, kunne transportere 100 mennesker og køre 15.000 km på en liter benzin. Formuleringen varierede noget. Måske skulle man sige, at hvis flyvemaskinen havde udviklet sig som computerne, så ville den besidde enorm motorkraft. Men en kanalflyvning ville være en meget vovelig affære.

Det var vist Bill Gates der fik kastet den første (dokumenterede) sten i dén fejde tilbage i '97:

http://web.archive.org/web/20090114203618/http://www.microsoft.com/presspass/exec/billg/speeches/1997/comdex97.aspx

Han sammenlignede også med prisen på morgenmadsprodukter. Og så kan man jo fundere over om de ultra billige havregryn ville fryse eller eksplodere hvis de serveres i en ikke kompatibel skål - eller bliver blå og giftige (BSOD) hvis der drysses brunt rørsukker på istedet for hvidt roesukker.

13
24. februar 2021 kl. 11:00

Er der en reference jeg mangler eller er det bare en generel kommentar ift. softwareudvikling?

12
24. februar 2021 kl. 08:55

Godt spørgsmål... jeg tænker nej! Vi har bare ikke hørt om det (hele) endnu.

9
23. februar 2021 kl. 20:51

Et eller andet sted læste jeg for lang tid siden det bedrøvede udsagn, at hvis arkitekter byggede huse, ligesom programmører skrev programmer, ville hele civilisationen ikke overleve det første møde med en spætte.

Foreløbig har vi overlevet mødet med folk værre end spætter. Men jeg er da godt nok bekymret.

Også for længe siden blev det sagt (af sælgere), at hvis biler havde udviklet sig som computere, så ville en Folkevogn kunne være i en tændstikæske, kunne transportere 100 mennesker og køre 15.000 km på en liter benzin. Formuleringen varierede noget. Måske skulle man sige, at hvis flyvemaskinen havde udviklet sig som computerne, så ville den besidde enorm motorkraft. Men en kanalflyvning ville være en meget vovelig affære.

Hvad er det egentlig, der gør, at det ikke er gået værre? Venter det hele bare på den rigtige diabolske person, hackernes Fu Manchu? Eller falder det hele sammen af sig selv under vægten af uigennemskuelige fejlrettelser og forbedringer?

7
23. februar 2021 kl. 20:31

FreeBSD har 17040912 linier C kode i mit træ netop nu.

I princippet skal du regne microkoden i CPU'en med.

Men ja, det hele er blevet meget stort. Resultatet er at man kan spytte avancerede applicationer ud på rekordtid. Min start med IT var en RC Piccolo+CPM80+Comal-80. Sikkert i størrelsesordenen 10-50 kloc. Applikationerne var derefter.

6
23. februar 2021 kl. 20:24

fixet.

Så kan du vel også "fixe" det manglende "er" i ".. , vi næppe ..". ;-)

4
23. februar 2021 kl. 18:46

Hvor mange linier er der i Varnish, hvis du bruger samme metode?

3
23. februar 2021 kl. 18:25

Kunne være interessant at se en tilsvarende optælling på Chromium eller Windows eller BSD for den sags skyld.

Men hold da op - gad vide hvor meget død kode der er i de 165.369.141 linjer.

1
23. februar 2021 kl. 17:04

Det er kun små 10 mio linjer, men du har vist talt Rust koden dobbelt?

Og ja, det er vildt - men en meget stor del af det handler om at få god performance. Det ville være en sund øvelse at lave den enkleste sikre, moderne browser.

P.S. Det er lille "f" i midten, Firefox.