The case for the /usr merge [LWN.net]

The case for the /usr merge

Posted Jan 28, 2012 1:27 UTC (Sat) by sbergman27 (guest, #10767)
In reply to: The case for the /usr merge by rickmoen
Parent article: The case for the /usr merge

"1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)"

For whatever reason, a separate /boot filesystem is necessary to convince RHEL's Anaconda to install grub on /dev/md0 rather than /dev/sda. Red Hat says a separate /boot is necessary to boot off software RAID.

Amusingly, that advice about "older systems" is still alive and well in 2012. New users worry about it since their machine is one of those older Core2 Quad systems and not a modern Core i7.

Anyway, I'm still waiting for one of Lennart's inventions not to be 0 steps forward, 2 steps back. Isn't destroying sound *and* init in Linux enough for one person?

to post comments

The case for the /usr merge

Posted Jan 28, 2012 15:36 UTC (Sat) by HelloWorld (guest, #56129) [Link] (36 responses)

> Anyway, I'm still waiting for one of Lennart's inventions not to be 0 steps forward, 2 steps back. Isn't destroying sound *and* init in Linux enough for one person?
You're clearly confused. Both PulseAudio and systemd are massive improvements.

The case for the /usr merge

Posted Jan 28, 2012 23:28 UTC (Sat) by sbergman27 (guest, #10767) [Link] (35 responses)

I can honestly say that I have *never* had a desktop machine that used PulseAudio where pulse did not cause some problem or another. I've also never had one where Pulse brought with it any advantages. Per app volume controls? What apps don't have thier own? Software mixing? What sound chipsets, even really cheap ones, don't support hardware mixing of multiple channels? Network audio? ESD did that just fine without causing audio problems so severe that a reboot (yes, a reboot) was required. Simply logging out, killing pulse, and logging back in, has not helped on the machines which exhibited this problem.

Regarding systemd... Scott James Remnant's team looked into the port-listening strategy that systemd is based upon for possible use in Upstart. It had architectural problems that were irresolvable, so they quite reasonably abandoned it.

Mark my words. Fedora will be changing its init system again in the not so terribly distant future. After they've had enough of Lennart and systemd, and something newer and shinier comes along.

-Steve

The case for the /usr merge

Posted Jan 28, 2012 23:53 UTC (Sat) by HelloWorld (guest, #56129) [Link] (12 responses)

> I can honestly say that I have *never* had a desktop machine that used PulseAudio where pulse did not cause some problem or another.
This is the typical FUD of lwn trolls. How many machines did you try it on? When was that? What specific problems did you run into? Without this kind of information, a comment like yours is just useless trolling.
Anyway, I've been using PulseAudio for some time now and it works flawlessly.

> Per app volume controls? What apps don't have thier own?
Firefox doesn't and I don't know how to use mplayer's. And I don't feel like I should need to learn, after all, pavucontrol offers a consistent interface for *all* sound applications.

> Software mixing? What sound chipsets, even really cheap ones, don't support hardware mixing of multiple channels?
Err, like, almost every one? I haven't seen an audio chip with hardware mixing since my Asus A7V880 broke. That's because hardware mixing is useless nowadays.

> Network audio? ESD did that just fine without causing audio problems so severe that a reboot (yes, a reboot) was required. Simply logging out, killing pulse, and logging back in, has not helped on the machines which exhibited this problem.
It's obvious that these problems are caused by the audio driver, not by PulseAudio. In fact, most PulseAudio-related problems could be traced back to driver bugs.

> Regarding systemd... Scott James Remnant's team looked into the port-listening strategy that systemd is based upon for possible use in Upstart. It had architectural problems that were irresolvable, so they quite reasonably abandoned it.
This is, again, totally useless. Where's your source? I checked netsplit.com and couldn't find anything about these supposed problems.

The case for the /usr merge

Posted Jan 29, 2012 2:58 UTC (Sun) by sbergman27 (guest, #10767) [Link] (11 responses)

"This is the typical FUD of lwn trolls."

I don't intend to spend the evening flame-warring with you. However, I will respond exactly once.

I've used it on many machines (too many to remember or count) since it first debuted in Fedora... whatever it was. 7? And I'm not kidding. There has always been *some* problem that prompted me to uninstall it. The first time through it immediately locked up all the remote X desktops at the client site where I had done the upgrade that introduced PA. And the problems continued, year after year.

Granted, over the last year or two I've taken to just uninstalling it immediately after installation. I did not do so on my new Scientific Linux 6.1 desktop... and sound in totem-plugin didn't work at all... until I uninstalled pulse.

"Firefox doesn't and I don't know how to use mplayer's"

Firefox should probably provide a volume control for its HTML5 video, if it doesn't already. Certainly Totem, VLC, and Mplayer plugins do. As well as the all-important Flashplayer. I can't say as I've noticed the Firefox issue since there is so little HTML5 streaming media available now. There's Youtube HTML5 beta. But it still doesn't work well enough to use on an every day basis.

"I haven't seen an audio chip with hardware mixing since my Asus A7V880 broke."

What color is the sky on your planet? I haven't seen a motherboard in years that didn't provide hardware mixing. Uninstall pulse, and I'll bet your current Mobo will mix just fine. Don't just buy the the PA propaganda uncritically. Try it for yourself.

"It's obvious that these problems are caused by the audio driver, not by PulseAudio. In fact, most PulseAudio-related problems could be traced back to driver bugs."

And yet I uninstall PulseAudio, and without exception, sound works perfectly fine. A very strange series of audio driver bugs, indeed. They only ever affect Pulse Audio.

"This is, again, totally useless. Where's your source?"

That information came from a talk given by Scott. It's available online. I spent a bit of time looking for it. But like I say, I'm not about to waste excessive time this evening arguing with an obvious Poettering fanboy over trivialities.

You want to suffer with his crapware? It's certainly no skin off my nose. Go right ahead.

-Steve

The case for the /usr merge

Posted Jan 29, 2012 10:11 UTC (Sun) by niner (guest, #26151) [Link] (9 responses)

> Firefox should probably provide a volume control for its HTML5 video, if it doesn't already. Certainly Totem, VLC, and Mplayer plugins do. As well as the all-important Flashplayer.

The only thing that MPlayer does is control the PCM volume. So when you turn down the volume in MPlayer, everything else gets quiet as well. That's hardly what I would call per application volume control.

> What color is the sky on your planet? I haven't seen a motherboard in years that didn't provide hardware mixing. Uninstall pulse, and I'll bet your current Mobo will mix just fine. Don't just buy the the PA propaganda uncritically. Try it for yourself.

Your motherboard does nothing! It's ALSAs dmix plugin that does the mixing in this case.

> And yet I uninstall PulseAudio, and without exception, sound works perfectly fine. A very strange series of audio driver bugs, indeed. They only ever affect Pulse Audio.

Because PulseAudio tries to do something better than sound systems on Linux have before. It uses timer based scheduling instead of interrupt based which lieterally increases battery life on my laptop for hours due to fewer CPU wakeups. Just like for example OS X has been able to for years.

The case for the /usr merge

Posted Jan 29, 2012 11:12 UTC (Sun) by mikachu (guest, #5333) [Link] (4 responses)

echo softvol = yes >> ~/.mplayer/config

The case for the /usr merge

Posted Jan 29, 2012 11:32 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (1 responses)

Which raises the inevitable question "Who, exactly, thought that softvol=no being the default was a good idea?".

The case for the /usr merge

Posted Jan 29, 2012 13:43 UTC (Sun) by mastro (guest, #72665) [Link]

Softvol uses a bit more CPU and when used at very low volume degrades sound quality when compared with just setting the correct PCM volume. At least this was the case a few years ago, not sure how stuff works with pulseaudio.

The case for the /usr merge

Posted Jan 29, 2012 13:58 UTC (Sun) by HelloWorld (guest, #56129) [Link] (1 responses)

Why bother with editing config files, when I can just use pavucontrol which gets the job done and works the same everywhere?

The case for the /usr merge

Posted Jan 30, 2012 20:18 UTC (Mon) by mikachu (guest, #5333) [Link]

I was just correcting an incorrect statement, feel free to use whatever you want.

The case for the /usr merge

Posted Jan 29, 2012 17:06 UTC (Sun) by sbergman27 (guest, #10767) [Link] (3 responses)

"Your motherboard does nothing! It's ALSAs dmix plugin that does the mixing in this case."

Even better. Then Pulse is not only redundant, but in some cases double-redundant.

"It uses timer based scheduling instead of interrupt based which lieterally increases battery life on my laptop for hours due to fewer CPU wakeups."

Show me the data. I'm extremely skeptical. Unless you mean that you save a lot of power after your sound dies. That would make sense.

The case for the /usr merge

Posted Jan 30, 2012 1:40 UTC (Mon) by slashdot (guest, #22014) [Link] (2 responses)

dmix won't be enabled if Pulse is active, in sane distributions, obviously.

The case for the /usr merge

Posted Jan 30, 2012 19:40 UTC (Mon) by sbergman27 (guest, #10767) [Link] (1 responses)

But ALSA will be there. (Is anyone using OSS?) So PA's "functionality" is still redundant in this capacity.

The case for the /usr merge

Posted Feb 2, 2012 8:54 UTC (Thu) by keeperofdakeys (guest, #82635) [Link]

ALSA is incapable of software mixing, the dmix plugin handles this. So PA isn't redundant in this capacity.

As for OSS, no one uses it directly (or at least shouldn't). Many programs will use the OSS emulation offered by ALSA (which doesn't support software mixing). The interesting thing about OSS is that it was originally open source, became closed, and became open source again with version 4. Although, now we have shifted to ALSA, it will probably never be as popular.

The case for the /usr merge

Posted Jan 31, 2012 10:37 UTC (Tue) by daniels (subscriber, #16193) [Link]

You want to suffer with his crapware? It's certainly no skin off my nose. Go right ahead.

It's a shame that this approach doesn't extend to LWN comments too.

The case for the /usr merge

Posted Jan 29, 2012 5:12 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (21 responses)

Last time you made a bet against Fedora, you lost but you probably don't remember that. So I am curious. What's the timeframe and what do you promise to do if you lose your bet? :-)

The case for the /usr merge

Posted Jan 29, 2012 5:48 UTC (Sun) by sbergman27 (guest, #10767) [Link] (20 responses)

"What's the timeframe and what do you promise to do if you lose your bet?"

It depends upon when the next new and shiny comes down the pike. One thing you guys can never seem to resist is new and shiny. Sometimes my Fedora predictions turn out to be correct. And sometimes they don't. To which one are you referring?

I'll sincerely give you credit, though. In general, the churning nightmare that is Fedora, after being vetted, tested, filtered, beta'd, properly QA'd and released by your parent organization, is absolutely top notch. Oh, RHEL's PulseAudio is nearly as bad as it was in Fedora, as I have already described. But it's easily removed. And packagekit inherits the perrenial locking problems that yum has had since the FC1 days. And it's still slower than Synaptic. (Although better than it used to be.) But other than that, RHEL and its clones are absolutely fantastic. I've taken a hiatus from Ubuntu on my home desktop, and am quite enjoying RHEL, CentOS, and SL. Especially SL, which is a new one for me.

Not that I ever left the RHEL family behind. It is a bitter-sweet combination of sadness and joy to me that several of my customers' venerable CentOS 4 servers must be upgraded in the next month. It's been a great 7 years of perfect OS stability. Some will be going CentOS 6.2. Others to Scientific Linux 6.1, or 6.2 if it is ready.

Oh, what the hell. I predict you'll be off systemd in 3 years or I'll buy you a burger. We can sync up in 2015. :-)

-Steve

The case for the /usr merge

Posted Jan 29, 2012 15:59 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (19 responses)

Nah. No burger. You will lose the bet and when you do, if you can sing praises of Fedora all the time, we have a real wager. See you in 2015.

The case for the /usr merge

Posted Jan 29, 2012 17:50 UTC (Sun) by sbergman27 (guest, #10767) [Link] (18 responses)

"You will lose the bet and when you do"

Time will tell. Your last new init replacement didn't lask very long in the very fickle Fedora. Few things do. So the odds are in my favor.

"if you can sing praises of Fedora all the time,"

Highly unlikely, but not entirely beyond the pale. It depends upon how responsibly the Fedora devs and advocates behave in future. I'm am critical. Even biased by long experience with the distro. But I am also fair.

BTW, my memory may be somewhat better than you counted on. I distinctly remember you stating that you had lost all respect for me because you felt that I was blaming Fedora for that Fedora creation, Pulse Audio, causing widespread problems in other distros. You claimed that all the other distros just weren't doing it right. And that all the problems had been resolved in Fedora. That was a while back.

Well... I now have 3 Scientific Linux 6.1 machines within 1 meter of me which put the lie to that claim. Unless you want to claim that Fermilab and Cern took the perfectly functional PA from Red Hat's premier OS, RHEL 6, based upon F12 and F13, and broke it, I must conclude that PA in F12 and F13 was as broken as I claimed at the time. Sound randomly dies on all three of these machines (with 2 different audio chipsets) until PA is removed. That, after an additional 3 years of QA from Red Hat, which normally does do well.

I really should have bet you a nice lobster dinner on *that* one.

-Steve

The case for the /usr merge

Posted Jan 29, 2012 18:09 UTC (Sun) by mpr22 (subscriber, #60784) [Link] (12 responses)

My instinctive questions would be "How large a sample size is two audio chipsets?" (I have no particular feel for how many different audio chipsets exists) and "Which audio chipsets, and did you file a bug report or just go 'bah, poxy lennartware *uninstall*' and not bother?".

The case for the /usr merge

Posted Jan 29, 2012 20:22 UTC (Sun) by sbergman27 (guest, #10767) [Link] (11 responses)

Since it was introduced in FC6 or F7 or whenever, my success rate with PA has been 0%. It can sometimes be made to mostly work with some futzing around. But why bother when it offers no advantage to just using ALSA?

Anyway, a Google search on:

pulseaudio "no sound"

brings up over a million hits.

It's been admitted in this very thread that PA tries to do things that have worked for Apple on its tightly controlled harware, but apparently don't work well in the freewheeling world of PC hardware. That was a fatal design in PA for its intended audience.

Vendors of sound hardware don't care if PA works or not. And with Linux having been stuck at ~1% of the desktop market for the last 10 years, that situation is not likely to change. Best to deal with sound hardware the way it *is* and not the way you'd like it to be.

ALSA FTW! The pragmatic approach is often the best.

-Steve

You've started it...

Posted Jan 29, 2012 21:34 UTC (Sun) by khim (subscriber, #9252) [Link] (6 responses)

Anyway, a Google search on:

pulseaudio "no sound"

brings up over a million hits.

Which looks like a disaster if you'll not compare it with similar search

alsa "no sound"

which returns over 50 millions results.

ALSA FTW! The pragmatic approach is often the best.

Right. And my pragmatic approach is to close all bugs where some kind of non-standard configuration is used as INVALID. This reduces amount of testing required - which is practical for me. Systems with uninstalled PulseAudio most definitely fit the bill as far as sound is involved.

You've started it...

Posted Jan 29, 2012 21:40 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

And my pragmatic approach is to close all bugs where some kind of non-standard configuration is used as INVALID.

Right. So in the end nobody but the developers can use the configuration options provided, because if they use them they can't report bugs or get them fixed. And then those configuration options get removed because they're unused. And then we look around at the non-configurable desert which our free platform has become and wonder when exactly we took this wrong turn.

You've started it...

Posted Jan 30, 2012 9:56 UTC (Mon) by khim (subscriber, #9252) [Link]

Why do you think someone took the wrong turn? Non-configurable desert is one description which tries to imply this is somehow bad. Uniform experience is another description for the same thing - and it's usually praised by reviewers... unless they themselves want to change something - and can not.

I'm not saying all options are worthless (it'll be hypocritical for me to say so since I toggle quite a few knobs on new systems). But they should all earn the right to live. No exceptions. You must compare overhead the developer faces for given option with popularity of said option. If option is wildly popular then it must be supported even if it's quite painful for the developer. If it's trivial and does not require a lot of Q&A resources then it can be kept even if it's not all that popular. But if it's both not popular and painful - then it's better to make it go away.

You've started it...

Posted Jan 29, 2012 22:05 UTC (Sun) by sbergman27 (guest, #10767) [Link] (3 responses)

"""
Which looks like a disaster if you'll not compare it with similar search

alsa "no sound"

which returns over 50 millions results.
"""

44 million. But since PA depends upon the underlying sound system, if one's chances of getting sound working in Linux without PA are bad, their chances of getting it working with PA are far worse.

PA is the first time in the history of Linux that after the actual sound driver is working, the user still faces a major and long-standing hurdle in getting the sound server working. Sometimes I think desktop Linux has a deathwish. No, that's not right. At this point, in 2012, it's pretty certain that Desktop Linux has always had a deathwish. We never had a chance. We only kill the things we love.

You've started it...

Posted Jan 30, 2012 9:49 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

PA is the first time in the history of Linux that after the actual sound driver is working, the user still faces a major and long-standing hurdle in getting the sound server working. Sometimes I think desktop Linux has a deathwish.

Sorry, but you are wrong again. Try the aforementioned search with esd instead of pulseaudio or alsa - and you'll get more results then in pulseaudio case.

The fact that you personally know how to debug and fix problems with esd and don't know how to do the same with pulseaudio says more about you then about pulseaudio or esd.

You've started it...

Posted Jan 30, 2012 14:48 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Even better than ESD, remember ARtS? Why have one sound server when you have have two incompatible ones both vying for access to a single, exclusive, sound output along with applications who try to use the sound output directly. Having one sound server rather than a bunch of incompatible ones fall in an out of fashion every few years is an improvement in and of itself, even if it was no better, which it is.

You've started it...

Posted Jan 30, 2012 19:48 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"The fact that you personally know how to debug and fix problems with esd and don't know how to do the same with pulseaudio says more about you then about pulseaudio or esd."

I only use a sound server when such functionality is useful. i.e. network transparency. (Though HelloWorld has mentioned another feature useful for some.)

You don't seem to understand that the sound server is dependent upon the underlying sound system on either the client or the server machine.

I've had less trouble (in fact, no trouble) with ESD. But I don't use any sound server when none is required.

The case for the /usr merge

Posted Jan 29, 2012 21:43 UTC (Sun) by elanthis (guest, #6227) [Link] (1 responses)

> Since it was introduced in FC6 or F7 or whenever, my success rate with PA has been 0%. It can sometimes be made to mostly work with some futzing around. But why bother when it offers no advantage to just using ALSA?

My success rate has been 100%. ESD constantly crashed on me, and ALSA dmix has locked up on me before. Also, ALSA/ESD don't support device hot plugging with automatic output switching, which I do use here and there on my laptop.

Anecdotes are a GREAT way to debate!</sarcasm>

The case for the /usr merge

Posted Jan 29, 2012 22:50 UTC (Sun) by sbergman27 (guest, #10767) [Link]

"""
My success rate has been 100%. ESD constantly crashed on me, and ALSA dmix has locked up on me before.
"""

Obviously, that was a problem with your configuration or harware.

(That's a little joke. But do try the latest ESD nightlies! They're fantastic!)

I quite agree with you about anecdotal evidence. Unfortunately, it's pretty much all we have in Desktop Linux. Rightly or wrongly, one's own anecdotes take priority over others' anecdotes. And there is some justification for that. About all we can do right now is keep careful notes and do the best we can with the information we have, trying to keep in mind the 'p' significance of our own personal datasets.

It would be much nicer to have actual data. But indeed, the plural of "anecdote" is not "data".

On my machines, and my customers' machines, over the last serval years, PA has been pretty much a failure.

The case for the /usr merge

Posted Jan 30, 2012 2:07 UTC (Mon) by HelloWorld (guest, #56129) [Link] (1 responses)

> But why bother when it offers no advantage to just using ALSA?
It does offer advantages, for example the ability to move audio streams from one device to another (*very* handy with USB or Bluetooth headsets). Anyway, you're obviously biased against PulseAudio, so discussing this with you is probably a waste of time.

The case for the /usr merge

Posted Jan 30, 2012 7:48 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"""
It does offer advantages, for example the ability to move audio streams from one device to another (*very* handy with USB or Bluetooth headsets).
"""

That's a reasonable enough point. It's not one that interests me. But it is likely significant to others. I would have nothing against PA if it did not so often break sound completely. If it sometimes allows people to enjoy a degree of increased flexibility, I would not begrudge them that.

-Steve

The case for the /usr merge

Posted Jan 30, 2012 0:57 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

"You claimed that all the other distros just weren't doing it right. And that all the problems had been resolved in Fedora. That was a while back."

This is clearly not something I have ever claimed and I bet the world you cannot produce a direct quote at all. So yes, my memory is much better than yours. We will see you in 2015 when you lose your bet :-)

The case for the /usr merge

Posted Jan 30, 2012 7:04 UTC (Mon) by sbergman27 (guest, #10767) [Link] (3 responses)

"""
This is clearly not something I have ever claimed and I bet the world you cannot produce a direct quote at all.
"""

It was either here or on OSNews. I might even bother to look it up if there were a lobster dinner in it for me. Just kidding on that last. Lobster is... tedious. But it *was* either here or on OSNews. And I'm not kidding on that point. :-)

-Steve

The case for the /usr merge

Posted Jan 30, 2012 15:40 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I am sticking to my bet. You can't provide a direct quote.

The case for the /usr merge

Posted Jan 30, 2012 20:42 UTC (Mon) by sbergman27 (guest, #10767) [Link] (1 responses)

It's not important enough to go digging through the archives for. I suspect you do remember it. I do, since it was the first response which I had seen from you in which you seemed to have lost your cool. It made me wonder if I had, perhaps, pushed things too far.

If so, I belatedly apologize. We do spar. But know that I do value your contributions, and respect your convictions. (In case you didn't already know.)

I still dislike Fedora. But it results in RHEL, which is superb. Hey, most people don't think of the stinking draught of the slaughter house when they go to Wendy's for a burger. I don't think of Fedora when I use Scientific Linux or CentOS.

-Steve

The case for the /usr merge

Posted Jan 30, 2012 21:13 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

People putting words on my mouth is a pet peeve of my mine but I do remember clearly what I said and you are badly paraphrasing it, which is what I was hinting at strongly. Feel free to look up the archives if you want to confirm what I said.

IMO, it doesn't make sense to look down on a parent distribution while praising a derivative when the benefits you see on the derivative are the direct result of a lot of the work in the parent. This applies as much to Fedora and RHEL and in many even more so when compared to say Debian and derivatives. In other words, work done in Fedora is a necessity for the results you see in RHEL and rest of the Linux world. Fedora might not be suitable for you and I understand that. However the evident disdain is irrational and just seems like a sore gripe from the past, be it Fedora or PulseAudio considering for instance, majority of distributions seem to be defaulting to it and I don't think most people are having any issues anymore. I would say, time to let go and move on to whatever works best.