Unix Haters unite!

Det er nok nærmest en kuriositet at "The UNIX-HATERS Handbook" i næsten et årti blev hostet på research.microsoft.com. Dette faktum gør i hvert fald ikke teksten mindre læseværdig, for indse det: Unix er absolut værd at hade.

Meget har ændret sig i de 14 år der er gået siden håndbogen blev udgivet. På nogle områder har unix faktisk forbedret sig, på andre områder er det mere omgivelserne der har ændret sig. Et gennemgåede tema er for eksempel at "korrekt fejlhåndtering" er er smide brugeren ned i en debugger - held og lykke siger jeg bare.

Og på andre områder er intet ændret. Unix er stadigvæk et kludetæppe og et af de bedste eksemler på at evolution ikke kræver intelligent design. Uhensigtsmæssigheder får stadigvæk lov til at eksistere i lange tider, for folk tør ikke ændre eksisterende funktionalitet. Og den næsten religiøse arrogance teksten giver opfattelse af, lever i bedste velgående.

Jeg kan komme på mange historier om hvordan små fejltrin efterlader en en rygende ruin af et nu ubrugligt unix-installation. En af mine sjoveste aftener i SSLUG-regi handlede netop om dette. Men lad mig komme med to helt andre historier:

Hvorfor skal det være så svært? For et stykke tid siden lavede jeg noget socket-programmering hvor processen faldt i to faser. En ret omstændig opsætning, efterfulgt af noget ret triviel kopieren data mellem forskellige sockerts. Hvor ville det være nemt at have 10 processer der tog sig af opstarten og en process der lavede det efterfølgende dataskubberi for alle forbindelser. Løsingen involverer unix domain sockets og SCM_RIGHTS, men hvorfor skal det være så svært i forhold til bare at kalde WSADuplicateSocket().

Hvorfor tager problemer så lang tid at løse? En kendt akkilleshæl ved rettighedssystemet i unix er den almægtige root-bruger. Efter 10 år opgav unix-leverandørene i 1999 at lave en POSIX-standard for at opdele roots rettigheder i mindre "capabilities" og med version 2.6.24 af Linux-kernen kan jeg vist endelig erstatte suid-bitten på visse programmer med et flag der fortæller at programmet netop skal kunne lave rå IP-forbindleser (ping, for eksempel)

Hvad er jeres yndlings-hadehistorier? Både nuværende og historiske anekdoter modtages.

Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Lasse Hillerøe Petersen

Som (Danmarks eneste?) NetBSD bruger er det vel på sin plads at jeg kommer med min yndlingshistorie (og kritik) af en komponent som mig bekendt stammer fra Berkeley, nemlig csh. Nu er kritik af csh jo en gammel nyhed, alle har vel læst (eller burde have læst) Tom Christiansens harske essay om csh-considered-harmful.

tchrist fokuserer desværre på csh som scripting sprog, og derfor er der en del der alligevel vælger at bruge (t)csh til interaktiv shell, bl.a. en del af mine kolleger. Jeg vil på det kraftigste advare mod denne praksis, så meget mere koster det ikke at skrive set -o emacs i Korn shell og trykke to gange escape for completion.

Min kollega loggede ind på et system for at finde nogle fejl i logfilerne. Som sædvanlig var hans første kommando:

$ tcsh

De to næste var: % cd sti/til/apache/logs % grep "fejlmønster" * >matcherfejl

Ganske kort efter var filsystemet fuldt (og der blev selvfølgelig ikke logget mere før det problem var løst.) Det var ikke sket med nogen Bourne shell variant jeg kender til.

Efter min mening burde csh fjernes fra alle Unix-varianter og -alikes.

-Lasse

  • 0
  • 0
#2 Deleted User

Så man bliver en "Unix-hater" hvis der er et par corner cases som ikke fungerer optimalt?

Så ved jeg ikke helt hvad mit forhold til MS er :) Jeg kan i hvert fald også komme på ret mange eksempler der efterlader en Windows installation som en rygende ruin

Dermed ikke sagt at der ikke er plads til forbedringer

  • 0
  • 0
#3 Poul-Henning Kamp Blogger

Det er det fordi UNIX verdendens inkompetente tumper ikke har forstået at enes om et API der er bare nogenlunde moderne.

Istedet valgte man at lave POSIX til en standard som alle existerende operativsystemer kunne leve op til, helt uden tanke på fremtiden.

Det er den primære årsag til at jeg hader UNIX miljøet.

Poul-Henning

  • 0
  • 0
#4 Deleted User

hvis takken for at sætte sig sammen og skrive en standard (så der i det mindste er en :) ) er at blive kaldt inkompetente tumper, så tror jeg måske godt jeg ved hvorfor der ikke rigtig er nogen der sætter sig ned og gør noget ved det...

@PHK Ville du have lyst til at lave den slags? du er rent faktisk en af de personer der har kompetencen til at udtale sig om hvordan det kunne skrues sammen.

Min fornemmelse af i hvert fald de forskellig *Nix i open source der findes er, at der findes nogen meget store egoer der vil have svært ved at indrømme at deres måde måske ikke er "the-right-way(tm)" som nok bliver nødvendigt for at lave en standard.

  • 0
  • 0
#5 Poul-Henning Kamp Blogger

Det seneste forsøg på standardisering var Ted T'so og hans "Linux Standards Base" der begik nøjagtig samme fejl som POSIX, X/OPEN og SVID før ham.

I stedet for at kigge på hvordan UNIX skal programmeres om 10 år, kiggede de på hvordan det blev programmeret for 10 år siden.

Den dag der er nogen der vil tænke på fremtidige API'er, stiller jeg gerne op.

Poul-Henning

  • 0
  • 0
#7 Jacob Christian Munch-Andersen

Ikke nogen dårlig ide, spørgsmålet er bare om det er en god ide at kale en "om 10 år" standard for noget som helst med *nix. Alt andet lige så må et navnesammenfald betyde at det må have en hvis base i det nuværende, med dertil hørende legacy. Men det værste er nok at en hel del andre personer nok også gerne vil have noget at skulle have sagt omkring standarden, og det er jo velkendt at for mange kokke fordærver standarden.

  • 0
  • 0
#8 Peter Makholm Blogger

Efter min mening er der ikke bare tale om nogle får hjørnetilfælde. Prøv at se på følgende stykke bourne shell:

[code=shell] $ I=1 $ ls -l | wc -l 10 $ ls | while read file ; do I=$(( $I + 1 )) ; done $ echo $I [/code]

Hvad forventer du at resultatet bliver? I en traditionel bourne shell bliver resultatet 1 og det gør det stadigvæk i bash. Men hvis man i stedet skriver

[code=shell] $ for file in $( ls ) ; do I=$(( $I + 1 )) ; done $ echo $I [/code]

Så bliver resultatet 11 (i hvert fald i bash).

Der er mængder af den slags enkeltstående irritationsmomenter, der helt klart skyldes at man valgte den lette løsning og senere så ikke kunne tillade sig at lave den rigtige men noget mere komplicerede løsning.

Så kan man måske mene at scoping-regler i shellen bare er en lille detalje, men i min bog udgør shellen mindst en tredjedel af konceptet 'unix', så tåbligheder ala ovenstående berører selve grundlaget for at unix overhovedet er interessant.

Jo, had er et hårdt ord at vælge, men der vilel ikek være meget sjov i bare at taler om en lille pussenussedetaljer. Og nu er unix det system jeg har kompetance til at hade og så skal det helst være gennemført.

  • 0
  • 0
#9 Peter Makholm Blogger

Der er stor forskel på de kompetancer der skal til for at skrive et godt styresystem og for at lave standarder for styresystemer.

Basalt set ligner POSIX et resultat af hvad alle har kunen blive enige om, uden at det har kostet dem at lave ændringer. Det vil sige at vi har fået en standard der mere beskriver mindste fællesnævner for de kommercielle unixer anno 1995 end et system det er værd at stræbe efter.

Èn standard der beskriver absoult laveste fællesnævner er cirka lige så ubrugeligt som hvis Sun og HP hver især havde gået enegang om standardisere henholdsvis Solaris og HP-UX. Ingen gider at kode ud fra mindste fællesnævner, det bliver i bedste fald bare en ekstra variation ved siden af systemer der går ud over POSIX.

Standardisering handler ikke om at deskriptivt beskrive de områder hvor folk allerede minder om hinanden. Den virkelig gode standard giver os ent endnu bedre mål vi alle kan stræbe efter.

  • 0
  • 0
#10 Claus Agerskov

Peter, læg mærke til at PHK skulle være igangsætteren og ikke den der skulle være tovholder eller hovedforfatter på en sådan standard.

PHK har efter min mening både ry og rygte inden for netop styresystemer såvel selve programmeringen som holdninger til disse på et meget højt teknisk niveau.

PHK har efter min mening også kendskab til, hvem der kan bidrage med udviklingen af en sådan standard, så det netop ikke blot bliver en POSIX++ - men netop er med til at sikre, at man ikke arver fortidens fejltagelser.

Desuden skal der også tages højde for, hvad der sker inden for udviklingen af hardware, så man ikke også her baserer sig på fortidens synder.

De herligste hilsner Claus Ageskov, AgerCon - fri software og åbne standarder

  • 0
  • 0
#12 torben fjerdingstad

UNIX er inficeret af all-singing-and-dancing programmer, f.eks. bind og sendmail som ikke lever op til UNIX filosofien om mange små programmer der hver kan løse netop een opgave.

Gennem årene har er jeg kun ca. 3-4 gange stødt på folk som vil have vi-mode på kommandolinjen. Ellers bruger de emacs-mode selvom de ikke bruger emacs. Det er da sært.

UNIX print skal vi nok ikke snakke om.

  • 0
  • 0
#13 Henning Makholm

Men hvad skal vi med en standard der beskriver hvordan tingene skal ske om 10 år, hvis vi ikke kan kode op mod den nu? Og hvordan kan vi være sikre på at sådan en rent fremadskuende standard beskriver en grænseflade som både kan implementeres og anvendes effektivt? Hvis vi ved begge dele kan jeg ikke se hvorfor vi skal vente 10 år ...

Grundlæggende bunder problemet i at "Unix" ikke er et enkelt system, men en flerhed af systemer med hver sine udviklere som hver for sig og med vekslende overbevisning forsøger at holde udviklingen nogenlunde parallelt med resten af familien. Sådan en "flerkulturel" tradition har mange fordele, men bagsiden af medaljen er så at det tager lang tid før nogen nyskabelse trænger igennem til "laveste fællesnævner".

Mange problemer er jo lettere at løse hvis man accepterer at binde sig til én bestemt unix. I den post Peter linker til (tak for det, forresten. Og tillykke!) grumler jeg over et problem med at rydde op efter unix domain sockets. Det kunne jeg let have løst hvis det kun var Linux jeg udviklede mod, for Linux har et "abstrakt navnerum" for AF_UNIX, som ikke svarer til nogen stinavne i filsystemet. At jeg får problemer er en temmelig direkte konsekvens af mit ønske om at være mere portabel end som så.

Men det er jo ikke sådan at der sidder onde mennesker og bestemmer at vi skal programmere til laveste fællesnævner; det er et valg den enkelte programmør/projekt tager. Og det skyldes nok at der ikke rigtig er nogen nemme pejlemærker der ligger mellem "laveste fællesnævner" og meget specifikke mål a la "den til enhver tid ældste supporterede release af Debian med dennes default-kerne".

Hvad vi har behov for er standarder der hverken er minus 10 år eller plus 10 år, men giver et rimeligt mål for hvad man p.t. kan forvente at en "nogenlunde moderne og opdateret unix" kan, men ikke med vold og magt skal omfatte alt hvad der muligvis stadig står og kører et eller andet sted. I en ideel verden ville det være lige så nemt at sige "vi forudsætter mindst PIXOS 5" som "vi forudsætter mindst Windows XP SP1".

Udviklingen af nye PIXOS-versioner må naturligvis være fremtidsorienteret hvad angår detaljerne - den detaljerede specifikation må eksistere før de enkelte unixer kan rette ind efter den. Men hvad angår principper og arkitektur duer det ikke at skrive en standard før de har været afprøvet i praksis, og derfor lyder 10 år som en absurd lang tidshorisont.

  • 0
  • 0
#14 Peter Mogensen

Først tænkte jeg at der egentlig ikke var nogen ting jeg hadede nok til at det retfærdiggjorde en kommentar, men nu rendte jeg igen ind det og må erkende at jeg har et yndlingshade-objekt:

Hvad pokker går der galt for readline, når man resizer en X-term væk fra 80x24 til noget bredere?

Det er komplet umuligt at læse og redigere i sin history i bash og det har snart været galt i årtier på samtlige Linux-distributioner jeg har prøvet (gætter på det samme er galt på div. UNIX'er).

Hvis der iøvrigt er nogen, der ved hvad der går galt og hvordan man får det til at virke, så er jeg lutter ører.

Det var det... en lille, men ufatteligt irriterende ting.

  • 0
  • 0
#15 Peter Mogensen

... nevermind.

Man skal jo ikke sidde med hænderne i skødet, så jeg tog lige endnu en tur på Google desangående og denne gang var der vist bid. $ shopt -s checkwinsize

... skulle forklare bash/readline at man kan finde på at trække i sin xterm

  • 0
  • 0
#17 Dennis Krøger

Det er så forskellen på Linux brugere og os andre, vi andre mener ikke at et problem er løst blot fordi at en eller anden underlig kommando kan afhjælpe det. Det burde ikke være noget man som bruger har brug for at tænke på.

Jeg ved ikke hvilke distributioner Peter bruger, men den er automatisk sat i de fleste jeg har prøvet, så det er ikke noget man har brug for at tænke på.

I Windows er det forøvrigt langt værre... Der kan man slet ikke resize vinduet i bredden, uden at skulle ind et eller anden obskurt settings vindue.

  • 0
  • 0
#19 Jacob Christian Munch-Andersen

Det var nu mest Peters accept af problemets løsning jeg ikke kan lide. Han stiller sig tilfreds med han har muligheden for selv at løse det, uagtet at andre burde have løst det for ham. Det leder til en kultur hvor det er bredt accepteret at brugeren må arbejde for at få tingene til at virke.

  • 0
  • 0
#20 C S

Det leder til en kultur hvor det er bredt accepteret at brugeren må arbejde for at få tingene til at virke.

Fri Software handler ikke om at gøre det nemt for brugerne men handler om licens.

  • 0
  • 0
#22 Kristian Larsen

Det er altså et problem at der findes options til cli kommandoer?

Det er lidt som en af mine venner som altid har problemer med sin GPS fordi han ikke har læst manualen - men det er vel fordi Garmin skider på sine brugere...

  • 0
  • 0
#23 Jacob Christian Munch-Andersen

Det er ikke et problem at der findes muligheder for at tilpasse sine programmer, problemet er de tilfælde hvor default indstillingerne er ulogiske i og med at de fleste brugere vil være bedst tjent med en specifik anden indstilling, samt de tilfælde hvor brugeren tvinges til at foretage et aktivt valg uanset at et sæt almennytte indstillinger fint kunne være defineret på forhånd.

Der er en tydelig tendens til at Linux brugere tvinges til at skrive underlige kommandoer i tilfælde hvor Windows og OS X brugere kan nøjes med at klikke next, og basalt set opnå præcis det samme.

  • 0
  • 0
#24 Peter Mogensen

Jeg bruger Debian og/eller Ubuntu-maskiner og det skal understreges at det ikke er altid at der er problemer, men nogen gange, når jeg har ssh'et lidt frem og tilbage sker det jeg sidder et sted, hvor det er er svært at bruge history i et resized vindue. Det er ganske muligt at samme problem ikke er til stede i andre terminal-programmer end xterm.

Anyway... jeg forstår ikke hvordan i alverden Jacob Christian Munch-Andersen kan se i et problem i at det var muligt at løse problemet? Hvad havde han foretrukket? At man slet ikke kunne resize? At der ikke var nogen løsning? At der var garanti imod at software kunne have bugs? Har han prøvet at ssh til/fra en MacOS boks og se om problemet optræder der? Har han prøvet at ssh til en Windo... nåe nej... glemt det. Måske kan jeg ringe til ham næste gang jeg støder ind et problem til Windows og høre ham hvor den "next" knap han snakker om sidder? Jeg kunne f.eks. godt tænke mig at Wordpad ikke insisterede på at appende ".txt" til alle filer jeg gemmer. ... jeg kan ikke finde "next"!?

Linux er ikke perfekt, men jeg syntes det er en underlig kritik Jacob fremfører

  • 0
  • 0
#25 Jacob Christian Munch-Andersen

Jeg havde foretrukket at du havde holdt fast i at der er et problem. Selvfølgelig er det utopi at forestille sig at den slags småproblemer ikke forekommer engang imellem, men hvis det kun skal være engang imellem, så bliver vi nødt til at behandle dem som problemer når vi finder dem. Det er her at du fejler, du finder et workaround, og du er tilfreds. Det er altså ikke fordi at jeg specielt vil være efter efter dig, din accept af tingenes tilstand er jo kun en dråbe i havet, men det er utvetydigt en del af en jantelovs kultur som hersker i store dele af Linux miljøet. Hvis brugeren ikke kan få det til at virke, så er det nok brugeren og ikke programmet den er gal med. Dermed er der også overhængende risiko for at blive stemplet som en useriøs nybegynder hvis man påpeger en uheldig omstændighed i et program.

Spørgsmålet jeg så vil stille dig er, synes du at Microsoft og Xterm folkene skal lave om i nævnte programmer således at kommende udgivelser ikke lider af disse fejl? Og vil du åbent fortælle dem det?

Mit eget svar er utvetydigt, godt nok er det små fejl, men de påkrævede rettelser er tilsvarende små, så ingen grund til at de skal behandles anderledes end alle mulige andre fejl.

Og for nu at få det hele med, jeg skriver en tendens, jeg har på intet tidspunkt fremført at Windows eller OS X skulle være fejlfri, der er blot områder hvor de operativ systemer giver samtlige Linux distoer baghjul.

  • 0
  • 0
#26 Peter Mogensen

... og der er områder hvor man løber skrigende væk.

Men du mener altså at det at jeg var glad for at jeg endelig fik løst det problem og ikke istedet bitchede over at det overhovedet var der (jeg kan læse mig til at det oprindeligt skyldes et grundliggende UNIX API problem, bare for at blive on-topic), er et udtryk for noget dybere, der er galt med Linux-miljøet?

Hvad er der så udtryk for at jeg stadig ikke har fundet ud af hvordan man får Wordpad til at lade være med at kalde ens perl-scripts .txt? Hvad er det udtryk for hvis noget fortæller mig det og jeg bliver glad for nu at være blevet klogere?

... jeg fatter ikke din kritik.

  • 0
  • 0
#27 Jacob Christian Munch-Andersen

Men du mener altså at det at jeg var glad for at jeg endelig fik løst det problem og ikke istedet bitchede over at det overhovedet var der (jeg kan læse mig til at det oprindeligt skyldes et grundliggende UNIX API problem, bare for at blive on-topic), er et udtryk for noget dybere, der er galt med Linux-miljøet?

Hvis man sætter det lidt på spidsen så ja. Eller for at sige det på en lidt mere moderat måde, fejlen er ikke forsvundet blot fordi du har fundet et workaround, og der sidder stadigvæk masser af andre brugere og bander over problemet.

Hvad er der så udtryk for at jeg stadig ikke har fundet ud af hvordan man får Wordpad til at lade være med at kalde ens perl-scripts .txt?

At du ikke har oprettet perl-script filtypen i Windows's database vil jeg umiddelbart tro. (Hvis du bare associerer et program med filtypen sker det helt automatisk.)

Hvad er det udtryk for hvis noget fortæller mig det og jeg bliver glad for nu at være blevet klogere?

At du har så meget diskussionsformat at du kan glæde dig over at have fået denne viden frem for at sidde og surmule over den bedrevidende måde informationen bliver leveret på.

Samlet set kan vi nok konkludere at der mangler en stak extensions i Windows's database, og det bør MS selvfølgelig rette op på. Også selvom problemet ikke eksisterer for mere erfarne brugere som bruger associationer helt naturligt.

  • 0
  • 0
#30 Thomas Ammitzbøll-Bach

Jeg kan huske som dreng, da jeg var spejder, at vi på lejr. Vi byggede alle mulige cool ting, og vi fik en fantastisk følelse af samhøringhed og blev udfordret på alle sanser. Mange af de oplevelser har gjort, at mig til en, der se løsninger i stedet forblemer, forskelligheder i stedet for konflikter, og ser verden som en ressource og ikke som en jammersdal.

Men jeg husker en dreng, der altid hylede over ting, der var ubekvemt. Vi hjalp ham, men jo mere vi hjalp ham, jo mere hylede ham. Til sidst kom hans mor og hentede ham. Først var jeg bare glad, men så blev jeg også ked af det, for vi kunne jo ikke hjælpe ham.

UNIX/Linux er ikke altid så bekvemt. Jeg har bandet over meget forskelligt i tidens løb (behøver jeg sige "backspace" i et blandet UNIX-miljø? Eller hvad med isolatin/UTF-8?), men spørgsmålet er, om man opfatter det som en spejderlejr eller en badeferie. Hvis man gerne vil have en badeferie, så synes jeg, at man holde sig til sin mobiltelefon, Playstation og kioskwebbrowser. Hvis man godt kan lide at blive klogere og forstå mere hver dag, så er der masser af muligheder i UNIX/Linux-land.

Og lige til sidst: Hvis du finder en graverende fejl i et stykke opensource-software og du ikke som minimum laver en bugrapportering, så er du ikke værdig at bruge gratis software. Ellers må du kræve dine penge tilbage.

Thomas

(Jeg kender et par stykker, der roder med gamle amerikanerbiler. Det sker, at der kommer en spade, og vil købe en brugt bil fra 60'erne og regner med, at der ikke skal laves noget på den, at den har airbag/sædevarme/cruisecontrol, og at han bare kan køre den til serviceeftersyn en gang år og ellers bare hælde saftevand på. Hvad f.*n vil han dog så med en gammel amerikanerbil, hvis den skal være på samme måde som en ny?)

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