Linked by Thom Holwerda on Thu 26th Jul 2007 16:01 UTC, submitted by SEJeff
Linux After years of being relegated to server racks and the desktops of ultrageeks, Linux is finally making some headway as a viable alternative to Windows on the consumer desktop. That's the optimistic message delivered by a newly energized contingent of Linux proponents. By employing the same consumer-friendly marketing techniques practiced by Microsoft, and by taking advantage of the rising popularity of web-based applications, Linux vendors are getting ready for what they say will be a wave of consumer interest in the free operating system.
Thread beginning with comment 258340
To read all comments associated with this story, please click here.
by JMcCarthy on Thu 26th Jul 2007 16:30 UTC
Member since:

if there's one thing Linux needs, it's *more* forks. The desktop and the server aren't mutually exclusive and using one mans experience, as prominent as it may be, to justify a split seems absurd. It's also not like his project was nicked without a decent replacement.

Reply Score: 2

RE: yay
by stestagg on Thu 26th Jul 2007 16:57 in reply to "yay"
stestagg Member since:

Some people think that having lots of forks is a bad thing. Rational people, however will be able to realize that there is no evidence that forking is detrimental.

Forking in open source software has led to the democratization of software development, has prevented Linux (etc.) from becoming too bureaucratic and committee-oriented (unlike most s/w projects) and has allowed individual talent to shine where otherwise, it might have been stifled. If there were different server and desktop branches of the Linux kernel, then Con Kolivas probably wouldn't have quit, and everyone would be a lot happier.

Don't forget, due to the permissive nature of the GPL, improvements made to one fork of a project can easily be merged into other projects, this way everyone wins.

Reply Parent Score: 5

RE[2]: yay
by butters on Fri 27th Jul 2007 02:09 in reply to "RE: yay"
butters Member since:

People would not be happy with multiple major kernel trees any more than they are happy with multiple major distributions. You think driver compatibility is a problem now? Imagine how bad it would be with two or three major kernel projects.

This is the reason why there's no development branch anymore. It's simply too much to maintain two branches at once. Nobody will run the development branch if they can't have their proprietary crack. We're not talking about putting the pieces together in various ways (as in distributions). We're talking about splitting our effort among divergent kernel development projects.

I really think that a lot of people are overreacting to this issue with Con. This isn't elementary school, where everybody is brilliant and deserves an equal amount of praise. This is real world kernel development going on out in the open. Patches will be rejected more often then they are accepted. You have to have a thick skin, and you have to be graceful in defeat.

This has been Con's initiation to the world of mainline kernel hacking, and he didn't like it. Remember, he's a relative newbie that mostly maintained enthusiast patchsets before moving on to swap prefetch and SD. He picked very contentious areas to begin his kernel career. The scheduler is the third rail of kernel development, like Social Security is to American politics. You have to realize going in that you're facing an uphill battle at best.

At the end of the day, you have to admit that Con is no Linus. He's not going to go off and maintain his own desktop-oriented kernel tree. He wouldn't be successful if he tried, and more importantly, he won't like it. He's not cut out to be a maintainer. Who knows what he'll end up doing next, but Con will not fork the Linux kernel.

Nobody is forking the Linux kernel. Not right now. There's simply no reason to take such drastic measures. CFS is a perfectly fine scheduler, an improvement over O(1), and Linux kernel development is going really well. Forking is not any anyone's best interest at the moment.

Reply Parent Score: 4

RE: yay
by kaiwai on Fri 27th Jul 2007 01:00 in reply to "yay"
kaiwai Member since:

if there's one thing Linux needs, it's *more* forks. The desktop and the server aren't mutually exclusive and using one mans experience, as prominent as it may be, to justify a split seems absurd. It's also not like his project was nicked without a decent replacement.

Take the scheduler for example, there is a weigh up between throughput and 'teh snappy' - if you tweak it for optimum throughput, its almost a guarantee that you'll end up with an operating system that isn't snappy enough for the end user.

It isn't about a fork/independence for each project, but for a realisation that there is no 'one size fits all' approach. If you're a vendor for the desktop and server, you'll need to have a kernel with different optimisations for different purposes.

I don't see it as a bad thing, it means that requirements for both end users can be focused on rather than it being a situation of ideas being at logger heads - one wants a feature for the server but could effect desktop performance and vice versa.

Edited 2007-07-27 01:06

Reply Parent Score: 3

RE[2]: yay
by butters on Fri 27th Jul 2007 02:33 in reply to "RE: yay"
butters Member since:

Well, you can have pluggable schedulers just as Linux has pluggable elevators. But more importantly, ongoing work suggests that you don't need to hard-code for throughput or latency. You can make it a tunable.

The primary tunable in the new "fair" schedulers is granularity, which controls the amount of time that must pass before the scheduler can switch out the running task in order to maximize fairness. Raising this value leads to more throughput, while lowering it results in lower latency. If you keep the scheduling fair, a single tunable is all you need to dial-in your particular place on the throughput/latency trade-off.

The primary difference between a desktop OS and a server OS is what kinds of applications they run. A kernel shouldn't care what applications it runs. It's job is to make sure that resources are distributed equitably and efficiently among the applications. There is indeed a "one size fits all" solution, with strategically-placed knobs to control the few fundamental trade-offs.

Specialization at the kernel level is bad. Vista gives Windows Media Player 80% of each timeslice if it wants. Is that the way an operating system should work?

Reply Parent Score: 4