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.'"
It is official; Lennart Poettering now confirms: *BSD Isn't Relevant Anymore
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming close on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be Lennart Poettering to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a cockeyed miracle could save *BSD from its fate at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD Isn't Relevant Anymore
This guy needs beaten just for this.
Just curious... does Netcraft confirm this?
PulseAudio is a useless piece of shit. It's like ALSA with a bunch of stupid complications. How it got to be the standard sound system for so many mainstream distros is a real mystery.
It lends credibility to the idea that Open Source developers don't really want to achieve a mature, working codebase and stick with that unless there are serious problems that really do require moving to something else. There is a perception that it has to be hackish and in perpetual beta to be considered sexy and cool for an Open Source OS. PulseAudio is a big example of why this perception exists.
Just answer me one thing. ALSA has had Dmix for nearly ten years. It has enabled Dmix by default (as in it just automagically works) for about seven years. What glaring need is there for adding a second software layer to a sound system that already does what you need it to do? No, playing sound over the network isn't a good reason. That's what application-level streaming software is for. What does PulseAudio contribute other than needless complexity and several FAQs dedicated to replacing it with ALSA for various distributions that ship with it?
Oh, and in the case of Mandriva, a petition to remove PulseAudio by default since more than 90% of users are disabling it and replacing it with ALSA. Yeah, that's not for no reason.
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.
Too bad they didn't port the FreeBSD audio. It actually works.
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.
now we know.
the developer lacks humility.
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.
TFS is flamebait.
LinuxFr.org : Systemd use a lot of Linux only technologies (cgroups, udev, fanotify, timerfd, signalfd, etc). Do you really think the Linux API has been taking the role of the POSIX API and the other systems are irrelevant ?
Lennart : Yes, I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit.
I am pretty sure those other systems are not irrelevant for everbody, after all there are people hacking on them. I just don't think it's really in our interest to let us being held back by them if we want to make sure Linux enters the mainstream all across the board (and not just on servers and mobile phones, and not in reduced ways like Android). They are irrelevant to get Free Software into everybody's hand, and I think that is and should be our goal.
But hey, that's just me saying this. I am sure people do Free Software for a number of reasons. I have mine, and others have others.
He's saying BSD isn't really relevant on the _desktop_ (and sorry but no, OS X is not a counter-example to this) and that if developers want Linux to succeed on the desktop then they need to worry less about other platforms. In other words, don't cater to the lowest common denominator.
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).
kc8apf
Actually, I -really- like Pulse.
For the first time since, err, RedHat 5?, I can actually hear music on amarok, watch a movie on youtube and get a call using skype without blocking the system.
I can dynamically reduce the volume of streams that I don't like (E.g. flash) without dropping the volume on other applications (E.g. amarok) or dynamically move streams from one device to another (E.g. Switch music stream from on-board / headphone to SB Audigy / 5.1).
I could never achieve that, not with Alsa (Linux w/ or w/o dmix) nor with OSS (under both Linux and FreeBSD).
Now, ***you*** may not appreciate or need it, but calling a very stable (at least on Fedora) a useless piece of shit just because ***you*** don't use it, should have earned you a -5 troll.
- Gilboa
Lennart is trying to make Linux more like OSX
Thank you for clarifying that. Now I understand that he is to be stopped at all costs.
If the only way you can accept an assertion is by faith, then you are conceding that it can't be taken on its own merits
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
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.
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.
http://www.moonlight3d.eu/
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