SIGKILL - Teknologi

Voxels

nospam@example.com (Troels Henriksen) — Mon, 12 May 2008 19:54:21 +0200

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.

Sverige og bloggens nede(r)tid

nospam@example.com (Troels Henriksen) — Wed, 08 Aug 2007 15:00:40 +0200

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!

nospam@example.com (Troels Henriksen) — Mon, 06 Nov 2006 15:39:11 +0100

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!

Hvor meget er 1gb?

nospam@example.com (Troels Henriksen) — Sat, 23 Sep 2006 00:02:50 +0200

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).

dung.dk

nospam@example.com (Troels Henriksen) — Sun, 09 Jul 2006 19:42:39 +0200

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.

Indkodet spam

nospam@example.com (Troels Henriksen) — Fri, 30 Jun 2006 14:37:23 +0200

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=

Da Vinci Mysteriet, Microsoft og filformater

nospam@example.com (Troels Henriksen) — Tue, 30 May 2006 16:15:46 +0200

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.

Sigkill.dk - nu med saksisk sektion

nospam@example.com (Troels Henriksen) — Sat, 25 Feb 2006 22:48:59 +0100

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.

Derfor Unicode

nospam@example.com (Troels Henriksen) — Sun, 19 Feb 2006 20:31:39 +0100

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.

Giv den døde hest nogle flere tæsk!

nospam@example.com (Troels Henriksen) — Sat, 28 Jan 2006 17:59:46 +0100

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.

Sun og open source

nospam@example.com (Troels Henriksen) — Sun, 04 Dec 2005 10:56:55 +0100

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.

Singularity - argh, spekulationer!

nospam@example.com (Troels Henriksen) — Wed, 09 Nov 2005 13:39:19 +0100

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.

Korrekt syntaks er ikke lig korrekt semantik

nospam@example.com (Troels Henriksen) — Sun, 30 Oct 2005 18:37:01 +0100

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?

logged.dk

nospam@example.com (Troels Henriksen) — Sat, 22 Oct 2005 20:41:55 +0200

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 sucks huge donkey balls

nospam@example.com (Troels Henriksen) — Sat, 08 Oct 2005 12:57:56 +0200

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.