OSNews

I thought Mac OS X used the Mach microkernel?

Yes and no.

[do correct me if I'm wrong at any point ]

Last time I checked, it was a hybrid.

A bit of history: the mach was essentially a bsd kernel where they started moving more and more stuff into userspace.

What apple did was, take an older mach release and move the bsd kernel parts that was in userspace back into kernel space.

So you got a mach kernel and a partial bsd kernel in kernel space.

:) Yes, definitely a hybrid, but FreeBSD today is a much changed beast from the long-ago BSD fork, as is the OS X kernel. But I get your point.

I am still interested in the scheduler and threading changes mentioned as improvements for OS X... no one says anything about them. But that isn't for this thread.

XNU Kernel which is a hybrid of the Mach with many monolithic parts bolted together.

GAAA! I knew that. (XNU). Brain lapse.

http://developer.apple.com/DOCUMENTATION/Darwin/Conceptual/KernelPr...

Has imho more to do with the stylish userland then the kernel. Not allways does the OSX sheduler shine, especially when you run a big mysql database.

See how you argue out of a server perspective? It may be slower on databases, but audio doesn't stutter regulary, latency is excellent, and even under heavy load the system is just responsive, something I still can't say about Linux, even the newest distros. Also, I find X11 rather unstable, and extremely unflexible: Connecting your Laptop to a beamer to do a presentation just works under Mac and Windows. Good luck on Linux.

This is all basic stuff, that just has to work, if Linux wants to be more than an alternative to Windows for Geeks. How can you possibly deny that!

Uh, no. It was more like:

NeXTStep (OS) -> Darwin (renamed NeXTStep) -> Mac OS X (pretty GUI on top) -> profit

You guys dereference a lot of pointers without checking for null!

Dude, in Objective C you don't have to check for null!

The Mac OS X kernel is worse than Linux. The killer feature in Mac OS X is the USERSPACE.

LOL, you have a sense for humor

MacOS X and the desktop revolution *g*

The latest NVidia graphics driver requires a 4 line patch (the kernel interface code is source viewable) to work with 2.6.23-rc1. The patch is on the NV News and gentoo forums.

Thanks dude for sharing!

I really can't believe you piss and whine and cry about how Linux hasn't made it on the desktop but expect end users to patch the bloody kernel to use a graphics card. You don't have to tell us why Linux didn't cut it on the desktop, you just demonstrated it quite clearly for everybody.

Geek clique. =/

No mainstream Linux distro will be shipping with that kernel unpatched. This is not a problem ordinary users will ever face. That's why god invented distros.

Oh, yes they will and they have.

Buy new graphics card -> discover Linux support is flaky unless you run the lastest nvidia drivers -> oops, the driver doesn't work with your specific distribution release unless you apply this experimental patch from a guy posted on a mailing list (which also happens to break a couple of other things).

No. This patch only applies to this particular version of the Linux kernel, which in this case is the very latest release candidate. You just don't get -RC kernels on mainstream distros. No doubt, any distro that did choose to run this kernel would apply the patch.

The real problem with getting the latest NVidia drivers running on a stable distro is that some distros package the drivers themselves, in which case you're probably stuck with a pre-9xxx series driver, which doesn't support Compiz, which is what everyone wants. If they don't package the driver themselves, then you have to install it manually, which is fine (kind of) until an automatic update updates the kernel and you find yourself unceremoniously dumped to the command line at boot.

Your post is prime example of pure FUD.
A. No distribution ships RC kernels. Period.
If you -choose- to use beta software (Fedora rawhide/Debian sid/Slackware current/etc) you should be ready to suffer some breakage.
B. Microsoft didn't get blamed from not having full hardware support during the beta stages of Vista. The same should apply to Linux.
C. Vista still suffers from problematic hardware support, and yet, everybody is blaming ATI/nVidia and not Microsoft. How come you do not do the same when it comes to Linux?

- Gilboa

... Plus, nothing stops nVidia/ATI/etc from getting their driver included into the main kernel tree.
As long as they keep their drivers closed, you should be pointing your "flaky-hardware-support" fingers somewhere else.

- Gilboa

"I really can't believe you piss and whine and cry about how Linux hasn't made it on the desktop but expect end users to patch the bloody kernel to use a graphics card. You don't have to tell us why Linux didn't cut it on the desktop, you just demonstrated it quite clearly for everybody.

Geek clique. =/"

Mod him down all you like; he makes a valid point.

Baadger, you say that only a four-line patch is needed to run the latest NVidia driver, and you find that acceptable? The fact is, no recompilation should ever be necessary to install a driver. For example, imagine if every time Microsoft released a security update that affected the Windows kernel, all drivers immediately became obsolete. If that were the case, there would be very few working Windows drivers, Windows' much-touted hardware compatibility would fall flat.

In case you're still not convinced, think about another hypothetical situation. Imagine a new hardware manufacturer creating a new graphics card, and wanting to provide drivers for all major operating systems out of the box. For Windows, a WDM/WDDM driver would do the trick, for Mac OS, they could include an installer for a kext. On Linux, the best they could do is go the NVidia route and provide an installation tool that attempted to compile the necessary kernel module. Of course, that wouldn't work if the user didn't happen to have the kernel headers installed, or the necessary compilers and development libraries.

First of all, he isn't making a valid point, because only a fraction of a percent of Linux users will roll their own kernels and run into compatibility issues with proprietary drivers. The rest will get their kernels as a part of the their distribution's service stream, and the distributor will not release a kernel that breaks compatibility with a major graphics driver without also shipping an updated driver. It falls on the distributor to hide these inconveniences from the user. That's why they should be lobbying for free software drivers more than anybody.

Many of the people who argue against interface instability misunderstand what the free software community is trying to accomplish. We don't want any single points of failure in our development community. We don't want to be beholden to a particular company for updates and fixes. On the other hand, a hardware vendor shouldn't have to develop their drivers in a vacuum. If a change is needed to run with the latest Linux kernel, then the kernel community would be more than happy to make the change. The graphics vendors are more than welcome to participate in the kernel project, and they do.

There are all of these boundaries between components in any software system. It doesn't always make sense for developers to draw a line in the sand and refuse to take responsibility for anything on the other side. A little cooperation goes a long way. It's like diplomacy. If international relations stayed the same, we would have longstanding arrangements and no conflict. But sometimes the relationship has to be renegotiated, and this must be done through bilateral or multilateral cooperation.

You can't apply the Windows platform model to Linux, or free software systems in general, because they're based on different theories. Windows is based on backwards compatibility: release once, runs forever. Linux is based on transparency and cooperation: watch the mailing list, try to keep up. You might argue that this makes life more difficult for developers. But it also keeps the development community engaged and somewhat unified. They have to work together and stay on top of changes, which ultimately (I believe) results in software that improves rapidly and forms cohesive systems.

The Windows world encourages complacency and independence. Therefore you get software that doesn't improve very often or very much, and it comes in these monolithic globs that don't share code, functionality, or look-n-feel. I don't quite understand why users prefer a system that makes developers' lives easier at the expense of progress and consistency to a system that makes developers' and distributors' lives a bit harder in order to squeeze out the latest and greatest for the benefit of the users.

Don't worry about the developers. They'll stick around through the seeming chaos, because, ultimately, they prefer hacking free software to proprietary software. It's more fun and more rewarding without any of the hassles associated with proprietary software development. You don't have to reinvent the wheel just because your employer doesn't own a particular piece of software (or because your department can't afford to license it from another department in the same corporation).

It's the distributor's job to put everything together and hide the underlying chaos from the user. The user just hits the update button and all is well in the world. That's all that the vast majority of users want from their OS. They want someone else to make sure that their software stays current and working. Modern Linux distributions accomplish this at least as well as any of the other desktop operating systems.

It's funny but every time a user points out why Linux doesn't appeal to them another Linux user has to answer with a ten page response about why the user is wrong. That is another major problem with the Linux community, your average user isn't going to be bothered to read through pages of excuses.

> Baadger, you say that only a four-line patch is needed to run the latest NVidia driver, and you find that
> acceptable?

Absolutely. I'd rather have the freedom to do that, or have distro's do that for me every quarter, than suffer with Vista for 6 months while the NVidia devs catch up with a major new release and driver API.

> In case you're still not convinced, think about
> another hypothetical situation. Imagine a new
> hardware manufacturer creating a new graphics card,
> and wanting to provide drivers for all major
> operating systems out of the box.
> For Windows, a WDM/WDDM driver would do the trick

And how is the Linux distro/packaging methodology any different to a lot of the crappy OEM's who's drivers are only made available preinstalled with the OS and updated via Windows Update? These kind of drivers exist.

None of the Linux distro's out there really use NVIDIA's installer as it is, these things are compiled and repackaged. To be honest i'm sure the open source community would appreciate a tarball, a Makefile and the binary blobs just as much as they appreciate that elaborate installer.

"And how is the Linux distro/packaging methodology any different to a lot of the crappy OEM's who's drivers are only made available preinstalled with the OS and updated via Windows Update? These kind of drivers exist."

Of course they do, and I see nothing wrong with Linux distributions distributing drivers in that same way. However, what about new hardware?

"None of the Linux distro's out there really use NVIDIA's installer as it is, these things are compiled and repackaged. To be honest i'm sure the open source community would appreciate a tarball, a Makefile and the binary blobs just as much as they appreciate that elaborate installer."

So let's say our hypothetical company making a brand new graphics card does just that, and contributes the source of the driver for their card to the community. Then what? The company stands back and waits half a year for mainstream distributions to include the driver, and hopes that users upgrade?

Actually, the installer more or less contains a tarball and makefile. Just decompress the installer, cd into usr/src/nv and you can make module && make install. I find it quicker and easier that way when playing with customized kernels.

If I'm trying differently configured kernels of the same version, I don't even bother rebuilding the module, I just make install from the module src directory when i've booted into the new kernel.

Of course, I'd hardly call it the most user friendly method, but it's quick and efficient, and besides, people looking for user friendliness likely aren't updating their kernels regularly anyways.

The latest nvidia driver installs perfectly on any stable distro kernel yet not on the latest kernels from the development tree. And that's is acceptible because hardly any average user wants to compile a kernel latest anyway.

> I really can't believe you piss and whine and cry about how Linux hasn't made it on the desktop
> but expect end users to patch the bloody kernel to use a graphics card.

No i suspect most users will just update their driver along with all the other packages on their system by making like ...2 clicks in Ubuntu's Update Manager (for example).

I patch my kernel because I want too.

"""
I'm not trying to restart the flames, but I tried the SD scheduler the other day (as part of 2.6.22-ck1) on my Gentoo box. During compilation of large packages the mouse cursor become jerky and useless, I've never experience that with the stock scheduler and haven't so far with CFS (which I'm running now). *In my very humble opinion* the SD scheduler needed more work.
"""

Con would tell you that you are just a corner case and don't really matter, because all of his other users are happy... except for the few other corner cases like you.

That's why his stuff doesn't get merged.

Fortunately, silly ideas like this one about forking the kernel actually involve a large amount of effort by people who actually know something about developing OS kernels. i.e. people who would take one look at the idea of maintaining separate desktop and server kernels , immediately recognize what a bad idea it is, and file it in the round file.

As long as it's just uninformed people blogging about how "someone should fork the kernel" we have little to worry about.

As long as it's just uninformed people blogging about how "someone should fork the kernel" we have little to worry about.

Yet, we all allow people to vote even though 95% of the people haven't a clue about politics or how to run a country.

"""
Yet, we all allow people to vote even though 95% of the people haven't a clue about politics or how to run a country.
"""

Let's not confuse a meritocracy with a democracy.

If distro's had flocked to Con's work, incorporating his patches into their own distros, and still mainline didn't listen, then we *might* (or might not) have a problem.

The thing is, by and large, distros have not been interested in the patches in question either.

It's inane to consider creating an out and out fork over what basically amounts to a sour grapes reaction by an ex kernel dev who quit because he didn't get a couple of patches merged.

Distros, both desktop and server oriented, have plenty of variant kernel trees to choose from (minus -ck for now).

That said, anyone, even if unskilled in kernel work, is perfectly free to fork the existing kernel, maintain his own, separately, and cultivate a user base of his own. There's your democracy if you really want it.

Edited 2007-07-26 22:55

That's why democracy is dangerous, why they tend not to last very long compared to other forms of government, and why they are prone to being overly fickle. It's necessary to have a body at the top that can flat out tell the people that they're wrong, that what they want the government to do is not in their best interests. Hopefully this body doesn't ignore the people when they're right and doesn't play politics for personal reasons, financial or emotional.

Of course, if this stabilizing body abuses its power and harms the nation, then the people will fork the government. But it will take more than just one bad decision to warrant this reaction. It would take a series of bad decisions, abuses of power, and a seeming disregard for what anyone else thinks. Even then, it might be counterproductive in the short term to fork the government.

Now, Gallup doesn't poll on Linus' favorables and unfavorables, but I'd hazard a guess that Linus is nowhere near Bush country (about 25% favorable, 65% unfavorable, including 24% "angry"). This scheduler debate had been brewing for a while, both patchsets were as ready as they were going to be, and a decision had to be made. Linus had to be The Decider.

In the CFS corner, Ingo Molnar, kernel hacker extraordinaire, primary author of the O(1) scheduler and countless other core kernel features. In the SD corner, Con Kolivas, patchset maintainer extraordinaire, desktop performance guru with a loyal fan-base of enthusiasts. In campaign lingo, Ingo is the experience candidate and Con is the change candidate.

Ingo relies on the fact that most people are happy overall with the O(1) scheduler and the general direction of kernel development. Con tries to rally grassroots support around the idea that desktop users are disenfranchised by the establishment and deserve a new perspective on kernel development. Con has a "where's the beef?" problem in that his solution is not very different from Ingo's. He's relatively inexperienced, and most people are rather dispassionate about his message.

Linus had to make a decision, and while there was little in the way of objective performance evaluation (see my recent post for more on this), the safe decision was obvious. Ingo has proven his considerable chops in this area. He's a pragmatist that doesn't take absolutist positions on anything. He was against plugsched because he worried about scheduler proliferation. Then he wrote scheduler modules to support cascading extensibility. He changed his position on fairness in response to successful results.

Ingo is the kind of guy that you trust with these things in the absence of hard evidence. Linus doesn't trust him for personal reasons. He trusts him because he's proven himself time and time again. This is not a "political" climate that's toxic to the establishment. Yesterday's news was pretty good, but today's news is better. If SD wiped the floor with CFS, that would be a different story. But in a decision that's too close to call, especially in times of peace and prosperity, you have to favor experience over insurgence.

"""
But in a decision that's too close to call, especially in times of peace and prosperity, you have to favor experience over insurgence.
"""

I would only add that the CFS scheduler has a maintainer who has never threatened to take his ball and go home, despite having had substantial portions of his hard work over the years denied a place in the mainline tree.

The alternative scheduler has no current maintainer. Neither does swap prefetch for that matter. And to the person with Linus Torvalds' responsibilities, the reliability of the maintainer has to count for a lot.

For more on Ingo's rejected work, see:

http://lwn.net/Articles/242912/

"Fortunately, silly ideas like this one about forking the kernel actually involve a large amount of effort by people who actually know something about developing OS kernels. i.e. people who would take one look at the idea of maintaining separate desktop and server kernels , immediately recognize what a bad idea it is, and file it in the round file."

You're right. This decision requires a certain knowledge that the author making the claim mentioned in the headline might be lacking.

Today's Linux desktop world offers lots of alternatives - and this is a good idea because of different needs and requirements at the user's site. At some point, distributions get incompatible at system tools or applications level. Imagine, what a joy it would be if they were incompatible at kernel level! :-)

"As long as it's just uninformed people blogging about how "someone should fork the kernel" we have little to worry about."

If someone sees a need to fork the kernel and wants to do it, he's free to do it, because the GPL allows him to. We'll see the results later and discuss them. :-)

On another topic, I mentioned that today's desktops do include a lot of server functionalities, see http://www.osnews.com/permalink.php?news_id=18333&comment_id=25... for related informations. Please note that most argumentation desktop vs. server is done in userland, not in kernel.

Servers and desktops would have much in common if it comes down to kernel level. So a fork would not be needed, but I could imagine different Linux distributions aiming at the desktop or the server user, providing different tools and configurations preinstalled. And, as far as I know, they already exist and do a good job. Some distributions can even be run on older x86 hardware to make a usable desktop that MICROS~1 guys would need to pay USD 500+ for... :-)

I agree, and I'd like to remind everybody that the kernel is a very small part of an operating system. It's supposed to be very generic. It schedules threads, allocates process resources, manages memory, deals with the hardware, and provides basic system services.

There's a lot of trade-offs down there, but the seasoned kernel architect will tell you to stay neutral or at least tunable. By all means, exploit fast-path conditions, but don't optimize at the expense of less probable conditions. What is a "stutter" if not an occasional performance inconsistency? You want the kernel to perform consistently in various workloads. Don't worry about isolated regressions. They can be fixed in userspace.

Which leads me to the broader argument that most of what's wrong with the Linux desktop is because of userspace. Obligatory link:

https://ols2006.108.redhat.com/reprints/jones-reprint.pdf

Con argues that it's hard to dramatically affect desktop performance by working on userspace. Yeah, userspace is massive, and there's a ton of work to be done. But that's where Amdahl's Law says to look. It's going to require a lot more than one man on a mission to iron out the performance wrinkles in userspace. Profiling userspace is not as glamorous as working on swap prefetch, but it's more likely to result in the large performance improvements we're looking for.

Performance will not come from a bunch of enthusiasts trying a bunch of kernels and gushing about how smooth they "feel". Con's followers should fire up their profiler of choice and start hunting for dust bunnies underneath their favorite applications. This way they can actually contribute something positive to the enhancement of desktop performance under Linux and other free software systems.

> remove multiple text terminal capability (Ctrl+Alt+F1, ...): useless for end user

You can do this yourself, it's nothing to do with the kernel as such. I have reduced 7 terminals down to 3, and only ever use 2 (one for X, one to login or use if my frantic experimentation results in X failure or freeze ups).

> remove X11 remote host feature (xhost) : useless for a > desktop => optimize X11 code for "localhost only"

Why? I use X apps across my LAN (using SSH X forwarding) all the time when in bed on the laptop

> Forget Indirect rendering: merge OpenGL and X11 layer

OpenGL direct rendering is already on par with Window's performance and X servers are starting to think about moving stuff (drawing?) over to OpenGL in a backward compatible manner. One of the big snags is the lack of complete open source OpenGL drivers for powerful desktop GPU's.

We also have XCB which is a C API to replace Xlib (but provides Xlib on XCB compatibility)... more optimization for local X server users.

> Use the staircase scheduler of CK (or, at least,
> boost the priority of the desktop/window manager)

I'm not happy with SD as it is, but I like the concept. But as a user I don't want to have to buggar around with nice levels to get things working smoothly. At the moment my desktop feels responsive under load already.

Edited 2007-07-26 16:50

Of course, all you said is right.

I can modify the OS default behaviour. I can use my labtop as an X terminal. I can stay with a display layer that doesn't know about modern 3D-GPU. I can sacrify confort for performance.

But is it really the right thing to do ?

@MORB: I see the difference between kernel and userland applications. But, from a Desktop point of view, X11/KDE/Gnome/... are not "user" applications. These are "system" components. And if a system component needs a tweak/hook in the kernel, why not ?

Edited 2007-07-26 17:02

I agree, especially since this functionality has *zero* impact on performance.

This is ridiculous. When you don't want a feature, don't compile it in the kernel.

It goes for all the bloat argument, really. The only thing that's really bloated with features you don't necessarily need is the source code distribution, not the kernel binary.

Also, I fail to see what desktop specific stuff could be implemented in the kernel that would help the linux desktop. The desktop is the desktop, and the kernel is the kernel. It just seems people are blaming the kernel for the sucess or unsuccess of the desktop, whereas they are two completly different layers.

Forking is a bad idea, because most of the stuff the kernel does is the same on desktop and server, and it is managing resources.
Yes, maybe it isn't perfect for the desktop right now (although using primarily linux at home I don't see what's supposedly so wrong with the performances), but windows is far from perfect as far as performance goes either (yes, a fresh windows install is blazingly fast, but I'm talking about those unacceptable one to ten second delays you experience randomly when for instance opening a new explorer window)

Also, thom holwerda, you advocate micro kernels (that is, a kernel that performs as little as possible and let userspace do the rest), and you also advocate creating a desktop-specific kernel? I fail to see how those two points of view aren't opposed.

Edited 2007-07-26 16:55

Ever heard the name "BeOS"?

Don't confuse the aim (performant desktop) with the underlying technology (kernel type, for instance). It's like asking "you advocate vegetarianism, but also want to eat good food; are you crazy?". No... Indians have done that for many years.

It's just that a micro kernel seems to me as something that aims to be as generic as possible, and wanting a desktop-specific kernel seems to be the opposite thing.

But anyway, when I read this article for instance, I don't see anything concrete. What people would add or do at the kernel level that would improve the desktop? They just keep saying that the current linux kernel does the desktop wrong, but they don't seem to be proposing any specific solution.

It's like they suddenly decided that linux failing its "year of the linux desktop" year after years has to be because of the kernel, and if the kernel is forked in a desktop version, everything will suddenly be rainbow and sunshines on the linux desktop.

All of this fails to account for the fact there are quite a few libraries and layers sitting between the kernel and a desktop like kde - hald and dbus for instance - and they are also very important things that didn't exist until quite recently, and are bound to result in dramatic improvement of the desktop, for instance when Xorg gets around using providing a dbus configuration interface.

My opinion is that desktop is a more complicated thing than it appears to get right, and it just takes time. But it's getting there, just not as fast as people hope it would.

Edited 2007-07-26 17:20

It's like they suddenly decided that linux failing its "year of the linux desktop" year after years has to be because of the kernel, and if the kernel is forked in a desktop version, everything will suddenly be rainbow and sunshines on the linux desktop.

Linux is defitely gaining momentum but doesn't follow the sureal expectations of some people.

The true is that "if the kernel is forked in a desktop version", the code changes will target a "better desktop" = take care of what desktop end-users want.

What are the rationals behind the code changes in the actual linux kernel ?

I agree with you I don't think forking is the answer, but at the same time why can Windows get pretty decent sound drivers even high performance ASIO drivers for their soundcards without having to install a howl new kernel and linux can't. Does it have anythign to do with it being monolithic, I can't possibly see how, but I don't really know all that much about it. I think performance does have to improver in certain areas and sound is one of these areas, having to have a kernel just for low-latency that affects performance on other things and doesn't have everythign else needed compiled is annoying and as a user I don't I should have to compile a new kerel everytime I want anew feature. the kernel should be more versatile than that.

Neither can I since you do not have to recompile the whole kernel to add drivers.

Honestly you might want to read up on Linux in general and performance related issues in specific.

- Eliminating the additional TTYs would make no difference in performance and take up close to zero resources. 6 might be excessive in a modern system but again they do not take a significant amount of resources and are quite useful at times.
- Changing X11 to remove remote X capabilities has been discussed and generally shot down as a dead end for improving local performance using X. Here, more than removing the extra TTYs, you are cutting off a significant sector of Linux users. Beyond people like many of the OSNews readers (including me) who use remote X applications regularly you are also cutting off linux based thin client solutions.

I meant in the sens that you have to install a low-latency kernel to get decent performance on sound hardware. Windows doesn't require this all that is needed is proper ASIO drivers. Does linux have an equivalent to ASIO drivers. I wasn't implying that installing new drivers requires a recompiled kernel. I was saying that in-order to get low latency performance, you need to have a low latency kernel. The low-latency kernel has issues with responsiveness when it comes to UI apps and generally feels less "snappy" than its plain vanilla counterpart. Windows has the ability to have both without any measurable decrease in responsiveness.

I'm an ubuntu user. The only place I use windows is at work and that's it. I use Linux and OSX at home, and I just started using OSX recently. In ubuntu the low-latency kernel works great, but then I can't watch tv on linux since the proper modules for my tv card are not compiled into the kernel. Do I have to compile my own kernel just to use tvtime?

Edited 2007-07-26 18:57

Mostly agreed, also to the part about our OS-wizard TH. Well, it is not true that the kernel has no effect on desktop performance, but there are definitely more important factors to take into account first...

I am sure Con had his good reasons to quit. But as I undertand it, he didn't work on the kernel as a job. It was his hobby. So he can quit whenever he wants and we should still thank him!

Anyway, Con seemed to me to be mostly dissatisfied with the whole desktop paradigm of 1990+ (rather than Linux), which has moved away from optimizied hardware design towards cheap all-purpose hardware where optimization means increase in speed. Well, I can understand that. Dedicated optimized hardware IS superior and damn elegant... but also more expensive, probably often more proprietary, and as opposed to software, it cannot be built and modified by everyone.

About Linux desktop performance I can only say: It is definitely sufficient, even for an impatient person like me. And a lot has been done WITHOUT FORKING THE KERNEL. The leap in desktop responsiveness (with Gnome) from Ubuntu Dapper to Feisty way remarkable, for example. It definitely compares very well to WXP!

And with Ingo's patch, the otherwise standard Ubuntu kernel provides latencies for desktop audio applications (like Ardour) which I could never get under Windows with ASIO drivers... around 2ms total latency. With most of my sound cards (even the really expensive ones), ASIO (with Cubase) was a pain in the A to even get to run. Then, it usually crashed a lot. I simply don't see the dramatic situation which warrants a fork of this overall all in all sophisticated, versatile, and stable kernel. People can optimize their kernel enough by coming up with an optimized build, adding patches, and that's enough for me.

Please remember that modding someone down just because you don't like his opinion is not in line with the forum rules.

Absolute nonsense.

I don't find them useless. Granted, I've never needed six of them (one would do), but it's nice to have somewhere to turn in an "emergency". The real question is what would be gained from removing them. An extra megabyte of RAM maybe? Not a great deal, anyway.



Again, a feature that I find useful as an end-user. Having the facility to run a programme on a remote computer and have the GUI pop up on my machine is a fantastic facility, and is widely used in academic and engineering environments for example. I've yet to see anyone prove that removing this ability would make X better, and conversely, even Microsoft has moved to a client/server-type graphics architecture for Vista.



I'm assuming you're talking about Xegl, which is indeed a good idea. But it's a long road there, and in the mean time AIGLX (along with hardware-accelerated XRender) provides a good solution. In addition, there are (as I understand it, at least) some problems in a 100% OpenGL solution; for example, OpenGL doesn't guarantee pixel accuracy, which is required for a GUI toolkit.



I don't know anything about the staircase scheduler, but boosting the priority of the window manager isn't necessarily a bad idea. That said, I've never had a problem with Metacity becoming unresponsive respond under heavy load, whereas I have with Compiz (even though the latter is meant to be hardware accellerated), so maybe the problem is with the window managers themselves.

Of course, it's a great feature...