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
Linux has far too many varieties already, it makes mainstream hardware and software support almost impossible.
And they want to fork the only consistent bit ?
If they want to do a desktop version, it's time for the kernel developers to branch out into standardising Desktop libraries, desktops (KDE vs Gnome), devices, packages etc etc... so that we can have our 1000 versions of Linux and a single underlying version of Desktop Linux.
Maybe then, Linux may make a dent in the world of Desktop Windows.
EMail: 0110001101100010010000000110001101110010 0110000101111010011011100110000101110010 0010111001100011011011110110
I can sympathize with Mr. Barr; I remember when Linux natively ran on a 386SX with 16MB of RAM, and ran *well*. X? We don' need no steenkin' X! I think that, even if you stripped the current kernel to the bare bones, you'd have trouble running it in 16MB, it's been "spoiled" by too much cheap memory.
The less segregation in the Linux world the better, at least until desktop Linux is better at coping with new versions of the current kernel line (eg nVidia graphics drivers needing recompiling when a new version comes out and that sort of thing). Having different forks of the kernel would eventually also lead to software that can only be run on one fork without modification, and that's not much use either. The less work involved in porting to different distros/platforms, the better IMO.
which is totally what she said
fact, the kernel is the core, everything else sits on top, no matter what, server, desktop, etc. Linux is doing well in server, desktop, mobile devices because its consistently provided a powerful and (read this, microsoft bastards) functional operating system. I have friends with reasonably powerful laptops which choke on windows bile, become soperific and lethargic, unresponsive and surly (like the dwarf). I run X windows with fluxbox on some of our old servers fine. Splitting linux is pointless and counter productive. Viva la linux!
prepare the survey weasels.
The advantages gained in forking a kernel are minimal compared to the disadvantages. Not to mention a lot of those advantages of a fork can be obtained by simply compiling a kernel based on your server's hardware and computing needs. If someone forked it they would then have to maintain two separate code bases, two separate patch bases a new naming scheme. Not to mention the main advantage stated which is getting rid of bloat occurs because of compiled driver support which means that only a small subset of hardware would be supported in theory and most of the bloat he is speaking about comes from the GNU side of things and can easily NOT BE INSTALLED or un-installed if so necessary...
It makes sense for Linux to fork into two branches: one, a conservative one, aimed at upkeeping what already works, and the second, a wild-ass anarchist, aimed at forging new and innovative technologies.
That's what they used to have with odd-number versioning. Problem is that cross-merging kept happening and the whole thing turned into a mess. Seems like what they do now (I'm not a kernel developer) is to do mini-forks to work on the new technologies and merge it back in when it works well enough. Sounds like a good idea to me - I don't think it wise to have *all* the buggy stuff in one 'test' distro, because the last thing I want when trying to debug *my* buggy code is sharing a codebase with *everyone elses* buggy code. And it's not like all the 'test' stuff finishes at the same time, so either distribution gets delayed, certain features get rushed, or you just end up merging some stuff back into stable anyway.
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.
Wish I had mod points.
:))
People should just read this comment before saying anything.
(No, I will not resort to changing subject to MOD PARENT UP, because that annoyes me
Bot Assisted Blogging
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
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.
Certainly, but the over head comes from the 'on demand' loading approach. You could technically use a modular approach and then have all the modules loaded at the start to reduce over head. If understand rightly the extra overhead in Darwin would come from the fact the 'modules' are slightly more loosely bound, allowing them to work with most kernels, whereas linux generally requires a recompile.
Jumpstart the tartan drive.
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
I hear what you're saying, but the real question is whether or not the gain balances out the pain. Assuming, and that's a big assumption, that there's some improvement to be had, the question is: how much?
Let's assume that you fork the kernel, tweak it to meet "desktop users' needs", and find that your real world improvements offer no significant advantage? So what if you get an extra FPS in Quake? Would that really be worth all of that effort?
Personally, I think all of the effort on eking out the last iota of performance is misplaced. Personally I'd rather have a system with more internal checks and layers to ensure stability and to protect the kernel from hacks and attacks.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
I'm quite familiar with all the CFS vs. SD issues.
My point was that no forking or pluggable schedulers are necessary because all the important ideas, if not the actual code, from Con's SD (and more recently, Roman's RFS) have been incorporated into the mainline scheduler.
Forking would only be justified if the work done by the likes of Con and Roman wouldn't be accepted into the mainline kernel. Even though there code hasn't been merged, the kernel has undeniably benefitted from their design work (which is far more important than the actual implementation). Using pluggable schedulers would only be justified if the single scheduler were forced to incorporate some fundamental tradeoffs that weren't acceptable to all users. That obviously hasn't happened: CFS and SD are both better than the previous O(1) scheduler all-around. Neither scheduler sacrifices desktop performance for server performance, or vice versa.
nice isn't all that's required for good gaming performance, but right now, it's the only way to exceed the performance from the default CFS and SD.
As for your comments about clean code: Cleaner code will be easier to maintain and thus more secure. A unified server/desktop kernel will allow desktops to benefit from optimizations made with servers in mind. This happens all the time, as desktops are constantly catching up with the servers that went before them.
Imagine where Linux desktop performance would be today if it weren't for the decade of SMP development that preceded the arrival of dual-core desktop processors. Now, in retrospect, would you say that it was worth it, given that none of the SMP code ever slowed down your UP kernels?
I think the point of a pluggable scheduler would be so that *future* enhancements can be tested, benchmarked, tried out and deployed without either blessings from kernel devs or messy patches that need to be kept current between releases of the mainline. Is there no chance of a better scheduler than CFS coming along at all? The argument makes sense only if the pluggable scheduler causes excessive compuational or administrative overhead.
This space for rent.
You left out two(the last two are more specific versions of the first two) that didn't exist in high end machines 10 years ago but exist in the current ones. gigabyte sized OS? check massive applications? check bloated internet forcing bloated interface software? check bloated guis on everything? check Computers today are not much faster in many applications than computers 10 years ago just due to the waste created by bloated (easy to use/gui?) software.
The Steenkin Kernel.
Case in point: BSD vs SYS V. What sepereated these distrubtions was a design philosophy.
There was a call to fork the kernel, based upon the replacement of the scheduler, but that can be handled with differing defines. But until there is a compelling design philosoply, like GNU vs Linux, or even a liscencing issue such as Purity of Open Source, vs mixing some 3D binary drivers. Dont FORK WITH LINUX. Use the dessert spoon.
This idea for server/client is a *Marketing* Idea. You can already install a subset of the full Redhat distrubtion for use as a server or a client workstation OR a developer workstation, and as I remember it, also a database server. ( MySQL et al ), but its too bad that I *hate* the RP package system so much, that I am using GenToo.
My 3 cents