Petter Reinholdtsen

In the Debian popularity-contest numbers, the adobe-flashplugin package the second most popular used package that is missing in Debian. The sixth most popular is flashplayer-mozilla. This is a clear indication that working flash is important for Debian users. Around 10 percent of the users submitting data to popcon.debian.org have this package installed.

In the report written by Lars Risan in August 2008 («Skolelinux i bruk – Rapport for Hurum kommune, Universitetet i Agder og stiftelsen SLX Debian Labs»), one of the most important problems schools experienced with Debian Edu/Skolelinux was the lack of working Flash. A lot of educational web sites require Flash to work, and lacking working Flash support in the web browser and the problems with installing it was perceived as a good reason to stay with Windows.

I once saw a funny and sad comment in a web forum, where Linux was said to be the retarded cousin that did not really understand everything you told him but could work fairly well. This was a comment regarding the problems Linux have with proprietary formats and non-standard web pages, and is sad because it exposes a fairly common understanding of whose fault it is if web pages that only work in for example Internet Explorer 6 fail to work on Firefox, and funny because it explain very well how annoying it is for users when Linux distributions do not work with the documents they receive or the web pages they want to visit.

This is part of the reason why I believe it is important for Debian and Debian Edu to have a well working Flash implementation in the distribution, to get at least popular sites as Youtube and Google Video to working out of the box. For Squeeze, Debian have the chance to include the latest version of Gnash that will make this happen, as the new release 0.8.8 was published a few weeks ago and is resting in unstable. The new version work with more sites that version 0.8.7. The Gnash maintainers have asked for a freeze exception, but the release team have not had time to reply to it yet. I hope they agree with me that Flash is important for the Debian desktop users, and thus accept the new package into Squeeze.

This evening I made my first Perl GUI application. The last few days I have worked on a Perl module for controlling my recently aquired Spykee robots, and the module is now getting complete enought that it is possible to use it to control the robot driving at least. It was now time to figure out how to use it to create some GUI to allow me to drive the robot around. I picked PerlQt as I have had positive experiences with the Qt API before, and spent a few minutes browsing the web for examples. Using Qt Designer seemed like a short cut, so I ended up writing the perl GUI using Qt Designer and compiling it into a perl program using the puic program from libqt-perl. Nothing fancy yet, but it got buttons to connect and drive around.

The perl module I have written provide a object oriented API for controlling the robot. Here is an small example on how to use it:

use Spykee;
Spykee::discover(sub {$robot{$_[0]} = $_[1]});
my $host = (keys %robot)[0];
my $spykee = Spykee->new();
$spykee->contact($host, "admin", "admin");
$spykee->left();
sleep 2;
$spykee->right();
sleep 2;
$spykee->forward();
sleep 2;
$spykee->back();
sleep 2;
$spykee->stop();

Thanks to the release of the source of the robot firmware, I could peek into the implementation at the other end to figure out how to implement the protocol used by the robot. I've implemented several of the commands the robot understand, but is still missing the camera support to make it possible to control the robot from remote. First I want to implement support for uploading new firmware and configuring the wireless network, to make it possible to bootstrap a Spykee robot without the producers Windows and MacOSX software (I only have Linux, so I had to ask a friend to come over to get the robot testing going. :).

Will release the source to the public soon, but need to figure out where to make it available first. I will add a link to the NUUG wiki for those that want to check back later to find it.

Ble tipset i dag om at et forslag om å stoppe forsøkene med elektronisk stemmegiving utenfor valglokaler er til behandling i Stortinget. Forslaget er fremmet av Erna Solberg, Michael Tetzschner og Trond Helleland.

Håper det får flertall.

Just got an email from Tobias Gruetzmacher as a followup on my previous post about sshfs. He reported another problem with sshfs. It fail to handle hard links properly. A simple way to spot this is to look at the . and .. entries in the directory tree. These should have a link count >1, but on sshfs the count is 1. I just tested to see what happen when trying to hardlink, and this fail as well:

% ln foo bar
ln: creating hard link `bar' => `foo': Function not implemented
%

I have not yet found time to implement a test for this in my file system test code, but believe having working hard links is useful to avoid surprised unix programs. Not as useful as working file locking and symlinks, which are required to get a working desktop, but useful nevertheless. :)

The latest version of the file system test code is available via git from http://github.com/gebi/fs-test

Jeg skrev for et halvt år siden hvordan samfunnet kaster bort ressurser på sikkerhetstiltak som ikke fungerer. Kom nettopp over en historie fra en pilot fra USA som kommenterer det samme. Jeg mistenker det kun er uvitenhet og autoritetstro som gjør at så få protesterer. Har veldig sans for piloten omtalt i Aftenposten 2007-10-23, og skulle ønske flere rettet oppmerksomhet mot problemet. Det gir ikke meg trygghetsfølelse på flyplassene når jeg ser at flyplassadministrasjonen kaster bort folk, penger og tid på tull i stedet for ting som bidrar til reell økning av sikkerheten. Det forteller meg jo at vurderingsevnen til de som burde bidra til økt sikkerhet er svært sviktende, noe som ikke taler godt for de andre tiltakene.

Mon tro hva som skjer hvis det fantes en enkel brosjyre å skrive ut fra Internet som forklarte hva som er galt med sikkerhetsopplegget på flyplassene, og folk skrev ut og la en bunke på flyplassene når de passerte. Kanskje det ville fått flere til å få øynene opp for problemet.

Personlig synes jeg flyopplevelsen er blitt så avskyelig at jeg forsøker å klare meg med tog, bil og båt for å slippe ubehaget. Det er dog noe vanskelig i det langstrakte Norge og for å kunne besøke de delene av verden jeg ønsker å nå. Mistenker at flere har det slik, og at dette går ut over inntjeningen til flyselskapene. Det er antagelig en god ting sett fra et miljøperspektiv, men det er en annen sak.

Denne høsten skal endelig alle Osloskolene få mulighet til å bruke Skolelinux. Ny IT-løsning har vært rullet ut i noen måneder nå, og så vidt jeg fikk vite før sommeren skulle alle skoler ha nytt opplegg på plass før oppstart nå i høst. På alle skolene skal en kunne velge ved installasjon om en skal ha Windows eller Skolelinux på maskinene, og en kan i tillegg PXE-boote maskinene over nett som tynne klienter eller diskløse arbeidsstasjoner. Jeg er spent på hvor mange skoler som velger å ta i bruk Skolelinux, og gleder meg til å se hvordan dette utvikler seg. Løsningen leveres av Logica med Skolelinux Drift AS som underleverandør, og jeg har vært involvert i utviklingen av løsningen via Skolelinux Drift AS siden prosjektet starter. Jeg synes det er fantastisk at Skolelinux er kommet så langt siden vi startet i 2001 at alle elevene i Osloskolene nå skal få mulighet til å bruke løsningen. Jeg håper de vil sette pris på alle de fantastiske brukerprogrammene som er tilgjengelig i Skolelinux.

My file system sematics program presented a few days ago is very useful to verify that a file system can work as a unix home directory,and today I had to extend it a bit. I'm looking into alternatives for home directory access here at the University of Oslo, and one of the options is sshfs. My friend Finn-Arne mentioned a while back that they had used sshfs with Debian Edu, but stopped because of problems. I asked today what the problems where, and he mentioned that sshfs failed to handle umask properly. Trying to detect the problem I wrote this addition to my fs testing script:

mode_t touch_get_mode(const char *name, mode_t mode) {
  mode_t retval = 0;
  int fd = open(name, O_RDWR|O_CREAT|O_LARGEFILE, mode);
  if (-1 != fd) {
    unlink(name);
    struct stat statbuf;
    if (-1 != fstat(fd, &statbuf)) {
      retval = statbuf.st_mode & 0x1ff;
    }
    close(fd);
  }
  return retval;
}

/* Try to detect problem discovered using sshfs */
int test_umask(void) {
  printf("info: testing umask effect on file creation\n");

  mode_t orig_umask = umask(000);
  mode_t newmode;
  if (0666 != (newmode = touch_get_mode("foobar", 0666))) {
    printf("  error: Wrong file mode %o when creating using mode 666 and umask 000\n",
           newmode);
  }
  umask(007);
  if (0660 != (newmode = touch_get_mode("foobar", 0666))) {
    printf("  error: Wrong file mode %o when creating using mode 666 and umask 007\n",
           newmode);
  }

  umask (orig_umask);
  return 0;
}

int main(int argc, char **argv) {
  [...]
  test_umask();
  return 0;
}

Sure enough. On NFS to a netapp, I get this result:

Testing POSIX/Unix sematics on file system
info: testing symlink creation
info: testing subdirectory creation
info: testing fcntl locking
  Read-locking 1 byte from 1073741824
  Read-locking 510 byte from 1073741826
  Unlocking 1 byte from 1073741824
  Write-locking 1 byte from 1073741824
  Write-locking 510 byte from 1073741826
  Unlocking 2 byte from 1073741824
info: testing umask effect on file creation

When mounting the same directory using sshfs, I get this result:

Testing POSIX/Unix sematics on file system
info: testing symlink creation
info: testing subdirectory creation
info: testing fcntl locking
  Read-locking 1 byte from 1073741824
  Read-locking 510 byte from 1073741826
  Unlocking 1 byte from 1073741824
  Write-locking 1 byte from 1073741824
  Write-locking 510 byte from 1073741826
  Unlocking 2 byte from 1073741824
info: testing umask effect on file creation
  error: Wrong file mode 644 when creating using mode 666 and umask 000
  error: Wrong file mode 640 when creating using mode 666 and umask 007

So, I can conclude that sshfs is better than smb to a Netapp or a Windows server, but not good enough to be used as a home directory.

Update 2010-08-26: Reported the issue in BTS report #594498

Update 2010-08-27: Michael Gebetsroither report that he found the script so useful that he created a GIT repository and stored it in http://github.com/gebi/fs-test.

I Norge pågår en prosess for å innføre elektronisk stemmegiving ved kommune- og stortingsvalg. Dette skal introduseres i 2011. Det er all grunn til å tro at valg i Norge ikke vil være til å stole på hvis dette blir gjennomført. Da det hele var oppe til høring i 2006 forfattet jeg en høringsuttalelse fra NUUG (og EFN som hengte seg på) som skisserte hvilke punkter som må oppfylles for at en skal kunne stole på et valg, og elektronisk stemmegiving mangler flere av disse. Elektronisk stemmegiving er for alle praktiske formål å putte ens stemme i en sort boks under andres kontroll, og satse på at de som har kontroll med boksen er til å stole på - uten at en har mulighet til å verifisere dette selv. Det er ikke slik en gjennomfører demokratiske valg.

Da problemet er fundamentalt med hvordan elektronisk stemmegiving må fungere for at også ikke-krypografer skal kunne delta, har det vært mange rapporter om hvordan elektronisk stemmegiving har sviktet i land etter land. En liten samling referanser finnes på NUUGs wiki. Den siste er fra India, der valgkomisjonen har valgt å pusse politiet på en forsker som har dokumentert svakheter i valgsystemet.

Her i Norge har en valgt en annen tilnærming, der en forsøker seg med teknobabbel for å få befolkningen til å tro at dette skal bli sikkert. Husk, elektronisk stemmegiving underminerer de demokratiske valgene i Norge, og bør ikke innføres.

Den offentlige diskusjonen blir litt vanskelig av at media har valgt å kalle dette "evalg", som kan sies å både gjelde elektronisk opptelling av valget som Norge har gjort siden 60-tallet og som er en svært god ide, og elektronisk opptelling som er en svært dårlig ide. Diskusjonen gir ikke mening hvis en skal diskutere om en er for eller mot "evalg", og jeg forsøker derfor å være klar på at jeg snakker om elektronisk stemmegiving og unngå begrepet "evalg".

I dag fikk jeg endelig tittet litt på mine nyinnkjøpte roboter, og har brukt noen timer til å google etter interessante referanser og aktuell kildekode for bruk på Linux. Det mest lovende så langt er ispykee, som har en BSD-lisensiert linux-daemon som står som mellomledd mellom roboter på lokalnettet og en sentral tjeneste der en iPhone kan koble seg opp for å fjernstyre roboten. Linux-daemonen implementerer deler av protokollen som roboten forstår. Etter å ha knotet litt med å oppnå kontakt med roboten (den oppretter et eget ad-hoc wifi-nett, så jeg måtte gå av mitt vanlige nett for å få kontakt), og kommet frem til at den lytter på IP-port 9000 og 9001, gikk jeg i gang med å finne ut hvordan jeg kunne snakke med roboten vha. disse portene. Robotbiten av protokollen er publisert av produsenten med GPL-lisens, slik at det er mulig å se hvordan protokollen fungerer. Det finnes en java-klient for Android som så ganske snasen ut, men fant ingen kildekode for denne. Derimot hadde iphone-løsningen kildekode, så jeg tok utgangspunkt i den.

Daemonen ville i utgangspunktet forsøke å kontakte den sentrale tjenesten som iphone-programmet kobler seg til. Jeg skrev dette om til i stedet å sette opp en nettverkstjeneste på min lokale maskin, som jeg kan koble meg opp til med telnet og gi kommandoer til roboten (act, forward, right, left, etc). Det involverte i praksis å bytte ut socket()/connect() med socket()/bind()/listen()/accept() for å gjøre klienten om til en tjener.

Mens jeg har forsøkt å få roboten til å bevege seg har min samboer skrudd sammen resten av roboten for å få montert kamera og plastpynten (armer, plastfiber for lys). Nå er det hele montert, og roboten er klar til bruk. Må få flyttet den over til mitt vanlige trådløsnett før det blir praktisk, men de bitene av protokollen er ikke implementert i ispykee-daemonen, så der må jeg enten få tak i en mac eller en windows-maskin, eller implementere det selv.

Vi var tre som kjøpte slike roboter, og vi har blitt enige om å samle notater og referanser på NUUGs wiki. Ta en titt der hvis du er nysgjerrig.

Jeg kjøpte nettopp to Spykee-roboter, for test og leking. Kjøpte to da det var så billige, og gir meg mulighet til å eksperimentere uten å være veldig redd for å ødelegge alt ved å bytte ut firmware og slikt. Oppdaget at lekebutikken på Bryn senter hadde en liten stabel på lager som de ikke hadde klart å selge ut etter fjorårets juleinnkjøp, og var villig til å selge for en femtedel av vanlig pris. Jeg, Ronny og Jarle har skaffet oss restbeholdningen, og det blir morsomt å se hva vi får ut av dette.

Roboten har belter styrt av to motorer, kamera, høytaler, mikrofon og wifi-tilkobling. Det hele styrt av en GPL-lisensiert databoks som jeg mistenker kjører linux. Firmware-kildekoden ble visst publisert i mai. Eneste utfordringen er at kontroller-programvaren kun finnes til Windows, men det må en kunne jobbe seg rundt når vi har kildekoden til firmwaren. :)

• Wikipedia-oppføring
• Nedlasting av firmware-kilden
• prosjektwiki hos NUUG