Let me add another reason:

(5) They don't care about the outlook format because Sharepoint is the new closed format. They don't care if your outlook mailboxes (or .doc or anything else) is in an open format because you put it all in sharepoint. You still can read your mailbox with another program, but because the "metadata" of your IT infrastructure (which isn't a single file, but a lot of files with owners and relationships between all them) is stored in sharepoint you're tied to it for the eternity. This is a brilliant move - Microsoft can convice governments that their outlook and office and all their apps are using open formats, but no government will ask about the openness of sharepoint because it's not an application that reads some kind of document.

That myth being moderated as "insightful" yet again....sight.

To start with, "startup speed" and "UI reponsiveness" are two different things. Firefox startup is fast (probably not the fastest, but fast), how would you compare it with Openoffice, which is quite slow? Firefox startup is not a issue for adoption, unlike it happens in openoffice, where it is a real problem. Firefox had startup problems back when firefox didn't existed, and it was firefox who solved them - without dropping xul (or any of the other mozilla technologies, for that matter). Firefox startup "problems" have nothing to do with XUL, if you check this blog you will find that XUL is not related to the startup gains mentioned there.

And when did you hear users saying that Firefox UI is not reponsive? It's just as reponsive as any other desktop app. When the chrome jit gets enabled by default it will be the same as running native code. So no, sorry, XUL is not a problem and there's nothing that "must be done" with it. In fact, it's a nice and very useful advantage for the mozilla project.

Pulseaudio is a system that would be, at best, a minor improvement in a perfect world and a never ending nightmare in the real one.

The current linux audio system was far from perfect. ALSA also was a minor improvement back when OSS + esd were the perfect world.

2. Pulse blameshifts all it's problems to apps and drivers. Ok, apps (open source ones anyway) will eventually get fixed. Drivers won't. Motherboards do not ship with sound drivers for Linux. Linux ships generic drivers for the sound chips on popular systems. There is a big difference.

The alsa drivers have lots of quirks to make sure it works for a given model of a given brand, just take a look at the sound/pci/hda git log output. There's nothing windows does here that linux can't do...

The problems are generally with the sorts of things that PulseAudio wants to do which shows up problems in ALSA.

Well, ALSA can be fixed. Pulseaudio works closely with the alsa devs to make them aware of their problems. They seem to have fixed the problems here.

Why people just can't accept that Pulseaudio can work and does work for most people? I mean, distros wouldn't have been able to push it if didn't worked for most of people. Pulseaudio, Alsa, etc, seems to work exactly as expected. Can't you guys get over it and admit that it's not because we are not "lucky" but because the whole thing does work?

I'm pleased for you. You've been lucky.

No, I have not been "lucky". I had problems with Pulseaudio in the past. I had to unistall pulseaudio. But the problems are fixed now. Just like your problems will be fixed, if they haven't already been fixed upstream. Hey it looks like you guys are overreacting here.

If they were then we wouldn't get articles like this and Lennart wouldn't be as defensive as he is.

Considering the high number of geeks attacking Pulseaudio with stupid reasons, I understand him.

PulseAudio reimplementing ALSA to look like ALSA is just plain silly.

Indeed. Long term maybe we can merge the libalsa functionality in pulseaudio and get rid of it. It would be far more clean. But that doesn't makes pulseaudio unnecesary.

We've had arts and esound largely to cover up for ALSA

Wrong, arts and esound were born largely to fix OSS....

I should...why? Pulseaudio works great here - no problems at all, no high CPU usage, nothing. It's funny that people will happily waste hours of their time getting rid of alsa while they critize pulseaudio for wasting their time with its problems...

It's clear to anyone that has looked into this that most people are very happy with Pulseaudio. All the important distros ship it, and the users that have problems are clearly a _minority_, which is only getting smaller and smaller with each new version of Pulseaudio, Alsa and the kernel. And the geeks that fear changes and love to bitch about are running out of excuses. Linux would have far more problems going back to OSS4 (hey, why I can't set per-app volume, why audio over bluetooth doesn't works as I want?).

Each time Linux redesigns some subsystem there are problems, and we see the same people bitching about how we should use $ALTERNATIVE instead and how Linux is not ready for the desktop. But with the time the problems dissapear and the linux desktop gets more and more solid.

Opensolaris is just as desktop-ready as Linux. Open source desktops are the same in Linux, Opensolaris and BSD: Gnome, KDE, Openoffice, Firefox, X.org, dbus, etc. They all use the same code. From the user POV they are the same.

The one real difference is the hardware support (where Linux is the king). But once you have hardware support in Opensolaris and BSD, the rest of the software stack is identical (and the same applies for servers, BTW).If Linux is desktop ready, opensolaris is also desktop ready.

You don't need them with OSS on FreeBSD and Solaris (for example), or on Linux with the out-of-tree OSS 4 implementation

You don't need them in ALSA either, because dmix is implemented in the ALSA library, not as a userspace daemon.

It's amazing the increible amount of FUD that has been spread about these topics...

Where do you think is the fastest place to process, kernel or userspace?

The CPU doesn't run magically faster when it is running kernel code...

not every app out there is written to use the dmix plugin.

The dmix plugin is used transparently in the ALSA libs, apps don't need to be rewritten to use it...

With a standard configuration, alsa does also

All the relevant desktop distros enable dmix by default...

Please see the OSS implementation in FreeBSD for a lesson in how sound should be done.

Yeah, FreeBSD. And instead, why not take a look at how OS X and Windows (Vista and ahead) implement their sound systems? Hint: Both mix audio in userspace, and Pulseaudio is the closest thing to them in Linux land.

But hey, what do OS X and Windows know about desktops and professional sound systems? Nothing. That's why we all should follow the lead and use cutting-edge technology like OSS and in-kernel sound mixing.

.

Yes, because userspace sound daemons were invented by ALSA. We didn't have these with OSS, not at all....

So? The EC fined Telefónica (a spanish telco) with 150 millions. And the fined EON (german) and GDF (french) with 550 millions each one for being a cartel. And the fined 11 european and japanese companies with 750 millions (including 330 millions for siemens, which is german).

And in my opinion, the EC is just doing what EEUU should do but doesn't.