/home/nand

Several times I have wished I had much more artistic skills. An beautiful and appealing UI can make a difference! Look for example at K3B: this is a real pleasure to use this app! But unfortunately, I can only struggle to do some basic graphics…

Luckily enough, some artists are around, e.g. in the Ubuntu art team, and when they start to work, it’s awesome. I asked some days ago on their mailing list for help to design a logo. One of them, Thorsten Wilms, quickly gave me this sketches, then the next day one mockup of one I choose, and finally this final result the next day. Awesome!

Kudos to him and the team!

And of course, happy new year!

I just got through the Ubuntu art team mailing list, and I should say : Whoah! What traffic! And what nice mockups! I’m really confident we will have an awesome new theme for Heron!

Here one of the best I have seen (from Thomas L.G in this post, http://www.portefolje.net/div/mockup.jpg) :

Edit: Sold/Vendu!

(Sorry, french only!)

Après un 4L Trophy 2007 fort d’émotions, l’année précédente à la bricoler, et l’année d’après à rouler tous les jours avec, je m’en sépare Et oui, malheureusement il se trouve que j’ai mon premier job à Paris, et je n’aurais plus le temps de m’occuper et d’utiliser ma 4L autant que je voudrais. Donc je vous fait la description de la bête:

4L TL 1989 956cm^2

• Décors désert et chameau, par Nessé, artiste à Grenoble.
• 140000 km (il faut que je verifie, c’est dans les alentours)
• Deux phares sur le toit, commande sur un tableau de bord customisé. Attention! La galerie sur le toit n’est pas à moi, je ne la vends pas avec.
• Sonde de temperature de liquide de refroidissement et indicateur sur le tableau de bord (tres utile!)

• Ajout d’un second ventilateur de radiateur, activable manuellement sur le tableau de bord. Possibilité de forcer la mise en route du premier.

• Redirection de l’entrée d’air du moteur à l’interieur de l’habitacle avec filtre supplémentaire. Protegez votre moteur du sable, prenez l’air dans l’habitacle!
• Pièces changées:
  • Pompe a eau (préventif)
  • Changement du joint de culasse, et autres joints annexes. Les courroies aussi. (préventif)

  

  • Changement du thermostat (préventif)
  • Deux pneus neufs à l’arriere. (préventif)
• Controle technique OK du premier coup (juillet 07). Vous aurez donc pas à le passer!
• Quelques pneus fournis.
• Un bon carton de pièces diverses et variées.
• Poste cibi avec son antenne. Pratique sur l’autoroute pour discuter avec les potes.

• Enceintes 4.1 installées dans la 4L. Oui, et du bon! Attention! Prevoir de changer le transfo 12-220V, le mien, un premier prix, est sur le point de mourir.
• Ordinateur de bord! Oui! Ecran tactile, il fait office de lecteur MP3. Pas forcement pratique, un petit baladeur mp3 est eventuellement à prevoir pour le remplacer.

• Plaque de protection: je peux vous passer photos et explications pour en faire une pour 60 euros (et encore, j’ai pas optimisé les prix).

• Et en prime, mes conseils sur les pieces critiques pour le trophy

Bon, tout ca, c’était les bon points. Mais comme je suis honnete :), voici les mauvais points:

• Le point d’attache de l’amortisseur arriere gauche a cédé pendant le 4L Trophy, a cause d’une fausse manip de notre part. A noter que cela ne nous a pas empeché de rouler pendant quelques centaines de km. Cela a été ressoudé, nous avons roulé la fin du trophy avec, je roule tous les jours depuis un an avec, et ca a passé le controle technique. Donc a priori, ca ne vous empechera pas de finir le trophy mais c’était à préciser.

Voila voila, je vends la bête à 1000 euros, jetez vous dessus! Je suis sur Vaugneray, à 20 km à l’ouest de Lyon. Me laisser un commentaire si interessé, avec email, je vous enverrais alors mon numéro de téléphone.

When packaging, the debhelper (dh_*) tools are both wonderful and awful. Wonderful because they easily handle almost every case, in a very neat way. Awful, because when they don’t work, have a few spare hours ahead!

I’ll share my experience with some private libs, it may be of some help for others. I have a source package that leads to two binary packages. One contains a daemon and some privates libs, the other contains a GUI client. The warnings were “dpkg-shlibdeps: Impossible to find a package for libike.so.2.0.3″ and then “dpkg-shlibdeps: Impossible to find the dependencies of libike”. This would then lead to a missing dependency between the two binary packages.

Ok. Why is it trying to find a package for the lib I am currently building?? The man page was no help. After a few hours of search, I found a notice inviting me to see the dpkg-shlibdeps man page in the very latest version of dpkg-dev. Ah yes, much more clear!

Basically, dpkg-shlibdeps works in two steps. It first list all the required libs for the executables, and then for each lib, it searches to which package it belongs, using dpkg -S and the shlibs files. And here was my problem : I had removed the call to dh_makeshlibs as I thought it was not necessary because the libs are private. But in fact you still have to generate the shlibs files : the debhelper tools will take care to put them in the binary package only if the libs are public.

Yay!

Yay I did it!

The eGenting competition is a programming competition organized by the Genting group that takes place simultaneously in Kuala Lumpur, Malaysia and Singapore. It’s eight hours of straight problem-solving, and the worse part of it? It is on paper. I gave it a try last september, and the results are just out : I’m third. That means 2000 Singaporean dollars (~= 1000 euros), a 120GB USB hard drive and a job offer at the Singapourean R&D branch of Genting. Whoah!

On these pictures you can see us, the first, second, third, fourth and the first of the “employees” category, going back in the MRT with our big checks

 Going to Japan has always been my dream. The glimpse of the Japanese culture I had attracted me so much, I didn’t really know why.

And last week, my dream comes true. I took advantage of the small holiday period I had before returning to France (I’m was studying for the semester in Singapore) to go to Japan for one small week, with a friend. Fortunately, I had a Japanese friend I met a while ago while traveling, and she was kind enough to make us discover Tokyo and its surroundings. Domo arigatoo Kaori!

Japan is a wonderful mix of traditional and modern culture. I was amazed at how the old ways of living are still common and present. For example, you could see businessmen and women in traditional kimono on the streets. And traditional houses along modern ones. Kabuki and Noh theaters along modern ones. Personnaly I am not a theater fan at all, but here I had the chance to see three different plays, a Kabuki one, a Noh one, and a modern one, and I loved them.

The religion is strong. The way of the Buddha is followed by Japanese people, and the multiples temples are often full, not like our churches. Japanese people are superstitious too. For example, I washed my money to bring me good luck! Wishes are written on wood blocks and hang on the temple, and we can have our fortune told. On a shrine, one shall throw a coin on a box before making a wish.

Food too is wonderful. Lots of new different tastes for me, some strange, some very good, some both (the green tea and purple potato ice cream was delicious!). Sushis of course, but it is far from the best. At the beginning I tried to remember the names, but I gave up! Ramens and udons (pasta and thick pasta on a soup) are pretty good!

I was lucky I came at a good time for the landscapes. At this time of the year, it is wonderful. Bright green, yellow, red all together, I have never seen that. I shot everywhere, I think I now have wallpapers for one good year.

Finally a funny thing : France and French is popular! While we can see some English on metros and some menus, French is definitely the cuisine and mode language. Look at this notice, it is the Lyon Bistro! (Lyon being my hometown in France)

During this week, I only stayed in Tokyo (in this hostel I definitely recommend) and to my surprise, one full week was still not enough for Tokyo. I will definitely come back to Japan in a few years, once I have some money!

Remember a few posts ago when I mentioned the cooperative bug isolation research project?

I was thrilled because it sounded like it has much potential, but still I was expecting the disappointment of discovering an empty box with buzzwords sticked all around it. So I gave a try and read some of their papers : [1] [2] [3].

And whoah! It looks nice and have a concrete useful output! To sum up the whole thing for a developer :

• Binaries need modifications, and a simple change in the toolchain is needed. The bad consequences here are an average package size growth of 50%, and a performance decrease, but it is said to be negligible.
• At each execution, some of the decisions of the program (ifs, return values,…) will be sometimes (e.g. 1 time out of 100) sampled and saved. Crashes will be recorded. Then the whole data is regularly send to a server. (A few kbytes a time).
• In the server side, we get a whole aggregated picture of how the software behaves, and misbehaves. Here is the interesting stuff : to put the things simply, the server will know at each decision of your code what is the probability of a crash depending the outcome of the decision. But wait, more to come! These probabilities themselves won’t help much finding the bug origin, which can be hundreds of lines before. So the server will compute the increase of crash probability between consecutive lines. If a crash probability jump after an given decision, it is likely this decision is at fault. Using this new info plus some more duplicate removal algorithm, we end with a small number of relevant pointers to buggy decisions. And this works pretty damn good!

Ok, the example now. Look at this exif analysis (xslt’ed xml). The thermometer size correspond to the logarithmic size of samples the server get : a big thermometer means *much* more samples than a smaller one. The white area correspond to the number of successful execution (no crash) with a given decision. The dark area plus the red area correspond to the number of unsuccessful execution (crash is incoming) with a given decision. And the important part : the red area is the difference of crash probability before and after this decision.

Now look at section 4.2.3 of the [3] paper for the analysis of the exif results. (and you should definitely read the whole paper btw). This is real good! More software samples here (end of page).

As a conclusion, paraphrasing one of the papers : before, users could only rumble at crashes. Now, the developers are overwhelmed by bugreports, many being duplicates or with not enough debug infos. Will CIB mean the end of bug handling as we know it?

Sometimes I stumble upon so good unknown movies that I want to share them here. The last one is called “A man from Earth” (2007). It is unique in several ways : first, all the movie takes place in one room. Second, you see teachers colleagues discussing the whole movie. Looks nice, right? But yes, you should definitely see it.

The story starts with the hero, one professor, leaving his home. Some colleagues come unexpectedly for a farewell evening, and are thrilled that the professor won’t reveal his destination. They ask questions, the hero is a bit bothered. Hesitating, he finally starts with “Ok. Imagine a man who lived 14000 years…” And he starts talking about his long lifetime, pressed by his friend questions. And here no fancy flashback with special effects or anything, just a discussion. A discussion between university teachers, with very credible characters, with reactions going from curiosity to anger, disgust, pity, incomprehension.

IMO, a factor that indicates a very good movie is for how long you still think of the movie after the end. And here, I did for a long time! Imagining the possibilities. How it would be like. Whoah!

Definitely recommand it.

Yay, I finally did it! The ike package (a VPN client) is up on the Ubuntu hardy Universe repository! Making a debian package for Ubuntu is not as easy as one may think…

I will now explain the process to create one.

• First find something to package Easy task, just pick one on this list at Launchpad. But as it is stated on the wiki page, don’t forget you will then become the maintainer of the package, meaning you’ll have to act as an intermediate between Ubuntu and upstream (it’s how the developers of the software are generically called) for the bugs, security updates,…
• Read some doc. Not the fun part, but you will have to. You can start by this Ubuntu wiki page. You will notice there are differents tools for packaging. I personally used debhelper.
• Then start packaging! An invaluable place to learn and ask question is #ubuntu-motu in irc.freenode.net. Lots of MOTUs ready to help there. (especially the one nicknamed “persia”, who helped me and others a lot!)
• Once you have your first rough package, you will use a nice review tool called REVU (MOTUs lacks originality ) There, you will upload your packages, and once a week, on “REVU day”, you shall ask for a review on #ubuntu-motu.  One MOTU will point out a list of errors, and help you resolve them. You correct, and you try again. And so on until it is shining! Here is my entry. Yeah, it took one month!

But once you have made your first package, the packaging internals are much more clear, and IMO this is a very good place to start!

While cruising randomly on the Internet during this recess week, I found an very interesting research project : the cooperative bug isolation project.

My rough summary : This is a project that aims at collecting a large amount of behavioral data from application, and extracting useful informations for debugging. To do this, the source code is altered, and at strategic points (ifs, system functions), it *sometimes* records the behavior of the application and send it to a server. Then, with all the data, we have some interesting statistics on the software behavior, and it can help greatly to track bugs down.

I definitely will read their papers