Avoiding the OS abstraction trap
Posted Aug 25, 2011 0:25 UTC (Thu) by chip
In reply to: Avoiding the OS abstraction trap
Parent article: Avoiding the OS abstraction trap
To claim that the current kernel development model means less resources is a fallacy. Compared to other open source projects of similar size (KDE, GNOME, Mozilla, LibreOffice), the Linux kernel involves around 10 times more developers per kloc.
I don't know if that statistic is correct, but if it is, I'd attribute that to the difficulty of developing a kernel vs. developing an application. I've done both, at least a bit -- I identified and fixed an SMP-specific dentry race condition in NFS, and wrote the boot-time DHCP support -- so I'm not just guessing.
From The Tao of Programming, 3.3:
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer, "when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
The programmer made no reply.
to post comments)