Teknologi

Tænk tilbage på de tidlige halvfemsere, tilbage til 3D-computerspillenes barndom. Dengang var 3D ikke nødvendigvis lig med polygoner, sådan som de er nu, i stedet var voxels (3D-pixels) en yderst realistisk mulighed. Som alle ved vandt polygonbaserede spilmotorer stort, hjulpet godt på vej af hardwareacceleration, men voxels har stadigvæk en fordel i kraft af deres fleksibilitet og gode understøttelse for kurvede overflader. Et blik på hvordan 3D i stedet kunne have udviklet sig kan man få ved at prøve Voxelstein 3D, et kort skydespil der bruger en voxelbaseret grafikmotor. Den vigtigste voxel-egenskab dette spil demonstrerer er hvor relativt nemt det er at lave spilområder som kan ødelægges - hvad der er yderst kompliceret med polygoner er trivielt med voxels. Jeg synes selv at det er interessant, men det er næppe overraskende at jeg er interesseret i halvdøde og obskure teknologier der påstår at kunne gøre alting bedre end det, der nu er mainstream.

Lidt forsinket kan jeg nu rapportere at jeg er vendt tilbage fra de svenske skove. Efter nøje granskning af vejret og de lokale myggepopulationer er jeg kommet frem til den afgørelse, at svenskerne bedst straffes for at stjæle Skåne, Halland og Blekinge ved at lade dem beholde disse jorde.

Store dele af verden har i de seneste par dage været hensænket i kaos og mørke, idet sigkill.dk, af årsager ude af min kontrol, blev suspenderet af min webhost, Unoeuro. Årsagen var, som jeg fik at vide i en email, at store mængder trackback-spam (eller forsøg, idet trackbacks er slået fra på denne blog) fik serveren til at gå i knæ. Omkring 3 dage efter jeg modtog denne email sendte jeg et svar tilbage om at jeg ikke forstod hvorfor min blog skulle være særligt ramt (jeg overvejede dog et kort øjeblik om musikkritikerne skulle stå bag, men deres bedrifter plejer altid at være akkompagneret af grammatisk fejlfyldt skryd på diverse IRC-kanaler), og Unoeuro var herefter uacceptable 12 timer om at svare at de havde åbnet siden igen. Jeg har til den ubloggende lømmel af en dagdriver, Kasper Tanggaard, lovet at sige at Unoeuro's behandling har været særdeles uacceptabel, og det er med stor glæde at jeg bryder dette løfte til den nidding af en giftblandende bolshevik.

Jeg forstår fuldt ud at Unoeuro ikke er i stand til at give ret meget traffik til hver af deres mange kunder, især i betragtning af hvor lidt jeg egentligt betaler for hosting. Det er naturligvis ærgerligt hvis det er trackback-spambots, og ikke horder af reklameklikkende læsere, der resulterer i at jeg må flytte til en dyrere host, men jeg skulle nu nok kunne klare en fordobling af hostingomkostningerne - helt op til 2€ om måneden!

Endelig er der et seriøst firma der begynder at arbejde på Firefox, så kan det være at browseren bliver værd at bruge. Det er jo tydeligt at de frivillige Mozilla-folk ikke har været i stand til at skabe kode af en tilfredsstillende kvalitet. Jeg håber at den nye fork vil føre til kraftige kvalitetsforøgelser!

Når man skal måle kvantiteter, størrelser eller andre absolutter er det rart, for ikke at sige essentielt, at have nogle enheder. Vi bruger f.eks. kilogram når vi snakker vægt, meter når vi snakker længde eller højde, grader celcius når vi snakker temperatur, osv. Men disse enheder er ikke uendelige sandheder der er nedfældet på stentavler eller dyrehuder af guddommelige krafter, ej heller er de fundamentale koncepter i universet - de er mere eller mindre arbitrære størrelser, som først for nyligt (det vil sige, i de sidste århundreder) er blevet tilknyttet specifikke fysiske størrelser. Igennem historien, og stadigvæk, har vi derfor været i den situation, at vi har haft flere forskellige enhedssystemer der har dækket over den samme ting. Noget af det vi stadig døjer med er at vi her, i den civiliserede verden, bruger metersystemet, mens de i det vilde vesten bruger det imperielle system (ironisk nok), hvor der på logisk vis går tolv tommer på en fod, og tre fod på en yard. Men i det mindste er der en utvetydig 1:1 overførsel fra enhed til fysisk størrelse - en tomme er en tomme og en fod er en fod. En mil kan så være en nautisk mil, en landmil, en svensk mil, osv., men det er også en af de få undtagelser. I det store hele har folk indset værdien i kun at have et enkelt, utvetydigt enhedssystem. Computerindustrien viser, naturligvis, her sin umodenhed ved at have et tvetydigt enhedssystem.

I daglig tale og skrift benævner vi størrelser på maskinlager i byte, kilobyte, megabyte, gigabyte og så fremdeles. Men hvor meget er en kilobyte? Hvis vi følger SI-systemet, hvilket man bør, så er en kilobyte lig ét tusind byte. På en moderne binær computer er tallet 1000 dog besværligt og halvmeningsløst, så vi definerer en kilobyte til at være 1024 byte. Hm. Det passer ikke helt ind i SI-systemet - hvad gør vi ved det? Vi starter med at ignorere det! Det gjorde man længe, og de fleste gør det stadigvæk, og det har den herlige konsekvens, at man aldrig er klar over om folk mener 1024 byte eller 1000 byte, når de snakker om kilobytes (selvom en kilobyte helt formelt er 1000 byte, idet SI-præfikset kilo betyder 1000). Men som sagt, tallet 1000 er upraktisk i kontekst af moderne computere. Om man skal forstå "kilobyte" som 1000 eller 1024 byte kommer altså til at afhænge af kontekst, og når forståelsen afhænger af kontekst, kan man tage fejl, hvilket ikke er hensigtsmæssigt, slet ikke når man har med computere at gøre. De er notorisk dårlige til at gøre og forstå det rigtige, med mindre man er helt præcis.

I 1999 valgte IEEE at løse dette problem på den eneste fornuftige måde, ved at indføre binære præfikser. Disse præfikser tillader en med 100% nøjagtighed at referere til bytestørrelser, der er en multipel af 2, og lader en bruge de sædvanlige SI-præfikser til at referere til størrelser, der er multipler af 10 (idet SI-præfikserne er designet med 10-tals-systemet i tankerne, hvor moderne computere som bekendt er binære). Det stopper dog ikke her - når man bare skriver "b" som grundlæggende enhed efter præfikset, menes der så bit eller byte? Med et lille "b" menes der bit, mens det store "B" betyder byte - hvis man vil være helt sikker på at det forstås som bit, kan man også skrive "bit" fuldt ud. Ved at følge disse regler, og være konsekvent med ikke at forbryde sig imod de standardiserede SI-enheder, kan man være sikker på at formulere sig helt korrekt og utvetydigt - mens dette måske ikke betyder så meget i daglig tale, kan det have betydning hvis man skriver et computerprogram der rapporterer lagerstørrelser eller forbrug. I disse tilfælde er det ofte, hvis ikke altid, ønskværdigt at være så præcis som mulig.

Nuvel - med disse regler er det muligt at konstruere en utvetydig repræsentation for 1024 byte: 1KiB. På samme vis er 1024KiB lig 1MiB og 1024MiB lig 1GiB. Det foregår på næsten samme måde når man ønsker at benævne 1000 byte, med den forskel at man skal bruge lille "k", og ikke store "K", idet store "K" benævner temperaturenheden grader Kelvin. Derudover er det ganske logisk: 1000 byte: 1kB. 1000kB = 1MB. 1000MB = GB. Med disse regler, og en liste over SI-enheder, kan jeg besvare titlens spørgsmål - hvor meget er 1gb? Det er muligt at give et svar, men svaret er ganske meningsløst: Et éttal er naturligvis 1, "g" er tyngdeaccelerationen (på denne planet, 9.82/(m/s²)) og "b" er bits. Svaret er altså 1gb = 9819999999/(m/s²) bit.

Hvad så med i daglig tale? Nu falder det desværre således at 1KiB udtalel som "én kibibyte", hvilket lyder bizart. Som de, der har været så heldige at høre mig nævne lagerenheder i talesprog, vil kunne bevidne, siger jeg kilobyte, megabyte og gigabyte, selvom jeg i virkeligheden mener kibibyte, mebibyte og gibibyte. Ak og ve! Hvorfor denne inkonsekvens - er jeg hyklerisk? På sin vis, ja. Jeg går langt mere op i at formulere mig korrekt og utvetydigt på skrift, hvor mine formuleringer og tanker i princippet kan leve uendeligt, og muligvis skal læses og forstås langt uden for den kontekst hvori de oprindeligt blev nedfældet, i modsætning til tale, der blot varer et øjeblik og derefter straks er uigenkaldeligt væk. Når man snakker er der et langt kortere feedback loop, samt en klarere fornemmelse af kontekst, der gør at man kan slippe af sted med at være langt mere upræcis. Derfor bestræber jeg mig på at bruge korrekte enhedsbetegnelser på skrift, hvorimod jeg ikke går det store op i det i daglig tale (hvor jeg primært benytter mig af enhederne fucking gigantisk og en ubetydelig klat).

Et overraskende velgennemtænkt og veludført træk fra statens side, er indførelse af den digitale signatur - hvis målet er at opnå en totalt papirfri forvaltning, så er det da noget der nok både kan forbedre serviceniveauet og spare penge på samme tid. For slet ikke at snakke om at det er meget lettere at have med at gøre for analog-underskrift-analfabeter som undertegnede (min underskrift består af blokbogstaver med svagt krøllede linjer - den er endda læselig, og dumper således på første krav for en god underskrift). En anden fascinerende mulighed som dette giver, er at alle og enhver kan benytte den digitale signatur som grundlæggende identifikationsmetode på websites og lignende - dette har den undtagelsesvist non-sucky Loke Dupont gjort med sin side dung.dk - en online-petition side som man allerede kender dem, men med den ekstra detalje at alle underskrifter foregår med en digitale signatur. Derved kan de lettere (eller i det hele taget) verificeres, og underskriftsindsamlingen får derved markant øget troværdigheden. Udover at siden er en interessant forbedring af det eksisterende underskriftsindsamlings-koncept illustrerer den også en, i mine øjne, ret fantastisk brugsmulighed for den digitale signatur.

Kasper Tanggaard igen om mærkelig spam. Jeg er også begyndt at få bizar spam (bl.a. base64-indkodet spam - WTF?), og jeg kan virkelig ikke forstå pointen i det. Hvordan kan det betale sig at sende emails ud, som kun få overhovedet ved hvordan man dekoder? Er det for at ødelægge spamfiltre eller hvorledes?

EDIT: Her er det herlige brev:

From: Â�¯@unoeuro.com, Â�S@unoeuro.com
Subject: ***SPAM*** ‚¨—ç
To: athas@sigkill.dk
Date: Sun, 18 Jun 2006 13:56:54 +0200 (CEST)

----102979246263254
Content-Type: text/plain;
Content-Transfer-Encoding: base64

hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSq
hKqEqoSqhKqEqoSqhKqEqoSqhKqEqg0KgVGBXoFRgV6BUYFegVGBXoFRgV6BUYFegVGBXoFR
gV6BUYFegVGBXoFRgV6BUYFegVGBXoFRgV6BUYFegVGBXoFRgV6BUYFegVGBXg0KgUCBQIFA
gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFA
gUCBQIFAgUCBQIFAgUCBQA0KgUCBQISshKqEqoSqhKqEqoStgUCBXoFAgUCBQIFAgUCBQIFA
gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBXoFAgUCBQA0KgUCBQISrgUCKroFA
kVOBQISrgZmBQIFAgUCDWoFFg3SBRYOMgUWDYoFFg06BRYNYIIFAgUCBQIFAgUCBQIFAgUAg
gZmBQCAgICAgIA0KgUCBQISvhKqErYFAgUCBQISvhKqErYFAgUCBQIFAgUCBQIFAgUCBQIFA
gUCBQIFAgUCBQIFAgUCBQIFAgUCBXoFAgUCBQIFAgUCBQA0KgUCBQIFAgZmEq4FAlrOBQJe/
gUCEq4FAgUCBYI+XgsyOcYNBg2iDjINYjPaKSoJhgmGCcoFAgUCBQIFAgZmBQIFAgUCBQIFe
gUCBQA0KgUCBQIFegUCEr4SqhKqEqoSqhKqEroFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFA
gUCBQIFAgUCBQIFAgUCBQIFAgUCBmYFAgUCBQA0KgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFA
gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQA0K
gV6BUIFegVCBXoFQgV6BUIFegVCBXoFQgV6BUIFegVCBXoFQgV6BUIFegVCBXoFQgV6BUIFe
gVCBXoFQgV6BUIFegVCBXoFQgV6BUA0KDQqBQCAgICAgICAgICAgICAgICCBq4FAgauBQINB
g06DWoNYgs2CsYK/gueBSYFAgauBQIGrDQqBQCAgICAgICAgICAgICBodHRwOi8vbG92ZS1m
bGV4Lm5ldC9zZngvaW5kZXguaHRtbD9tZWRpYT1wYzM0Mw0KDQqEqoSqhKqEqoSqhKqEqoSq
hKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSq
hKqEqoSqDQoNCoFAgZ2C4IKtgraBnQ0KDQqBQIJQgUSDWoN0g4yDYoNOg1iCzYqukVOWs5e/
gUkNCg0KgUCCUYFEgnKCb4JkgmSCY4OBgVuDi4LFj5eCzI5xgvCRX4KijIKCv4FJDQoNCoFA
glKBRINHg42OyoOBgs6CqYLogsyTb5hej5eQq4FJDQoNCoF8gXyBfIF8gXyBfIF8gXyBfIF8
gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8
gXwNCoF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8
gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXwNCoFAgUCBQIFAhKyEqoStDQqBQIFAgUCBQISr
glCEq4FAgUCBQCCDWoN0g4yDYoNOg1iCzYqukVOWs5e/gUmBQIFAgUCBQIFAgUCBQIFAgUCB
QIFAgUANCoFAgUCBQIFAhK+EqoSugUCBQIFAgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGB
QIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUANCg0KgUCBm4FAg1qDdIOMg2KDToNYgs2T
b5hegsyVS5d2gsiCtYFCDQoNCoFAgUCBQJP8ie+U75dwgUCBY4FjgWOBY4FjgWOBY4FjgUCC
T4l+gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUANCoFAgUCBQJNvmF6U
75dwgUCBY4FjgWOBY4FjgWOBY4FjgUCCT4l+gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCB
QIFAgUCBQIFAgUANCoFAgUCBQI+XgsyOcYLMg3aDjYN0im2URoFAgWOBY4FjgUCCT4l+gUCB
QIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUANCoFAgUCBQI+XgsyOcYLJkryD
gYFAgWOBY4FjgWOBY4FjgUCCT4l+gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCB
QIFAgUANCoFAgUCBQIJygm+CZIJkgmODgYFbg4uBQIFjgWOBY4FjgUCCT4l+gUCBQIFAgUCB
QIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUANCoFAgUCBQI+XgsyOcYKpgueCzJXUkE2K
bZRGgUCBY4FjgUCCT4l+gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUAN
CoFAgUCBQIFQgVCBUIFQgVCBUIFQgVCBUIFQgVCBUIFQgVCBUIFQgVCBUIFQgVCBUIFQgVCB
UIFQgVCBUIFQgVCBUIFQgUCBQIFAgUANCiAgICAggUBodHRwOi8vbG92ZS1mbGV4Lm5ldC9z
ZngvaW5kZXguaHRtbD9tZWRpYT1wYzM0MyAgICAgICAgICAgICAgICAgICAgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIIqukVOWs5e/gsWXVoLR
lfqR6ILFgreBSYFAgUAgDQoNCoFAgZuBQINUg0ODZ4LJg0GDToNag1iCtYLEgUGPl4LMjnGC
8JFJgvGCvoLnjGaOppTCgsmSvJDaj5GCq42egt6CvoKvgUKBQIFAgUANCoFAgUCBQIKggsaC
zZXUkE2XcINBg2iDjINYgvCTYIKmgsSBQY+XgsyOcYKpgueCzJXUkE2C8JHSgsKCvoKvgsWC
t4FCgUCBQIFAgUANCg0KgUCBm4FAj5eCzI5xgsyDdoONg3SMqYLpgsyCyZPBlcqCyI7okbGC
q4LNiOqQ2IKgguiC3IK5gvGBQoFAgUCBQIFAgUANCoFAgUCBQIOBg2ODWoFbg1eC8JGXgumN
24LNgUGDWoNMg4WDioNlg0KCqpackVOCyILMgsWMwpBsj+6V8YKqik+VlILJmFKC6oLpDQqB
QIFAgUCCsYLGgs2I6pDYgqCC6ILcgrmC8YFCDQoNCoFAgZuBQI+RgquNnoLcguqCvY/ulfGC
yYLCgqKCxILNg1SDQ4NnkaSCxYK1gsGCqYLogsaV24zsgrWCxIKigtyCt4FCDQoNCoF8gXyB
fIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyB
fIF8gXyBfIF8gXyBfIF8gXwNCoF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyB
fIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXwNCoFAgUCBQIFAhKyE
qoStgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCB
QIFAgUCBQIFAgUANCoFAgUCBQIFAhKuCUYSrgUCBQIFAgnKCb4JvgmSCY4OBgVuDi4LFj5eC
zI5xgvCRX4KijIKCv4FJgUCBQIFAgUCBQIFAgUCBQIFAgUANCoFAgUCBQIFAhK+EqoSugUCB
QIFAgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBQIFAgUCBQIFAgUCB
QIFAgUANCg0KgUCBm4FAgXWI6pBsiOqQbILJg4GDYoNagVuDV4LwkZeC6YLIgvGCxJbKk3yB
doK7gvGCyJBsgsmCcoJvgmSCZIJjg4GBW4OLgUmBQA0KICAgICAgICAgICAgICAgICAgaHR0
cDovL2xvdmUtZmxleC5uZXQvc2Z4L2luZGV4Lmh0bWw/bWVkaWE9cGMzNDMNCoFAgUCBQC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS2BQIFAgUANCg0KgUCBQIFAgUCBnIFAjqmVqoLMg3aDjYN0gsaDgYNig1qBW4NX
gvCI6pDEkZeQTYFJDQoNCoFAgUCBQIFAgZyBQIONg0+DQ4OTkoaCzI+XgsyOcYLJkZeC6YLM
gsWCxoLJgqmCrZXUkE2CqpGBgqKBSQ0KDQqBQIFAgUCBQIGcgUCV1JBNgqqRgYKigsyCxYnv
gqKCvYKijp6CyYK3gq6J74KmgumBSQ0KDQqBQIFAgUCBQIGcgUCV1JBNgqqXiIK9j5eCzI5x
gsyShoKpgueOqZWqgsWRio7ogvCRSYLXgumBSQ0KDQqBQIFAgUAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tgUCBQIFA
DQoNCoFAgZuBQJXUkE2CqpGBgqKBSYFAg16DQ4N+g5ODT4Kql8eCr4Lqgs6M3JWqgsWJ74Km
gr+C4YKkgrGCxoLgicKUXIFJDQqBQIFAgUCV1JBNgqqTzYKigr2C54FBjqmVqoLMjUSC3YLM
j5eCzI5xgvCRX4KijIKCv4K3gumCvoKvgUkNCg0KgUCBm4FAjqmVqoLMkcyXzYKqi5aCt4LI
gueBQZOWkVKVoZCUgsyOcYLGguCVdIKrjYeCpoLEgrWC3IKigtyCt4FJDQqBQIFAgUCWs5e/
gsWCsYKxgtyCxYLFgquC6YNUg0ODZ4LNkbyCyYKgguiC3IK5gvGBSQ0KDQqBfIF8gXyBfIF8
gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8
gXyBfIF8gXyBfIF8DQqBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8
gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8DQqBQIFAgUCBQISshKqErYFA
gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFA
gUCBQIFADQqBQIFAgUCBQISrglKEq4FAgUCBQINHg42OyoOBgs6CqYLogsyTb5hej5eQq4FJ
gUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFADQqBQIFAgUCBQISvhKqEroFAgUCBQIGB
gYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBgYGBQIFAgUCBQIFAgUCBQIFAgUCBQIFAgUCBQIFA
DQogICAgICAgICAgIGh0dHA6Ly9sb3ZlLWZsZXgubmV0L3NmeC9pbmRleC5odG1sP21lZGlh
PXBjMzQzDQoNCiAggZuBQINag3SDjINig06DWILNk2+YXo+XkKuCzIrngs2Ct4LXgsSOyoOB
gsWKbZRGgsWCq4LcgreBQoFAgUCBQIFADQoNCoFAgZuBQIJngsiPl4LMjnGCqpG9gqKCzILF
gUGCZ5bak0mCzI9vie+CooLgisiSUILFgreBQoFAgUCBQIFAgUCBQIFAgUCBQIFAgUANCg0K
gUCBm4FAjGeR0YKpgueDQYNOg1qDWILFgquC6YLMgsWBQYKigsKCxYLgi0OMeYLJl5iXcILF
gquC3IK3gUKBQIFAgUCBQIFAgUCBQA0KDQoNCoFAICAgICAgICAggaWBQJazl7+CxYJngsiP
l4LMjnGCyYnvgqKCyY1zgq2CyILng1KDUoFJgUCBpQ0KICAgICAgICAgICAgICCRvINUg0OD
Z4LmguiI6pBsgsWC4JG9gq2CzI+XkKuC8IKggsiCvYLJgUINCiAgICAgICAgIIFAaHR0cDov
L2xvdmUtZmxleC5uZXQvc2Z4L2luZGV4Lmh0bWw/bWVkaWE9cGMzNDMNCg0KhKqEqoSqhKqE
qoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqEqoSqhKqE
qoSqhKqEqoSqhKqEqg0KDQqBQIFAgZmBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gZmB
fIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gZkNCoFAgUCBlJX8jnENCoFAgUCBlDIxgWAy
NY3OgUCRzIxegUaVV4+ADQqBQIFAgZSXVoLXgumOnorUgUaSi4KpgueCboJqDQqBQIFAgZmB
fIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gZmBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyB
fIF8gZkNCoFAgUCBQJWegsaCqYm7j8+VaYLGgqmPV4LfgumCzIKqjUSCq4GZgqifrZeOgrWC
xIKoj2+CqYKvgreC6YtAie+Cqg0KgUCBQIFAjcWL34LIgqKCyIKfgWMooS1fLTspDQoNCoFA
gUA+Pj4+PiBodHRwOi8vbG92ZS1mbGV4Lm5ldC9zZngvcmVnX2FwcGx5LnRwbC5odG1sP21l
ZGlhPXBjMzQzIDw8PDw8DQqBQIFAgZmBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gZmB
fIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gZkNCoFAgUCBlIpHikM9ZW1pPQ0KgUCBQIGU
MzGBYDQwjc6BQJHMjF6BRpVXj4ANCoFAgUCBlJdWgteC6Y6eitSBRpbpkoaCxYLggm6Cag0K
gUCBQIGZgXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIGZgXyBfIF8gXyBfIF8gXyBfIF8
gXyBfIF8gXyBfIGZDQqBQIFAgUCKxYzslXeC8IK1gsSCooLcgreBQo5kjpaCqpZagrWCrYLE
lYGSyoLJj2+J74KkjpaCqpROl+6TSYLJguANCoFAgUCBQI6eitSTSYLJguCT74K1gqKCxYK3
gUKDR4Nig2CCqpHljUSCq4LIgsyCxZOvgraCrYNHg2KDYIKqkeWNRA0KgUCBQIFAgquCyJBs
gsaSh5fHgq2CyILogr2CooLFgrcNCg0KgUCBQD4+Pj4+IGh0dHA6Ly9sb3ZlLWZsZXgubmV0
L3NmeC9yZWdfYXBwbHkudHBsLmh0bWw/bWVkaWE9cGMzNDMgPDw8PDwNCoFAgUCBmYF8gXyB
fIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBmYF8gXyBfIF8gXyBfIF8gXyBfIF8gXyBfIF8gXyB
mQ0KDQqBQIFAiq6RU5azl7+CzINgg4ODk4NYgsmBQZCllPGCspNvmF6JuoKzgqKBQg0KgUCB
QGh0dHA6Ly9sb3ZlLWZsZXgubmV0L3NmeC9pbmRleC5odG1sP21lZGlhPXBjMzQzDQo=

I går var jeg i biografen sammen med nogle andre kumpaner. Vi var med til et show som Microsoft afholdt, hvor de først ville fortælle lidt om deres kommende Office Open XML-filformat, og derefter lade os se Da Vinci Mysteriet. Filmen var okay, men det er ret tydeligt at historien egner sig bedre til bogform - de lange fortællinger manglende, og, paradoksalt nok, var der også for mange actionscener - så mange, endda, at man knapt nok nåede at få introduceret én, før man var videre til den næste. Jeg anbefaler helt klart bogen frem for filmen (men jeg anbefaler Dan Brown's anden bog, Engle og Dæmoner, endnu mere, den er langt bedre end Da Vinci Mysteriet).

Jeg vil ikke svine Microsoft til for at give gratis biografbilletter, men jeg er ganske bevidst om at jeg ville miste halvdelen af min læserskare (yep, alle tre), såfremt jeg undlod at give dem et par ridser i lakken ved denne lejlighed. Så det vil jeg nu gøre ved at nævne at det "tekniske" foredrag var alt, alt for tyndt. Det var blevet skåret ned fra et kvarter til kun 10 minutter, men jeg tvivler på at det var det der gjorde forskellen. Oplægget bestod af at oplægsholderen viste at man kan unzippe filer gemt i dette nye Office-filformat, og derefter ændre på de resulterende XML-filer. Når man så zippede dem sammen igen var dokumentet ændret ("ohhh!"). What joy. Jeg kunne ikke undgå at lægge mærke til at præcist det samme har kunnet lade sig gøre med OpenOffice.org's filformat i årevis, og det ligeså kan med OpenDocument-formatet. Jeg kunne godt have tænkt mig en forklaring på hvorfor Office Open XML er et bedre format end OpenDocument, men det blev der desværre ikke tid (eller lyst) til. Jeg studsede også lidt over at oplægsholderen postulerede at det nye filformat vil fylde mindre end det gamle - ja, det kan være at jeg ikke er blevet tilstrækkeligt påvirket af XML-hjernekontrol-laserne endnu, men plejer XML ikke at fylde en pæn bid mere end binær data? Hvordan kan de nye XML-format fylde mindre end de gamle binære, med mindre de gamle var ufatteligt svinske med pladsen? De steder hvor jeg har set binære formater konverteret til XML-formater (Mathcad, din bærmeyngel af et bjerg afføring besat af Satan og en brækbesudlet mudderpøl, jeg ser på dig) er filerne tværtimod blevet større, ofte i betragteligt omfang.

Jeg er rimeligt kold hvad OpenOffice.org versus MS Office angår - jeg bryder mig ikke om nogen af programmerne - så jeg går ikke synderligt meget op i hele denne formatkrig (og jeg afviser ikke kategorisk at Microsoft kan lave et åbent format, jeg er bare heller ikke overbevist om at OpenDocument ikke er godt nok), men gårsdagens "tekniske" oplæg var for tyndt, og det er en skam, for jeg var faktisk interesseret i at høre hvad de havde at sige. På de steder jeg plejer at frekventere er debatten rimeligt ensidig til fordel for OpenDocument, men jeg ser det ikke som synderligt viist at udtale sig om sagen, før man har fået belyst begge sider.

Lad mig først gøre opmærksom på at denne opdatering slet ikke er så sparsom, fordi jeg ikke kunne finde på noget at skrive. I stedet er det fordi jeg har taget første skridt mod at gøre min side mere international - 10% af mine besøgende er trods alt fra USA (og størsteparten af mine pageviews stammer fra Sydkorea, i form af ekstremt aktive, men pænt ineffektive, spambots). De sidste par dage har jeg haft en language switcher i sidebaren, og hvis man er fortrolig med de korrekte besværgelser og forbudne ord, samt har indgået blodpagt med en 4-5 højere dæmoner, kan man sandsynligvis benytte den til at skifte sproget på siden, hvormed man skulle opnå den glæde at kunne læse en saksisk introduktionstekst. Dette mirakel har jeg dog selv kun oplevet én gang, til trods for ihærdige forsøg.

Jeg mangler dog stadigvæk at finde ud af hvordan man sætter Serendipity til kun at vise danske indlæg, når dette er det valgte sprog. Hvis nogen ved hvordan dette kan lade sig gøre, så vil jeg sætte stor pris på at høre besked fra jer.

Nuvel, når blog-maskineriet ikke vil internationaliseres, så må jeg jo gøre det manuelt. Derfor har jeg oprettet en engelsk sektion, med mere information om mine igangværende programmeringsprojekter.

Edit: Læs dette. Nu.

Op igennem computerens udviklingshistorie, har det altid været et godt spørgsmål, hvordan man skulle lagre tekst. Da computere ikke er i stand til at lagre andet end tal, var det logisk at definere talværdier for bogstaver, og konvertere mellem disse repræsentationer, når det var nødvendigt at vise teksten på en terminal. Da der dog ikke er nogen fast, aksiomatisk definition på hvilken talværdi et givent bogstav har, og der kun er en begrænset mængde forskellige tal, der kan bruges, opstod der desværre en lang række forskellige tegnsæt, hvor hvert havde sin egen idé om hvilket tal et givent bogstav svarede til. I vesten havde vi ASCII, der senere udviklede sig til de forskellige ISO-8859-tegnsæt, af hvilke ISO-8859-1 og ISO-8859-15 er de mest udbredte. Globalt set har vi dog en større mængde fuldstændigt inkompatible tegnsæt (bortset fra ISO-8859-tegnsættene, hvis laveste 128 værdier alle er ækvivalente med standard ASCII), hvilket selvsagt er et problem. Derfor har vi noget kaldet Unicode, en standard, der skal tildele talværdier til stort set alle bogstaver i brug i den moderne verden (og den antikke, for den sags skyld, Unicode understøtter fønikiske bogstaver). Unicode er ikke perfekt, og det har svagheder der er blevet indført med henblik på delvis bagudkompatibilitet, men det burde være åbenlyst for enhver at det er et langt bedre valg end en myriade af inkompatible tegnsæt.

Et fælles tegnsæt er dog ikke nok - det er også behov for en fælles standard for indkodning af bogstaverne som en serie af bits. ASCII og ISO-8859-tegnsættene er 8-bit-tegnsæt (omend ASCII kun bruger de laveste 7 bit), så det er åbenlyst at det ikke er muligt at indkode Unicodes flere tusinde forskellige tegn med denne indkodning. Ydermere er det heller ikke en god idé at bruge en større, fast tegnbredde, f.eks. 32 bit, da mange vestlige bogstaver kan indkodes i 8 bit uden problemer. Disse problemer løser indkodningsmetoden UTF-8, ved at tillade bogstavs-indkodninger af variabel bredde (den mest betydende bit bruges til at identificere længden). Derfor ser jeg brug af UTF-8 til indkodning af al tekst som det eneste rationelle valg, for at bruge forskellige indkodninger og tegnsæt, afhængigt af hvilke symboler og sprog, teksten indeholder, er bare for ulækkert.

Hvis alle skifter til Unicode/UTF-8 vil tegnsætproblemet sandsynligvis være løst et godt stykke ud i fremtiden. Problemerne kan ganske vist løses ved at alle standardiserer på et vilkårligt tegnsæt, men kun Unicode indeholder nok tegn til at næsten alle kan blive tilfredse.

Folk kender vel efterhånden min indstilling til GUI'er, og programinterfaces rent generelt: Jeg er tilhænger af kraftfulde og effektive interfaces, også hvis det betyder at de har en næsten lodret indlæringskurve. Jeg ser stort set kun på slutpotentialet for effektivitet, når jeg skal bedømme et brugerinterface. Dette er mange uenige med mig i, især dem, der er tilhængere af begyndervenlige brugerinterfaces, som vi ser dem i de fleste moderne desktopsystemer. Disse interfaces er lette at lære, men har til gengæld ikke nær så meget potentiale som de mere eksotiske ekspertvenlige interfaces.

Opfinderen af det grafiske brugerinterface, Douglas Engelbart, er åbenbart enig med mig. Han så idéen med grafiske interfaces som en mulighed for at gøre det muligt for mennesker at arbejde endnu mere effektivt med computere - at visualisere mere kompleks information, end det er muligt med tekstbaserede interfaces. Nutidens interfaces er mere fokuserede på at gøre det let at udføre den samme opgave - se bare på den universelle desktop-metafor, en metafor, der går ud på at simulere virkelighedens svagheder på en computer. Det er ret dumt i mine øjne, og er en af grundene til at jeg bruger en tiling window manager. Jeg kan også lide Engelbarts musikmetafor: En kazoo er et instrument, som det er utroligt let at lære at bruge, men selv de bedste værker udført på en kazoo vil være af tvivlsom musikalsk værdi. På samme måde kan vi ikke forvente at skabe revolutioner indenfor HCI (human-computer interaction) hvis vi insisterer på at blive ved begyndervenlige interfaces.

Det er blevet til et ideal, at alle applikationer til en given "platform," skal ligne hinanden og bruge samme datamodel. Men dette forhindrer os også i at udnytte potentialet i computere - hvert problem bør have et skræddersyet interface, og så må vi bare acceptere, at det tager tid at lære at bruge effektive værktøjer. Ligesom alle andre videnskabsmænd og professionelle redskabsbrugere på planeten har accepteret.

I løbet af det sidste år har Sun Microsystems mere end flirtet med open source, især i forbindelse med OpenSolaris. Nu vil de også til at åbne "enterprise"-software. Det produkt, som mange har ment at Sun bør open-source, Java, er der dog intet nyt om, hvilket jeg absolut ikke forstår. Jeg kan på ingen måde se hvad Sun skulle tabe ved at udgive J2SE under GPL eller en lignende licens, de tjener jo alligevel ikke direkte noget på produktet, men på de dertilhørende services og værktøjer (alias, de har lavet et system så komplekst og barokt, at man er nødt til at bruge meget specialiserede værktøjer for at lave noget fornuftigt med det). En frigivelse af Java-VM'en, compileren, klassebiblioteket og hvad der ellers hører til, ville da, om noget, kun resultere i bedre frie udgaver af Java. Jeg har lidt svært ved at se hvordan en frigivelse af kildekoden skulle kunne gøre indhug på Sun's profit på markedet for gratis Java-runtimes.

Men hva', det er Sun, hvis de opførte sig rationelt, ville de miste deres firmakultur.

Microsoft's research-afdeling, der som regel laver nogle rimeligt interessante ting, der dog sjældent bliver udnyttede, er i gang med at lave et nyt styresystem ved navn Singularity; et projekt der skal besvare spørgsmålet om hvordan et styresystem ville se ud, hvis det var opbygget fra bunden med fokus på dependability. Det er et rimeligt interessant forskningsprojekt, skrevet i Spec#/Sing#/C#, men endnu ikke noget synderligt brugbart, og slet ikke noget der på nogen måde er i en position, eller blot potentiale, til at erstatte Windows.

Dette faktum har de fleste overset.

Mange danske websites har haft debatter kørende om systemet, debatter der snakker om hvorvidt Singularity vil erstatte GNU/Linux, Windows, Unix, om det er hurtigere, og især, at Singularity er et Microsoft-produkt. Det er det ikke - det er et forskningsprojekt, og når forskerne i en nyligt udsendt rapport offentliggør nogle benchmarks, der viser at GNU/Linux er hurtigere til at starte processer end Windows, bliver det opfattet som at Microsoft indrømmer at Windows er langsomt. Dette er ikke tilfældet, Microsoft Research er ikke lig med Microsofts produktafdeling. Singularity er ikke et produkt, planen med det er på ingen måde at erstatte eksisterende styresystemer (men muligvis inspirere dem), og vigtigst af alt, de mikrobenchmark-resultater forskerne har i deres tekniske rapport, er ikke et officielt udsagn fra Microsoft om noget som helst. Hvis folk havde læst rapporten, dens indledning, skimmet den, eller blot læst lidt på projektets hjemmeside, ville de vide dette.

Kasper Tanggaard kan ikke lide Opera. Idet Opera er min foretrukne webbrowser under Windows, siger Internettets love at jeg nu skal blive groft fornærmet, svine ham til, stille spørgsmål til hans sexuelle præferencer, og på anden vis slynge smæde udtryk efter hans person.

For det første bruger Kasper det argument at både HTML og CSS validerede, som ræsonnement for at siden skulle virke, og at det var Opera der var noget galt med. Dette er naturligvis ikke nødvendigvis korrekt, da W3C's validator primært checker syntaks, og overfladisk semantik. Blot fordi en side validerer, kan browserens output godt være i modstrid med det man ønsker, hvis man i sin CSS eller HTML, har indskrevet noget andet end det man i virkeligheden mene.

To af de problemer Kasper havde med Opera, var at Opera's standardindstilling for margin og padding-CSS-attributterne, åbenbart var anderledes end IE's. Men er dette overhovedet en overtrædelse af standarderne? Jeg har aldrig læst CSS-specifikationen igennem, men jeg tror ikke at der står så meget om standardværdier - det må browserproducenterne vil selv bestemme, og da det hele alligevel kan overrides i sidens CSS, er det vel i princippet også mere eller mindre ligegyldigt. Altså mener jeg heller ikke at dette er et problem i Opera.

Kaspers sidste problem med Opera, som han ikke har givet så mange detaljer om, kan naturligvis godt bero på frygtelige fejl og forbandelser i browseren, der gør den totalt uegnet som klient til webbrowsing. Og hans allersidste kommentar er naturligvis også korrekt, Opera er et djævelsk program fra vor tabte provins, Norge, et landområde vi hurtigst muligt må vinde tilbage igen, til Danmarks ære! Hvorfor er den slags sager aldrig på dagsordenen i Folketinget?

E-props og håndtegn og den slags til Kasper Tangaard, der står bag Udvikleren.dk og TSW Tetris 99, og som tillige er stormogul (med behørig krussedulle) over IRC-kanalen #udvikleren.dk, har nu lanceret Logged.dk, en log/quote-service. Interfacet (og opdateringsfrekvensen?) er præcist som på den klassiske logs.tsw.dk, der i årevis har forsynet verden med udsøgte bidder af IRC-visdom, men nu har de uvaskede masser også mulighed for at oprette deres egne grupper, og tilføje quotes og logs, der på ingen måder er morsomme, med mindre man er en del af den eksklusive gruppe, enhver IRC-kanal udgør.

Kort sagt: Hvis du har brug for en logside til din IRC-kanal, så se på Logged.dk.

Edit: Og som om det ikke var nok, har han netop relanceret sin blog, der vanen tro vil blive opdateret med en frekvens der får kontinentaldriften til at virke som et farthelvede.

Streaming er nok noget af det lammeste Internettet har frembragt. Hvorfor kan diverse medieudbydere ikke bare lægge filerne ud til download via almindelig FTP eller HTTP? Hvorfor skal vi rode rundt med MMS-URL's, mere komplicerede programmer end en webbrowser eller FTP-klient, og rode med ugudelige og obskure stykker software, hvis vi har lyst til at benytte materialet når vi er offline? Er det ikke både billigere og lettere at placere filer til download på en FTP-server, end at sætte en hel streaming-server op? Man kan jo stadigvæk pakke linket ind i en Flash-inficeret HTML-side, hvis man skulle have lyster i den retning. De fleste medieafspillere tillader oven i købet streaming fra HTTP og FTP-kilder, mens filen downloades, så det er ikke fordi man mister funktionalitet. Streaming er (naturligvis) godt til live broadcasting, net-TV, netradio, og lignende, men ikke til statiske filer der ikke ændrer sig. Så hvorfor er streaming blevet så udbredt? Helt ærligt - det er jo dumt.

Da Dice, en jobsøgningsside, skulle have sig en bannerreklame, valgte de at lave en funky kode-inspireret animation. Dog er jeg ikke sikker på at jeg har lyst til at benytte mig af Dice's tjenester, da animationen tyder på at de ikke har synderligt gode kompetencer indenfor deres virkefelt: http://sigkill.dk/blog/uploads/fuckedad.gif. Sådan når det når man forsøger at være popsmart i sin reklamekampagne.

I morgen skal jeg på studietur til Amsterdam, og jeg kommer først hjem om onsdagen. Derfor vil denne side være endnu mere død end sædvanligt i de næste par dage.

Her i aftes havde jeg på #udvikleren.dk en debat med KasperTech omkring vores allesammens yndlingsemner - interfaces og Emacs. Jeg har skrevet om det før: Her og dér og herovre og derovre og her er noget mere.

Hans hypotese går ud på at fordi Emacs ikke er synderligt kønt ("terminal-look" som han udtrykte det) nedsætter det ens effektivitet. Jeg mener at et programs udseende kun påvirker salgbarhed og intuitivitet - Emacs' interface er ikke intuitivt, det er der ingen der vil påstå, og det tager tid at lære, men til gengæld er det ganske effektivt, når det først er lært. Jeg kan godt se at Emacs' udseende nok får programmet til at se frygteligt skræmmende ud for mange der ikke er vant til den form for programmer (stort set alle Windowsbrugere), og at det derfor har en negativ indflydelse på indlæringskurven. Men jeg kan ikke se hvorfor et grimt design skulle kunne påvirke ens effektivitet med redskabet, når man først har lært det at kende. Det er et faktum at mennesker er gode til at tilpasse sig, og før eller siden vil man have vænnet sig til Emacs' design i en sådan grad, at enhver positiv eller negativ effekt det må have haft, vil være forsvundet. Derfor opfatter jeg Emacs som en investering - i starten bruger man en masse tid på at lære det at kende, tid hvor man er frygteligt ineffektiv, og konstant skal slå selv de simpleste ting op, men efter den tid er overstået, så vil ens effektivitet med programmet være højere end ens effektivitet med langt de fleste andre editorer.

For nu at stjæle en af KasperTech's metaforer, så svarer forholdet mellem [tilfældig editor] og et program som Emacs, til forholdet mellem en trehjulet cykel og en racercykel. Førstnævnte er langt lettere at køre på, man sætter sig bare op, og man skal ikke bekymre sig om at den vælter, eller andre af den slags tåbelige detaljer, og man kan umiddelbart derefter cykle fint omkring. En racercykel, derimod, kræver en del tilvænning - selv for folk der er vante til at køre på cykel kan en racercykel være et besværligt bæst at tæmme, og man vil sædvanligvis vælte rundt, og ønske sig tilbage på den trehjulede i den første tid. Men helt ærligt - du har ikke lyst til at køre Tour de France på en trehjulet cykel, vel? Når man først har lært racercyklen at kende, så er den et fantastisk redskab, der lynhurtigt kan bringe en rundt i verden. Og hvis racercyklen var lyserød med gule prikker, ville den så blive langsommere af den grund? Man ville synes at det var lidt pinligt at vise sig offentligt i starten, og måske ville denne nervøsitet resultere i flere styrt, men når man til sidst vænner sig til dens udseende, så kan man være bedøvende ligeglad. Det påvirker ikke ens endelige effektivitet. Det skal dog siges at det måske ville være mere hensigtsmæssigt at sammenligne Emacs med en alsidig mountainbike end en racercykel, idet en racercykel er et rimeligt ensporet og ufleksibelt værktøj - noget man ikke ligefrem kan sige om Emacs.

Dette argument gælder forresten for næsten alle "ekspertvenlige" editors, så hvis du er Vim-fanatiker, så behøver du ikke skrive slemme ting i min shoutbox.

Download Opera nu! Opera Software's CEO har lovet at han vil svømme fra Norge til USA hvis browseren er blevet downloadet mindst én million gange på søndag. Allerede nu er vi oppe på 600.000, så der er en god chance for at han bliver nødt til at indfri sit løfte!

Og så skader det jo naturligvis heller ikke, at den nye version af Opera (v8) er en udemærket browser.

Hvis der er noget Microsoft kan, så er det at bevare bagudkompatibilitet (og derved, helt automatisk, fremadkompatibilitet). Microsoft bliver tit kritiseret for at bryde bagudkompatibilitet i nyere udgaver af deres programmer, men, helt ærligt, det er direkte usandt. Som enhver der har læst Raymond Chen's blog ved, gør Microsoft's udviklere de vanvittigste krumspring, for at få gammel software til at fungere korrekt. De emulerer endda bugs! Rygtet siger også, at det orinale SimCity (der kørte under DOS), slettede et sted i hukommelsen, og derefter brugte en pointer til denne hukommelse. Dette var "fint" i DOS (ikke "fint" som "det var tilladt," men "fint" som i "DOS gjorde ikke noget ved det"). Den slags går dog ikke i Windows, for memory-manageren kunne have delegeret hukommelsen til et andet program i mellemtiden. Derfor var Windows 95-udviklerne nødt til at indsætte kode der checkede for om SimCity kørte, og hvis det var tilfældet, ændre på den måde hvormed memory manageren fungerede! Jeg tvivler seriøst på at Linux eller FreeBSD hackerne ville ændre på kernelkoden, for at akkomodere bugs i et program. Det er mildest talt uretfærdigt at kritisere Microsoft for dårlig bagudkompatibilitet. Uden det helt store arbejde kan man endda få Windows 1.0 applikationer til at køre i Windows XP (ToastyTech).

GNU/Linux har ikke nær så god binær kompatibilitet, og ofte vil en opgradering af glibc eller compileren resultere i programmer der nægter at arbejde sammen. Heldigvis betyder dette sjældent særligt meget, for efter en rekompilering er alt kørende igen. Hvilken model er bedst? Det er svært at sige. Microsoft-modellen kan gøre programmører dovne, idet de kan finde på at udnytte udokumenterede features, eller udføre handlinger der ifølge dokumentationen har et udefinérbart resultat, men som tilfældigvis virker, vel vidende at Microsoft vil sørge for at deres programmer vil fortsætte med at virke et godt stykke ud i fremtiden. Open-source modellen opfordrer derimod til at lave større arkitektoniske ændringer, der bryder binær kompatibilitet, og muligvis gør det mere besværligt for slutbrugeren. Dette er muligvis en af årsagerne til at det generelt ikke anbefales at installere programmer på en GNU/Linux-distribution, der ikke er pakket specifikt til den relevante distribution. Dette slipper man naturligvis let og elegant udenom, hvis man kompilerer ens software selv. Hurra.

Jeg har tidligere skrevet om styresystemet Plan 9. Det er udviklet af de samme der designede Unix, hvilket gør det ekstra interessant at Plan 9 nok er et af de mest mus-orienterede styresystemer jeg kender til. Plan 9 tilhængere argumenterer for at musen skulle være keyboardet overlegent til, nåja, stort set alt. De kan komme med alle de fine argumenter de vil, men jeg har utroligt svært ved at se hvordan det kan være hurtigere at bruge musen til at rykke ét tegn tilbage (hvilket indebærer at markøren muligvis skal flyttes meget langt på skærmen, og anbringes med stor præcision det rigtige sted), for at rette en tastefejl, end ganske enkelt at bruge piletasterne (eller C-b C-f i Emacs). Plan 9 er således noget nær et brugerinterface-mareridt, det er meget tekstbaseret (ligesom Unix), men dette tekst-interface er i højere grad frustrerende, end effektivt, fordi man tvinges til at bruge musen til unaturlige opgaver. Jeg tror at Plan 9-udviklerne skal tage et kig på Emacs, for at se hvad et tastaturinterface virkelig er i stand til, i stedet for at sammenligne deres mus-helvede med et subsæt af kommandoerne i en gammel udgave af vi.

Visual Basic (og Basic generelt) har et yderst skidt ry blandt mange programmører. De har ry for deres ofte meget åndssvage syntaks, og af at de opfordrer til spaghettikode - noget som nyere implementationer dog har modvirket. Jeg vil med det samme sige at min erfaring med Visual Basic heldigvis er yderst mangelfuld, så jeg vil lade Kasper Tanggaard om at oplyse jer om Basic's fortrædeligheder, i et passende navngivet indlæg.

Nuvel, jeg har, som jeg sagde, ikke overvældende meget erfaring med Visual Basic, og afskyer det mest pga. de skræmmehistorier som alle har hørt, og den, i mine øjne, kluntede syntaks. Med VB.NET forsøgte Microsoft at løse nogle af problemerne med Visual Basic, og resultatet er da også blevet et sprog der i det store hele minder meget om C#, blot med en Basic-lignende syntaks. Der er stadigvæk irritationsmomenter, f.eks. case-insensitivitet, men det er til at leve med. Det lader dog til at old-style Visual Basic (åbenbart VB6-udviklere) har utroligt meget imod Microsoft's forbedringer. Hvilke katastrofale og kataklysmiske ændringer har Microsoft så bragt, der fuldstændigt eliminerer disse udvikleres evne til at producere software? Jo, her er nogle udvalgte kritikpunkter:

• Arrays may not have a lower bound other than zero.
• Dates are not stored internally as Double values.
• Longs are not 32-bits; they are 64-bits.
• Integers are not 16-bits; they are 32-bits.
• Core language constants do not have a "vb" prefix (vbRed becomes Red).
• Parenthesis are not optional when calling procedures.
• Code is not compiled to native, thus making decompilation much easier.
• Line numbers are not supported. Labels may be numeric.
• The MsgBox function is not supported.
• Setting a Timer control's Interval to 0 does not disable it.

Jeg er helt vild med at de brokker sig over at interne repræsentationer bliver ændret. Hvilke programmeringsstilarter har Visual Basic opfordret til, hvis en variabels interne repræsentation kan være af betydning? Og at antallet af bits i typerne tilmed bliver forøget? Har disse programmørers programmer afhænget af overflows, eller hvordan skal det fortolkes? Det er også dybt bizart at de brokker sig over at mange af Visual Basic's egne klasser og objekter er forsvundet, til fordel for .NET-klassebiblioteket. Især kan jeg også godt lide at de brokker sig over at GUI-funktioner er forsvundet fra selve sproget, og i stedet er blevet til et meget omfattende library. Faktisk beror mange af kritikpunkterne på at ting er blevet flyttet ud af sproget og ind i .NET. Jeg ved ikke om disse programmører har røget for meget bønne, men jeg ser den ændring som en forbedring.

Klagen over at GOTO ikke længere kan hoppe til linjenumre, men kun til labels, er bare så ufatteligt dum, at ingen yderligere kommentarer burde være nødvendige.

Jeg har fundet min nye browser - Conkeror. Det er en extension til Mozilla (desværre ikke Firefox) der gør det muligt at browse helt uden at bruge musen - og hvad der er bedre, alle keybindings er modelleret efter GNU Emacs! Yeah! Nu kan gnaveren få lov til at hvile i fred - endelig er der ingen museafhængige applikationer tilbage i min daglige arbejdsgang på min computer. Desværre virker Conkeror kun under Mozilla Classic, men pyt, det er jo samme renderer, og jeg tror ikke at jeg ville kunne mærke forskel alligevel. Jeg kan kun anbefale andre keyboard-brugere at prøve Conkeror, for det er i sandhed en fantastisk applikation (og tilmed en der tydeligt demonstrerer hvor fleksibel en platform Mozilla/Firefox er).

På NewsForge læste jeg i dag en artikel om en der bruger FreeDOS styresystemet på sin workstation. Dette fik mig til at tænke på hvorvidt vi egentligt har behov for alle de funky nye ting der bliver udviklet i disse år. Hvis vi måler ren produktivitet, hvor meget mere produktiv bliver en kontorarbejder så af 3D-interfaces, 64bit-farver, grafiske effekter og runde kurver, hvis vedkommende blot skal skrive en rapport vedrørerende organisationens sanitære budget? Hvis der skal skrives ren tekst, kan det så ikke gøres lige så godt i MS-DOS's EDIT-program? Jeg er jo selv tilhænger af ikke-grafiske og kommandolinjebaserede interfaces, men jeg bestrider ikke at grafiske interfaces har deres plads (især blandt novicer), men det er alt for let at lave interfaces der måske nok ser flotte ud, men som til gengæld er et helvede at arbejde med. Det kan godt være at præsentationslaget er vigtigt, når nye brugere skal præsenteres for programmet, men efterhånden kan det bliver yderst generende, hvis visuelle effekter kommer i vejen for ens arbejde. Jeg har tidligere forsøgt at køre udelukkende via en tegnbaseret systemkonsol, men gik tilbage til (semi-)grafiske interfaces grundet tekniske vanskeligheder. Måske jeg skulle prøve igen.

Jeg er begyndt at eksperimentere lidt med styresystemet Plan 9, godt hjulpet på vej af denne Wiki. Systemet kan hentes gratis, og der findes endda præpakkede VMWare disk images. Det er designet af de samme der stod for det oprindelige UNIX, og det er sjovt at se hvordan Plan 9 skiller sig ud fra sit fædrende styresystem. Plan 9 er langt mere museorienteret, og formår at give det "grafiske" interface samme form for elegance, som man ser i den klassiske UNIX-kommandolinje. Jeg har endnu ikke eksperimenteret med det særligt længe, men det virker yderst interessant... Desværre er der ingen udgave af GNU Emacs til Plan 9. Det er lidt røv. :-(

Nu kan selv folk der, af den ene eller anden grund, ikke er i stand til at køre et kvalificeret styresystem blive seje. Her er en fin guide til hvordan. Af en eller anden grund får jeg en million trackbacks til denne artikel, derfor er kommentering til den nu slået fra.