Kernel 2.6.31 To Speed Up Linux Desktop 360
Dan Jones writes "As the Linux community looks forward to another kernel release, the kernel hackers have been working on improving the memory management so that the X desktop responsiveness is doubled under high memory pressure. The result is an improved desktop experience. Benchmarks on memory-tight desktops show clock time and major faults reduced by 50 per cent, and pswpin numbers (memory reads from disk) are reduced to about one-third. Another improvement coming with 2.6.31 is kernel mode-setting support for ATI Radeon graphics cards, enabling faster user switching and a more seamless startup experience. Peripheral developments that will also improve the Linux desktop experience include support for the new USB 3.0 specification and a new Firewire stack. Even minor Linux releases have heaps of new features these days!"
Funny how Windows and Linux go opposites (Score:0, Interesting)
MS takes the drivers back to user mode after touting the kernel-mode as a performance plus.
Based on my experience with 2008/Win 7 and ATI, I think the display drivers belong firmly in user mode.
I've never had my OS punk out because of a graphics bluescreen. The desktop manger and explorer may have needed a restart, but no data ever stopped streaming or got corrupted.
Re:Even minor releases? (Score:3, Interesting)
Benchmarks (Score:5, Interesting)
We just need an alternative to X (Score:2, Interesting)
Just like folks at Apple realized with their OS X, we in the Linux world, need an alternative to X. I heard that Google Chrome OS will get rid of it entirely. I would like to hear from anyone who disagrees.
Re:We just need an alternative to X (Score:3, Interesting)
X works really good for what it's designed for and I'd hate to have to live without it. That said, what I also would like is a custom version for gaming which turns down or off features not needed for gaming. Wouldn't it be nice if users could build a custom X as easy as custom kernels?
Re:Obligatory XKCD (Score:5, Interesting)
Actually the fault is split. 2D acceleration in Linux for most video drivers is shabby at best.
On the other hand, Adobe doesn't really put that much engineering force into X11 optimizations. Adobe Flash on a non-accelerated Mac OS X (hackintosh using the included Vesa 3.0 driver) is still faster than on X11/Linux.
I can't really blame Adobe for this. There are quite a lot of ways in which you can accelerate SOME drawing operations, but they are not available on all desktops. Clutter comes to mind right now, but it's not really the best option for QT/KDE users. It's hard to create an accelerated, desktop environment independent piece of software.
Re:Obligatory XKCD (Score:4, Interesting)
Linux isn't broken because Flash sucks, the "Ready For the Desktop" moniker is broken if people consider it to imply Flash support. Flash is a closed technology (the spec is only open if you're not writing a player), which puts any problems with Flash playback anywhere squarely into Adobe's hands. If being "ready for the desktop" implies "Adobe plays nice with you" and there is nothing you can do if they don't, something is really wrong. What is the Linux community supposed to do, hold Adobe at gunpoint until they fix Flash?
I'm not saying Linux is otherwise ready for the desktop (and complaints about issues with Linux desktops themselves are perfectly okay), but Flash brokenness is a silly example.
Re:Obligatory XKCD (Score:3, Interesting)
The same way mp3 became a standard and "linux" users must install codecs "at their own risk".
The same way linux-verboten WinModems became a standard that faded only when they couldn't keep up with ADSL.
The same way Realtek and Broadcom WiFi cards have become a standard in most notebooks (and some desktops) and they still perform very poorly under "linux".
The same way NVidia and ATI have become the video adapter standards and none has yet got full support (not even mentioning double screens) under Linux.
I'm not blaming linux for any of this, but I do blame those that cry over the fact the rest of the world has accepted and can get along with those de facto "standards".
With the right kexts and a couple of clicks, my Leopard hackintosh install gets a much better grab of my hardware than both my Ubuntu and Debian installs, over which I'm endlessly trying new drivers and recompiling the kernel.
Re:Obligatory XKCD (Score:3, Interesting)
Users have a choice with every one of those 4 examples. They do not have a choice with Flash, as there is only one vendor with a half-decent implementation and they block any potential competitors from using their specification.
Re:We just need an alternative to X (Score:3, Interesting)
X works really good for what it's designed for and I'd hate to have to live without it. That said, what I also would like is a custom version for gaming which turns down or off features not needed for gaming. Wouldn't it be nice if users could build a custom X as easy as custom kernels?
I agree that X works well for it's designed purpose, and that said I agree that we have further need as we move beyond what it was designed to do (and into the issues we run into with a modern desktop, such as gaming).
I find I struggle a bit with X on each new install (I like to switch around and use different Linux distros as the mood to tinker comes and goes). After working in an OSX-based development shop with Logitech MX1000s at each desk, I became spoiled on the 12 buttons (10 if you don't count the wheel's scroll up and scroll down), especially combined with Expose. The same features are available in an X desktop environment using Compiz Fusion, and as is usually the case, the Linux equivalent of Expose can be configured to do a whole lot more.
The first issue with X is getting my mouse configured. I can get all mouse buttons to work, but I usually find myself searching and coming to the xbindkeys method after making minor changes to X's config file. I never remember just what I did to get it working the last time, and have to play around for a while to first figure out what the buttons are, and have to resort to assigning key bindings to them (which I also do for some of them in OSX, as something like ctrl-alt-right and ctrl-alt-left get the job done for switching desktops since I already have that shortcut in place).
There are desktop-environment specific issues (Compiz refusing to take a click to toggle all windows, for example, instead required the button be held down), but the main annoyance was the bindings not being captured by video games (WoW was the game at the time). WoW ran great on my Linux system, but to use my mouse properly (which was important for in-game macros), I had to exit X, swap the .xinitrc files, and start up my "WoW-configured" X, which launched the game and allowed me to use my mouse bindings without anything else competing for them. I didn't get around to including ventrillo into that setup.
Now these are two different things:
1) It's been a major pain to set up my fancy-pants mouse to be fully recognised in X.
2) Once set up, there are conflicts between the non-X desktop environments that use the bindings and any applications launched.
The first could be made easier, but as the mouse is supported by evidence of me getting it working, repeating the process each time is no one's fault but my own. If it's a serious enough complaint I should even write a tool to do the configuration. I suspect that it would be useful to some, but not all, due to the main issue seen in #2.
There seems to be structural functionality lacking in X that applications can use to share resources, such as input devices. I don't expect X to have been designed expecting a KDE / Compiz Fusion environment to compete with WoW running from Wine, and the last thing I'd like to see is X development push entirely in that direction, since obviously we still need it's server/network features without bloating it with features that won't be used in most cases where those are needed. Still, I'd like the option for universal recognition of mouse buttons beyond the 3+scroll model in all applications that use X, with rules about which applications one wants to take the input. Perhaps that's a window manager issue, but with so many window managers out there, it seems like there should be a solid framework written into X that provides a standard way for the different desktop environments to handle such things.
Re:Obligatory XKCD (Score:3, Interesting)
Not anymore. (From http://en.wikipedia.org/wiki/Adobe_Flash [wikipedia.org])
In May 2008, Adobe launched the Open Screen Project (Adobe link), which made the SWF specification available without restrictions. Previously, developers couldn't use the specification for making SWF-compatible players, but only for making SWF-exporting authoring software. The specification remains incomplete, however, as it does not include any details regarding RTMP or Sorenson Spark,[27] both of which are widely used to distribute video through Flash.
So the only missing piece is the video encoding and that can be handled by mplayer already.
Re:Obligatory XKCD (Score:3, Interesting)
As an ex-Mac user, and a video game fan, the rule is that the Mac version of the number 1 game usually comes out about 3 months after everybody else has already gotten sick of playing it to death.
Re:We just need an alternative to X (Score:3, Interesting)
Now if you look at the aspects of it to just put pixels on the screen from things running locally it performs just as well as other display methods (eg. nvidia drivers on X vs nvidia drivers on XP - same performance). If you can think of real examples instead of dredging up the stuff from the people that were complaining about how they didn't need this slow GUI thing when text was fast from twenty years ago then please share. If the stuff running on top (eg. gnome) is slow then you ditch that for something that isn't.
Re:Obligatory XKCD (Score:3, Interesting)
You're sure about that?
http://koji.fedoraproject.org/koji/buildinfo?buildID=126369 [fedoraproject.org]
* Fri Aug 07 2009 Kristian HÃgsberg - 2.8.0-4
- Add dri2-page-flip.patch to enable full screen pageflipping.
Fixes XKCD #619.