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

Om ældre ~ visere korrelationen

30. januar kl. 10:1921
Artiklen er ældre end 30 dage

Specielt halvgamle mænd elsker at fremhæve den hypotetiske "ældre ~ visere" korrelation, til trods for det meget spinkle datagrundlag.  De fleste af dem der lærer af deres fejl bliver klogere med tiden, men det er sådan set også alt hvad der er at komme efter.

Når man selv er blevet et FOSS-koryfæ, løber man ind i andre FOSS-koryfæer til konferencer og jeg har derfor mødt en masse herlige, smarte, i visse tilfælde grænsende til geniale, FOSS-folk der har skrevet software vi alle bruger hver eneste dag.

Men som tiden går, begynder der at komme ridser i lakken hist og her.

Tag f.eks Daniels CURL.  Daniel har endnu aldrig mødt en protokol han ikke kunne lide og derfor understøtter curl, som default, GOPHER, SMB og DICT samt guderne vide hvor mange andre protokoller.  I FreeBSD ports spytter make all-depends-list 588 andre ports ud, som er CURL skal bruge.

Artiklen fortsætter efter annoncen

Men CURL havde også 21 CVEer alene i 2022 og er oppe på 132 totalt indtil videre.

I min optik er CURL derfor begyndt at blive en del af problemet frem for løsningen.

Eller tag Tobi's SmokePing, hvor make all-depends-list i FreeBSD ports spytter 728 linier ud.

Sidste sommer hyggede jeg mig med at "rydde op" i Andrew's rsync og fjernede 60% af kodelinierne, uden at miste nogen relevant funktionalitet.  Rsync supporterer f.eks alle tidligere versioner af den interne protokol - just in case.  Jeg fandt også en ret obskur fejl, men det kunne jeg ikke overbevise de nuværende maintainers om, fordi fejlen stort set er usynlig under de mange arkæologiske lag der bygget ovenpå.

Artiklen fortsætter efter annoncen

Og nu føjer Mark Adler, der ejer det allestedsnærværende "zlib", sig til listen af midaldrende mænd der måske ikke helt har kontakt med beat'et mere, ved at nægte at droppe K&R funktioner selvom ISO-C nu endelig har droppet dem.

Nederst i den github ticket er der en stadigt voksende liste af andre projekter, der er nødt til at fedte rundt med compiler-options på grund af Mark's stædige klamren sig til en 40 år gammel, praktisk taget antik, version af C-syntaxen.

I min optik hører både CURL, SmokePing, rsync og zlib, i deres nuværende form, hjemme i FOSS-verdenes svar på Den Gamle By:  Sådan kodede man i 1980'erne og 1990'erne.

Men det er forbandet svært, grænsende til umuligt, at erstatte populære værktøjer som alle og enhver bruger, og derfor må resten af branchen leve med diverse halvgamle mænds særheder - og de deraf følgende omkostninger.

/phk

 

21 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
21
8. februar kl. 16:01

visere ~ ældre

Ja, den vej virker relaionen; det er anden vej, som kan vise sig tvivlsom. Som i:

  • vise personer er tit ældre
  • ældre personer er tit ikke vise
19
6. februar kl. 19:58

qoute I min optik hører både CURL, SmokePing, rsync og zlib, i deres nuværende form, hjemme i FOSS-verdenes svar på Den Gamle By: Sådan kodede man i 1980'erne og 1990'erne. not nore qoute :)

Hvis jeg læser dig rigtigt er pointen at man skal lade være med at være bange for at lave grundlæggende om og man skal ikke have for mange afhængigheder. Noget som jeg ser næsten alle steder gemt som gradle, npm, nuget, osv.

Giver god mening, men kan du ikke komme med dit take på hvad hjørneflagene er i 2020'erne?

18
5. februar kl. 22:43

Den sande visdom i softwareudvikling er at der findes ingen perfekt løsning, kun tradeoffs. Forskellige projekter prioriterer forskelligt.

17
4. februar kl. 19:51

Det er mange gange vigtig intet bliver lavet om så man kan oversætte gammel kode med gamle makescripts, så flyene ikke dratter ned. Men selvfølgelig bør man rydde op i curl/smokeping/... En renaming når oprydning foregår er måske en god ide, og vil nok accepteres af 'de gamle', som vi ser med python->python3. Jeg bliver også boomer-sur, når der pludselig rettes i api til gamle nix kommandoer, he he

16
4. februar kl. 14:37

ældre-visere-korrelation

Generelt vokser vores samlede viden hurtigere end levealderen, så i den forstand at visdom er et udtryk for andelen af samlet viden, man besider, går visdom tilbage; hvis man da ikke har visdom indenfor et område, hvor samlet viden ikke vokser.

Problemet med software er at mængden vokser (i kørende systemer) - mens level-1 cachen (bortset fra enkelte udbydere) er konstant. Dvs at både kommerciel software og FOSS (hvis man ikke gør noget radikalt) har større chance (risiko) for at miste tilstedeværelse i level-1 cachen.

14
3. februar kl. 16:48

Tager man et kig på opsætningen af CURL kan man se at man kan slå de protocoller fra man ikke er interesseret i.
[geshifilter-]if test "x$CURL_DISABLE_SMB" != "x1" 
 -a "x$use_curl_ntlm_core" = "xyes"; then SUPPORT_PROTOCOLS="$SUPPORT_PROTOCOLS SMB" if test "x$SSL_ENABLED" = "x1"; then SUPPORT_PROTOCOLS="$SUPPORT_PROTOCOLS SMBS" fi fi[/geshifilter-]

11
3. februar kl. 09:53

Jeg ku' nu godt leve med en erstatning til Smokeping der nået frem til de moderne paradigmer som web 1.0, hvis altså bare der var noget der var lige så ligetil at sparke i gang.

9
2. februar kl. 18:40

Jeg har hørt, at dele af curl nu bliver kodet i Rust, så Daniel er vist ikke gået helt geronto, men er måske ved at tage konsekvensen på en ny måde.

13
3. februar kl. 12:56

Jeg har hørt, at dele af curl nu bliver kodet i Rust

Handler det ikke bare om at de protokoller han hiver ind er kodet i Rust ?

15
3. februar kl. 19:11

Jo, det kan godt tænkes, at Daniel ikke skriver Rust selv. Men ikke desto mindre vil en del af applikationen nu være skrevet i et sprog med mulighed for bedre forebyggelse af fejl.

12
3. februar kl. 10:45

Her er faktisk et lille paradoks. Når xyz moderniseres vælges nogengange det nyeste og bedste sprog dags dato og/eller et eller andet hype of the day framework. Desværre understøtter mange af disse sprog kun ARM eller X86. Framework of the day fylder oftest voldsomt meget. Begge dele spiller meget dårligt sammen med produkter med tiny rootfs og/eller en eksotisk afart af en CPU. MAO det der i sin tid gjorde xyz udbredt ryger ud med badevandet - funktionalitet, portabilitet og fleksibilitet

6
1. februar kl. 12:47

Ha ... da jeg så overskriften, var jeg overbevist om der var tale om en af dimserne til at vise/læse koder for MitID :-D

4
31. januar kl. 10:08

ingen af de ting du foreslå kommer til at ske, så længe en halvgammel sur stodder lægger armene over kors og siger "Blankt Nej."

Ha ha, true:)

Men men men, der hænder af og til tektoniske skift i et dependency træ.

Der findes et maksimalt niveau for teknisk- og dependency-gæld, hvorefter den pågældende gren i det samlede globale træ, før eller siden knækker af eller visner. Med evolutionær sikkerhed.

Og dette uanset en gammel mand sidder pivende på grenen.

Omvendt vil ikke-perfekte nyttige grene, som holder sig under omkostningsmaximum, kunne overleve som et arkaisk kanon. På trods af teknisk smerte for alle parter op- og nedstrøms.

De uperfekte underliggende arkaiske sub-rutiner er ret godt skildret i The Matrix.

Jeg forestiller mig, det lidt er som at besøge Oraklet eller The Keymaker, når man har behov for at revidere curl og lignende legender.

"Don't worry about the vase", blev der sagt, lige inden nogen fjernede SMB support fra curl.

3
30. januar kl. 15:05

Min stille, men håbløse, drøm er at GNU autotools kunne "af-opfindes"...

5
31. januar kl. 10:33

Jeg ville heller ikke savne programmørenes svar på DJØF. I sin tid løste det sikkert en masse eksotiske problemer. Nu løser det mest en masse problemer, jeg ikke havde i forvejen.

8
2. februar kl. 14:44

Mente du mon ikke "skaber en masse problemer jeg ikke havde i forvejen" :)

10
3. februar kl. 09:42

Jo, men udtrykker man sig i DJØF sprog skal man tale ordentligt til hinanden :-)

2
30. januar kl. 13:42

Men Martin, ingen af de ting du foreslå kommer til at ske, så længe en halvgammel sur stodder lægger armene over kors og siger "Blankt Nej."

1
30. januar kl. 13:29

Men det er forbandet svært, grænsende til umuligt, at erstatte populære værktøjer som alle og enhver bruger, og derfor må resten af branchen leve med diverse halvgamle mænds særheder - og de deraf følgende omkostninger.

Sålænge smerten ved en refakturering overstiger gevinsten, vil et produkt gennemgå en evolution hvor teknisk gæld fortløbende tynger, komplicerer og sløver.

Heldigvis er den perceperede smerte mindre for grønne developers.

Så af og til ankommer friske øjne, som skriver en ny version forfra eller et renere erstatningsprodukt, som håndterer kanonisk legacy men pruner randtilfælde.

I større økosystemer tyder det på, at der ofte mere systematisk etableres en rutinemæssig deprekering af uddaterede afhængigheder.

Systematisk deprekering hvor afhængigheder eller funktionalitet i version 1, markeres deprekeret i version 2, og udgår i version 3 er behageligt for økosystemer, som fortløbende skal holde hele stakken opdateret. Og som kan tillade sig at klippe en arkaisk hale af løbende.

Men det løser ikke problematikken for produkter, som er strengt afhængige af arkaisk funktionalitet. Eller omg endda er "afhængig" af en fejlagtig implementering i en dependency.

En kedelig men udbredt nødvendig løsning, er at freeze en stak på de dependency versioner, som understøtter ens behov. Men det får man ikke point af hos it-revisionen.

I min optik er CURL derfor begyndt at blive en del af problemet frem for løsningen.

Så hvor stor er smerten versus omkostningen ved refakturering og friktion fra arkaiske dependants?