Nexus 10: good stuff and disappointments

Laisser un commentaire

After a few days of use, I can say that the Nexus 10 is quite a nice device. I was a little bit disappointed that:

  • I struggled so much to login the first time using my Google account (mandatory to use the tablet). After many attempts, I could login using the browser interface (and not the native interface)
  • During these attempts, I tried to change the keyboard layout, and I found myself stuck in the keyboard configuration because the button 「back」is not present at this stage (what a stupid bug). I had to reboot to try again.
  • Transferring files using MTP (official way using USB) or FTP (limited by the wi-fi bandwidth) is super slow. Using ADB gave a descent 5Mo/s, but come on, using a debugging tool for such a thing is a shame
  • Charging the battery takes forever if you are using the device (I even wonder if it is charging at all).
  • The autonomy is not impressive
  • No cover is present in the package (my EEE-PC had one for a smaller price)
  • I had a complete freeze after starting Chrome once (I barely use it), and I am not the only one
  • These random reboots, grrrr (lost some work)
  • Sometimes, the automatic time sync get wrong by exactly 10 minutes, and the only solution is to disable it
  • Some apps look really ugly on a tablet

Now the good points:

  • Android 4 is really nice to use, not perfect, but really nice
  • Always very responsive, it doesn’t feel like a computer or a phone but like a physical object. It always reacts immediately. That is so great not to have to wait (well, excepted for network comm). On my (fast) PC, if I start Kate, I have to wait a few seconds (wait for a text-editor to start!?). On my Android phone, switching from an app to another is sometimes slow because of the lack of memory.
  • Even Firefox is fast (on my phone its start-up is slow)
  • Does not come with crap like Facebook or trial apps you will never use
  • The screen looks sooo great
  • Voice search is fun (even if it doesn’t always work well)
  • Using voice recognition (not) to type is also fun

I was a little bit sceptic at first, but I may become one of those who use their computer once in a while. Well, I will still need it to edit my Anki packets, type long emails, edit Openstreetmap, order and edit my photo, write code and things like that, but I have to admit that for the rest (browsing and reading, listening to music,  endless watching pointless streaming video) the concept is fantastic (thanks Steve).

Cygwin, xorg et clavier bépo

Laisser un commentaire

Sous Windows, on peut demander à xorg de supporter les claviers français et bépo en le démarrant comme ceci:

/usr/bin/startxwin -- -xkblayout fr -xkbmodel pc105 -xkbvariant "fr,bepo"

Par contre, l’option -xkboptions grp:alt_shift_toggle » ne m’a pas permise de basculer de l’un à l’autre, alors j’ai créé les alias suivants:

alias bepo='setxkbmap -layout "fr" -variant bepo'
alias fr='setxkbmap -layout "fr" -variant oss'

 

 

Golang, Openstreetmap, threads

Laisser un commentaire

In my previous attempt of parsing Openstreetmap data, I found parsing XML data slow. Fortunately I realized that the data was also available in Google Prococol Buffer format, and

  • it’s 30-40% smaller than bzip2 XML (and you know, bzip2 requires a fair amount of CPU power)
  • it’s much faster to parse: with Osmosis, reading a PBF file on my quad-core took 14 seconds, and reading the XML.bzip2 with the help of lbunzip2 (multi-thread decompressor) it took 1mn50s. Ouch!

There is a Go library to handle Protocol Buffers, so I tried to write a PBF reader in this language and could see how efficient it would be. My program worked like this:

  • the main thread would read blocks from the file and pass them to thread workers using a channel
  • each worker (a goroutine) would decompress the block, unmarshall the data and process it
  • when there would not be any block left to process, the results of the workers would be merged into a single image

So what kind of performance did I get? I get the best result with a number of workers equal to the number of cores + 1 (so 5 workers): about 28 seconds. I cannot compare this result with Osmosis (not all the cases are handled), but it’s quite acceptable.

I find Go a nice language to use, and it compiles very very quickly. I struggled a little bit with some points, and everything is not clear yet for me also. It feels strange not to program in a OO-way. And I can’t be sure if I have to trigger tons of goroutines or use a pool of workers, if I should pass callback functions or channels.

That’s also a pity that the tremendous performance is not there yet. It’s supposed to be «close to the metal», «a language for system programming», but for the moment (after 3 years) it is not a fast as Java.

Hébergement e-mail associatif: Sud-ouest.org

Laisser un commentaire

Mise-à-jour: l’association est plus ou moins en sommeil. Les inscriptions sont fermées.

Billet d’origine: « Si le service est gratuit, c’est que vous êtes le produit ». Je cherchais une alternative à Gmail car je n’aime pas:

  • qu’on fasse du ciblage à partir de mes données
  • être pieds et poings liés face à d’un fournisseur (quelque soit la qualité de son service), qui pour une raison ou une autre peut couper les vannes

Mon hébergeur historique, Free, a longtemps eu le défaut honteux de ne pas proposer de communications chiffrées avec ses serveurs (bref, si quelqu’un écoutait le tuyau, il pouvait voir le contenu des communications).

Il existe une alternative: l’hébergement d’e-mail associatif, comme par exemple chez Sud-ouest.org. Pour une modique somme (un prix libre en fait), cette association héberge en toute confidentialité vos courriers.

Attention, leur but n’est pas de stocker tous vos e-mails depuis la nuit des temps (comme sur gmail): vous devez déclarer au préalable la taille de votre boîte mail. J’ai configuré mon lecteur de mail (en l’occurrence Thunderbird) pour laisser sur le serveur les courriers des jours précédents, comme ça je peux consulter ceux qui m’intéressent depuis mon téléphone ou le webmail.

Sud-ouest.org permet d’héberger les mails de son nom de domaine, ce qui permet de changer de fournisseur en gardant son adresse mail. On a  aussi accès aux fonctionnalités qu’on peut attendre d’un hébergeur: pop3, imap et smtp chiffrés, anti-spam, webmail. Et pour ma part, ça marche très bien depuis des mois.

Go XML sax-like parsing is slow

4 réponses

I wanted to write a Openstreetmap XML processor in Go language, hoping that I would get a performance boost from my Python implementation. And it ended being slower. Python is using Expat (written in C) and maybe the Go module «encoding/xml» is not the state of the art of optimization.

In wrote simple programs handling the event «start element». In 10 seconds, I could parse the following amount of XML data (Athlon II X4 620):

  • PyPy: did not run because of a bug (no progressive parsing)
  • Go: 70Mo
  • Python 2.7: 210Mo
  • Python 3.2: 215Mo
  • Java 7: 460Mo
  • C++ / libxml: 675Mo

I tried to use Expat or Libxml in Go, but for the moment it is just too complicated. In Go code, It’s easy to call C functions located in shared libraries, but if you need to pass callback functions written in Go to a library written in C, you will have to do dirty things (create wrappers in a Go module having C code).

That’s a pity because the Go compiler automatically generates C wrappers for your exported Go functions, but you can not get an raw pointer to these wrappers (this way I would have been able to pass my callbacks to LibXML or Expat)… See you later, Go.

Berlin, Paris, Tokyo, and their respective size

Laisser un commentaire

I asked myself what were the respective size of Berlin, Paris and Tokyo inside of the Ringbahn (S41/S42), the Yamanote and the boulevards des Maréchaux (that are between 33 et 37km long), so I know which one is the longest to visit by feet.This image was created using the pifomètre method (rough approximation). I have made screen-shots on Openstreetmap.org, and I have resized them to the same scale.

By selecting the inner zones of each city, I get the following values:

  • Paris: 646 000 pixels
  • Berlin: 638 000 pixels
  • Tokyo: 463 000 pixels

Obviously, the comparison is futile. Tokyo is much wider than the sole Yamanote inner side and is much more dense than Berlin.

Berlin, Paris, Tokyo, et leur taille

Laisser un commentaire
Des clichés se sont glissés dans cette image, sauras-tu les retrouver?

Je me demandais quelles étaient les tailles respectives de Berlin, Paris et Tokyo à l’intérieur du Ringbahn (S41/S42), de la Yamanote et des boulevards des Maréchaux (qui font tous entre 33 et 37km), histoire de savoir laquelle est la plus longue à parcourir à pied

Les cartes de Berlin Paris et Tokyo, l'intérieur de leurs lignes de métro circulaires respectives sont mises en évidence.

Cette image a été réalisée par la méthode du pifomètre. J’ai effectué des captures d’écran sur Openstreetmap.org, et ensuite, j’ai remis les images à une échelle commune.

En sélectionnant les zones intérieures de chaque ville, j’ai obtenu les valeurs suivantes:

  • Paris: 646 000 pixels
  • Berlin: 638 000 pixels
  • Tokyo: 463 000 pixels

Bien sûr, la comparaison est futile. Tokyo s’étend bien au delà de la Yamanote et me semble bien plus dense que Berlin par exemple.