The True Power of Open Source

Something what’s considered to be one of the major strengths of open source, is that you can modify the source code to suit your needs. If something doesn’t work the way you want it to, you can change it. If you find a bug, you can fix it. Great huh?

This monday I’ve had two situations where I could experience this ultimate power. The first was when I wanted to install “Fedora Core 3”:, the Linux Distribution. The install went fine, but for some reason it didn’t recognise my network card. That was weird, it did work in Fedora Core 2… My network card always used the “tulip” module and with 2.4.x kernels it always worked fine (FC 3 uses a 2.6 kernel). After doing some research on Google, I found out that support for my card was also in the de4x5 module (or something, can’t really remember the name). So I loaded the module and my computer froze. The only thing I could do is reboot.

OK, we have two network card modules who should work, but one says it can’t find the network device and the other let’s the computer freeze. Open source to the rescue! Just download the kernel source code, find the right .c file. Fix the problem. Recompile and you’re set.

Yeah right. Have you ever seen what such a device driver looks like? It’s thousands of lines of code and all extremely low-level. I don’t know anything about hardware and, honestly, I’d like to keep it that way. Besides, debugging a kernel module that freezes up your computer is kind of hard, you know, because it freezes up your system every time you try something that didn’t fix the bug. For now I fixed the problem by one of the other strengths of open source: freedom of choice. I installed “Ubuntu Linux”:, which also comes with a 2.6.x kernel, but a different release, which, apparantly, doesn’t have that bug. Not that it worked right off the bat, but after some tweaking I got it to work.

Second example: I’m taking an embedded systems class at university. We have to write programs for a 8051 processor system. The main trouble with it is to fit the program that you have to write in its tiny winy memory. Or so you’d think… Because you can’t just run normal Windows or Linux executables on such a processor, you have to use a cross-compiler. For this course we use the amazing “SDCC”: See that URL? Yeah, it’s open source! I feel confident already. So, we wrote the program first on the PC to see if it compiled well and worked. It worked fine. Then we compiled it using SDCC, no problem, no errors, no warnings. Then we uploaded the program to the 8051 system through the parallel port. After that we started sending data to it and then the 8051 froze… After some investigation by the professor there seem to be bugs in SDCC. Who knew? We tried a newer (unstable) version, which appeared to be even worse. Even the pong game that we wrote for this system in a previous class didn’t work with that one. But luckily it’s open source. We can just get the code, fix the bug, recompile and go!

Yeah right. Don’t even get me started on this one. Compilers make device drivers look like “Hello world” programs. I didn’t even dare look at the source code of SDCC. This time we didn’t solve the problem by using another strength of open source. Nope, our professor now only demands that you show that the program works on the PC and fits into the memory of the 8051 system.

Just another day in open source paradise.