Slashdot Mirror
Lennart Poettering: BSD Isn't Relevant Anymore
halfaperson writes "In an interview with LinuxFr.org, Lennart Poettering speaks freely about his creations, PulseAudio, Avahi and systemd among other things. Naturally, what has stirred up most of the discussions online is Lennart's opinions on BSD. Following the recent proposal to make Gnome a Linux-exclusive desktop, Lennart explains that he thinks BSD support is holding back a lot of Free Software development. He says this while also taking a stab at Debian kFreeBSD: 'Debian kFreeBSD is a toy OS, people really shouldn't misunderstand that.'"
Something that doesn't make him sound like a complete idiot?
The core of Mac OS X borrows heavily from BSD, so one could legitimately argue that BSD is now the most widespread UNIX variant. In fact, I wouldn't swear to it, but I suspect that makes BSD (and Mac OS X, specifically) more popular than all of the other Linux and UNIX variants put together.
You'd pretty much have to be living under a rock to think that BSD isn't relevant. Either that or you have to believe that Windows is the way of the future. Take your pick.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I don't take anything from this guy seriously after dealing with Pulse Audio on a few systems. The shit never improved and only added a layer of incompatibility to systems that ran just fine using ALSA by itself.
This guy needs beaten just for this.
I don't blame him for creating PulseAudio. I blame the distribution maintainers for having the poor judgment to make it the main sound system for so many distributions. It would be one thing to have a sane default like ALSA and then have PulseAudio available in the repositories for those who really want it.
For my friends who use Linux, the first thing I do whenever a new distro is installed is to check if it is using PulseAudio. If so, I remove it and replace it with ALSA. Suddenly issues related to audio playback go away and everything just magically works. Oh and they easily have a proper mixer without jumping through hoops, too, which is handy considering some of them are using 5.1 surround sound and/or bluetooth headphones.
The first headache I had with PulseAudio was when I tried to run something as a different (normal) user account and audio wouldn't work. There was no meaningful error message. There was only a "connection refused" error in the terminal. As it turns out, this is because PulseAudio has to be run by the user and it is recommended not to run it as a system-wide daemon. User A was running the user-daemon and User B was denied access to it as a consequence. They both could not run their own, well they could but it wouldn't work, as that'd be far too easy. Rather than screw around trying to get that to work I just used ALSA since PulseAudio didn't do anything I needed it to do that ALSA couldn't do with none of the hassle.
In case you wonder why I was running something as another normal user, it was for using Windows programs in WINE. I always prefer to do that with a separate user account that isn't used for anything else. This special WINE account has additional restrictions because I do not trust Windows programs -- they might phone home, they might contain malware, they are binary blobs that cannot easily be inspected, etc. The point is, Unix and therefore Linux are multi-user systems. You expect to be able to have multiple concurrent users running programs without issue.
PulseAudio smacks of the walled-garden model, where as long as you are a very average user who does extremely predictable things that they have decided to allow for, such as only having one active user on the local system, then you have few or maybe no problems. As soon as you do anything even the slightest bit unusual (which multiple users on a *nix system hardly is) you start running into brick walls. To that I say "no thanks, not for me". If I wanted that experience I'd use Windows. If ALSA were a barely-functional, poorly designed sound system I could at least understand why PulseAudio exists and why it is becoming so popular. As far as I can tell it's a burdensome solution to a problem that doesn't exist.
It is a miracle that curiosity survives formal education. - Einstein
Before PulseAudio it wasn't possible to turn on a bluetooth headset and have any audio that was playing through your speakers automatically start going to the headset instead.
back in the late 1990s, i had a flamewar on an irc channel with a guy from redhat, screaming at me that there was no reason anyone would want to have two programs play a sound at the same time.
This issue has been going on for a long time, and each time a BSD developer asks to see solid docs so that he/she can port the API to be used on FreeBSD they get a bunch of incomplete specs that are absolute shit.
http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors#c14587
Warner Losh asking for good specs to implement udev on top of devd which has done the things that udev now does for years.
cat
Working audio was what made me switch to FreeBSD in the first place. This was back around 2001. The state of the art was something like this:
Applications played sound by writing writing to /dev/dsp. This was a fairly standard way of playing sound, based on the Solaris, and supported by most *NIX systems. OSS defined a set of ioctls for controlling playback, and these worked everywhere. There was one slight problem: most implementations didn't support software sound mixing if your hardware (like most cheap AC97 CODECs) couldn't do mixing in hardware. This meant that only one device could write to /dev/dsp at once, meaning only one application could play sound. KDE and GNOME both had their own (incompatible) sound daemons, so multiple KDE or multiple GNOME apps could play sound at once, but not both. I was using a KDE Jabber client, a GNOME email client and wanted to get audio new message notifications from either. I also wanted XMMS (which wrote directly to /dev/dsp) to play music in the background, and I wanted to play BZFlag! sometimes and have its sound work without breaking anything else.
In Linux land, there was ALSA. ALSA did sound mixing, but it required your applications to be rewritten to use it. Some sound cards only had ALSA drives, some only had OSS drivers. A few had both. ALSA had a half-arsed OSS emulation mode, but that broke various other things, and still didn't let multiple OSS applications play audio at once.
FreeBSD 4 had a virtual channel (vchan) mechanism. You had several /dev/dsp.n devices. /dev/dsp was a symbolic link to one of them. I set the KDE sound daemon to use /dev/dsp.1, the GNOME one to /dev/dsp.2, XMMS to use /dev/dsp.3, and whatever other app tried to use /dev/dsp got the /dev/dsp.0 channel (typically games, running in the foreground). All of my running apps could play sound at once and, after a small amount of initial configuration, it Just Worked.
I didn't stay with FreeBSD 4 for long on the desktop, I started using the FreeBSD 5 betas. This was a really unpopular FreeBSD release, because it was only about as stable as Linux at the time, which most FreeBSD users felt was completely unacceptable. It improved the sound system so that the vchans were automatically allocated. Now, things worked just as well as they did with FreeBSD 4, but I didn't need to configure anything. Apps could just open /dev/dsp and they'd each get a new vchan, up to a configurable limit (I set it to 16, which seemed to be more than I needed).
Now I use FreeBSD 8. As well as the earlier features, it has a new low-latency sound mixing path, per-vchan volume controls, and full OSS 4 support. Oh, and it even has a compatibility layer, so if I run old code that uses the OSS 3 APIs and tries to modify the global volume control via /dev/mixer, I can make it only modify its own vchan's volume.
Meanwhile, Linux developers were told that, actually, they shouldn't use ALSA, they should rewrite their sound code yet again, this time for PulseAudio. And people wonder why I hate having to support Linux...
I am TheRaven on Soylent News