Lennart Poettering: BSD Isn't Relevant Anymore 460
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.'"
In related news (Score:4, Insightful)
Apple claims HTC is no longer relevant and Ford also claims GM is no longer relevant.
Seriously you're asking a linux developer his opinion on BSD? What answer were you expecting?
PulseAudio? (Score:5, Insightful)
This guy needs beaten just for this.
Re:Holding back? (Score:5, Insightful)
Too bad they didn't port the FreeBSD audio. It actually works.
Re:Linux itself isn't relevant anymore (Score:4, Insightful)
That was my thought, BSD gets a bit of a license in that regards because it isn't trying to take over the desktop space. There are a small number of OSes that are related, some are focused on the desktop environment, but they're more focused on polish and actually working reliably from release to release and evolving the experience over time.
Linux OTOH varies enough that I can't really make a particularly fitting statement on that. Some distros are run by people that know what they're doing and focus on fixing things that are broken, others like Ubuntu are clearly run by crack smoking monkeys and you end up with unusable garbage or releases that have nothing in common with previous releases.
But with the dozens of distros and all the talk of being relevant to the majority of users, it's hard not to view it like the short bus kid that thinks he's going to be valedictorian. At the end of the day, most of what's wrong with Linux is the direct result of trying to copy Windows and scoop up the users even if things like automounting were stupid to begin with.
Re:In related news (Score:1, Insightful)
I guess he thinks Apple is no longer relevant too since MacOSX/iOS are both based on BSD.
Re:Holding back? (Score:4, Insightful)
As for Alsa/another sound server replacing OSS, OSS do the mixing (and resampling?) in the kernel space, citing latency is one of the reasons, while alsa let userspace programs the jobs. IMO, that kind of works does not belong to kernel space, so I prefer alsa.
Regarding to pulseaudio, dmix is fine, but pulseaudio is better with features like glitch free playback (ironically, this is the reason why pulseaudio glitches so bad on some systems with broken drivers), you can set the resampling algo, per stream volume control, flat volume (another problematic feature), and as some people said, it is the only setup that allow output via bluetooth devices but I haven't tried it yet. The main reason for many problems related to it is the horrible audio drivers on Linux (as always), so you can't exactly blame pulseaudio, at least it always has fallback mode, and the distros never set them as default. Back when pulseaudio was first integrated into Ubuntu (around 8.04, right?), it didn't work well for me and stop working for many other. But now, most people I know have absolutely no problem with pulseaudio. PS: Aside from dmix, there are several other sound servers like arts, esd etc.... too, I'm glad that we get rid of all that and now pulseaudio on alsa is the standard.
The in-kernel audio drivers have always worked flawlessly for me. I have never had problems with latency, glitches in playback, etc.
But let's just assume, for the sake of argument, that I just got lucky. Let's assume most users have problems that can be directly attributed to shoddy in-kernel drivers (as highly unusual and unlike the typical linux kernel experience as this is...). The solution to that is to put available development effort towards fixing those drivers. They are, after all, the low-level foundation of the audio system. The solution is emphatically NOT to add a redundant software layer on top of broken drivers. You do like to solve problems by fixing things where they are actually broken, right? That's the sensible thing to do. That's the correct use of the talent of developers who specialize in programming sound systems.
Arts (what a piece of vulture shit that was) and ESD are not on equal footing with Dmix. Dmix is a small, relatively efficient, rather problem-free mixer for sound cards that do not have a hardware mixer. It just works and it actually serves a purpose, unlike the sound daemons. ALSA will use a hardware mixer instead of Dmix if you have high-end hardware and one is available. I have never known Dmix to introduce playback stuttering, idiotic problems with multiple users, or any of the other problems you can easily find when you do a Google search for Arts or PulseAudio. I have also never known Dmix to use any noticable amount of CPU.
Again I will reiterate. PulseAudio is a middleman standing between the applicating wanting to play sound, and ALSA. How exactly is that going to fix an inherent flaw in the underlying ALSA system? Hint: it will not and cannot. If there are such horrible problems with Dmix (that somehow I won the lottery of never personally encountering), that kind of development effort should be put towards fixing Dmix. Doesn't that make a lot more sense?
always wondered why PulseAudio sucked (Score:5, Insightful)
now we know.
the developer lacks humility.
Re:PulseAudio? (Score:5, Insightful)
Word. Systemd. What a pointless masturbatory waste of effort. That's just one area where BSD, far from not being relevant, is right. They don't fuck with what works fine.
ha ha (Score:4, Insightful)
Linux's vaguely meritocratic approach has obliterated the BSD cliquish approach, period.
Does any other OS have multiple competing teams writing the scheduler? How could anyone possibly compete with that? Seriously!
Conversely, the LLVM will eventually obliterate GCC for the same reasons, multiple participants engaging in healthy competition. Oh, plus the LLVM simplifies writing compilers for virtually any language.
p.s. Does APL/K/J have an LLVM based compiler yet?
Re:Holding back? (Score:3, Insightful)
PulseAudio isn't a bad concept, it's just that it doesn't work properly for far too many people. But the widespread adoption of tablet, smartphone and other "slim computing" devices does kind of speak to a need for a software-agnostic way to stream audio from server to client - requiring every application that wants to do this to implement streaming isn't a very sensible solution to the problem IMO.
Lennart (Score:4, Insightful)
Re:In related news (Score:5, Insightful)
It's interesting that the question implies that Linux is leading the charge in defining new APIs. Everything listed has a FreeBSD equivalent that predates the linux version:
cgroups -> jails
udev -> devfs
fanotify, timerfd, signalfd -> kqueue
Of course, the Linux developers decided to reinvent them all making compatibility impossible. I guess you could argue that the Linux versions offer some extra features over the FreeBSD versions, but from a user and developer perspective, the FreeBSD versions seem more complete and stable (see jails vs cgroups).
Re:Holding back? (Score:3, Insightful)
The right way of dealing with it, IMO, is more or less the pulse-audio way. ALSA is doing a lot of stuff in the kernel that probably should be in userspace, and cramming your entire bluetooth stack (plus any other audio sources and sinks that might be hotplugged) into the kernel just to handle audio is architecturally the wrong fix. You want to take a step back, figure out what needs to be done in the kernel (analogous to kernel modesetting for video), and pull the rest of ALSA's functionality into a userland daemon analogous to an X server.
But PulseAudio is (still) immature, and in some ways (particularly its braindamage pertaining to multiuser systems) just plain wrong; I'm in no way advocating for its adoption now, much less back when distros started adopting it.
Re:Holding back? (Score:3, Insightful)
Sounds like everything you could do with JACK years ago. Pulseaudio was written because... well... there is no good reason for pulseaudio to be written in the first place. Lennart simply didn't like JACK, or ESound, or aRts, or any of the other existing sound servers. It's the age old open source dilemma of rewriting from scratch what could otherwise be fixed in the existing systems..
.
I can only speak from my own personal experience, but at least in my case, ESD and Arts never really worked when trying combined non-native applications (E.g. KDE under GNOME or vice versa, let alone running OSS games/flash/etc under both) and as for JACK, well, tried it a couple of times, never really worked for me, dropped it.
Pulse marked the first time both me and the people around me can reliably mix multiple streams from different applications while getting expected results. (E.g. Mixing Amarok, skype, qemu running Windows VM w/ audio and a native Linux games that uses OSS)
Granted, both me and my friends/coworkers use Fedora which doubles as PulseAudio test-bed (which may be the reason to better out-of-the-box experience), but at least for us, PA simply, err, works?
The problem is that it got shoveled down the rest of our throats long before it was ready for public consumption, and without any real pressing need.
I fully agree, even though I understand Lennart's reasons for doing it (AKA KDE 4.0 release limbo).
Heck, I used to automatically remove PA as the first post install phase up-until Fedora ~8-9.
As I see it, PA had a rotten beginning and has improved tremendously since then but much like KDE 4.x, it still suffers from the bad reputation that trails it since the initial troubled release.
The irony is that a lot of people here praise Alsa... anyone that's old enough to remember the first years after the move from OSS to Alsa would easily remember that Alsa attracted more-or-less the same hateful reaction that PA now draws. ... One can only wonder what will be said on GNOME 3 and KDE 4 when GNOME 4 and KDE 5.0 will be released :)
- Gilboa
Re:ha ha (Score:2, Insightful)
Conversely, the LLVM will eventually obliterate GCC for the same reasons, multiple participants engaging in healthy competition.
LLVM development is mostly supported by Apple.
Re:Holding back? (Score:4, Insightful)
The other linux problem: Not Invented Here.
See DTRACE vs Systemtap [oracle.com]
Re:Lennart (Score:5, Insightful)
Poettering is a zealot for a religious cause. It has nothing to do with truth or facts or even logic. His chief gripe isn't actually that BSD isn't keeping up with Linux, it's that BSD does things different from Linux and he doesn't like it. He tries to spin different as not keeping pace, but that's based on the assumption that the way he wants to do things is the One True Way. Mind you, he says this while simultaneously and purposely trying to keep BSD out of the party by refusing any and all compatibility patches that would make his One True Way usable on BSD.
Amazingly, the BSD people have a way of fixing this crap themselves. It's just more of a pain in the ass when people like Poettering actively work against their efforts.
Re:Holding back? (Score:5, Insightful)
I hate audio demons. These crutches never worked properly and never will. Someone needs to actually make a lot of absolutely breaking changes to ALSA. Why?
When I plug in my USB headphones in Windows, all programs using default audio output automatically move from my 5.1 speakers (onboard sound) to the headphones the moment I plug them in. When I pull the plug, the reverse happens automatically. It just works! MacOS supposedly behaves the exact same way.
On Linux, this is broken in ways you cannot even imagine. When I plug in the USB headphones after booting, they are treated as the second sound card (hw:1) when everything uses the first one (hw:0) by default. So in order to have anything use the headphones I have to reconfigure the applications one by one and probably restart them (xine needs a restart). Same when I change back. When I leave the USB headphones in when booting, it is totally random which sound device will be hw:0 and which will hw:1. Great. To make matters worse, when I leave the webcam plugged in, the internal microphone also gets registered as a different sound device. Plus, when it is plugged in when booting it gets a number one below the headset. So sometimes the webcam microphone ends up as hw:0 during boot and every program attempting to use hw:0 as output device will throw up confusing error messages about how everything stopped working (if they even detect that). A normal user would have given up on this mess already!
The really proper fix would be the following: break the ALSA interface in a big way: don't number sound devices, but name them after the hardware they contain (not the bus location, esp. in the case of USB devices), and make the current default device queryable somehow. Programs must then query ALSA for the default device and be aware that this may change at any moment. ALSA must be extended by a mechanism to report such changes to programs, which absolutely have to respond to this in order to not crash and burn (it'll be a PITA for the programmers, but it's absolutely necessary to enforce all of this). Also, ALSA must be able to report the speaker configuration connected to a certain device.
Why? Programs that are capable of generating two or more channels of output sound need to be aware of how many channels are going to be audible. It's not enought to know that the sound device has a 5.1 analog output. It is equally important to know whether all outputs are actually connected to speakers (e.g. a headphone connected to the onboard 5.1 analog output) or the program will play sound on channels that are inaudible and will not be heard by the user. Really great programs even should distinguish between stereo speakers and headphones or different setups for the same set of speakers (I guess most OSS Linux app devs won't even know why that is). Automatic downmixing inside ALSA when the output channel count decreases on a device change should not happen because the program almost always has additional information and thus can do a better job.
I know that programmers will cringe when they read this because it makes using ALSA much more difficult, but that's what is missing to get consumer desktop audio up to par on Linux.