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.
Linux has no central repository, so the concept of forking linux is meaningless. Linus' branch is considered "official" because it historical and institutional reasons, not technical ones. Anyone can create their own branch and start incorporating patches, even pulling from others' branch. I believe this is exactly the reason why Linus switched to the new SCM system (Git).
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.
First, Linux is Linus' hobby that is kinda also a job. I've read somewhere where he said that he is more proud of Linux being on a digital picture frame that he bought his wife than having it on the top500 list.
Second, AFAIK, the kernel is fine for both desktop and server stuff. There are compile options to optimize for each, and patches, etc. Linux on the desktop is difficult because of a lacking standard and good software installation system and GUI environment and various other things. The kernel is fine for the desktop. There simply is not software on top of said kernel to make it desktop friendly.
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?
"A Lisp programmer knows the value of everything, but the cost of nothing." - Alan Perlis
It's already done. ALL THE TIME. Ubuntu, Redhat, Suse/Novell all maintain their own version of the base kernel. There is NO reason why some other person (or group) can't maintain his "desktop tuned" kernel. He would be wise to re-sync with the base kernel every now and then unless he wants to start maintaining all the drivers....
The objection is that maintaining the patch is a PITA. IMHO, it's a lot easier to just maintain a patch set than an entire kernel however, but FORK AWAY!
All this said and done, I have been using Linux as my primary desktop for the past 10 years. I have no issues with "jittery" video on my modest 3 year old desktop (a single core P4 2.4G, with 1G ram), even playing HD content. I guess I just don't understand the problem. It is certainly better than my "occasional use" Windows XP laptop, which is a new dual core, 2G ram box that can't reliably play a DVD without jitter.
A server is a relly different beast than a desktop
/proc/sys/*) or things like that.
No, it isn't IMO. It's all software that does the same things: open, read, mmap, copy, etc. Different software names, sure, and different workloads, but there's not so much difference. The kernel doesn't care if the process reading a file is apache or firefox, it just tries to read it fast. It's have been a long time since desktop was "stupid" software. Desktop software needs performance just as much as a server.
This (stupid) idea of splitting the kernel seems to come from people who thinks that the linux kernel is missing "optimization oportunities" from having a single kernel for all. Quite the contrary, i think we benefit from having it unified. Optimizations done to improve workloads for desktops usually _also_ benefit some server workload, and the reverse. And today's server hardware is tomorrow's desktop, so supporting well the servers means you work well tomorrow in the desktop. From the puristic design POV of many kernel hackers, they would tell you that a kernel that doesn't work for servers but does for desktops is broken and must be fixed. Of course, this is not always possible and there're also lots of config options to enable/disable particular functionality, but they aren't usually developed from the marketing POV of "this is for servers of desktops", but rather from a technological POV "when you run this workload, this feature improves the performance..." (like the sysctls at
Take for example, the real-time patchset. Other operative systems take real-time like something that only very few people dedicated to embedded devices use - they even don't care about it and leave that task to specialized real-time OSes. But in Linux, people developed a real-time patchset - they didn't though so much in what devices would use it, but rather in the technology. So, when the patchset was ready, Red Hat and Novell and others have launched server versions of a real-time. Now, those realtime server versions are happening to break latency records when serving transactions in Wall Street. This would have never happened if linux had different branches for embedded devices. In fact since most of the "other" operative systems are developed according to the needs of their company, and their company segments their way of working in "market segments", they've never though about trying to include realtime support in their operative systems.
So, please, let's leave "market segmentations" to red hat and novell, who can enable/disable extra features for specific market segments. Leave the kernel outside of that discussion, the kernel should only focus in technology. Me, as a geek, I might want to have a apache server being slashdotted and/or a FTP server running at the same time I play a 3D game. Just because the marketing teams think geeks are not worth of releasing a specific product optimized for me I shouldn't have good technology in my kernel to do whatever I want.
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.
#ifs are preprocessor directives. They are evaluated at compile-time and have absolutely no effect on efficiency when the kernel is running. Sorry, but you're going to have to look elsewhere for your "bloat".
Bogtha Bogtha Bogtha
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.
Hell yeah! I couldn't agree more. Not trying to start a distro flame, but that's why I love Gentoo. It's so easy to rip out stuff you don't need. I shouldn't even say rip out, it's more like build with out.
Shameless plug alert: Game server control panel
Optimized in current terms of Linux is really all about tuning it for its intended role - which can have a significant difference in performance. The scheduler has gotten a lot of attention lately. There is also preemption which is typically opposite when considering server and desktop roles. Aside from that there is the internal kernel 'clock' (that might be the wrong term, I can't recall right now). Generally on servers you would probably want a lower 'tick' so more work is done, while desktops would want a higher tick count - which I may be wrong but I believe this reduces latency and improves perceived responsiveness.
And as others have said you don't need different versions of Linux, just different compiled kernels you can select. Wow, that was a lot harder than forking Linux wasn't it? Slow news day?
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.
Think of the (Linus') Children!
There are approximately 2 kernel configuration changes required to switch from a throughput-optimized system to a latency-optimized system. They work. Any questions?
CONFIG_PREEMPT and CONFIG_HZ are pretty much all you need to worry about.
Roman wrote a poorly documented monolithic patch. Ingo requested that he split it into more manageable pieces isolating the various changes. Roman didn't, so Ingo did, crediting him in the description and on all the segments based on Roman's ideas. How is that wrong?
(On a side note, it was hardly a large patch. The bulk of it was removing dead code.)
and why shouldn't desktop users get that extra fps?
Ok, lets return to reality for a second here.
FPS games are SINGLE-THREADED! Thereby schedulers are meaningless. They do not perform disk-IO - they pre-load the entire level into memory; so tread-contention with the swapper/flusher daemons are not an issue. They use direct-to-video-frame-buffer operations, so socket calls to X are meaningless. They make very few system-calls (aside from the calls to video drivers).
If you consider that a scheduler will give you better FPS, then I think you should first determine that shutting down evolution, firefox (with CNN on auto-refresh) and spamd are going to give you better response rates. This is the exact same thing windows people have been doing for decades. There is also the concept of single-user-mode in Linux.
If we're talking a more responsive UI, here too we are not talking about heavy thread contention. The only real slowdown left these days are the multiple levels of file-system abstraction that you go through before hitting the disk. Or perhaps the selinux security checks.. Or things like that. X, itself is of course no performance deamon (due to it's network centric design), but you can't change X without breaking X-compatibility - basically it would be something else entirely.
These layers of abstraction do detract from performance, but that's not really what's being discussed here.. You can run ext2 instead of ext3, or reiserfs (don't know how fast you can get it). You can run stripped RAID. Hell, you can twm instead of gnome... Or.. You can spend an extra $200 on beefier memory + CPU on a desktop (sadly not as fortune on a laptop - get jipped $500 to upgrade the CPU there).
-Michael