I have started a new open source project: The Digest Software Project. It’s a small project where I develop two tiny libraries, libdigest and libpam-digestfile.

libdigest is a C library which generates RFC2617-compliant digests, used by Apache and others.

libpam-digestfile is a Pluggable Authentication Module which lets you use an arbitrarily-named text file similar in structure to /etc/passwd to authenticate users but using digested passwords (see RFC 2617 for more information about the digest algorithm).

Both libraries are stable and in production.

Did you know the code the compiler generates to handle C++ exceptions is not written in stone? I did not.

Did you know there are two preponderant styles to do that, DWARF(2) and SJLJ? I did not

When most of the unit tests in ZeroC ICE failed after building it with MinGW, I suspected something was wrong. It turned out the stable MinGW version provides gcc/g++ 3.4.5, which implements exceptions using the SJLJ style but has not implemented propagatation of user exceptions across libraries. That was the reason why unit tests were failing.

I have already built third party dependencies (OpenSSL, Bzip2, Expat and BerkeleyDB) with a gcc/g++ 4.2.1 which produces SJLJ code and is able to propagate user exceptions. ICE is now building on the side (some warnings and info messages are shown, let’s see what happens as some of them are not my fault).

I am creating Debian packages for a SNMP library in C++ which unfortunately does not properly set soname or versioning information in the makefile. It is unacceptable to ship a library in those conditions under Debian guidelines.

If you are a C programmer you don’t need to worry as binary-compatibility is usually not an issue in C as it lacks polymorphism.

If you are a C++ programmer and you don’t know what an ABI is and why binary compatibility matters, you must first read and understand what an API, an ABI and name mangling are.

Even if you already knew about ABI and name mangling, you probably don’t know about binary compatibility in shared objects (libraries). Don’t worry: ABI-compatibility is non-obvius and most C++ programmers don’t know a word about that.

The idea is quite simple: if you uncarefully change the API of your library you have also changed the ABI of your library and, most probably, due to name-mangling and virtual tables (needed to support polymorphism), the new version of the library is ABI-incompatible with the older version.

There are two kind of changes you can make: extend the API/ABI but leave it compatible with former versions, or extend the API/ABI and break binary-compatibility. There is very good information about what changes render your library binary-compatible and which don’t in the KDE wiki and in the Qt FAQ.

Once ABI compatibility is clear, the next question arises: how does my library state its binary compatibiliy? There are essentially two mechanisms for that: the Sun Solaris-specific mechanism (which is great, by the way) and sonames (used by most other Unices and Linux). There is plenty of information about sonames at the libtool manual and the Debian Libraries Packaging Guide and a good example at LinuxQuestions. For more information about the Solaris mechanism, read carefully the DSO howto by Ulrich Drepper (page 35, section 3.3: “ABI Versioning”).

Two important things you have to remember:

  • If your library version is the same as your soname version, you have not understood a thing of what I said above
  • If your library is stable, follow these guidelines.

In case you really want to keep ABI-compatibility for whatever reason (you are developing a very spreaded C++ library and the user might have a newer/older version already installed, you don’t want to update versions unless totally necessary, etc), take a look at the opaque pointer technique (AKA D-Pointer) invented by Trolltech.

For almost 4 years I worked for a small company, Venue Network, as a Systems Administrator. At the beginning my job meant dealing with Windows 2000 Server and Windows 2003 Server systems. As time went by I was able to introduce Linux and FreeBSD servers in some clients, saving them money and us hassle. The last 18 months there I barely touched Windows systems: the increasing demand for Linux and the storage-hungry users led me to focus on SANs and NASes and Linux. I still did some very specific (read: complex) work on webservers, but that was the exception as I was already overloaded with work.

One day at the end of October 2006 I received an e-mail from another company saying they read about me in the aKademy 2006 site (I gave a conference last year) and would like to know more about me. I sent them my phone number and the next day we talked on the phone for about 20 minutes: they wanted me to work as a C++/Linux/Qt developer. I told Jesús (the CTO and one of the founders of the company) I had never had a developer job. The most ressembling job I had held was a summer internship in 2002 as a multimedia script writer but I didn’t think that qualified. I was not the person they were looking for. He insisted and we arranged a meeting for next week at their offices. Truth is I thought Jesús was crazy and I would be wasting his time and mine, but I agreed. How could I possibly have a job as a C++ developer? It had been years since I programmed in C/C++ and I only developed in Ruby and as a hobby (Ruby, QtRuby, Rails, etc). My visit to Arisnova went very well: Jesús was full of confidence I would be able to do the job and he was so convicing even I started to believe it (actually he was so confident I tried to hand him my resume and he declined the offer :-O)

Would it work? Venue Network was a tiny company where I held a very comfortable position and I already had earned my medals, I did not need to demonstrate anything anymore. At Arisnova I was going to start from scratch!

Fast forward to May 2007.

Turns out I accepted the offer and I have been working for Arisnova for 4 months now. My main job is porting our Integrated Platform Management System from Windows to Linux (auxiliary libraries, middleware, applications, everything). This software manages ships (frigates, corvettes, etc) and has been in use on Windows for several years now, ships have been sold for several countries and they all are very impressed with the software.

We use a lot of open source for the IPMS: Qt, Boost, ACE, ZeroC ICE, OpenSceneGraph, Lua and the list goes on. As the building blocks were already cross-platform, the port is being easier than everybody expected (including me).

The main innovation coming with the Linux version is the movement to KDE: the Windows version depends on several ActiveX components for video, documentation, videoconferencing and some other features. Obviously ActiveX do not work on Linux, so the first thing you think is we would need two different branches of code or a hell of a lot of #ifdef‘s. Not! (sorry, I couldn’t resist). Thankfully, being a KDE bigot is going to benefit our IPMS: KDE4 is multiplatform (Linux/Unix, Mac and Windows), therefore we will be making extensive use of KParts and almost every new technology KDE4 features: Phonon, Decibel, Strigi, etc (by the way, GNOME is not even close to this). We will also be using CMake.

As the port has progressed at a faster pace than we expected and we’d like the KDE4 to be quite stable when we invest our time, I have some time to fiddle with other things. Something I am looking at for the third version of our IPMS, which is currently in its inception, is Flash. Is it possible to integrate Flash in a desktop application (our GUI) and make it feel natural for the user? Will we need to embed a WebKit/Konqueror/whatever component as a "proxy" between the application and Flash? I don’t know yet, but I am currently investigating every lead: dlopen, libflashsupport, XEmbed (which has pretty easy to use since Qt 4.1).

Summarizing, I am very happy I moved to Arisnova: the job is interesting, I am learning a lot, people are nice, I am performing way better than I (and everybody) expected and I see exciting challenges coming. Thank you guys!

I have started a new open source project called Destral. It is a command-line utility to split and join files, much like Hacha and HJSplit.

The main advantages of Destral over Hacha and HJSplit are:

  • Multiplatform
    It is written in pure C, therefore it should build in every operating system with a C compiler.
    This single utility works the same for Linux, Windows, Mac, etc, forget about using a different utility in each operating system. Same use, same flags, same everything.
  • Destral is able to split and join using Hacha 3.0, Hacha 3.5 and HJSplit formats. To state it clearly: Destral does not use a new split and join algorithm. It does not need Hacha 3.0, Hacha 3.5 or HJSplit to work, I have implemented the algorithms.
  • Destral is intelligent and uses sensible defaults.
    Most times you will not need to tell it what split and join algorithm you want to use, it will discover.
    For instance, when you want to join several chunks in a file you just run destral -j myfile.0, or destral -j myfile.000, or destral -j myfile.001 (at this moment you need to provide it with the path for the first chunk, but this weekend I will make it intelligent enough to search for the first chunk if you pass, for instance, chunk #3).

There is no release yet, if you are interested you will need to access the code via Subversion. The only dependency besides a C compiler is CMake, but it’s possible and easy to build it without CMake.

Current features:

  • Join Hacha 3.0, Hacha 3.5 and HJSplit/lxsplit files (no CRC check in Hacha files yet)
  • Multiplatform
  • It works and is very fast

Known bugs: there is an issue I just discovered with the names of the joint file under certain conditions, I will fix this soon.

Future features:

  • Fix bugs
  • Implement splitting of files, with sensible defaults: Destral will automagically select certain chunk sizes depending on the input file (it will be possible to override that using parameters).
  • GUI
  • CRC reverse engineering (the Hacha developer does not answer my e-mails, so I have no information about the CRC algorithm he is using)

A few weeks ago Troll Tech released official QtJava bindings under the name of Jambi. With Jambi, you can build native applications for Windows, Unix and MacOS X using Qt and Java. It’s a good idea and a good implementation, although nothing revolutionary, I myself have been successfully using QtRuby bindings for a few months.

But this mad head of mine started to think about the potential of bindings, compilers and code generation.

There are thousands of Qt developers who know the C++ API to Qt very well.

Qt is able to build native applications for many platforms (Windows, Unix and Mac OS X).

There is a number of unofficial Qt bindings (Ruby, Python, Java, Ada, Scheme, etc).

So here comes the idea: Qt-Web bindings/compiler/whatever. How could this mad idea be implemented? I have some ideas.

Keep in mind the point in the Qt-Web idea is not to have the best possible webapp development framework but to take advantage of the horde of Qt-literated people out there. Let me re-phrase that: this idea makes more sense to Troll Tech who be selling more Qt licenses and support contracts, than it makes to web developers.

As I was saying, I have several ideas on how to implement this:

  • Use Jambi to build Java applets. The return of Java applets 10 years later, wooohooo. Horrible, I know. And there is the disadvantage of downloading part of Jambi as needed or get Jambi included in the official Java repository. But that could work.
  • Qt-Flash bindings. You develop your application in ActionScript using Qt and you get a SWF. It would be more or less like the previous approach.
  • Qt-to-Flash compiler. You develop your application in C++, using the very same APIs and tools you use to develop a desktop application and you have a new “make all_flash” target that generates a SWF. 96% of computers have Macromedia Flash installed.
  • Qt-to-AJAX “compiler” (I think “translator” or “generator” would be a more appropiate word). You develop your application in C++, using the very same APIs and tools you use to develop a desktop application and you have a new “make all_ajax” target that generates HTML, CSS and Javascript. Now this has the potential to become Web 3.0: you develop webapps just like you would develop desktop apps!

Everybody is talking about Novell’s decision to move from KDE and Qt to Gnome and Gtk. Me too.

My point: Novell is stupid. Plain and simple. Very stupid.

Gtk is ugly to develop with, inconsistent, lacks a lot of functionality and it is a complete joke for multi-platform development.

KDE is so superior to Gnome, the next version of Novell Desktop will be a joke. Kiosk in Gnome? No. Integration and consistency rather than a collection of non-cooperating Gtk tools? No. Lots of advanced software? No.

People say the reason behind the move from KDE to Gnome is the Qt license (pay for commercial use). What a joke. Qt is so superior to Gtk it pays for itself so soon you will never regret buying it. A Qt license is worth half the pay of one developer for one month. Your company will recover that money immediately.

Had Suse used Gtk instead of Qt, Novell would be firing twice the people they are firing now. And the movement from KDE to Gnome is so stupid they are firing theirselves on the foot.

Bye, bye, Novell, you had the best (Suse Linux, ZenWorks and eDirectory) and you decided to suicide. You can thank Miguel de Icaza, Nat Friedman and those Ximian people. This reminds me of Netscape & Collabra.

Today they arrived, after two weeks crossing the ocean: Code Complete, 2nd Edition and Programming Ruby, The Pragmatic Programmers Guide 2nd Edition.

I have really big expectations from Code Complete, everybody keeps saying it’s a wonderful book and McConnell is a genius of software development management. Hope to learn at least 10% what he knows 🙂

I also have big expectations from Ruby, but not because of the language per se but because of Ruby on Rails. If everything goes fine, in a few weeks I will be leading a very big project where I will need to develop a web application really fast, and RoR seems to be the right choice here. I tried Subway (it uses Python, a language I am more familiar with), but it just does not compare to RoR, maybe in a few years.

These books didn’t came alone, they were in good company: What do you care what other people think? by Richard P. Feynman, Perfectly Reasonable Deviations From The Beaten Track: The Letters Of Richard P. Feynman and The Elegant Universe by Brian Greene (yes, I know it’s in Spanish, but it’s soooo expensive in Spanish!)