The Windows UI

If you have read all my previous posts, you probably deduced that I'm a free software fan. Yes, I am, and I love free software. However, as many people, I'm forced to use Windows systems from time to time, specially for university homework.

And every time I sit on a Windows box, all I can say is "great UI". In the inside, it may be worse or better (and I tend to think it's the former), but the outside, what the user uses and looks at, is very good. Note that I'm referring to the classic UI, which got to its best look in Windows 2000, IMVHO. The new interface in Windows XP is also good, but I can't stand it for day to day usage (too bright colors).

The interface is damn fast and usable. Most common things (and not so common) are easily accessible; those that aren't usually need ugly registry tricks (but this is the "inside" view, not what I'm talking about now). The widgets have the right amount of 3D effects and size, and the default gray level is good. And if you are in Windows XP or Windows 2003 with ClearType enabled, they just look extremely well.

At last, we have the Windows Explorer... a tool that Microsoft has got simply right over the years. I still haven't found another file manager that provides me the same balance of usability and features. Konqueror may have lots of functionality but it's slower and not as comfortable. Nautilus, in its spatial mode, is quite fast, but has changed the file management philosophy completely; and in its browser mode it's just slow.

Well, now blame me for these comments, but it's what I think. KDE and GNOME are very good (assuming they are configured properly, like done in some Linux distributions), but I find them too bloated or slow compared to the Windows UI. They'll surely get better in the next years, and I hope that my view changes some day ;-)

To finish, I'm going away for two or three weeks, so there won't be more posts in this period (just in case anybody cares a bit). See you!

Changing NetBSD's console colors

Do you remember the good old days (playing with your Amstrad, MSX, ...) where the screen was something like yellow on blue? You can now do this in NetBSD!

Starting from NetBSD 2.0G, code has been added (hmm, by me ;-) to customize the console colors as well as kernel messages from userland. Previous versions allowed the modification of kernel colors, although it had to be done by a kernel rebuild.

As part of the changes, I've added a question to the wscons FAQ explaining how to do it.

For the impatient, to set your screen to look like an Amstrad:

wsconsctl -d -w border=blue msg.default.bg=blue
   msg.default.fg=white msg.default.attrs=hilit

Framebuffer on NetBSD

I've got very surprised today to find that NetBSD has a framebuffer device on the i386 platform (in fact any which uses the vga(4) driver). Well, certainly, I first saw it in NetBSD/mac68k (where there is no real text mode, so it must be emulated) some weeks ago, but was stranged to not seeing it in NetBSD/i386.

The "framebuffer" (or raster graphics device) can be enabled by adding options VGA_RASTERCONSOLE to your kernel config. According to CVS logs, this has been available since October 2002, commited by junyoung@.

However, note that this is not as featureful as Linux's framebuffer device. Ours is meant to be used to display multilingual text, but nothing more (i.e., no drawing). Anyway, it surely has room for improvements, and it could be interesting to see a complete framebuffer device support (for example to get X working easily, or to get graphical programs without X).

Tips to create good patches

We've seen the basics about patches: what they are, how they work, and how to create them. Now, I'm going to give you some tips to make your patches better.

First: change a single thing per patch, so that it can be handled on its own. For example, if there are two bugs in a single file, create two different patches that fix them independently (and submit the two in different bug reports>; see this post). Or if you are adding features, keep each feature in its own patch, except if they are highly related. In fact, this tip is not always a must; you should only care about this one if you are going to submit the patch back to a software developer.

Second: do not modify lines when you don't need to - i.e., keep your patches minimal. For example, if you are fixing a bug in a function, do not try to repair trivial stuff in other parts of the file, like removing empty lines, fixing typos in comments... I know, sometimes these happen by mistake.

Third: respect the style - indentation - of the original file. If it uses spaces instead of tabs to indent, use spaces. If lines are indented with four spaces, use four spaces in your changes... and so on. This is a general rule when modifying others' code; a single file with different indentation styles is very hard to read.

Fourth: always review your changes through a patch - that is, search for useless/incorrect chunks. When working on a project handled by CVS, it's a very common practice to modify a file and commit it afterwards. Running cvs diff in the middle allows you to catch stupid mistakes 990f the times. You see, understanding patches is also good even if you don't need the patch file for anything ;-)

Well, I think that's enough for today, as nothing else comes to mind. If you have any other suggestion, please share it!

The FluxBox window manager

GNOME 2.8 is going to be beta real soon now, which reminds me that I should start working on its port to NetBSD through pkgsrc. This means I have to zap all my desktop packages and configuration, and update them one by one. The operation is very, very time consuming, so I will be several days without GNOME installed (well... not really a problem ;-).

So I installed FluxBox 0.9.9 today... Wow! What a difference from the stable versions! (0.9 is unstable, in case you don't know.) It finally supports always on top (which I need to watch TV), edge attraction (I'd prefer edge resistance, but never mind), it's very usable through the keyboard and is really fast. Ah! And it supports tabs; I haven't got used to them yet, but many people finds them very useful (so do I in the web browser or in chats). It feels like if I had just bought a new computer.

BTW, using some of these "dedicated" window managers reminds me of several flaws in Metacity (the default window manager in GNOME). On the first hand, it is unable to remember the state of each window, in case you want; for example, it's very convenient to always start the TV viewer in the same place, with sticky state and on the top layer. AFAIK, you can't do this with Metacity, but is as easy as hell with FluxBox. On the other hand, Metacity often looses focus of the window that had it when switching desktops (haven't isolated the problem yet), which is a real PITA; FluxBox handles this pretty well too.

Give a try to this window manager. If you like minimalism, you won't be disappointed.

Creating patches using CVS

Two days ago I introduced patch files. Let's see how to generate them when the sources you are modifying are controlled by a version management system: CVS. (Note that others also have this feature; just read their documentation.)

Recalling the previous post, the common procedure to modify a source file, to later generate a patch, is to keep a backup of the original, like in:

$ cp file.c file.c.orig
$ vi file.c
edit, edit, edit...
$ diff -u file.c.orig file.c > patch.diff

This is acceptable if all you modify is a single file, but gets complicated when you have to patch many of them. Furthermore it may lead to "outdated" patches (which don't apply correctly to the latest version of the program).

But... if the sources you are modifying are controlled by CVS, things change completely. First of all, you don't have to save a copy of the original code, as it's already stored in the repository. That is, you can proceed to modify all the files you wish locally. So, how to generate the patch? All you have to do is run cvs diff -u from within the source directory. This will create a patch that includes the differences for all the files you've modified. The command accepts multiple (optional) arguments, which are the list of files (or directories) to be diffed (diffing the whole tree can be sloooow).

Once you do this, you'll note that the output generated by the command is slightly different from what I explained in the previous post (in fact, the header is bigger). Let's analyze a sample header:

Index: sys/arch/i386/conf/GENERIC
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.623
diff -u -r1.623 GENERIC
--- sys/arch/i386/conf/GENERIC  19 Jul 2004 14:23:59 -0000      1.623
+++ sys/arch/i386/conf/GENERIC  23 Jul 2004 12:39:16 -0000

The first line shows which local file is beeing diffed (matches the name in the --- line. The second, third and fourth lines give infomation about the file beeing retrieved from the CVS repository; in this case we can see that it picked up version 1.623 of the /cvsroot/src/sys/arch/i386/conf/GENERIC,v file, and that the diff command was called with the -u flag. The last two lines are as in regular patches. This information is there for the reader; the patch(1) utility will never use it.

Also note that generating patches from CVS (if available) gives a better impression to the person who has to review and apply the patch, so please use this feature.

For a complete example, check out this patch (which I'm quite proud of ;-) against the NetBSD repository.

GNOME 2.7.4 released

The GNOME project has just published the 2.7.4 version of its desktop environment. This version is the last one with "big" changes; the branch has now entered the API/ABI freeze and the module and feature freeze. Further versions will not include new features; just new translations, fixes and general polishment.

Check the 2.7 start page for more information.

Understanding patches

A patch is a plain text file that describes the differences (and nothing else) between two different files. They are a very convenient way to provide modifications to programs - you modify the sources, generate a patch and submit it back to the mainstream author - as they describe exactly what you changed. The original can easily check your modifications and decide if they are wrong or not.

Patches are very easy to understand, assuming they are in unified format (the only one I'm going to explain here). Let's see an example to make things clear. We start with two files, called file1 and file2. file1 contains the following:

This is the first line.
A line of text.
This is the last line.

And file2 contains:

This is the first line.
A modified line of text.
This is the last line.

To generate the patch between these two files, just do: diff -u file1 file2 (note that the original file goes first, while the modified goes last). The output of this command will be something like:

--- file1       2004-07-23 22:59:00.000000000 +0200
+++ file2       2004-07-23 22:59:05.000000000 +0200
@@ -1,3 +1,3 @@
This is the first line.
-A line of text.
+A modified line of text.
This is the last line.

The first two lines are the header. The first - the one that starts with three dashes - shows the name of the original file and its timestamp. The second - starting with three plus signs - has the same information but for the destination file. The second line is specially important, as the patch(1) utility will use the name in it to look for the file to be modified. More on this below.

After the header, there come several chunks, which are identified by the lines starting and ending with @@. They define the position in the original file where the chunk has to be applied (I've never understood them very well, so can't explain this in detail).

Inside each chunk there is a block of text (the four last lines of my example). Lines starting with a dash mean lines removed from the file (file1). Lines starting with a plus sign mean lines added to the file (file2). At last, lines starting with a single space describe the context of the changes: they are used by the patch utility to locate the exact chunk of the file (i.e., those lines are searched around the position specified in the chunk's header).

When you have two completely unrelated files, "removed" and "added" don't have any real meaning (but in that case, why do you want to do a patch ;-). But when you are modifying an existing file, they do.

As you can see, the patch just includes the lines that differ (and some others that surround the change). But, if the file is large, all the parts of it that haven't been touched won't be included in the patch, thus saving a lot of space.

At last, suppose you have file1 on your computer and I send you the patch in a file named patch.diff so that you can get file2. How do you apply these changes? Easy. Start by copying (or renaming) file1 to file2; patch(1) will look for the later as it appears in the second line of the header (remember I said the name on the second line was important? this is why). Then, just apply the patch: patch -p0 <patch.diff. The program will backup the original file as file2.orig and the new copy of file2 will have all the changes applied. Nice, eh? ;-)

Compiled vs. interpreted languages

A friend of mine has asked me today what the difference between compiled and interpreted languages is; so here is the answer for her and anybody else who needs it.

A compiled language is one where you have to compile the code before it can be executed. The compilation process, for those that don't know it, transforms the source code into object code; the later can be directly executed by the microprocessor (as it's formed by opcodes), while the former can't. So, more generically, a compiled language can be executed, after compilation, without any helper utility. Examples of these include C, C++ and assembler.

An interpreted language is one where you can execute the code without compilation, by means of an interpreter. An interpreter reads the code from the source file and executes it, without converting it to machine code (forget about JIT compilers for now). The way this is done depends on the specific interpreter you are using; but to get an idea, they often construct a parse tree - an in-memory representation of the code structure - from the source file and then evaluate it. Examples of these include Perl, Python, PHP, Basic and POSIX shell scripting.

So... where do Java and C# lay? You will get different answers from different people. But, in my opinion, they are interpreted languages. Yes, you have to compile them, but the code you get - bytecode - is not directly executable by the machine: you need an interpreter that runs it afterwards, which IMHO, makes them interpreted. If someone designs a microprocessor that runs Java natively (which is theorically possible, IIRC), this could change.

And at last, let's see what JIT compilers are. JIT stands for Just-In-Time compiler; they are used in interpreters (specially, in Java VMs) to improve runtime performance. How? They convert the original bytecode to native instructions before executing them, so that they can take full profit of the underlying architecture. Note that this process is completely transparent to the developer and to the user, and only depends on the specific interpreter you are using.

Scheduling timetables

I've to enrol myself in the university again - 5th semester - this Friday. The first problem is to choose the subjects I want to do; there are a lot of different subjects to choose from. But when chosen, the big problem is to schedule them so that they don't overlap in the timetable.

For those who have the same problem, well... only if you are studying at the FIB faculty... there is a program, Compatibilitzador, that can do the work for you. You only need to introduce which hours are addressed to each subject, and all the groups they are divided into. After this, you simply ask the program to calculate all possible timetables that have no overlaping subjects. And that's it!

If you know Catalan, you can use it for your enrolling too, but it'll be a bit more difficult. You'll have to add all the information manually; otherwise, it can read HTML files produced by LCFIB pages.

Teleworking considered bad

Gah, I forgot to post a message yesterday (hmm... does anybody care?). Anyway, let's talk about what I wanted to look at yesterday. While doing my English homework on Monday, I came across a quite interesting article about teleworking, titled Second Sight, from Guardian Unlimited.

If you think that working at home is all advantages, this article will show you the other point of view. Most of the reasons it gives are related to the lack of communication with people. Think of it: if you are at home, you are physically alone (and if you aren't, you'll hardly be productive). This means that you don't socialize with other people at all.

(Unfortunately) I've suffered this, although not at work. So, when, you ask? When doing university's "homework". Many people stays at the faculty and does it surrounded by other people, which they'll eventually know. Instead, I've done all of them from home. Hmm... maybe it's time to change my habits ;-)

Build your own PRAM battery

My Mac has never worked properly since I got it, as its internal battery, which keeps PRAM data, was dead. PRAM stores a lot of information (more than you could imagine, if you come from the PC world), so losing its data is very annoying (aside of producing strange system problems). So I decided to fix it today.

The first step is to reach the battery; in the Mac model I have, it's just a matter of removing the motherboard through the back tray, and detach the battery from it. Next you have to buy a replacement battery, after checking the one you need. In my case, it's a Rayovac 840, which costs more than 12 euros. Ew... I don't want to spend that amount of money - when there are other solutions - for a computer I'll use only to play with NetBSD/mac68k.

So I've picked up three alkaline and non-rechargeable AA batteries (also named R6) and soldered them together in series, producing a total of 4.5V. Then picked up the wire from the original battery and used it to connect this home-built one. Plugged it, replaced the motherboard and powered up the system. All done! I hope it keeps working properly for a long amount of time ;-)

If you are going to do this, be aware that some models use 3.6V batteries (so two AA batteries should be enough). And remember that you do it at your own risk.

Playing with NetBSD keymaps

Having configured my mac68k to boot with NetBSD, I wasn't very surprised to see that it doesn't have an Spanish keymap. So... first task, write one. Yeah, I could get used to the us mapping, but hey, I want to hack the sources ;-)

Keymaps are specific to each platform (just think that keyboards are different). Furthermore (and if I'm not too confused), some platforms use kernel keymaps while others use userland ones; if you ask me, the way to go is userland. Anyway I've only modified i386 and mac68k maps, which are both in-kernel, so this is what I'm going to explain.

To get started, take a look to the sys/dev/pckbport/wskbdmap_mfii.c file, which is used in the i386 platform, among others. It's quite complete (as i386 is the most extended platform); I've used it as a reference to create the Spanish keymap for mac68k. As you can see, the only complete map is us; all others just override the bits that differ from it. This saves space and keeps common keycodes centralized in just one table.

Ok, so let's go to the file that defines keymaps for mac68k, sys/arch/mac68k/dev/akbdmap.h. Notice that its structure is very similar to the one described in the previous paragraph. I just had to add a new array overriding the keys that don't match the us keyboard. While at it, I also modified the later as it lacked some extra keys (insert, delete, etc.).

How did I guess which keycodes correspond to those undefined keys? Well, it was "easy": I created a small program that reads from /dev/wskbd0 and prints each key press/release event together with its keycode (very easy; if you have doubts, check out wsmoused's sources, which does the same but for the mouse device).

Now you know the basics. If your keymap is not supported, it can be a good reason to start hacking! ;-)

Deprexification

Have you ever used a Mac? No matter what you answered, there is an interesting concept that makes things a lot easier when it comes to installing and/or deinstalling applications. To install a new application, you just unpack it in the directory you want. To remove it, you just remove the folder. You can even move that folder to other locations and the program will keep running as well as before.

So what's going on here? While I'm not a Mac expert - in fact I still know very few things - I guess that applications use relative paths to their files. As an example, in the Unix world, the foo program could search for its pixmap in ../share/pixmaps/foo.png (starting from its respective bin directory), instead of trying to open /usr/local/share/pixmaps/foo.png directly. Using relative paths, you could move the program anywhere else: the relative paths do not change, while absolute do.

If you have understood this, you'd have noticed that it's a matter of removing the installation prefix from all paths, hence the name of deprexification. You can find more information in this article.

This sounds like a good idea, as it could certainly make things a lot easier when installing packages: just consider the distribution of binary tarballs for any system, no matter what their tree structure is. But it seems that getting there can be very difficult (if not impossible) :-/

Got the Mac's ethernet card working

As I commented a while ago, I got a Macintosh Performa 630. Fortunately for me, it came with a regular Ethernet network card; it kinda worked with the Mac OS that came installed with the machine (7.something). However, since I zapped the disk and installed MacOS 8.1, I haven't been able to get the card working again... until today.

I've been pointed out that I could be lacking the drivers. Oh, drivers... how is that I never realized that? (May it be because I rarely use Windows? ;-) Anyway, I took out the motherboard and watched at the NIC's labels to see which one I have. According to multiple diffferent inscriptions, I concluded that its name is DaynaPORT E/CS-T. So a quick search in Google revealed several links pointing to Intel. I was surprised to see that, but later I realized that Intel bought Dayna Communications Inc. a while ago.

Once in the page, I downloaded the drivers and installed them on the Mac OS 8.1. Surprise surprise, it works! Now I have network (and Internet!) access from the Macintosh, which means I can easily copy files to it; i.e., NetBSD's installation files (what I'm playing with ATM).

My solution for the "shared directories" problem

The previous post explained a problem in pkgviews WRT directories used by a program where other packages can install files; the most typical example are directories holding plugins. It also outlined two possible solutions, or better said, workarounds. I'll explain my solution here, which is already implemented but waiting for approval.

The idea is to "configure" programs at run time to let them access the view from where they are executed. This is very easy to do: we just have to patch all programs that have this problem so that they use a global environment variable, say PKG_VIEWBASE, that points to the root directory of the view being used. Picking the XMMS example again, the program could be modified to search for its input plugins from ${PKG_VIEWBASE}/lib/Input, falling back to its depot directory if the variable is not set.

You may now think: "but hey, I have to manually set an environment variable before running programs!". True. But this can be worked around by changing the semantics of pkgviews a bit. That is, instead of creating symlinks for executables, we'd have to create wrappers. The task of these small wrappers is simply to set up the environment variable and then launch the real program.

For example, to make it clearer, /usr/pkg/bin/xmms could be this piece of code:

#!/bin/sh 
PKG_VIEWBASE=/usr/pkg; export PKG_VIEWBASE
 
/usr/pkg/packages/xmms-1.2.10/bin/xmms "$@"

As you can see, this script also has hardcoded paths in it, but these were written when the package was added to the view. If I want to add XMMS to another view after its installation, I can easily do it, and the appropiate wrapper will be generated on the fly with the right paths.

You may argue that adding a new variable is not needed in some cases, as programs provide their own way to specify the location of files at run time (for example, PKG_CONFIG_PATH in pkgconfig). I know; this is why these wrappers can be easily extended (on a package basis) to override more environment variables (like this one), which simplifies maintenance in such programs (less patches).

Nice, eh? ;-) As I said, this is already implemented and works well for me. When I've got an 'Ok' from one of the main developers of pkgviews, I'll start fixing all programs (basically, GNOME) to use the new environment variable.

The "shared directories" problem in pkgviews

As I explained in a previous post, pkgviews enables the installation of each package in its own depot directory. To accomplish this, the package gets configured with a different prefix (for autoconf users, using --prefix flag) for each package.

Now consider a program that uses a directory where other programs can install files. Let's take, for example, XMMS. This package, when installed with pkgviews, will have all of its files under /usr/pkg/packages/xmms-1.2.10; but note that all of the hardcoded paths will also point inside the depot directory. What does this mean? Simply that XMMS will try to load its plugins from its depot directory! And, as the only package that puts files there is XMMS itself, it won't be able to find any extra plugins installed by other packages.

There are several ways to solve and/or workaround this problem. For example, all packages could be patched in a way so that they always look for files in "shared directories" under a fixed view, like /usr/pkg (the default view). The problem of this solution is that you loose a lot of flexibility if you ever want to use multiple views.

Another solution is to make packages install those "special" files into the depot directory of the main package. In the example of XMMS, this means that all packages providing plugins could get installed under XMMS' depot directory. With this approach, you loose the concept of a package per view and you are also forced to add an amount of packages in each view, even if you don't want them.

These two solutions are applied at build time. There is no way you can fix this problem while building the packages. The reason is that views can be created or removed after and before installing packages. So they can't know during the build which views will be available, and in which views they'll be added.

To solve the problem, one has to find a way to change the binary behavior at runtime. But I'll leave this for a further post (probably tomorrow), and let you think about it in the meantime ;-)

Why learning English is a good idea

This is an article I have had to write for my English classes as homework. So, instead of throwing it to the trash after it gets reviewed tomorrow by my teacher, I'm posting it here. Nothing specially interesting, but it may change your mind about English ;-)

These days it is becoming more and more important to know English. There are multiple reasons to make this statement, which I'll discuss below.

Let's start with (maybe) the most relevant reason. English is spoken almost everywhere, being North America (in special, the United States) and the United Kingdom the main zones which speak it. If I say "main zones" is because they have derived in two dialects of English, known as American English and British English, respectively. If that doesn't mean they are important, what else could?

These two regions are very important in the world's economy (and culture, when talking about America), which means that you'll eventually have the need to talk to people in these countries; learning English is a must to be successful. Of course you can surely find people that knows another language, but... will it be yours? This dramatically reduces the amount of people that can understand you, depending on which language you want to use.

Another reason, related to the previous one, is the following: if you make the effort to use English when talking to native English people, they'll be more receptive to what you say. That is, they won't need to do any extra effort (if you speak correctly) to understand what you want to say (which, in the business world can be important).

And the last point I'm going to make is about computer science, as it's the world I'm familiar with (although it can be extended to many other branches of science). Most of the progress in this area happens in the countries I outlined above. But even if it happens in other countries, people tends to use English in their own programs, articles, or anything they write just because they will get a bigger audience.

An introduction to pkgviews

pkgviews is a new technology in pkgsrc; in fact it's not that new, but it is getting popular nowadays. What does it provide over the regular pkgsrc? It lets you install every package in an independent directory, called the depot directory. Lets say you install the buildtool-0.16 package; all of its files will end up in /usr/pkg/packages/buildtool-0.16, and nothing will be installed outside that location.

Which are the advantages of this approach? On the first hand, all the files coming from a single package are grouped in a single directory, making things a lot clearer when searching for files. On the other hand, it allows the concurrent installation of multiple versions of the same program. This last reason is specially important, as it simplifies the process of updating a shared library (which is a PITA if has changed its major version number) or updating a server with a very short offline window (consider PostgreSQL, where you have to dump the database using the old version and import it in the new one).

Even though, you may be asking yourself if this is worth the effort, as doing it makes PATH settings unviable. Well, here is where views come to play. pkgviews lets you create a directory that holds symlinks to the packages installed under /usr/pkg/packages; these directories are views. The default view, /usr/pkg, contains links to all installed packages (unless modified by the administrator). But if that's not enough for you, you can create as much views as you want. For example, you could create a /usr/gnome view that hold links to all your GNOME packages, and nothing else. Then, the end user has to configure his path to point to the view he wants and he gets direct access to all the packages in it.

Cool, isn't it? Of course! ;-) But there are still some problems, like handling packages that use "shared" directories (i.e., directories holding plugins and similar stuff). This is something being worked on at the moment, and it's worth a future post. For now, read the pkgsrc/mk/buildlink3/PKGVIEWS_UG file included in pkgsrc and start playing!

Need new music? Get Nightwish!

So, you are bored of always listening to the same music in your collection. Maybe it's time to get some new discs. If that's what you are thinking, give a try to Nightwish, a Finnish band. You won't regret about this choice ;) Their style is often described as gothic metal, although I've also seen them classified as opera metal. Never mind, just listen to them and then make your own conclusions.

Their last album, Once (published this year), is really cool, although many people says that it "sounds different" than previous discs. It's possible that you have listened to the Nemo song in the radio (it's the only song I've listened there so far), which is a bit commercial. If in doubt, other very good albums are Century Child (2002) and Oceanborn (1998); all of this IMHO, of course.

The seahorse project

Seahorse is a GNOME frontend for the GnuPG utility. This program is quite nice but, unfortunately, it has been unmaintained for a long time.

I've just seen in the main page of the program that they are looking for someone to take over the project maintainership. This post is just a call for volunteers. I would like to help that project (it seems a nice way to get more involved in GNOME), but I feel I don't have the time to do it :( And it could be good to have an up-to-date program that can compete with kgpg.

If you are interested, look through the list of open bugs; you'll see that there are a bunch of interesting patches sitting there, waiting for integration in the project's mainstream code. This could be a good place to start if you decide to take over the project; that is, review those patches and integrate them, publishing a new version afterwards.

Ease the way to plug your earphones

I was tired of having to manually connect the earphones every night to my computer and disconnect the speakers. So I decided to put a solution: construct a small "switch". All you need are some cheap pieces and some hours to work on it (how many depends on your experience).

What I've done is the following: put a switch which alternates between two female jacks (one to connect the speakers and one to connect the headphones). Both circuits are connected to the computer output through the switch. A very, very simple circuit. Everything is inside a small metal box, which I've attached in the bottom surface of the table. (You can also assemble everything inside your computer, if you want to avoid the extra box.)

That's all! Now switching to the headphones is a matter of pressing a button ;-)

Silencing the computer

I've decided to try to silence my computer a bit; it made too much noise. So, after reading several articles from 7Volts, as well as other sites, I've done some computer "modding" today, and the noise has decreased, but the overall temperature has increased a bit, *sigh*. Guess I'll have to tune it a bit more.

The first step has been to disassemble the box completely. Why? To cut the metal sheet covering the front and rear fans. Believe it or not, this sheet produces a lot of noise when the air blows through it. If you do this, be very careful to not leave metal filings anywere, or you could cause a shortciruit later. Also install finger covers on any hole that's accessible from the outside.

After this, I've reassembled all the pieces and listened closely to check which fan was making the most noise. Yeah, your guess is correct; it's the microprocessor fan's fault (the smallest and the one which rotates faster). I think I'll get a new heatsink plus a fan... one that's not as cheap as this, and which cools better and makes less noise (yes, there are such gems).

Anyway, I've sealed all holes in the side covers of the box and removed the side fan (sealing the hole too). I hope this improves the air flow through it. At least, the temperature has just increased one or two degrees (but note that there is one fan less than before). If you are wondering what I used to seal the holes... well, just sticky tape.

Now, it does less noise, but I feel it's too hot. Tomorrow I'll try to remove the top cover of the box, as I notice that a lot of heat remains there. If that helps, I might make a hole there to install the fan I removed before. Note that I'm no cooling expert, so these tips may seem useless to you ;-) Before trying anything, check the site I linked above, and ask in forums if you have doubts (Ars Openforum is very good).

Test Driven Development

TDD? Test Driven Development? Don't you know this concept? I didn't, until two or three weeks ago. TDD is, simply put, a development technique where test code is written before the code itself, so that the test fails before the funcionality is added and passes later. Furthermore, you'll end up with a complete suite of regression tests, useful to check if a new feature (or bugfix) breaks any other part.

I find this quite interesting so I'll be applying it to Buildtool soon. The point is to get a regression test suite so that it's easy to verify all features on as many platforms as possible (in Sourceforge's Compile Farm or HP's TestDrive, for example) before releasing a new version. As it's now, this is a tedious task, and almost impossible to properly verify all features.

You may be interested in this for your own project, too ;-) There is more information in this web.

Buildtool 0.16 released

I'm proud to annouce the sixteenth version of Buildtool (0.16), the newest and coolest version ever published (hmm... this holds true for all new versions so far). Don't know what is it? Just go to the website and start reading!

This new version comes with lots of new features and bug fixes, developed during the previous five months. Yeah, I know... a very long delay since the previous version, but I haven't had enough time to sit down and publish a version; it's a very time consuming and error prone task. Without detailing it much, I've to: create the tarballs, upload them (to Sourceforge), create entries for the files, update the website to announce the new version, send an announcement to Freshmeat, update the NetBSD packages... and post to this blog (this step is new in this version, hehe).

Hmm... I think I'll have to talk about why automake and autoconf are "bad"... to convince you of the joys of Buildtool ;-) But for now, you can read the manual, and in particular, the developer's tutorial. Have fun!

The Kaffe packages in pkgsrc

At last! I'm able to go through my TODO list and work on the items in it :-) Today I've chosen one that said "Improve the Kaffe packages" (in pkgsrc). I'm going to explain why they were wrong from pkgsrc's point of view and needed to be changed.

Until today, there were two packages for Kaffe, both mutually exclusive: kaffe-nox11, which provided kaffe built without AWT support, and kaffe, which provided everything. Conflicting packages should be avoided where possible, as they are a PITA for the end user. For example, suppose you have installed kaffe-nox11 and a bunch of packages that depend on it, only to realize later that you need to run AWT applications.

Furthermore, there was a Makefile knob, USE_ESOUND to enable or disable sound support during the build. Why is this wrong? Because it only works when installing from sources. Users installing from binary packages (me, for example, on my server) won't have a choice: they'll have to use whatever the package builder decided, be it with esound or without it.

In some scenarios, it's impossible to go another way, specially if the package builds a single, monolithic binary program (like, unfortunately, mplayer). But Kaffe is different: both AWT and sound support are provided by optional libraries, which can be installed at will.

So I removed the X11 and esound features from the main kaffe package, while doing some cleanup. Then, I removed the oddly named kaffe-nox11 package and added two more: kaffe-x11 and kaffe-esound. These two depend on the base package, and there are no conflicts between them at all. What they do is build and install the specific shared libraries needed to add these features, which are later loaded by Kaffe at runtime.

You see, problem gone. No more conflicts and people using binary packages have a choice about what they want to run on their systems ;-) Keep this in mind if you ever plan to help pkgsrc.

Posting messages with Drivel

Despite Livejournal beeing a free service, it allows you to post new messages to your blogs through external applications. This is much easier than having to log into their website and write the message from within your browser.

The only client I've tried so far is Drivel. It integrates perfectly within the GNOME desktop, and is very easy to use.

Once started, it logs you into the service and a window appears ready to post a new message into your blog. Other features include the ability to see all your previous messages and edit them interactively. I guess other clients may have more features (like backing up your messages), but I'm using this one mainly because it's designed for GNOME and is free software.

I would like to thank the author, Todd Kulesza, for his quick handling of bug reports and for kindly helping me to solve some problems that only appeared under NetBSD ;)

Make your prompt more visible

If you are like me, you'll probably have found yourself with multiple command lines on a terminal, together with their respective output. Searching those lines in the screen can be difficult, specially if your prompt is long (and with that, I mean more than 4 characters or so). A solution is to make your prompt more visible. How? Putting it in boldface mode.

While this sounds obvious (and easy), one may not know it until seen somewhere. I knew it, but as I use(d) ksh, I couldn't do it "safely" (the prompt does weird things when non-visible characters are in it). Anyway, one of the very first hacks of the BSD Hacks book (which I mentioned yesterday) made me think about this. It's not a hack by itself, just part of an example.

So let's do it. The way to achieve this depends on the shell you use. tcsh and zsh users are lucky, as it's a matter of four more characters in their prompt. The special control code %B turns on boldface, while 0 turns it off. For example, in tcsh: set prompt="%B%m%0 "; and in zsh: PROMPT='%B%m%0 '.

For bash users, it's a bit more difficult, as you have to manage escape codes directly. The way to enable boldface is with the \e[1m code, and to disable it, with \e[0m (in fact, this resets all attributes previously set). But note that you can't add that directly to your PS1 variable as these codes won't be printed. Doing so means that bash can't calculate the prompt's length correctly and will expose weird behavior when reaching the end of screen. Therefore you have to surround codes with \[ and \]. For example: PS1='\[\e[1m\]\h\$ \[\e[0m\]'.

Now I'll leave it up to your imagination. Specifying escape codes lets you do many things, like using colors or manage xterm's titlebar (IIRC), not just boldface. Note that tcsh and zsh also allow direct escape codes.

Got BSD Hacks

I've just got a copy of the recently published BSD Hacks book, by Dru Lavigne. Back in February, I wrote two little hacks (specially addressed to the book), titled "Log a headless server remotely" and "Automate NetBSD package builds", that were added to it. Wow, I'm really happy to see the printed results :-)

After I've read it entirely, I'll post another message with my impressions. Just to say that it looks promising.