Slashdot Mirror

It's a massive, complicated, and very poorly behaved substitute for a simple, robust, and well behaved program. And it's not just a regular program, it is (if used as intended) a critical system component that will take your entire system down when it goes wrong.

Not at all. Don't substitute you not understanding a system with complicated and poorly behaved. There are careful design decisions and planning of systemd. You may not agree with them, but that doesn't make it wrong. Systemd is increasingly more popular for a number of very good reasons. It has become a freedesktop.org standard. You could start by reading this,
http://0pointer.de/blog/projec...

But since you probably won't, let me just say this. Serially executing a bunch of arbitrary shell scripts has got to be the worst possible way to design an init system. The fact that it works doesn't make it good. First of all, each script is code. Second, no script is aware of any other scripts presence, although intrinsically linked to and dependent on those other scripts. Third, a typical shell script is >100 lines of block logic to implement the equivalent of "service start". A configuration file for systemd for a single service can often be less than 10 lines and very easy to read.

I know I know, none of that matters, it is too "massive" and "complicated".

Have you read the rationale behind Systemd? It aims to solve a number of fundamental problems of SysV init, including explicit daemon interdependancy as well as process monitoring, and takes inspiration from other daemon-control attempts such as upstart and DJB's daemontools. It's actually targetting a larger set of problems than just "start these services on boot".

Furthermore, it aims to solve these problems on the whole range of linux systems, from phones through servers. You'll note Android doesn't use SysV init (of course, to be fair they'll probably not use Systemd either because GPL).

SysV init has been around for a long long time. It is a indeed a flexible system where sysadmins can apply their existing scriping and debugging skills, but it has a number of flaws.

Systemd is new and introduces a whole new set of concepts (did you ever care to understand what cgroups could do for you before?). It also drops the imperative configuration style of shell script (do this then this and maybe that) for a declarative configuration style (I am this and I provide that service and I depend on this). It is the very definition of uncomfortable change. But there's are reasons people back that change.

There's this new thing called "init.d" which makes things really simple - you can start a system up and step through things, and though the boot takes 5 seconds instead of 1 second, that isn't really a problem.

Once I read the original post about systemd, and all the other let's-invent-a-problem-to-fix nonsense surrounding init.d, I literally hung up my hat and stopped being a syseng. I was a unix guy starting in 93, so it was probably time anyway, but it was the straw that broke my back, as it were.As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. I especially "loved" this line: As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. No. A good init system does it reliably, with no drama and no politics. A good init system allows one to easily determine the state of a system, and doesn't assume things like GUIs and such. A good unix init system does all this with commands which can be piped and parsed easily with grep and awk - two things the original post about systemd actually complains about. The idea that a unix person would complain about grep and awk was so mind-boggling to me that...well, I just hung up the hat. You did all this nonsense, just to save a few seconds? Because what, the only thing linux is used for, is laptops? Meh.

In my opinion...
Wayland + Systemd + Gnome 3 + kernelspace Dbus = transforming Linux into Windows. Or something more like Windows. They represent a complete rejection of the foundational Unix philosophy.

Regarding Wayland: You clearly have no idea how X works today. Todays X is not like Unix should be at all.
Regarding Dbus: How is a dbus protocol different from semaphores and shm in the kernel?
Regarding systemd, I agree and see it critically, because it is tries to solve everything at the same time. Perhaps the direction of OpenRC is more appropriate. But to criticise systemd you have to understand the issues: A number of links are on http://freedesktop.org/wiki/So... including http://0pointer.de/blog/projec...
Regarding Gnome3: Gnome3 is conceptionally little different than Gnome2, KDE or XFCE: Windows and pointers. I actually really like it. If you don't exchange it for something else. Very Unixy.

We have to keep in mind that the system we have today are not mainframes that are booted once and have their daemons running for months.
We have plug-and-play of devices and screens, hibernation, multiple input devices, while at the same time the screen output must not flicker or have delays beyond 50ms. It's a different arena today.

If you want to know why hardcore fedora users have been asking for the switch to systemd for many years, here it is:

http://0pointer.de/blog/projects/systemd.html

A lot of people who were otherwise in the "stick with SysV" crowd fall in love with systemd as soon as they learn the details. It is truly a step forwards over 80s UNIX.

I love Lennart Poettering's response:

It's really appalling how GNOME first NIH'ed Unity, and then the Wayland guys came and NIH'ed Mir, and then the git guys came and NIH'ed bzr, and then the github guys and came and NIH'ed launchpad. But the systemd guys are still the worst, NIH'ing Upstart! Such suckers! Let's stand together against NIH'ing Canonical technology!

https://plus.google.com/115547683951727699051/posts/RCfN9NwZrLN

NIH is only a problem if you "invent" something inferior to what's already there. And really, NIH is an intellectual weak argument that someone uses when they lack the stones to make an argument based on metrics that are actually meaningful. Lennart is actually very clear on the technical reasons why he chose to create systemd even if Mark wants to remain ignorant of them.

Also, we'll know that Mark as actually done his homework when he learns the proper capitalization of systemd. Come on Mark, at least read the fucking cover page and FAQ.

PS: you can also read up on various topics on their site http://freedesktop.org/wiki/Software/systemd/
eg, FAQ http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/
and Myths http://0pointer.de/blog/projects/the-biggest-myths.html

They didn't help me when systemd crashed and took with it the entire system. It's built as a card house, with assumptions that things don't go pear shaped, or if they do, you have time to wade through hundreds of configurations in search of the proverbial needle in a haystack.
I don't LIKE systems where you put all your eggs in one basket, and for good reason.

This is no different from a failed init that causes a kernel panic. The difference is that systemd now is thoroughly tested on *thousand of machines and keeps improving, so using it to control services will minimize all the dangers that comes from hand editing complicated, often undocumented init scripts.

systemd has superior debugging facilities and is well documented. You can actually systematically analyse what a certain run-level (called target) requires, or tell systemd to spawn a shell if it crashes. It is so much better when it comes to tracking down service/daemon troubles than static scripts.

Sure, there is something to learn about systemd before mastering it, and many people seems to loathe reading about new technology, or just doesn't have much time on their hands to learn new stuff. But neither is a systemd problem, and learning new technology and new ways of doing things, comes with the territory as SA.

Check out all the wonderful stuff one can do with systemd, journald, and all the *ctl tools; completely consistent control and behaviour across every Linux system that uses systemd. No need to learn and relearn dozens of small system peculiarities across distributions for controlling services, working with log-files, getting system info, etc. etc.

systemd is the future because it is such a good idea that most major distributions are switching to it. I will recommend all Linux SA's to put their real or imagined reservations against systemd aside, and start boning up on the subject

There is a lot to learn, not because systemd is complicated, but because it can do so many things, like resource limiting, mounting etc.

Here is a link that compares sysvinit, Upstart and systemd
http://0pointer.de/blog/projects/why.html

Come on, "On-demand socket activation for per-connection service instances" for virtual servers, how cool is that!

Then, they changed to systemd - a dual layer abstraction abomination for services and configurations, incompatible with the runlevel and init.d scripts that admins have and rely on.

My experience of systemd is that it's fine, when it works which in fairness is usually. Then again, the same could easily be said of init scripts.

But it is really opaque and not especially well documented so when it does go wrong (which is more common on servers with odd custom setups) it is really, really hard to fix.

That is not fun.

There is a plethora of systemd documentation. What additional information do you need?

Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.

And what do you do when something goes wrong? Or you need access from a different arbitrary system?

I really recommend reading this list of systemd myths:

http://0pointer.de/blog/projects/the-biggest-myths.html

And Lennart's "systemd for Administrators". Here is a link to the first part of twenty instalments:
http://0pointer.de/blog/projects/systemd-for-admins-1.html

Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.

Do you have any links that has been written by others than Poettering himself? Like, for instance, system administrators?

Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.

And what do you do when something goes wrong? Or you need access from a different arbitrary system?

I really recommend reading this list of systemd myths:

http://0pointer.de/blog/projects/the-biggest-myths.html

And Lennart's "systemd for Administrators". Here is a link to the first part of twenty instalments:
http://0pointer.de/blog/projects/systemd-for-admins-1.html

Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.

Do you have any links that has been written by others than Poettering himself? Like, for instance, system administrators?

I think its just cranky old sysadmins that don't like systemd. Its actually quite good and offers several benefits over the old sysvinit.

It's the cranky old sysadmins who keep the servers and internet running. What they say is often important. When someone tries to re-invent Windows Services, AIX smit and Windows Event log, they may grump, but they do so with the experience saying that it wasn't a good idea the last time either.

The problem is that many aren't "cranky old SA's" but just uninformed old gits that refuses to even read up on new technology and flat out denies that there any problems whatsoever with Linux logfiles, and the way Linux handles services (init etc).

Whenever I see systemd or Journal hate here on Slashdot, it is always just snarky remarks that almost always are totally wrong, and clearly demonstrate that they don't know what they are talking about.

Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.

IMHO, systemd and Journal is the best new tools for the Linux SA made in the past decade.

I really recommend reading this list of systemd myths:

http://0pointer.de/blog/projects/the-biggest-myths.html

And Lennart's "systemd for Administrators". Here is a link to the first part of twenty instalments:
http://0pointer.de/blog/projects/systemd-for-admins-1.html

Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.

I think its just cranky old sysadmins that don't like systemd. Its actually quite good and offers several benefits over the old sysvinit.

It's the cranky old sysadmins who keep the servers and internet running. What they say is often important. When someone tries to re-invent Windows Services, AIX smit and Windows Event log, they may grump, but they do so with the experience saying that it wasn't a good idea the last time either.

The problem is that many aren't "cranky old SA's" but just uninformed old gits that refuses to even read up on new technology and flat out denies that there any problems whatsoever with Linux logfiles, and the way Linux handles services (init etc).

Whenever I see systemd or Journal hate here on Slashdot, it is always just snarky remarks that almost always are totally wrong, and clearly demonstrate that they don't know what they are talking about.

Even if you never, ever use the Journal tools or access the Journal log files, systemd and Journal will enhance the Syslog files considerably, by enabling log info early in the boot process, and tagging and aggregate the logfiles.

IMHO, systemd and Journal is the best new tools for the Linux SA made in the past decade.

I really recommend reading this list of systemd myths:

http://0pointer.de/blog/projects/the-biggest-myths.html

And Lennart's "systemd for Administrators". Here is a link to the first part of twenty instalments:
http://0pointer.de/blog/projects/systemd-for-admins-1.html

Very good stuff. A must read for any Linux SA, whether they think they dislike systemd or not.

Your a moron. Here, read this and get aclue.

http://0pointer.de/blog/projects/the-biggest-myths.html

Not impressive at all. Current Fedora with systemd can container with whole OS in 2 seconds, serve the data and shutdown. All of this is triggered by network request. And you have full OS, not some highly specialised runtime.
More details at Socket Activated Internet Services and OS Containers.

http://0pointer.de/blog/projects/the-biggest-myths.html

This is an interesting, albeit long read. I must say, it does wonders for those with an SSD.

http://0pointer.de/blog/projects/systemd.html

Ahh, so what you really want is the BSD rc subsystem or perhaps rcng in Gentoo

Or maybe launchd, which was one of the inspirations from systemd, but has 25022 lines of source code (as per a recent download of a source tarball of the 10.8.2 version) rather than 158743 lines (as per a recent checkout with git clone git://anongit.freedesktop.org/systemd/systemd), with "lines of source code" determined by finding all source files (files matching any of *.[chylsSxm], *.ch, *.fth, *.sh, *.m[td], *.asm, *.java, *.jav, *.cpp, *.cc, *.cxx, *.cp) and xargsing them through wc -l.

No, launchd probably doesn't do as much as systemd; some might consider that a feature.

In most areas I'm a bit of a unix curmudgeon but I'm happy to be rid of SysV init scripts.

And why would I like systemd?

All the reasons given here: http://0pointer.de/blog/projects/systemd.html

oh, a newbie ...

No, I'm not a newbie.

in many cases you could just use alsa without a sound demon

For many users this is not possible anymore. There are plenty of sound devices out there with fancy features, including the ability to mix multiple streams together for you; but many newer computers come with brain-dead sound devices that have no features at all. You get one sampling rate (probably 48000 Hz), and you get one audio stream. If you want to be able to play sound files that were recorded at 44100 Hz, or mix multiple streams, you must have some sort of sound system managing your sound device. Like PulseAudio.

http://0pointer.de/blog/projects/jeffrey-stedfast.html

If we didn't have PulseAudio, we would need some other audio daemon that had similar features. And at this point I would rather see effort put into polishing PulseAudio than effort put into writing yet another sound system and trying to promote it as a superior alternative to PulseAudio.

Now the current situation is: you have almost only pulseaudio, sitting on top of alsa, hiding all the interesting stuff of alsa (an example: alsa provides for a typical soundcard about 10 different audio channels, where you can control the volume. pulseaudio hides this all and provides ONE volumecontrol. you cannot say the front jack has another volume than the rear one).

That's an interesting complaint. But it's a long walk from the original "it's broken and they shove a new one down my throat each year" complaint.

There is no reason why a sound system like PulseAudio couldn't expose the controls the way you want. And I'll bet that the controls you want actually are in PulseAudio somewhere, even if the GUI desktop environment you use doesn't expose them.

Many applications use an intermediate framework, such as gstreamer, to abstract the painful details. which of course adds latency and sources for trouble.

You can say that about any sort of intermediate framework: they are always trying to abstract the painful details, and they are always sources of potential trouble. And for audio, they are always sources of potential latency.

steveha

Would it surprise you to learn that systemd is written and maintained by the same guy who did PulseAudio? Lennart Poettering.

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

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

Linux [...] doesn't conform to POSIX where POSIX is broken.

Oh yes it does.

I have no major objection to change, or to things like PulseAudio

Jack handles all the functionality PulseAudio does but also appeases the high-end audio folks by providing a means to do low latency work and connection of different programs to each other in an ice and easy fashion.

The PulseAudio developers reasoning for it's existence was to provide a solution that can scale the latency to up to seconds(!) for things such as video and the like that are pre-determined to save a few fractions of a percent battery on context switching. In doing so the trade-off is it is absolutely useless for anybody who actually cares about their audio subsystem. Now we have all of the professional and some of the non-professional audio applications using jack. And some end-user only things using pulse that have to be wrapped to jack. This is far from ideal.

The ironic thing is the pulseaudio developers own talk on the two is almost a diatribe against it. Most of his main points against jack are moot (it apparently requires powerful hardware.. tell that to my eeepc that is running a whole heap of high cpu requirement services) And that the system is usually static (I plug in new midi devices all the time, no need to restart jack they simply appear). And finally that audio is the only thing going on in jack systems, I use it system wide even for my youtube playback as most others that use jack do.

Basically, all the perceived downsides of jack are moot except the few points of a percent difference in cpu usage, and I for one fail to see why we still continue to inflict this pain that is pulseaudio on the audio community. - end rant.

Besides the totally shit nature of the configuration tools, I mean.

qjackctl can hardly be called hard to use. it gives sane defaults and if you want to configure it you can, by default all you have to do is click 'start'.

With the exception of pro audio apps such as synths where it shouldn't be assumed you want it output to speakers, programs using jack automatically connect themselves to the system out without any configuration.

why is JACK so rarely supported?

Everything I'm running on my main machine right now uses jack, pulseaudio isn't even installed, yes this even includes the proprietary adobe flash plugin. All kde related notifications etc are using jack natively, mplayer, and so on.

Anything that doesn't use jack and tries to use alsa (i.e. adobe plugin) uses the alsa jack device.

So why don't we all just use JACK?

Because that would make sense, oh and it would consume a portion of a percent extra cpu time because of the more consistent cpu wakeups because of the smaller buffers and lower latency.

I am not kidding you, pulse audio devs think a fraction of a precent of cpu usage is worth dragging everyone through this bollocks with pulse. Oh, and that multiple seconds of latency can be a good thing.

As a fellow long time fedora user I can concur with most of your points, except on the pulseaudio horror stories.

After having significant issues with audio bits I went solely to jack (because of limitations with pulseaudio before that I had to disable pulse and enable jack for specific tasks), and have not been happier.

After reading this it is easy to see just how flawed the design of pulse is in comparison.When pulseaudio can have up to two seconds (!) of buffer and still create static, there are DEEP issues.

Recommended read. And that is from a primary pulseaudio developer. It goes on about all the design 'features' (flaws) that make it so damn lovely.

In essence we sacrificed stable, awesome low latency audio for fractions of a percent of cpu usage. Now anyone who does anything demanding with audio uses jack (I use it on all machines even if they just watch youtube vids) and all the stock distros distribute pulse.

PulseAudio should have never been invented, and it still doesn't have proper transport and SMPTE controls like jack (because it would fail horrendously with their as much lag as possible without getting noticed model)

ALSA functions well as what it is designed to more or less be, a hardware driver interface. Let Jack take over for mixing and routing and you are fine and dandy. Having low latency, synchronized audio with minimal cpu usage like Jack is a _good_ thing, not bad.

WTF is systemd?

Let me Google that for you.

If you use Linux, you'll be using it soon.

Here are some slides explaining it.

Also, mods, the GP wasn't flamebait, it was a valid opinion.

Lennart Poettering, the pulseaudio lead, is an Red Hat employee. Jaroslav Kysela and Takashi Iwai, the only two persons in the world who get paid for their work in ALSA, are hired by Red Hat and Novell respectively.

So where is Mark (and his money) when we need him?

And Ubuntu is known to have done a great deal of damage to PulseAudio's reputation by royally fsck up Poettering's work.

So what's the benefit of PulseAudio again?

Much better battery life for notebooks and other portable devices:

http://0pointer.de/blog/projects/pulse-glitch-free.html

Seamlessly handling hotplugged audio devices.

Smoothly handling sharing of audio hardware when doing fast user switching.

Providing software mixing and sample rate conversion for modern motherboard audio devices that very well might support only a single stream of audio at 48000 Hertz and 24-bit samples.

PulseAudio on Linux makes sense for exactly the same reasons Apple added a userspace sound daemon in OS X and Microsoft added a userspace sound dameon in Vista/Windows 7.

whenever I move away from my wireless access point at home [...] my sound stutters

The author of PulseAudio has gone to some great lengths[1] to make sure that PulseAudio is running at realtime priority, to make sure it doesn't drop packets of audio, i.e. stutter. Ubuntu has not enabled realtime priority for PulseAudio yet[2]. The network driver is a prime source of system slowdowns; I'll bet if you were to move your mouse pointer around as you move away from your wireless access point, you would see the smooth motion of the mouse turn into stuttering too.

I hope PulseAudio gets better in Ubuntu 9.10!

[1] He went so far as to champion a patch to the kernel, which allows giving realtime priority to a single process; if that process forks off any children, they do not inherit the realtime priority. This way, PulseAudio can be given realtime priority, but cannot be used to effect a Denial-of-Service attack against its host computer.

[2] http://0pointer.de/blog/projects/pa-in-ubuntu.html

What most people quite often fail to realise is that Latency is Good.

In some situations, but hardly all. PulseAudio needs to stop billing itself as a jack-of-all-trades solution to audio on Linux. Based on what I've seen, it's only helpful for use cases that few average users are likely to presently encounter. It may become the basis for a large number of really cool things in the future, but right now it's doing more harm than good by shipping by default on the majority of Linux distributions.

Here's a useless anecdote: For months I was trying to get a decent music production system set up on Linux and it was an unmitigated disaster. No distribution had the correct mix of drivers, sound servers, and applications that would make everything just work. I should point out that PulseAudio was enabled by default on all of them, and PulseAudio had to be manually disabled on all of them just to get any sound moving through the system at all.

When I can play a chord on my MIDI keyboard and have it played, mixed, processed, and output through the speakers in less than 20ms with PulseAudio in the chain, give me a call.

Ubuntu has gotten much better since then, the people involved are engaging with us upstream and a really good people to work with

I take it you haven't yet read Lennart Poettering's blog post today. In it, he basically says that Ubuntu is repeating the same kind of bonehead mistakes with packaging PA in Karmic that they've done with ever other Ubuntu release so far: "Not good, Ubuntu, really not good! And I'll get all the complaints for this f**up again. Thanks!"

"I'd like to try this out. I did a brief search for PA streaming via UPnP to a PS3 but didn't find anything. Could you point me in the right direction? "

http://0pointer.de/blog/projects/oh-nine-sixteen.html

/me laughs at the way /. has trimmed the subject to add the Re: prefix :p

You cannot separate the mixing from the buffering like that. Consider two apps, both playing audio tracks (it will sound terrible but let's not think about that!). Both apps have fed 10 seconds into the buffer so they can "spin down" and save power. All well and good. So the output is mixed and fed to the device buffer with the highest possible latency it supports. Again, all good. Now the user suddenly skips a track on player A. What happens here is that we have to throw away the 10s of pre-mixed audio, keep Player B's audio but remix it to new content provided by player A's decoding of the next track. So the mix+buffer has to be kept together, so that the buffer from a given app is not thrown away until we known that it's spent. AFAIK, these buffers can be passed in to PA under zero-copy and are only copied when the audio is mixed and then dumped into the device buffer. i.e. it's very low overhead.

As for the "implemented in alsa" stuff, it sadly isn't really a valid comparison. If it *were* implemented in alsa, we'd first of all need some kind of daemon to run and handle this mixing for us. We'd need something that has exclusive control of the real underlying hardware so that it can disable interrupts on it and feed the data into the device buffers under it's timing control, regardless of whether applications start or close inbetween. In the end you'll just design PulseAudio all over again but call it "alsad" instead. So the whole exercise is rather pointless!

And as for the comments about representing sound controls in GUIs this is actually a pretty complex task, especially when you take the concept of flat volumes into consideration. For every app there are effectively three volumes kicking around but it will only ever make sense to show the user a single unified volume.

When it's back online (currently that service is down due to Trac basically not handling things!) this article should be insightful: http://0pointer.de/blog/projects/writing-volume-control-uis.html

You may be interested that Ubuntu isn't the best at PA integration.

A lot of the problems with Pulseaudio are caused by the misconfiguration of Ubuntu's default kernel. It seems that they will be making the upcoming Karmic Koala even worse, according to a small rant on Lennart's blog today.

an explanation of the "need" for pulseaduio
*complex mixing code shouldn't go in the kernel
*"glitch-free audio" (yeah, i agree, whoever named it that should be shot) should save power
*per-app software mixing
*change the mixing/effects on hardware events
*position dependent sound (IMO if an app wants that they should code it/use a lib themselves)
As you can see I'm not a real fan but apparently that is why it's needed.

A really insightful article regarding this topic is this: http://0pointer.de/blog/projects/guide-to-sound-apis.html And this is what Lennart Poettering (Linux audio guru) had to say about this article: Nah, this is a complete and utter bullshit story. Slashdot just proved again that it is full of nonsense. Gah. Disgusting. I don't think that this deserves a real response. I mean really, this smells more like a astroturfing from 4front, with all that OSS4 fanboyism. This guys is just some lame fud blogger, not a technical guy who does any real the work, knows the technical details, works with the community and gets his stuff into the kernel or the distributions. Would be good if Slashdot would verify that the folks whose story they post actually know what they are talking about. Because this dude obviously hasn't. But I guess Slashdot is not the New York Times and asking some actual respected Linux developers or even just linux-audio-devel before publishing such FUD stories would be asking for too much. That famous Adobe jungle picture that was posted 2007 was grossly misleading already, and it still is. At least arts, nas, esd, oss were obsolete back then already, and mentioning almost unknown niche system such as Allegro or ClanLib doesn't make it any better. What I have to say about the situation of Linux audio APIs I posted here: http://0pointer.de/blog/projects/guide-to-sound-apis.html If you care enough about slashdot, then try to get them to bring a story about that blog story, even if it is already frm last year. As a change from their usual stories this one, as I dare to say, would be written by someone who has at least a bit insight into what's really going on. ;-) Lennart

A really insightful article regarding this topic is this: http://0pointer.de/blog/projects/guide-to-sound-apis.html And this is what Lennart Poettering (Linux audio guru) had to say about this article: Nah, this is a complete and utter bullshit story. Slashdot just proved again that it is full of nonsense. Gah. Disgusting. I don't think that this deserves a real response. I mean really, this smells more like a astroturfing from 4front, with all that OSS4 fanboyism. This guys is just some lame fud blogger, not a technical guy who does any real the work, knows the technical details, works with the community and gets his stuff into the kernel or the distributions. Would be good if Slashdot would verify that the folks whose story they post actually know what they are talking about. Because this dude obviously hasn't. But I guess Slashdot is not the New York Times and asking some actual respected Linux developers or even just linux-audio-devel before publishing such FUD stories would be asking for too much. That famous Adobe jungle picture that was posted 2007 was grossly misleading already, and it still is. At least arts, nas, esd, oss were obsolete back then already, and mentioning almost unknown niche system such as Allegro or ClanLib doesn't make it any better. What I have to say about the situation of Linux audio APIs I posted here: http://0pointer.de/blog/projects/guide-to-sound-apis.html If you care enough about slashdot, then try to get them to bring a story about that blog story, even if it is already frm last year. As a change from their usual stories this one, as I dare to say, would be written by someone who has at least a bit insight into what's really going on. ;-) Lennart

I installed a new Videocard. Windows detected it and I installed the drivers. Worked great. I then booted Linux. Linux detected the card and I installed the drivers. Linux couldn't figure out what resolution my monitor supported.

My experience has been decidedly the opposite. I've had Windows refuse to boot when I added a new video card, but Linux ran fine. Not long ago, I had a SATA error on my motherboard. Windows refused to boot, Linux (Ubuntu 8.08, to be specific) ran just fine. The fact that it was only Windows that failed kept me from suspecting the hardware, though clearing the CMOS eventually fixed the problem.

Linux does have problems, but the thing is, they aren't being ignored.

First up your point about the sheer proliferation of different ways of playing sound on Linux and lack of docs is a strong one but things have been slowly improving over the years. The author of Pulseaudio has written a good guide as to what to use. The list of APIs is still bigger than 3 but in most cases it becomes clearer on what to target.

ALSA comes in (yeah I can hear the groans) two forms. A small "virtualisable" subset referred to as safe ALSA and full ALSA.

OSS is usually considered legacy. There most certainly is OSS4 (which is not) but that does not have the traction on Linux and most people only have an OSS3 -> ALSA layer so its dangerous for new apps to target it.

NAS is not that popular. I only come across it in Linux audio conversations like this. I don't think anyone feels they have to target it.

ESD is obsolete but was VERY popular. New apps should not be targeting it now though.

Pulseaudio. Interesting but has suffered due to partial implementations in some popular distros that users felt caused more problems than they fixed. For regular users I do think it is key for Pulseaudio to work past its problems though - it offers a lot of promise and is probably Linux's best chance to date of offering certain features. New apps can target it directly (for best support) or just use safe ALSA.

SDL (for sound). Interesting if you are writing games but in most other cases you would use something else. Its presence has never been a problem as it quickly became clear it was for games.

JACK. This is for professional musicians. If you have to target this then you are going after a high-end sound market. Most sound playing apps are not in this case.

KDE 4's Phonon. If you are only targeting KDE4 then I guess you should be using this.

gstreamer. If you are interested in codecs (e.g. playing vorbis music files or theora video) rather than decoding/encoding files yourself you should probably be using this.

For games use SDL. If you are only targeting KDE4 use the KDE4 stuff. For codec support use gstreamer. OSS and ESD should no longer be targeted in first tier Linux audio support. Pulseaudio will probably become more popular (so you can consider targeting it directly) but safe ALSA will probably have the broadest user base for a while.

I found out there were patches made to SDL that broke compatibility with many Linux games. It took weeks of "digging them out." to solve the problems.

For SDL: Did a packaging of the pristine upstream source have the same problems? Did you identify which specific patches which caused the problem?

Also, the sound stack for Linux seems overly complicated at the current time. There is some guidance here, but if you need to have a talk at the Linux Plumbers Conference that says, "Application developers, do not write directly to the hardware interface," you have already failed. Of course, there's some controversy about this guide because a bunch of OSS programmers can't accept any opinion of their API different from theirs.

The pulseaudio sound daemon does this.

screenshot

It allows for setting the volume per audio source.

In great *nix tradition, you should solve the problem by combinding many single purpose tools.
Use something like http://0pointer.de/lennart/projects/ifplugd/ to launch a script that runs Unison file sync when ever you are connected to the network.

Seems not only Linus is pissed of by Sun. The GNOME project as well:

http://www.placenet.org/benoit/index.php/post/2007 /06/13/Indiana-patches
http://0pointer.de/blog/projects/project-indiana.h tml

Someone would need to write an nsswitch "plugin" for bonjour. So far as I know, this has not been done.

It has been done - nss-mdns. It's been packaged for most Linux distributions. Getting it working on my Debian box was a simple matter of apt-get install libnss-mdns and then edit /etc/nsswitch.conf to use the new nss plugin.

I noticed that the article didn't mention LUFS. This alone allows for tremenduous possibilities, not least of which is rapid development of filesystems. Do any other systems (besides GNU HURD) have userspace filesystems?

LUFS hasn't been maintained since 2003, and is therefore almost dead. FUSE (Filesystem in Userspace) is the most promising alternative that is getting merged into the 2.6.14 mainline Linux kernel. It works with several network filesystem protocols like:
SMB for FUSE
SSH Filesystem (SSHFS)
FuseDAV (WebDAV)

Linux-FUSE can also provide all applications on the system (even shell utilities) with access to network locations set up under KDE. There's a tutorial for how to do this, but last time I tried it did not compile :-(

These are much needed improvements to usability of the Linux desktop, because unprivileged (non-root) users shouldn't have to contact their sys. admins everytime they need to mount network locations. The KDE approach to providing network access is not complete without Linux-FUSE, because only KDE apps can open/save to network locations set up under KDE. Hopefully the KDE devs will create a GUI for mounting/unmounting FUSE shares so that all apps (GTK, Motif, even shell utilities) can access network files.

This filter tries to make Wikipedia more authoritative: http://l33t.0pointer.de/?skill=3&url=http%3A%2F%2F en.wikipedia.org