SHA1 calculation using boost

Here is how to calculate a SHA1 hash using boost.

/*
  sha1 digest function, using boost.
  By Paul Dreik 20121001 http://www.pauldreik.se/
  License: GPLv2 or later, at your option.
*/
#include <fstream>
#include <iostream>
#include <iomanip>
#include <boost/uuid/sha1.hpp>

int main(int argc, char* argv[]) {
  if(argc<2) {
    std::cerr<<"Supply file name as the first argument.\n";
    return -1;
  }
  
  //open the file
  std::ifstream ifs(argv[1],std::ios::binary);
  
  if(!ifs.good()) {
    std::cerr<<"bad file\n";
    return -2;
  }

  boost::uuids::detail::sha1 sha1;
  unsigned int hash[5];
  char buf[1024];
  while(ifs.good()) {
    ifs.read(buf,sizeof(buf));
    sha1.process_bytes(buf,ifs.gcount());
  }
  if(!ifs.eof()) {
    std::cerr<<"not at eof\n";
    return -3;
  }
  ifs.close();
  sha1.get_digest(hash);
  std::cout<<std::hex<<std::setfill('0')<<std::setw(sizeof(int)*2);
  for(std::size_t i=0; i<sizeof(hash)/sizeof(hash[0]); ++i) {
    std::cout<<hash[i];
  }
  std::cout<<"  "<<argv[1]<<std::endl;
  return 0;
}

Statistik om PIN-koder

Den här artikeln var intressant - den handlar om vilka pinkoder som är vanliga och ovanliga.  Den vanligaste koden är 1234 och den ovanligaste 8068. Intressant hur kodrymden visualiseras och hur man väljer.

http://www.datagenetics.com/blog/september32012/index.html

Bandwidth limit ssh

For all you who are interested in rate limiting ssh, to not consume too much bandwidth, here is a suggestion:

Use trickle! (apt-get install trickle for debian/ubuntu users)

instead of

ssh you@example.com

you use

trickle -u 123 -d 456 ssh you@example.com

where u is the upload limit in kbytes/s and d is the download limit in kbytes/s.

Very handy. I use it to rate limit file synchronization with unison. I have a ssh.sh script with

#!/bin/sh
trickle -u 20 -d 40 ssh "$@"

in it, and sshcmd=/path/to/ssh.sh in my unison profile.

Good luck!

Utveckling med OpenCL

Efter att länge ha varit nyfiken, har jag nu tagit steget och börjat använda OpenCL. För dig som inte vet vad det är, är det ett standardiserat sätt att kunna använda en grafikprocessor till generell beräkning, inte bara grafik. Den råa prestandan i ett modernt grafikkort är många gånger större än för en normal processor, men har helt andra egenskaper och kan inte alltid utnyttjas för alla typer av problem.

Jag tog en existerande algoritm jag jobbat mycket med och implementerade delar av den. På min medelmåttiga laptop, med teoretisk prestanda 155 GFLOPS lyckades jag genomföra beräkningarna en faktor 30 snabbare än på cpu:n! Detta helt utan att försöka optimera koden. Ett grafikkort för stationära datorer i 5000 kr-klassen når ca 3000 GFLOPS. Med ett sådant kort skulle alltså prestanda kunna öka till en faktor 600 gånger snabbare än cpu, för mitt problem. Tack alla ni som spelar datorspel och finansierar denna fantastiska utveckling!

Det tog ett tag att läsa igenom dokumentationen och förstå hur det är tänkt att fungera. Jag rekommenderar att läsa många olika tutorials innan man börjar, eftersom det är ganska annorlunda mot "vanlig" programmering och varje författare förklarar på olika sätt.

En liten disclaimer:
för att nå höga prestanda behöver man göra avkall på beräkningsprecisionen, samt kunna dela upp sitt problem i parallella delar. Därutöver tillkommer fördröjning när problemet ska flyttas till grafikkortsminnet, och kerneln kompileras. Och så behöver man installera ickefri programvara...

Best paper award

I am delighted to inform you that your paper, detailed above, has been awarded the joint winner of 2011 SAGE Best Paper Award by the Editor and Editorial Board of the Journal of Rail and Rapid Transit.

Detta mail fick jag för ett tag sedan. Jättekul! Jag har för kunds räkning utvecklat ett system för igenkänning av spårdefekter.
Efter att ha beskrivit detta i en artikel tillsammans med andra har det nu tilldelats pris som bästa artikel!

Läs sammanfattning här:
http://pif.sagepub.com/content/225/1/1.abstract

Direktlänk till artikeln:
http://pif.sagepub.com/cgi/reprint/225/1/1

Läsvärt om SSD

Jag tillhör en av dom som bytt till flashbaserad lagring (SSD) i min dator och kommer aldrig att byta tillbaka - prestandavinsten (både den verkliga och den upplevda) är helt enkelt så väldigt stor. För SSD är det mycket prat om TRIM och prestanda. Samt de eviga firmwareproblemen, som även jag drabbats av.
Nu snubblade jag över en mycket intressant artikel som går avsevärt djupare än vanligt och förklarar de största problemen och deras lösningar. Det gav mig en större förståelse för hur knepigt det måste vara att få till en välfungerande SSD med höga prestanda. Det finns mycket skräp på nätet, men då och då hittar man verkliga guldkorn!

Backup med hjälp av btrfs snapshots

En stark fördel med btrfs är möjligheten att på ett mycket effektivt sätt göra backup med hjälp av snapshots. De flesta oroar sig för dataförlust på grund av hårdvarufel men det är faktiskt (rent statistiskt sett) viktigare att skydda sig mot användarmisstag. Och här är btrfs snapshot ett mycket bra verktyg!

Det går till så att en kopia av filsystemet sparas, på ett sätt så att originalet och kopian i bakgrunden använder samma utrymme, ända till dess att en fil ändras. På detta sätt tar kopian inte särskilt stor plats. På btrfs går detta sekundsnabbt, och man har då en kopia att gå tillbaka till.
Jag har nu lagt upp ett cronjobb som åstadkommer just detta.

Min filstruktur har de subvolymer som används i katalogen /btrfs-stuff/subvolumes/
För att detta ska fungera som avsett har jag följande i /etc/fstab:

$tail /etc/fstab
/dev/mapper/sda2_crypt /root/btrfs-roots/sda2_crypt btrfs noauto,noatime,compress,subvolid=0 0 0
/dev/mapper/sdb2_crypt /root/btrfs-roots/sdb2_crypt btrfs noauto,noatime,compress,subvolid=0 0 0

och sen cron-jobbet:

$cat /etc/cron.daily/btrfs-snapshots
#!/bin/sh
#Av Paul Dreik 20120506
set -e
for t in /root/btrfs-roots/* ; do
    if [ ! -d "$t/btrfs-stuff" ] ; then
        mount "$t"
    fi
    /root/btrfs-snapshot.sh "$t/btrfs-stuff"
    umount "$t"
done

 och så har vi filen som gör själva snapshoten:

$cat /root/btrfs-snapshot.sh
#!/bin/sh
#gör snapshot. Scriptet antar att du har en struktur
# /some/path/subvolumes/
# /some/path/snapshots/
# där du anger /some/path som argument till scriptet.
#
# Scriptet gör sedan ett snapshot av varje subvolym och placerar det i
# snapshots.

#Paul Dreik 20120506

#bail out on error
set -e

#assume a directory structure where the subvolumes and snapshots are
#in subdirs of a specific directory. This directory should be given as
#the first argument to the script.
if [ $# -ne 1 ]; then
    echo "please give the btrfs root directory as the first argument."
    exit 1
fi
if [ ! -d "$1" ] ; then
    echo "directory $1 does not exist."
    exit 1
fi
cd "$1"

#make sure subvolumes exist, as well as snapshots.
for d in subvolumes snapshots ; do
    if [ ! -d "$d" ] ; then
    echo "directory $d does not exist"
    exit 1
    fi
done

for sv in subvolumes/* ; do
    echo "looking at subvolume $sv"
    #make sure the snapshot directory exists
    svname=$(basename $sv)
    mkdir -p "snapshots/$svname"
    #now make the snapshot
    datestamp=$(date --rfc-3339=s)
    btrfs subvolume snapshot -r "$sv" "snapshots/$svname/$datestamp"
done

echo all ok

Detta åstadkommer nu ett snapshot av varje volym, en gång per dygn. För att komma åt en gammal version är det bara att montera det snapshottet. Fungerar otroligt bra!

En liten fotnot:
backup måste naturligtvis ske "ordentligt" också, dvs på en annan fysisk plats. Att lagra gamla versioner lokalt är dock ett väldigt bra sätt att skydda sig mot att oavsiktligt råka ta bort eller ändra filer. Bra för oss med barn som "hjälper till" ibland....

kompression i btrfs

Mina experiment med btrfs fortsätter. Har nu slagit på kompression, vilket fungerar fantastiskt bra. Tänk att inte behöva hålla på att komprimera filer för att inte slösa på utrymmet! Eftersom jag använder ssd resp en högvarvig SATA-disk för att få höga prestanda är det viktigt att hålla ner storleken om det går.

Att slå på kompression är så enkelt som att lägga till compress som option i fstab, dvs att den btrfsrelaterade raden i /etc/fstab är
UUID=xxxx / btrfs noatime,compress 0 0
Jag är inte så modig att jag slår på lzo, utan jag håller mig till gzip än så länge...

btrfs som rotfilsystem på Debian Wheezy

Nu har turen kommit till att använda btrfs som rotfilsystem på en Debian Wheezy-installation. Efter att installationen blivit klar efter en evighet (läs förra inlägget, om prestandaproblem med fsync) stannade booten på att fsck fallerade. Detta är något missvisande och verkar ha att göra med att "reparation/kontroll-verktyget" för btrfs inte är klart. I väntan på att det är klart returnerar det att allt är ok, om jag förstått saken rätt.
Workaround: ta bort filsystemkontrollen från fstab, dvs ändra sista kolumnen till noll för btrfsvolymerna. Detaljer finns här.

Nu håller jag på att sätta upp subvolymer och snapshots, så att jag får lite ordning och reda. Time machine-funktionalitet på filsystemnivå är en helt annan femma än rsync+hårdlänkar som "alla" använder för backup!

experiment med btrfs

Nu har jag använt btrfs på en partition för backup - funkar perfekt. Det jag framförallt vill åt är checksummekontrollen, dvs att man vet att data är korrekta.

Glad över hur lätt det var att komma igång med btrfs satte jag igång en nyinstallation av debian, med btrfs lagt ovanpå en krypterad partition. Vilken pina! Det visar sig att btrfs i sin nuvarande version är riktigt kass när det gäller fsync(), vilket installationsprogrammet för Debian gör väldigt, väldigt ofta. (Läs mer här, debian bugg #635993). Det verkar tack och lov finnas workarounds när man väl installerat systemet, men just nu har jag tröttnat på att höra hårddisken knattra sedan två timmar för något som brukar gå på under en halvtimme.

Hur man gör rep

kul film som visar vissa moment när man väver rep.
http://www.youtube.com/watch?v=UyDHBNix6hA

Jag vill jobba i en grupp med olika fackkunskaper

Jag såg den här videon om en ingenjör som kom med ett förslag på operationsmetod. Jag vill också jobba i en grupp vars medlemmar har olika kunskap och perspektiv!
http://www.ted.com/talks/tal_golesworthy_how_i_repaired_my_own_heart.html

Jämförelse mellan Unison, Dropbox och Sparkleshare

Jag har länge använt unison för att synkronisera filer mellan datorer. Detta är väldigt effektivt och ett väl genomarbetat verktyg. Nackdelen är att det kräver att man tänker sig för innan man jobbar med filer, så att man inte råkar ut för att man råkar ändra en fil på två ställen och att dessa måste slås samman manuellt. När man vant sig vid arbetsflödet är det inte ett stort problem eftersom man synkar efter att man ändrat något, men när man delar filer med andra som inte är lika intresserade/vana så är det lätt hänt att det blir trassel. I värsta fall leder detta till att systemet inte används, vilket gör att filer råkar komma bort eller att man glömt vilken dator de ligger på, precis det som man vill undvika genom att synka filer.
Ett sätt att lösa det på är att använda ett system som fungerar som unison, fast synkroniserar sig själv automatiskt i bakgrunden. Detta gör att man inte manuellt behöver bry sig om det. Ett sådant system är dropbox, som blivit väldigt populärt.

Det finns dock en nackdel med dropbox - det är inte ett fritt program, det är storleksbegränsat om man inte betalar och framförallt är dina filer åtkomliga för dropbox själva. Det senare betyder att ett säkerhetshål kan göra att filerna blir allmänt åtkomliga eller att en myndighet kan begära ut dom. Vem har att göra med vad dina filer innehåller? Bara du, såklart.

Jag håller på att pröva ett fritt alternativ som heter sparkleshare. Det fungerar ungefär som dropbox, även om det inte än verkar finnas något sätt att komma åt filer via webgränssnitt. För mig är det strunt samma eftersom man kan använda sin egen server att lagra data på. Det finns därför ingen godtycklig storleksbegränsning, ingen yttre insyn och ingen tredje part att förlita sig på.
Hitills är det lovande, enda nackdelen jag ser är att det på klienten går åt dubbelt så mycket diskutrymmet som filerna upptar, dvs om man har 1 GB filer går det åt 2 GB utrymme på disken. På servern går det åt 1 GB. (Detta är en förenkling, eftersom git används i botten kommer komprimering, deduplicering och filhistorik in i bilden. För mitt användningsområde, att arkivera foton, är det sant.)

Sammanställning

• Unison och sparkleshare är fria, dropbox är det inte.
• Unison och sparkleshare har ingen storleksbegränsning.
• Dropbox har webgränssnitt för att komma åt filer
• Unison kräver mycket lite utrymme utöver själva filerna, dropbox kräver en del (vet ej exakt hur det fungerar), sparkleshare ungefär det dubbla (beroende på).
• sparkleshare lagrar äldre versioner av filer, dropbox också men upp till en viss gräns om man inte betalar. Unison har ingen versionshantering.
• unisons synkronisering initieras manuellt, på gott och ont.
• sparkleshare och unison låter dig använda egen server.
• sparkleshare är mycket resistent mot datakorruption tack vare att det använder git
• alla tre alternativ finns för de vanligaste operativsystemen.

Jag ska använda sparkleshare ett tag och se hur det fungerar, så får jag återkomma.

Intressant föredrag om btrfs

Det "nya heta" vad gäller filsystem är btrfs. Chris Mason från Oracle, huvudutvecklaren, håller här ett väldigt intressant föredrag som berättar lite om vad filsystemet kan och hur det fungerar. Det är inte en reklamfilm som maler på hur förträffligt det är utan sakligt och visar på intressanta skillnader jämfört med arbetshästen ext4 och xfs. Speciellt animationerna för diskaccess för de olika filsystemen är väldigt intressanta.

Efter att tidigare ha insett hur allt mer sannolikt det är att råka ut för "bit rot" så väntar jag på att börja använda ett filsystem med redundans och checksummor. Suns zfs som verkar riktigt bra fungerar inte i linux pga licensskäl (nej, jag vill inte köra via fuse så det räknas inte...).
Utvecklingen av btrfs har ssd i åtanke och det är väldigt viktigt prestandamässigt.

Nu väntar jag på att "de sista" buggarna åtgärdas så att jag slipper vara försökskanin. Min nuvarande setup med det förträffliga lvm kommer då att ryka.