User: Password:
|
|
Subscribe / Log in / New account

Avoiding the OS abstraction trap

Avoiding the OS abstraction trap

Posted Aug 18, 2011 9:27 UTC (Thu) by Np237 (subscriber, #69585)
In reply to: Avoiding the OS abstraction trap by dmag
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. The very reason for requiring so much people is that the current model IS the burden. Every time you rewrite the SATA stack or the USB one, it involves an insane amount of work to update every single driver.

1 year is too long in your book? Sorry, but that’s nice of you for living in a pure-developer world where you can break everything every 2 weeks. There’s also a world out there where computers need to just work, and to do the same thing for decades.


(Log in to post comments)

Avoiding the OS abstraction trap

Posted Aug 18, 2011 9:56 UTC (Thu) by dmag (guest, #17775) [Link]

> To claim that the current kernel development model means less resources is a fallacy.

Well, I guess I (and the kernel developers) agree to disagree.

> Compared to other open source projects of similar size (KDE, GNOME, Mozilla, LibreOffice)

It's not news that an Operating System Kernel requires more work than a Word Processor or a Browser. Want to bet that Linux supports more CPU architectures than your Word Processor supports file formats?

> Every time you rewrite the SATA stack or the USB one, it involves an insane amount of work to update every single driver.

Heh. It only looks that way on TV. Real programmers write programs to do the programming for them.

http://lwn.net/Articles/315686/

> There’s also a world out there where computers need to just work and to do the same thing for decades.

Exactly. That's the job of the distributors. They fork the kernel and support it for as long as people will pay for it.

Avoiding the OS abstraction trap

Posted Aug 25, 2011 0:25 UTC (Thu) by chip (subscriber, #8258) [Link]

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.

kloc

Posted Aug 25, 2011 0:31 UTC (Thu) by chip (subscriber, #8258) [Link]

Let us also consider the possibility that more effort per kloc means they're working harder to make better code.

Writing big code is easy! Writing small yet good code is much harder.

kloc

Posted Aug 25, 2011 4:41 UTC (Thu) by dlang (subscriber, #313) [Link]

when was the last time anyone found a million lines of dead code in the kernel (like what was removed by libreoffice from the openoffice.org codebase)

how many of the 'easy' office suites that existed 10-20 years ago are still in use today?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds