Similar feelings here, this "it kinda works"-feeling was the reason why I switched to Linux in the first place. What are your plans? Where do you go when you 'leave'?

I switched all my servers and desktops to FreeBSD. It's like going back in time in many, many good ways (commandline/text-config focus, less magic, etc.), and one bad way (HW support).

One more for FreeBSD, and the hardware support issues are a lot less frustrating than for example what I remember of Linux in the early part of the last decade. I expect with the renewed interest in FreeBSD because of systemd, that we'll see things improve greatly overall (for example the million dollar donation to the FreeBSD Foundation).

I'm also planning on switching my two Linux boxes to FreeBSD.

To a distro that doesn't force things down the throats of its users in the same degree Ubuntu et al. do. e.g. Gentoo. (You can even run a FreeBSD kernel in Gentoo if you want.)

That isn't to say it's been all rosy in Gentoo-land. It was an effort to keep Gnome3 off my system, to keep the existing Gnome2 versions of everything until MATE (and the Gentoo community packaging) was ready enough to replace Gnome2. But my system is happily free of Gnome3, systemd, and pulseaudio. And because Gentoo doesn't really have release versions, I can keep my other packages up to date indefinitely.

I do wonder how much effort and forks will be required to keep Gentoo, well, Gentoo going forwards, as more and more stuff either is either lumped into Systemd or depends on/assumes its presence.

One can already see how you at least have to keep the libsystemd package installed on Debian's latest, even if you use something other than systemd as the init etc, or else apt throws a tantrum.

http://ewontfix.com/15/ may be the most interesting read in all this. Notice how everything but dbus and the systemd lib have various issues. And if kdbus hits the kernel, systemd is poised to position itself as the mediator between (legacy) dbus and kdbus.

All in all there is some serious "one true way"-ism coming out of the systemd camp.

Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?

Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.

Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk.

The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program.

So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.

If you end up with a giant ball of hidden complexity, that's a strong indication that you're dealing with that complexity at the wrong level.

Both PulseAudio and systemd seem to have the "throw everything out, start from a beautiful abstract interface and work down" mentality, which is a recipe for the mess that they've ended up as. Sometimes the best thing to do is pass the ugly complexity one layer up - which is, I think, one of the things that Unix does mostly right.

PulseAudio supports network streaming, but it's certainly not the main selling point. Important features are:

* Mixing several streams in software, if there's no hardware support (th e FreeBSD sound driver does that as well)

* Dynamic switching between several audio interfaces without stopping the stream, e.g. switching to a Bluetooth headset during a phone call

* Reducing power usage by supporting different latencies for each client application, and then running the hardware with the lowest currently requested latency

Supposedly network transparency came later.

Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call).

Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage.

Also, i don't think Alsa had dmix (user-space software mixing) at that point in time.

As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.

Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.

Particularly that it doesn't work. I always hear about people for whom It Just Works, but that hasn't been the case for me over the course of a couple handfuls of machines. For what it's worth, LP and his gang seem like people for whom "it mostly works" is satisfactory, and that's not something I'm comfortable with in something like an init system, to be frank, because what about when it doesn't? The answer there unfortunately seems to be WONTFIX or outright hostility.

Your implementation doesn't work. My question is what part of the design is flawed?

> Over the course of a couple handfuls of machines

That's more than "your implementation" considering that it spans at least ten machines across about the same number of distros including Fedora (and one FreeBSD). But it's cute that you're so quick to say it's "implementation" when it's clearly broken across so many different environments.

Pulseaudio is a stinking pile of shit.