Monthly Archives: February 2009


Not so long ago, I asked my first employer if they were still using the Unit Testing framework I developed for them while I was still in University. It was simple, with lots of hardcoded stuff and not very professional, but it worked perfectly for the needs in that moment. They told me they were not really using it, so I asked them to make it Free Software and they agreed.

A couple of weeks ago, ARTE was released licensed under the GPLv3+ license, fully copyrighted by Panda Security S.L..

I now started to improve ARTE, with better documentation and based on GLib library. ARTE is hosted in SourceForge, and you can download the first stable release here.


Having fun with an A380

So imagine that you are a pilot of small aeroplanes. Really small ones, like the ones for two people with propellers. You have piloted that aeroplane tons of times.

One day, you find yourself in a holiday trip flying in a big A380, and both main pilots get ill and can’t pilot the aircraft. You are an experienced pilot of small aeroplanes, so you decide to pilot the huge A380 yourself.

Now, what do you do?

  1. Ask for help to the people in the airport to guide you with the aeroplane details and how to pilot it
  2. RTFM, even if you know it may take some time to learn it
  3. Fuck everything! You are a pilot! You have done it tons of times! This big A380 shouldn’t be too different, right?

Oh, alright, you chose last option, hum? Then, as it is normal, your experience with the small aeroplanes has nothing to do with the A380. Even if at the end the result is the same (an aeroplane flies), they are different in nature. Engines are different, power is different, size is different, everything is different. So the plane starts to go down, and you continue trying different things… you press this button, then that one, oh shit… it’s going down… then you push that lever, nothing, oh maybe that red button there…
Shit it doesn’t work! Do I have a manual? Oh yes, there it is… ok… where is the chapter “how to start the propellers”? Humm.. where is it? Humm… Can’t find it!!! How is this possible! There is no chapter where it explains how to start the propellers!!?

Nice, so you realized it doesn’t work the way you thought it should (A380 doesn’t have propellers, among others). Again, what do you do?

  1. Ask for help to the people in the airport to guide you with the aeroplane details and how to pilot it
  2. RTFM carefully, not only looking for the chapter explaining how to start the propellers, as you already noticed that maybe the A380 doesn’t have propellers
  3. Blame every engineer who built the aircraft
  4. Blame not only every engineer who built it, but also the one who wrote the manual
  5. Blame every engineer who built it, the one who wrote the manual AND also say that your small aeroplane is also much much better than this A380 you don’t understand

How will this end? Of course, not well.

What’s the moral in this? If you don’t know how to do something, even if you think you know it, better ask someone or read the manual carefully.

Now, why this post? Because of this one: Having fun with bzr

And yes I know that Git is not a small aeroplane and neither GNU Bazaar a huge A380. But no one can say that Git is easier to understand than Bazaar. You just need to understand that even if both are Distributed VCS, their way to work is different, their interface is different… in a brief, they are completely different VCS.

P.S.: The command you were looking for so desperately was “branch”, neither “get” nor “waldo” nor any other thing. A380 doesn’t have propellers! Don’t look for how to start them in the manual!

P.P.S.: Also, the URL of the repository you were using was probably not the good one: doesn’t exist (404 Not Found). A good choice would have been to go to an upper directory and look for the existing URLs…

Debian 5.0 “lenny” is now stable

Some of you may be used to the every 6-months release of a new stable version of Ubuntu GNU/Linux [1]. That’s quite a hard strategy to follow, as it seems that the important thing is to have the release out, even if not as perfect as desired. I see this approach as coming from the world of proprietary software companies, where the important thing is to reach the release date no matter what, so that the commercial department doesn’t need to re-print the leaflets or re-design the web page to change the release date of the product. This can lead into very very wrong decisions and situations: for example, shipping KDE4 in Kubuntu 8.10 even if the release of KDE4 shipped was lacking of lots of things (and then we have to read things like these [2] to justify the decision!!).

Debian GNU/Linux [3] uses a complete different approach. There are always 3 main version of Debian available at any time: stable, testing and unstable [4]. The stable version contains what the developers consider is a real stable version. The testing version contains usually latest releases of the upstream packages, and this version will be the one converting itself into stable in the next step. The unstable release contains all the testing-pending packages submitted by the Debian developers. In this approach, you always know that stability is assured in every stable release of Debian.

Lenny, from Toy Story

Lenny, from Toy Story

This is the main reason why a new stable version of Debian, like the Debian 5.0 codenamed lenny [5] is always a special event: it happens only when it must happen, and never before.