Open Source Pampere

Min seneste klumme til ACM's Queue har affødt nogle spøjse reaktioner.

Hvis vi starter fra den fjerne ende er der dem er giver mig ret fordi ungdommen nu om dage har ingen RESPEKT for voksne (osv. osv. osv.) Disse Jeronimus'er findes i alle fag, glem dem.

Så er der nogle tankevækkende reaktioner fra folk der er gamle i gårde, som overordnet set er enige, men som har deres egne interessante vinkler på både diagnosen og hvorledes kuren bør se ud.

Dernæst er der reaktionerne fra dem jeg skriver om, fra lange idologiske epistler, helt ned til den email der bare lød "Bazaar won, f..k cathedrals". Den reaktion var helt forudsiglig og jeg takker de pågældende for at underbygge og dokumentere min påstand så eftertrykkeligt.

Nogle få, tydeligvis unge mennesker, har reageret med forskellige varianter af "ok, så var det ikke bare mig der synes det var underligt..." dem venter jeg mig meget af.

Den respons jeg var helt uforberedt overfor, var dem der kom efter mig for at "pisse på mine egne" og "ikke være med på holdet mere".

Har vi virkelig sejret så meget at vi nu også har Open Source Pampere ?

Men så var det jeg kom i tanke om at det har vi haft i rigtig mange år.

phk

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jacob Larsen

Jeg kan kun tilslutte mig kritikken af hele "configure" balladen. Det er noget værre ineffektivt rod.

Har du set hvad Google har gjort med Android userland build? Der har de helt fjernet de forskellige configure scripts, og bygget et rigtigt non-recursive make system, samtidig med at de har centraliseret config. Det kan man desværre kun når man kan diktere platformens design fra bunden.

  • 3
  • 0
Martin Bøgelund

Den respons jeg var helt uforberedt overfor, var dem der kom efter mig for at "pisse på mine egne" og "ikke være med på holdet mere".

Har vi virkelig sejret så meget at vi nu også har Open Source Pampere ?

Men så var det jeg kom i tanke om at det har vi haft i rigtig mange år.

Jeg vil mene at de der beskylder dig for ikke at være med på holdet mere, ikke gør sig skyldige i pamperi ved denne handling.

De gør sig nærmere skyldige i gruppetænkning ("group think"), hvor det ikke tolereres at stille spørgsmålstegn ved de vedtagne dogmer.

Og RMS...
Socialt handicappet, brysk og arrogant overfor alle der ikke lige fatter hans geniale masterplan, og derfor straks smider alt hvad de har i hænderne for at hjælpe ham? Klart ja!

Men pamper?

Det er ikke min opfattelse at RMS rager til sig (altså til sin egen person), men nærmere at han mener han kan tillade sig alt på en barnligt krævende manér, fordi han føler han arbejder for den eneste rigtige sag - men de ressourcer han afkræver går uvægerligt også til den sag han kæmper for.

Og det mener jeg ikke gør ham til pamper i ordets egentlige forstand.

  • 6
  • 0
Anders Wegge Keller

Nu ved jeg ikke hvordan FreeBSD har det, men i min linux-distribution, er der ikke mindre end 4 forskellige inkompatible automake-pakker, og to forskellige autoconf. Så hvis du kun har en af hver, burde du næsten være glad.

Men bortset fra det, har du så et bedre bud på hvad vi kan erstatte autoconf/automake med? Jeg er ikke sikker på at min approach med at skrive langhårede makefiles, der nærmest er selvmodificerende kode, er så meget bedre, så jeg vil gerne høre om du kender til noget der virker?

Portabel kode er et andet ømt punkt. Du har ret i at det er sådan vi burde skrive software Men der er altså nogle ting der ikke kan håndteres uden at vide noget om det miljø koden skal afvikles på. Bare det at skelne mellem 32 eller 64bit arkitektur, little eller big endian, og hosted eller freestanding giver allerede 8 kombinationer. Det giver nogle meget dybe, og svært vedligeholdelige lag af nestede #ifdef, som jeg hellere end gerne vil slippe for at vedligeholde. Så igen: Har du en bedre ide?

  • 0
  • 0
Troels Henriksen

Min erfaring er at platformsspecifikke #ifdefs meget ofte dækker over forsøg på at udnytte platformsdetaljer af ydelseshensyn. Især bør det næsten altid være fuldstændigt ligegyldigt om din arkitektur er big-endian eller little-endian (Rob Pike har skrevet et nogenlunde blogindlæg om sagen - i almindelighed er Plan 9-folkenes fremgangsmåder virkelig værd at studere nærmere). Skriv kode der følger (portabel) C-semantik, selv hvis det virker lidt mere klodset eller ineffektivt end at udnytte fikse detaljer omkring platformen, og lad oversætteren tage sig af at generere effektiv kode. Hvis det virkelig viser sig at være for langsomt, så er det jo nemt at optimere senere.

Et problem, der desværre er knapt så nemt at løse, er hvis man skal være kompatibel med flere forskellige udgaver af et givent programbibliotek (eller endnu værre: Hvis "standard"-funktioner i virkeligheden varierer fra system til system). Det ved jeg ikke om der er en god løsning på.

  • 3
  • 0
Jens Henrik Sandell

Nu har jeg ikke redet på open source bølgen, men jeg kan se tilsvarende mønstre (som dog ikke har en dyt med auto-xxxx at gøre):

  1. REPRAP og generelt 3D print er godt på vej ned ad bakke. Markedet blomstrer, enhver kan sætte sig ned og printe den næste printer med salg for øje, samt det er ikke til at finde hoved og hale i de tool-chains der kan downloades til de forskellige printere.

  2. Automobiler. Hvis man i år 1900 havde kunnet forudse, hvor vi er i dag, så ville privatbilismen være blevet forbudt, eller i det mindste stærkere reguleret. Forfatteren Peter Hamilton har i den sammenhæng en sjov facet på spørgsmålet om forbrændingsmotoren i sin novelle "Watching Trees Grow".

Og selvfølgelig skal du have et venskabeligt klap på skulderen. For du har jo ret, min ven. ;-)

Jens

  • 0
  • 0
Ole Laursen

Jeg læste din artikel, og ærlig talt synes jeg du fik hvad du bad om. :)

Du kunne udmærket have spidset din pointe lidt ved ikke at blande hele bazar vs. katedral-diskussionen ind i billedet, som jo da den blev skrevet havde stærke undertoner af et magtopgør i visse centrale dele af infrastrukturen til Linux (måske missede du det i BSD-land), og måske heller ikke starte med at gøre internetudviklergenerationen ansvarlig for problemerne.

Når jeg læser den igen nu, synes jeg artiklen er interessant ud fra hvad den fortæller om phk's syn på tingene. :)

Og så er det jo næsten en tautologi, men desværre en som ikke alle har forstået, at hvis man tager hovedet under armen og bare drøner derudaf, så ender man i mudder til halsen (og med hovedet under armen er man så temmelig druknet).

Nu er min metier for tiden webudvikling, og du ville faktisk måske finde det interessant at konkurrencen her har drevet kvaliteten af tilgængelige API'er i vejret. Hvis jeg starter et nyt projekt, er det f.eks. uendelig let at hive et andet og bedre designet Javascript-bibliotek ned og bare bruge det, der er ikke hele balladen med afhængigheder i mange lag som skal komme fra et pakkesystem.

Der er naturligvis masser af amatørarbejde i felten, men hvis man graver lidt, finder man også en kerne af folk der virkelig dyrker ordentligt design.

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