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.'"

Comments

BSD Isn't Relevant Anymore

[Anonymous Coward]

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

Re:BSD Isn't Relevant Anymore

[Anonymous Coward]

Dear God, you dont know of the *BSD troll?

Hand in your geek badge

(Impressed he got FP with it too)

Re:BSD Isn't Relevant Anymore

[Cinder6]

(Impressed he got FP with it too)

I like to think that he always has it in his clipboard on the off-chance it will be relevant.

Re:BSD Isn't Relevant Anymore

[flak89]

So 2005: http://www.osnews.com/thread?11786 nice story bro

Re:BSD Isn't Relevant Anymore

[Anonymous Coward]

For all practical purposes, *BSD is dead.

Fact: *BSD Isn't Relevant Anymore

I think BSD market share is much higher than 5 years ago. I mean everyone seems to be forgetting to count Macs, iPhones, and iPads, and iPod touches in their numbers. If anything, Windows is becoming irrelevant... Now it is just between BSD and Linux like it should be.

         

Re:BSD Isn't Relevant Anymore

[garaged]

*BSD is open source, none of the current apple OS are, and that is another big problem with BSD, the license

Re:BSD Isn't Relevant Anymore

[Lord_Jeremy]

The BSD components of those OSes are. That's the benefit of BSD, the license.

Re:BSD Isn't Relevant Anymore

[equex]

Well to be fair, it's the longest BSD troll I've seen AFAIR. They usually go like "BSD is dying! Netcraft confirms it !" and "BSD is dead to me!".

Re:BSD Isn't Relevant Anymore

[MikeUW]

less than a fraction of 1 percent of all servers

I believe only a number less than or equal to zero can satisfy that statement.

Re:BSD Isn't Relevant Anymore

[leenks]

There is nothing to require you to release the source of a BSD derived binary you ship. Apple do it purely out of respect, not obligation. The GPL, however, forces you to release your source (as far as it can be enforced anyway).

Re:BSD Isn't Relevant Anymore

[Canberra Bob]

Well to be fair, it's the longest BSD troll I've seen AFAIR. They usually go like "BSD is dying! Netcraft confirms it !" and "BSD is dead to me!".

These are based on the original BSD troll which was very similar to the FP, which used to (many years ago) make an appearance in almost every story related to BSD.

Re:BSD Isn't Relevant Anymore

[Onymous Coward]

Windows isn't quite "becoming irrelevant". It's still a huge player and will continue to be for a long while. But as the OS is commoditized, as the platform is commoditized, through document standards and through frameworks, Windows stops being the juggernaut it once was. Microsoft stops being able to define the market and becomes just another player.

Windows is ceasing to be relevant as the phenomenon it was, as the de facto standard and platform. Now it has to compete.

Re:BSD Isn't Relevant Anymore

[cthulhu11]

Therefore there are about 7000/5 = 1400 NetBSD users
Am I the only one who sees the sophistry here? Just in case: o Unspecifed method for counting *BSD posts o Usenet itself has been irrelevant for years, due both to the flood of spammers and migration to web-based forums I argue that *BSD has been irrelevant for years. What innovation, or even keeping up with the times, has it done since the 1980's? In the 1995-1997 timeframe I was stuck with BSD/OS thanks to a decision that preceded me, made by a network engineer of all people. It was a fscking nightmare. The preceding decision maker had asserted that it would be inexpensive by virtue of running on peecee hardware that we could maintain ourselves. In the end the countless hours and karma lost dicking with both the hardware and software were soul-devouring. A few low points: o Rob Kolstad, who believed that home directories -- yes, home directories -- belong in /mnt o Systems were extremely prone to wedging, requiring physical intervention o Systems were especially unstable with >256MB of physmem, and BSDi wouldn't even look at their kernel dumps because they didn't have a machine with more than that themselves to load them into, and refused to get/upgrade one. o No matter how hard I tried, and no matter what well-regarded mobo I sourced, I could not for the life of me get two SCSI HBA's to co-exist in a single system. o No software striping/mirroring. In an OS that cost a grand. At one point someone emailed me some old *BSD striping driver that I could hack into the kernel, but it was slow, required that the set of metadevices be compiled and hardcoded into the kernel, including component devices and their sizes. o Getting stuff to compile and run without dumping immediate core was a nightmare, even worse than Ultrix I eventually won out against the unrelenting nightmares and installed Solaris on the same systems. They ran faster and stayed up.

Re:BSD Isn't Relevant Anymore

[iggymanz]

if by servers you count print servers, routers, and other appliances, the percentage of BSD goes way above 1%.

Holding back?

[Anonymous Coward]

Innovation is still happening on the OpenBSD and DragonFly fronts.

FreeBSD is all about incorporating other people's software at this point (ZFS, DTrace, LLVM), and hasn't really originated a good idea in a decade. Coincidentally, that is where DragonFly split off. That's what happens when Apple buys the FreeBSD development team...you get a bunch of core developers running FreeBSD in a virtual machine on MacBook Pros. They can't be bothered to get basic functionality like suspend/resume to work, and all new wireless drivers are lifted from OpenBSD.

NetBSD is dead.

Regarding the summary, PulseAudio adds nothing to the *BSDs...OSS has always been able to have multiple programs access the sound card at the same time. Avahi runs fine at least on OpenBSD, and systemd....well there are only about two Linux distributions even using it at this point.

Re:Holding back?

[Anonymous Coward]

Regarding the summary, PulseAudio adds nothing to the *BSDs...OSS has always been able to have multiple programs access the sound card at the same time. Avahi runs fine at least on OpenBSD, and systemd....well there are only about two Linux distributions even using it at this point.

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.

Re:Holding back?

[Anonymous Coward]

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 was pushed by Redhat and nobody else had a better solution to clean up the morass that is linux audio.

Re:Holding back?

[mevets]

Too bad they didn't port the FreeBSD audio. It actually works.

Re:Holding back?

[causality]

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 was pushed by Redhat and nobody else had a better solution to clean up the morass that is linux audio.

PulseAudio is a relatively recent arrival. ALSA + Dmix by default has "just worked" for a long time now, about seven years. As a matter of fact, I don't see PulseAudio in a kernel config anywhere -- implying that PulseAudio is just an extra layer of software standing between the program wanting to play audio and ALSA. If the goal is to get rid of problems caused by ALSA (I'd love to hear what those are, by the way), then that's not going to work.

Please explain to me the specific problems with Linux audio and the ways that PulseAudio addresses them. I am hoping someone will respond to that, but if no one does I will definitely understand it is not a coincidence if no one can back up your assertion.

When I actually read user forums and do research on it, the impression I receive is exactly the opposite: PulseAudio is causing problems that didn't happen with ALSA. That's about what you would expect when you add redundant, needless complexity to an already-working system. As for me, on my system I have never installed PulseAudio. I use ALSA for all audio needs. Anytime I fire up Wine, mplayer, Amarok, or anything of the sort, audio just works and I don't have to worry about it. The only requirement whatsoever is that the user in question is a member of the "audio" group and that's all; it really is so simple and easy. I am so satisfied with this setup and the way it simply works that I have no problems with it to fix. What more do users want?

Re:Holding back?

[Clarious]

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.

Re:Holding back?

[Wonko the Sane]

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.

Re:Holding back?

[causality]

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?

Re:Holding back?

[causality]

Replace "PulseAudio" with "X Window" and you fit right in the UNIX-hater's handbook. Not that that means you're wrong, mind.

I agree that PA-on-ALSA is just ridiculous. However, PA or something like it, after it matures, and over a barebones kernel layer, can make good sense.

What does PulseAudio-on-ALSA accomplish that straight ALSA cannot? Assuming a non-null answer to that, how many users really need that functionality to justify including PulseAudio as the default configuration for major distributions?

The case for PulseAudio rests on those two questions.

Re:Holding back?

[causality]

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.

It's good to have a real answer to a question. Still, I have another question. Given the open-source nature of all the software involved, wouldn't the developer time be better invested in fixing the ALSA drivers to accommodate Bluetooth headsets instead of creating an entirely new layer of middleman software between the application and the audio system?

It's a question of how to best manage and invest the finite talent and effort that is available. Why would PulseAudio be the best possible method? What does that answer look like when you subtract from its gains all the time wasted by users with no such headsets who had to sort out PulseAudio-specific audio problems? There's a big picture here and it doesn't look good for PulseAudio.

Re:Holding back?

[Electricity Likes Me]

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.

Re:Holding back?

[Anonymous Coward]

If the goal is to get rid of problems caused by ALSA (I'd love to hear what those are, by the way) ...

Not that PulseAudio would necessarily solve these, but here's my list:

(1) The default dmix resampler sucks. The "high-quality" one is better, but that one uses up significant chunks of CPU time. I haven't had a chance to look at the code (been meaning to) but it seems to me it should be possible to maintain quality without using so much CPU.

(2) Semi-pro home-studio type soundcards are poorly supported. Currently my ENVY 1712 does not come up right on boot and it takes an iteration or two of unload-modules and restart alsa before it "catches". Seems something broke somewhere between 2.6.32 and 2.6.38. Alas I need the latter to support this motherboard.

(3) After audio's been playing for an hour or two, I'll start to get some crackling in the left speaker. Unloading modules and restarting alsa fixes it.

(4) The resampler/dmix semantics are dumb given that many soundcards can run at any of the popular sampling rates up to 96K. A smarter way to do the mixing is: when no other sound is playing and an application asks for audio, set the card to run at the same rate as the source to be played. No resampling required. If and only if a second sound source wants to come in while sound is currently being played; and if this second source asks for a rate different than the one currectly being used, then and only then the resampler is started and used to match the second sound's rate to the first.

Most the time this does what you want: music being played will sound as clear as possible. Any ancillary system boops and beeps and desktop sounds that come in the middle will get resampled if needed. And you won't be burning CPU except when needed, and only for the relatively short ancillary sounds.

(5) Perhaps there's a way to configure the behavior desired in (4), but the alsa configuration language and options are so dense and (to me) counterintuitive I don't know where to start. It is like a programming language onto itself but there's no idea of what options are relatively efficient to use, and what should be avoided if possible.

(6) Related to (5) and indirectly to (4), there are time I _want_ exclusive use of the audio, without any mixing. I live with several roommates; we rotate around who plays mood music in main room. When I'm playing audio in this manner, the _last_ thing I want is to be shocked out of my seat when I inadvertantly visit the "wrong" web-page that blasts some sounds. What's the best way of expressing this in alsa-lingo?

(7) The Jack-audio-connection-kit realtime audio router seems to solve a lot of the same problems as dmix, and as PulseAudio. Why didn't they just use that? I get much better results when using Jack. Admittedly, Jack runs on top of alsa, so what's Jack doing that the apps aren't outside of Jack?

Some of these may well be PEBKAC. I apologize but find the documentation is simply too dense and obscure for someone who doesn't yet have a grasp of just how all the pieces interact that I may know where to look and what to tweak - or, even - what pieces are available. It didn't help that I was trying to set up audio right around the time dmix entered the picture and what I thought I knew one week no longer worked the week after, which has put a rathar sour taste in my mouth over the whole thing.

Re:Holding back?

[gilboad]

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

Re:Holding back?

[Billly Gates]

It seems to me after many of the core developers left for Apple or quit the quality of FreeBSD when down by 5.x and never recovered. I never tried DragonFly, but FreeBSD today disregards stability with ... oh yeah that unstable subsystem it will be fixed next release.

BSD used to be well written, small, and conservative with new features gradually being thrown in. GEOM and a few things they are trying are just terrible and making it unstable. It seems FreeBSD 4.x was its golden age

Re:Holding back?

[Anonymous Coward]

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?

[babai101]

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.

ALSA with dmix produces shitty quality sound. When pulseaudion was introduced in ubuntu 8.04 it was causing all sorts of problems, mainly with sound latency. If you give pulseaudio a try now you'll see all of those latency issues have somehow vanished, plug-in an audio device to your pc and it magically works like in windows, and the sound quality due to some good resampling is just crystal clear as with OSSv4. While OSSv4 has a very good resampler it fails to support the plethora of sound devices that pulseaudio supports.

Re:Holding back?

[gilboad]

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:Holding back?

[havardi]

I installed pulseaudio so that my wife could plug in USB speakers on her laptop and have the sound come out. Maybe you can do that with ALSA?

Re:Holding back?

[Anonymous Coward]

This is dumb. A simple purview of PulseAudio's features would answer this question. You can not desire the features. That's your right. But you probably shouldn't pretend other people don't want them.

Re:Holding back?

[shutdown -p now]

Regarding the summary, PulseAudio adds nothing to the *BSDs...OSS has always been able to have multiple programs access the sound card at the same time.

The purpose of PulseAudio is much more than just letting several programs access the sound card at the same time (it was a solved problem in Linux as well even before PA appeared).

Re:Holding back?

[subreality]

IMO: Like you say, PulseAudio doesn't add any important technical features.

The problem with ALSA is the configuration. Changing anything (even as simple as redirecting audio to a digital out, or indeed, even enabling dmix) requires monkeying around in your .asoundrc which to put it politely, is arcane at best, and there are no user-friendly tools to make it easier.

So you slap PulseAudio on top of it, and it provides a convenient API. As such, there are easy GUI tools to configure where you want your sound to come out.

Of course that's a terrible solution to the problem. It just adds another confusing layer of complexity and incompatibility, but I think we're stuck with it until someone writes a better UI for ALSA.

Re:Holding back?

[smash]

The other linux problem: Not Invented Here.

See DTRACE vs Systemtap

Re:Holding back?

[PeterBrett]

What does PulseAudio-on-ALSA accomplish that straight ALSA cannot? Assuming a non-null answer to that, how many users really need that functionality to justify including PulseAudio as the default configuration for major distributions?

At the risk of repeating myself:

1. Plug in USB speakers and have audio come out
2. Individually control applications' volume/balance/output channel

Re:Holding back?

[t2t10]

If you want to support wireless devices and streaming properly, you need user mode audio servers; you can't put that stuff into kernel drivers.

PulseAudio got off to a bad start, and I don't really know whether it's a good design in its details. It almost certainly isn't the "best method", but it's the method that people who actually put in the work came up with, and they stuck with it, which is why it's still around.

If you want to put in the work to do something better, please feel free to do so.

Re:Holding back?

[multi io]

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.

And that was a fundamental design flaw in Alsa (rather than just missing drivers), and it could only be remedied by inventing a whole new sound daemon / system and putting it on top of Alsa?

Re:Holding back?

[perryizgr8]

i saw this about a year ago and stopped worrying about audio from my gentoo machine: http://blogs.adobe.com/penguinswf/files/penguinswf/linuxaudio.png

now i just use my phone or win7 running laptop when i want to hear audio.

Re:Holding back?

[simcop2387]

some answers. 1) I'm not sure I've noticed a problem, but I'm not an audiophile and when doing anything with high quality audio I'm not using the software mixing (see 4. below) so I may just not have noticed or heard it yet. 2 & 3) Given what you describe this sounds like a driver issue, i'm honestly unsure of what could be going on there to help, sorry. 4) This is actually the default behavoir of alsa's software mixing. this may not be the way that your distro (judging by the kernel versions you gave, i'm betting ubuntu?) sets it up by default, or what happens if pulse audio is running (i've seen it keep the audio card open even when not in use and basically force it to a single sample rate). 5) It is a bit arcane, but there are actually relatively few things that you'll ever really need to do unless you're trying to bond multiple devices into a single virtual one to play things back on. (e.g. use several elcheapo cards for home brew 7.1). you can also put in LADSPA filters directly for play back and this will be relatively expensive because LADSPA operates on the audio in floating point. 6) the best way to do this is to tell a program to use "hw:0" instead of "default" for the alsa device. doing this will depend on application since there is no way to standardize configuring every application. 7) I also have far far better luck with jack (and it's a hell of a lot nicer to work with than pulse audio). pulse audio is in fact one of the reasons that i refuse to use many of the fasionable "modern" distros on my own machines.

Re:Holding back?

[perryizgr8]

i have zero knowledge about how audio works but referring to your (4), won't the following be a better approach?
the lower quality stream is resampled and the output is always the same as the stream with the highest quality. in the approach you describe, if at first i play a low quality stream, and then start playing a high quality stream, the output will match the lower quality stream. that should not be happening.

Re:Holding back?

[walshy007]

Pulseaudio sound latency is still shit, it cannot compare to the likes of jack.

Re:Holding back?

[icebraining]

Sure you can, I do exactly that. Well, it doesn't switch automatically, but it's just a couple of keypresses on my music player, hardly a problem that needs a whole new sound server.

Re:Holding back?

[gmueckl]

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.

Re:Holding back?

[Burpmaster]

Hello again.

PulseAudio is a middleman standing between the applicating wanting to play sound, and ALSA.

So is dmix. I explained this to you before.

How exactly is that going to fix an inherent flaw in the underlying ALSA system? Hint: it will not and cannot.

You are conflating ALSA, the clean efficient kernel API for using sound hardware, with ALSA the user-space API that adds on a complex system of plugins that can be inserted in place of, or before, sending sound to the hardware. It's this complex plugin system (and the mixer built on top of it) that is inherently flawed and has fundamental limitations. There's no dynamic routing or hot-plugging for starters (and I mean while an application is running). Fixing these limitations requires a rewrite.

If there are such horrible problems with Dmix [...], that kind of development effort should be put towards fixing Dmix

Dmix is being fixed, via a rewrite called 'pulseaudio'. You may have heard of it.

Re:Holding back?

[mmcuh]

JACK is designed for low-latency realtime audio, and as such it demands that the audio callbacks in every program using it is realtime safe - it must not block, and it must not take an unusually long time to finish. This is not a problem for people writing serious music software or sound editors since they have to care about things like that anyway, but it is for your average media player or game programmer who typically doesn't. If your JACK callback doesn't finish quickly enough (e.g. if it decides to wait for a disk thread which is blocked by some other disk operation), you will get a glitch in your audio. And "quickly enough" is usually rather quickly indeed since JACK is meant to be a low-latency system.

This can be solved with internal buffering and one more thread in every program but that's not really a nice solution. And let's face it, someone who writes a basic MP3 player isn't going to care about that just to be nice to people writing hard realtime audio software.

I'm not a fan of the current implementation of PulseAudio - I've stopped using it on my system since it kept dying at random times - but there is one nice thing about it and that is the ability to switch backend while you're playing. It means that JACK, when it starts, can tell PulseAudio to get off the soundcard and use a dummy backend instead so that JACK can get exclusive access to the hardware. Now when I'm using raw ALSA instead of PulseAudio for "consumer" type programs I have to make sure myself that nothing else is using the soundcard before I can start JACK.

I think the idea of PulseAudio is sound (haha!) but the persistent bugs has put me off using it. I might try again in a couple of months.

Re:Holding back?

[mmcuh]

(4) The resampler/dmix semantics are dumb given that many soundcards can run at any of the popular sampling rates up to 96K. A smarter way to do the mixing is: when no other sound is playing and an application asks for audio, set the card to run at the same rate as the source to be played. No resampling required. If and only if a second sound source wants to come in while sound is currently being played; and if this second source asks for a rate different than the one currectly being used, then and only then the resampler is started and used to match the second sound's rate to the first.

This would require reconfiguring the hardware, which would almost certainly cause an audible glitch.

Re:Holding back?

[Anonymous Coward]

Alsa is a piece of shit but at the time it served a clear requirement due to OSS licensing. Jack has audio productivity covered, this is the only sound server I have any interest in running (which I do from the shell). There was no clear requirement for pulse since dmix already worked... Unlike BSD, Pulse Audio was never relevant!

Re:Holding back?

[Jorl17]

Nowadays I don't use Pulseaudio, but it provides itself to be fantastic in the machines where I have it.

Like TFA says, it rarely ever is bugged, since what it does is expose bugs. If you RTFA then you'll also see some of the good things it has, but I'd like to point out my favorites.

I love to be able to share sound through the network with one, two clicks or one or three lines in a config file. I'm thrilled about plugging in headsets and watching things just work. I love to be able to dinamically change the capture sources of individual applications and even setting some of them to the monitor (in Pulse-speak) of the sound coming through my speakers. I'm sorry, I may not be good at searching, but I've spent days looking for a simple way to grab my ALSA output sound and I've found nothing. The API might be powerful, but it's shit. Seriously, it is plain old shit. I can't code a fast-coded or simple application that suits my needs with that crap. Now the (simple?) Pulseaudio API is fantastic -- I've managed to, in about 5 minutes, find out how to capture my output sound. I used that, together with other decent socket APIs to create my own way of sharing sound between two PCs, one with Pulse and the other only with ALSA (guess which one can't record its output sound?).

But really, like I said, the ALSA API may be powerful, but it's plain shit if you just want to do things without caring about the hardware that much, or if it all goes to the same place, or if you need twenty-thousand structures. I mean, in Windows there was (is there still?) a sync call to PlaySound and it'd just work -- where's a reliable way of doing just that without adding excessive library crap[1]? Back on the topic of ALSA+dmix vs Pulseaudio, I've also had, strangely enough, more success with Pulseaudio. It doesn't make sense that I have to write some 20 or so lines to get "dmix" to work and still have some lazy apps that just fail. Pulseaudio just works for me, most of the time. The reason I removed it is because I finally "learned"proper ALSA and decided that I didn't need any of the brilliant features I pointed out anymore[2], but recently I've found out that I do, unless you can tell me how to capture the output of my audio in a quick manner, like Pulse allows me to.

Seriously, have I told you how I think that, for the simple user application programmer, the ALSA API seems like a piece of atom-crushed shitty rubbish? And then there's configuring every freaking line of asoundrc to be compatible with other applications that somehow chose to use gigantic sound buffers! Jeez, those same apps just WORK with Pulseaudio.

[1] Not that I'd really want it, since this usually means that sound itself hasn't been initialized "app-side" and I like the way my Linux works when I code, but ALSA is just a Pain In The Ass
[2] Well, and because during Idle times it does eat more CPU time.

Re:Holding back?

[RobbieThe1st]

I *wish* this was the case. I prefer alsa for everything I can due to lower latency, but for Wine, I *cannot* get my Audigy 2's mic to work - I just get a "pulsing" mic input, dropping every second or so.
With PulseAudio(and a latency-reducing environment variable), it works perfectly. Probably due to software resampling.
PulseAudio has it's uses - Mainly ones involved with overcoming shortcomings in the hardware - though it may not be needed(or wanted) everywhere.

Re:Holding back?

[RobbieThe1st]

Unless you need software resampling. That's where it shines - especially if your app isn't aware of such things, like stuff running through wine.

Re:Holding back?

[koinu]

I don't know where you have problems with "instability" in FreeBSD. This and your statements about GEOM is definitely not true. Please look at the system first, before trying to lie to people here and trying to cause harm to this excellent distribution.

Re:Holding back?

[TheRaven64]

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...

Re:Holding back?

[TheRaven64]

I'm not familiar with the ALSA architecture, but your second point definitely doesn't require PulseAudio. I get that with OSS on FreeBSD (per-vchan mixer controls), and apparently it's present in OSS 4 for Linux too. Plugging in USB speakers and having the audio come out shouldn't be a problem either. They just appear as another sound sink in the audio stack and if it's configured to automatically add then audio will come out.

Re:Holding back?

[poltsy]

While ALSA doesn't seem to currently allow defining defaults with the names it gives to each device (very disappointing I know) you can already force a driver to allocate a specific number for the device by giving index=whatever to the driver module. This way at least they don't jump around at every boot. Unless of course you have two devices using the same exact driver in which case it'll still be a mess.

Obviously this being linux there is no gui magic to do it for you.

Re:Holding back?

[JamesP]

It was pushed by Redhat and nobody else had a better solution to clean up the morass that is linux audio.

What problems exactly? Are users crying for a solution? Does Android uses Pulseaudio?

Per-app volume control? Most apps offer a volume control and btw, I'm not DJing by starting several players at the same time.

Funny how the first thing I HAVE to do is disable pulseaudio, otherwise things will break, lag, hang, etc, etc.

Pulseaudio is an utter and complete failure, and then people wonder why there aren't many users of Linux

Re:Holding back?

[JamesP]

I have no words to add, this this this

And of course, Pulseaudio sends the data to ALSA, so it's not going to solve anything that's broken in ALSA or its drivers.

Re:Holding back?

[Nate B.]

Some months back I decided to install PA on my Debian laptop so I could plug my USB Logitech speakers in and have them work. It didn't. (I was frustrated as KDE has a nice GUI to set sound device ordering but I don't use KDE any longer, opting for XFCE) I spent all manner of time reading FAQs and using my Googlefu, all to no avail. Seems that what does not exist in the PA universe is a sane bit of documentation for the end user on how to configure and use the POS. I wound up with a simple hack to ~/.asoundrc that lets me use the speakers. It is inelegant and it works.

I'd really like to use its claimed features but it only seems useful as the volume slider on a Ubuntu desktop. Any use case beyond that violates GNOME HID or some such nonsense.
 

Re:Holding back?

[Nate B.]

Do you have a link to make this claimed "Plug in USB speakers and have audio come out" actually work? I'm not trolling as I'd really like to know. I nearly tore my hair out trying to find one bit of documentation on doing just that as all I found was post after post on removing PA and then writing a ~/.asoundrc to make the USB speakers work which is what I did. But if you have a link to any sort of documentation (and don't point me to the PA site as it is as useless as tits on a boar hog for end user docs) please do post it.

Thus far I have to agree with those arguing against PA as I've simply been unable to achieve any of PAs claimed benefits/features.

Re:Holding back?

[maxume]

Only before the first stream starts.

Re:Holding back?

[etrusco]

> 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?

What "inherent ALSA flaw" are you talking about? PA was not created to fix any ALSA flaw, other people have already stated several features it introduces *on top of* ALSA. I'll cite two more: reduce power consumption and provide multi-user/seat policy.

> Hint: it will not and cannot.

You can't affirm a middleman can fix all possible flaws of the lower layer, but of course it can work-around some kinds of flaws.

> 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?

Lots of influential people didn't think dmix was the way to go, that's why there are so many alternatives.

Re:Holding back?

[PeterBrett]

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.

And that was a fundamental design flaw in Alsa (rather than just missing drivers), and it could only be remedied by inventing a whole new sound daemon / system and putting it on top of Alsa?

In a word, yes.

Re:Holding back?

[etrusco]

PulseAudio is not about fixing ALSA, it's about fixing the parts the distros/people think are missing in the Linux audio stack.
Please try these:
http://ossguy.com/?p=347
And from the previous article: https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble#Use%20cases
http://www.cio.com.au/article/320807/open_source_identity_pulseaudio_creator_lennart_poettering

Re:Holding back?

[ustolemyname]

Yes. And the guy who made pulseaudio said: "if you need a low latency sound server with lots of manual routing control: use jack" (read that in an article somewhere). If you really want to you can even run pulse on top of jack (I just use pasuspender when I'm running my keyboard through jack/ardour/linuxsampler).

Meanwhile pulseaudio:

• Just works (jack DOES NOT just work)
• Lets me control multiple volume sources (I can hear skype ringing all over the house, but my music/movies doesn't leave the room)
• Lets me get hear sound from my virtual machines, and my server downstairs in the basement
• Doesn't even break the top five tasks on top for me. when playing audio and having my machine largely idle.

Times have changed, mocking pulse makes no sense today. Jack and pulse have different design goals, get used to it.

Re:Holding back?

[loufoque]

Please explain to me the specific problems with Linux audio and the ways that PulseAudio addresses them. I am hoping someone will respond to that, but if no one does I will definitely understand it is not a coincidence if no one can back up your assertion.

The point of pulseaudio is to allow, at any time, to control the mixer extensively from userland.
You can see all applications currently accessing your devices and how, mute a particular one, change its volume, or even change the device it outputs to; all of which transparently while the application is running and without affecting any of the other applications accessing the same sound device.

ALSA + dmix doesn't give you that flexibility. It only allows to create a device that supports mixing, and when an application uses ALSA it is in charge of choosing the device to output to. You cannot change how that mixing is being done transparently while all the various applications are outputting sound.

That information is pretty much common knowledge. Even Wikipedia clearly states this.

Re:Holding back?

[iluvcapra]

The problem is this makes mixing much more complicated, and you've reinvented /dev/dsp's ioctl interface. If a client is allowed to alter the DAC rate it'll interfere with any other devices that are trying to play out the interface. All of the sudden all clients wanting to play their sound will need to monitor the output's sample rate (and even better, sample format and encoding) and then reconform what they're writing to the audio hardware in order for it to match with whatever the interface is making that moment. This also significantly complicates keeping sound in sync with picture streams.

Re:Holding back?

[maxume]

I was simply pointing out that GP was misinterpreting things.

I have no opinion about whether it was a good idea.

Re:Holding back?

[Daniel Phillips]

PulseAudio isn't a bad concept, it's just that it doesn't work properly for far too many people.

Isn't it usually a bad idea to add a new layer of software that is not absolutely necessary? Usually that has two main results: 1) add a new layer of bugs 2) increased overhead.

Re:Holding back?

[seantide]

FreeBSD 5 was bad, 6 was iffy... but starting with 7 it started to get much better and 8 has been very solid.

Re:Holding back?

[naasking]

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.

To do this, the standard approach is to add a layer of indirection between the "real" output devices and the "virtual" output devices held by the applications, and adjust virtual-real mappings on the fly based on some policy. And wouldn't you know, that's a sound server/audio daemon. PulseAudio is exactly the right solution for this problem.

Re:Holding back?

[gmueckl]

This "standard approach" of yours is horribly broken. It adds latency, degrades audio quality by withholding information about the current audio setup from the source application and on Linux never was done in a way that worked (e.g. FMOD not working with pulseaudio last time I checked).

Re:Holding back?

[badkarmadayaccount]

A proper migration path should be in place - though it would take coordination between kernel teams - get proper OSS 4 multiple application support in ALSA and/or PA - slowly deprecate their interfaces, and when everything is running on a OSS 4 backend, just cut the cruft.

Re:Holding back?

[badkarmadayaccount]

The streaming layer has to go somewhere - either per-app, or a unified one - which has less bugs and is easier to optimize?

Re:Holding back?

[badkarmadayaccount]

What distro are you using - 3 iterations of Fedora in, and I've had approximately squat problems with PA.

Re:Holding back?

[naasking]

The Jack sound server is proof that an audio daemon can still be real-time. A level of indirection is exactly the right solution. Why don't you focus instead on how to achieve the timing properties you want, instead of hand waving some non-existent kernel API. Every audio output need not be routed through the audio daemon.

Re:Holding back?

[gmueckl]

Now you mention just another incompatible audio daemon. Great! See what's wrong with that? In order to make that audio mess work, it has to be scaled back into a single, monolithic, much more capable system.

Furthermore, any remixing that the application is not aware of is able to degrade the output quality. Consider the following scenarios:

1. The user starts playback of a DVD with 5.1 sound while his headphones are plugged in. Some time after he started playback, he pulls the plug and the sound output should transition to the 5.1 speaker set also connected to the computer. However, the player started playback in stereo because the default output was stereo only. Result: unless the player is notified and re-initializes sound output, the output must remain stereo.

2. The user now terminates the DVD player and starts playing a first person shooter. The game detects 5.1 channel output and initializes its audio engine for that. Now, the user wants to switch back to his headphones. In this scenario, a downmix from 5.1 to stereo may not be what the user expects because the game engine might have a special mode for headphones where it applies HRTFs to the sound sources in order to give the user spacial cues about the sounds (some commerical audio engines offer that).

Currently, there is no way to not have quality degradation in either scenario with the current Linux sound system mess.

Yet another sound server will never be the answer to this because if there's one, there will be others and users will expect developers to support all of them. That is infeasible. There must be one and exactly one kernel-level interface or else the situation will never get better.

Re:Holding back?

[walshy007]

Just works (jack DOES NOT just work)

yum install qjackctl, run it, press start... it functions, just because it doesn't come stock with distros and a few distros packages aren't compiled to use it doesn't mean it couldn't easily be made to.

Lets me control multiple volume sources (I can hear skype ringing all over the house, but my music/movies doesn't leave the room)

You really think a multi-channel mixer is beyond jack? considering it caters to the needs of professionals too? really?

Lets me get hear sound from my virtual machines, and my server downstairs in the basement

I can do this with jack too, your point?

Doesn't even break the top five tasks on top for me. when playing audio and having my machine largely idle.

Likewise with jack.... your point?

Times have changed, mocking pulse makes no sense today. Jack and pulse have different design goals, get used to it.

Jack fits all of pulses uses except one, and that one is low power embedded where they want as little context switches as possible to enable low power states.

While I wholly agree pulseaudio is usable in modern times unlike when first adopted, the whole clusterfuck was unnecessary from the start.. and pulse still doesn't cater to uses jack does, while jack likes low latency too much for embedded, it is always a poor idea to sacrifice performance on every single machine for a tiny end case like low power embedded. (and yes, I even run jack on an original atom complete with synths etc without issue, and have done so recently on as old a machines as a pentium 2)

Re:Holding back?

[iggymanz]

NetBSD is very much alive, latest version 5.1 released in November 2010. The code from NetBSD is used by FreeBSD and OpenBSD (and vice verse, they're an incestuous bunch) for porting of various device drivers and for architecture support

In related news

[ArchieBunker]

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?

Re:In related news

[Kagetsuki]

The point here is precisely that he is a Linux developer and not a BSD developer - as in if BSD doesn't get more developers porting their work between Linux and BSD and maintaining compatible builds BSD is just going to continue fading into obscurity.

Re:In related news

[grub]

Apple does, though, claim BSD is relevant. Look at OSX for proof.

Re:In related news

[dgatwood]

Seriously you're asking a linux developer his opinion on BSD? What answer were you expecting?

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.

Re:In related news

[jo42]

Look at OS X for proof.

And iOS since they share about 80% of their code base...

Re:In related news

[stms]

I guess he thinks Apple is no longer relevant too since MacOSX/iOS are both based on BSD.

Re:In related news

[Anonymous Coward]

The Apple variant of BSD is a dead end. All branches of linux are still alive and kicking, for example on Android phones - the most popular smartphone.

Funny, Android devs don't really consider Android to be a Linux environment. Android is probably less Linux than Mac OS X is BSD.

Re:In related news

[sg_oneill]

Sure its a BSD. Pretty much any unix that isn't linux (or minix lol) shares DNA from the early AT&T + BSD unix's.

But I wouldn't call it a sibling anymore of the modern BSDs (It was originally), more a hipster turtleneck wearing cousin.

Re:In related news

[sgunhouse]

Android, NetOS and the upcoming ChromeOS are based on Linux, as are many routers and embedded devices. Sorry, but Linux is the most popular version of UNIX as of today.

Re:In related news

[Tester]

Seriously you're asking a linux developer his opinion on BSD? What answer were you expecting?

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.

1. Lennart is NOT a kernel developer. He is a userspace developer who wrote many important pieces of infrastructure for all free operating systems.

2. Lennart is trying to make Linux more like OSX.. What he is saying is that the other BSDs are way way behind in features. Apple had to radically change BSD to make it suitable for a desktop, and Lennart is doing the same.

Re:In related news

[Tom9729]

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.

Re:In related news

[Dahamma]

Yeah, but using it as an argument that BSD isn't dead it like using you as an argument that your great-great grandfather isn't either ;)

Re:In related news

[EdIII]

You missed my point. Of course Apple has based their OS on an open source platform, and therefore it is subject to certain terms.

My point is that Apple will not let you download their entire OS for free from a distro which is being counted amongst the BSD variants that are.

So if we are going to count up all the BSD installations, in the context of open source and a comparison against Linux, then it does not make logical sense to include Apple's BSD variant. One might say such a study or analysis would be deliberately misleading.

My first point is getting modded down of course, but I hold no opinion of BSD (fanboys pay attention - not agree!=troll) either way. So I can honestly say that before hearing this story I had no idea of the state of BSD in open source at all. I knew Apple was based on it, but other than that, I just hear about occasional references by other admins that they run such and such on BSD.

Although I was curious about BSD, I am just very comfortable with Red Hat and CentOS. No judgement against anything else. So can't we just all get along? :)

I mean we are all on the side of open source right? So why get our panties in a bunch and get into a fight over it? :D

Re:In related news

[bonch]

Apple hired FreeBSD's co-founder.

Re:In related news

[samkass]

http://www.opensource.apple.com/release/mac-os-x-1068/

You can even recompile your Mach+BSD kernel and install it on your Mac or hackintosh.

Since Apple has also rejected GPLv3, they are moving away from all things GNU in their user space as well. That means they've contributed heavily to LLVM and clang to replace GCC, also under the BSD license and written an entire new libc/c++ which they've also open-sourced. They've probably done more for BSD-licensed OS work than anyone in the world at this point.

I'm not entirely sure why they get a reputation for being closed. It's true Darwin as a separately-installable distro never caught on and they ended the project, but they're very open and permissive about their core OS development.

Re:In related news

[bonch]

The Apple variant of BSD is a dead end. All branches of linux are still alive and kicking, for example on Android phones - the most popular smartphone.

Android isn't a smartphone. It's an operating system. With iPods and iPads counted, the most popular mobile operating system is iOS by a large margin. Apple's Darwin foundation is the most popular UNIX in the world.

Re:In related news

[bonch]

Darwin is free and open source. You most certainly can download and install it on your server. Do your research.

Re:In related news

[bonch]

That's incorrect. Darwin is the most popular version of UNIX as of today and powers every iPhone, iPod touch, and iPad. Counting all Apple devices, iOS is the most popular mobile operating system in the world by a large margin, a fact that Apple trumpeted at WWDC this year.

Re:In related news

[Moridineas]

http://www.opensource.apple.com/

http://www.puredarwin.org/

Admittedly little used and no recent releases, but there are/have been Darwin OS releases apart from Apple.

IMHO, if you're curious, give it a shot. I personally much prefer FreeBSD as a server operating system. I don't run a Linux/BSD desktop, but if I did, I would probably use Linux.

Re:In related news

[bonch]

Slashdot is the Aint't-It-Cool-News of tech journalism these days. Every story is days behind and has to be controversial or misleading.

Re:In related news

[kc8apf]

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:In related news

[EdIII]

I prefer headless operating systems for my servers. It's what I use the most. I guess my biggest problem in trying different variants is just time really. I got so much to do coding and developing with a CentOS platform that I don't have the time yet to really explore different OS. Truth also being I don't have a lot of time for games either.

When I do get out from under the projects that I there are many things I am curious about, and BSD has always been one of them. If nothing else because Apple is based on it.

Re:In related news

[RLiegh]

Just because some guy is a Linux developer doesn't mean there aren't plenty of folks (and companies with HUGE market value) dedicated to working on BSD.

Are you saying that there are? If so -citation needed.

Re:In related news

[oakgrove]

That's funny because with a simple chroot, I can run 99 percent of the applications in the Ubuntu repository. Seems pretty Linuxy-goodness to me.

Re:In related news

[jon3k]

Not even close, linux dominates in the server world and Android is based on linux, which is outselling the iPhone quite easily (up to 550,000 android devices activated PER DAY).

Re:In related news

[jon3k]

Not for much longer, Android is up to 550k activations per day.

Re:In related news

[Galactic Dominator]

Sure they have. Take this for example.

http://www.osnews.com/story/22331/FreeBSD_Gets_Grand_Central_Dispatch_Port

I could go on, but it's obvious you need to develop some research before forming opinion skills so I'll let you handle it from there.

Re:In related news

[jon3k]

Do you have some current numbers? Because at 550k activations per day if Android hasn't caught up yet, it will soon.

http://www.businessinsider.com/android-iphone-market-share-2011-4

Re:In related news

[Anonymous Coward]

"sorry but no, OS X is not a counter-example to this"

Why isn't OS X a counter-example?

The *whole point* of the BSD style license is that you can take the distribution, modify it to your liking, and keep your modifications to yourself.

Apple's Darwin incorporates elements of BSD because the license allows them to. That's the whole point. Apple wanted to bring BSD to the desktop, so they made their own windowing system and built it around the BSD shell. Apple is the perfect example of BSD methods, incentives, and monetization. You don't get to exclude OS X just because it isn't a typical BSD. You have to include OS X because it uses BSD exactly how it is permitted to be used..

Re:In related news

[Moridineas]

Apple is due to report quarterly earnings next week. Guesses are that they will have sold around 18 million iphones and 8 million ipads, maybe 5-6 million iPod touches. Comes out to a ballpark of roughly 360k activations a day.

Is it just me or is it almost unbelievable that between iOS and Android there are almost a million devices being activated every day? Amazing...

Re:In related news

[Darinbob]

Didn't Linux invent the NIH syndrome or are they just pretending there too?

Re:In related news

[MacGyver2210]

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.

Re:In related news

[Jah-Wren Ryel]

Didn't Linux invent the NIH syndrome or are they just pretending there too?

No, that happened long ago, back when it was SysV vs BSD. Even "standards" like POSIX and Unix95 are jokes because they tried to allow every vendor to keep doing their own thing as much as possible.

Re:In related news

[alukin]

I do not understand, really do not understand, WHY that shit he wrote is "in infrastructure". I never thought that I can hate free software developer. Now I do because of pulseaudio, The worst thins, that removing this piece of shit from "infrastructure" if harder and harder task.

Lennart is polluting infrastructure with his shit, that's what he does.

Re:In related news

[shutdown -p now]

From the perspective of a Linux UI developer, yes, OS X should be completely irrelevant - as it has an entirely different and incompatible graphics/UI stack.

(the fact that it is not really a BSD to begin with is another issue, but is not of importance in this context)

Re:In related news

[smash]

Making code cross platform exposes bugs and gets them fixed in the process. Both KDE and gnome have plenty of those, and could therefore benefit from maintaining portability.

Re:In related news

[PeterBrett]

cgroups -> jails

What on earth are you talking about? They have completely different aims and functionality!

Re:In related news

[Anonymous Coward]

Linux didn't invent it, but they didn't like the existing implementation so they went ahead and rolled their own.

Re:In related news

[stms]

Yeah I understand that OS X is pretty far away from BSD (though it is based on it). But their are some Linux Graphics/UIs that are compatible ever heard of this little piece of software called X Window System.

Re:In related news

[shutdown -p now]

X on Mac is a last resort measure, and not really an integral part of the system - somewhat like Wine on Linux. You use it when you absolutely need some piece of software running, but X apps look ugly as hell.

Re:In related news

[0x000000]

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.

Re:In related news

[wertigon]

I can't speak for all of these, but I do know that for ALSA Linux wanted something that didn't mix music in kernel space (like OSS did, and still does).

I'm pretty sure many other decisions follow the same lines. But we as end users rarely see this, we just see "WTF they broke my apps!"

And yes, poor documentation sucks major donkey balls. There should be a separate documentation team - with NO kernel devs - that ask and document the neccessary questions.

Re:In related news

[gtirloni]

Besides, systemd is Solaris's SMF made worse. Nice job there!

Re:In related news

[tyrione]

http://www.opensource.apple.com/release/mac-os-x-1068/

You can even recompile your Mach+BSD kernel and install it on your Mac or hackintosh.

Since Apple has also rejected GPLv3, they are moving away from all things GNU in their user space as well. That means they've contributed heavily to LLVM and clang to replace GCC, also under the BSD license and written an entire new libc/c++ which they've also open-sourced. They've probably done more for BSD-licensed OS work than anyone in the world at this point.

I'm not entirely sure why they get a reputation for being closed. It's true Darwin as a separately-installable distro never caught on and they ended the project, but they're very open and permissive about their core OS development.

First of all, all major architects of LLVM work for Apple. Secondly, Apple created Clang, LLDB and Libc++ for the LLVM Project, not to mention much more that is coming along. Not to nitpick but the point is LLVM would be as prevalent as GNU Hurd if it weren't for Apple taking over the vast majority of resource expenditures and bulk of the work. It is basically Apple's LLVM/Clang replacement to GCC for anyone to use who can't f'n stand GPL. I'm glad they finally did it. With 10.7 and iOS 5 GCC is done within Apple's own solutions, though GCC is available through MacPorts for anything newer than GCC 4.2, but officially no longer supported. Besides, Blender, Inkscape, Qt, Boost, the Linux Kernel, and several other projects are testing against LLVM/Clang to build themselves to have another compiler solution and less dependency upon GCC.

Re:In related news

[tyrione]

Lennart's an idiot then. Apple [NeXT augmented BSD from 4.3 onward to work with the Mach Microkernel from NeXT and alter the XNU kernel at Apple]. Lennart can work himself to the bone trying to mimic OS X, but he'll need billions in resources and thousands of quality engineers to pull it off. And to call FreeBSD from Debian a toy insults everyone within the Debian Infrastructure and all it's many users, myself included who wouldn't touch Linux if it weren't for Debian. And now, I'll add FreeBSD next to OS X, Openstep and Debian Linux to the list.

Re:In related news

[drinkypoo]

Lennart can work himself to the bone trying to mimic OS X, but he'll need billions in resources and thousands of quality engineers to pull it off.

Ubuntu Natty is very like OSX in every relevant technical way. I promise you I can find more ways in which they are like than ways in which they are different. Both have accelerated graphics interfaces which will tile your virtual desktops or your windows. Both have a unified menu bar, and both sometimes generate applications whose menu doesn't go there (when you run something targeted against an ancient API.) Both try to have a unified look, but both will run applications which use other widget sets and make your desktop look ugly. Both are Unix and neither are UNIX(tm). Both can be programmed in multiple languages but primarily C and C++. Both have components written in various languages, but primarily C and C++. Both have a capabilities-based security system. Should I really go on?

Your claim that you need billions in resources and thousands of quality engineers is close to the mark yet without actually hitting it. It's true that billions in resources and thousands of quality engineers must be involved, but it's not clear that one person must control them. The world has produced an operating system very like OSX, but one which is free, Free (with appropriate drivers) and Open Source, which makes it superior in my book. Indeed, anyone who claims that Linux cannot do more things than OSX "out of the box" is insufficiently familiar with both.

FreeBSD is a minor player compared to Linux. That's nothing against it, but the fact that there are multiple BSD forks and just one main Linux tree (there's tons of forks of forks of forks, but there's only one mainline for Linux, while there's four for *BSD now, if you count OSX) makes Linux more flexible and powerful than any single BSD. The same Linux runs in so many places! That makes it a more logical choice than a BSD for starting new projects.

Re:In related news

[drinkypoo]

They shouldn't have to be ugly, though. wxWidgets, GTK, and Qt are all skinnable, and at least some of them resolve to native widgets now. And even Ubuntu manages to put at least GTK and Qt apps' (haven't tried Athena...) menus into the menu bar at the top of the screen ala MacOS.

Re:In related news

[TheRaven64]

They don't fund FreeBSD development directly, but they are generally pretty good about relicensing any of their code that the FreeBSD guys might want to import. They also funded a lot of development of LLVM / Clang, which will be shipped in the base system in addition to GCC for FreeBSD 9, and replacing GCC in FreeBSD 10.

Re:In related news

[TheRaven64]

Speaking as a non-Apple LLVM developer: If you look at svn, you'll find a lot of contributions from the likes of Google, Adobe, AMD, ARM, Qualcomm, and Sun, as well as from numerous universities (UIUC still hosts the code and they typically have a dozen people working on LLVM-related projects). Apple shouts the loudest about using LLVM, but they're far from the only ones contributing. I wrote about 1% of the code in clang, and there are a lot of other non-Apple developers who have made similar-sized or larger contributions.

Re:In related news

[DarkOx]

important pieces of infrastructure

For highly inclusive definitions of important.

Re:In related news

[suy]

Have you bothered to read the interview? Lennart was talking about free software developers that cold be held back by the differences between Linux and BSDs. Those differences add complexity to support another OS that has small market share in the desktop OS in comparison with Linux (and this point is assumed, I don't know if it's proved somewhere).

That's sad but true, and happens everywhere. Sometimes you see how in the XDG list developers of one system (e.g. GNOME) are held back because KDE or XFCE don't invest the same amount of resources to one topic, while the opposite happens too (KDE moves forward in one topic that GNOME lags).

Want more examples? Debian wants to be an universal OS, so they have to support a wide variety of architectures, and now even different kernels. That's good, for sure (I'm a happy Debian user), but you have to admit that is a price that not everyone agrees if it's worth to pay.

Re:In related news

[That's What She Said]

Last time I checked, one could download Darwin as a full operating system.

I have no time to look for links now, but I am pretty positive, since I downloaded a ISO for the bootable installation disk some years ago. I remember trying it on a Dell PC and booting to the installer, but never got back ever since.

As you can see, I use a Mac and am part of the 0.0000001% of people in the world that use *BSD.

Re:In related news

[tepples]

No, comparing a platform (Android OS for phones) to a platform (iOS for phones).

Re:In related news

[Bing Tsher E]

True, but apparently this guy thinks the Microsoft model of 'build for just one platform' is superior.

Re:In related news

[Antique Geekmeister]

The MacOS kernel is not a BSD license, and has rather different policies.

      http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/APPLE_LICENSE

So no, it is not a BSD. Neither are other core components of the Apple's "Darwin" operating system.

Re:In related news

[dgatwood]

Have you bothered to read the interview?

Of course not. This is Slashdot. I read the summary, same as everybody else. ;-)

Lennart was talking about free software developers that co[u]ld be held back by the differences between Linux and BSDs. Those differences add complexity to support another OS that has small market share in the desktop OS in comparison with Linux (and this point is assumed, I don't know if it's proved somewhere).

What you see as being "held back" is what I see as designing for portability. Linux isn't always going to be the dominant open source OS, just as GCC isn't always going to be the dominant compiler and Bash isn't always going to be the dominant shell.

When Debian moved their default /bin/sh from Bash to Dash (which is a port of Ash from NetBSD, BTW), a lot of stuff broke because developers were coding to Bash-isms instead of coding to a pure Single Unix Specification.

When Apple began their shift from GCC to Clang+LLVM, a lot of folks have had to significantly fix GCC-isms in their code (and Clang has had to work around and attempt to support lots more of them) because the open source compiler world had previously become such an utter monoculture.

Do we really need, as an open source community, to make the same mistakes again with Gnome? It is always a mistake to code only to a single platform. For an example of why, you need only look to Apple. For a decade, they kept most of Mac OS X at least minimally functional on x86. Then, when IBM couldn't handle the power consumption needs of laptops, suddenly it became important, and they were able to very rapidly shift to x86. That flexibility also allowed for rapid bring-up of ARM, which came in handy when they decided to switch their iPod offerings from an embedded OS to a subset of Mac OS X and add iPhone, iPad, and Apple TV. None of that would have been possible in such a short time span were it not for the continuous background effort to keep that OS functional on another architecture.

The same thing happened, no doubt, in Linux at the kernel level when ARM-based netbooks started gaining popularity. That's why Android happened as quickly as it did; the OS stack had already been kept running on ARM by folks porting it to embedded systems, etc.

The same thing applies to higher level software like Gnome. The more you code to a single platform, the harder it becomes to port to other platforms in the future when the need arises... and eventually, it invariably arises.

Re:In related news

[Cyberax]

QT has been polishing their Mac OS X skin for 10 years by now. It still looks non-native on Mac.

There's only so much one can do with skinable apps.

Re:In related news

[linuxpyro]

I got curious about it and tired it out in a VM once. It was neat, from the standpoint of playing around with a different UNIX variant that I could get for free, but beyond that, what would be the point? It may be the core of OS X, and I'm sure it's a big help for people who want to do things like write device drivers for OS X, but I'm not sure I've heard of anyone using it as a desktop or a server (I mean aside from an OS X machine). So while you may be able to grab it and use it, if you want a server or a free UNIX-like desktop you may as well just go with a Linux distro or a BSD.

I mean, I'd be interested to hear if anyone uses OpenDarwin (or one of the variants) regularly, but it seems like for most things there's not much point.

Re:In related news

[drinkypoo]

What about GTK? I haven't messed with OSX in a few revisions so I don't have any recent experience. I find it odd that in a world where GTK can look just like Qt, and Qt can look just like GTK, that either ought to have trouble looking like OSX, let alone both.

Re:In related news

[mdf356]

Are you saying that there are? If so -citation needed.

Isilon's product is based on FreeBSD. ISLN was recently acquired by EMC (perhaps you've heard of them?) for 2.5 billion. At the most recent BSDCan there was a meeting of various vendors who sell a product based on FreeBSD, and there were other recognizable names in the room.

Re:In related news

[suy]

In general, I agree with you. The fact that Debian compiled all their packages on different architectures made software better, because it allowed to catch lots of endianess bugs, or 32bit-isms, even if nobody was using that software on that arch. Nobody was using KDE 3 on ARM, but now there are packages of some KDE 4 applications and technologies on ARM.

The problem is that making some compromise is necessary, or nobody will do vertical integration. For example, there are applications that could make use of file system metadata, but since the application developers strive for portability, they can't rely on it for important uses. Okular stores a configuration file for each file that opens, saving the page you were reading when you closed. If you store that information on the file system you can rename the file or remove it and everything is consistent. If you rename the file you lose that feature, and if you delete it you have a useless file lying there on your configuration. In this case is not a big deal, and I would not advocate to make this feature only available to systems with file system meta data. But there are situations were the compromise can at least be questioned and discussed, and dropping support for some platforms if there is an added gain that is more valuable, sometimes makes sense.

Re:In related news

[jmorris42]

> Darwin is the most popular version of UNIX as of today...

Nope. Android is already outselling the iPhone and it only gets worse from here on out. And for every iPod there are how many tablets, ebook readers, routers, tv sets, BD players, etc. running Linux? So that leaves desktop OS X vs Linux desktops and servers. Yes OS X has way more desktops/laptops in service but close to zero servers while Linux servers and appliances almost certainly outnumber hipsters with Macbooks. The OS wars are pretty much over and Linux has won. Microsoft owns the desktop, but realizes that doesn't matter much longer. Apple will be the choice for people who have more cash than common sense until Steve passes and ends the cult of Mac. Linux now rules the consumer electronic space and the (terrifying because of the DRM it promises) future of computing is its evolution into just some new categories of consumer electronics.

Apple had a brief shining moment of triumph when they surged to rule the mindshare of the decisionmakers and with their insanely great profit margins had so much cash flow it drove their stock into orbit, eclipsing Microsoft and challenging even Google. But that time is passing because it couldn't last. Apple, despite the current iPod exception, isn't a mass market business. It is an elite brand experience which is incompatible with volume success. The iPod slid out of focus as prices fell too low to support insane margins and it's functionality merged with the iPhone. The iPhone refused to compete with Android on price and thus is now #3 behind RIM and Google and will continue to decline until it hits the same ~10% as Macs historically exist at. If too many people start showing up with an elite brand it ceases to be an elite brand. If a shlub like me could swing a BMW the current doctors and lawyers would be forced to buy a Jag to display their higher status.

Re:In related news

[Bing Tsher E]

"out of the box"

multiple BSD forks and just one main Linux tree

You are making an apples/oranges comparison, it's obvious you know quite little about the BSD ecology.

The BSD OSes consist of a kernal and a complete userland, which even includes X11. Meanwhile, Linux is just a kernel, and there are dozens and dozens of different kludged together userlands that people combine with the linux kernel and call 'Linux.'

When a release of NetBSD is released (the BSD that I choose to use, but they are all released this way) a new version number is laid down for each utility or application that is considered part of the release. Everybody using NetBSD 1.4.1 has the same vi command, the same collection of daemons. The core configuration of my system is contained in text files in /etc that seldom ever need much if any modification with new releases. What version of any particular component of which bit of the userland that a Linux user has installed is far, far more chancey and undetermined. The Linux release mechanism is clanky and disjointed. The release mechanism for a BSD is one or two (a kernel and a userland) CVS tags and (for NetBSD) building binaries for a few dozen architectures.

BSD is a unified os. Linux is a kernal. A Linux os is a mashup. (I like Negativland, but I wouldn't hire them as architects to design a commercial building.)

Re:In related news

[Bing Tsher E]

A good example of Linux NIH is the TCP/IP stack. Virtually every other OS out there, including Windows NT, just adopted the BSD stack, which is widely considered the 'reference design.' Doing so makes intercommunication between all these OSes using TCP/IP much more bug-free and compatible. Linux, for obscure reasons, decided to branch off and invent their own stack. So Linux has always thereafter had it's own warts and peculiarities.

Because of the way the BSD code is licensed it is well suited to serve as a reference design, which promotes good intercommunication. The viral license Linux uses repels it's use in any project whose developers are not a 'fellow travelers' of the gnu ideology.

Re:In related news

[loufoque]

The core of Mac OS X borrows heavily from BSD

I think the word you're looking for is "steals", not "borrows".

Re:In related news

[Dahamma]

Bad example, that was not BSD modified code, it was a new library that was eventually ported to FreeBSD. No one said Apple doesn't release open source in general. It's obvious you need to learn better reading comprehension skills, but I'm not sure you are up to it.

Re:In related news

[drinkypoo]

QGtkStyle, which is now a standard part of Qt, uses GTK+ to render Qt widgets.

Re:In related news

[drinkypoo]

You are making an apples/oranges comparison, it's obvious you know quite little about the BSD ecology.

That's funny, because I could swear I've installed and used a whole bunch of BSDs, including SunOS4, AOS 4.3 and BSD 4.3-lite on IBM RT PC, and scads of others (not to even mention x86 variants!)

The BSD OSes consist of a kernal and a complete userland, which even includes X11. Meanwhile, Linux is just a kernel, and there are dozens and dozens of different kludged together userlands that people combine with the linux kernel and call 'Linux.'

In practice they all tend to run approximately the same userland at the same time, although they may have different widget sets etc. This is also true of BSD to a certain extent, in that basically everything in use today is descended from BSD 4.4-lite, including OSX... as NeXTStep inherited bits from 4.3-lite and 4.4-lite at different times.

Re:In related news

[mfwitten]

The nature of standardization is to recognize what is standard; of course POSIX tried to allow every vendor to keep doing their own thing as much as possible. What you're thinking of is innovation.

Re:In related news

[shutdown -p now]

wxWidgets is the only one that uses native widgets (and always did).

Qt draws the widgets itself, but tries to use the OS theming APIs to match the native look. Generally, it looks okay, but Qt apps compiled for OS X are not X Window apps, so that is irrelevant.

Gtk has some OS X-like themes, but they're all very far from perfect. Ultimately, so far as I can tell, and X Window app will have problem handling the top menu right no matter what. There is, apparently, a Gtk version that works directly on top of Cocoa, but it still draws the widgets itself (and is nowhere near as good at it as Qt), and is generally not all that stable.

Re:In related news

[Jah-Wren Ryel]

The nature of standardization is to recognize what is standard; of course POSIX tried to allow every vendor to keep doing their own thing as much as possible. What you're thinking of is innovation.

Written by someone who has never tried to deploy POSIX standard code on multiple vendor systems.

Re:In related news

[Galactic Dominator]

More dribble showing your ignorance. I suggest you read the history of Jordan Hubbard, then ask yourself why a top level Apple employee is making significant BSD licensed contributions to FreeBSD if your statement is correct.

Again, many other examples could be made but you do the practice. Keep trying!

Re:In related news

[Dahamma]

"We have ported libdispatch, Apple's Grand Central Dispatch event and concurrency framework to FreeBSD." Apple open sourced a library under the Apache license, and it was ported to FreeBSD, among other platforms. That's what I said.

You keep making irrelevant insults that don't even bother to focus on what the thread was talking about...

Anyway, why would I even want to debate anything with you? From your comment history you are a /. troll who gets off on insulting other people more than making sense. Your arguments would probably be much more interesting if you didn't have to be such a dick. Since that's not why I read /. and for some reason I have now stooped to your level, I'm done. Have fun.

Re:In related news

[dgatwood]

For extended attributes like that, the right thing to do is probably to use it if it is there, and to use a SQL database if it isn't. Sure, that won't survive moving the file to another system as metadata would, but that's not generally a deal-breaker. For handling renames, store more than just the filename in the database. On most filesystems, for example, you can store an inode number and be reasonably assured that it won't change unless you move it to a different partition entirely. You could also use a hash as a fallback; if the name and content hash match, you can generally assume that it is the same file even if you find it at a different path.

It's important to support such fallbacks when the user chooses a root filesystem that doesn't support EA, if you need to run on an OS that has limits on the size of data in EA, if the user is accessing files from an SMB or NFS share, etc.

BTW, most of the BSDs should support POSIX extended attributes already. FreeBSD supports it on both UFS1 and UFS2; NetBSD supports it on UFS1 (but not UFS2 at last check); OpenBSD... I think it supports them, too.

Re:In related news

[dgatwood]

Not even close, linux dominates in the server world...

Which is what, one half of one percent of all computers sold?

...and Android is based on linux, which is outselling the iPhone quite easily (up to 550,000 android devices activated PER DAY)

Yeah, but again, I'm not including embedded devices.

Re:In related news

[Galactic Dominator]

Pick the lamest of these 3 points:

1) You made a hideously inaccurate remark revealing your true understanding of the situation.
2) You attempt to defend the gross inaccuracy by saying I don't understand which is clearly a deflection technique against my criticism.
3) You want to somehow blame me for your ignorant comments.

Next time, don't present ignorant opinion as truth and we can all get along.

Re:In related news

[Ofloo]

Finally, ..

Re:In related news

[Ofloo]

the question is not, if it is opensource or not, it's if it is relevant, .. knowing that they use like 95% of the source of freebsd makes the comparison very relevant, ..

Re:In related news

[Bing Tsher E]

You've clearly indicated you have near zero experience with any of the modern BSD Oses in their current state. It's okay to have an opinion, but when you are so ill informed on how the modern BSD oses are packaged and distributed, the proper tact is to sit and listen, not carry on about the topic.

In practice they all tend to run approximately the same userland at the same time,

Did you even listen to anything that I read? The fact that Linux distros are 'dogs breakfast' collections of arbitrary versions of GNU flavor 'userland stuff' is a far cry from the ordered structure of the BSDs' userlands. You can check the entire BSD userland out of the source repository with a single CVS update command and run make. It's all synched together.

Re:In related news

[Cyberax]

So what? It still does not _behave_ quite like GTK.

Re:In related news

[exomondo]

I think the word you're looking for is "steals", not "borrows".

Neither term is correct for this situation.

Re:In related news

[exomondo]

The MacOS kernel is not a BSD license, and has rather different policies.

http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/APPLE_LICENSE

So no, it is not a BSD. Neither are other core components of the Apple's "Darwin" operating system.

We are talking about BSD the software, not BSD the license, so comparing the distribution license is completely irrelevant.

Re:In related news

[drinkypoo]

In practice they all tend to run approximately the same userland at the same time,

Did you even listen to anything that I read? The fact that Linux distros are 'dogs breakfast' collections of arbitrary versions of GNU flavor 'userland stuff' is a far cry from the ordered structure of the BSDs' userlands.

The problem is that you're wrong. Virtually all Linux installations have the same stuff in their userland. Sure, it comes from a variety of sources, but they are the same sources; and most of them are GNU. The others are either pulled from the same sources, or in the case of lightweight distributions, replaced with equivalents from busybox. Meanwhile, virtually all BSD systems end up with a bunch of GNU components, because the BSD equivalents (OK, the GNU versions are the equivalents... except they are more likely to follow SysV conventions than BSD ones when they have to choose one) are limited by comparison.

While I haven't mucked with FreeBSD, I have used OpenBSD and NetBSD on x86, though admittedly I have more experience with NetBSD on 68k... why use it on x86 unless you have a lot of it on other architectures? And I understand that they have a source tree, and some kind of port tree. And I also understand that all three of these operating systems are descended from BSD 4.4-lite, a sanitized release of 4.4-BSD which does not contain any third party copyrighted code. And no, I'm not looking this up, which is why I don't know the dates. I looked all this up when I cared about BSD. Those days went away as more Linux ports were merged back into mainline. I have nothing against BSD, though.

Today I can download all the sources for a Linux distribution from a single repository, so even though they have many origins I don't have to go hunting them down like I would if I built from scratch, which I don't recommend. It's not as rewarding as you might imagine. The only reason the typical user ought to be rebuilding the entire system is if they are on a wacky architecture for which there is no official build. I've built my own gentoo system for k6, for example, because it's a great CPU but a lousy i386. And amazingly, I didn't have to go looking for source packages. So while I understand where the BSD userland comes from (again, BSD 4.4-lite) and I even know that a complete Linux userland comes from a lot of disparate places, I also have built busybox and I know that you can have a quite complete Linux system with nothing but Linux, glibc and friends (the full GNU toolchain... I mean, if you're not self-hosting you ain't shit) and busybox. And, of course, a handful of scripts. Throw in another daemon or two (e.g. udev) and it's not even unpleasant. I would be surprised if you couldn't do the same with a BSD kernel and libc.

So at the risk of being repetitive; I've run fairly recent BSD, but you only need to have run anything descended from 4.4-lite to get the picture of where it all comes from. Actually, you don't even have to have run it, but I've run it myself. I've built netbsd from source for mac68k and run it on a IIci. And my point in mentioning the RT PCs with AOS 4.3 (BSD 4.3) and BSD 4.3-lite is knowing both where BSD came from, when it was let go by Berkeley, and where it went thereafter. I've also built gentoo from source (stage1) for the k6 so I've watched the sources fly in and during the stage1 more of them came from the same spots than not. It's not a coincidence that many people insist on calling it GNU/Linux; in the typical base Linux system there's virtually nothing that isn't one or the other.

Re:In related news

[jon3k]

It's just staggering, absolutely. The other thing to consider is not only the number of activations but the incredible rate of increase in activations per day by android devices. I remember about a year ago it was only about 200k android activations per day.

Re:In related news

[jon3k]

Not including embedded devices is incredibly arbritray when there are more smartphones sold than PCs. You're ignoring the fact that a smartphone is a handheld computer. For many people it's their _only_ computer. It's a fundamental shift in computing and ignoring it is a vast oversight.

Re:In related news

[MachineShedFred]

If comparing platform to platform, be sure to add in iPad and iPod Touch then. Oh wait, that might skew your numbers towards reality.

Re:In related news

[evilviper]

He's saying BSD isn't really relevant on the _desktop_ (and sorry but no, OS X is not a counter-example to this

Actually, no. He's saying EVERY OTHER POSIX OS isn't relevant, which means OS X is most definitely a couter-example. Not just BSD, he's strictly Linux-only, an atitiude which is so wrong

Also, he's talking about SOUND systems, something which is certainly NOT desktop-only. Desktop tasks just happens to be the predominant use for audio on a Unix system. I know I routinely use ESounD to output audio from multiple Unix (Linux, BSD, Solaris, AIX, SCO, etc) and Windows systems over the network to a headless server with a soundcard...

Re:In related news

[dgatwood]

I'm not ignoring it. I'm simply acknowledging that embedded devices are almost all specifically designed to not expose their UNIX/Linux underpinnings to users unless you take fairly drastic steps to gain access to it (jailbreaking, rooting, uploading custom firmware images, whatever). Therefore, at least as far as the user is concerned, they use a black box OS, not UNIX or Linux.

Further, many embedded devices don't even come with a shell installed, nor even the most basic command-line tools, much less a compiler, make, etc. You can't really call something UNIX/Linux if there are no UNIX/Linux bits above the kernel level. AFAIK, you can't even run the Single Unix Specification or POSIX test suites to test compliance without those bits, much less pass them.

Embedded devices are a far cry from Mac OS X or a desktop Linux distro, where you can simply run a terminal application and gain access to a full set of command line tools with a range of standard shells.

Re:In related news

[mfwitten]

The nature of standardization is to recognize what is standard; of course POSIX tried to allow every vendor to keep doing their own thing as much as possible. What you're thinking of is innovation.

Written by someone who has never tried to deploy POSIX standard code on multiple vendor systems.

Written by someone who still doesn't understand the POSIX standard; if a system is POSIX compliant, then you know all of the possible behaviors, because they are listed in the POSIX standard. That's the point.

Re:In related news

[Jah-Wren Ryel]

Written by someone who still doesn't understand the POSIX standard; if a system is POSIX compliant, then you know all of the possible behaviors, because they are listed in the POSIX standard. That's the point.

Just what do you mean by "all of the possible behaviours?"

Try this on solaris and then try it on hp-ux:

shm_open("/shm-test", O_RDWR, 0600);

It will work on solaris and fail on hp-ux because the underlying mechanism for tracking the shm namespace is undefined by posix, so different vendors have implemented it in "innovative" ways. Posix is riddled with shit like that.

Re:In related news

[jon3k]

You're using an arbitrary argument - "it doesn't give me a familiar set of userland tools so somehow it's not linux". It makes no sense. Access "under the hood" doesn't change the platform underneath.

Re:In related news

[Grishnakh]

That sounds like BS to me. According to this logic, we can also consider every Linux distro to be BSD, since they all use openssh, which is a project that's part of openBSD. Or, even more relevantly, because the Linux kernel incorporates some BSD device driver code, we can call Linux "BSD".

Sorry, I don't think so. Taking some small parts of BSD code and integrating them into something much larger, which is substantially NOT BSD, does not mean you can call that larger item "BSD".

OS X is not a BSD. It has some BSD elements, but so does Windows. Only an insane person would call Windows a BSD project. OS X doesn't use the BSD kernel, it just uses a few userland tools (to my knowledge). The vast majority of OS X is NOT BSD, it's a Darwin microkernel (which is open-source too, but no more part of BSD than Apache is), plus a ton of proprietary Apple stuff on top for the GUI and libraries that all the applications use.

Re:In related news

[mfwitten]

It is, as you say, undefined by POSIX. What's your point? What do you not understand about this?

Re:In related news

[Jah-Wren Ryel]

It is, as you say, undefined by POSIX. What's your point? What do you not understand about this?

Let me get this straight.

You are saying that a function that is included in the posix standard isn't really part of the posix standard because the standard doesn't fully define a required part of the function?

Well then, I guess we can just throw out about half of the standard then. Perhaps we could call what's left the POSIX2008.witten standard, eh?

Re:In related news

[mfwitten]

My point was simply that you cannot rely on undefined or implementation-defined behavior across implementations. Moreover, part of the purpose of a standard is to provide a centralized delineation of exactly what is defined behavior, what is implementation-defined behavior (including the set of possible implementation choices), and what is undefined behavior; this is far preferable to only having a collection of a myriad of proprietary documentation (most of which is often incomplete).

Now, help me understand your scenario.

Try this on solaris and then try it on hp-ux:

shm_open("/shm-test", O_RDWR, 0600);

It will work on solaris and fail on hp-ux because the underlying mechanism for tracking the shm namespace is undefined by posix, so different vendors have implemented it in "innovative" ways. Posix is riddled with shit like that.

Am I to assume that the shared memory object named "/shm-test" already exists? If it does not, then I would expect a failure with errno set to ENOENT, as per the POSIX:2008 (IEEE Std 1003.1-2008 Base Definitions, Issue 7) documentation.

What are you experiencing that is particularly annoying?

Re:In related news

[Jah-Wren Ryel]

My point was simply that you cannot rely on undefined or implementation-defined behavior across implementations.

Really? Ya think? Thanks for clearing up the obvious.

Moreover, part of the purpose of a standard is to provide a centralized delineation of exactly what is defined behavior, what is implementation-defined behavior (including the set of possible implementation choices), and what is undefined behavior;

The thing you seem unable to grasp is that an incomplete standard is worse than no standard at all. Leaving key components undefined and not even mentioning that they are vendor-specific sure as hell ain't innovation, its just standards-group politics.

Am I to assume that the shared memory object named "/shm-test" already exists? f it does not, then I would expect a failure with errno set to ENOENT

Again with the captain obvious stuff.

Re:In related news

[mfwitten]

Well, you've brought the discussion full circle: What you don't seem to grasp is that standardization is not about innovation; it's about recognizing long-existing commonality and what has been proven to work or be useful, which is exactly what POSIX does and which is exactly why POSIX leaves some behavior as implementation-defined or even undefined.

The C++0x standard is another good example of standardization done properly; rather than innovate FROM THE STANDARD, it largely just recognizes widely used stuff that has been around IN PRACTICE for a long time (boost libraries, constructs from other languages, usage patterns, design patterns, etc.).

In any case, I see you've declined to justify your example.

Re:In related news

[Jah-Wren Ryel]

What you don't seem to grasp is that standardization is not about innovation;

Never said it was, that's your defense for an incomplete and ill-defined standard.

it's about recognizing long-existing commonality and what has been proven to work or be useful,

No it's not. "Recognizing commonality" is just the means. Standardisation has one and only one legitimate purpose - making customers' lives easier. Half-assing a standard to the point of significant ambiguity is counter to the entire reason for standardisation.

In any case, I see you've declined to justify your example.

I don't need you to debug what's broken. I know exactly why both solaris and hpux behave the way they do because I ran it down along with a bunch of other posix ambiguities over the years. If you really want to debug it, go ahead - compile and run it yourself.

Re:In related news

[mfwitten]

LOL

Re:In related news

[Jah-Wren Ryel]

Virtually every other OS out there, including Windows NT, just adopted the BSD stack,

Nope, never did, never will. First it was a port of the Spider Systems stack and then it was replaced with something homegrown. FWIW, I know the Spider stack pretty well from a long-defunct HPC unix variant I used to support (actually, I've tried hard to forget it, Spider was a real PITA).

http://www.kuro5hin.org/story/2001/6/19/05641/7357

Re:In related news

[aztracker1]

hoping you meant source of TFS, not me... "I don't know that I agree."

Re:In related news

[iggymanz]

you can put the familiar LInux UIs on Mac OSX, including gnome and kde.

I have 25 year experience in systems programming and admin on BSD, of course Mac OSX is a BSD. that you think it isn't means you don't know what a BSD is.

Re:In related news

[shutdown -p now]

you can put the familiar LInux UIs on Mac OSX, including gnome and kde.

You can put KDE on Windows, too, and I think you can put Gnome as well if you run an X server.

So what? No sane Windows user would run things that way, and no sane Linux developer should consider that as a target platform for his software (unless he's feeling masochistic).

Pragmatically, OS X is the same. Yes, you can write a program for it using, say, Gtk - but it will look like crap, and users will treat it like crap - and rightly so. If you write apps for OS X, you should use native APIs for that. At which point the relevance of it all to a Linux developer is exactly nil.

Re:In related news

[iggymanz]

Linux and BSD developers have targeted and ported to osx and windows, there are reasons one might want to run a kde or gnome or other app there. I have such useful apps on my employer's metaframe server. My wife and children run certain linux apps on their macs. Just because you think it's pointless doesn't mean all others do.

PulseAudio?

[0100010001010011]

This guy needs beaten just for this.

Re:PulseAudio?

[0racle]

I'd like to beat him for systemd while we're at it.

Re:PulseAudio?

[causality]

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.

Re:PulseAudio?

[bcrowell]

This guy needs beaten just for this.

Can slashdot start allowing posts to be modded up to Score:6, Insightful -- just so we can apply it in this one case?

But to be fair, BSD does have its problems. I ran FreeBSD on both my desktop and my server for years. It was OK as a server OS, but not so great on the desktop. I had a list of open-source apps I wanted to run, and I could only get about 85% of them to run at any given time. That's why I jumped ship when ubuntu came along.

Re:PulseAudio?

[Windwraith]

I used to share your opinion after I moved to Ubuntu from Gentoo. Specially developing games, Pulse caused a lot of lag and made coding sound effects terribly hard. My first install task was to remove pulse and set SDL to use ALSA.
However, one or two Ubuntu releases ago, it started to just work© and haven't had a complaint about it since then (except for the huge pipes (?) stored in /dev/shm, a directory I use often, and doesn't cause lag in my tracker or my games anymore. That's enough for me, saves the trouble of having to excise it.

Re:PulseAudio?

[fnj]

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.

Re:PulseAudio?

[causality]

Want a dual-boot Linux/Windows system with /user on an NTFS partition? Sorry, PulseAudio wont let you. WTF?!

Poettering is the poster child for crappy Linux developers.

How and why would a sound daemon even know or care about the filesystem type for any kernel-supported, read-writable volume? While the objections to PulseAudio are legion, I have never heard this particular one before.

Re:PulseAudio?

[0123456]

What's so significant about /user?

I presume they mean /home, and I'm surprised that much of anything works if you're weird enough to mount an NTFS partition there. I'm guessing FAT32 wouldn't make it very happy either.

I believe the issue is that Pulseaudio wants to set specific permissions on $HOME/.pulse and NTFS doesn't support them. SSH probably won't work either and I suspect that a bunch of other programs will fail.

Re:PulseAudio?

[Billly Gates]

The only problem I had were Java apps 6 years ago. Netbeans and Eclipse were certainly problematic. Gnome was becoming linux centric and I believe I only had a problem or two with it. At the time I used WindowsMaker.

FreeBSD was excellent for me as a desktop. I wonder what recent changes happened?

Re:PulseAudio?

[wagnerrp]

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.

Actually, that's not entirely true. You're not replacing PulseAudio with anything. ALSA is already installed and set up, because ALSA provides the hardware access that PA is layered on top of. PA has no hardware support to survive on its own. You're just removing PA so the applications can hit ALSA directly.

Re:PulseAudio?

[tusam]

Count me in for avahi, our office network uses .local, if avahi is running nothing in LAN works.
While I realize mDNS isn't his fault there should definitely be a user friendly option to disable it (on install time or like that "Proprietary drivers available" popup on Ubuntu).
Still, have to wonder how much wasted time has this guy's creations imposed on the world.

Re:PulseAudio?

[visualight]

He can't open his mouth without sounding like an arrogant punk. All of his ideas are bad ideas. I'm really really tired of these people (the turks at fedora) forcing their incredibly narrow use case down everyone's throat. If I wanted to use only a laptop and have it look and act just like a MAC then I'd go buy a god damn MAC. I just have my fingers crossed that systemd doesn't spread like the algae bloom that pulse audio is/was.

Re:PulseAudio?

[PeterBrett]

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.

So, tell me. How, using ALSA, do you turn on a pair of BT headphones and redirect sound from running apps to them?

I too had problems with PA when it was initially introduced, but now I haven't had any problems with it in literally years. These days it Just Works, and I've used some of its nifty features from time to time. To claim that it doesn't solve any relevant problems or that raw ALSA should be the default is completely bogus, TBH.

If ALSA were a barely-functional, poorly designed sound system...

It is.

Re:PulseAudio?

[wertigon]

"Oh something new and shiny that breaks backwards compatibility! Therefore it must automaticly be bad!"

The rationale behind systemd is quite sound. Go and read it and then come back to complain.

Re:PulseAudio?

[Chris Mattern]

"Oh something new and shiny that breaks backwards compatibility! Therefore it must automaticly be bad!"

Well, yes, actually. Breaking backwards compatibility is always bad. It may on occasion be necessary to do so to gain a greater good, but it's still bad.

Re:PulseAudio?

[Burpmaster]

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.

What would you think of the following hypothetical complaint?

I don't blame him for creating X. I blame the distribution maintainers for having the poor judgment to make it the main interface for so many distributions. It would be one thing to have a sane default like text consoles and then have X 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 X. If so, I remove it and replace it with screen. Suddenly issues related to mice go away and everything just magically works. Oh and they easily have a proper task switch without jumping through hoops, too, which is handy considering some of them are using international keyboards and/or aalib.

The first headache I had with X was when I tried to run something as a different (normal) user account and graphics wouldn't work. There was no meaningful error message. There was only a "cannot open display" error in the terminal. As it turns out, this is because X has to be run by the user and it is recommended not to run it as a system-wide server. User A was running the X server 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 screen since X didn't do anything I needed it to do that screen couldn't do with none of the hassle.

Surely you know enough about X to understand the errors and mis-diagnoses made in the third paragraph. Well, they are exactly analogous to your own error and misdiagnosis about PulseAudio. First, the error message is actually very meaningful. It's telling you it can't talk to the server. So right away you should know to check that the server is running, that the app is trying to talk to the right server, and that it has permission. But you instead mis-diagnose that you need another server running and waste time trying to set up a configuration that won't work.

You'd have that same attitude toward X that you have toward PulseAudio if X was as new and unfamiliar to you as PulseAudio is.

Re:PulseAudio?

[drinkypoo]

I've had several machines where the hardware mixer doesn't work. If you try to use it, the applications think it should be working, but you hear one thing, or no things. The most recent was a Compaq nw9440 Elitebook with HDA Intel. An audio daemon is a good thing. Shoulda been JACK.

Re:PulseAudio?

[visualight]

Uh, fuck you AC
I said *fedora* . And I meant *fedora*. Don't come into my conversation an try to bring the whole world into what applies to two jerks at fedora with more influence than they should have.
Also, I didn't say anyones code sucks. I said the man has bad ideas. Now go take your medication.

Re:PulseAudio?

[fnj]

You seem to have an unwarranted idea that I have NOT read it, comprehended it, and REJECTED it.

Re:PulseAudio?

[wertigon]

"It may on occasion be necessary to do so to gain a greater good, but it's still bad."

Of course it is. But that doesn't mean the entire new system is a PoS that needs to be replaced now does it?

While the transition period was indeed painful, PA today works just fine for me on latest Ubuntu (though now it's Unity and display drivers that mess up instead -_-;;), I get low-latency playback and it's great for all your consumer needs - and if you REALLY need to go a step further for "pro" use there's Jackd.

Systemd, likewise, does a great job of reducing and/or eliminating the kludges of SysV init (which Ubuntu also has abandoned in favor of Upstart, which isn't as good as Systemd). I don't say Systemd is neccessarily *the* answer, but when the *only* reason not to use it is "Because it'd break compatibility with the rest of Unixes", well, in that instance Poettering is right; why should we hold back?

Re:PulseAudio?

[wertigon]

Gratz, then you are 0.000001% of the tiny minority that actually did so. Most of the rest of the comments QQ:ing about Systemd/Pulse have not.

Re:PulseAudio?

[naasking]

Funny, I have the exact opposite experience: solving ALSA issues on a barebones Linux install is tedious and annoying. Instead, I just install PulseAudio, and everything automagically works. You should install blame the distributions for not understanding and Pulse, and configuring it incorrectly. That's the real source of hte problems, most of which are now ironed out from what I've heard.

Re:PulseAudio?

[badkarmadayaccount]

What is the technical difference between systemd and upstart?

Re:PulseAudio?

[badkarmadayaccount]

ALSA plug-in system?

Re:PulseAudio?

[wertigon]

A few differences, the biggest being that services aren't started unless explicitly requested. You can read more on Upstarts limitations here (see "On upstart"): http://0pointer.de/blog/projects/systemd.html

Does Netcraft confirm this?

[mlts]

Just curious... does Netcraft confirm this?

Re:Does Netcraft confirm this?

[webmistressrachel]

Damn you beat me to it. The famous troll appears as a front page article. Maybe a really old troll got promoted to editor status. /troll

Re:Does Netcraft confirm this?

[DeVilla]

Dunno. How about Minecraft?

Like SpinalTap

[jvillain]

I guess Gnome is becoming more selective in it's appeal just like SpinalTap.

That's funny.......

[cyberkahn]

I will be sure to let the good folks at Juniper know.

Re:That's funny.......

[xgadflyx]

Make sure you forward that to Apple and McAfee/Sidewinder, K, thanks!

Re:That's funny.......

[ampmouse]

And don't forget about EMC Isilon.

Re:Linux itself isn't relevant anymore

[siddesu]

Why are you using "anymore"? When was Linux ever relevant on the desktop?

Disclaimer: linux desktop user

Re:Um... Pardon Me, But...

[hedwards]

Here's a hint, it's unlikely that you would be on slashdot if not for BSD.

Re:Linux itself isn't relevant anymore

[glwtta]

Linux zealots remain convinced than "next year will be the year of Linux on the desktop"

Heck, next year isn't even the year of the desktop anymore.

Pulse Audio

[Beelzebud]

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.

Re:Pulse Audio

[Anonymous Coward]

He has a tendency to develop things halfway, without taking any input from any users, and then everyone using Fedora has to end up using it even if it's complete shit. If you criticize him, he's got some staunch defenders that will call you out on it, mostly the people who have only ever used Linux on a laptop... that really does seem to be the only thing he cares about.

PulseAudio - a useless NIH layer. ALSA was just fine. He lists a bunch of other problems with Linux audio, but everyone was just using ALSA directly, nobody was using his straw men really (Jack? OSS? Really?) This is the first thing I remove on my Linux boxes.

I predict systemd will be his next "hit". He named the control command "systemctl" even though every Linux has a "sysctl" command already... one of the most easily avoidable CLI namespace problems I have ever seen in over 20 years of UNIX and 18 years of Linux administration. I think systemd is because he really really wants to make Linux into MacOS X. If you want MacOS X, then great, it's a fine desktop OS, have at it.... but Linux is still mostly used on servers, and there is nothing wrong with that at all. Anyway, systemd just throws out everything that was good about init and even upstart, and starts over, and he is busy adding the features of cron and inetd to it for some reason. Because saving some tiny amount of space in the process table is somehow useful.

I just wish there was some review of features that make it into Fedora, etc, to see if they're really worth it.

Re:Pulse Audio

[Tragek]

Mmm. I'm still bitten every day by pulse problems, hate it intensely. However, I can't hate lennart for it, because as near as I can tell, IF you can get a distro that's done the packaging correctly AND you don't run into problems, it's amazing.

I just think it's nuts that I have a key-stroke to call pulse-audio --kill

An aside: Am I the only one who always preferred the BSD userland to the GNU/Linux?

Re:Pulse Audio

[Anonymous Coward]

Your post is complete nonsense.

ALSA was not fine when PulseAudio was started -- that may have changed, but I doubt it. Software mixing doesn't belong in a kernel, it couldn't re-route audio on-the-fly to different outputs, dmix didn't work with different sample rates (and apps using alsalib naively would randomly fail because of that), there was no per-application volume, etc. etc.

re: Systemd

The "event" model in upstart is shit and the core developers have admitted as much (search the mailing list for the later posts of SJR). systemd actually does what an init system should do, and does it properly. (Socket activation means dependencies don't need to be declared. It just works.)

Re:Pulse Audio

[Anonymous Coward]

ALSA and OSS always just worked for me.... all the way back from the first time I tried audio on Linux with OSS on a 1.0.x kernel. I have been using Linux daily as my main desktop OS since 1993, with a variety of soundcards (mostly Soundblasters and recently more onboard integrated audio, but also a variety of other cards), and I'm telling you, I never had the problems PA was supposed to solve with just directly using ALSA. Now I get fewer functions and PA uses more CPU. Great. Removed.

Regarding systemd:

System-V init actually does exactly what a Unix-like system needs it to do... but regardless of that, my problems with systemd are:
1. If you even suggest for a second that systemd isn't awesome, you will hear from people (for example.... you) who says it's great, without addressing any concerns that system admins actually have.
2. The command line interface is annoying... it's even worse than the problems we have with SMF on Solaris 10+. Following the original threads about it, you can tell Lennart has no idea what people actually do with the command line. systemd calling $MORE? Hasn't anyone ever used expect?
3. They want to roll cron and inetd into it... for no reason that I can see. Vixie cron and xinetd both work great last I checked. This seems to be bacause that's what MacOS X does with launchd, not for any real reason.
4. Doesn't socket activation require changes to daemons?
5. D-Bus dependency. On my init system. Sounds awesome, where do I sign up. systemctl actually didn't work at first on my F15 box because... I don't run dbus (standard X11 window manager, I don't generally use Gnome or KDE, lucky me.)
6. Optimizing for a problem most Linux boxes don't have... reboot speed and dependency resolution, which really sounds like something I do as little as possible. I run 100s or 1000s of boxes... reboot speed is rarely my concern... my boxes spend more time in POST then they do mounting filesystems and starting sshd these days. Sounds like a laptop problem to me.
7. No separate /usr... and when you ask about it you're told "you don't want that." Now, I don't ever separate /usr if I don't have to, but I do not think that is an adequate answer, and I know people this is going to seriously affect at some point.

My concern is that systemd is going to make it into CentOS and RHEL at some point, and that will suck for me, unless Redhat actually makes some changes to it.

Am I still talking nonsense or are you just blind?

Re:Pulse Audio

[luther349]

thats couse fedora is just a huge testbed for there enterprise edtion. in short they care less abought it untill something that acully works makes it in. then they just toss it in the pile.

Re:Pulse Audio

[gmueckl]

From what I've read about systemd the most irksome part is that every daemon that wants to really work well with systemd must undergo quite some code changes. Otherwise, that particular demon will be handled like in the old init system. So, in order to bring any benefit at all, the whole system (which worked) must be adopted to systemd in some way. Given that some of these demons are really there to be run on servers where systemd has no place, this thing does not seem like a very good idea.

But unlike PulseAudio, i haven't had a chance to see systemd fail spectacularly.

Re:Pulse Audio

[Richard W.M. Jones]

PulseAudio sucks, but systemd is reasonable stuff. It's like upstart (but done right) combined with inetd.

Unlike what another reply says, systemd does not require changes to daemons.

Rich.

Re:Pulse Audio

[PeterBrett]

1. If you even suggest for a second that systemd isn't awesome, you will hear from people (for example.... you) who says it's great, without addressing any concerns that system admins actually have.

Mainly because said concerns tend to boil down to "Waaah, it's different." Oh no.

2. The command line interface is annoying... it's even worse than the problems we have with SMF on Solaris 10+. Following the original threads about it, you can tell Lennart has no idea what people actually do with the command line. systemd calling $MORE? Hasn't anyone ever used expect?

"Annoying" is an opinion. Could you please link to said threads?

3. They want to roll cron and inetd into it... for no reason that I can see. Vixie cron and xinetd both work great last I checked. This seems to be bacause that's what MacOS X does with launchd, not for any real reason.

There are some advantages, such as per job/per request cgroups to make sure that all processes get cleaned up correctly. I'm not particularly bothered either way. Note that "in systemd" doesn't mean "in PID 1".

4. Doesn't socket activation require changes to daemons?

It does. However, you don't need to use socket activation -- "classic" forking services can be used just fine. Obviously, yes, if you want all the advantages of systemd, daemons do need to be modified to receive their sockets from systemd.

5. D-Bus dependency. On my init system. Sounds awesome, where do I sign up. systemctl actually didn't work at first on my F15 box because... I don't run dbus (standard X11 window manager, I don't generally use Gnome or KDE, lucky me.)

Some sort of RPC was needed for communication between systemctl and PID 1. TBH I would rather systemd used a solution that's already widely used in the Linux desktop, is well-maintained and robust, rather than Lennart rolling his own NIH version. But maybe that's just me. It doesn't seem like an unreasonable design decision to me. What solution would you prefer?

6. Optimizing for a problem most Linux boxes don't have... reboot speed and dependency resolution, which really sounds like something I do as little as possible. I run 100s or 1000s of boxes... reboot speed is rarely my concern... my boxes spend more time in POST then they do mounting filesystems and starting sshd these days. Sounds like a laptop problem to me.

As far as I can tell, systemd is also optimised for ensuring that login sessions and daemon processes are correctly & fully cleaned up (for example, if you're rebooting apache, systemd will make sure all the processes apache forked are terminated -- something SysV init can't do).

7. No separate /usr... and when you ask about it you're told "you don't want that." Now, I don't ever separate /usr if I don't have to, but I do not think that is an adequate answer, and I know people this is going to seriously affect at some point.

"systemd itself is actually completely fine with /usr on a separate file system that is not pre-mounted at boot time. However, the common basic set of OS components of modern Linux machines is not, and has not been in quite some time. And it is unlikely that this is going to be fixed any time soon, or even ever." People seem to be very keen to shoot the messenger (i.e. the systemd devs) for warning them that about breakage that has been present since before systemd existed.

Gah, I don't even run systemd myself and I seem to know more about it than most people commenting on this article...

Re:Pulse Audio

[naasking]

From what I've read about systemd the most irksome part is that every daemon that wants to really work well with systemd must undergo quite some code changes.

Not from what I've read. If your daemon already works with inetd, no changes are necessary. Otherwise you just need a small startup file describing the sockets it binds. You can make some optional code changes to make startup even more parallelizable, but these are strictly optional.

Re:Pulse Audio

[badkarmadayaccount]

point 2 - please clarify.
point 3 - xinted duplicates iptables, systemlog and cron functionality - what gives? (I agree). Cron - I also agree. Though that seems rather minor.
point 4 - socket activation - please clarify
point 5 - Considering it manages processes, it makes sense to have IPC, possibly standard - hence - D-Bus. What's stoping from running D-Bus anyway?
point 6 - if it doesn't make anything worse for you, then you have no basis to complain. Go and contribute to coreboot if you don't like your POST time.
point 7 - please clarify

Re:Linux itself isn't relevant anymore

[hedwards]

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:Linux itself isn't relevant anymore

[camperdave]

Linux on the desktop is so last year...

Re:Um... Pardon Me, But...

[scubamage]

Yeah, it was. BSD was THE unix for awhile after AT&T got split up. In the early 80's BSD was the basis for a lot of proprietary Unix's. Afterwards, the *BSD projects came out. It was incredibly important for awhile. Further, I know a couple of places that still use net-bsd with switch cards and iptables/ipchains to act as a second tier firewall after a hardware appliance. They work quite well. I wouldn't touch it with a 10 foot pole for anything desktop related though.

Re:Um... Pardon Me, But...

[Greyfox]

Must have been a busy day for it!

Of course

[tpstigers]

BSD is irrelevant. Nobody's played Doom for years.

Oh, wait.... Maybe I'm thinking of BFG.

Re:Of course

[VortexCortex]

What? People play Doom all the time...

Re:Of course

[perryizgr8]

BIG FUCKING GUN!
i was actually playing doom (the original one) a few hours ago and am a little psyched.

Re:Um... Pardon Me, But...

[TheGratefulNet]

not sure about today, but years ago, Juniper networks used freebsd inside, to run the userland side of their core routers.

netbsd was used (also about 10 yrs ago, a lot) for non-intel style embedded network devices. I was at a router/switch company and we used netbsd (ppc arch. at the time).

can't say I ever ran into a bay area company, during my travels, that used openbsd. but back about 10 yrs ago, freebsd and netbsd *were* quite popular in the enterprise. corp people didn't like the GPL (at least at the time) and bsd was the most business-friendly license they could find.

Re:Linux itself isn't relevant anymore

[ChunderDownunder]

Precisely. Linus' kernel has found critical mass in Android. It uses as little of GNU as possible and - it's just a kernel - Google could port dalvik to one of the BSDs within a year without too much trauma.

I'm still hopeful we'll see desktop wayland-enabled meego/webos to save us from Gnome3/Unity!

Re:Um... Pardon Me, But...

[epine]

Was BSD relevant at some point? I think I was sick that day. Could you fax 'round the memo so I can update the logs? "BSD was relevant today. Huzzah! Who knows what tomorrow will bring!"

Remember to sign your entry "So long, and thanks for all the packets!"

Tomorrow will bring a centrally controlled internet. Huzzah!

Re:Um... Pardon Me, But...

[aztracker1]

Agreed, though PC-BSD is really nice, on supported hardware, the lack of, and/or late driver support is just unbearable... Really nice for network (monowall) or NAS (FreeNAS) base OS though... stable API structure good... breaking everything under the sun every other kernel update, bad.

Re:bah

[larry bagina]

avahi is fine (it's a re-implementation of Apple's bonjour/zero-conf for broadcasting local dns and services. quite useful).

Netcraft Confirms

[Anonymous Coward]

You are new here, aren't you.

Re:Um... Pardon Me, But...

[Dahamma]

Yeah, there was this company called Sun that had some small server market share a ways back, using an OS based completely on BSD...

always wondered why PulseAudio sucked

[decora]

now we know.

the developer lacks humility.

Re:always wondered why PulseAudio sucked

[fnj]

You put it too kindly. I would say he is a punk.

Re:always wondered why PulseAudio sucked

[Urkki]

now we know.

the developer lacks humility.

I think it'd be more accurate to say, his level of social and/or technical ability is not in balance with his level of humility. This is a pity, as his level of humility might be suitable for da Vinci, Newton or Einstein.

didnt openbsd develop ssh?

[decora]

that basically everyone and their brother uses?

Re:didnt openbsd develop ssh?

[TheGratefulNet]

and its *in* every os. but that doesn't mean openbsd has any real relevance as an *os*, really. I don't know a single person who runs openbsd today; but I could say otherwise 10 or more years ago. its advantage is just not there.

ssh is great. we like ssh. ssh is everywhere, though.

Re:didnt openbsd develop ssh?

[Noryungi]

I use OpenBSD every day - one of my machines has been OpenBSD-only since day one.

I run OpenBSD on 90% of the infrastructure of a small ISP I created with friends. The remaining 10% are FreeBSD only.

As a matter of fact, if you are running anything like a serious infrastructure, Linux is out of the picture entirely. FreeBSD, OpenBSD and NetBSD are the way to go. OpenSSH owns the SSH field for a good reason: because it's based on one of the most secure OS out there. And the programmers of both OpenBSD and OpenSSH have a well-deserved reputation for quality code.

Just because you are your friends don't know how to run and administer OpenBSD does not mean it's irrelevant.

Re:PulseAudio sucks cpu

[dfries]

ogg voribs playback using Alsa 5.7% CPU usage total
use PulseAudio and the PulseAudio daemon takes 36% CPU

That's telling when it's taking less CPU to decode compressed audio than it does to forward the audio to the sound card. Maybe PulseAudio was doing an expensive resampling, but that's it's fault for not letting the sound card do the resampling. This was an older slower system, but who wants to burn extra CPU cycles like that?

redhat audio people on irc

[decora]

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.

Re:redhat audio people on irc

[Ginger Unicorn]

at the time he was probably right.

Re:redhat audio people on irc

[TheRaven64]

In the late '90s, I had MP3s playing all of the time and wanted to be able to have instant messaging and email applications go 'ping' when I had a new message. Being able to do that easily was why I switched to FreeBSD. The good documentation and a libc that doesn't make me want to kill the author whenever I write code made me stay.

Re:redhat audio people on irc

[cheekyboy]

No, that redhat guy still an idiot.
The amiga in 1990 could play two sounds at once from 2 apps.

ha ha

[Weezul]

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:ha ha

[Anonymous Coward]

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:ha ha

[Chris Mattern]

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.

I follow open source software a fair bit and had never heard of LLVM before your post. Maybe it will take over GCC, but you've got quite a ways to go still.

Re:ha ha

[wootest]

Is your argument really "well, *I* haven't heard of it, so it can't be that good"?

clang, the LLVM-based compiler for C/C++/Obj-C that Apple and others built (and, yes, actually keep open source and updated, no hidden bogeyman saving-the-good-bits forks) builds all of Mac OS X, all of FreeBSD kernel and world, several other OS kernels and probably most C and C++ code in the world. The Linux kernel and all drivers in the tree are almost working (see http://lwn.net/Articles/441018/ ) but needs some deep and/or rare GCC functionality to compile correctly.

clang is better structured than GCC, compiles the same code faster and optimizes it heavier, assuming it's in the 99% of the code that it will support. It's also built around a library approach that lets you use its innards and ASTs for related projects (like translators and deep code analysis) along with a more stable long-term API for syntax highlighting and symbol/type lookup.

I am not up to date with GCC, but when clang was started a few years back, it was started because the compiler team at Apple wanted all these things -- none of which involve making Apple masters of the universe or forcing everyone to port to Objective-C -- but couldn't do them with the GCC codebase. From what I've heard, GCC has now started to move in this direction. I still want GCC around and I hope it keeps improving, but I'm happy I didn't wait.

Re:ha ha

[TheRaven64]

Clang, using the GNUstep Objective-C runtime also has feature parity with OS X 10.7 for Objective-C code, including things like automatic reference counting. The FSF's branch of GCC is about five years behind - they've got all of the features supported with OS X 10.4, and some supported with 10.5.

It's much easier for us to keep Objective-C support on non-Darwin systems working with clang. I wrote the initial IR generation support for Objective-C in clang and made sure that there was a clean separation between the runtime-specific and runtime-agnostic parts. The Apple guys have been really good at maintaining this separation. To bring support for all of the new features over to non-Apple systems, I had to write about 50 lines of code in clang and a few hundred in the runtime. In contrast, GCC doesn't even have a clean separation between parsing and code generation for Objective-C, let alone between code generation for a specific runtime and for generic code.

I've pretty much given up on bothering to support GCC for Objective-C code now. It supports a few architectures that LLVM doesn't, but in terms of language support it feels incredibly constraining to go from modern Objective-C to the subset that GCC supports (especially FSF GCC - Apple GCC is a bit better, but only supports Darwin).

Re:ha ha

[wootest]

It's not exactly weird that FSF GCC is behind on Apple's improvements to their own language to run on their own OS, especially since Apple decided to not track GCC development shortly after starting clang.

My point (and yours too, it seems) was more that clang is a cleaner and more well-maintained architecture than at least the version of GCC that Apple left. The layering had grown crooked in GCC. Some things, like GCC's breadth of optimization, extensions, target architectures and bug compatibility support, can only be solved by adoption and maturing over time.

Re:ha ha

[TheRaven64]

It's not exactly weird that FSF GCC is behind on Apple's improvements to their own language to run on their own OS, especially since Apple decided to not track GCC development shortly after starting clang.

My point is that this isn't a new development. With GCC, the FSF branch has been about five years behind the Apple branch in terms of feature support for Objective-C. With clang, we're actually ahead. There are features where GNUstep is currently the only publicly supported target. Unless you have the developer seed of OS X 10.7 or iOS 5, you don't get weak references with automatic reference counting (ARC), for example. You do on Linux / *BSD with publicly available code. The same happened with blocks - we had a publicly available implementation about 6 months before OS X 10.6 was released.

This makes a huge difference for people wanting to port Mac code elsewhere. When declared properties were introduced, Cocoa developers started using them immediately. FSF GCC didn't support them until 4.6, five years later. Clang supported them from the first release, but people wanting to use GCC were stuck. They had to rewrite a load of their code if they wanted to run their apps on Windows or *NIX.

The same thing happened with blocks. Supported in 10.6 (2009), used extensively throughout Cocoa, and on the might-implement list for GCC 4.7. If you want to port your code off Darwin and you use blocks, you can't use GCC.

With XCode 4.2, ARC is now the default development mode. We support it on other platforms immediately with clang. I doubt GCC will support it for a long time. They don't even support non-fragile instance variables...

The layering had grown crooked in GCC.

The lack of sane layering in GCC was a design choice. If you look at the mailing list archives, then you'll see GCC people intentionally rejecting the idea of making front ends completely independent because people might use them in non-Free IDEs - apparently they thought the GPL wasn't strong enough protection. As a result, people couldn't use them in Free Software IDEs either. In contrast, it took me about a day to get syntax highlighting and error reporting working in an editor using the clang libraries.

GCC's refusal to make the front ends modular has been quite painful for anyone writing an IDE that compiles with GCC. They need to implement their own parser for syntax highlighting. Often this is quite ad-hoc or is just a simple tokeniser and breaks horribly with macros. If the language is C++, then trying to do syntax highlighting correctly in the presence of templates is incredibly painful. GCC, in the name of protecting Free Software, has made developing Free Software significantly harder.

The optimisation support is also easier to share. For example, Apple wrote the ARC optimisations as LLVM passes. I've written a Smalltalk compiler that generates Objective-C ABI-compatible binaries with an LLVM back end. Now that it uses ARC, I can run those same optimisations, giving me an overall speedup. The GCC back end is simply not modular enough for that.

Re:Um... Pardon Me, But...

[BagOBones]

And Juniper is using JunOS on it's new Switches and Firewalls now, not just it's routers.

The worst thing about OSS ...

[Anonymous Coward]

... or perhaps the only annoying issue with OSS in general, is that the OSS community contains far too many fools who think that their opinion about some other project they don't like somehow matters.

Re:The worst thing about OSS ...

[Doctor_Jest]

Really? I thought it was all the goddamned vampires....

Re:The worst thing about OSS ...

[causality]

... or perhaps the only annoying issue with OSS in general, is that the OSS community contains far too many fools who think that their opinion about some other project they don't like somehow matters.

That's different from any other thing ... exactly how?

The world is full of people like that. Each one of them is perfectly right in his or her own eyes. Anyone who sits there hanging on their every word is not only part of the problem, but the biggest part.

Re:The worst thing about OSS ...

[iggymanz]

that is nonsense, the proprietary software makers are the much bigger offenders. Ask the chair-winger at Microsoft about projects he doesn't like.

Re:Um... Pardon Me, But...

[macshit]

Was BSD relevant at some point?

It was super influential in the early '80s.

What's with the Newspeak?

[Anonymous Coward]

"...people really shouldn't misunderstand that."

George Orwell is turning in his grave at such a horrible abuse of English. Why didn't he just say that BSD is double plus ungood?

Well ....

[DaMattster]

For security, stability, and reliability, I will take OpenBSD over Linux any day of the week. I can look at my logs and most would-be intruders give up after doing an OS fingerprint on my gateway machine. They see that it is OpenBSD and quit while they are "NOT ahead."

Uninstalling Avahi is one of the first things I do

[Bloodwine77]

I see a lot of hate for PulseAudio in these comments, but no mention of Avahi. If a distro has it installed and running by default then that is one of the first things I uninstall or disable. Sad to say due to some odd dependencies it is sometimes easier to disable Avahi instead of uninstalling it (unless I feel like a sadist and and go go and re-install all those other packages that somehow ended up in dependency hell with Avahi).

As for BSD, I haven't tried using it on the desktop, but I've had no complaints when I've run FreeBSD on headless servers. Well, I take that back, my single complaint is BSD, or at least FreeBSD, is behind-the-times with regards to versions of some software and packages. Of course, that problem mainly exists because of people like Lennart who want to write off BSD and focus only on Linux.

Lennart

[DaMattster]

Why does he have to spread crap like this around? Really, there should be cooperation between the Linux and BSD camps. They interoperate very well because, for the most part, they share some common userland tools and are also semi-POSIX compliant. One of Sun Tzu's principles in the Art of War is to divide and conquer. When FUD gets spewed from the OS camps, it simply shows how divided Open Source really is and makes it easier for proprietary OSes to gain inroads.

Re:Lennart

[Alcoholic Synonymous]

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:Lennart

[Anonymous Coward]

Looks like a lack of vision. He probably thinks there is not enough people around and the few that exist should be working on his pet projects / Linux.

Re:Lennart

[Crispy Critters]

"there should be cooperation between the Linux and BSD camps"

Of course there should be, but you won't see it from Pottering. He doesn't care if anything works on Linux except under Gnome. He certainly isn't going to care if things work on BSD.

Oddly, as someone trying to use a modern Linus distro without Gnome, Potterings antics have made me wonder if I should switch to a BSD.

Re:Lennart

[Anonymous Coward]

You are absolutely correct. There is movement in the BSD community to support desktop systems. Consider there are several BSD projects devoted to this task: PC-BSD, DesktopBSD and MidnightBSD.

The developer count is very low, but that was true of Linux at one point. FreeBSD has been working hard to improve the ports to be BSD friendly and I use it at work with much success in an all Linux environment. I'm that guy, but things work better for me.

The worst part isn't the snide comments, it's the lack of tacking upstream patches we we (BSD people) do make them. Then they point to the lack of patches as proof that we don't care and are irrelevant. Perhaps if they took them? Any software I write, I'd be glad to take Linux or HURD patches for.

I think it's a fundamental issue that BSD developers like to solve a problem and move on not reinvent the wheel 200 times.

Re:Lennart

[staticsafe]

Nicely said. Infighting is OSS' worst enemy.

Re:OS X is on its way out

[dgatwood]

Sorry. I should have been clear: I'm not including embedded systems in that calculation; I'm only talking about desktops and servers based on PC hardware and similar. By that standard, Mac OS X has more than double the Linux installed base by most estimates (the most optimistic estimates I've seen for linux are 25 million, where the most pessimistic Mac OS X estimates are around 53-54 million, growing by roughly the size of the entire Linux installed base every 1.5 years or so).

If you include embedded Linux, Linux is probably more widespread, but then we have to get into the argument over whether Android is Linux and whether iOS is BSD, and that just gets messy....

Re:Um... Pardon Me, But...

[Billly Gates]

BSD Unix invented TCP/IP practically with release 4.2 as it was integrated. Before then It arpanet was only PPP. The localhost as in 127.0.0.1 and many utilities in Linux are based from BSD Unix standard. Bill Joy wrote this who also became the founder of Sun Microsystems. Guess which OS Sun chose? SunOS was BSD Unix.

I used it 6 years ago last as it was frankly fun compared to boring Linux and it had a great handbook if you bought it at Borders or CompUSA. The config files in /etc were #remove this line to do something cool. It encouraged it unlike any other OS I have ever seen. The scripting was simpler and you had cool stuff like /usr/etc/cvsup #uncomment this line for real CVS updates automatically. The handbook explained these quite well. The man pages for FreeBSD were more unixlike and interactive where I can do man of a .config file. /Usr/share/local/doc had real manuals and tons and tons more documentation than Linux where you had to google to go find it.

Linux uses RC (AT&T style) config files which were more cryptic and less command line friendly to do simply hacks to automate stuff. It is not the same with /etc on a Gnu/Linux system.

FreeBSD I found easier to learn and use. Ok that was a rant rather than if it was ever relevant on why it was supperior. ... but yes BSD was relevent and if it were not for the AT&T lawsuit that canned it for 2 years you would be using it today rather than Linux. This was why BSD users flipped over the SCO lawsuit as it brought memories of death as FreeBSD as Linus wrote Linux instead of waiting for them.

It is a shame

Today, it is a niche and a dying one. I left because FreeBSD 5.x was really really horrible and I needed to learn Java for school. My USB keyboard wouldn't work for 2 years?? Java 5 had many new features and Java 3 with many patches from some guys website (literally), I had to bootstrap FreeBSD 4.12 (already obsolete because 5.x sucked ass) to get it to run. I went back to windows rather than try to use Linux again :-(

BSDi, was the defacto OS for small ISPs 10 years ago too and it was the commercial version of Free/net BSD. It went out of business or was bought by Walnut creek. Sun's were expensive and Linux was merely a toy compared to a real BSDI Unix.

BSD 10 years ago could run circles around Linux in network throughoutput and other benchmarks. Linux is just catching up today. It was 5 years ago that Samba even caught up under Linux as to what the BSD operating systems could do back in the early 90s.

The FreeBSD ports had a lot of applications bundled and if it were not more popular today I am sure it would be easier to use with preconfigured software to setup things like Lamp or Lapp (with BSD instead of linux).

Excuse me

[lymond01]

Pardon me while I shut down my OpenBSD pf firewall guarding my Plone installation running on FreeBSD -- the latter of which you'll need to not be sighed at on the Plone support forums.

Re:Excuse me

[zzatz]

You run your firewall on a desktop? You run Plone on a desktop? You do realize that Poettering was saying that BSD is not relevant to the desktop, don't you? He wasn't talking about servers, yet the examples you cite are servers.

Certainly, BSD continues to play a role in the server market. On desktops, it's a different story. BSD as a desktop OS has faded away. Some may claim OS X is BSD, but that's nonsense in the context of this particular discussion. What makes OS X a desktop OS is the non-BSD, non-open parts. Such as Core Audio, which addresses the same issues as Pulse Audio, and for the same reason: those issues are ignored in BSD.

give him support

[Errtu76]

There are many bugs in PA that need to be solved. I see a lot of people complaining about that but very few actually helping out to fix them. Linus couldn't create Linux on his own. It only got the the place it is now by many supporters. Maybe people should put some effort in helping Poettering instead of bitching.

Re:Um... Pardon Me, But...

[Billly Gates]

I wrote PPP, but my mind meant just IP. It is late ...

BSD is dying last 20 years but still alive

[alukin]

Windows is most popular OS. It's obvious. Who uses it? Hmm, forget this question. Well, Linux is gaining popularity more and more. Even blonds know today something about Linux. Therefore it is being filled with different crap like PulseAudio. BSD is for old-school professionals only. So, dear Lennart Poettering, why you dare speak about BSDs?!! Looking at that shit, you wrote, called libdaemon, pulseaudio and others, I do not think you're old-school professional.

Pulseaudio, b.t.w is the first thing I remove after installation. I's the most annoying piece of crap in any linux dist.

Regarding BSDs. It will never be "popular". It has academic model of development and strong user community. This is like classical music and pop music. Classical music is dying last 100 years.

Re:Linux itself isn't relevant anymore

[luther349]

all i can say for you is arch linux hehe straght hardcore build your own os distro there but also very well documented on how to do it. i agree ubuntu has gone off the deep end but so has gnome. no ubabilty tweaks in there releses just oh look at the 3d ontop of a interface everyone hates and that only proves they only care abought being trying to be cool and not the user exp. why i run xfce at least those guys are still in the realm on sanaty.

using openbsd on laptop

[reiisi]

I sometimes do. If a certain iBook weren't having problems with the video generator chip (_that_ famous problem), it would be running openBSD mostly now. (and sometimes Vine Linux and sometimes ancient Mac OS 10.3). But mostly openBSD, even with the funky need to startx after logging in.

Saying *BSD is irrelevant is kind of like saying your dad is irrelevant.

Other kernels are in the right direction

[cyberthanasis12]

"Debian kFreeBSD is a toy OS, people really shouldn't misunderstand that.''
It is extremely important to have more than one free kernel. In other slashdot stories we all have seen the attack to Android, which is basically Linux. How long before MS Apple and other criminals (convicted monopolists) attack Linux to oblivion in USA. I just hope, that Europe might come to their senses, and continue to resist software patents.
I had hope about free Solaris, because I believed that Sun could protect the OS with their patent portfolio. But now Sun is Oracle.
So, Debian kFreeBSD and Debian kHurd, are invaluable projects. It must be made clear to those criminals that if they nuked Linux, everyone would switch to a replacement kernel (FreeBSD) without affecting the userland. And if they nuked FreeBSD too, then we could switch to Hurd, and the criminals would have to start all over again.

By the way, of course Debian kFreeBSD would be a toy OS. Didn't MS say so about Linux at the start? didn't old Unix vendors say exactly the same about Windows? And before that wasn't DOS only for playing around with toy computers?

PulseAudio, Avahi and systemd?

[BestNicksRTaken]

Wow one guy is responsible for the three worst things to happen to Linux in the last few years and he's still doing interviews?

I bet he's working on Gnome3 too isn't he?!

Re:PulseAudio, Avahi and systemd?

[perryizgr8]

maybe unity too?

Use the Adapter pattern, Loehnnert

[amn108]

I find it surprising that the guy behind the projects mentioned, hasn't heard or appreciated the concept called an "adapter".

An adapter is either an interface or an implementation of said interface (the term is a bit vague in that sense) designed to connect software components that can't "connect" to each other by themselves, essentially an abstraction layer. It is what you'd use if you need to extend your software, but worry about platform portability. Think of it as a LEGO brick that is needed to connect two other LEGO bricks.

http://en.wikipedia.org/wiki/Adapter_pattern

*BSD Trolls are Dead

[xombo]

It is now official - Netcraft has confirmed: "*BSD is dying" trolls are dying.

Yet another crippling bombshell hit the beleaguered Slashdot community when recently IDC confirmed that "*BSD is dying" trolls account for less than a fraction of 1 percent of all posters. Coming on the heels of the latest Netcraft survey which plainly states that "*BSD is dying" trolls have lost more market share, this news serves to reinforce what we've known all along.

You don't need to be a Kreskin to predict their future. The hand writing is on the wall: "*BSD is dying" trolls face a bleak future. In fact there won't be any future at all for them because "*BSD is dying" trolls are dying. Things are looking very bad.

All major surveys show that "*BSD is dying" trolls have steadily declined in market share. They are very sick and their long term survival prospects are very dim. If they are to survive at all it will be among the "hot grits" dabblers. "*BSD is dying" trolling continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, it is dead.

Fact: "*BSD is dying" trolling is dead

Re:bah

[PeterBrett]

systemd is fine. Out of interest, what exactly is your problem with it, other than it's not SysV init?

No wonder he is fighting back

[koinu]

You all should know that Lennart Poettering's creations are widely criticized on FreeBSD, for example.

http://forums.freebsd.org/showthread.php?t=22444 - "Some things may break in mysterious ways." (because he refuses to accept /usr directory in systemd or wtf it may mean)

Here a thread about PulseAudio: http://forums.freebsd.org/showthread.php?t=2613

I guess, he is a bit disappointed and fights back now.

Further pulseaudio reasons

[Sits]

Many of the things that pulseaudio provides:

• When I log into GNOME I don't have to have the same volume as the last user who logged into GNOME- it's restored on a per user basis
• Simplified volume interface. Pulseuadio multiplexes things like the Master volume and the PCM volume into a single control thus allowing better granularity than the Master volume alone
• When I plug a USB webcam in, pulseaudio now remembers that I prefer it as my default microphone and applications switch to using it rather than the built in one without forcing programs to be reconfigured
• The per app volumes are also useful - sometimes a Flash app in the browser doesn't have a volume control but I can use pulseaudio to make it quieter
• esd has been allowed to retire
• Using pulseaudio allows the kernel to sleep longer when audio is playing by sending a bigger buffer when possible. When not possible (because a quicker response is needed) it sends a smaller buffer. This enables power savings to be made.
• Easier to apply volume boost (artificially making quiet audio "louder")
• Easier to switch between audio setups (e.g. from stereo to 5.1)

There were introductory issues too:

• When it was introduced most programs didn't use pulseaudio directly. Some programs still wanted to use OSS. Pulseuadio can emulate a subset ALSA but some programs were using more than that subset
• Not all distributions enabled ALSA emulation when they first enabled pulseaudio. This created fights between ALSA using programs and pulseaudio using ones
• Bugs in audio drivers were uncovered. Like a tree falling in a forest with no one around to hear it, you can create a philosophical debate as to whether a bug is a bug if no one hits it. Regardless, the result was pain for some users.
• Bugs in the userland audio stack. Bugs in gstreamer and pulseaudio have caused issues like the volume going to 0 every time a track was changed or huge CPU usage that caused pulseaudio to be killed off.
• Choice of audio mixing methods which make use of floating point

These issues seem to have been mostly solved with time but caused a lot of heartache along the way. The problem is whether it was a chicken and the egg issue where these issues wouldn't have been uncovered until people started testing these things but you can never get enough testers so...

Then there are issues that are still with us. If you have a creative sound card your life is going to be difficult. Pulseaudio doesn't make use of hardware mixing so if you have such a card, you may have noticeably higher CPU usage than ALSA alone (even though the audio mixing is no better). Two steps forward, one step back?

ALSA was never going to be able to introduce all the features mentioned in the first part of this mega post, mainly because it is too low level. Even OSS on the BSDs doesn't present an easy GUI for all those features (it does do mixing and per program volumes) yet Windows and OS X have many of these features. The big picture is that I can do things that I couldn't before and sometimes a lot simpler (remember esd and artsd?) but there was a cost. You may not find the cost was worth it but my feeling is that it will be around on "big" Linux (e.g. machines similar in power to desktops) for the next 10 years.

Re:Uninstalling Avahi is one of the first things I

[koinu]

I actually changed to FreeBSD on my desktop 10 years ago because Linux distributions have been slower than FreeBSD in providing up-to-date ports.

I occasionally changed to a Linux-based desktop for some months, but always gave up, because I missed FreeBSD ports collection very much. I even tried with Gentoo, but it locked itself up into some weird dependencies, I could not find out how to do the next upgrade and changed to FreeBSD again.

I think FreeBSD is much more easier to use than Linux distributions. I don't like to spend time about thinking what's broken next on my kernel. At the moment Wireless LAN is broken on Linux for me (some kind of regression). For FreeBSD kernel, I just load the drivers (modules) instead of compiling stuff into kernel. FreeBSD is comfortable in every way... that's why I use it.

Re:Linux itself isn't relevant anymore

[perryizgr8]

i think the only way for linux to be relevant on the desktop is if someone places their android phone on their desk.

Can't stand Linux...

[drussell]

AGREED! You can call me a BSD fanboy if you like, but I run FreeBSD on about 20 servers and 10 other personal boxen for various purposes (and yes, most of my "desktops" are FreeBSD) and another 50 or so installed at customer sites... The ** ONLY ** reason I ever use any variant of Linux for ANY reason is for tuner card support for Myth-TV-type systems. And I HATE it. FreeBSD just always works. Set it up, sit back and read the logs. Thats what UNIX is supposed to be. FreeBSD has never crashed and eaten files on me... Many of my Myth boxes seem to eat files every few months for no apparent reason... no matter what filesystem I use, even on a clean shutdown probably 20% of the time when I fire up one of those Linux boxes it won't even fsck and boot; it's easiest to just pull the HDD and fsck it on another box... That's just the tip of the iceberg... It just seems to me to be a horribly fragmented OS... everyone and every distro does something differently and mostly just in the name of being quick-to-market... They all seem to have that same Microsoft-style disease; get it out the door quickly instead of doing it RIGHT. Every time I have to actually use Linux for something It makes me realize just how inferior it is to FreeBSD... Sometimes seems almost as bad as Windows! I'll take my BSD flavors ANYDAY over any flavor of Linux. Yes, perhaps I'm excessively biased (I've been using FreeBSD extensively since 1.x) but I've tried many Linux variants MANY times over the past, what's it's been now; 15 years? I've TRIED to like it! Yet, I've NEVER liked it one bit... ARGH! GRRRR!

Re:Lennart bashing again?

[etrusco]

Agreed. Of course I hated PulseAudio (in Ubuntu) at first, but I've read enough to know it wasn't Lennart's fault and anyway now it just works.
These "Linus' Moments" of him doesn't help much, but I always found reason in them.
I think this might be the article with the worst ratio of uninformed and nonsense comment (per total comments) I've ever saw. "I replaced PA with ALSA", "cgroups -> jails", "BSD is relevant, it's used by Apple", etc, and all of them voted +5, Informative! WTF?!

Re:OS X is on its way out

[drinkypoo]

If you include embedded Linux, Linux is probably more widespread, but then we have to get into the argument over whether Android is Linux and whether iOS is BSD, and that just gets messy....

It's safe to say that iOS is still OSX, and it seems reasonable to say Android is as much Linux as iOS is OSX. Do we really need to know anything else to have a conversation about this stuff?

Re:linuxFR.org?

[Alex Belits]

FFmpeg and VLC look pretty relevant...

Re:Misleading summary

[poltsy]

As for systemd, I still am not sure what to make of it - it seems very advanced, there are definite benefits, but somehow it seems to be doing too much for a single application...

So it's exactly like pulseaudio then! I think I'm seeing a pattern here.

Re:Misleading summary

[koinu]

He merely states BSD isn't relevant to desktop systems.

Yes and saying this, he is already wrong. It is as much relevant as Linux is. Maybe he also thinks about Microsoft's position about Linux desktop systems. I hate his arrogance, really. Not every operating system has to be like Linux and developers should respect this before breaking portability generally (see X11 disaster... X11 used to be a standard earlier). There is also a possibility to help in the development.

I am using FreeBSD and I like Linux systems, but having such kind of developers on the Linux side is simply shit and makes the whole Linux community look bad from my point of view.

Re:Linux itself isn't relevant anymore

[Larryish]

True about the Ubuntu part.

We still run 8.04 on client boxes. Everything "just works" after the initial install, and it doesn't complain about the onboard Intel gfx on 10-year-old hardware.

I wouldn't dream of running Ubuntu on a server, though.

As for Pulseaudio, I can play music on one machine, games on another, my wife can play music on her machines, and our daughter can play a game on her machines and all 6 client boxes stream it over the network to the headless file/print/PulseAudio server which outputs to our cheap 5.1 surround system.

All of it plays flawlessly, through the same source, with no noticeable ticks.

PulseAudio works very, very well IMO.

I WOULD, however, like to see PulseAudio stream input from the line-in port.

Anybody got an angle on that?

einstein

[decora]

"You ask me if I keep a notebook to record my great ideas. I’ve only ever had one"

http://worldsstrongestlibrarian.com/3207/einstein-was-hilarious-and-humble-three-great-quotes/

Hello guys.Is BSD really way behind Linux ???

[captain_perry]

I remember a quote from Linus Torvalds which said "If 386BSD had been available when I started on Linux, Linux would probably never had happened." Yeah I know that's many years ago. Back to question. Is BSD seriously way behind Linux ?? Btw what you guys think about PC-BSD PC-BSD: FreeBSD Made Easy for Your Desktop

Re:Hello guys.Is BSD really way behind Linux ???

[WorBlux]

It's not way behind, it just has different goals. It's TCP/IP stack is phenomenal, and for most intents and purposes it's the only stack out there. Other OS's are ports and adaptations of it. It does what it does very well... Provide a robust and secure system, within a mature development environment to support database and server applications. It's doesn't try to be full featured or cutting edge like Linux, but rather pull out and distill solid, proven ideas. So on the consumer/desktop side it is pretty much dead except for people who like to play around or use a BSD environment elsewhere and they want something familiar and compatible. You'd never see Unity arise in the BSD community because it's simply too unorthodox. If Mac is the stylish metrosexual young man, and Windows the overweight and somewhat dweebish guy in a suit, then Linux is a gifted adolescent desperately looking for friends, and BSD is an older skilled tradesman who keep all his old tools in immaculate condition.

no idea what he's talking about

[Nightshade]

i use OpenBSD on *all* my laptops. these are not servers. they are desktops with gnome/chrome browser/etc. find it works really great. i don't know if he's just making stuff up sight unseen or he's actually tried using one of the BSDs.

Rubbish

[TheVelvetFlamebait]

If BSD were irrelevant, Netcraft would have confirmed it.

Re:Lennart bashing again?

[grimharvest]

"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. " You think snide remarks like this should earn him kudos? Of course, BSD users are going to take exception to this.

The horrible Truth

[jmorris42]

> Now I understand that he is to be stopped at all costs.

The horrible truth is there are no Linux developers who are trying to create a UNIX for the 21st Century. They are all of three types. There are the ones who develop for Linux in a VM on their Macbook who want to make Linux into a knockoff of OS X. Then there are the ones who develop Linux apps on their Dell or Thinkpad who lust after Microsoft's taillights, cloning every one of their new features and APIs. Then there are the ones who develop Linux on their Windows PC who are working on enterprise/server features who care not for the Linux desktop. Yes I have generalized a bit, but it serves frighteningly well as a first approximation of the current situation.

That leaves BSD, but there is no innovation happening there either, the small about of developer resources there are consumed trying to keep up with the churn in device drivers and keeping linux binaries running so they can have must have things like a web browser, flash player, etc. The old mainframe/timeshare UNIX model built around terminals does need updating for the 21st century world of multiple CPUs per user, dynamic hardware and pervasive networking. But nobody is even thinking about those problems except Plan9 and it only exists in emulators because of the driver problem. There is almost no thought going into preserving the UNIX culture because we took in to many immigrants from Windows/Mac and didn't make them natives before giving them commit access our key cultural artifacts. There is probably a lesson here for the larger political immigration arguments in the 1st world but that gets kinda offtopic.

Re:The horrible Truth

[mfwitten]

"Linux"

I do not think that means what you think that means.

Re:The horrible Truth

[swb]

There is almost no thought going into preserving the UNIX culture because we took in to many immigrants from Windows/Mac and didn't make them natives before giving them commit access our key cultural artifacts. There is probably a lesson here for the larger political immigration arguments in the 1st world but that gets kinda offtopic.

What a great metaphor, and quite apt, I might add.

As to the larger question, there was a time when there were people who really had no "PC" experience outside of launching a terminal emulator to connect to a timeshare system of some kind and thus were largely pure of mind when it came to UNIX.

Now so many of these people cut their teeth on Macs and Windows, often for years, that they don't know any different -- it's become like a burned in image on a monitor; all you can hope is that you can turn up the brightness enough that you don't notice it.

I think you could make an argument that for all its flaws, both Macs and Windows "work well enough" that making desktop linux work like them isn't the worst thing.

Yes but he didn't say it quite so bluntly.

[tomxor]

If focusing on the topic heading i would agree..

When introduced in such a black and white manner it's difficult to bother reading the original article, but when read in context he isn't being quite as dismissive or blunt as saying it's completely irrelevant.

A better way of rephrasing his opinion is that he doesn't think it's relevant in the interest of popularising free software. As a disclaimer he also acknowledges how this isn't the sole purpose of free software, and how BSD has relevance to other people. Here is an extract pertaining to the discussion of BSD's relevance:

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.

thanks for the context

[decora]

it is basically the same thing.

freebsd as 'irrelevant' and 'holding us back' is kind of a bizarro argument.

Re:Um... Pardon Me, But...

[pseudonomous]

Aren't both iptables/ipchains Linux only? Doesn't NetBSD use pf like OpenBSD?

Yes

[rawler]

Hurd is taking over it's space.

BSD death = happy Billco

[billcopc]

I sense a puny disturbance in the Force, as if dozens of DNS operators suddenly cried out in terror, and were suddenly silenced.

The decades-old argument in favour of BSD is that it's more secure than Linux. Yeah, great. It also doesn't support any hardware nor software from this century. I've always felt like BSD was an unloved, unjustified waste of resources. I've never bothered supporting it, and while Linux has pissed me off lately with feature bloat and poor QC, it still causes me far fewer headaches than the handful of BSD boxes I occasionally have to support.

I like Theo, he's a good shit, but I don't care for his project. I'd rather see his great skills put to use on improving Linux.

Re:BSD death = happy Billco

[toadlife]

It also doesn't support any hardware nor software from this century.

FreeBSD's hardware support is about on par, or a little bit better than Debian Stable.

The decades-old argument in favour of BSD is that it's more secure than Linux.

There are more/better arguments than that. Security has never been why I've preferred FreeBSD to Linux.

it still causes me far fewer headaches than the handful of BSD boxes I occasionally have to support.

I feel the same way about Linux. Linuxisms always come out to bite me in the ass.

I like Theo, he's a good shit, but I don't care for his project. I'd rather see his great skills put to use on improving Linux.

Now your post makes much more sense. Your entire opinion of "BSD" is based solely on OpenBSD.

Re:Linux itself isn't relevant anymore

[DaVince21]

I know this is a troll post, but when you say "people with narrower than normal needs who don't mind reinstalling everything every couple of years" sounds much more like you're talking about Windows...

prob a typo ..

[Randy_Leatherbelly]

surely he meant Linux audio isn't relevant anymore ?

Headlines You want to read ::

[Randy_Leatherbelly]

Lennart Poettering isn't relevant anymore .. nice chap though he seems to be, in interviews i've heard, lock him in a room. please.

Re:Misleading summary

[bhepple]

Read Mr Poettering's own account of systemd at http://0pointer.de/blog/projects/systemd.html Features are listed in legions but only one tangible, significant benefit: it's supposed to be faster. Only one real benefit and then only to laptop owners. What would a server admin care if it takes 2 minutes to boot or 15 seconds or 10 minutes? Who cares? Now, if you google the first major distro to go systemd ie fedora-15, you'll see that it's not faster at all in practice. So all that change, all the obfuscation of hiding in compiled code what used to be clear (in bash-scripts), all the complexity, confusion, breakages, fear, uncertainty and doubt amounts to - no advantage at all. I'm not sure if it's enough to have me bail out of the fedora world - but surely this won't find its way into RHEL?!?!? Please tell me not!!!

Re:Um... Pardon Me, But...

[scubamage]

Not sure TBH. I just figured it was cross *NIX. I know they use netBSD + some software firewall, and the syntax looked exactly like iptables/ipchains so I figured that's what it was. The boxes just "worked" so we never really had to touch them much. So I'm not exactly sure what firewall package they used. PF could very well be it.

people really shouldn't misunderstand that

[Zubby]

I'd expand it to say Linux is a toy OS, people really shouldn't misunderstand that.

GEOM

[liquidhokie]

I could not agree more. I have used many of the GEOM features, they all work perfectly. The partitioning scheme, in particular GPART and GLABEL, make working with USB and other hot-swappable devices much easier and less error prone.

The FreeBSD motto is "the power to serve", linux laptop users should keep that in mind.

Like Apache?

[liquidhokie]

Many FOSS projects have their primary development done on xBSD, so that fear may be overstated:

http://uptime.netcraft.com/up/graph?site=www.apache.org

Re:Um... Pardon Me, But...

[iggymanz]

BSD in in some of your or your employer's printers or routers or wifi or fax machine/copier or other appliances...as others pont out, mac osx and ios are BSD. many of the IPC, socket, and networking structures in your Linux (and in the commercial Unix even though they are sys V) are from BSD. The influence and use of BSD is massive. Even Microsoft still uses BSD code.