Mac users are very proud of their oh-so-shiny operating system and hardware. They have to be. Mac users paid good money for their system, and it would be quite a big waste of they weren’t proud of it.

The more extreme Mac users will go around and talk about how inconsistent Linux is and how the entire Linux community doesn’t give a hoot about consistency.

While it is true that not all applications have consistent user interfaces, due to different widget tookits, it is possible to achieve basic consistency with either one of the below methods:

1. Only use applications that use the same widget toolkit as all the other applications on your system.
2. Use something like GTK-Qt to achieve consistency with multiple widget toolkits.

The second option listed doesn’t work perfectly, so to both get access to all the best applications on Linux and still have consistency would be to apply the first option until one encounters a totally awesome app that uses a different widget toolkit, and then use something along the lines of GTK-Qt to make that awesome app look consistent with the rest of the system.

Below is a screenshot of a GNOME desktop in Ubuntu Intrepid Ibex. There are small differences, such as the icons added by Firefox extensions being inconsistent with the other applications, but the desktop in general is pretty consistent.

Click the thumbnail for a full size image. The Pidgin IM client looks unusual because contact names have been blurred.

Now, what about the second option? Below is a demonstration of GTK-Qt in Kubuntu Hardy (KDE 3.5.10). Note the conspicuous lack of eye candy, relative the the above screenshot.

Click on the image to view it full size. Kate is a KDE application, and Gedit is a GNOME application.

Kate and Gedit look remarkably similar, right? Gedit’s user interface just looks a little bit simpler than Kate’s. The two editors also use slightly different fonts in the editing box, but besides that, the two editors look pretty consistent.

Of course, consistency is not just about the way things look, but also the way things act. If consistency was just looks, then there would be little need for Human Interface Guidelines. The point of this post was to demonstrate that Linux applications aren’t inconsistent to the point where it is extremely annoying.

Conclusion? Linux users enjoy consistency, though consistency is not handed to Linux users in the way that it is to Mac users.

The ancient practice of putting various monsters in unexplored regions of maps and the phrase based on that, “Here be dragons“, applies still to programming.  Personally, I’ve always had a dragon the size of a moon (or battlestation, if one prefers) on my own mental map in the area of build systems.  Hopefully, this should be a series, with several tutorials succeeding this brief summary of available options.

What is a Build System?

Just a quick introduction for those who are uninitiated into these rgb(0,0,0) arts.  A build system offers a relatively easy way to automate building and packaging of a software system.  While something as simple as a one-line shell script could supposedly be written for smaller projects, this has several problems.  Firstly, it would tend to redundantly and naively recompile objects that have already been built and have not been changed.  Secondly, this has no portability system; that is, it has no way to analyze the host system and find the appropriate utilities and libraries on differing platforms.  There are more reasons, of course, but these are the crux of the matter.

Current Build Systems

Make

Make is one of the oldest build systems, having its first release in 1977 at Bell Labs.  It is extremely simple, but pays the price; it has no configuration system, nor any automatic dependency analysis.  This makes it a decent choice for smallish projects with any advanced portability needs, but most likely you’re better served by a more powerful tool.  However, it should be noted that various projects such as Autoconf (see below) serve to expand this utility.

Autoconf

Autoconf and Automake together form a framework for generating Make scripts.  Autoconf provides the portability configuration system, while Automake will automatically analyze your program structure to determine the order that things need to be rebuilt in.  Unfortunately, on some level, this is merely lipstick on a pig (which is an idiom I used to be able to use without shifting my eyes), and due to the obscure language (m4) used to write Autoconf scripts, this is both a finicky and difficult option to use.  Configuration is slow, and is extremely awkward if you wish to target Microsoft Windows.  Last but not least, it is legendary for being extremely difficult to learn.  It is, however, the most common build system on the Free Desktop.

SCons

I’ll get my bias off of my chest now: SCons is my current favorite build system.  The scripts are written in Python, so you have a very powerful programming language to work within.  The API is a bit less than ideal in some ways, but is still quite usable.  Compilation is fast and portable, as well as being in one step (as opposed to the two-step compilation as used in Autoconf).  The GNOME project is currently considering switching to it from Autoconf.

Waf

Waf is a descendent of SCons, and thus shares the power of Python.  However, it is expanded in several ways: the API is retooled and is more intuitive in design in some ways; the configuration stage has been spawned into its own step; and compilation is quite pretty.  Despite all of this, it does suffer from a lot of API irregularities and absolutely intolerable documentation.  It is also important to note that Waf is unique in the build systems that I’m aware of in that the preferred way to use it is to actually ship it with the application itself instead of using a system-wide installation

CMake

CMake is the build system for KDE 4, and is a very nice and simple build system for projects of any size.  However, this clean and simple design is detracted from by the simplistic (though not to the Make extreme by any means) language used to develop for it.  If you can get past this weakness, however, very nice things lie inside, such as an integrated unit testing framework.  It is worth noting that rather than being a base build system, it instead generates files for the native build system (Microsoft Visual C++ on Windows, Makefiles or KDevelop on *NIX, etc.)

Others

This is where the real dragons are; the previous build systems I have at least some experience with, but these are build systems I have only heard of.  Despite this, I would feel remiss in my duties to you the reader if I did not at least mention some of the lesser-used options.

• Apache Ant is a build system is aimed at Java projects, and has its project files written in XML.
• Perforce Jam appears to be a C/C++ build system with a syntax reminiscent of Make, but with portability features, control structures, and automatic dependency ordering.
• QMake is a Makefile generator not unlike Autoconf, only with a much easier-to-learn syntax.  It is part of the QT toolkit.

This list is by no means complete.  If you have a favorite build system, please do mention it in the comments.

The web application in permanent beta is the latest fashion in today’s Internet world. Some folks believe that after several years of testing, that web applications ought to shed the beta tag and call themselves stable.

I disagree.

Open source desktop software is significantly more flexible than a closed source web application in terms of giving what users want. Desktop applications have extensibility through plugins, extensions, themes, and so forth. Web applications currently have only a weak extensibility through Greasemonkey.

Facebook Apps are closer to true extensibility, but Facebook remains in control over Facebook Apps, which results in rumors that Facebook is going to close down third party apps. Developers creating extensions of desktop applications usually do not have to worry about their extensions being wiped off the face of the Earth.

Also regarding Facebook, some users are not happy with Facebook’s transition to a new user interface. There is even a petition for the old user interface to return. I suggest you compare Facebook to WordPress. Nobody is going to force a blogger to upgrade to the latest version of WordPress, but there is little one can do if Facebook decides to switch to a different (and worse, in the mind of the user) UI.

Does my blog post ring a bell? Oh yeah, this blog post sounds roughly similar to Richard Stallman’s opinions on cloud computing. Stallman is dead right. One should only truly trust open source software on hardware within the ownership of the user.

So where does the whole “keep Web 2.0 apps in permanent beta” idea come into play? My point is that Web 2.0 apps ought to keep themselves in permanent beta as a reminder to users that no Web 2.0 app outside of the user’s control is as safe as an application within the user’s control.

Use Web 2.0 apps responsibly™.

A year or two ago, I dug out an old Compaq Presario 4508 with the task to get Ethernet working on it. After multiple failed attempts, I was successful. But my efforts were worthless, because I couldn’t find a decent browser for it.

Last week, I dug out the old Compaq Presario 4508 again to install Linux on it. I booted up the Slackware CD, and found that none of the kernels on the CD would work on the Presario. Rather than spending time debugging error messages or creating a custom kernel, I moved onto FreeBSD, which succesfully installed the first time around. Because of the very limited RAM that the Presario had, running xorg wasn’t, and still isn’t, an option. So I peacefully went to work trying to install Python and a terminal web browser.

Yesterday, when I successfully installed the web browser, the issue hit me. I sacrificed a somewhat ancient operating system with a working GUI for a more modern, stable, and secure operating system without a graphical user interface. Did I make the right choice? Most software that I care about is available or can be easily compiled on FreeBSD, but I cannot use anything that requires a GUI. With Windows 95, I had a graphical user interface, but a limited set of modern applications that still can be run on Windows 95.

So what choice would you make? Would you go with the old OS with a GUI or the modern, stable, secure, and graphics free OS?

Not counting this footnote, the blog post is exactly 248 words long.