Recently in Norsk Category

Det har blitt mye tilbakemeldinger på mitt innlegg om filnavn. Noe tror jeg bygger på misforståelser eller en trang til personangrep, men noe er også god kritikk.

Premissene

Det jeg vil ha frem var at det er merkelig at vi (i dag) blander sammen filnavn og filtype og lagrer dette i samme enhet. Jeg er klar over at dagens teknologier er bygget på tanken om at slutten på filnavnet angir typen. Men er det sannsynlig at vi holder oss til disse begrensningene i fremtiden? Vil vi om 30 år fortsatt bruke tre bokstaver i filnavnet til å angi filens type? Om 50 år?

• Jeg mener altså ikke at vi alle burde slutte øyeblikkelig med hvordan vi navngir filer.
• Jeg vet altså at hvis vi våknet opp i morgen uten filendelser på filene våre så ville det blitt problemer.
• Jeg er klar over hva dette innebærer med tanke på filtype må overføres ved filoverføring og endringer i lesing og skriving av filer i operativsystem.

Den meste av kritikken går på å ramse opp hva det er med dagens filbehandling og filoverføring som gjør at et bytte i neste uke ikke vil fungere. Det er ikke særlig vanskelig. Det jeg påstår er at om vi ser bort fra dagens begrensninger og ser hvor vi vil i fremtiden, så er det naturlig å skille mellom navn og type. Jeg påstår at grunnen til måten vi gjør det på i dag er historisk heller enn at det å blande navn og type er en god idé.

Det er også ingenting som hindrer oss i å beholde informasjon om typen både i filnavn og som metadata i en 20-30 år, eller så lenge vi måtte ønske.

Eksempel 1

Jeg kan prøve å illustrere det med et eksempel:

Se for deg at vi i dag skulle designe et nytt OS fra bunnen - uten av vi var klar over historikken og konvensjonene knyttet til hvordan filer navngis.

• Vi kommer frem til at vi må ha en form for filer som representerer programmer og en rekke typer forskjellig informasjon.
• Om disse filene er vi interessert i å lagre en del informasjon (hvem eier filen, når ble den sist åpnet, når ble den opprettet).
• Vi vil også lagre noe som forteller oss hva denne filen inneholder.

Jeg har vanskelig med å se for meg hvordan disse hypotetiske designerne tenker at “informasjon om filene lagres som metadata - med unntak at informasjonen som sier hvilken type fil dette er. Den putter vi inn sammen med filnavnet.”

Hvis noen mener de vet noen god grunn til at dette er en god løsning, så må de gjerne opplyse meg.

Eldre OS skiller mellom navn og type.

Når tidlige OS ble designet blandet de ikke sammen navn og type (DOS skiller for eksempel mellom filnavn og filtype). Det var satt av 8 bytes til navn, og 3 bytes til type.

Dagens OS skiller ikke mellom navn og type, men stoler på konvensjoner. (De siste ca 3-5 bokstavene etter siste punktum i navnet angir hva jeg skal gjøre med denne filen).

Eksempel 2

Sett at du jobber som programutvikler. Hvis du bruker navnefeltet i en database til å angi personens type (kjønn), så får sannsynligvis kjeft.

• “Fornavn Etternavn.mann” er en dårlig løsning fordi den blander informasjon om navn med informasjon om kjønn. Den baserer seg på at et punktum skiller navn og kjønn. Skillet kommer ikke frem i måten dataene er strukturert.
• “Fornavn Etternavn” og et eget felt for kjønn er selvfølgelig bedre. Det skilles klart mellom navn og kjønn. (Det beste er selvfølgelig i tillegg å skille for- og etternavn)

Legg merke til at det er ingenting som hindrer deg fra å lese inn eller vise dataene på formen “Fornavn Etternavn.mann”.

Svar

For å referere til filer.

Det skrives at “filetternavn” er en god måte å referere til filer. Det nevnes et eksempel der readme.txt og readme.html ligger i samme katalog.

Det er selvfølgelig helt rett. Dette er nettopp det som er grunnen til at punktum opprinnelig ble innført som separator. Det jeg mener er at OS bør skille mellom navn og type basert på noe annet enn konvensjoner. Ditt OS bør skille mellom navn og type. Navn og type bør lagres som separate data. Jeg sier altså ikke at du ikke bør kunne referere til dine filer som readme.txt, (men det kan hende fremtidens OS presenterer filer anderledes)

Sortering

Du vil fortsatt kunne sortere filene dine om typen lagres separat. Dette klarte du i DOS. Du klarer å sortere basert på for eksempel dato i dag.

Ikke klag - det er bare å skru av i Windows.

Hvis du har lest helt hit så håper jeg du ikke tror mitt problem er at det er plagsomt å se på filendelser. Det er ikke poenget. Jeg er blitt anklaget for å skrive 90% microsoft-hat til å være en Windows-bruker basert på samme innlegg.

Hvert OS sin tilnærming.

Det som kommer klart frem av debatten er at forskjellige OS forholder seg til filtyper på forskjellige måter. Det er uklart hvordan filens type skal avgjøres.

Konvensjonen sier at de tre (enkelte ganger fire eller fem) bokstavene etter siste punktum angir hvilken type fil det er. Etter hver som vi får flere og flere filtyper, blir det trangt om plassen og mange typer brukes til forskjellige formål.

Si at du får tilsendt en fil som har navnet “navn.img”. Ditt operativsystem må finne ut av hva denne filen er og hvordan den eventuelt skal åpnes. I følge filext.com er det 24 alternativer.

Enkle OS slår bare opp program basert på filtypen, mens andre bruker andre metoder for å gjette seg frem. Det innebærer mye gjetting, og jeg mener vi i fremtiden bør kunne løse dette bedre. Ikke at løsningen er å kutte ut filtypen.

Norske myndigheter med sin forakt for våre privatliv utsteder i dag pass med RFID-chip. Make har en artikkel der det beskrives hvordan RFID kan settes ut av spill.

Jeg aner ikke hva som vil skje i det du prøver å komme gjennom tollen med et pass der RFID ikke fungerer, men det kunne jo vært gøy å funnet ut. (Eller?) Muligens litt hodebry for betjentene på flyplassen, men dine personopplysninger er iallefall noe tryggere. Når myndighetene ikke gjør noe for å beskytte våre privatliv bør man jo kunne ta grep selv.

Men det frister vel ikke å prøve, tatt i betraktning hva et nytt pass og en tapt utenlandstur koster.

Det er kjent at historie og vane veier tungt når det gjelder hvordan vi bruker PC’en. Jeg mener at dette er grunnen til at utviklingen går i sneglefart når det gjelder vårt grensesnitt til PC’er. Hender det du setter deg ned og tenker på filnavn? Hvorfor de er som de er og hvilke begrensninger som er knyttet til de? Neppe, med mindre din interesse til datamaskiner grenser til det syke. Undertegnede har altså tenkt mye på filnavn i dag.

For eksempel: README.TXT

En fil heter “README.TXT”. Dette er jo litt forvirrende - navnet på filen burde jo vært “README”. Slutten på filnavnet angir hvilken type fil dette er. “.TXT” forteller oss at dette er en tekstfil. Men vi kaller altså hele navnet (“README.TXT) for filnavnet. Er ikke det rart?

Problemet mitt er altså at når vi sier “filnavn”, så blander vi sammen filnavnet og filtypen.

Warum?

Grunnen til dette er historisk. I gamledager så ble filtype angitt på denne måten. Filnavnet var maks 5-9 bokstaver langt, og filtypen ble angitt av 2-3 bokstaver. Filtypen anga hvilken type fil dette var. Når brukeren skulle taste inn kombinasjonen filnavn + filtype, var det vanlig å skille de med et punktum. Tidlige versjoner av FAT-filsystemet (for de som husker DOS) bygget på denne tanken. Kjørbare filer måtte for eksempel slutte på “.EXE” eller “.COM”. Det kalles “8.3 filename” på godt norsk.

Dette er godt innarbeidet hos de fleste av oss, og (nesten) ingen tenker på det i dag. Jeg har erfart at hos enkelte er det så innarbeidet at de går i forsvarsposisjon hvis jeg påstår at det er en dustete måte å navngi filer på.

Dårlig design.

De historiske grunnene til dette er altså klare. Men hva er grunnen til at vi fortsatt har det i dag? Moderne filsystem støtter metadata som angir en rekke egenskaper ved filene. De forteller oss hvem som eier filen, om den er eksekverbar, når den var opprettet, sist lest, og så videre.

Det er også blitt såpass mange filer at det blir konflikter. Får du en DOC-fil, kan det være ren tekst, eller Microsoft Word-dokument. Får du en IMG-fil, kan det være et CD-image, en fotografi, bitmap bilde, eller et disk-image.

Det er tyvetydelighet rundt hvordan programmer viser filtyper. Du kan motta en epost med en “readme.txt” som du dobbeltklikker på. Det viser seg at filen egentlig het “readme.txt.exe”, og at din PC nå reklamerer stort for viagra eller billige armbåndsur.

Jeg har ikke lyst til å bruke mye tid i dag på å rakke ned på Windows (men det er vanskelig å stanse når jeg først begynner) - jeg har brukt GNU/Linux og BSD for lenge til å være helt oppdatert på Windows.

Altså, jeg mener at der i gården må filtypen være en del av filnavnet. Et program må altså ha et navn som: “program.exe” for å kunne kjøres. NTFS er designet for å kunne lagre en rekke metadata om filene, men Windows baserer seg på at filnavnet må slutte på “.XYZ” for å vite om den skal kjøres eller ikke. Hvorfor da ikke også lagre filtypen som metadata og bruke filnavnet til - tja - filnavnet? Helt idiotisk spør du meg.

Til Windows sitt forsvar, så er det vanlig at GUI på for eksempel GNU/Linux også baserer seg i stor grad på filendelser. Men GNU/Linux i seg selv bryr seg ikke et døyt om hva filen heter.

Andre begrensninger

Et annet tegn på det jeg mener er svakt design på Windows er reserverte filnavn. Du trodde kanskje et filnavn bestod av tekst og kunne være hva som helst (med unntak av noen spesialtegn)?

Windows har også en rekke reserverte ord som hindrer deg fra å lage filer med enkelte navn (du får det til hvis du prøver hardt nok, men det er ikke anbefalt). Du får ikke lage filer av navn som: CON, PRN, AUX, NUL, COM1 til COM9 og LPT1 til LPT9. Også her er grunnen for det meste historisk fra DOS sine dager, selv om “copy con filnavn.txt” eller “copy filnavn.txt prn” også (vistnok) skal virke i dag. Ønsker du å lagre medlemslisten til Namsos Ungdomslag i filen “nul.txt”, eller passord til dine porn voksen-nettsider i filen prn.txt, bør du altså bruke et ordentlig operativsystem. Dette har også ført til en rekke morsomme feil der du kunne provosere frem kræsj ved å referere til filer som “c:\con\con” på forskjellige måter (i HTML-dokumenter eller fra en FTP-klient).

Noe annet merkelig er at NTFS tillater filnavn som slutter på mellomrom eller punktum, men Windows vil ikke tillate dette.

. . Og jeg skal ikke engang begynne å skrive om at Windows ikke ser forskjell på STORE og små bokstaver.

Mitt poeng er at dette er dårlig design, men at det er vanskelig å endre det som brukerne har vendt seg til.

Bedre løsning?

Jeg forstår at folk har sine vaner, og at endring i brukergrensesnitt er noe mange brukere ikke nødvendigvis vil like. Det er kjekt å se ut fra endelsen hvilken type fil det er snakk om, men jeg mener heller at operativsystemer skal designes for å vise filtypen som en egen kolonne i utforskeren, ved ikoner, eller på andre måter. Det er ikke lett å erstatte vanlige teknologier (se på DAB-radioer eller IPv6), og det kan være en leng og smertefull prosess for brukere som har sine faste vaner.

Men er vi ikke snart klare for å legge bak oss begrensninger som stammer fra 60- og 70-tallets operativsystemer? På 70-tallet hadde filendelser en funksjon - i dag er bakoverkompatibilitet hovedårsaken. På Internet bruker vi allerede MIME-typer, og filsystemer lagrer en rekke metadata om filer. Jeg mener informasjonen om filtype er metadata og bør flyttes sammen med resten av metadataene. Filnavn bør brukes til - nettopp - filnavn.

Da har jeg brukt noen dager på å roe meg etter å ha lest Steve Pepper sin redegjørelse for prosessen i Standard Norge som leder til en godkjennelse av OOXML som en ISO-standard. Det er nesten uvirkelig å lese hvordan prosessen har foregått og hvordan Ivar Jachwitz har kapret avgjørelsen på tross klare råd fra den tekniske ekspertisen. Standard Norge har utgitt en mer fyldig redegjørelse der de forsøker å forsvare sin avgjørelse. Etter min mening graver de hullet enda litt dypere.

SN ventet seg kritikk

Som forsvar har SN hevdet at en avgjørelse kom til å bli kritisert uansett hvilken “side” som hadde vunnet. Dette er en stor overdrivelse. De som offentlig har lobbyet for OOXML er få i antall og har klare motiver. Ved å stemme nei til OOXML, ser jeg for meg at kritikken hadde kommet fra Shahzad Rana (som får betalt for dette), og (i verste fall) et par andre personer. Kritikken ved en nei-stemme ville altså blitt marginal.

Fast-track som metode

SN gjør klart at avgjørelsen om at fast-track var riktig prosedyre for denne standarden ble tatt av ISO. Det har hele tiden vært åpenbart at fast-track ikke har vært en riktig prosedyre, men vi som har kritisert har heller ikke lastet SN for dette. Greit nok - SN peker på ISO som vel bør få skylden.

Høringen

Det kom som kjent 37 likelydende brev i støtte for OOXML. Disse hadde store mangler som skulle tilsi at enkelte ikke engang var gyldige. Etter møtet i 2007 ble kritikerne beroliget med at disse ikke skulle tas hensyn til. (- og stanset med det en debatt som vi egentlig burde hatt den gang)

Så viser det seg at nå er de allikevel blitt gyldige stemmer “for” OOXML. SN redegjør at alle brevene kom med “kjent avsender og i undertegnet stand”. De unnlater elegant å nevne det som digi allerede har påpekt at de har store betenkeligheter knyttet til seg.

Videre i sin redegjørelse graver SN hullet dypere ved å gjenta at kriteriet for å endre vår nei-stemme fra 2007: For å lande på en ja-stemme skal kommentarene være tilfredsstillende løst (dette kommer klarere frem i pressemeldingen fra 2007). Dette har åpenbart ikke vært tilfelle.

Vurdering av BRM

Om BRM-møtet beskriver de antallet kommentarer som skulle vurderes som “betydelig”. Dette er i beste fall å underdrive. Andre beskriver det som et hastemøte der hvert land fikk tatt opp og diskutert 1-2 kommentarer. Den store majoriteten ble tatt som “hjemmelekse” og stemt over eller bulk-godkjent uten diskusjon.

Slik SN ordlegger seg så blir 2 kommentarer avvist. De resterende 10 ble “akseptert eller akseptert med modifikasjoner”. Det virker jo som at det store flertallet ble akseptert.

Steve Pepper ordlegger seg anderledes. Han skriver at det var enighet om at 2 kommetarer var løst, og at 2 ikke var løst. De resterende 8 var det uenighet om.

Jeg vil tro at det de aller fleste anså de resterende 8 som ikke løst, og jeg tror jeg vet hvem som helst ville anse de som løst. Tatt i betraktning at Microsoft har en betalt person til stede, så er det urimelig å vente seg konsensus rundt hva som er løst tilfredsstillende.

Partisk komité

SN trekker frem et åpent brev som ble undertegnet av en majoritet før komitémøtet som et tegn på at medlemmene hadde tatt stilling før møtet. Slik jeg forstår SN så antyder de at majoriteten av komiteen var forutinntatt og inhabile.

Dette er naivt - hele komiteen (med noen få unntak) har deltatt i den offentlige debatten rundt dette og argumentert for sitt standpunkt. Dette har foregått i over et år, og medlemmenes standpunkter er slettes ingen hemmelighet. Jeg forstår ikke SN sin påstand.

Avstemming

Det har vært klart at det ikke skal stemmes om SN sin avgjørelse. Men, SN sin uttalelse påpeker at det (samlet sett) var en overvekt av ja-stemmer.

Men vent litt - de har jo allerede fastslått at standarden har en rekke punkter som må utbedres. Hvorfor teller de da med stemmene fra 2007 da Microsoft stuffet komitéen og sendte inn ferdig-brev? Med mindre jeg husker helt feil, så uttalte de i 2007 at de ville se bort fra brevene.

For å sli det slik: De konkluderte i 2007 med at (på tross av majoritetens stemmer) standarden hadde punkter som måtte rettes. De så altså bort fra disse stemmene og deres ferdig-brev i 2007.

Nå, i 2008, teller disse stemmene og brevene igjen? Har SN snudd igjen og mener at kommentarene ikke var relevante? Stemmene fra 2007 var tatt på et helt annet grunnlag enn det som ble diskutert i 2008.

Ser man for seg det samme ved f.eks. stortingsvalg, ser man absurditeten. Når man stemmer gjør man det ut fra dagens situasjon. Selv om hva du stemte ved sist valg kan være en faktor for deg personlig, så er det ikke en faktor når stemmene skal telles opp. “FRP gjorde det godt dette valget - men ved forige valg var det ikke mange som stemte FRP. Vi får korrigere resultatet”

Vi kan jo fikse standarden

SN argumenterer med at vi bør akseptere OOXML som en standard for da kan vi fikse standarden. Da vil vi kunne “være i en best mulig posisjon for å initiere og delta aktivt i et slikt revisjonsarbeid”. Dette er et gyldig argument i seg selv, hadde det ikke vært for at SN motsier seg selv. I 2007 var de klare på at kriteriet var at kommentarerne skulle utbedres tilfredsstillende. SN skal ta stilling til hvorvidt standarden er god nok - ikke om den kan la seg fikses.

I følge Geir Isene sin redegjørelse var dette heller ikke et kriterie på møtet, med unntak av en bisetning fra Jachwitz mot slutten.

Det at ISO kan være i stand til å fikse standarden er altså et ugyldig argument fra SN. Tullprat altså.

Og de graver dypere . .

Avslutningsvis skriver SN at de mener ISO bør evaluere fast-track-prosedyren og de påpeker at ECMA sin mulighet for å bruke frast-track bør diskuteres. De skriver “Vi mener at arbeidet med OOXML ville ha vært bedre tjent med om det hadde vært initiert som et nytt ISO-prosjekt.” Så hvorfor i all verden trumfet du da igjennom en godkjenning, Jachwitz? Dette har vært nei-sidens kanskje sterkeste argument. Ved å stemme nei hadde vi tvunget OOXML gjennom ISO “fra bunn”, slik SN hevder de ønsker og slik nei-siden hele tiden har arbeidet for. Hvorfor i all verden avgir du da en ja-stemme på vegne av Norge? Og hvordan kan du begrunne norges ja-stemme ved å argumentere for en nei-stemme?