Source-Level Versioning?

When you develop software, you’re always dealing with dependencies, and, if you’re lucky (or have made a quite enlightened choice of dependencies), you don’t have to worry too much about version numbers. But what if you do?

Patching the Environment for ‘exotic’ Libraries

Every time I add a development library (or any other application) that is not found in my distro‘s repositories, I ask myself how troublesome it will be. If you’re really lucky, it comes in a package (and repository) compatible with the target distribution (like a Debian package or a RPM) and everything is just fine: you install it from the package manager, and that’s it. But if not, you have to download a tarball from some (more or less trusted) location like Sourceforge. It usually comes with a rather well designed set of configure, make, and (sudo) make install scripts that reduces configuration to little more than launching the configuration script, check for any unmet dependencies, add them and rerun the configuration script until they are all met, and then make install performs a smart, standard location install and you’re done. You won’t have the automagical upgrades with everything else, but you can go on with your life.

Then again sometimes you have to install a library (or application) that either has a half-baked installation script, or is incompatible with your distro, or, cerise sur le gâteau, both. And, just to aggravate you just fine, it installs to a non-standard location requiring you to specify include and library paths in your make files or just to invoke the application. And, of course, default location will change from from /usr/local/shared/thislib/ to /usr/shared/include/thislib between version 2.1.5 and 2.1.6, just to make sure to break just about everything you set up.

Sound Screen

Even if you pay some extra to get low dB fans and set your BIOS to have varying fan speeds it still can be quite far from quiet. 20 dB isn’t that loud, but it’s not silence, and— let us be blunt —adaptive fan speeds seems pretty much to alternate between off and full blast. If your computer is near a wall, the noise reverberates through the room, and the low-frequencies leak in the room on the other side of the wall.

So to muff the sound, I build a “sound shield” made out of custom upholstered panels.

Programming Fonts

Having a decent editor is something we have discussed before. Last time, I was telling you about features that I wanted for programming, such enhanced scope visibility. But the font we use also play a major role in code legibility. This week, let me present you the few I really like.

Damn you, Saint-Exupéry!

The Ubuntu Linux distribution is putting a lot of efforts into streamlining the interface and provide a greater user experience. While there’s clear progress, there are a number of things that are still really missing. The guys at Gnome and at Ubuntu are maybe taking the motto perfection is not when there’s nothing else to add, but nothing else to remove a bit too seriously. Every release shows more and more features but less and less user configurability.

Well, to be honest, I have always found my way around those limitations by hacking directly configuration files, the gconf-editor registry-like thingie, and writting scripts to set automatically configurations for which there were no other way—or just not documented, which is the same as far as I am concerned.

Amongst the extra thingies, there are many keyboard shortcuts, but not all of them are configurable. For example, if there’s a way from Gnome to configure which keys you want to use to control LCD or keyboard brightness or to display power information, it’s pretty damn well hidden. On my Dell mini, there’s a nice key with a battery icon on it. If I press it, Gnome displays in the OSD a concise battery status. But on my macbook pro, there’s’nt such a key and I have no way of telling Gnome (from Gnome itself) to use the F4/Gauge key to act as the Show Battery key.

Dog Days

Last week (at the time of writing), we were hit by a bad heat wave and, while none of my computers crashed or caught fire, it was clear that they were operating well outside their usual comfort zone. The first thing to do is of course to use well designed cases that provide adequate cooling (not like the compaq 6400NX). The second is to use all the advanced power management features available—whether it’s SpeedStep, Cool’n’Quiet, or PowerNow!. You enable it from your computer’s BIOS and usually the operating system takes over when you boot.

Changing dynamically the CPU’s (and other devices?) speed (and therefore power consumption) to respond on demand to the user or system tasks is quite a good policy for desktops and servers (that’s why it defaults to “ondemand” on Ubuntu) but it may not be what you want for your laptop or netbook. For a netbook, setting the power policies to “powersave” will keep the CPUs into low gear and extend significantly battery life. The thing is, Ubuntu doesn’t let you set the default policy easily.

Getting Clip-Art

Interoperability of software is still a major issue. Not only closed systems do not play well with others, open systems sometimes—often—have the same problems with exchanging information. One that only plays well with others when forced to is, of course, our good friend Microsoft. Sometimes they pretend to play well, and other software developers must reverse-engineer the file formats to read and write data in a compatible format.

One minor annoyance is Microsoft Office’s clip-art bundle file format that is not supported (at the time of writing, anyway) by Open Office. This means that you can download clip-art for your presentation only to discover that they are perfectly useless. Or, you can take 10 minutes and look at what the bundles actually contains!

One Does not Simply Rename Into C++

Programming is in many ways more art than science—I do not want to start that debate in this post—in that you need more than mere functionality and correctness to have great code. For code to be great, it has, amongst other things, to be beautiful in that strange, vague, language-specific way.

As you know, this blog is C and C++-centric. Those are the two main languages I use both for personal and for professional projects. I resisted the transition from Pascal to C a long time, for many reasons. One was that at that time C compilers were flimsy, while we had a couple of really great Pascal compiler, such as Turbo Pascal—quite the upgrade from my Apple II’s USCD Pascal. Another was that I found C just ugly, clunky, and primitive; it was terse and inelegant. But over the years, I learnt to like the way C gives you pretty good control on what code is generated—not that you can predict right down to the assembly instructions what the compiler will generate; but you still have a very good idea if you understand even vaguely the underlying machine.

#defines are EVIL (part II)

In a previous post I discussed some aspects of the C preprocessor (hereafter the CPP) that are evil. Turns out that this week, I had another problem related to a bad usage of the CPP. It didn’t take long to fix, but I can understand why it could be long to figure out.

And while the bug was caused by a careless use of the CPP, I think there’s a couple of simple things we can do to help avoid these.

Upgrading to Lucid Lynx

Every once in a while, if you’re not using a rolling release distro like, say, Arch Linux, you have to dist-upgrade your machines. Dist-upgrading consist in upgrading pretty much everything on your computer to the new version sets that correspond to the next distro. I just upgraded from Koala to Lynx.

And, well, …