Improving your coding skills

If you want to improve your coding skills, you can do so by solving some problems used in the ACM International Collegiate Programming Contest. You can find the entire collection here, which is really huge.

Solutions to problems are verified by an automated program, the Online Judge. To get started, you must sign up for an account; after that, you will be given a user identifier and a password. The identifier must appear on all problems you solve (check the documentation in the site for more information), so that the judge knows who solved them.

After that, start to do solve any problem you like. When done, it must be sent back for verification (again, check the site on how to do this). The judge will reply you with a code indicating if your program ran ok, failed during execution, did nor compile, lasted for too long, etc.

Note that these problems are not all about coding skills, though. Coding helps in getting a solution implemented as quickly as possible, but you first have to know which algorithm to use. Some of them require geometry or graph theory knowledge, for example. Others are very easy.

Frankly, I don't enjoy much these problems; if I have done some is to pass a subject in my degree, but not to spend my free time. Even though, you may be different, and enjoy solving them, like other people does. And you can even join the programming contest!

Dealing with bug reports

Some days ago I posted a message, titled "The art of bug reporting", which gave some tips to fill good bug reports. Today, I'm going to review this same process from the developer's point of view, who has to handle these reports.

Developers are often organized in workgroups; this way new bug reports can be easily assigned to one of these groups. This classification is done automatically, based on what the submitter specified in the respective field. Even though they can be reclassified (in case of bogus choices) by a team specially designed to review bugs (or individual developers). For example, GNOME has the Bugsquad team (which you can start to help now!), while NetBSD has no such workgroup (yet).

When the bug is assigned to a team within the project, it will easily catch the eye of one of its members. That developer can either do nothing (because the report is incomplete, doesn't have enough time to work at the moment, doesn't know how to solve it...), fix it immediately (if it's trivial) or assign it to himself (to deal with it in the future, and to note other developers that he's working on it).

If a report you are reading misses information or is incorrectly written, request more information from the submitter (putting the report in the appropiate state, like NEEDINFO or feedback). Remember to be polite, even if the report seems "useless" to you (I.e., it lacks a lot of details, points out an obvious thing, etc.). It's important to get collaboration from submitters, and bashing them won't help.

If you are going to fix it, do whatever is appropiate (you are a developer of that project, so you are supposted to know what's good or not ;). Note that if the submitter sent a proposed patch to fix the problem, and you used it, you should give credit where possible. This will make contributors feel better (which implies that they will send more patches).

And, at last, try to fix bugs as soon as possible. Forgetting about them will only make your bugs database grow; patches attached to bugs will become obsolete, some will not be reproducible any more (although the problem will still be there), the reporter may not be available any more to provide more information, etc.

GNOME 2.6.2 released

The GNOME Project has just released the 2.6.2 version of its desktop environment, probably the last release of the 2.6 stable branch. The official announcement provides more information, including a list of changes since the previous version.

Furthermore, I've just updated all the GNOME packages in pkgsrc to their respective versions in this new release. That is, you can easily install GNOME 2.6.2 with the simple cd pkgsrc/meta-pkgs/gnome && make install command... and on multiple platforms! This may be a good reason to try this excellent package system today ;-)

Making an Athlon system consume less power

This has been posted today to Barrapunto, but as I find it very interesting, I'm repeating it here.

The Athlon Powersaving HOWTO describes a way to make your Athlon, Duron or Athlon XP microprocessor consume less power when it's unused, i.e., when the null process of the operating system is executed. This process does nothing; it's just an endless loop, activated when no other process can use the CPU. So why use the entire power of the microprocessor when the null process is running?

To make these microprocessors consume less power, they need to be disconnected from the FSB, a process that can be done with just two commands. This is what the HOWTO explains. It also covers some common problems that may appear after doing this, as well as workarounds for them.

I just tried it and the processor reduced its temperature around 10�C! Yeah, I know, make system load go up and it will return to its normal temperature. But many CPUs are not overloaded all the time, so this little trick can increase their life significantly.

It's a pity it only works in Linux. I guess I'll have to port it to NetBSD... I mean... try to ;)

Watching remote system activity

gkrellm is a very good program to watch system activity. It provides a small window where monitors are stacked up; these include things like CPU and network monitors, weather reports, sensor control, etc. The window is also themeable, so that you can customize gkrellm's appearence in any way. Just because of this, you have to give it a try!

One of the new features in the (somewhat recent) 2.x version is support for remote logging of computers. That is, you can watch remote system activity (provided by any supported monitor) from a single computer. Let's see how to do it.

To start, you have to set up a server process in the machine you want to watch its activity. This is simple, depending on which system you use. In NetBSD, you have to install the gkrellm-server package (simple as hell with pkgsrc ;). Once installed, you need to activate it. Just add the gkrellmd=YES line into your /etc/rc.conf file, copy /usr/pkg/etc/rc.d/gkrellmd into /etc/rc.d and start it like any other service. You may also want to edit gkrellmd.conf to only allow connections from the system monitoring this one. After this, the server is now ready. (Adapt these steps to your system; should be similar.)

In the client side, just launch gkrellm with an extra parameter, like: gkrellm -s hostname. A new window will appear, and... suprise, the statistics of your server are there!

The art of bug reporting

Software is not perfect. When using it you'll eventually hit bugs, some of which may be trivial, like a typo, or very annoying (crashes, broken features, etc.). Reporting them is a good way to help developers, and you can do it even if you are not a coder.

But you should be careful when reporting a bug. If they are repeated, incomplete, or are not really bug reports, they can annoy developers (and that's not what you want to do ;).

So, when hitting a problem, the first thing to do is to check if you have the latest version of the program; if not, update it and check if the bug still exists.

The next step is to verify if the problem is already reported. Some bug trackers, like Bugzilla, have excellent search features; others, like GNATS, are not so powerful. Anyway you should be able to find similar bugs easily, if they exist.

If the bug is not in the database, open a new bug report. Try to fill in as much information as possible. This includes: a complete description of the problem, a description of hardware and/or software that may be related to the problem (including version numbers, external patches, etc.), an explanation about how to reproduce the bug (non-reproducible bugs are very difficult to verify and fix) and, if you have enough knowledge, a suggested fix for the problem (in the form of a patch file, usually). Keep in mind that reports that lack information are (very) annoying.

If the bug is already in the database, just check if it's complete or not and add any (additional) information that may be missing. Do not open a new report for the same issue, please.

Another tip: do not use bug reports to propose new ideas; they are very difficult to handle. Try to discuss these in a mailing list first and, if people likes your proposal, then open a bug report. Also avoid using bug reports to ask questions; these should go to mailing lists too.

Start reporting easy and simple problems, but try to report everything you find. You'll only improve your style with practice ;) And doing this, you'll be helping a (free) software project!

For some examples, you can check my list of GNOME bugs. Or search my surname in the NetBSD Problem Database to check my bugs there (I can't add a direct link, so you'll have to do the search manually...). Have fun!

Connecting two networks

First of all, a bit of background. My home network is based on the old 10base2 connection. There is a server doing firewalling and NAT (among providing some services). There are also several workstations; mine has two NICs, one integrated in the motherboard, which only supports 10baseT (so I can't use it for my home network), and one plugged in a PCI slot. This network is class C, using 192.168.1.0/24 IPs.

Last week, I got an old Macintosh Performa 630. Fortunately, it has an integrated NIC, but only with a 10baseT connector, so I can't connect it to my home network (directly). The easiest solution I found is an UTP cross-over cable to connect the Mac to my workstation (plugged to the unused on-board NIC). I have configured this mini-network as a class C, using 192.168.2.0/24 IPs.

Everything fine so far, but I wanted the Mac to have access to the home network and also direct access to the Internet. My first thought was to set up a NAT service in my workstation, but I felt that it was not needed at all (as one has full control over class C networks).

Instead, I have gone through a more complex path (complex because I never did it before; now looks quite simple ;). The first step is to enable IP forwarding in the workstation, so that packets coming from vr0 (the on-board NIC, connected to the Mac) are redirected to ne0 (the PCI NIC, connected to the home network). Using NetBSD, the exact command is: sysctl -w net.inet.ip.forwarding=1.

With this in place, packets can go to other machines, but they don't know how to return responses. So the next step is to play with the routing tables. As I only need the server to "know" how to access the Mac (I don't care about all other PCs in the network... they are running Windows ;), I used the route command by hand, issuing: route add 192.168.2.0/24 dawn.local. This means: "to access the 192.168.2.0/24 subnet, send packets to the dawn.local machine", being dawn.local my workstation's name. I guess there are more elegant ways to achieve this, but this works for me.

The Mac now has full access to my workstation and the server (i.e., to the machine doing NAT for the Internet). But... I still had problems accessing the Internet itself. It took a while to figure out what was going on, but at last I found it: I was missing to add a new rule in the NAT table, to tell it to also translate packets coming from the 192.168.2.0/24 subnet. Adding the rule to ipnat.conf fixed this.

That's all! The Mac can now access both networks transparently. BTW, the instructions above are for a NetBSD system using IP Filter (the default firewall and NAT program). The steps required to achieve the same goals in a Linux box should be very similar.

Helping pkgsrc (through pkgsrc-wip)

I suggested you yesterday to contribute to a free software project. I know choosing one can be difficult, so this post is to give you a suggestion: help the pkgsrc project.

pkgsrc is The NetBSD Packages Collection. Despite its name, it works on many other operating systems, like Linux, Solaris or MacOS X, to name some. pkgsrc provides a package tree from where you can install any kind of program. It takes care to download the sources, configure and build them and install the results. It also handles all required dependencies.

To start using pkgsrc, you must get a copy of the package tree and learn how to use it. The pkgsrc manual contains all this information, and the website (linked above) provides a summary of what's needed to get started.

Assuming you already know the very basics of pkgsrc (just read the links to documentation), you can easily contribute to it. Different ways to help are providing new packages, updating the existing ones to the latest versions, reporting bugs (that you'll probably hit, specially when using it outside NetBSD) or becoming the maintainer of unmaintained packages.

Back in March 2003, Thomas Klausner (one of the core developers of pkgsrc) created pkgsrc-wip, a project targeted to new contributors (like you!) to make their life easier in providing new stuff and learning from other experienced developers. You can join this subproject (i.e., get a developer account) by just asking for it (follow the link for more information).

Anyway, before you try to do any patches or new packages, try to get familiar with pkgsrc and understand what's going on (as you should do when helping any project). Learning CVS is also a must, as it is used by both projects.

Keep in mind that maintaining packages is very addictive! I'm actually maintaining a big part of GNOME 2 in pkgsrc, so I know what I'm talking about ;-)

Getting involved in a free software project

It's now late June and, for many people (not me, yet), summer holidays are here. If you don't know what to do, or want an idea, here is it: join a free software project.

You'd ask: "Why?". I'd answer: "Why not?". There are many reasons. To mention some of them: to return something to the free software community; to learn and improve your general (coding) skills; to do something useful (depending on your POV); or simply put, to have fun!

So, start by choosing a project you would like to help. If nothing comes to mind, one of those you use daily are good candidates. Or one you'd like to be more mature but is fairly new (or abandoned!) and doesn't fit your needs. Think, think, think. It may take a while. (I may give you some ideas in further posts.)

Ok, project chosen. Now I listen: "But I'm not a coder...". Who said you must help by coding stuff? Of course code is (maybe) the most important part of a software project, but it's not all about it. A project needs documentation (in some cases, it's a must to have it in order to use some software), support (by helping other people in mailing lists), extensive testing (reporting any bugs you find), translation to other languages and, depending on the type of project, it may require artwork, audio samples, etc. You can surely fit in some of these groups, specially testing, which is very important (more on this on a further post).

OTOH, if you are a coder you can try to do other stuff. For example, implement that functionality the program is missing, debug and provide a patch for that annoying problem you often hit, or become the new maintainer of an obsoleted project (this last thing is a very good idea, instead of starting a new one from scratch).

Believe me when I said "to learn". Your knowledge about the project you choose will grow a lot, as you will see how it's organized internally, some design decisions taken in the past, help in future decisions... Furthermore, you will probably develop more generic techniques (useful in any project), like debugging programs, cooperating with other developers, improving your code quality, etc.

BTW, when the project accepts your first contribution... you'll be extremely happy, I'm sure. And that will make you want to contribute more. It's like an endless loop, so be sure to start it ;)

And at last, if you are wondering if all I've said is based on experiences or not, of course it is! For example, I became a NetBSD developer after helping during several months (and still contribute regularly). I submit many bug reports to the GNOME project. And I also drive my own projects, like Buildtool. I wish days were longer...

Welcome to my new journal!

Hi everybody! After thinking about it during some days, I've decided to start a new journal (AKA blog) after a failed attempt on November 2003 (which only lasted three posts, IIRC). I didn't know what to write in it, had almost no readers (obviously), and had few time at that moment to keep it growing.

At the moment, I've in mind several ideas of texts to write in this new blog... but they will not come all at once. I'd like to be able to post one every few days; just hope I have the time and don't get out of ideas soon.

Ah! And I have to think a title for it... names... I'm not good with them, so it may take a while.

BTW, this site (Livejournal.com) seems very complete to manage a (simple) weblog, even in the free version (the one I'm using). Compared to Blogger, this one lets you comment posts (while in Blogger you had to use external services) and does not have ads!

And if you are wondering why I'm writing in English instead of Spanish/Catalan (being my native languages)... well, I like English and it's fun to write in this language. Plus I may have a bigger audience ;)

Having said all this, have fun with further posts if you keep coming!