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'd rather spoon it
Why not? It made Microsoft plenty of money...err
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.
Besides, most people's desktops are much more powerful than any server you'd be able to buy years ago. With the cost of cheap disks going down, there's no excuse for even home users to ignore the benfits of such "server" features as raid.
Kevin Smith on Prince
Actually, its been done before. Remember when we had a "stable" and an "unstable" pair? IMHO the idea of forking into desktop and server versions is a technical answer to a political problem with various developer's goals.
C|N>K
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.
Cause linux obviously doesn't care about ANYTHING, let alone big iron.
A different branch of distros for the desktop makes sense, but I'm not sure the kernel is what needs addressing.
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.
I think what the original author was saying was that he/she would like the Linux community to fork into two branches, one thinking like desktop software (Windows XP is the best example) and another thinking like big iron, where Linux already has a presence but could learn a thing or two from *BSD.
technical writing / development
There is no need to fork Linux into a "desktop" version. Projects like Syllable already exist, and we re-use a fair amount of code from Linux, GNU and other OSS projects.
Syllable : It's an Operating System
Wow, nothing like pulling a quote from 4 years ago to make your point. Most acknowledge Linus's shift in thinking with version 2.6 of the kernel, a project that only started releasing stable builds in December of 2003.
Let's not be so concerned with the politics of the matter though; Version 2.6 of Linux hasn't made a priority of remaining small, but at the same time must be patched to have drivers for most systems. If someone wants to start a more desktop centric fork, I won't be stopping them. This will make a kernel packagers job a lot easier, and probably result in more stable final builds.
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.
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!
On the 0th day, God created C
I sure do wish people would stop submitting their own blog postings to Slashdot. What is this, Digg? I guess next time I want some serious traffic to my message forum, I'll post about some technical issue and pump it into the Firehose.
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...
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.
I think that right now the majority of development at the kernel level is server based. It is only logical after all since the majority of paying Linux systems are servers. When I mean paying I mean paying their way. The technical question is can one scheduler work well for both server loads and desktop loads. Is there an ideal scheduler that works every where? We know that isn't true when you are dealing with real-time systems so is it true for the desktop?
I don't think this is a dumb question I just happen to think that currently there isn't a need to fork the kernel.
I happen to think that currently there isn't really a need to fork the Kernel into a server and desktop version. I feel that most of the performance problems with Linux on the desktop are in X and not in the kernel. I think more work needs to be done in X to solve the problem than the Kernel.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I've generally found "Wrong and stupid" goes hand in hand with blogs. The easier it is to be heard, the lower the signal to noise ratio is going to get. It'd be nice if we could just taser them but perhaps unconstitutional. :D
Relevant quote: "Don't taser me! Ow! Ow! Ow!" - opportunistic journalist at Democratic National Convention
Maybe in a virtual machine or sandboxing situation this would make sense, but for general practice forking an entire kernel makes little sense, unless you want to make Linux as efficient as Vista. Interactive processes would really get bogged down with all that overhead.
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.
[tumbleweed]
I'll get my coat.
throw new NoSignatureException();
What "bloat" feature can you not disable with configuration?
I think that says it all. Of course, we'd have to wait until Randall replies to these accusations.
It's probably a serious concern!
If you disagree with me on social issues, then it's pretty clear that you are a narrow-minded bigot.
I can not see why is it a stupid idea.
Me neither, especially considering that's all the frothy-mouthed zealots tell you to do when you criticize the kernel developers.
Linux user: I like Linux but I think the kernel should incorporate feature X.
Linux zealot: If you don't like it, fork the kernel!
Linux user: I think the kernel developers aren't open enough to contributions.
Linux zealot: If you don't like it, fork the kernel!
Linux user: I think the kernel is too focused on big iron.
Linux zealot: If you don't like it, fork the kernel!
Linux user: Ok, I guess I'll fork the kernel then.
Linux zealot: OMG YOU CAN'T FORK THE KERNEL!!!
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?
Putting a bunch of #if 0's into complex, bloated code doesn't make it slim and efficient. Statements elsewhere still make assumptions about one of 1000 things happening rather than one in 10. Slow, scalable algorithms are used rather than lean but limited ones. make config is not going to turn your Linux into FreeDOS.
If I understand correctly, that's exactly what Ubuntu does with their "desktop" and "server" version. The desktop version have certain modules and patches that the server versions do not, and vice versa.
We all know what to do, but we don't know how to get re-elected once we have done it
Really, the distro should do the fork, and they actually do. While most have general compiled kernels, others have kernels compiled based on what is desired; server or desktop. Solves the issue.
I prefer the "u" in honour as it seems to be missing these days.
Okay, so somebody made a stupid blog post. Why submit it to Slashdot?
Bogtha Bogtha Bogtha
With Linux you can fork the Kernel, but without it, another OS might fork the user.
We also need a Linux kernel for gaming and a Linux kernel for running Wine.
Desktop users can stick to Windows.
These guys can't even keep a print version going. Wonder why? It's ok to ignore blogs where the author is both 1) clueless and 2) probably never compiled a kernel in his entire life. Nothing to see here.
---- Teach Peace. It's Cheaper Than War.
Go yourself a favor and wath "the italian man who went to malta" on youtube.
"I went to have dinner, and there was no fock on the table. I called the waitress and said - I wanna fock"
how long until
Con and Ingo are just continuing the bitch session about the scheduler.
"They" don't agree with the new scheduler; face it this is where most of the divide is; so "they" want their own version but they know damn well that unless they have Linus's blessing its dead in the water. As such expect attempts to guilt him. As such see attempts to deflect attention from their real peeve by suggesting 'multiples' instead of just their way and his way.
Arrogant from the standpoint that since they can't have their way and cannot get support for their own on their own they want Linus to do that for them. If 'they' are so right then 'they' will win out in the end. Regardless its their Linux and they will have to name it something people will cleary understand is not Linus
* Winners compare their achievements to their goals, losers compare theirs to that of others.
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.
You really need to read up compiling the Linux kernel from sources. You can choose EVERYTHING about how your kernel is compiled. My kernel ONLY has drivers and support for the hardware I need to use and it has tweaks and settings configured for optimal desktop performance. If I was running a server on special hardware and with special high performance server needs, I'd compile it with different settings.
And before you (and clueless journalists and column writers) start spreading more uneducated myths, how about you read some lkml and previous slashdot threads for the full reasoning behind the scheduler decision. Here is a clue: Linus has said multiple times that one of the reasons the Linux kernel is such a success is that the same code is used on everything from supercomputers to embedded microcontrollers. In hacking the kernel to provide more network performance on a 10 gigabit datacenter network, those patches also improve the networking performance on small 10 megabit network within a tiny microcontroller. Reducing the size of the kernel for an embedded microcontroller also reduces the size of the kernel on high performance servers. Because the same source code in the kernel is used so widely, it is tested beyond the extremes more than any other piece of software in existence. This is just one reason of many that Linux kernel developers will give you as a reason why forking/splitting the kernel is a seriously bad idea.
Comment removed based on user account deletion
Lackies? lackeys? not sure what the spelling of that is and am too lazy to type dict into mozilla.
However, some time ago there was an article on slashdot about the top 10 things MS could do to kill the linux "threat". Since then at least 5 of them have been quite prominent - among those was the idea of forking both the development and community, one has been achieved in some way with MS pulling some linux tricks we all know about and so i can only think this is a part-approach to the second problem.
I wish i could find that article on slashdot though, it was pricessless more because of the fact that it looks like a play book MS have been using ever since!
16MB of RAM is enough for anybody. I mean, c'mon.
-Nathan
Please stop stalking me, bro.
eg nVidia graphics drivers needing recompiling when a new version comes out and that sort of thing
I never expected I will say this but... here it is: Buy ATI ! They are opening 3D specs, AFAIK already opened 2D specs for new cards. Users can expect ATI new cards to play nice with new kernel versions regardless kernel upgrades. As a bonus, you will have drivers auto-installed as a part of the kernel (HDD or DVD drive right now).
839*929
Plus, you can already recompile your own kernel without the modules that you don't want? What's the point in a fork?
which is totally what she said
I'm amazed at the ignorance of many. Kernels do not make servers OR desktops. Kernels are pieces of software designed to connect User Space with Hardware. The only difference between a kernel optimized for desktops and one optimized for servers is the process scheduling algorithm (a configurable option). Servers spend more time dealing with hardware interrupts, while desktops spend more time dealing with users. The rest of the "kernel", ie. the modules, are all extra. The stock kernel is bloated because it has modules installed for every piece of supported hardware, allowing the stock kernel to run on almost any system (and thereby allowing you to boot, and recompile the kernel to best fit your system). Anyone who has never done a "xconfig" or "menuconfig" should not way in on forking the kernel. Also, I read somewhere (I forget where) a new timing algorithm specifically designed for desktop PCs will come with the next kernel release.
Is a pretty big /grief :)
I can say you live up to your username.
Time flies. It's already time for the perennial call for forking the kernel. Now everyone will bitch and moan about what a bad idea it is and everyone will tell the person who suggested it that they are a moron. Where as it may have some practical value in some limited set of cases. However, I'd assume that if it presented that much value someone would have done it already and released it under the GPL. On the other hand, maybe they are so intimidated by the rabid reception the call receives that they can't even imagine attempting something so audacious.
In Linux, if the projected is run badly, there are calls to:
- Fork the project and do it "right"[TM]
In Windows, if the projected is run badly, there are calls to:
- Knife the new version and fix the dam bugs in the old version
In MacOS, if the project is run badly, there are calls to:
- Spoon the new version. You just don't understand the superiority of the new "Mac way"[TM] because you're stuck in the "Windows Mindset"[TM]
Linux already *IS* a "server" OS, and isn't really intended as a desktop one in the first place. It would only need to fork if it was really a common priority for most people that Linux be a desktop OS. But most people that want a desktop OS don't use Linux anyways, and wouldn't even if Linux forked as suggested, so there's no real point.
File under 'M' for 'Manic ranting'
Isn't it the job of the distro to choose how the kernel should be configure "out of the box"? If Red Hat (as example) wants to have server and desktop versions, wouldn't they configure the respective kernels for the respective environments? Why do this so specifically down to the kernel development level? If you're talking about bloat and usability, you're probably not "rolling your won" Linux. You have some distro and use its automated installation tools (ie yum and apt). Let the distro decide what their stock kernel should have and base your Linux decisions on the distro you choose.
Power to the Penguin!
Some have argued that, for desktop Linux to succeed, the code base will have to be "forked" - that is, a separate base image for desktop and server distributions. It's an approach that has worked in the past, most notably with Microsoft Windows NT (and later Windows 2000/XP/Vista). As the Redmond behemoth has shown, you can have your cake (robust, shared kernel architecture) and eat it (separate code bases optimized for specific runtime scenarios) too.
Windows has always existed as a two seperate pieces until 95. At that point they said who needs DOS and went to the all in one model. Linux has always been a layered operating system. If you don't want a specific part you just compile that layer out. Micrsoft did it mainly because they did have an all-in-one model. And when you do that, you must do seperate images.
And why else did they do it? Well money of course. Linux has all the features and you compile what you want. the cost? FREE. Microsoft had somewhat of a shared code base in NT 4.0. If you typed the write registry fix, you could enable certain features. It was after that Microsoft went to seperate images and made it impossible to get the extra feaatures without he server product or an additional purchase.
http://www.freebsd.org/
Want to fork the kernel? Go right ahead.
Deleted
In Soviet Russia, Linux forks you.
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
come on, can you *please* digg it? the shame for letting this lame story make it into the news won't be on slashdot alone then.
At first I saw this "story" and said "who cares?", but as I read the comments I realized that if there were a unified as in procedurally cooperative fork of "Linux" for the desktop then I would be actually excited about working on it. At this time I would not waste my time developing for such a fractured Linus cetric "community". It seems that if someone would have good ideas about how to streamline Linux and reduce or even eliminate confusion they can't just start work unless they have "community" support. There needs to be a leader that has the desktop in mind and understands how to get it done. Linus is no leader and obvously not qualified or interested in the measures that need to be taken to free the everyday person from Microsoft (as if THEY cared) or the ever looming closed Apple (OS X). It still boggles my mind why no company such as IBM or Google has not started on this ten years ago. It will take a corporation to get this done.
If I remember correctly it was suggested to have a kernel scheduler that is aware of 'interactive' applications like video players to give them precedence over background processes. Linus Torvalds dismissed that back then. Right, Windows does have a scheduler that acts like that and you can all guess now what causes bad network performance on Vista when watching a video while downloading.
fork linux? :/
why not fork hurd, port it under gpl2+, have a linux-style development, so no one complains about the license and people are more happy to improve it?
hurd is not dead, but compared to linux development, it doesn't move really much
maybe this is due their closed development...
why not try to improve something that has a better design?
Then explain why Linux is still years behind OSX and Windows on basic things like playing video with sound without performance problems?
Well, my MacBook Pro already has an ATI card - though last time I tried an Ubuntu live CD it didn't even get to X windows! I'm satisfied with Mac OS for non work use at the moment anyway (tend to use it for browsing, listening to music, watching DVDs, MUDding over telnet etc when I'm at home, and XP for other stuff)
which is totally what she said
I always build a custom kernel, and view the distro kernel only as a platform for bootstrapping the real kernel. The box I'm typing this on right now is a Slackware box, with a custom kernel. What the hell do I need RAID drivers for?
At the risk of heresy, if we really want a desktop operating system, we might want to look at a ground-up redesign. There are lots of ideas out there, and lots of goodness too, just looking for a home.
...laura who has played with both Minix and Syllable
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.
and MMUless processors
and X86s
and SPARCs
and Desktops
and Servers
and Laptops
and Routers
and Watches
and SetTop Boxes
and Spa Controls
and Mobile Phones
and Internet Radio Devices
and PDAs
Just imagine the endless possibilities that would be served by Forking the Kernel.
We've been pidgeonholed for too long, geeks unite and divide.
I'm sure you could get Con to be the scheduler maintainer for your new Fork. (I'm going to dub it LUNIX or maybe LooniC)
OSGGFG - Open Source Gamers Guide to Free Games
On July the same discussion was on lkml. I guess the opinion of Linus Torvalds himself is pretty clear:
"I think that people who argue for splitting desktop kernels from server kernels are total morons, and only show that they don't know what the hell they are talking about."
"If I can't have a revolution, what is there to dance about?" - Albert Meltzer
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.
The vast majority of Linux users these days don't know compiling from composting, and should never have to. The point of the article is to create two standard versions of the kernel that will be optimized for their respective purposes, and maintained without the user having to know any of the programming magic involved.
I'm sure that users like yourself consider it an outrage that -- dare I say it -- the common people are actually allowed to run Linux. It's like an auto mechanic demanding that you should be able to repair a car before being given a driver's license. It's an unreasonable expectation at best and elitism at worst.
/rant
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
"Sure there's a reason home-lusrs should NOT consider r-a-i-d. RAID does NOT just work. LAN is another example. In fact any admin task that does NOT automagically install & configure has no business on a home-lusr system. Period."
Most people are running lans at home, so your example sucks.
Software RAID 1 is super easy to set up and maintain. Throw 2 new hard drives into the box, create your partitions as type RAID (a couple of clicks), set your mount points (a couple more clicks), and you're done.
After that, it will "just work". Check its health once a week, to be on the safe side, Rotate the drives on a weekly basis with a spare drive, and you have 2-minute backups. (Rebuild te raid on the previous spare drive in the background - its a heck of a lot quicker and easier than backing up using any other method).
Kevin Smith on Prince
The problem is, how to do you define "Server" and "Desktop"? Suppose you're using a primary desktop. If you run an access-like database on your computer, are you a server? If you allow file sharing are you a server? If you have your own personal wiki, are you a server? Suppose that wiki is visible to other computers in an intranet?
As far as servers go, what do you call a VMWare server or terminal-server? Is it a server or a desktop?
The problem is, in the real world, there are very few "pure desktops" out there, so if you optimize for the pure desktop, everything else suffers.
It's not a new problem. HIG people face exactly this issue every time there are calls to divide a GUI into an "beginner", "intermediate", and "expert" mode since you eventually end up with beginners who need to do some expert things and experts who don't want to have to do "simple things difficult" as the normal case (which generally happens to make difficult things possible). HIG people generally agree that moded interfaces are a cop-out. If you do things right, the GUI should be simple but scalable to advanced needs.
That's what Linus and the kernel gang are trying to do. Do things right instead of copping out. Make Linux good for both the "Pure Desktop" and the "Pure Server" and everything in between. It may not be "optimal" for the "Pure Desktop" or "Pure Server", but it should be possible for it to be indistinguishable by anyone else other than the ricers.
See subject.
The linux development model is built on forking anyway.
Trying to fork linux is like trying to burn fire.
- all multimedia should work with zero knowledge
- you should be able to go into a hardware shop, grab anything, and have it work with your Linux
- the UI should be free of gotchas, those being too common in a culture where people actually like hacking around stuff
Mkay? Forking the kernel to marginally improve the UI responsiveness is so off the mark it isn't funny.Jump to conclusions mat. http://www.youtube.com/watch?v=yhdyxTAhz3U
http://www.rense.com/general79/wdx1.htm
Somebody's writing without thinking. Most of the distro providers "fork the kernel" in a temporary way. I.e., they re-compile from source using custom modifications. Red Hat, among others, is well known for this behavior. You can be certain that if any of the dirtro providers had seen a long-term benefit in extending their fork rather then dropping it, and forking again from the next kernel version, then they would have.
Also various developers already maintain forked kernel trees. Alan Chapman comes to mind, but he's only one of many. If someone wanted to start a kernel fork, the material is ready to hand. Nobody does. It's not because they haven't got the means and opportunity, it's because they don't see any advantage.
Linus may be the "top of the pole" position, but most coders are relatively satisfied with his choices. If any weren't, a fork would occur. They've happened in the past. Generally they were only demonstration forks, or experimental versions, but they were still genuine forks. If anyone had wanted to pick them up and run with them, they could have. I presume that there are currently extant forks that are moderately current. The problem is, if you keep them separate, they won't stay current.
In principle, I'm all in favor of forks. That's why I'm in favor of Linux AND the Hurd AND the BSD Unixes. And while I'll probably be in favor of OpenSolaris. (Favor is withheld while they're chosing their license...if it's not FOSS I don't want it.) Just being in favor of them doesn't mean that I'll use them. Actually, I've pretty much stayed with Linux since I left MSWind around 2000. I still don't really understand it in depth, so I'm not likely to make that kind of investment in multiple OSes, even ones that are pretty similar. Which gets into why specializing an OS for only servers or only desk tops is a bad idea. It fragments your user base in a bad direction. It makes it unlikely that any one developer will know in depth both the development environment and the execution environment (unless the application is intended to only run or desktops, or is to be developed on servers). And as a result it's likely to fragment your applications in an unpleasant way.
N.B.: As the decades go by if two branches of a fork survive they are likely to become increasingly distant. At first any application that would run on one, would also run on the other. This wouldn't be true a year later. A decade later it would be an unreasonable expectation for an application chosen at random. In two decades there might be only a handful that would run in both environments...without special handling. (I'm not including via use of wine-like emulators.)
I think we've pushed this "anyone can grow up to be president" thing too far.
To me the question isn't wether it is a good idea or not. The real question seems to be wether someone will actually sit down and do it. look at sourceforge, code.google.com and all the other hosters that let you create projects with a few mouseclicks (been there done that unfortunately myself).
It is just too easy to think "Hey I need a tool, let's go to sf.net creat a project make up a 3 liner as specification and wait for some community to build up".
Sourceforge alone counts too many projects that haven't even started - I'm not putting critics on anyone who has done a tool the third time, there may have been arguable reasons but at least he/she has done _something_. Better someone sits down writes the software he/she needs until at least a level of usability is reached so that you acutally have a lib/executable whatever that does what the initial idea was. It doesn't have to be bug free or extraordinarily reliable or the cleanest code ever. But damnit something has to be there to build upon. And mot important the initial author has to care about the project at least long enough until some critical mass has been reached that then will evolve by itself (URL:http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar).
This is what has to be done. Just writing a (stupid) blog post with 100-200 lines of code and think someone will sit down for you and do the work? Ah yessss you can then go and sue him/her that the idea was actually yours just to get the credits (prior art)....
If you want to fork it, sit down and start working (damnit just start working don't talk about it until you're too old to hit the keys....)
I have no knowledge of the arguments. However, I can comment on the state of the Linux Desktop: It needs serious work.
I use Linux and it's great at compiling, running Apache, running MySql or PostGrep. However, as a desktop machine (especially for the masses) it needs serious work. Walt Mossburg has reviewed the Dell Linux system and he pretty much agrees with my experience. Even Mark Shuttleworth (Mr. Ubuntu himself) agrees that the Linux Desktop is not for the non-technical.
Whether forking the Kernel will help this issue or not is up to people who understand the details of kernel design, and I am not one of them. All I can report is that there is no Linux distribution that is ready to take on either Mac OS X or Windows as a desktop machine.
If that is what he wants, nobody is stopping him. He can do it himself. That's what Linux is all about!
I have followed some of the discussion about the kernal and its optimizations for desktop vs. server usage, especially recent arguments over the scheduler. Although I am most definitly NOT a kernel hacker, I am quite well-read on the subject of McLuhan and his insights into media.
Computers are "hot." Their screens are clear, and, more and more, are solid-state rather than CRT (McLuhan said we feel the electrons come through a TV-type screen to land on our skin). As a "hot" medium (compared to TV or even FM radio) it is fitting that a computer spring into action immediately a control, key or mouse button, is activated. That it does not do so is frustrating. It is like watching an Imax movie and listening to the audio through cheap headphones; it is an unsatisfying experience.
A server, OTOH, is not a medium. It is an appliance. It does not interface with our personalities as a desktop computer does.
But I disagree that the problem lies with the kernel or its scheduler. It seems to lie elsewhere in the system as KDE seems sluggish and slow-to-respond to input even with 1.5 gigs of RAM on a 2800Mhz-rated Semprom, while Blackbox on a RH-6.2 box with one-fifteenth the computing power and one-sixth of the RAM was much, much more responsive. On this box, KDE (versions 1.0, 1.1, 1.2, 2.0, 2.1 and 2.2) was no more or less responsive than it is on my current Mepis-6.0 installation. I do not have Gnome installed so I cannot compare it.
During the years of using the AMD-K6 300 box, I experimented with various self-compiled kernels (the old 2.4 series) and patches. Optimizing sometimes radically, I might achieve a modest (2-3 per cent) improvement in certain benchmarks but nothing noticeable in the real world, so I stopped compiling my own kernels and used bone-stock distribution-supplied ones.
I agree that the Linux Desktop should SNAP-TO when a command is issued or pressed. But I do not see significant gains to be made to this end by the kernel scheduler. Perhaps reading all those KDE text config files each time an event happens has something to do with desktop sluggishness. Perhaps RAM latency is part of the prob and some data could be prefetched in some way. Or perhaps engineers might install an enormous, fast L3 cache on mobos.
Whatever the solution, the organization that makes a computer to respond in a way that would please McLuhan, were he still with us, will own the 21st century, IMHO.
But I don't think anyone has yet built even a moderately good single user machine OS. Until someone does, we don't know if it can effectively use the same kernel as servers and special purpose desktops. Windows 9 might have eventually evolved into something interesting. But instead, MS elected to produce NT -- which is probably an OK server OS, but is really a mediocre desktop OS. (Takes forever to boot; often even longer to shut down; response to keystrokes is often slow; security is an ongoing problem etc, etc, etc)
But I think the right way to handle this is for experimeters to try to build a decent single user OS based on Open Source Unix. If, after they get their act together -- which will take years -- they really can't do it with the Linux kernel because of fundamental, irresolvable, conflicts, then it's time to talk about forking the kernel
(Note, single user machine architecture surely is not GNOME vs KDE vs Xfce vs Windows Explorer vs OsX. It's what does a consumer want in a computer and how do we deliver it to him or her? e.g. instant ON, instant OFF, secure by design ... just works ... no suprises ... stuff like that).
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
A key component of publishing is the role of writers as great masters of wisdom that all of us can barely understand. That's why the AP Style guide limits writers to 20,000 words: because our feeble simian brains can barely comprehend the greatness of their massive ideas.
People who make their livings as writers have to publish stuff like this, or else they will weaken and eventually die.
On a more serious note, what scares me is that this sort high-above-the-clouds view of issues has no place in the IT world. Any editor dumb enough to let it be published needs slapped -- viciously and repeatedly. When I read political or business news, it is this type of grand, self-annointed pontification that makes me quit reading and go back to coding or playing video games.
Every medium eventually hits this point: more audience than they have content. So what do you to keep the audience? Churn out blithering piles of crap. If the audience goes for it, you keep churning it out.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
Yeah... wake me up when it can actually boot and do something. I tried Slowlaris as the Nexenta OS (I wanted as desktop version of the OS) and it... well it never booted. Kept complaining about the IDE device timing out. So much for the kernel being all the good. I've NEVER had Linux kernel fail to boot. Not once.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
I have twice brought the Linux kernel to its knees. To the extent that it was not even able to move the mouse cursor around on the screen. And I would argue that a "desktop" system that cannot move the mouse cursor around is not a "desktop" system.
And it is very easy to reproduce this. Create an 8 GB swap partition. Then execute a self-reinvoking shell script. Mind you I am *not* reccomeding one try this. This is a recipe for dragging ones machine into the depths of hell.
The fact that the designers of Linux have failed to perform sufficient "limits testing" (and performance under stress on the desktop) is a testimony to what they really need to do. It is simple, "Break Linux" and have it still perform.
If a blog entry says, then the debate must be on!
"Finally someone is beginning to understand.
A PC is not a server and the setup for a PC is not the same as the setup for a server."
[X] All my PCs, whether at home or at work, double as servers, you ignorant clod.
Seriously, in todays' computing environment, I *want* to be able to access my home web/ftp/ssh server. How many times have you said "gee, I have that on my machine at home ... wish I could get it ..." Or "I really should back this up to my home machine so I can work on it over the weekend" ? Or called someone at home, had them turn on the computer, and then tried to have them navigate to just the file you want, and email it to you?" Screw that. Set up your home box as a desktop AND server. This is the 21st century - get over 20th century unconnected thinking ...
As for at work, again, my box doubles as a server. Co-workers have accounts on it, are free to dump stuff on it, etc. It's also nice to be able to run a few wikis off it, for local use, as well as to let others test stuff before we move it to the "real" internal test server. Plus, it assures that there's another copy floating around for when (not if) their hard drive dies (not everyone wants to use the svn server).
A computer operating system without servers is crippleware.
Kevin Smith on Prince
Just a few years ago, only servers and a few enthusiasts had more than one CPU in their machines. Now we have desktops with dual cores or quad cores. Only servers had 64-bit OS's and software. Now we have 64-bit desktops. Only servers had more than 4GB RAM (or 1GB, or 64MB, or 640KB) - now desktops routinely have that much memory. Same for disk space - filesystems had size limits, but servers had bigger size limits, then server file systems moved to the desktops as desktops got bigger hard drives. I'm seeing RAID in desktop machines - that used to be solely a server thing.
Meldroc, Waster of Electrons
The argument that the blog post was making was that, because Con stopped working on the kernel, and Ingo Molnar's scheduler got merged instead, this means that the desktop is being ignored. In fact, Con's work demonstrated that there were issues in how the scheduler worked, and that things could be improved with a simpler scheduler based on a different calculation. This got the attention of Ingo, who whipped up a better implementation of the same idea while Con was out sick. There were a couple of issues that Con had worked out that Ingo then had to work out again, because there wasn't good communication as to exactly what the problems were that Con had solved. Ultimately, Con succeeded, because he convinced one of the superhero coders to put his theory into practice.
Ironicly, when Con was working on the kernel, he had essential a fork, because he had his own mailing list and community of users. This just meant less communication with the core kernel community, which meant that it took longer for the mainline kernel, as shipped by (for example) Ubuntu for desktop use, to get the benefits of this attention to issues that desktop users were having.
The new scheduler is based around a different and better fundamental scheduler formula, which, as it turns out, can be made to also solve server workload problems better. So the fact is that (a) there was a fork before, and it has now been healed, at least partially, and (b) work was done in the "desktop" fork that turned out to be beneficial both to desktop users of the mainline fork and to big iron users.
Also languishing in the "desktop" fork is "swap prefetch"; nobody's been able to show a logical reason for an actual benefit for desktop users (and the original theory has been debunked; the benefit seems real, but they want to know what's actually going on so they don't accidentally break it again, and they might be able to fix it more effectively differently). On the other hand, it's a clear win and a big help for large CGI rendering installations, according to a representative from Dreamworks.
And Ingo managed to implement code that worked closer to Con's ideal formula than Con could write because Ingo was using timer code developed for big-iron server hosting support, so the fork was also bad for its own users. Forks are good short-term to get development done, but they also benefit from getting merged back in.
if a kernel is componentized and modular (yes, even in Linux's monolithic sense), then you can simply compile different parts of it - the basic for desktops, a shrink version for mobile devices, and extra capabilities for servers and big iron. Forking a kernel is essentially creating a new OS, since it's a huge mess trying to constant reconcile new codes across forks....
just look at the gazillion variations of BSD. Why can't we have an OS that's secure (OpenBSD), high performing (FreeBSD), and multi-architectural (NetBSD) at the same time?
Choice is one thing. Having choices is healthy for competition. But too many choices will simply dilute their power to compete against big companies.
Look at the floppy-replacement. There was Iomega Zip/JaZ, SyQuest EZ-135, LS-120, Caleb UHD144, Castlewood Orb, Sony HiFD....and guess what? everyone lost, and all replaced by CD-R and CD-RW.
Even Unix's own fragmentation left few survivors. IBM AIX and Sun Solaris being the major ones. Even HP is half-heartedly supporting HP/UX.
All the people stating that a fork of Linux kernel is needed to support the differenced between the Desktop and Server are woefully misinformed.
Do you really believe that the Server runtime is more different from the Desktop that it is from mobile phones, retail routers, and other embedded devices? If a fork was not required to handle the embedded environment, it is certainly not needed to handle desktop.
The argument that configuration options can't support the need for different optimizations between Server and desktop is likewise misinformed. The config scripts and C Preprocessor could support building a kernel from entirely different codebases if necessary - even if you DID 'fork' the kernel, "make config" and make could handle this, up to and including applying patches to source files generated by diff-ing your new source tree and the standard kernel tree.
Con did not apparently quit because of the lack of focus on Desktop, not entirely - he did not quit until a similar scheduler patch from another developer (Ingo) was accepted*. He had some technical Which means his problem was not the core team's reaction to Desktop oriented patches, but the way he felt they acted toward him. Valid complaint or not, this is not a technical issue - it is a personal issue, and will not be solved by advocating a kernel fork.
If a person wants to fork the kernel, because they think they can do a better job of maintaining it and directing development than the current dev team, good for them. I doubt it will gain a lot of traction, but if they CAN do a good enough job to compete, good for them. But I doubt anyone who is advocating a kernel fork "for the desktop" because desktop optimization is incompatible with server optimization within the same source tree will be able to do so, because it indicates incomplete understanding about how the build and configuration process works. If a successful fork for the desktop were to be done (which I do not advocate) it would be done because someone was better at directing development for the desktop... and I think the best of these modifications would be quickly snapped up by the mainline developers.
*http://apcmag.com/6762/interview_with_con_kolivas_part_2_his_effort_to_improve_linux_performa/
It's a kernel!
This is only useful for big business, to maintain the status quo (from a support standpoint), to keep things "efficient" (an illusion actually), and be able to target products (2 product lines = 2 lines of supporting products = more money for the biz). The home user loses since not all home users require a 'home' edition (I use Linux or Windows Server, not XP at home).
The beauty of the kernel (or what it should be) is that is scales from 'home' users to 'servers'--not scale by means of computing power, but by features, which is what all users want in the end. That's the purpose of having distros, not the kernel.
Old story.
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.
Noone is realizing that , instead of putting that much effort into the Linux kernel itself, someone should fix userspace applications (starting from X) to get better desktop performance....
INTERNETS
Serious Business
Ok, it may be news to all of you, but Ingo Molnar has been working on a schedular that incorporates most of Con's ideas. It's called the 'Completely Fair Scheduler' (CFS), and its slated to be released in the 2.6.23 kernel.
If you'd like to read a bit about it and see some benchmarks comparing it to Con's SD scheduler, there's some very good coverage of it all over at kerneltrap.org
As for people calling for a fork of the Kernel, they obviously don't understand the Kernel development process, or how many forks currently exist.
Redhat, Suse and the like have written custom linux patches for years useful for for different tasks, no need to fork just customize with patches...it works for everyone else. Who is he anyway, I have never heard of him? Obviously he writes a patch set for the kernel to make it behave the way he wants it to. Just because he is whining about not getting his geek award via actual introduction of his code into the linux kernel tree does not mean we want to encourage him or anyone else to actually fork the linux kernel. Anyway I know it will sound trollish, but who really cares?
There is, however, a difference between running a server on your home (or development) machine and running a server at, say, amazon.com. Probably different optimizations, yes?
What's wrong with X? I think it is an excellent design.
“Common sense is not so common.” — Voltaire
Not to forget that the maintenance will be more complex.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Quote:In 2003, for example, he told me, "I still use it day-to-day on regular desktops, and that's what I care most about. Obviously my 'regular desktop' tends to be a fairly high-end one, but it's not that high-end. I'm aiming for the high-end desktop, because that will be 'normal' in a few years. And we still do care about low-end machines too, so it's not like we're trying to leave those behind either."
Excuse me but that sounds like he is leaving the base of whatmade linux great being able to use ANY machine wiht and for it.
YUP linus is selling out.
I agree.
Freedom is free.
It has to do with wannabe chimpanzee alpha males trying to bring down the alpha male leading the troop. Standard primate behavior.
Happened to Bill Gates - who deserves it - big time.
Now it's happening to Linus, who couldn't care less because as he's said many times, all he cares about is the technology, not the politics.
Fortunately, who cares? It's not happening unless Alan Cox or some other kernel maintainer decides he's bigger than Linus and can convince the majority of kernel maintainers that he is...
Email me when this happens.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
It's not about "alpha male" status. Maybe you should read "Free Software, Free Society" if you want to have a better understanding of what's happening.
Freedom is free.
Before even considering to tune the kernel for a specific workload, just try and tune user space. Tune your algorithms. Don't blame the kernel if your algorithm is inefficient. If the kernel has problems to cache your disk load, cache it yourself (hi, PostgreSQL). Your application knows its work load best. The kernel could only do an educated guess. Java VMs have specific tuning options for server and desktop. Use them. Then the kernel also has some tuning paramters (on kernel command line and in /proc). If you have latency problems, reduce interrupts. Last but not least you can turn Linux into a real-time OS and use a real-time capable language. If that's still not enough, try a different platform. And if that doesn't help... I don't want to see that code.
For some reason, context switches on an ARM platform take 1.5 more time on 2.6 than on 2.4 series. This isn't that small if you consider that, for example, typical values for EP9301 are about 150us. If low latency is required and timeslices are set to 1ms (1000Hz), than in 2.6 switching itself takes 25% of processor time, instead of 15% on 2.4. Perhaps, simplified algorithms designed specifically for embedded systems with typically 1 active processes and 20 sleeping could lower overhead even more.
"Fork the Linux Kernel so it can be ready for the desktop!"
About as constructive as:
"Get rid of X window system and build a new GUI into the kernel"!
or this classic gem:
"Get rid of network transparency from X window system because it makes X slow"!
Learn something about the system before you go spouting off idiocy like the above.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
please don't fork it, this will just produce confusion, complexity and a lot of code duplication, this is unnecessary... just make a great scheduler that works great on the desktop and server, or if this is not possible, put a scheduler for desktop and server on the vanilla kernel, like there is now different preemptions for server/desktop.
Lived by the C...
I have to say, maybe this guy has a point. This is, after all, a new approach to Lunix on teh desktop.
It's hardly news to anyone except the most deluded zealot that Lunix on teh desktop has failed. So this guy seems to be taking the shockingly revolutionary step (shocking given that it's emerging from within the Lunix community itself) of saying "hey, it's not Microsoft's fault Lunix has failed on the desktop... it's Lunis's".
Now maybe he is right, and maybe he isn't. But his direction seems to be the correct place to start: rather than blaming Teh Lunix's failures on Microsoft (sadly, the gold standard in justifications for teh Lunix community), he is instead looking to blame Lunix for the failures of desktop Lunix.
I always thought it was up to a particular distribution of Linux to specialize the kernel for server or desktop applications. Ubuntu, Redhat, Suse, and others do this.
Sounds like a blogger needs to do a some research...
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Clearly optimized!
Very interesting! This "recoiledsnake" guy (parent poster), up to this point, was a thinly masked Microsoft apologist:
He was slamming OpenOffice
He was posting a Microsoft explanation for the Windows stealth-update scandal
He was flaming Apple users
He was downplaying an article about a boot sector virus on a Windows Vista laptop
And now, after a long history of Microsoft-centric and Microsoft-friendly comments, he is suddenly pretending to be an expert in Linux kernel matters, giving a deceptive and incorrect account of what happened. (He even got moderated to "Informative". I expect to be modded me down for this - dont spare me.)
Read this if you are curious about the true story of why and how Con Kolivas quit kernel hacking:
LWN.net article
Written by long-time Linux kernel observer Jonathan Corbet.
Could this really be Microsoft PR in action? Is Microsoft trying to plant false grass-roots "history" via such deceptive postings? Seeing that they cannot win via technology in the marketplace, is Microsoft now trying to attack the credibility and integrity of Linux kernel developers?
People have gotten so fed up over non-inclusion of a pluggable scheduler that they are considering a fork? Usually something like this means they are really asking for a fork to change leadership, or at least take things in a new direction.
Now, can someone honestly tell me what would be wrong with a pluggable scheduler, besides saying "Linus/Ingo say no"? Think for yourselves and answer. Other places in the kernel have selectable things, like a selectable IO scheduler. But selectable CPU scheduler? No way! The ole "it will confuse users" is really a bogus argument. Non-power users can take a default scheduler and not lift a finger. There isn't going to be a scheduler that is optimal for ALL loads, much like there is not a single allocator that works for "optimal" for all allocation loads, nor a perfect IO scheduler.
What I think I'm seeing is plain ego-tism. Not invented here type of stuff. Perhaps giving users a choice of schedulers in some form or another (pluggable or compile option) would mean Ingo doesn't know it all about scheduling. Now, we can't have that now can we? The scheduler algorithms would probably be simpler if they didn't try to do it all with one, by the way, and you could probably eek out a little more performance because of that.
Some of the people pontificating on the issue used to think source code control systems were for the weak minded, and that debuggers should be outlawed, if you all can remember that far back.
Just do it!
The reason why there is an impression that desktop performance is sub-par is because of the x-windows client/server architecture. It has *nothing* to do with the kernel outside of a history of crappy video drivers for ATI/Nvidia compared to their windows counterparts.
Whats funny is that even for remote access windows terminal services is faster and more efficient than x will ever be and x was *designed* to be network centric while windows wasn't.
A couple times a year I will get board and boot a linux distribution..knoppix, fedora..etc. Compared to windows it 'looks' pretty at first but that opinion quickly fades. The windowing environment always seems kind of laggy and lack of really nice/scaled fonts that exist on the windows platform really stand out. I think part of my problem here is using live cd's which don't have the room for extensive fonts.
Opening a lot of apps or dinking around in the x environment for any amount of time always causes the x server to die outright, the os to freeze or corruption artifacts to fill the screen. This is using modern nvidia and ati chipsets.
I love linux as an IP router and a whole host of other things... But the windowing system IMHO needs to be more like windows and less like X which IMHO has always sucked.
Software Freedom Law Center gave some very nice advice on how to wrap new licenses around old code -- let's fork Linux and make the new changes available only under a BSD licence!
:)
We can then ask SFLC for legal advice in case anyone disagrees, right?
Here is their advice: http://lwn.net/Articles/248223/
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
Have you ever dealt with a 'typical' user? Half of them have trouble understanding the difference between the internet and Internet Explorer.
Is that why my linux system is currently crawling (94% idle, load 3.8)? Updatedb is running in the background while I'm operating firefox. Firefox pages keep getting kicked out of memory while the disk is busy.
That, I think, is due to the extremely elegant principle of regarding all RAM as cache and swapping out pages regardless of their use. Updatedb and big compilations (= file access) should operate in their tiny sandbox and should not be allowed to kick out process pages.
This suggestion of a linux fork is absurd and could be quite destructive if anyone took it seriously. At the kernel level it does not make much sense. Perhaps distros might have their own focus or whatever in regards to what packages you want to install. But usually with the kernel, you dont need to load drivers and such unless they are needed so drivers for server hardware might not need to be loaded on a desktop. I dont really think there is a compelling reason that there should be a seperate server and desktop kernel, they probably have similar needs and benefit from the same improvements to say the scheduler. There was also talk of perhaps including a plugin interface for the scheduler so the user could plugin different schedulers easily. Con suggested this so the staircase could be used in Linux without needing kernel patches, or CFS depending on user preference.
I fail to see how user level software would fail with a kernel fork, so long as they keep to the POSIX api, while in kernel interfaces change every kernel, there has been a stable interface on int 0x80 for the entire time, sure linux has extra things that can be used that aren't specified by the spec. So long as you keep your featureset to the POSIX api, all is compatible. With the exception of when you change architecture to something that the dev wasn't expecting, porting something between linuxen should be a walk in the park. Oh and incompatibilities with libraries etc between distro's aren't exactly the kernels fault, thusly couldn't be blamed.
For the majority of users, the kernel that comes with their distro of choice will do fine for both server and desktop. If you're running S3 or the Googleplex, then its worth investing time in modding the kernel to YOUR needs, but for most of us, we're better served (pun intended) with what's already out there in the market.
forking the kernel to generic "server" and "desktop" is just stupid. Its more work for nothing.
Kevin Smith on Prince
"Have you ever dealt with a 'typical' user? Half of them have trouble understanding the difference between the internet and Internet Explorer."
And they're the ones who need a RAID1 setup the most - they'll never back things up - they don't know how. Hard disks are so cheap that it doesn't make sense not to do it, and its not like its all that hard to set up ... Plus, since each disk is only doing half the reads, and head stroking is much less, both drives will last longer. Plus, your disk cache size is additive, so instead of 16 megs of cache, with 2 drives you've got 32 megs.
Kevin Smith on Prince
Not true! According to Kanye West, Linus also cares about black people.
Show me on the doll where his noodly appendage touched you.
Microsoft Windows Server 2003 gives you that already - you only add server level components as needed. Otherwise, it's workstation/pro model essentially. Best of BOTH worlds, from Microsoft.
If you've read any of the myriad mailing list messages Linus has posted on the subject, you'll already know that Linus strongly advocates that anyone who thinks forking the kernel is a good idea just go ahead and do it. This is why he chose the GPL as his license. If you have an idea, an alternate direction for the software, you've already got the code and the permission to make with it what you can. And here's the best part: if it turns out that you've got something going and have accomplished something important, then Linus has the right to take your changes and incorporate them into his kernel too.
Most project leaders fear forks because they split an already thin development force between two competing projects. Linux, on the other hand, has no shortage of willing developers. Instead of begging for help, Linus and his "lieutenants" spend their time sorting through lists of patches looking for those they want to keep. A fork in the Linux project would probably not significantly hinder development.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
There may be a problem with background I/O interfering with everyone on current kernels. See the bug reports in Ubuntu Launchpad about Tracker on Gutsy. Tracker indexes files in the background. While it's doing that, everything slows to a crawl. It does seem to do so disproportionately, as through the kernel isn't scheduling I/O very well.
I think that you lost most people on the first step (i.e. throw 2 new hard drives into the box). This is not to say that it's not useful for them if it could be setup.
"I think that you lost most people on the first step (i.e. throw 2 new hard drives into the box). This is not to say that it's not useful for them if it could be setup."
If they can't do it, they can always
Kevin Smith on Prince
n/t
We've secretly replaced Slashdot with new Folgers Crystals - let's see if it notices.
If you don't like it, you can go fork yourself.
Linus, and most Linux users, don't consider desktop performance the 'most important thing'. For instance, these same class of users find it 'absolutely inexusable' that Vista constrains network activity while playing video files. But at the same time, that very solution solves the solution (granted, in a rather draconian way).
The same desktop patches that most major Linux distributions actually incorporate will no longer exist or be supported by their author, because they couldn't make it into the mainline kernel.
The modularity that Linux *HAS* could allow for these very patches to co-exist. There was really no reason to NOT include them, so what was the original author to do?
The reasoning that I've read was, 'It just didn't seem to make a noticeable difference to me'. But it DID make a difference to the people who used these patches, so why not include them, unless, of course, the original contributor of those patches was right?
-- I'm the root of all that's evil, but you can call me cookie..
About time we forked the hurd kernel too, so that someone can get one of the branches finished...
(yeah, yeah, who am I to make cheap shots, I haven't contributed any code)
Often on the path to invention you need to shake things up. It's time. The Linux Kernel is stale and stagnant without significant innovation for quite some time now. Shake it up. Innovate.
Fork it, fork it good. Take it in new directions.
Take it where you want it.
Take it in the direction of a true microkernel or exokernel or even in a new direction that hasn't been thought of yet.