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."
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
Actually a lot of forks do exist and are supported. There are all kind of real-time and low-latency and security patches floating around that get a lot of attention. Most big vendors do not ship a exact copy of the version that linus creates, but add some patches/modules that they think their actual users need.
One time they may be get merged into the main linux kernel, or maybe their features are obsoleed by features that are accepted by linus.
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.
Karma Whoring for Fun and Profit.
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?
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 .
This space for rent.
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.
The best way to accelerate a windows server is by 9.81 m/s2
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.
The question is not whether you can fork the kernel, the question is whether you should. On one side, you have hope that this would revive progress in desktop Linux. On the other, you have fear that this would create conflict and duplication of effort.
My answer? It just doesn't matter. Yes, desktop Linux is being neglected. But it's not because LT has developed a Big Iron fetish. It's because Open Source development, despite what people like to think, is subject to economic pressure.
OS evolved out of "Free Software", which is based on the quaint notion that software development is totally divorced from economics. Yeah yeah, I know about the beer/freedom dichotomy. It's BS. "Free" software has never been about anything but RMS throwing a tantrum over the fact that AT&T starting making people pay for Unix licenses. So he set out to write a "free" OS. Which, 20 years later, he still hasn't finished!
On the other hand, the anarchistic/fascist development model behind "Free" software (anybody can hack the source code, but the direction of a project is totally controlled by a small cadre not answerable to the other developers) turns out to be a pretty good way to develop non-proprietary software. Before, when a bunch of companies wanted to do this, they'd form a committee. After endless wrangling and compromise, the committee would produce a spec or standard that was usually feature-bloated, hard to implement, and basically satisfied no one. With the new model, somebody (like Linus Torvalds) with a vision for a new software product just sits down and starts coding. If the product turns out to be useful, people start contributing to it, and the product grows. Because LT chooses to listen to his contributers, but isn't compelled to accept their ideas, the product grows organically, responsive to user needs. Thus Open Source Software was invented.
But isn't that just the same as Free Software? No it's not. Because the OSS movement acknowledges that not all programmers can get by on grant money. Most Open Source code is written by programmers who are paid to do it. Who pays them? Companies that have a use the new feature or fix being coded, and find it in their own best interest to donate the new code to the OSS community.
That's why so much Linux kernel development is driven by the needs of Big Iron manufacturers (like the company I work for). They love Linux because it's a de-facto standard. And because it's not a real standard, it lacks the compromises and feature bloat of committee-driven software. It helps them sell hardware, and its in their interest to have their in-house programmers make improvements to it. But of course, those programmers are only going to make improvements that their employers actually need.
TFA cites Con Kolivas's retirement from kernel work as a sign that desktop Linux isn't healthy. But in fact the bad sign was that Con Kolivas was ever the leading hacker for desktop kernel features. Because nobody ever paid him for his work on the kernel. Indeed, he's not even a working programmer! He's a medical doctor who programs as a hobby.
That pretty much sums up the status of desktop Linux: it still belongs to hobbyists at a time when server-side Linux is an important commercial product. Unless and until you can change that, it doesn't matter who controls Linux kernel development: the needs of Big Iron will prevail.
See subject.
The linux development model is built on forking anyway.
Trying to fork linux is like trying to burn fire.
Con Kolivas had been shouting from rooftops about slow desktop performance and was submitting feedback and bug reports. One of the kernel devs apparently said "I do not notice the issue on my quadcore machine with 4GB RAM". Rightly or wrongly, this lead Con to believe that the kernel devs do not care about desktop performance and only give priority to issues that big corporates complain about.
In the true open source style, he took upon himself to learn kernel programming and released a whole set of -CK patches and various versions of benchmarking tools and schedulers. On the other side, Ingo Molnar was the maintainer of the scheduler portion of the kernel and maintained that the O(1) scheduler(and the one before it?) is good enough and has no problems. Con conclusively started proving this wrong with his benchmarks. At this point, everyone assumed the -CK branch would be merged into the kernel at some point and Linus says he had been considering it.
At some point, Ingo starts making his own scheduler, which later evolved into the Completely Fair Scheduler. A number of posts claim that it was kind of rip off of the ideas behind Con's scheduler with which it was in a race to get included in the kernel. Then Linus decides to include CFS into the kernel instead of Con's scheduler. The reason he gave was that Con thought SD was perfect and that he ignored and flamed the users on the CK mailing list and that he(Linus) was far more comfortable working with Ingo since he knew him well. He also admitted that he might have formed this opinion on a single incident on the mailing list and he didn't have the time to follow the CK mailing list.
Some people on Con's side in the LKML tried to explain this by saying that the single incident was in response to a troll who submitted faulty bug reports and ignored the reasons for why they were rejected and that Linus was playing favorites. Con couldn't take the non-inclusion of -CK and plugsched(which would have given users a clean way of using a custom scheduler) and quit kernel development totally.
The latest twist in the story was reported on Slashdot here . The gist of it was that another hacker(Roman Zippel) was trying work on CFS. He had asked questions about what some parts of the code did, and also made some patches that considerably simplified the code and mathematically proved his patches made things better. In response, Ingo came out with a big patch that ripped out the code that was questioned and included Roman's Zippel's ideas(another rip off?) with hardly any discussion and a tangential acknowledgement of including his changes. Roman complained that talking in patches without explanation is detrimental to collaborative OSS development.
This space for rent.
CONFIG_PREEMPT and CONFIG_HZ are pretty much all you need to worry about.