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
I can not see why is it a stupid idea. Forking the Kernel in desktop and server forks will mean that each specific kernel is optimized for such tasks and that the distribution makers have just a subset of the huge kernel to care about when creating their distributions.
A server is a relly different beast than a desktop and having this "all-in-one" kernel means that the operating system gets bloated with a) desktop specific features when using a server and b) Server specific features when installing a desktop.
I think that a controlled fork in the linux version control tree might be beneficial.
Ubuntu is an African word meaning 'I can't configure Debian'
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.
Why is this even controversial? If you don't like the way things work, the beauty of open source is that you can fork the code at any point. So...quit whining ("prings"?) and good luck with your fork.
Shrug. Let 'em fork it. I doubt they'll be able to swing enough maintainers to seriously effect development on the main fork.
One of the great strengths of open source is that it allows for competing code. If the new fork is better (I view this as unlikely) then I'll switch. I'm about what works.
When the level of discourse falls to articles of faith and prejudice, it's not about what's best for the code anymore. It's about your personal ideology, y
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
# Forking isn't necessary.
options BIGIRON
#options DESKTOP
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.
The linux kernel already does this, with modules that can be loaded and unloaded at runtime. Whole subsystems (things like SCSI and DRI) can be loaded on demand. You can also enable or disable kernel preemption at compile time, and you can swap out I/O schedulers at run-time.
However, the modular approach can have some overhead of its own (though not as much on linux as on darwin). If you really need a small kernel, you can actually disable loadable module support at compile-time, if you know exactly which drivers you need.
Slow, scalable algorithms are used rather than lean but limited ones.
If this is true it is actually a good idea. Today's personal computers have a lot in common with high end machines from 10 years ago.
Multiple processors? Check.
Gigabytes of RAM? Check.
Harddisks with hundreds of Gigabytes? Check.
And I guess the trend will continue, so what belongs in the big iron of today will be fine for tomorrow's personal computers.
C - the footgun of programming languages
Sure, linux kernel modules don't have any significant execution speed overhead, wheras darwin does because of excess context switches. The overhead I was referring to on linux was just that a modular kernel (with all the modules loaded) can take up more memory. If you know you will always need all your drivers (usually for server and embedded workloads), compiling in everything and leaving out loadable module support can cut down on your RAM usage (though this typically only matters for embedded systems).
Slashdot and linux.com are owned by the same company. Joe Barr submitted the slashdot article and also wrote the rebuttal blog. He can look smart and double the ad revenue all in one story.
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
what's the pain really? business will continue as usual on LKML etc., there will just be a separate tree handled by somebody interested in this which will accept 'desktop patches' and will also integrate most, if not all, of the mainline patches.
and why shouldn't desktop users get that extra fps? desktop users couldn't care less that getting an extra fps in quake will lower some Oracle benchmark by 50%. Also what if, by really messing things up for databases or network loads and by hardcoding specific scheduler behaviour for the X binary, you could make xorg 50% more responsive? No way this would go in a mainstream kernel, but I bet a lot of users would run this quite happily if they could.
I am sure there are people that feel the same way you do, maybe you could consider a fork yourself?
-- the cake is a lie