Musings of ~kqr

Jag skrev förut om Floyds triangel i Haskell. Jag insåg nu att min triangel var onödigt komplicerad. Så här ska triangeln definieras i Haskell:

module Main where import Data.List.Split (splitPlaces) floydTriangle = splitPlaces [1..] [1..]

Har jag sagt förut att Haskell är coolt, eller? Nu satt jag och skrev en funktion som jag kan skriva om till ett mer lättförståeligt exempel. Vi kan låtsas att funktionen får som argument en person, och sen ska den returnera personens ålder om den är myndig, och annars ska den inte returnera någon ålder alls.

Alla personer har ingen ålder registrerad, så getAge-funktionen kan returnera antingen en ålder eller Nothing, som indikerar att det inte finns någon ålder. Funktionen för att returnera vuxna människors ålder kan se ut som följer.

adultAge person = do age <- getAge person if age > 18 then return age else Nothing

Detta fungerar och är bra och så. Först försöker den läsa in åldern till age-variabeln. Om den misslyckas med det kommer funktionen returnera Nothing. Om den lyckas kommer den istället gå vidare och se om personen är myndig. Om den inte är det kommer den returnera Nothing, och annars returnerar den åldern.

Problemet var att jag hade någon slags känsla av att jag i Haskell inte brukar behöva skriva kod på så här låg nivå. Att läsa in ett värde, och sen jämföra det med något annat, och sen returnera det kändes alldeles för mycket som Python och alldeles för lite som Haskell.

Så, jag funderade över vad som var det viktiga i min kod. Jag funderade över vilka datatyper som var involverade. Jag sökte på Hoogle. Jag hittade en funktion som gör det jag vill.

Den nya versionen av min kod blev följande.

adultAge = mfilter (> 18) . getAge

Och så var det klart.

Och det är så imponerande med Haskell. Det är superlätt att skriva kod som går att återanvända lite överallt, så om man letar finns det nästan alltid någon som har skrivit en smart funktion som gör att ens egen kod på fem rader kan kortas ned till en kort och snygg rad som betyder precis samma sak.

Hej. Jag är inaktiv för det händer mycket i mitt liv. Jag har svårt för att prioritera min tid och hur jag än gör blir det fel. Vänta inte mycket från mitt håll här. Jag jobbar av och till på en bok. Men vänta inte för mycket där heller. Jag behövde bara skriva lite nu.

Haskell är väldigt coolt.

Det dök i IRC upp en uppgift som lät som om den egentligen bara går att lösa ordentligt med Haskell. Den är som beskrivet härnäst.

Be användaren om ett tal $$n$$. Skriv sedan ut $$n$$ grupper med siffror, där varje grupp innehåller en siffra mer än gruppen innan. Med ett konkret exempel för $$n = 5$$ blir det till exempel

[1] [2,3] [4,5,6] [7,8,9,10] [11,12,13,14,15]

Först gruppen innehåller bara en siffra – 1. Nästa grupp innehåller de två påföljande siffrorna, 2 och 3. Gruppen efter det innehåller de tre nästa siffrorna, 4, 5 och 6. Så fortsätter det med så många grupper som användaren ber om.

Denna gruppering av siffror kallas Floyds triangel. Exemplet ovan är Floyds triangel med fem nivåer.

Denna uppgift är än så länge ganska enkel om man löser den på enklaste möjliga sätt: Du behöver bara skriva ut en siffra till skärmen skärmen i taget tills du har skrivit ut lika många som gruppens nummer, och sen börjar du på nästa grupp. Du kan lösa det med två forloopar eller en forloop och en ifsats. Men! Detta var inte hela uppgiften som den var presenterad för mig.

Uppgiften ska också lösas på ett så matematiskt sätt som möjligt.

Även om "matematiskt sätt" är en ganska luddig term så innebär det några få saker, bland annat att

Det ska finnas en funktion som ger Floyds triangel med önskat antal nivåer; det är inte okej att skriva ut varje siffra samtidigt som man plockar fram den, vilket innebär att koden som skriver ut triangeln ska vara skiljd från koden som skapar den,

Det ska inte gå att "misslyckas" med att använda koden – funktionen som genererar triangeln ska inte bero på något som kan göra att den genererar fel, och

Triangeln ska helst vara oändligt stor.

Det sista innebär i praktiken att man ska ha en variabel eller motsvarande som innehåller hela triangeln, och sen kan man hämta ut så mycket av den som man vill. Hela triangeln är naturligtvis triangeln som den ser ut när $$n$$ är oändligt stort, vilket gör uppgiften lite intressant. Men vi kommer till det. Här är lösningen, härligt kort, så dissekerar vi den alldeles strax!

module Main where import Data.List (unfoldr) floydTriangle = unfoldr (Just . nextFloyd) (1,1) where nextFloyd (number, quantity) = (take quantity [number..], (number+quantity, quantity+1)) main = do putStr "Depth? " depth <- fmap read getLine let finiteTriangle = take depth floydTriangle mapM_ (putStrLn . show) finiteTriangle

Vi börjar i toppen. De två första raderna är så uppenbara så jag vill ha de ur vägen.

module Main where import Data.List (unfoldr)

Dessa två rader deklarerar att det är ett program (module Main where) samt laddar in en funktion ur standardbiblioteket för listhantering (import Data.List (unfoldr).) Vi använder bara en funktion ur listbiblioteket (unfoldr), så det kändes lika bra att ladda in bara den. Nu tänkte jag hoppa över en variabel, och går direkt på main-funktionen!

main = do putStr "Depth? " depth <- fmap read getLine let finiteTriangle = take depth floydTriangle mapM_ (putStrLn . show) finiteTriangle

Mainfunktionen består i princip av tre delar:

Be användaren om antalet grupper ur Floyds triangel den vill ha,

Plocka ut det antalet grupper ur den oändligt stora triangeln, och

Skriv ut dem till användaren, en rad per grupp.

Den första raden, putStr "Depth? " skriver bara ut frågan om depth för användaren. Efter det läser vi in en rad text från användaren (getLine), konverterar den till ett nummer (fmap read) och sen sparar den i variabeln depth. Det intressanta är att fmap read skulle kunna konvertera till vad som helst. Varför konverterar den till ett nummer? Den kollar,

Vad används depth till? Aha, den används som argument till en funktion som tar ett nummer som argument – alltså måste depth vara ett nummer. Okej! Jag konverterar till ett nummer!

Haskells typsystem är väldigt flexibelt på så sätt. Trots att vi inte har angett en enda typ i hela programmet så kan den ändå lista ut vad alla typer ska vara, och den konverterar saker rätt beroende på vad de har för typ. Kompilatorn vet precis vilken typ en Floyd-triangel har (lista av listor av nummer.) Den vet precis vilken typ som den måste få för att kunna skriva ut något på skärmen (sträng) och den sorterar ut allt sånt innan programmet ens har kört. Är det något fel får vi veta det direkt!

När vi har läst in från användaren hur mycket triangel den vill ha så plockar vi ut så mycket triangel ur vår floydTriangle-variabel. Vi vet inte ännu hur variabeln skapas, men vi kan tänka på den som att den innehåller hela, oändligt stora Floyds triangel. Vi förutsätter det.

let finiteTriangle = take depth floydTriangle

Detta skapar variabeln finiteTriangle (icke-oändlig triangel) och sätter den att vara lika med de första depth lagrena av floydTriangle, som ju vara hela, stora, oändliga Floyds triangel. Nu kommer finiteTriangle vara en icke-oändlig lista av listor av nummer.

mapM_ (putStrLn . show) finiteTriangle

Den sista raden i main-funktionen konverterar varje lista inuti finiteTriangle (med mapM_) till en sträng (med show) och skriver ut den på en egen rad (med putStrLn.)

Du kanske undrar om det går att skriva ut den oändliga triangeln, istället för att ta en slice av den. Ja, det går, men det är ganska värdelöst med ett program som sprutar ut siffror i all oändlighet (faktiskt!), så vi väljer att avgränsa den till något värde. Om vi behöver mer av triangeln senare är det ju bara att be om ett större värde – hela den oändliga triangeln finns ju lagrad i floydTriangle.

Nu till den största magin, när vi skapar variabeln floydTriangle!

floydTriangle = unfoldr (Just . nextFloyd) (1,1) where nextFloyd (number, quantity) = (take quantity [number..], (number+quantity, quantity+1))

Floyds triangel följer ett unfold-mönster. De flesta saker man gör inom programmering följer något mönster, och ett av mönstrena är att generera en lista baserat på någon funktion och ett ursprungsvärde. Om man har ett ursprungsvärde, någon funktion, och vill göra en lista med värden, då är det ett unfold-mönster man ska implementera. Lyckligtvis finns det redan en funktion unfoldr i Haskells standardbibliotek för att jobba med listor, så vi använder den färdiga funktionen.

Och Floyds triangel kräver ju egentligen bara en unfold: man startar med numret 1 och gruppen 1, och man kan uppfinna en funktion för att generera nästa grupp. I Haskell-kod blir det

unfoldr (Just . nextFloyd) (1,1)

Funktionen unfoldr implementerar unfold-mönstret. Vi skickar med som ursprungsvärde (1,1), och funktionen för att ta fram nästa grupp är nextFloyd. (Vi skickar varje grupp genom Just-funktionen också, egentligen bara för att unfoldr vill värdena på ett speciellt format.)

När vi har insett att det är en unfold vi är ute efter, så blir det intressanta funktionen nextFloyd: den tar ett argument som består av två delar,

startsiffra, och

gruppnummer

och den ska generera ett resultat med två delar,

en grupp, och

en kombination av startsiffra och gruppnummer för nästa grupp.

Funktionen ser ut som följer.

nextFloyd (number, quantity) = (take quantity [number..], (number+quantity, quantity+1))

number är startsiffran för denna grupp, och quantity är gruppnumret, eller, om man vill, antalet tal som ska vara med i den här gruppen. Kom ihåg att antalet tal i varje grupp är lika med gruppnumret.

Svaret består av två delar, varav den första delen är gruppen man får med det startnumret och gruppnumret som skickas som argument.

take quantity [number..]

[number..] kommer att generera en oändligt lång lista av nummer, som startar med number. Till exempel [7..] kommer att generera listan som börjar med 7, fortsätter med 8, sen 9, sen 10, sen 11, sen 12 och så vidare. Vi plockar ur (take) gruppnumret antal tal (quantity) ur den oändliga listan, och kvar har vi en lista som börjar med number och innehåller quantity tal. Precis det vi ville!

Andra delen av svaret är delen som talar om för oss var nästa grupp startar och hur många tal den ska innehålla.

(number+quantity, quantity+1)

Denna kod returnerar startnumret för nästa grupp (number+quantity) och gruppnumret för nästa grupp (quantity+1). Sammanställt kommer funktionen returnera en grupp och villkoren för nästa grupp. Om vi matar in (7,4) kommer den att ge tillbaks dels [7,8,9,10] (den fjärde gruppen) samt (11,5) (villkoren för nästa grupp.) Om vi stoppar in villkoren för nästa grupp ((11,5)) i funktionen igen kommer vi få ut nästa grupp ([11,12,13,14,15]), samt villkoren för gruppen efter det ((16,6)). Funktionen i sin helhet är ganska enkel:

nextFloyd (number, quantity) = (take quantity [number..], (number+quantity, quantity+1))

Denna funktion, som ger en grupp och villkoren för nästa grupp, är precis vad vi behöver i unfold-mönstret. Det är så unfold-mönstret fungerar. Man har en funktion som ger ett svar och villkoren för nästa svar, och så matar man in villkoren i funktionen igen, får nya villkor och matar in dem igen. Ad infinitum.

Hela programmet sammanställt är

module Main where import Data.List (unfoldr) floydTriangle = unfoldr (Just . nextFloyd) (1,1) where nextFloyd (number, quantity) = (take quantity [number..], (number+quantity, quantity+1)) main = do putStr "Depth? " depth <- fmap read getLine let finiteTriangle = take depth floydTriangle mapM_ (putStrLn . show) finiteTriangle

och nu har vi ett lite bättre grepp om hur det fungerar. Det är dessutom matematiskt enligt kraven som ställdes i början. Triangelvariabeln innehåller till och med en oändlig triangel, för vår nextFloyd-funktion kan man ju använda på sig själv gång på gång på gång. Det är därför det är "viktigt" att vi plockar ut bara lite av den oändliga triangeln, för annars blir det väldigt mycket triangel väldigt snabbt.

Bonus!

Det finns ett annat sätt att implementera triangeln på, men som inte är lika snyggt enligt mig, eftersom det inte reflekterar problemets natur tydligt. Det ger dock något kortare kod. Det är följande.

floydAlternative = map group [0..] where group n = take (n+1) [(n*n + n + 2) div 2..]

group är en funktion som tar ett argument – ett gruppnummer. Med det gruppnumret genererar group den efterfrågade gruppen. (Obs! Här är grupp nummer 0 den första gruppen, till skillnad från i förra implementationen.) Exempelvis kommer group 3 ge [7,8,9,10] medan group 1 ger [2,3].

Men om man har en funktion som ger en grupp om man ger den ett gruppnummer, så behöver man ju bara använda den funktionen på alla gruppnummer för att få en färdig Floyds triangel. Det åstadkoms av map group [0..] som använder group på alla tal med start 0 och returnerar resultatet.

Denna kod är kortare och använder simplare koncept, men funktionen för att räkna ut en grupp baserat på dess nummer är inte alls lika snygg och lätt att förstå enligt mig, eftersom den kräver lite matematisk analys av hur grupperna kan räknas ut.

Så två processer kan inte försöka använda samma variabel samtidigt. Det ger problem. En naiv lösning är ju att bara förhindra dem från att använda samma variabel samtidigt. Det brukar kallas lås eller mutexes (mutex står för mutual exclusion och betyder att flera saker inte får komma åt en variabel samtidigt.)

Process 1 sätter ett lås på variabeln den använder, gör sitt med den, och låser sen upp låset. Process 2 får då sätta sitt lås på den. Det är faktiskt så här man oftast gör i dag när man gör något parallellt. Man låser variabler eller delar av minnet. Tyvärr är det inte utan problem.

Tänk dig att Erika och Jonas går på dagis båda två. Det finns två lådor med lego som man behöver för att bygga en tuff borg. Både Erika och Jonas vill bygga den där borgen, men de pratar inte med varandra så de vet inte om att den andra vill det.

Erika går fram till en av lådorna och sätter sitt lås på den för att han kommer att använda den. Erika går vidare till den andra lådan och upptäcker att Jonas har satt sitt lås på den. Erika ställer dig där och väntar på att Jonas ska bli klar med lådan och låsa upp sitt lås, men det händer aldrig. Erika står där natt efter natt och dag efter dag men aldrig låser Jonas upp sin låda.

Har du listat ut vad som har hänt? Jonas ville också bygga den tuffa borgen, så han låste lådan som var närmast honom och gick till lådan som Erika just hade låst. Där väntar Jonas på att Erika ska låsa upp sin låda, men det händer aldrig. Båda väntar på varandras lås och det här kallas för en deadlock.

Det finns naturligtvis strategier för att undvika deadlocks, som till exempel att alla måste låsa lådorna i samma ordning, men i någorlunda komplicerade system så kommer deadlocks uppstå ändå.

Deadlocks är inte heller det enda problemet med lås. Lås kan vara ineffektiva också. Tänk dig om en process behöver 57 variabler för någon lång uträkning, medan en annan process bara behöver en av de där variablerna för att skriva ut något. Om den långa processen hinner låsa variablerna först måste den lilla, snabba vänta länge på att få göra den där viktiga utskriften som den skulle kunna göra bara den fick.

Då kan man börja prata om lås som hindrar andra från att skriva, men de fortfarande får läsa. I vissa fall fungerar det, i andra är det väldigt dumt; tänk dig ett kärnkraftverk eller sjukhus där programmet inte får läsa en variabel som är halvskriven.

Så nu när gratislunchen är över måste vi göra program snabbare på något annat sätt. Parallellism betyder att göra flera saker samtidigt. Med flera kärnor kan man göra flera saker samtidigt. Ändå verkar det som att de allra flesta program som skrivs i dag bara kör på en kärna. De är skrivna för att bara göra en sak i taget.

Trots allt är det så vi är vana vid att programmera saker. Vi är vana att skriva kod på formen

gör det här

sen gör det här

sen gör det här

om det här är på något visst sätt

gör det här

annars

gör det här

och det här

och det här istället

när du är klar med det, gör det här

och gör sen det här

och så vidare. Det här är en lista på instruktioner som måste göras uppifrån och ned, annars blir det problem. Det går inte att köra något samtidigt där inte.

Den största boven här är variabler. Tänk dig följande kodsnutt i assembler.

li $t0, 0x03fb6c78 # stoppa in adressen 0x03fb6c78 till t0 lw $t1, 0($t0) # ladda in innehållet i adressen till t1 addi $t1, $t1, 1 # lägg till 1 på värdet i t1 sw $t1 0($t0) # stoppa tillbaks nya t1 till gamla adressen

Först hämtar man innehållet någonstans i minnet, sen ökar man på det med ett, och sen stoppar man tillbaks det. Det där är vad som i C skrivs

variabel++;

Ser du hur det är komponerat av fyra olika instruktioner egentligen? Där kommer problemet in. Tänk om det är två processer som körs på olika kärnor som ska göra det där. Om variabeln börjar med värdet fyra kan man vänta sig att efter att två processer har ökat den så blir värdet sex. Inte om de försöker öka samtidigt.

Process 1 hämtar variabel som har värde fyra

Process 1 lägger till 1 till variabel, som får värde fem lokalt i process 1

Process 2 hämtar variabel som har värde fyra i minnet fortfarande

Process 1 skriver tillbaks sin lokala variabel med värde fem till minnet

Process 2 lägger till 1 till sin variabel, som får värde fem lokalt i process 2

Process 2 skriver tillbaks sin lokala variabel med värde fem till minnet.

I slutändan har variabeln värdet fem i minnet, trots att vi väntade oss sex. Kaos! Det här är problemet med flera processer som kör samtidigt. De kan förstöra för varandra när de delar på minne och sånt.

Ända sen datorer började bli användbara på 50- och 60-talet har de alltid blivit snabbare, snabbare och åter snabbare. En dator i början av 80-talet var lite grovt 50 gånger snabbare än en i början av sjuttitalet. På ett år hann datorerna bli lite grovt 1.6 gånger snabbare.

Det här är vad som kallas för en gratis lunch. När man på 90-talet programmerade något, så kunde man medvetet göra programmet lite långsamt på dagens datorer, för när programmet släpps ett år senare, kommer det gå ungefär 1.6 gånger snabbare. Utan att programmeraren behöver göra någonting. Det sparar massa utvecklingstid. Programmeraren behöver inte bry sig om ifall programmet är lite långsamt, för hårdvaran kommer att komma ikapp.

Men något har hänt. Vi nådde området omkring 4 GHz vid 2005 eller 2006. Vi borde ju nu i 2012 ha allra minst 50 GHz. Varför har vi inte det? Det har hänt något. Det har hänt något stort.

När vi slog i 4 GHz-gränsen så blev värmen för mycket. Vi kan inte längre ha snabbare processorer, för de blir alldeles för varma. De som överklockar en bra bit över 4 GHz skaffar vattenkylning. Det räcker inte med luft då längre. Industrin tänker inte tvinga alla att vattenkyla sina datorer. Industrin har gett upp jakten på fler GHz.

Så vad kan man göra om man inte har snabbare processorer? Var tar utvecklingen vägen? Vi får fler kärnor istället. Nu har antalet kärnor börjat växa lika snabbt som processorhastigheten gjorde förut.

Nu, år 2012, tillverkas det väldigt få datorer eller datorliknande enheter med bara en kärna. Samtliga nya, häftiga mobiltelefoner har flera kärnor (oftast fyra.) Så vitt jag vet har alla spelkonsoler flera kärnor. Laptops och stationära datorer är flerkärniga. Surfplattor är flerkärniga.

Man kan inte längre utveckla långsamma program och vänta på att hårdvaran ska komma ikapp.

Jag tycker om att läsa böcker/sagor högt för andra. Det är avslappnande och roligt för både den som läser och den som lyssnar. Jag tycker att alldeles för mycket fokus placeras på synen i dagens samhälle. Det är trevligt när de andra sinnena får komma till tals, som till exempel hörseln under högläsning.

När jag skulle konfirmera mig så var jag på några gudstjänster innan, och pappa lärde mig något häftigt. När prästen högläste ur bibeln så var det många som plockade upp biblar och följde med i texten. Pappa lutade sig tillbaks, blundade, och lät prästens ord fylla honom istället. Jag smålog och tyckte att det var lite fånigt men jag provade det jag med.

Det är något speciellt med att hänge sig helt åt ett enda sinne. Man fokuserar på ett sätt som man inte gör annars. Man slappnar av på ett sätt som man inte gör annars. Efter den dagen i kyrkan när jag provade, så har jag aldrig följt med i texten när någon annan läser. Att följa med i texten är något små barn gör medan de lär sig läsa, eller något lomhörda människor gör när de inte riktigt uppfattar orden. Friska, unga människor har ingen anledning att följa med i texten. Luta dig bak, blunda, och låt dina öron göra sitt, ostört.

Men jag kommer av mig. I alla fall. Det är trevligt att lyssna på någon som läser högt. Det var väl min poäng antar jag. Att få läsa högt har en lite speciell betydelse för mig också, men den är ganska personlig så jag tänker inte skriva den här.

Men! När man läser normalt så läser man ganska snabbt. Man läser definitivt snabbare än man bör prata när man läser högt. Zoomzoom det går snabbt alltså, när man läser.

Normalt sett, i alla fall. Ibland dyker det upp främmande ord (Shikoku och tatamimatta är två exempel från senaste gången jag högläste i går) som man inte riktigt läser lika snabbt. Man läser dem till och med väldigt långsamt, eftersom man nästan måste läsa varje bokstav för sig när man ska uttala dem ordentligt.

Så, hur ska man göra för att inte staka sig och fastna när man kommer till främmande ord? Som YouTube! Jag märkte i går att när jag börjar läsa så läser jag en mening framåt eller något sånt, och sen säger jag orden jag just läst. Medan jag säger orden jag läste förut fortsätter jag att läsa nästa mening. På det sättet har jag alltid lite marginal att läsa långsamt ett tag om det behövs, för då kan jag bara "prata ikapp" där mina ögon är.

Att läsa en sak och säga en annan är inte något jag har gjort hela livet, utan det är något som har utvecklats sedan jag började läsa högt. En annan fördel med att koppla loss dem från varandra är att man kan snegla framåt ett stycke eller så i taget då och då, för om man vet var styckena tar slut och var det finns kursiva ord och liknande kan man bättre anpassa sin intonation och eftertryck och liknande till textens struktur. (Naturligtvis är det bäst att kunna texten man läser utantill, men hälften av tiden jag läser högt läser jag något som jag själv håller på att läsa, och därför aldrig har läst förut. Då behöver man alla ledtrådar man kan få.)

Något annat intressant jag reagerade på i går var att medan jag läser tyst för mig själv så bryr jag mig bara om den övergripande bilden av vad som händer. Jag är matematiker så jag är duktig på övergripande bilder, men jag undviker gärna att beblanda mig med detaljer så långt det går. De är bara ineffektiva.

När jag högläser tvingar jag mig själv att föreställa mig varje scen med alla detaljer, för att kunna återge författarens ord på ett så levande sätt som möjligt. Ja, det blir lite en personlig tolkning när man högläser, men poängen är att jag som läser högt får en mer konkret bild tillsammans med varje scen. Texten börjar betyda mer. Jag minns mer av vad som hände. Det är ganska tufft. I går regnade det och var jävligt när jag gick från affären, och eftersom jag höll på och sms:ades med vännen jag just läst för kunde jag konstatera att "Vädret känns precis som det gjorde i Shikoku." Ingen av oss vet ens var Shikoku ligger, men vi visste hur vädret var senast vi hörde om det. I boken. Det skulle jag aldrig dragit mig till minnes så omedelbart om jag hade läst tyst för mig själv.

Min huvudsakliga poäng var nog det där med buffringen, för det är det som fascinerar mig mest, men om du inte har högläst förut, prova att göra det för någon. Det kommer kännas jättefjantigt i början, men bry dig inte om det. Ta dig tid, läs inte för snabbt, våga variera din röst lite och fortsätt trots att det känns hur fånigt som helst. Det är trevligt.

Jag har alltid haft tur med hårddiskar. Jag vet inte varför, men ingen av mina hårddiskar har kraschat. Alla hårddiskar jag någonsin har använt fungerar än i dag. Dett är bara att koppla in dem och Bam! där finns all data på dem, precis som den såg ut när jag senast använde hårddisken.

Hela den grejen gör mig lite nervös. Det känns som att jag lever på lånad tid. Snart måste det vara min tur att få en hårddiskkrasch. Jag tänkte inte särskilt mycket på det förrän jag började jobba. På jobbet exponeras jag hela tiden för kraschade hårddiskar och liknande strul.

Och kom igen. Erkänn. Vi samlar väldigt mycket av våra liv på hårddiskarna nu för tiden. Allt på ett enda litet flyktigt minne. Så ja, jag började fundera på om det inte var min tur att ta backupper.

Backupper är en lustig grej. Det är en sån där grej som alla borde syssla med, men som de flesta inte börjar med förrän det är för sent. Om ens då. Man brukar inte förstå hur viktigt backupper är förrän man står i skiten. Så på sätt och vis kan jag väl vara tacksam för att jobbet öppnade mina ögon.

Min första tanke var att köpa ett ton dvd-skivor och sen bränna ut allt skräp med jämna mellanrum. Det är förmodligen den enklaste svenssonlösningen och det är tio miljoner gånger bättre än ingen backup alls. Jag orkade dock aldrig köpa dvd-skivor, så jag kom inte så långt med den idén.

I går började jag fundera på det där igen. Jag föreställde mig hur mitt drömsystem för backupper skulle se ut. En sak är säker: Det hade inga dvd-skivor i sig.

Nej, det jag förställde mig ser ut så här:

Skalbart. Till en början behöver jag kanske bara 20 gigabyte utrymme, men jag vill kunna utöka det närhelst jag behagar upp till terabytestorlek.

Krypterad överföring och krypterad lagring. Ett backupsystem som inte stöder kryptering ska man inte ta seriöst.

Simpel användning. Det finns massor av *nix-verkyg för att sköta backup redan. Jag vill kunna styra min backup med dem. Jag vill inte ha ett separat program för att backuppa. Jag vill kunna cronna rsync eller något sånt.

Redundans i någon form. Allra helst ska datan naturligtvis vara spridd över flera datacenter på olika platser på jorden, men absolut minimum är raid-6 på hårddiskarna där backuppen ligger.

De är de viktigaste bitarna, misstänker jag. Jag var bestämd att jag skulle starta en sån tjänst när jag hade råd. Sen gjorde jag en sista desperat sökning på internet, och

rsync.net.

Jag har en regel när det kommer till att ingå avtal. Om avtalet verkar för bra för att vara sant, så är det förmodligen det. rsync.net var alldeles för bra för att vara sanna. De är som om någon har läst mina tankar och byggt en tjänst skräddarsydd för mig. Jag bara skrattade mig genom deras hemsida, för jag var fast besluten att det var något skämt eller fuffens på annat sätt.

De har till och med ett datacenter i Zürich, Schweiz. Grejen med Schweiz är att de inte är med i EU, så de blir inte påtvingade alla fåniga skitlagar som vi blir påtvingade. När det kommer till personlig integritet så finns det förmodligen inget bättre än Schweiz.

rsync.net kan helt klart omöjligt vara på riktigt. De är alldeles för bra. Alldeles för perfekta.

Jag valde ändå att söka lite omkring dem för att se om det finns några omdömen av folk på internet. Det var förvånansvärt få som nämnde dem, men jag var redan fast. Jag ville ha en tjänst precis som rsync.net. Jag räknade lite snabbt och såg att 10 GB i en månad kostar bara ungefär 50 kr, så jag tänkte att om det är något lurt förlorar jag inte så mycket. Dessutom går det att som kund avsluta avtalet när som helst utan uppsägningstid. (Jag säger ju att de är för bra.)

Nu har jag fått igång automagiska backupper på min huvudsakliga dator. Jag tar en inkrementell backup varje natt, och sen roterar jag full backups en gång i månaden och sparar dem i två månader. Det borde räcka. Det återstår att se om rsync.net är så bra som de verkar vara, men hittills har de inte missnöjt.

Jag letar efter en bra backuptjänst för personligt bruk. Jag vet inte om jag har hittat den en, men jag ska prova rsync.net i en månad för att se om det är något att ha. På pappret är de helt otroliga, men jag väntar med lovorden tills jag har faktiskt provat dem ett tag. Däremot gör de en grej som fascinerade mig, som jag kan tala om redan nu.

De värnar om sina kunders integritet. De vill helst att ingen ska kunna se deras kunders filer, och de rekommenderar att man krypterar sina filer.

Men om polisen gör en razzia mot dem finns det en risk att polisen läser kundernas filer. Det är hemskt och det vill rsync.net upplysa kunderna om. Problemet är att i USA kan tydligen polisen kräva att rsync.net inte avslöjar att en razzia har skett. rsync.net vill kunna avslöja att en razzia har skett. Hur gör man då?

rsync.net går ut varje vecka med att en razzia inte har skett. De berättar en gång i veckan att de inte har haft något problem med polisen. Om de plötsligt slutar berätta det så vet alla kunder att de har haft problem med polisen och att kundernas filer kan ha blivit lästa av obehöriga.

Men… säger du. Hur vet man om de har slutat skriva såna meddelanden? De kanske bara lägger upp samma meddelande dag ut och dag in. Nej, de har ett trick mot det också. I varje meddelande finns det en eller två rubriker från dagens nyhetsflöde. Samma dag som de skriver ett meddelande tar de nyhetsrubriker från den dagen för att bevisa att meddelandena inte var skrivna i förhand. Så primitivt, men så smart.

Men… fortsätter du säga. Kan inte polisen bara fortsätta skriva meddelandena då? Nej, det kan de inte, för alla meddelanden är kryptografiskt signerade, så det är garanterat rsync.net som har skrivit dem. Och de har garanterat skrivit dem dagen de släpps. Och om de inte släpps så har de råkat ut för problem med polisen.

Enda sättet för polisen att dölja en razzia är om de fysiskt tvingar rsync.net-folket att skriva ett nytt meddelande och ljuga i det, men det kräver ganska mycket mer.

Så här säger jag: Jag har en kompis, och hans tre syskon är samtliga pojkar.

Det är ju helt otroligt, säger jag, Att alla blev pojkar kan ju inte vara vanligt!

Sannolikheten för att det skulle hända måste ju vara jättelåg, eller hur? undrar jag.

Ibland stöter jag på blogginlägg som jag egentligen inte är intresserad av, men jag läser ändå för att författaren skriver så bra. Det här är ett av dem.

När jag bodde med mina föräldrar drack jag ekologisk mellanmjölk. I massor. Jag dricker mycket mjölk, för jag tycker att det är gott även om jag är medveten om att det egentligen är ganska äckligt.

Sen flyttade jag till min egna lägenhet, och då blev det genast ganska dyrt att leva. Ett paket vanlig mjölk kostar 8 kr, har jag för mig. Ett paket mellanmjölk kostar 10–11 kr. Eftersom vanlig mjölk var billigare köpte jag det från dagen jag flyttade.

Några veckor senare började Arla med en ny förpackning för den vanliga mjölken. En förpackning med skruvkork i plast.

Vad i helvete?

Jag kan tänka mig en bra anledning för en skruvkork på mjölkpaketet: Om man är ute på utflykt på vintern och har mjölken i paketet (för den håller sig ändå kall på vintern) så kan man återförsluta mjölken medan man rör på sig.

Skruvkork är bra om och endast om man har mjölk med sig när man är på utflykt på vintern.

Bara då. Annars är vanliga paket helt i papper lika bra.

Newsflash: När jag var liten var jag ganska ofta på utflykt både på sommaren och vintern. Man kan faktiskt ha mjölk i en termos på sommaren och PET-flaska på vintern. Faktiskt.

Vad är då poängen med att lägga till en skruvkork i plast, som gör det mycket jobbigare att källsortera mjölkpaketet? Det finns ingen som helst poäng med det och det är idioti.

Man kan ju undra hur många dagar det går på en månad. Är det 31? Eller är det kanske 30? Eller 28 eller 29?

På fyra år går det, med skottår, $$365 + 365 + 365 + 366 = 1461$$ dagar.

På lika lång tid går det $$12 + 12 + 12 + 12 = 48$$ månader.

Hur många dagar per månad blir det? Per betyder ju division, så det är bara att dividera.

$$$\\frac{1461}{48} = 30.4375\; \\mbox{dagar/månad.}$$$

Joakim har köpt ny telefon, och undrar, Var är filhanteraren i Android? Nu råkar jag känna till det specifika sammanhanget och han behövde faktiskt en filhanterare, men rent generellt är det väldigt intressant att lyssna på folks krav vad gäller filhantering.

Om någon ber om en filhanterare som visar katalogstrukturen och har en "uppåt"-knapp, då vet man med ganska stor säkerhet att det är en datorkunnig människa som växte upp på 90-talet. Som använde datorer på 90-talet och i början av 2000-talet. De människorna vill ha ett träd med kataloger, och de vill kunna navigera sig uppåt och nedåt i trädet.

Men varför? Egentligen? Katalogträdet är ett koncept på hemskt låg nivå, och tanken är att användare inte ska exponeras för det.

Vill du läsa en pdf-fil? Starta pdf-läsaren och välj "Öppna" i någon slags meny. Bam. Där har du en lista på dina pdf-filer, kategoriserade på något smart sätt. Inte en katalog i sikte. Inte ett filträd i sikte.

Samma sak gäller bilder. Du ska inte leta upp jpeg, png och svg-filer i en katalogstruktur. Du ska öppna bildvisaren och trycka "Öppna" eller "Bläddra." Bam. Där har du en lista på alla bildfiler, kategoriserade på något smart sätt. Inte en katalog i sikte. Inte ett filträd i sikte.

Anledningen att det inte funkar så i dag är att ingen vågar gå fullt ut med det. Alla som har möjlighet att göra något sånt gör någon halvmesyr istället. De har kataloger i grund och botten och visar dem för användaren av och till. Och hoppas att användaren blundar just då. Kanske blinkade den. Men nej, det gjorde den inte. Där var de. Katalogerna. Det är nog säkrast att använda dem ändå, nu när de finns.

De funkade ju för tio år sen. Varför skulle de inte funka nu?

Kan använda dem bara för de här filerna. Bara. Och några till.

Innan man anar det har man en härlig soppa av kataloger och modern filhantering, och ingen vet riktigt vad som är vad och det blir bara en röra.

Och Joakim undrar, Var är filhanteraren?

Folk skrämmer mig.

För ganska länge sen var det naturligt att prata om folk som "negern" eller "den vite." Det var hundra år sen. Vi slutade med det, för det var en idiotisk uppdelning när den inte spelade roll.

Fast forward 150 år. Året är 2012. Vi delar fortfarande upp människor i grupper helt i onödan. Varför ska jag säga "han" eller "hon" när könet inte spelar någon som helst roll?

Missförstå mig rätt nu. Naturligtvis finns det sammanhang där könet spelar roll. Till exempel kanske man pratar om en människa och vill veta så mycket som möjligt om den, då är könet en intressant bit information som kan inkodas i meningen som "han" eller "hon." I daglig konversation däremot, spelar könet väldigt sällan roll. Därför finns det ett mycket bra pronomen, "hen," som betyder en människa oavsett kön, hudfärg, religiös åskådning eller ålder.

Att avråda ett så harmlöst ord är galenskap, idioti och egoism. Alla samtidigt. Jag förstår inte vissa människors besatthet av att kategorisera andra människor i vardagligt tal. Det finns ingen som helst poäng med det.

– Tills vi ser om vi får några rekommendationer kan den som är osäker säga ”barnet”, säger Renée Hildebrand.