On tuesday last week, geeksphone started to sell smartphones running Firefox OS so… I bought one.

There are two models:

• Keon (1GHz, 521MB RAM, 4GB ROM, 8.9cm screen, HSPA)
• Peak (1.2GHz dualcore, 512MB RAM, 4GB ROM, 10.9cm screen, HSPA)

Those phones are "developer preview", which may sound like "they currently suck so it's not for everybody", but anyway, it's a good thing to see that there is a lot of interest in a more open mobile platform (geeksphone went out of stock just hours after opening the shop).

I received my Peak yesterday:

I had a quick tour and here is my first impression (I may be wrong on some stuff since I used it just for a couple of hours):

• Firefox OS
  • Setup process has only a few steps, which is good, but is long because I had to setup time manually. Considering that the phone was connected to the local WiFi and has a GPS chip I was expecting to only have to selection my region/country (and get time through NTP) or tell the phone to "guess" my current time based on my location (using the GPS location and time). Some UI stuff in that part are a bit awkward too (like the next button that was hidden by the keyboard).
  • E-Mail application can't use email discovery configuration through SRV records in DNS (like Thunderbird, same issue probably), so I had to enter my mail configuration manually…
  • …but it didn't work. Looks like there is a problem to handle STARTTLS command. So I can't read my emails on Firefox OS' mail client.
  • Configuring a GMail/Google Apps account in E-Mail application works just fine.
  • There is CalDAV support in the Calendar application! But here again, no discovery configuration, I entered the configuration manually but I didn't manage to connect successfully (looks like invalid certificate for HTTPS is the problem… and I'm not going to buy one for myself). Again, Google Apps Calendar was configured simply and works.
  • Looks like it's not possible to remove the "offline" (local I assume) calendar from the Calendar application.
  • Contacts application does not support CardDAV… so no contacts for me :-(.
  • In overall Firefox OS does not feel very responsive (while scrolling for instance), a bit less reponsive than my iPhone 3GS for instance (but much more responsive than my iPhone 3G), the keyboard is too slow/imprecise.
  • The styling is very polished in some places and very raw in others.
  • No fucking activation required!!!
  • I took a couple of pictures but their metadata contained a date around 11 years ago.
  • Music player reads mp3 properly, ogg vorbis (but seems to have some tag issues) but doesn't read flac and m4a.
• Geeksphone Peak hardware
  • The plastic looks nice (expect for the buttons) but feels cheap (but a €400 Samsung Galaxy S3 is not much better).
  • Accessories are really cheap.
  • The screen is a bit too "grippy".
  • The screen is not too bright so it's a bit hard to watch in a bright environment.
  • Otherwise the screen is nice (much better than the one on my iPhone 3GS).
  • Only 2GB of ROM is reported instead of 4GB.

So, is it ready for mass market? Clearly not yet, but it looks promising (even if I'm a bit dubious on some choices that have been made).

Next step? Put a SIM card in it ;-).

If you want to have a look at Firefox OS, you can install Firefox OS simulator.

My blog is powered by Jekyll and I display gravatars on comments and for post author. As stated in my previous post, it's a centralized service. Now there is libravatar doing the same but not centralized. I wrote a gravatar liquid filter, now here is the libravatar liquid filter:

require 'libravatar'

module Jekyll
  module LibravatarFilter
    def to_libravatar(input)
      Libravatar.new(:email => input)
    end

    def to_secure_libravatar(input)
      Libravatar.new(:email => input, :https => true)
    end
  end
end

Liquid::Template.register_filter(Jekyll::LibravatarFilter)

It's based on libratar ruby gem that you have to install first:

$ gem install libravatar

• With this input: {{ 'user@example.com' | to_libravatar }}
• The filter will output something like:
  http://avatars.example.com/avatar/8ab058066d75ea5b7e613094a7676d82

See the libravatar filter on github.

You may know gravatar which is a service that allows you to attach a picture/avatar to your email address which then allow any other services (blogs, forum…) to display your avatar as soon as you provide your email address.

Those services lookup a specific URL on gravatar's website to get your avatar if any. This is how my picture is displayed on my github account or on this blog (as well as people commenting).

That's a cool service with a major drawback: it's centralized (like github, twitter, facebook, google…). That mean that I'm not in control of my data (ok, there is little data here) and the day they decide to stop the free service, or sell their email database, or close the company, we will be fucked.

Here enters libravatar. They provide a similar service and in fact their API is based on gravatar's one, but with a major difference: you can host your own avatar service.

They provide an open source server, there is also an other implementation called surrogator. Since the libravatar API is quite simple, there is nearly no need of a server in order to have a basic implementation.

There is a description on how to install a simple libravater service on Puslingblog and I'm going to do something very similar here.

DNS

First let start with the DNS which is the magic part compared to gravatar. The idea is that given an email address, lookup the DNS server of that domain which server is taking in charge of providing the libravatar service.

The method used is similar to email configuration discovery or xmpp configuration, you have to provide an SRV field in your zone configuration:

_avatars._tcp        IN SRV    0 0 80 avatar.example.com.

And if you also provide it over HTTPS:

_avatars-sec._tcp        IN SRV    0 0 443 avatar.example.com.

So here I'm telling that the server avatar.example.com. Libravatar provides a service to check if your DNs is properly configured.

For an email address like foobar@example.com, the avatar will be on an URL like http://avatar.example.com/avatar/bfaa47fff290d85cd956cc303edb6033.

Web server

So here we are serving the avatars as static images in an Apache server. Let start with creating a new vhost in Apache:

$ sudo emacs /etc/apache2/sites-available/avatar

<VirtualHost *:80>
  ServerName avatar.example.com

  ExpiresActive on
  ExpiresByType image/jpeg "access plus 1 week"
  ExpiresDefault "access plus 1 day"

  DocumentRoot /path/to/avatar/root/directory
  ForceType image/jpeg
  Options -Indexes
</VirtualHost>

Here I'm forcing all content delivered on this webserver to have MIME type image/jpeg (since avatars won't have any file extension) and then setting a default TTL to 1 week (the libravatar specify that the TTL must be at least 1 day). Note that with this configuration, if an avatar does not exists, a 404 error will be returned. You can add something like ErrorDocument 404 /path/to/default/picture.jpg if you want to specify a default picture.

Now we need to create the vhost root directory and put images in it. The images must be in a sub-directory called avatar and their name must be the MD5 or SHA256 of the email address (for "foobar@example.com" that's 0d4907cea9d97688aa7a5e722d742f71 for the MD5 and 3bc3ca01dd1d501ca1c22e1c5d7d16feac90b8a3178fb17c710510d8a85e21bf for the SHA256).

$ sudo mkdir -p /path/to/avatar/root/directory/avatar
$ sudo cp /path/to/picture.jpg /path/to/avatar/root/directory/avatar/`echo -n foobar@example.com | md5sum | sed 's/-//'`
$ sudo cp /path/to/picture.jpg /path/to/avatar/root/directory/avatar/`echo -n foobar@example.com | sha256sum | sed 's/-//'`

There is a more automatized command explained on Puslingblog.

Now finish the installation:

$ sudo chown -R www-data:www-data /path/to/avatar/root/directory
$ sudo chmod -R ug=rX /path/to/avatar/root/directory
$ sudo a2ensite avatar
$ sudo service apache2 reload

Of course libravatar provides a service to check that your avatar is set up properly.

You know what's annoying? Non-free WiFi access (in airports, trains, restaurants…).

Usually you try to go on some webpages then you are redirected to some portal where you have to pay outrageous amounts to access the internet.

Quite often those WiFi access let the DNS requests go through so you can try to go on a webpage before being redirected to the portal. So obviously some people had the idea to tunnel their connection through the DNS port (this technique is called IP-over-DNS or DNS tunnelling).

For this to work 2 things are needed: a server on the internet listening on DNS port (53) ready to tunnel your connection, and a client on your computer sending all your IP traffic through port 53 on the server.

One of the most popular software for doing so is iodine. In this post I will explain quickly how to set up a iodine server on a Debian server.

Prerequisites

• a Debian server available on the internet
• a DNS server where you can set your domain names

Installing iodine

As usual on Debian, it's brain-dead easy:

$ sudo apt-get install iodine

Configuring iodine

Iodine configuration is done in file /etc/default/iodined:

1 START_IODINED="true"
2 IODINED_ARGS="10.0.0.1 tunnel.example.com"
3 IODINED_PASSWORD="some password"

• Line 1: tell iodine daemon to start automatically.
• Line 2: tell iodine to use network 10.0.0.0 to do the tunnelling. Enter here a network that you don't already use. The second arguments is the name the iodine client will use to contact the server.
• Line 3: password used to connect to the iodine server (so mostly only you can use your tunnel).

That's all for the server, only need to (re)start iodine.

Configuring the DNS

In your DNS server zone file (for the example.com domain) you need to add something like that:

1 iodine  IN A   12.34.56.78
2 tunnel  IN NS  iodine.example.com.

• Line 1: create an A entry pointing iodine.example.com to the iodine server IP address (the public one on the internet).
• Line 2: create a DNS entry telling that DNS requests for tunnel.example.com are handled by iodine.example.com.

Test

The guys doing iodine provide a test page. Go there and enter tunnel.example.com, you should get a "Well done" message.

So… Well done!

No you have to configure iodine client on your computer/laptop. Iodine client works on Linux/Mac OS X/Windows…

Un ami a décidé d'organiser un voyage en Laponie, une semaine au mois de janvier dans un chalet sans électricité ni eau courante, juste un poêle au bois pour se chauffer. Forcément, j'ai accepté.

Laponie

Quelques trucs à savoir sur la Laponie :

• La Laponie est une région qui s'étend sur la Norvège, la Suède, la Finlande et la Russie.
• Le peuple lapon est aussi appelé Sami (Sámi, Saami).
• La Laponie est principalement située au nord du cercle polaire arctique.
• La température moyenne au mois de janvier vers notre chalet est comprise entre -11 et -19ºC.
• La durée du jour au mois de janvier varie de 0 à 6h.
• L'animal le plus emblématique de la Laponie est le renne.

Préparation

Des points précédents on peut deviner qu'il faut se préparer à 2 choses : le froid et la nuit.

Pour la nuit, c'est assez simple, une lampe frontale fait très bien l'affaire et laisse les mains libres. Pleins de modèles sont disponibles chez Petzl, j'ai réutilisé celle que j'avais acheté pour gravir le mont Fuji.

Pour le froid, il faut plusieurs couches de vêtements, pas trop serrées, pour emprisonner un maximum d'air (l'air étant plus isolant que les fibres textiles). De mon côté j'ai opté pour quelques vêtements en Ullftotté de chez Woolpower. À la base c'est un textile développé pour l'armée suédoise, donc a priori ça doit tenir chaud.

Jour 1

• Levé du soleil : 11h44.
• Couché du soleil : 12h58.
• Température : ≈−7ºC.

Arrivée à l'aéroport vers 13h, direction le loueur de voitures, le supermarché pour acheter des vivres et le chalet.

Arrivée au chalet vers 15h30. Premières étapes :

• faire du feu,
• faire un trou dans la glace du lac (pour récupérer de l'eau),
• déblayer la neige (entre le chalet, les toilettes, le sauna et le lac),
• rentrer du bois dans le chalet et le sauna.

Et enfin manger, aller au sauna et regarder une toute petite aurore boréale.

Jour 2

• Levé du soleil : 11h34.
• Couché du soleil : 13h07.
• Température : ≈−7ºC.

Au programme :

• visite d'une ferme de rennes tenue par des samis (lancé de lasseau, balade en traineaux tiré par des rennes, petites explications sur la vie des samis, chants samis),
• check d'un point de vue pour les aurores,
• apprendre à faire un feu dans la neige en cas de problème,
• re-perçage de la glace du lac mais au bon endroit (avec la lumière du jour c'est plus facile),
• sauna (avec plongeon dans l'eau du lac).

Jour 3

• Levé du soleil : 11h25.
• Couché du soleil : 13h16.

Direction : le nord. On sort de la Finlande pour aller en Norvège jusqu'à Bugøynes pour faire trempette dans l'océan arctique. Coup de chance inouïe, une fois sur place nous tombons sur une très sympathique personne qui nous a gentiment prêté son sauna pour nous réchauffer avant d'aller à l'eau.

Jour 4

• Levé du soleil : 11h18.
• Couché du soleil : 13h24.
• Température : ≈−17ºC.

Au programme :

• balade en raquettes,
• pêche dans le lac,
• barbecue,
• aurore boréale.

Jour 5

• Levé du soleil : 11h11.
• Couché du soleil : 13h31.
• Température : entre −17 et −27ºC.

Au programme :

• chiens de traineau pour les uns,
• motoneige pour les autres,
• luge pour tous.

Bref, de bonnes activités en plein air, air un peu frais tout de même…

Note pour plus tard : la vodka au frais à -25ºC ça va, la bière par contre ça explose.

Jour 6

• Levé du soleil : 11h05.
• Couché du soleil : 13h38.
• Température : entre −15 et −20ºC.

Au programme :

• repos,
• ski de fond,
• repos.

Il semblerait que l'iPhone trouve que par -20ºC il fait trop chaud :

Jour 7

• Levé du soleil : 10h59.
• Couché du soleil : 13h45.

Dernier jour, mais avant de prendre notre avion presque privé (nous représentions 6 des 8 passagers), petit tour par la station de ski.