Slashdot Mirror
Fork the Linux Kernel?
Joe Barr writes "Fork the kernel? Are you crazy? A blog entry on InfoWorld.com urged the Linux community to fork the kernel into desktop and server versions because, according to the author, all Linus Torvalds cares about is big iron. Sorry, but that's both wrong and stupid."
If you want to fork the Linux Kernel, there's absolutely nothing from stopping you from doing it yourself. Wanna tune a version just for Desktop or Server? By all means, just adhere to GPL. Your attempt at forking might even get some support from the community, however I'd think Linus's blessing on such a fork means something however...
...in bed
It's a blog post, so it's not like it's going to happen, but I don't see how forking the kernel would do anything than just lead to distribution craziness. Arguably that's Linux's biggest hurdle for new people -- deciding which distribution to get. And if people are checking out linux for workload purposes, forcing them to decide whether to get a server distro or a home distro and making that distinction at the kernel level? Buh?
Generally, if it's good enough for enterprise, it's good enough for home use. And things that are useful for desktop Linux are often utilized at the enterprise level anyway. So yeah, it's just a blog post; I'm not sure anyone will take it seriously.
# Forking isn't necessary.
options BIGIRON
#options DESKTOP
Because the distinction between server and desktop is rather fuzzy these days. What could you leave out of the desktop OS?
RAID? Doubtful with it being so affordable these days.
ECC RAM? That can be had on many boards as well.
Support for SCSI tape drives? Does my box suddenly turn into a server if I get a cheap drive on ebay?
Ok, how about say, optimizing the desktop version for latency and the server version for throughput? Problem with that is that there exist server tasks that want low latency.
Years ago you'd say "remove SMP support, nobody uses that". Not so these days.
What could you leave out of the server?
Support for sound cards? What if it's a server that records audio?
Support for video cards? What if the server uses it for computation (rare but possible)
Okay, so somebody made a stupid blog post. Why submit it to Slashdot?
Bogtha Bogtha Bogtha
You could have made the same argument against including SMP a few years ago. And look, now ~90% of PCs (thats personal computers, for you me grandma and the king of Tahiti) have multiple processors. We don't know the direction computers are going to take in the future, but a lot of previous high end server stuff has trickled down into the consumer level hardware.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Have you got any examples where there is significant overhead that can't be removed with a make config but could be removed with a specific, less scalable algorithm that isn't available in the kernel source?
I'm pretty sure your comment is mostly BS. The vanilla kernel source includes a lot of configuration options for embedded systems. Low on RAM? Turn off CONFIG_BASE_FULL to use several smaller, slower data structures. Don't have swap space? Turn off things like CONFIG_SHMEM. Using uClibc? For now, you might as well throw out CONFIG_FUTEX as well.
Which algorithms are bottlenecking your desktop? Is it the I/O scheduler? You can swap between one of four choices, at runtime.
Is it the CPU scheduler? If so, you're a liar. Nobody had produced repeatable benchmarks that show a significant shortcoming in CFS for desktop and gaming use.
Is the memory allocator really bad for your workload? Try using the new SLUB allocator, instead of the older SLAB allocator.
Is the system not as responsive as you want? Turn on forced preemption and set the tick speed to 1000Hz.
Yes, you are correct, but you're missing the point. The Linux kernel is made to provide maximum throughput at the expense of responsiveness. Throughput is great for a server, responsiveness is great for a desktop. There is a trade-off.
They call me the wookie man, I guess that's what I am
meaningful according to whom? and desktop users couldn't care less about 'hard coded nice levels' if it means their 3d games and/or X apps work better: yes, I know this is anathema to the linux developers where only super perfect code supposedly should go in, however if this supposedly super perfect code doesn't meet desktop users' needs as well as hacks, well, I'd all be for giving desktop users as many hacks as they want/need (as long as this could be changed via either a pluggable architecture or a difference in make config).
As much as Linus has done a great job into making linux a great server side OS, if he's not willing to make compromises to make the desktop faster (because either it's too 'hacky' or it will cause issues for big iron, which is what pays the devs' bills) maybe it IS time to fork under the stewardship of somebody with the desktop users' needs more at heart. If companies like, say, NVIDIA or Adobe paid a kernel developer to make linux better on the desktop this is what would probably happen IMHO.
I don't think a fork would be the end of the world, fork it and let the best survive: if a year from now we have a 'server linux' and a 'desktop linux' kernels, so be it, if instead the 'desktop linux' project flounders due to minimal speed improvements and so on, well, so be it as well. The vast majority of the patches/changes would apply to both the same way, so I don't see this causing issues and slowing development, if at all maybe people could spend less time flaming on LKML and more time writing code.
-- the cake is a lie