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."

Well that's the beauty of Linux...

[tekiegreg (674773)]

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...

Re:Well that's the beauty of Linux...

[MightyMartian (840721)]

Or, alternatively, you could just custom compile the fucking thing to take out the "big iron" if that's what you want. I frequently custom compile kernels, particularly when I'm putting Linux on older hardware.

There's nothing quite like the grand proclamations of the idiots.

Re:No you can not

[644bd346996 (1012333)]

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.

Re:No you can not

[recoiledsnake (879048)]

Your examples totally miss the point. The CPU scheduler is a *lot* more crucial to desktop performance than swap space, memory config etc. etc.

Have you even been keeping up with the whole CPU scheduler in the kernel issue that the article mentions?

The whole point is that the CPU scheduler is NOT modular and you cannot change its behavior by much by changing kernel options. Con(along with soemone else) made patches to make it modular, calling it plugsched, but it was nixed from getting into the kernel by Linus who said something on the lines of "The scheduler is not something you see frequent changes in."

Con wanted it because desktop users can easily plug his desktop-centric scheduler into the kernel. For a lot more details read here [apcmag.com].

Re:No you can not

[644bd346996 (1012333)]

You're missing the point. A pluggable scheduler is not necessary for desktop usage, because nobody (not even Con) has been able to come up with a scheduler that is significantly better than CFS for desktop usage, except by doing things that amount to hard-coded nice levels. All of the meaningful performance improvements have made it into the default scheduler.

Re:No you can not

[MarcoAtWork (28889)]

except by doing things that amount to hard-coded nice levels. All of the meaningful performance

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.

Re:No you can not

[Lumpy (12016)]

Really? I better tell the guys down in R&D that the 1.2 meg linux install we use on the embedded box devices does not exist and cant work.

Thanks for letting us know before shipping this thing it would have been embarassing that the linux would explode and become huge upon use.

Re:No you can not

[Braino420 (896819)]

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.

Re:Well that's the beauty of Linux...

[MightyMartian (840721)]

Can you, or this blogger, or anyone, site some actual evidence that shows what the fuck "optimized" even means? You know, you guys go around spouting stuff about how Linux is too serveresque, but no one so far as I've seen has even defined that. A decade ago there might have been something to the complaint, although I can tell you now that I can take a Pentium 233mhz and turn it into a router running the newer kernels, and have it run like a hot damn, so I think you, like some other folks, are just spouting ill-conceived crapola.

Meh

[paullb (904941)]

I'd rather spoon it

Re:Meh

[Archangel Michael (180766)]

Me, I'm gonna spoon the fork. I'm gonna SPORK it. :-D

Fork?

[EggyToast (858951)]

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.

Keep the code together; make it configurable

[Kartoffel (30238)]

# Forking isn't necessary.

options BIGIRON
#options DESKTOP

Re:Keep the code together; make it configurable

[pohl (872)]

At the moment I'm making this post, the parent post has been moderated "Interesting". I think "Insightful" or "Informative" would be more appropriate.

What the parent poster is saying is that C pre-processor [wikipedia.org] flags already allow the same kernel source code to contain features for both server and desktop without resulting in any bloat or compromise in the resulting binary.

Only those who don't understand C would fret about a "bloated" kernel in this context.

Now given a binary kernel that contains both feature sets you would have a legitimate concern, because then there would certainly be a bevy of both bloat and compromises. But this is linux, after all. We have the source code -- so none of that matters.

One size rarely fits all

[Creamsickle (792801)]

People who advocate this aren't necessarily stupid, just ignorant. The Linux kernel's flexibility is being taken to the limit, and people are forgetting the easiest way to improve performance for their particular rig: Customize your kernel! You can add all the code in the universe, and then you pick and choose the particular things you need or don't need! Say I run a 486/25 with 16 MB RAM as an IP Masq router. The hard drive is an old IDE with 600 megs of space. I have two network cards, and that's about it. Do I need SCSI support? Do I need to support joysticks, X, Pentiums, AX.25, or anything else? No! I compile a kernel specifically to run the IP Masq, and run it well. My P100 laptop, on the other hand needs a bit more. I use it for packet, so I need AX.25. It uses PCMCIA, so PCMCIA support needs to go in. I use Seamonkey and the GIMP, so I need graphics. But, my HD is not SCSI. I yank out SCSI. My CPU is subject to the 0xf00f bug, so that gets included. I brew a custom kernel, and boot time is a lot shorter. My big-rig is a AMD X2. I need just about everything, as I have a Nvidia card for Quake4; a SCSI scanner; and a connection to my Packet base station. I optimize compilation for the higher-end computers. I plan on getting a Mac Pro from Apple and putting SuSE on it. Again, by optimizing the options I optimize my system. Get the point? If you want a once-size-fits-all kernel, use Windows. If you want a kernel which can be adjusted for your particular and peculiar environment, use Linux and customize your kernel!

I don't see the need

[downix (84795)]

The only difference between a "server" build and a "desktop" build, kernel-wise, is in which components/modules you compile. Functionally, there is no difference. Same goes for Windows, the "desktop" and "server" kernels are fundimentally the same, it is only what you put on top of them that differentiates the two.

Someone here does not understand the difference between a kernel and an OS.

I saw it on an Internet blog!

[n6kuy (172098)]

It's probably a serious concern!

Why isn't this front page news everywhere?

[Minwee (522556)]

What's this? Someone with a blog pulled a half-baked idea out of his butt, and then posted it where the entire Internet could see it? And some other people don't agree with him?

That's amazing! An event of this magnitude only happens once in a billion femtoseconds! Why aren't we all paying more attention to this incredible discovery?

So why the attention?

[Bogtha (906264)]

Okay, so somebody made a stupid blog post. Why submit it to Slashdot?

Re:Why is it stupid?

[Gordonjcp (186804)]

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.

Perhaps the source code does, but there's nothing stopping you from leaving out all the server-specific stuff from your desktop kernel when you compile it. If you're producing a server-grade OS, leave off the desktoppy stuff. Simple.

Re:Why is it stupid?

[644bd346996 (1012333)]

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.

Re:Why is it stupid?

[DaleGlass (1068434)]

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)

The Linux Desktop already crawls..

[vdboor (827057)]

Call me stupid, but the Linux desktop already crawls.

There used to be a time I could download 5 shared files, burn a CD and watch a DivX movie at the same time. That was with Slackware 9.0 and Linux 2.4.20.

Nowadays it takes my browser 2 seconds to open a *tab*, and another 2 seconds per website. This happened because there was continuous I/O activity in the background. After the I/O completed everything was back to normal. Bottom line: every serious I/O activity causes the desktop to crawl.

It's still the same machine (AMD 1800 and DMA-enabled) but interactivity my Linux system had is unmatched by the recent kernels. The problem is too many commercial developers care about server performance alone, or test desktop performance with their quad-core raid array configuration. Patches get rejected too when they affect server performance.

I'm honestly not surprised people want a change here, or even start suggesting a fork.

Re:memories...

[Koiu Lpoi (632570)]

Uh, you know that it still does? You just have to pick and choose what you want. If Linux doesn't run in 16 MB of Ram, how do people get it running on things like the Nintendo DS with a whopping 4 MB?

What about SMP?

[Bill, Shooter of Bul (629286)]

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.