Vi har sejret ad helvede til...

Forleden stod jeg sammen med en af veteranerne fra SSLUG og savnede de gode gamle dage med Open Source Days osv.

Vi måtte dog erkende at den tid var definitivt forbi, for vi har sejret ad helvede til.

En ny EU rapport sætter tal på:

"It is estimated that companies located in the EU invested around €1 billion in OSS in 2018, which resulted in an impact on the European economy of between €65 and €95 billion. The analysis estimates a cost-benefit ratio of above 1:4 and predicts that an increase of 10% of OSS contributions would annually generate an additional 0.4% to 0.6% GDP as well as more than 600 additional ICT start-ups in the EU. Case studies reveal that by procuring OSS instead of proprietary software, the public sector could reduce the total cost of ownership, avoid vendor lock-in and thus increase its digital autonomy."

Nogen fra de bonede gulve bør give SSLUGs bestyrelse en fortjenstmedalje, for at have hevet landet ind i fremtiden.

phk

Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Nis Schmidt

Er du helt sikkert på det? Eller har lønningerne i branchen nået et niveau, hvor det ikke giver mening mere?

Hvor meget bidrager OSS til samfundet i forhold til Kine-produceret forbrugerelektronik? En simpel "app" koster millioner og bruges et par måneder. Jvnf Comic Agilé.

Du kommenterede, at MIT's visning af at spændvidden i software ydelse byggede på eliminering af "crap" (var vist det ord du brugte).

En matrix multiplikation af to kvadrat matricer (med sidelængde 4096) tog 7 timer i Python mod under et halvt sekund (0.5s) i C ved brug af "tiling" og vektorinstruktioner! Der var ikke luget ret meget død kode, men derimod skrevet mere kildetekst, som blev afviklet mere effektivt ved fornuftig brug af cachen.

Okay, eksemplet er fjollet hvis man ikke lige laver "adaptiv optik i kode", men essensen holder: koden bliver ikke mere effektiv af "håndkompilering og bitfnidder", men effektiv brug af cache ($), det var vist også ca Georg Poulsens pointe - i hans tid.

OSS fører til en masse kode, som kritikløst inkluderes (og brænder en masse CPU-cykler af), i stedet for at tænke hvordan en opgave bedst (hurtigst) løses.

Alternativet er at bruge rigtig mange penge på IBM z15 CPU'er (eller nyere).

  • 3
  • 36
#4 Nis Schmidt

IBM Telum

Det fænomen er på ingen måde isoleret til FOSS, tværtimod nærmest, i closed source er der bare ingen der kan se det.

Der findes ganske rigtigt fatware over alt, bare tegn kurven over en Windows-installation gennem tiden; fra få 3½" disketter til en DVD.

Det gjorde jeg for 19 år siden (skråt/skrodt op:), men kurven over"cache miss penalty" går den modsatte vej (tidstab/cache-misses).

Med "goodbuy"-ware sætter prisen (næsten) grænsen for spild af "disk-space"; med "bugware" køber man bare en ny (større) disk.

De er klart, at "de selvfede" hopper på "FOSS" ;-)

  • 0
  • 25
#8 Gert Madsen

Før et eller andet stort offenligt IT projekt kasseres fordi koden ikke skalerer til den nødvendige belastning (host Polsag host).

Lige her er Polsag nok ikke så godt et eksempel.

Det var jo et bevidst valg at basere Polsag på et produkt, der var udviklet til et andet formål.

Dermed slæbte man rundt på masser af uanvendt kode, som formodentlig både leverandøren og ledelsen ville beholde for bibeholde et skær af "standard hyldevare".

Ekstra indlejret kode, som var kommet med fra diverse standardbiblioteker var vist det mindste problem.

  • 5
  • 0
#9 Poul-Henning Kamp Blogger

Det var jo et bevidst valg at basere Polsag på et produkt, der var udviklet til et andet formål.

Dermed slæbte man rundt på masser af uanvendt kode, som formodentlig både leverandøren og ledelsen ville beholde for bibeholde et skær af "standard hyldevare".

Mnjoe, jeg synes egentlig det er et godt og relevant eksempel:

Man valgte at bruge et sags/journaliseringsystem, som er fokuseret på netop behandling af enkelte sager, til at løse en opgave hvor netop mulighed for at søge på tværs af og sammenkæde sager var det største behov.

Mao: Politisk dikteret IT-arkitektur med hovedet under armen.

  • 16
  • 0
#10 Palle Due Larsen

OSS fører til en masse kode, som kritikløst inkluderes (og brænder en masse CPU-cykler af), i stedet for at tænke hvordan en opgave bedst (hurtigst) løses.

Efter 35 år i IT-branchen har jeg endnu til gode at skulle gange to matricer sammen. Derimod har jeg tit skullet bruge en gennemprøvet standardkomponent, som OSS har kunnet tilbyde mig. Der er udvikingstiden og ikke afviklingstiden, der er den vigtige parameter i de fleste projekter.

  • 22
  • 0
#12 Povl H. Pedersen

Ikke alt OSS giver pengemæssig værdi. Og noget som Home Assistant der tillader en at lave smarthome med et stort kludetæppe af produkter mindsker samfundets vareomsætning. Der er ikke mange der kunne drømme om at købe Philips Hue når man kan det hele med IKEA pærer i stedet for. Og hvad skal man med et alarmsystem når man kan købe generiske zigbee, 433MHz og WiFi sensorer til lavpris og koble til Home Assistant i stedet for ? Det er et projekt der drives i høj grad fra EU.

Er det super effektivt, det er det nok ikke. Men det er smart at mange komponenter (database etc) kan installeres i containers.

Der er flere home automations ystemer, som låner integrationer fra hinanden.

Så dette er et område hvor BNP ikke vokser væsentligt, men det gør forbrugernes formue.

  • 0
  • 0
#14 Nis Schmidt
10:

Efter 35 år i IT-branchen har jeg endnu til gode at skulle gange to matricer sammen.

Så må du være en af de heldige. Min første gang går 36 år tilbage, hvor vi vandt en kunde på den.

10:

Der er udvikingstiden og ikke afviklingstiden, der er den vigtige parameter i de fleste projekter.

Undtagen for kunderne/brugerne! Mit ynglingseksempel er Sundhedsplatformen, hvor lægen på et københavnsk hospital brokkede sig over, at "den var langsom". Jeg var på den "forkerte side", så det var ikke morsomt at høre på.

11:

Man kan brænde mange CPU sekunder af for en million kroner. Og det bliver bare billigere med tiden.

Ja, det kan man og cyklerne bliver billigere - til et vist punkt. Som min matematiklærer i gymnasiet sagde, "vi er alle me'talarbejdere" - ligesom Georg Poulsen. Det eneste der aldrig bliver billigere er udvilkertid. Hvis man brugte Test Drevet Udvikling rigtigt kunne man (i min erfaring) spare tid i udviklingen - og bruge den på bedre planlægning.

Men der er ikke den store forskel på FOSS og proprietær, når det kommer til at tage ansvar for kodekvaliteten. Begge sider bruger de samme (formuleringer i deres) DISCLAIMER.

  • 1
  • 9
#15 Morten Mathiasen

Jeg elsker og bruger næsten udelukkende OSS i mine udviklingsprojekter - det første fix med OSS er jo gratis :-) Desværre bruger software leverandører og kunder KÆMPE ressourcer på fejlretning, måske 10 gange så meget tid på fejlretning som på nyudvikling, hvilket måske er det største problem i vores software industri! Generelt leder OSS til flere fejl end betalt software. Mit indtryk er at OSS er dårligere dokumenteret, har svagere support og koden er ofte udviklet med ét mål for øje, så kun en smal sti i dens anvendelse virker optmalt.

  • 0
  • 16
#17 Christian Nobel

Den der inkluderer er ikke udvikleren af OSS, det er den der bruger det.

Ahhr, det kan man vist ikke sige.

Nis har sådan set et pointe, men det har intet med om hvorvidt vi taler OSS eller CS, nemlig det at mange udviklere inkluderer et hav af libraries ukritisk, hvorved selv en simpel Hello World ender med at blive et monstrum - det ses jo ret tydeligt med mange "apps" som er perverst store, trods det deres funktionalitet er beskeden.

Brugeren af et givet program eller en app har ingen indflydelse på hvor få eller mange libraries der er inkluderet.

Men som sagt, det har bare ikke noget med OSS vs CS at gøre - ved OSS er der dog den fordel at man kan kikke ned i motorrummet, det kan man ikke med CS.

  • 2
  • 0
#18 Christian Nobel

Desværre bruger software leverandører og kunder KÆMPE ressourcer på fejlretning, måske 10 gange så meget tid på fejlretning som på nyudvikling, hvilket måske er det største problem i vores software industri!

Og er det forskelligt om vi taler OSS eller CS?

Generelt leder OSS til flere fejl end betalt software.

Er det noget du kan underbygge?

Og ved du overhovedet hvad OSS er?

indtryk er at OSS er dårligere dokumenteret

Aha, og er det noget du kan underbygge, og hvad anser du for "at være dokumenteret"?

har svagere support

Svagere support - som i at der er et sted man kan ringe og tale med en inder der ikke fatter hvad man siger?

Support kan jo også ligge i et kompetent community.

og koden er ofte udviklet med ét mål for øje, så kun en smal sti i dens anvendelse virker optmalt.

Og det er noget du har evidens for?

  • 10
  • 1
#19 Torben Mogensen Blogger

En matrix multiplikation af to kvadrat matricer (med sidelængde 4096) tog 7 timer i Python mod under et halvt sekund (0.5s) i C ved brug af "tiling" og vektorinstruktioner!

Det giver ikke mening at sammenligne en naiv algoritme i Python med en højoptimeret algoritme i C. Hvis du kodede naivt i C og brugte NumPy eller lignende i Python, var det nok Python, der vandt den sammenligning.

Python er (ligesom Matlab, R og Maple) ikke designet til, at man koder de beregningsintensive dele i sproget selv, men derimod i så høj grad som muligt kalde præoptimerede biblioteksfunktioner (som ofte er kodet i noget andet, f.eks. C, Futhark, eller OpenCL).

Men den dikussion har i øvrigt meget lidt med open vs. closed source. Udover at man ved open source selv kan identificere flaskehalsene og (afhængig af licensen) erstatte naiv kode med optimeret.

  • 11
  • 0
#20 Finn Aarup Nielsen

En matrix multiplikation af to kvadrat matricer (med sidelængde 4096) tog 7 timer i Python mod under et halvt sekund (0.5s) i C ved brug af "tiling" og vektorinstruktioner! Der var ikke luget ret meget død kode, men derimod skrevet mere kildetekst, som blev afviklet mere effektivt ved fornuftig brug af cachen.

Det må referere til et situation fra forrige årtusinde. En almindelig matrix-multiplikation kan gøres hurtigere, - omkring 25 millisekunder i Python:

import numpy as np  
import timeit  
N=4096; A = np.random.random((N, N)); timeit.timeit(lambda: A*A, number=1)  
0.02582312400045339
  • 2
  • 3
#21 Nis Schmidt

Ad #19:

Det giver ikke mening at sammenligne en naiv algoritme i Python med en højoptimeret algoritme i C. Hvis du kodede naivt i C og brugte NumPy eller lignende i Python, var det nok Python, der vandt den sammenligning.

Det er vel, som man ta'r det. Eksemplet var ikke mit, men gengivet som journalistisk artikel i Version2 (kopieret fra norsk kilde, 15-jun-2020) og stammer fra introduktionsforelæsningen til MIT's kursus 6.172, som du og andre kan finde på Open Course Ware, hvor jeg selv fandt det i (i 2010-udgaven) ca 2012. Selvfølgelig er det ekstremt. Det er nok derfor python-udgaven er en enkeæt tråd og parallitet indføres senere.

Før det havde jeg selv brugt 'matmul' i min danske bacheloropgave fra feb 2011, hvor jeg undersøgte virkningen af at transponere B-matrix, så dens multiplikation kunne udføres "liniært" ift cachen.

Men den dikussion har i øvrigt meget lidt med open vs. closed source. Udover at man ved open source selv kan identificere flaskehalsene og (afhængig af licensen) erstatte naiv kode med optimeret.

Ja, men hvor mange kan og gør det?

Ad #20; Mange compilere optimerer beregning resultater, der ikke bruges helt væk. Prøv at gemme resultaret og se om tiden holder?

  • 0
  • 11
#22 Christian Nobel

Ja, men hvor mange kan og gør det?

Du har ikke rigtig fanget pointen vel?

Hvis jeg har en right to repair dims (og det kan også være OSS!), så kan jeg, hvis jeg ikke selv kan gøre det, opsøge en der kan reparere tingen.

Hvis vi skulle følge din filosofi, så må jeg ikke engang åbne motorhjælmen på min egen bil (eller en John Deere traktor - gys) og hvis jeg har mere tillid til min egen mekaniker end haps&gnask's værksted, så må jeg heller ikke bruge ham.

Eller hvis min McFlurry maskine bliver ved med at fejle, så skal jeg blive ved med at lade nogen jeg ikke har tillid til reparere den.

Og, og, og ......

Så der er ingen der siger at man selv skal rode med koden, men man har friheden til at lade andre gøre det, eller få en second opinion.

  • 8
  • 1
#23 Sven Waskönig

Det forekommer mig, at mange stadig har fordomme og forudintagelser omkring open source og closed source.

F.eks. at open source altid er gratis, at closed source er bedre testet / mere fejlfrit, at open source er mere sikkert osv.

Efter min opfattelse består forskellen helt grundlæggende i, hvorvidt kildekoden er tilgængelig eller ej. That's it.

Alt andet afhænger i høj grad af, hvilke beslutninger leverandøren har taget omkring sikkerhed, test, stabilitet mv. samt hvordan man vælger at tjene sine penge.

  • Open source software kan godt koste penge. Mange har vel bare valgt at gøre det gratis, fordi man tjener sine penge på noget andet.
  • I princippet kan der potentielt være flere øjne på en open source løsning, fordi kildekoden er tilgængelig. Om der er det i praksis, beror vel på interessen for projektet - eller om man generelt bare stoler på det.
  • Der kan sagtens være god dokumentation og support på open source software, uden at man skal være henvist til brugerfora. Det afhænger helt og holdent af, hvad leverandøren har valgt at tilbyde.

Generelt afhænger kvaliteten af software vel mere af kulturen og principperne hos leverandøren end det handler om closed- vs open source.

Jeg tvivler stærkt på, at kvaliteten dalede eller steg fra den ene dag til den anden, da Microsoft valgte at gøre .NET core til open source.

Jeg tror heller på, at man nødvendigvis har skumle hensigter med kodefusk, hvis man ændrer et open source projekt til closed source; det er nok mere et spørgsmål om licens og måden man vil tjene penge på.

Jeg synes, at open source har vist sig at have mange fordele. Alene det, at man ikke behøver at bygge alting op fra bunden, men kan gøre brug af open source til dele af sit projekt og "betale" ved at komme med forbedringer eller flere features. Gøres det rigtigt, er det vidensdeling på højt plan. Og rigtig rigtig mange slutbrugere har glæde af det.

  • 9
  • 0
#24 Nis Schmidt

Ad #22:

Du har ikke rigtig fanget pointen vel?

Jo! Men har du?

Ad #23:

Gøres det rigtigt, er det vidensdeling på højt plan.

Jeg har faktisk længe før (F)OSS arbejdet i et firma, som inkarnerede 'digital open culture' i både HW og SW. Men det handler ikke om hvad jeg som person har eller ikke har fattet, men om at vores 'kultur' tilsyneladende er ved at fravige vidensdeling til fordel for klam- og griskhed (selvfedme); hvilket i slutningen af sidste årtusind kostede mig næsten en million kr.

Jeg er for længst nået frem til, at ikke alle danskere lider af selvfedme (ikke engang her), men sandsynligheden for infektion stiger uheldigvis med bruttoindkomsten.

  • 1
  • 9
#26 Finn Aarup Nielsen

Jeg kan se at mit overstående eksempel jo ikke give mening. Det er blot en almindelig elementvis multiplikation. Den rigtig matrix multiplikation ligger med Numpy oppe på over to sekunder på min computer.

N=4096; A = np.random.random((N, N)); timeit.timeit(lambda: A@A, number=1) 2.1382109729966032

  • 2
  • 0
#28 Nis Schmidt

Ad #26: Tak fordi du så eksemplet efter, det ville være interessant at vide hvilken hardware du havde benyttet til de 2 eksempler?

Og ret beset er det vel C-kode du (primært) timer, ikke Python :-)

AD #27: Det tror ikke engang det var. Numpy benytter Intels MKL (Math Kernel Library) og det hitter ud af hvilken HW, der er til rådighed, fx AVX-512. Derfor spærgsmålet om HW. Det er trods alt ca 357 mia floats eller doubles man ganger sammen (plus det løse) ;-)

  • 0
  • 0
#29 Sune Marcher

AD #27: Det tror ikke engang det var. Numpy benytter Intels MKL (Math Kernel Library) og det hitter ud af hvilken HW, der er til rådighed, fx AVX-512.

Er Intel MKL ikke en blanding af C++ (med intrinsics til SSE2/AVX) og Fortran (svjh inkluderer det BLAS og LAPACK)?

Under alle omstændighed er pointen stadig den samme: det er ikke primært Python-kode du timer, Python bliver (som altid, når der er performance involveret) bare brugt som klister til at kalde optimeret kode skrevet i andre sprog.

  • 0
  • 0
Log ind eller Opret konto for at kommentere