Slashdot Mirror
Why Linux Has Failed on the Desktop
SlinkySausage writes "Linux is burdened with 'enterprise crap' that makes it run poorly on desktop PCs, says kernel developer Con Kolivas. Kolivas recently walked away from years of work on the kernel in despair. APCmag.com has a lengthy interview with Kolivas, who explains what he sees is wrong with Linux from a performance perspective and how Microsoft has succeeded in crushing innovation in personal computers."
The article really focuses on how quickly the desktop responds to user operations. I haven't personally found this to be a problem on the 2.6 kernels; however, to say that work is not being done in this area is unfair. Kernel Trap has had several articles on people working on CPU schedulers to address this problem, recently the Completely Fair Scheduler was merged to potentially solve this problem: http://kerneltrap.org/node/11773.
It's been working fine on my desktop since Slackware '96.
Utter rubbish.
I use Linux as a PVR and it's more than up to the task. It can maintain adequate performance and responsiveness even when doing heavy number crunching. My MythTV boxes are quite often running at 100% cpu and a load average of 5 or 10.
Forget "audio skipping".
Let's try realtime video capture + realtime video decoding + 3 video transcoding jobs all going at the same time.
I can even still use my mythbackend as a desktop with very respectable responsiveness while all of this is going on.
"most people" are at a loss to see what his problem is.
A Pirate and a Puritan look the same on a balance sheet.
Yeah, actually his patches were pretty good. He taught himself C, grokked the kernel coding style, and was a presence on the kernel mailing list. He maintained the -ck set of patches for quite a while, and wrote a couple of new schedulers (staircase, staircase deadline, rotating staircase deadline) based around the concept of fairness.
After quite a bit of discussion, Ingo Molnar produced the CFS (completely fair scheduler) which just recently got merged. The bulk of the new scheduler was written in 62 hours, then finetuned over many weeks on the kernel mailing list. He gave credit to Con for proving the fair scheduler design concept, and for some of the tuning.
A number of people were disappointed by the perceived nepotism, where it appeared that Ingo's got merged because he was in the "in" crowd. I expect this is part of what triggered Con's decision to leave. On the other hand, the two schedulers are very different and it may be that one is really technically better than the other--I haven't compared the two in detail.
Maybe the author doesn't grok the idea of setting the kernel to be responsive for the desktop. It's not rocket science, you know.
Of course not, Microsoft does it for the customer so they don't need to learn how to do it themselves. Would it be so hard for a Linux distro to do so as well when it is doing a "workstation" rather than a "server" install. Some distro ask and have this info regarding intended use.
I think you are exemplifying the "by nerds for nerds" attitude that the author of the article would probably argue is holding back Linux adoption.
And I would avoid correcting people when you don't know what you're talking about.
MythTV is not an embedded application, it's a software application that runs on a general purpose PC. I, like the GP, have a desktop computer that runs MythTV. It can record two channels at once while flagging commercials or transcoding a third TV show while I use it as a desktop or watch a fourth TV show. The audio doesn't skip nor does the desktop feel slow (as the GGP suggested) until I'm functioning at 100% CPU, which is fairly rare.
His point is that the kernels are optimized for servers. That is, focus on throughput, performance, but not latency or responsiveness. A desktop has the latter two as priorities, while sacrificing the former two. As an example, it doesn't matter if that mpeg4 video I/O eats a little more CPU, as long as other tasks don't interrupt its playback.
This sig does not contain any SCO code.
But that's not the title of the article. It's just the title of a horribly written slashdot post. The article itself is pretty reasonably, and makes some excellent points.
But, I suppose, "why linux has failed on the desktop" sounds catchier than "a well known kernel hacker muses on the relationship between software and hardware in PC innovation and discusses the problems he sees in the way the mainline kernel developers address desktop user needs."
I want to agree with you, I really do. But my SuSE 10.1 desktop regularly has fits where it becomes completely unuseable - if I can manage to get a shell, I find that the load has spiked to 5-10 (on a single core system) when the system was doing *nothing*. Just this morning, I woke up, poured a bowl of cereal, walked over to it to read some Slashdot over my Cheerios, and found the system thrashing and refusing to come out of screensaver because the load was so high. This happened while I was sleeping. I had to ssh in from my Powerbook to kill off any processes that appeared to be using CPU before the system would respond to the mouse.
Meanwhile at work, we just tossed an Ubuntu server that should have been reasonably swift, but was regularly DOS'ing itself by spiking to loads of 40 or more several times a day under normal use. A load of 40-60, on a single-core machine! We "fixed" it by spending thousands of dollars replacing it with a pair of multicore beast with scads of memory and fast disks, which seems to overpower the problem.
Then there's that server belonging to a client, a RHES 4 system. When I ssh in through a tunnel to update it, it insists on running the update program as an X client for crissakes. Then it tells me to register the system at a URL, but the URL cannot be selected or copied to the clipboard. This is "enterprise" quality software?
Back at work, the dev server is still a RedHat 7.3 clunker. It has a half dozen developers fine-tuning their infinite loops, fork bombs, broken joins, buffer overruns, and spaghetti code, all day long. It simply never crashes or hangs, never gets slow, and never complains about the abuse it receives. It's a rock-solid dream. Except that it's a damn nuisance to update, since it's so old. And it's only hobbyist-quality software, after all, built before RedHat went all enterprise-centric
Posted, with regrets, from my Powerbook. I'm starting to think that software built for the home user is a safer bet than the "enterprise" shite I'm dealing with every day.
First, the Slashdot article is terrible. The article isn't about "why Linux is failing on the desktop", it's about why a kernel developer who was trying to improve scheduling performance quit.
The scheduling issue is interesting. I used to work on mainframe schedulers, I've done real-time work, and I'm familiar with the issue in game implementation, so I know how hard this is. We could do better than what we have now, but not by some magic fix to the scheduler. We have to look at interactivity as a real time problem.
It is, too. Alan Kay used to say that there is no more excuse for a delay between pressing a key on a computer and having something happen than there is on a piano. We haven't been faithful to that, and it subtly drives users nuts.
One useful idea from the real time world is explicit "sporadic scheduling". Some real time operating systems have this. A process can explicitly request that it wants, say, 10ms of CPU time every 100ms. The scheduler must reject that request if the system is overbooked. If it does accept the request, the scheduler has committed that much resource to the process. If the process overruns its time slot, it loses priority and an overrun is tallied.
This is what an audio or video player should be using. This is how you get audio and video that don't pause or skip. For this to work, the player must be able to calculate, for each system it runs on, exactly what resources are needed to play the current content. This may take more analysis and benchmarking than many programmers are used to doing. It's worthwhile to make overruns visible to tools outside the application, so that users can detect broken applications. To a real time programmer, overrunning your time slot means "broken". You have to think that way.
On the interactivity front, it's useful for a thread to be able to request a high priority for a short period after an event, with a priority drop to follow quickly if it keeps the CPU too long. That's how you get the mouse cursor to track reliably. Of course, the thread that handles mouse events has to pass off all the real work to other threads, not stall the thread handling fast events.
It's also probably time to end paging to disk. When it works, paging at best doubles the effective RAM. But paging inherently results in long unexpected delays. If you want interactivity, don't page. Real-time systems don't. Neither do game consoles. RAM is so cheap that it's not worth it. (1GB starts at US$56 today at Crucial.) Paging devices maxed out around 10,000 RPM since the 1960s, and haven't improved much since. Give it up. Today, paging is in practice mostly a means for dealing with memory hogging apps. (Hint: open "about.config" in Firefox and turn off "browser.cache.memory.enable". so it doesn't save screen dumps of each page for faster tab switching.) It's probably time for Linux to not page interactive processes by default.
This implies an operating system that says "no" when you put on too much load, instead of cramming it in and doing it badly. Open too many windows of video, and at some point the player won't open another one. There's nothing wrong with that, but most Linux/Unix apps don't handle resource rejections from the operating system well.
Two words: Direct Rendering
The issues your describing have almost nothing to do with Linux and everything to do with your graphics card driver (or lack thereof). If you've ever run Windows XP on a system without your graphics card driver you will experience the same thing. In fact, in my experience it's quite a bit worse.
There certainly are some things that could be optimized in Linux, but I those are relatively insignificant.
Seems someone didn't RTFA. CK is saying that while he was pushing the kernel to be speedy on the desktop, all the other developers were pushing it to be speedy on the server, sacrificing the desktop performance (and this is because all the others were big-corporation workers).
And yes i know it isn't "either the desktop or the server" but i can see his POV beeing somewhat right.
It seems they were sensitive to my complaint and have changed the title of the story at apcmag now. The slashdot title for the interview and their misquoting was... unfortunate.