I think you're confused. Alt+SysRq+K is one of the Linux "Magic Keys" http://en.wikipedia.org/wiki/Magic_SysRq_key it kills all processes on the current VT, not just X. Most modern X implementations will still work with Ctrl+Alt+BkSp but you now need to do it twice and the first time it makes a rather ominous "beeeeeeeeeep" at you to warn you that you maybe about to make a bad decision....

So this is hardly an "Ubuntu decision" (like most distros they just package up what's already there, mix it up with a few good and a few bad ideas of their own and paint it nicely).

Well IMO both the Gnome and KDE flavours of Mandriva are very well put together, maintained and supported. I tend to jump between DEs (and run apps from both when running either too), and I can't say I've ever found either lacking!

Well no one is forcing users to upgrade! People can stick about for a while and see how it goes for others.

Also we just released Mandriva 2010.0 (release notes and Errata). The mirrors are currently syncing and the main download page is waiting for that to complete before offering direct downloads but the torrents are out now..

IMO Mandriva offers excellent Gnome and KDE flavours, so feel free to take the most appropriate "Mandriva One" live CD for a spin.

Yes consolekit is the bit to work on when dealing with multi-seat systems. Udev and consolekit very recently were changed to support seats a little better but there is more work needed in that area. Pulseaudio already integrates to consolekit, so using this system is the way to go.

In the mean time, if you have tow sounds cards (e.g. one for each of you) you can do a "poor mans" setup but each logging in once, and then being nice ot the other but loading pavucontrol and choosing the "Off" profile for the card not meant for you. This doesn't work if you swap seats tho', but for this kind of setup, I'm guessing that doesn't happen too often anyway. Like I say support in consolekit is coming.

NAS and ESD are both obsolete, so are no longer developed and should not be used.

PulseAudio does not have it's own SSH piggy back implementation like X11 but we do piggy back on to the X11 one. Really openssh needs to be refactored to make the X11 forwarding modular and we can then write a PulseAudio module for SSH so that it can all be done properly.

OSX support is also underway but it's done by those people who are interested and only two people are really interested right now, so the progress is a little slow, but getting there.

The routing policy you describe (when you see it, use it) is now implemented in PA git master with module-device-manager, although currently only a KDE gui for this is available (it's not the way Gnome want to work, but it is the way KDE want to work, so I accommodated that).

And the disto I do packaging for is certainly not backed by a wealthy individual. It just takes someone who actually cares to get the distro integration right, not money :)

Well straight away, you're trying to do some kind of specialist setup, which is always going to mean you're going to have to look into things firther.

Also, PulseAudio is not something that is generally targeted at end users, it's targeted at distros who have the experience and knowledge to tie together all of the components.

You are also the first and only person who has complained that PulseAudio offers (for the most part) a drop in replacement for pure alsa via the use of an alsa plugin. This is *only* way that pulse could get any kind of acceptance at all. It's not expected that applications should need to write direct pulseaudio support, they should go through some kind of abstraction library. For the most part, libasound can serve that role well, provided you stick to the Safe ALSA API Subset that has been documented.

If all you want is per-app volume control, then I don't think it's all worth it for you, but if you want a proper multi-user desktop experience, where the sound follows the *active* user, not the inactive one (i.e. a standard desktop), reduced power consumption, bluetooth support, Apple Airtunes support, UPnP support etc. then PulseAudio is the way to go.

But free software is about choice. If it's not right for you, that's fine, don't use it, but there's no need to bitch about it either.

Do you care to elaborate on which parts of the implementation "sucks"? Is it the client/server model? The fact it uses a fully asynchronous, zero-copy, lock free core? Or something else?

I'd be interested to have a technical discussion about this, but obviously I'd need to more more than the equivalent of playground banter: "girls smell". :p

Do I think pulse has a sane design? Yes I do for the most part, tho' I wont pretend to know it inside out.

The article you quote there (which was covered in /. before) has so many glaring errors I just don't know where to begin! If you're genuinely interested (and it sounds like you are), then I'd strongly recommend reading the comments on that thread, particularly the ones made by "dawhead" who I believe is actually Paul Davis who wrote Jack and Ardour and is about as much of an expert as you'd want on this stuff. He shows the patience of a saint in explaining (repeatedly) to the blog author where his analysis, opinions and criticisms are just plain wrong, providing very solid background as to why.

Paul is not a PulseAudio fanboi by any stretch of the imagination - he's clearly Mr Jack, but even he openly admits that some of the things going into pulseaudio are pretty smart. He doesn't believe it's necessarily the final ultimate solution, but certainly reckons that some parts of it could very well be used. With Linux it is all about evolution. Pulseaudio today is quite different to what it was a couple years ago, and I'm certain that it will continue to evolve and ensure that those good bits are matured and nurtured, and the missing bits are incubated.

The second or third last comment ("Executive Summary" on page 2 of the comments) also wraps things up nicely IMO.

Everything you've said is working FINE for me with PA. So whatever problem you're having, I can only assume it is outwith PA. As for "unmanaged" complexity... that's the problem right there? Did you just run "make install" or did you run a disto that managed the complexity for you? You should be doing the latter. If you distro doesn't manage that complexity for you, complain to them.

And for what it's worth UPnP and Bluetooth were very much plugged in later. The architecture allowed that to work with minimal hassle. For me that's good design, not over architecting.

Yup, just see the "About" page on my site. Some of the articles under the "KDE" tag have more info about the specific patches needed to make this all work. Feel free to comment etc. on the site and I'll try and get back to you.

Nicely said :)

Well I'm a true Scotsman, and a technical person and certainly agree with Lennart on this front. Don't know what that means overall :s

Really? Your system sucks then because on mine it works fine! Have you submitted a backtrace for this issue? Even a bug report?

If you haven't then the bug doesn't exist, plain and simple.

Well, on my system (4 year old core2duo) it sits between 0 and 1% even when playing...

Not heard of any problems here but is there a bug report about this?

I'm not experiencing any problems. It's been pretty stable for me for quite some time? What version have you been using?

If you even had a tiny clue about things, you'd realise how ridiculous this statement is. OSS is old news. The API is not going to help us move forward. Have you even seen some of the stuff from the latest Linux Plumbers conference? Paul "Jack/Ardour" Davis summary is probably the best one I've read about why OSS is not sufficient and these are decisions that were made years ago... where on earth do people get this "OSSv4 causes world peace and solves every problem ever" option from? They've clearly never actually *looked* at things for themselves that's for sure.

Yeah because that kind of code writes itself right? All we need to do is get everyone to catch a fairy at the bottom of their garden and then stuff it into their CD drive... the code will be there by morning!

There are probably about four people working on linux sound as a paid job... Lennart, Takashi, Jaroslav and Paul... Maybe a few other too, but typically in very specific disciplines/hardware, but certainly none of them are going to start working on OSS that's for sure. So where is this magical work going to come from?

This is us getting it right and this is that pain.

Yeah, because *my* computer is so shit it can only decode the DVD audio in real time and there isn't any way that it could possible decode say 20 seconds worth of the audio, and pump it into the audio layer in anything under 20 seconds right???

This is *exactly* the point I'm making when people here the word latency, they assume completely the wrong thing. You go on to say "As such you need to keep latency as low as practical"... which is where I switch off, as from this comment it's clear you've not read my posts, so I'll just ask you to read them again.

Now, like I say, you do not want high latencies at all times. Certain circumstances mean that this is simply not possible, e.g recording sound and playing it back or some other interactive sounds, but there are also a lot of applications where it certainly is a good thing.

And all this "windows has done this for years" crap people keep spouting, should read up about some of the "new" features in Windows 7 audio stack that are features PulseAudio has had for a long time! They are playing catchup.

This is why distros play an important job. Compiling your own kernel is a complex job that 90% of users shouldn't have to care about. Even with a shedloads of documentation, you still need to keep on top of kernel developments to ensure you're using the right options and the right approach. Ditto with configuring pulse. I don't deny that it's a complex beast to configure correctly, but that's why we have distros. Just like we vote in politicians to read policy and make decisions on our behalf (why everyone shouts "referendum" whenever anything vaguely complex comes up is beyond me - the people voting in referendums do not read the policy in question to make informed decisions - they read the red tops... insane), so we chose our distros to take care of this stuff for us. Users should not have to venture beyond a few ticky boxes.

And none of these problems were there before the Linux kernel, so obviously it's the one to *really* blame right?? Argument fail. :p