UNIX idioterne

Jeg bliver regelmæssigt beskyldt for at være efter alt hvad Microsoft gør, mens de same folk ikke lægger mærke til når jeg revser UNIX verdenen. Nu har jeg sat en overskrift der burde fange deres opmærksomhed.

"Hvis UNIX er så godt..." starter et udtærsket argument, men det beror på en misforståelse.

UNIX er godt, det er derfor alle andre operativsystemer, fra NT, til MVS konvergerer imod det.

Grunden til at UNIX ikke er en enorm success, er de mange idioter der er i den branche, som gør alt hvad de kan for at gøre livet svært for programmører.

Jeg begyndte engang at skrive på en liste der hed "I hate UNIX people because..." men jeg har opgivet den, den er alt, alt for lang.

Senest har jeg brugt det meste af en uge på at spore et obskurt problem med Varnish på Solaris og nu har jeg endelig fundet årsagen og det er til at tude denne saga.

Først opfinder POSIX et API for multithreading, det berømte "pthreads", men de glemte indlysende nødvendige funktioner som f.eks "pthread_mutex_assert_lock()" og der var også lige den detalje at "errno" stadig var en global variabel.

Errno blev fixet som en panik-ændring og skal i threadede programmer være per-thread storage.

Ind kommer Sun/Solaris.

Indtil da, havde errno altid været en "extern int" og i deres nærmest religiøse iver efter bagudkompatibilitet, laver Solaris ikke errno til per-thread altid, men kun hvis du giver den rigtige compiler option, som sætter nogle CPP macroer som gør lidt magi i sys/errno.h

POSIX folket har ikke standardieseret en sådan compiler option, så sun vælger et eller andet, vist nok "-mt".

Andre vælger "-pthread" og andre igen "-pthreads".

Smukt, ikke ?

Hvis du ikke sætte denne magiske compiler option på Solaris, vil kernen stadig levere errno til din thread-local errno, men hvis du checker "errno" i dit program, får du den gamle globale errno, der intet at at gøre med hvad din thread foretager sig.

Nice Heisenbug, ikke ?

Jeg begyndte for alvor at undre mig, da unlink() returnerede ECONNRESET...

Jeg har just tilføjet kode der skal sikre at errno virker:

int errno_is_multi_threaded;
errno = 0;
AN(unlink("/")); /* This had better fail */
errno_is_multi_threaded = errno;
assert(errno_is_multi_threaded != 0);

Varnish er i forvejen skrevet dybt paranoidt, omkring 10% af alle kode linier er asserts, men dette check markere et nyt lavpunkt for hvad man kan stole på under UNIX.

Hvad bliver det næste, skal jeg teste at alle bits virker i en int ?

Det siger sig selv at HP, *BSD, Linux, Apple, GNU, IBM og alle de mange inkompetente UNIX leverandører der heldigvis forlængst er gået på røven, ikke kan se det fornuftige i at gøre portabilitet imellem UNIX platforme nemt, og derfor har forskellige compileroptions, forskellige funktioner i standardbibliotekerne osv. osv.

Derfor opstår ideen om "configure" scriptet, der finder ud af hvor programmet er henne.

Derefter opstår scripts til at skrive configure scripts med.

Dernæst opstår scipts til at skrive scripts der skriver configure scripts med.

Og idag har vi det værste klaphatteri man kan forestille sig, i form af "autocrap" værktøjerne.

Autocrap bruger en nærmest herostratisk obscur macro-processor ved navn M4 og indtil flere magiske lag af scripts og programmer, og ender med det "configure" shell-script vi alle kender.

Niveauet af WooDoo programmering på dette punkt er uhyggetligt.

Har I lagt mærke til at for mange pakker skrevet i C++ leder configure efter en FORTRAN77 compiler ?

Jeg er principielt helt enig i at en FORTRAN compiler altid er rar at have, men alligevel...

Men når man har set en konfigurationsfil til autocrap, forstår man hvorfor "copy & paste - it works - don't mess with it" WooDoo er så udbredt.

Hvis så autocrap værktøjerne havde fundet den rigtige magiske pthread compiler option på Solaris, kunne man måske tilgive dem, men alt autocrapperiet var faktisk med til at skjule problemet.

Der er forresten ingen nem måde at sige til autocrap "Threaded program, DTRT": Man skal fiffle rundt med alle mulige spøjse variabler og kalde magiske M4-macroer der måske, eller måske ikke virker på alle platforme.

Ja faktisk skal man nærmest lave et work-around, fordi der er andre ting autocrap er meget mere opsat på end at lade dig compile pthread-programmer, f.eks at bruge så mange GNU værktøjer som muligt.

Læg mærke til at jeg slet ikke har talt om noget der foregår i kildeteksten, det er indtil flere kapitler for sig, dette brok handlede alene om at få kildeteksten oversat rigtigt på forskellige UNIX systemer.

Så nej, jeg er ikke imponeret over MicroSoft, men det er jeg ved gud heller ikke over UNIX branchen...

Og ja, jeg har fremført denne klage internt og svaret fra alle lejre, lyder: "Alle de andre burde gøre som os, for vi er smartest."

I guder for nogle idioter...

phk

Kommentarer (56)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Kenn L. Schjødt

Nu er jeg jo bare en nogenlunde almindelig DBA på Microsoft SQL Server, som ikke har den store lyst til alle de her småreligiøse debatter...men jeg synes dit indlæg her rammer noget eksistentielt for alle IT folk.

Basalt er der to slags IT folk, dem der programmerer skidtet og dem der administrerer skidtet ;)

En som mig der administrere bliver hurtigt ikke-religiøs. For optimering og erfaring handler ikke så meget om at udnytte systemer eller hardware bedst muligt. Nej...det handler mere om at styrer uden de problemområder og sumpe, i den IT infdrastruktur man sidder på.

Det tror jeg gælder æblespisere, vindueskiggere, *nixnørder osv. For vi lever alle i en verden, hvor vi skal kommunikerer med omverdenen...og den er jo aldrig så homogen, som indersiden af hovedet på en religiøs fanatiker eller idealiseret guru ;)

/Kenn

  • 0
  • 0
#2 Carsten Sonne

Lad min starte med at sig, at jeg er relativ ny i UNIX verden. Pt. har jeg kun hands-on erfaring med Ubuntu.

Jeg er meget begejstret for Ubuntu. Det giver mig nogle ellers uopnåelige muligheder. Jeg kan køre et virtualiseringmiljø, en webserver, en mailserver, et kildekontrolsystem, en filserver, en LDAP server osv. osv. uden det koster andet en tid og strøm.

Jeg kender flere forskellige system udover Windows. Specielt AmigaOS har jeg et relativt indgående kendskab til. Dengang Amiga'en langsomt uddøde forsøgte jeg mig frem med Linux. Det var dog alt for besværligt at få computeren til noget som helst. Og når ting ikke virkede, havde jeg ikke en chance for at løse problemet. Jeg kunne bruge timer på de mest banale ting.

I dag ser jeg stadig de samme problemer på UNIX. Jeg tillader mig at lave den antagelse, at de problemer jeg oplever på Ubuntu er generelle elementer i alle UNIX miljøer.

Mange ting fungere på forunderlig vis. Som oftest er det de underligste ting man skal gøre for at få et eller andet til at virke. Selv når man syntes man har lært noget, så finder man ud af der er undtagelser, mange undtagelser.

Det er en af de ting jeg personligt syntes er det største problem. Diverse fremgangsmåder er alt for inkonsistente. Der er umuligt at gætte sig til noget som helt, selv med en relativ solid baggrund og indgående kendskab til den anvendte teknologi. Hvis noget går galt, kan det koster timer at få det op og køre igen. Og uden internettet er det håbløst.

Der er ikke nogen tvivl om, at de dygtigste sysadms findes på UNIX. Det kræver en dyb indsigt i de anvendte teknologier og det kræver en enorm mængde viden om alle mulige særheder.

Det fantastiske ved UNIX miljøet er friheden og mulighederne. Men det er også det der skaber de største problemer.

  • 0
  • 0
#6 Thomas Petersen

Jeg har selv arbejdet for et hedenganget firma der leverede Unix (Compaq, derhavde overtaget Digital Unix). Der var ingen tvivl om at management og salg kun var interesseret i at sælge så mange bokse som muligt. Det var i de gamle dage hvor man bandt kunderne til sig ved at være incompatible så det var jo i tråd med den filosofi, at andres software ikke nødvendigvis kunne køre. Set i det lys er der jo håb forude for Linux - nu skal leverandørerne jo leve af at softwaren kan køre så godt som muligt på så mange maskiner som muligt.

  • 0
  • 0
#7 Jimmy Krag

...ATCHJUU!!! Jeg er allergisk over for ordet.

Microsoft evangelist ATCHJUU!!! Linux evangelist ATCHJUU!!! Apple evangelist ATCHJUU!!! Google evangelist ATCHJUU!!! BSD evangelist ATCHJUU!!! (Har jeg glemt nogen?)

Hvis vi var enige om noget mere, ville der være færre evangelister (ATCHJUU!!!), men hvorfor kan vi ikke bare være uenige uden?

Nå, men så behøver jeg vel heller ikke whine mere. Men det var nu rart at komme af med...

  • 0
  • 0
#9 Deleted User

@Rune

Han savner en fælles grundstruktur.

Nogle gange skal den fælles grundsturktur også udvikles.

Ligesom i bilindustrien, som er mangfoldig, men alle har som standard en motor, et rat, pedaler, osv...

Dårligt eksempel. Nogen, vidst nok Svenske volvo busser, har opfundet en kombineret speeder/bremse pedal som nedsætter din reaktionstid fordi du ikke skal flytte benet. Den fungerer som speeder når du vipper foden i anklen. Den fungerer som bremse når du strækker benet. Men er den blevet indført endnu? Næh

@Michael Zetlitz

Der er jo ikke meget udvikling i at opfinde den dybe tallerken på 17 forskellige måder.

Jo, det kan der sagtens være. Nogle gange har man behov for en stor diameter. Andre gange for en høj kant. Men kanten kan også blive for høj. Andre kan mangle en tud til at hælde af, eller 2 ører så man ikke brænder sig. Andre vil have kun et håndtag.

Nogle gange bliver man bare nødt til at være forskellig, og hvis det ikke tillades så dør man.

  • 0
  • 0
#13 Deleted User

... her småreligiøse debatter...

.. hurtigt ikke-religiøs....

...en religiøs fanatiker..

Vil du ikke nok være sød ikke at (mis)bruge dette ord så meget? Religion er noget med voksne mennesker der tror på irrationelle ting.

Det er sandt at styresystemer til tider kan provokere ophedede diskussioner, men de har intet med religion at gøre. Når du kalder det for "religiøst" antyder du at det ikke baserer sig på noget virkeligt eller håndgribeligt, og at de argumenter der fremkommer ikke har rod i den virkelige verden, og det er ærligt talt at undervurdere det som bla. PHK siger her.

  • 0
  • 0
#15 Carsten Sonne

Jon,

Det kan godt være at forskelligheden har en god begrundelse som PHK ikke har opdaget.

Den har helt sikkert en god begrundelse. Om ikke andet, så har den løst et problem for nogle compilere udviklere. Det er bare knap så interessant. Det interessante er konsekvenserne.

De kompiler options har helt sikker givet en værdi her og nu under udviklingen, man har kunnet komme videre og samtidig løst et behov. På lang sigt, koster løsningen bare dyrt i form af tid for brugerne (af kompileren). Specielt hvis brugeren er orienteret mod mere end een specifik distribution eller platform.

  • 0
  • 0
#19 Henrik Mikael Kristensen

Disse små detaljer skyldes ofte selviskhed med et ønske om at rette en lille fejl i sit eget system og egentlig ignorere, hvad andre synes om det. Med mange bække små gør man store UNIX programmører vanvittige.

Samme problem ses med webbrowsere og generelle varianter i kloner af programmeringssprog og vist nok også officepakker, som diskuteres her engangimellem.

Det er lige præcis denne type problemer der gør, at programmering sjældent er [i]simpelt[/i], hvor man kan skrive sin kode i vi/emacs og compile det og det så kører problemfrit på alskens forskellige UNIXer. I stedet skal man have travlt med at checke om 2 + 2 ikke giver 4.001. Det er dét der gør, at det tager 12 timer at skrive en stump kode i stedet for 2 timer, og man sidder med den ubehagelige fornemmelse bagefter, at det nok alligevel ikke er nogenlunde bugfrit.

Her skal man snakke om at være konsekvent, så hvis ét UNIX system laver en bestemt tosset ting, er det bedste faktisk at gøre den samme tossede ting på andre UNIX systemer. Så er man i det mindste konsekvent, og fejlen er kendt. Hermed er det generelt simplere at skrive sin software, så den virker som forventet, og antallet af grånende hår, sene aftenstimer foran tastaturet og væltede kaffekopper vil falde.

Så kan grupperne sætte sig ned bagefter, diskutere og aftale at fjerne denne tossede ting, f.eks. gennem en POSIX opdatering.

Så, nej, Jon, det er ikke her i de små fine detaljer, man bør være "innovativ". Det er ikke dét, der bør gøre UNIX systemer forskellige. Forskellene skal være ganske markante.

  • 0
  • 0
#20 Poul-Henning Kamp Blogger

Måske er problemet at PHK forventede at Solaris var identisk med de andre platforme.

Jon, nu er du decideret dum at høre på.

Jeg har arbejdet med UNIX i over 25 år nu, jeg har arbejdet på maskiner og UNIX varianter du end ikke har hørt om, inklusive en hvor telefonopkald til firmaet blev redirigeret til SÄPO fordi de havde solgt illegal teknologi til Soviet.

Nej Jon, jeg forventer ikke at Solaris er identisk med andre platforme. Men jeg påpeger, at UNIX branchen altid har været sin egen bedste fjende, ved at gøre livet så surt for brugerne som man kunne.

Poul-Henning

  • 0
  • 0
#26 Deleted User

Monokultur er vel først og fremmest farlig hvis alt kører på samme implementation. Der er ikke noget i vejen for at flere produkter (her Unix-varianter) har de samme veldefinerede grænseflader. Der kan stadig godt være forskelle på implementationerne. Sun kunne f.eks. godt have en implementation af pthreads som i visse tilfælde er bedre end konkurrenternes, uden at de bryder med de gængse konventioner/standarder.

Hvorfor bliver POSIX egentlig ikke videreudviklet, så man f.eks. får pthread_mutex_assert_lock() med i standarden?

P-HK: Hvad gør man i praksis når man har brug for pthread_mutex_assert_lock() (ud over at bande højlydt).

Overordnet er dette vel ikke noget specifikt Unix problem. Der er mange ting som kunne være standardiseret bedre på tværs af forskellige systemer.

  • 0
  • 0
#27 Deleted User

Monokultur er vel først og fremmest farlig hvis alt kører på samme implementation. Der er ikke noget i vejen for at flere produkter (her Unix-varianter) har de samme veldefinerede grænseflader.

Nogle gange kan der godt være fejl i grænsefladerne.

  • 0
  • 0
#31 Carsten Sonne

Monokultur er farligt ift. driftsikkerhed, men det endnu værre er det ift. innovation. Hvis vi alle tænkte på præcis samme måde og var enige om alting, så ville verden enten gå i stå eller divergere ud af en eller anden tangent.

Alt innovation kommer ud af at tænke anderledes. Hvor skulle modspillet og inspirationen komme fra i en monokultur?

Eksempelvis er et monopol er på sin vis sin egen lille monokultur. Hvem er begejstret for monopoler?

  • 0
  • 0
#33 Deleted User

Alt innovation kommer ud af at tænke anderledes. Hvor skulle modspillet og inspirationen komme fra i en monokultur?

I dette tilfælde er det jo forskelle i platformen, som ikke er synlig for brugerne. Det gør det kun sværere at udvikle det samme stykke software til forskellige platforme. Resultatet kan således blive, at der udvikles en monokultur, fordi det er for svært at udvikle til forskellige systemer. Hvis det havde været nemmere at porte Windows applikationer til Unix varianter, ville Microsoft formentlig stå en del svagere i dag.

Der findes altså design fejl.

Ja. De fleste standarder som bliver anvendt meget, vil forhåbentlig blive udsat for tilstrækkelig mange kritiske øjne. Dermed må man håbe, at designfejl bliver opdaget i tide.

  • 0
  • 0
#34 Jens Katz-Kolberg

Kom med et bud på en plausibel begrundelse, med teknisk substans

Jeg vil da hellere se en (rent teknisk) begrundelse for at de forskellige udbydere skulle have en ens grænseflade. En sådan teknisk begrundelse eksisterer nemlig ikke. Ønsket om ensartethed er udelukkende et ønske om at gøre livet lettere for programmører, der laver programmer for forskellige platforme, og det er ikke teknik, men politik.

Grunde til at man ikke laver grænsefladerne ens, kunne f.eks. være: * Hvem skulle vi efterligne (vores værste konkurrent, med fare for at blive kaldt kopister) ?

  • Hvorfor bruge (meget) tid og penge på at koordinere med konkurrenter, når vi hellere vil bruge tiden og pengene til at lave produktet bedre (end konkurrenternes) ?

  • Hvorfor skulle vi gøre det lettere for vores software-partnere at portere deres programmer til vores konkurrenters platform ?

  • <Indsæt andre begrundelser her :-) >

Bemærk, at jeg også gerne vil have ensartede grænseflader, - men jeg kan da sagtens forstå hvorfor det er endt som det er.

  • 0
  • 0
#36 Jens Katz-Kolberg

PHK, du har jo valgt at bidrage til FreeBSD, så du kender projektet bedre end stort set alle: Hvilken strategi bruger I i projektet, for at gøre det API kompatibelt med de andre *NIX varianter ? Her tænker jeg specielt på de ting, der endnu ikke er standardiseret.

  • 0
  • 0
#37 Martin Bøgelund

Kan vi ikke bare være venner allesammen?

Èn er rødhåret, én er fra Herlev, nogen spiser franskbrød med smør [i]og[/i] Nutella, nogen kører mountain-bike i deres fritid.

Og?

"Alle der mener de har fundet De Vises Sten bedes række hånden op. Alle der sidder med hånden i vejret bedes forlade lokalet, og overveje deres værdier, mål og normer!"

Hvis vi taler pænt med hverandre, og iøvrigt bruger kræfterne på noget vi kan li', bliver vi så ikke lykkeligere allesammen?

Behøver vi tærske mere i hvilken platform vi foretrækker?

Skal vi ikke hellere lade det handle om standarder og protokoller som alle har mulighed for at benytte, og så lade det være en personlig sag om man er til pistacie-, chokolade-, eller hindbær-is?

Fælles snitflader, personlige præferencer. Vi er jo alligevel allesammen for meget "eksperter" til at enes om hvordan "the one true system" ser ud.

  • 0
  • 0
#38 Carsten Sonne

Hej Martin,

Hvis vi taler pænt med hverandre, og iøvrigt bruger kræfterne på noget vi kan li', bliver vi så ikke lykkeligere allesammen?

Kloge ord. Den af og til skarpe tone skal nok blot ses som et retorisk virkemiddel, der bliver brugt til at tydeliggøre og understrege en pointe.

Nogle gange taber man dog alligevel hovedet lidt og begynder at være decideret ukonstruktiv og barnlig. Der må vi lige hver især sætte vores filter på når vi læser :-)

Skal vi ikke hellere lade det handle om standarder og protokoller som alle har mulighed for at benytte, og så lade det være en personlig sag om man er til pistacie-, chokolade-, eller hindbær-is?

Jeg mindes ikke at have læst en af PH-K's blogs, der var blottet for pointer. Der er altid mindst en valid pointe.

Min agenda er langt hen af vejen den samme, og nu skal jeg passe på hvordan jeg formulere det... Der skal være et ægte og intelligent formål samt en 'passende' udførelse. Samtidig skal en summeret samfundsmæssig og menneskelig værdi være positiv på bundlinien.

Udgangspunktet er nok bare meget forskelligt.

Jeg er enig i at det ikke nytter noget, at stå i hvert sit hjørne og råbe idiot af hinanden. Det er dog heller ikke mit indtryk, at det i hovedreglen er det der sker. Derimod er ønsket blot at præge udviklingen i den retning som giver mest mening ift. egen overbevisning.

Du kan sige, det vigtigste er hvad folks (rigtige) agenda er. Så længe der ikke er væsentlige modstridende interesser og/eller en ond vilje, så er det kun til gavn at lytte.

Mvh Carsten

  • 0
  • 0
#39 Poul-Henning Kamp Blogger

Jeg må nok indrømme at jeg har givet op, efter at have brugt 10 år på at hyrde katte der havde helt andre ideer.

Som Linus har noteret sig, mener mindst 95% af alle programmører at de er over gennemsnittet og ligeledes er antallet af personer i UNIX verdenen der mener at have fundet de vises sten overvældende.

de ting, der endnu ikke er standardiseret.

Her rammer du problemets kerne: Der er ikke foretaget standardisering eller koordination af nogen betydning i de sidste 10-15 år.

Varnish er mit første store cross-platform program i lang tid og det afspejler på visse områder mit mismod.

F.eks har alle poll(2)/select(2) API'et, der stammer fra før webserverens tid.

Dette api har den ulempe at det er state-less, hvis du skal vente på 10000 fil descriptorer, skal kernen sætte et flag på dem alle, hver gang du kalder poll eller select og rydde op inden den returnerer de 5 fil descriptorer der skete noget på.

Derfor er der brug for et state-full API, hvor det at markere en fd for overvågning er en separat operation, forskellig fra det at checke om der er sket noget nyt.

FreeBSD har dertil kqueue, Linux epoll og Solaris et eller andet tredje. (NetBSD's og OpenBSD's kqueue er muligvis ikke helt magen til FreeBSDs, men da ingen af dem ser ud til at være attraktive platforme for Varnish er det lidt ligegyldigt.)

Da "waiter" funktionen i Varnish er ret central for performance, har jeg simpelthen været nødt til at gøre den til et "pluggable" interface, således at der kan skrives et modul for hvert enkelt OS private API for en fuldstændig generisk funktion.

Det næste der sker, er at en eller anden skriver et sæt m4-macroer der spytter C-kode ud der kalder et python bibliotek der vælger det rigtige API for den aktuelle maskine.

Fremskridt ? Vi har hørt om det.

Sendfile() er et andet sted, hvor alle gør deres egen ting, uden at nogen tænker længere end egen næsetip.

Selv noget så basalt som madvise() options har forskellige navne i forskellige OS, selvom det er options der gør det præcist samme.

Den slags diversitet er fint under forskningsforløbet og når folk skriver deres USENIX papers, men det er et helvede at skrive gode programmmer til, når det pludselig er i produktion...

Poul-Henning

  • 0
  • 0
#42 Michael Deichmann

Et eller andet sted bunder det i umodenhed - i hele IT branchen som sådan og i høj grad også af nogen af udøverne. Det er noget udisciplineret vrøvl at frihed til forandring er forudsætningen for innovation - i hvert fald som hovedregel. Hvis det virkelig er nødvendigt er det udtryk for at det oprindelig design ikke er tilstrækkelig solidt designet. Og det kan der være mange grunde til - for eksempel at man ikke føler ansvar for helheden men er tilfreds når man har fået løst sit særtilfælde af alle de generiske mulige udfald. Lige så vel som mange der kalder sig IT Arkitekt ikke er det gælder det samme for software ingeniører. Inden for begge discipliner er der metoder som man arbejder efter i den kreative process, men de fleste programmører er hverken arkitekter, ingeniører eller håndværkere - de er kunsthåndværkere og resultatet er derefter.

  • 0
  • 0
#43 Carsten Sonne

Hvis det virkelig er nødvendigt er det udtryk for at det oprindelig design ikke er tilstrækkelig solidt designet.

Betyder det at der findes designs, som er den ultimative endelige uforbederlige løsning? En opgave ville aldrig kunne løses på en nemmere eller smartere måde? Virkelighed ville aldrig kunne ændre sig på en måde, så designet ikke kunne forblive det ultimative endelige uforbederlige design?

Hvad var det du kaldte udisciplineret vrøvl?

  • 0
  • 0
#44 Deleted User

Betyder det at der findes designs, som er den ultimative endelige uforbederlige løsning? En opgave ville aldrig kunne løses på en nemmere eller smartere måde? Virkelighed ville aldrig kunne ændre sig på en måde, så designet ikke kunne forblive det ultimative endelige uforbederlige design?

Jeg har tænkt en del over api problemstillingen, og uden at sige at jeg har en definitiv løsning på problemet, så vil jeg mene at det langt hen af vejen kan løses med middleware som sølvkuglen. Et bibliotek/programmeringssprog med veldefinerede funktioner, som kan oversættes til forskellige kombinationer af systemkald alt efter hvilken platform der kompileres til, vil i vid udstrækning kunne løse PHKs problemer. Så længe problemet blot er at de samme funktioner hedder noget forskelligt så er det forholdsvis ligetil, men når styresystemerne ikke spejler hinandens funktioner 1 til 1 bliver det mere kompliceret, hvis man blot tager en funktion fra et system og implementerer den eksakt vha. et andet systems funktioner er det ofte ikke muligt at få en respektabel ydelse med, heller ikke selvom der findes en funktion som gør næsten det samme. I nogle tilfælde kan en løsning være at man definerer en "laveste fællesnævner" funktion som er så tilpas begrænset at alle systemer har en funktion som spejler denne funktionalitet, og i nogle tilfælde kan man komme langt ved blot at definere de højniveau funktioner som man typisk har brug for.

Man kan tilføje nye funktioner i det omfang de kan oversættes til eksisterende funktioner, efterfølgende kan OS leverandørerne så føje nye funktioner til deres api som gør at disse funktioner kan oversættes til noget mere optimalt på netop deres platform.

Det ultimative design er netop forbederligt på en sådan måde at man kan tilføje nyt uden at det går ud over kompabiliteten.

Det blev vist en værre smøre, jeg håber at I forstår bare lidt af hvad jeg mener.

  • 0
  • 0
#45 Jonas Finnemann Jensen

Derfor opstår ideen om "configure" scriptet, der finder ud af hvor programmet er henne.

Derefter opstår scripts til at skrive configure scripts med.

Dernæst opstår scipts til at skrive scripts der skriver configure scripts med.

Hmm... Har heller aldrig kunne beslutte mig for om jeg synes at autotools er vanvittigt eller genialt... :)

  • 0
  • 0
#47 Torben Hørup

Karsten, jeg har brugt cmake til et par af mine egne småprojekter og der har jeg været meget glad for det. Man gennemskuer hurtigt hvordan CMakeLists.txt fungerer, men har kun prøvet med <100 .cpp/.h filer og kun på mine egne maskiner - så jeg ved ikke hvordan den er på større projekter eller i crossplatform sammenhæng.

  • 0
  • 0
#48 Poul-Henning Kamp Blogger

Et bibliotek/programmeringssprog med veldefinerede funktioner, som kan oversættes til forskellige kombinationer af systemkald alt efter hvilken platform der kompileres til, vil i vid udstrækning kunne løse PHKs problemer.

Den ide hedder "python" og er for langsom til et stort segment af opgaver.

Poul-Henning

  • 0
  • 0
#50 Poul-Henning Kamp Blogger

Det er ideen. Der findes applikationer hvor du har brug for at få adgang til den rå uindpakkede hardware performance og funktionalitet.

Dertil har vi C-sproget og indtil videre ingen relevante konkurrenter.

Poul-Henning

  • 0
  • 0
#52 \n \r

Carsten, lad mig hjælpe dig lidt med et citat fra PHK:

Der findes applikationer hvor du har brug for at få adgang til den rå uindpakkede hardware performance...

Til det formål er C perfekt omend lidt uskøn, men at kaste C++, Pascal efter applikationer som disse viser bare hvor meget du misforstået hardware nær udvikling.

  • 0
  • 0
#53 Carsten Sonne

@David

Grunden til C er så oplagt ift. Varnish ol. er vel nærmere at POSIX er direkte orienteret mod C.

Mig bekendt er Pascal stort set lige så tæt på OP koder som C.

Fair nok at C++ er knap så tæt. De tidskritiske dele kan man jo vælge at skrive uden brug af objekter og resten med.

Jeg undre mig blot over den udbredelse C har ift. relativt oplagte alternativer.

  • 0
  • 0
#54 Kenn L. Schjødt

Jeg tror ikke jeg er den første som synes at folks tiltro til deres OS platform og andre IT teknologier til tider nærmer sig religiøse overtoner, hvor det mere handler om udefinerbare værdier eller detaljer, end om teknologien.

Det er vel ikke tilfældigt at IT firmaer selv har "evangelister" ;)

Religion er et fremragende ord til at beskrive dette, for i alle henseender har mennesker end tendens til at blive religiøse med andet end religion. Religion handler om at se verden fra en bestemt synsvinkel. Det ser jeg en masse tendenser til herinde fra alle sider.

Verden er et bedre sted når man frigører sig fra forudindtagethed og kan se ud over sin egen synsvinkel.

/kenn

  • 0
  • 0
#56 Nikolaj Brinch Jørgensen

Det er set så mange gange det skidt...

  1. "Oh boy vi har gjort i nælderne, vi har lavet et værktøj som ikke er særlig smart at bruge, skal vi ikke fikse det?"
  2. "Nej vi laver et nyt værktøj som vi bruger, det bruger så det første. Det nye værktøj vil være super nemt at bruge" (... 1 år senere ...) {Goto 1}

Få nu fikset de fejl i jeres software. Når folk laver dumme beslutninger så fastholdes de i en uendelighed, i stedet for at erkende at det var sgu dumt og vi gør noget andet. Sun har i denne sammenhæng sikkert problemet at en uoverskueligt masse software allerede baserede sig på deres implementation da de opdagede fejlen, og derfor ikke rettede den. Men kære Sun - det retter man altså op på ved næste major release - hvis man ellers er et mandfolk.

Det virker altid som om nogen prøver at sparke en død hval hen ad en strand...

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