This blog is about technology, programming, video games, books and other related topics. It is published by Mark Papadakis.

Linux Kernel Development ( book )

I am currently reading Linux Kernel Development, by Robert Love. This book serves as a great introduction ( it actual aims to become the canonical reference for intrepid kernel hackers ) to some fundamental operating system concepts (or, rather, kernel concepts ) and goes into great length describing how the Kernel ( version 2.6 ) is structured and how the various subsystems work.

For instance, the 2.6 process scheduler is a marvel of engineering. Extremely simple and extremely efficient. It reminds me of a similar solution I had to come up with, for one of our services, but mine wasn't near as elegant, really.
I have only read a couple of pages thus far, but everything makes sense. The linux kernel hackers are aiming for simple(=clean), elegant and efficient solutions, the kind of solutions that yield the best possible performance because they are kept simple and are extremely optimized. Its just sad that the quality of the majority of the surrounding applications running in user-space ( desktop managers, open source applications.. ) do not follow this route. If there was a desktop manager ( say, Gnome ) that would have been as well thought of and well build as the underlying OS kernel, Linux would have been a champion that would drive fear to Microsoft and friends.

The Microsoft engineers should do the 'right' ( which is essence is wrong, of course) thing. Study the Linux Kernel source code and rebuild the Vista kernel by following the algorithms and design decisions found in the Linux Kernel. While they are at it, they should make sure to stay away from the concept of microkernels - even if the microkernel servers exist in kernel space ( which invalidates the whole idea behind microkernls anyway ), as it is the case with Windows, its a BAD thing to do. Performance matters. Perhaps, then, Windows would be at least an order of magnitude faster and wouldn't require so much iron ( pumped up hardware requirements ) to run.

Friday, 13 October 2006 7:22 pm

Linux

Linux on Wikipedia:

More Than a Gigabuck: Estimating GNU/Linux's Size, a 2001 study of Red Hat Linux 7.1, found that this distribution contained 30 million source lines of code.[10] Using the Constructive Cost Model, the study estimated that this distribution required about eight thousand man-years of development time. According to the study, if all this software had been developed by conventional proprietary means, it would have cost about 1.08 billion dollars (year 2000 U.S. dollars) to develop in the United States.
In a later study, Counting potatoes: The size of Debian 2.2, the same analysis was performed for Debian GNU/Linux version 2.2.[11] This distribution contained over fifty-five million source lines of code, and the study estimated that it would have cost 1.9 billion dollars (year 2000 U.S. dollars) to develop by conventional means.

Also worth noting is that Playstation 3 will run Linux by default. According to the GPL License Sony will be obliged to release the source code to whatever modifications they have made for their custom (presumably) linux kernel. That will be an interesting point in time.

Thursday, 5 October 2006 1:41 am

Linux Kernel Hacking

After spending a few days looking for ways to building a filesystem (actually, on hooking it on the Linux vnode layer ), which we are going to need sooner or later for NFS clearly doesn't work very well for us nowadays, I had the chance to read about linux kernel internals, kernel modules development, device drivers and more - related to the Linux development process.

It certainly isn't really that hard to understand most things, once you spend sometime reading about it and experimenting with 'playground code'. I am actually thinking about contributing to the linux kernel development soon - whether my patches + ideas will be accepted, that's another story altogether, though. I tracked down two great books on the subject and once I get them and study them, I am going to go for it. Having Parallels on my MacBook Pro is a blessing; I have a virtual machine running Ubuntu Linux. Messing with the kernel can get me a kernel crash, resolved as easily as copying a backup VM data file over to the 'corrupt' VM data file and restarting the virtual machine, while I am having a great time on Mac OS X. The merits of hypervisor technology are truly great.

Tuesday, 3 October 2006 10:05 pm