Some questions that do 3d6 fire damage

Posted Aug 26, 2010 5:14 UTC (Thu) by jmorris42 (guest, #2203)
Parent article: Systemd and Fedora 14

Dunno, I have a couple of observations....

First off, since Mr. A**hat's last great 'innovation' (solution to a problem few have) has had audio on Fedora broken for several YEARS now and shows no signs of getting fixed any time soon, wouldn't his "What me worry?" attitude be better received if he could have bothered to finish PulseAudio before moving on to breaking an even more fundamental subsystem?

With only a trivial effort one can still find a dozen less popular apps both in and out of the Fedora repos that Pulse breaks. It wasn't too long ago that FlashPlayer was hit or miss. Because Fedora has embraced it so hard removing it breaks most of the desktop so there isn't a solution. Classic no win scenario. All because Fedora realized that forcing users to run Pulse was the only way anyone would ever run it. Seriously, if the core packages still supported ALSA nuking Pulse would be as routine as nuking SE-Linux after the first couple of kaboom! events. No brainer, no benefit to keeping it because it provides zero benefit for 99% of users.

Systemd might just be the greatest thing since sliced bread. I read the article and still can't decide if I like the theory or not. But the number one objection is that it sounds too good to be true in that it will work great... if every last obscure package gets with the program.

Been there and got the T-Shirt, this is Pulseaudio all over again. Since it is useless to a user, if it can be disabled it will so Fedora will either abandon it or force it by dropping upstart and sysvinit.

Every package will still be maintaining support for traditional startup because other distros (and *BSD, OpenSolaris, etc) will be sticking to UNIX ways. Any package where the core devels aren't on Systemd the support for it will either be an afterthought or a contrib package from outside, probably from an @redhat.com address. Not a recipe for the sort of 100% buyin this totally different init scheme requires.

There is one certainty if history is any guide, implementing this thing will cause years of lossage and the only sensible question is whether the pain will balance the gain. Beautiful theories don't exist in a vacuum, lots of real users and admins are going to have to expend a non-trivial amount of effort just relearning. That assumes it works flawlessly. It won't.

Which brings me to the final question, one I have asked relating to all of this New Tech. UNIX is well documented. Will this ship with quality documentation? Because if it doesn't the history of the rest of the New Tech indicates it never will be documented because the professional publishers have stopped trying to keep up with the warp speed replacement and re-replacement of the core tech in Linux. So when it breaks, and it will, figuring out what broke and how to patch it is going to be a nightmare of highly complex and poorly documented software. Say what you will about the wisdom of a nest of shell script but SysV Init can be understood in under an hour by anyone halfway Unix literate.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 5:57 UTC (Thu) by tajyrink (subscriber, #2750) [Link]

Indeed a bit flamy, but it's reasonable. I think the attitude in general is that Pulseaudio isn't broken, everything else is. Will it be the same with systemd? Not really broken, it's just that the applications are...

And yes, I still have worse audio user experience with Pulseaudio than what I had before it. And I'm not even using Adobe Flash, but just watching movies (with pass-through audio via digital coaxial out) and playing some games. I've figured out some workarounds by googling, but not all. For example Frets on Fire I can't play properly on a 64-bit computer without Pulseaudio uninstalled (visual hickups caused by Pulseaudio audio chain strain eyes, yes there is a bug open).

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 6:00 UTC (Thu) by Hknr (guest, #67789) [Link] (32 responses)

Amen brother, another project from a man that tries to solve
problems where there aren't any and breaks everything along
the way.
I wouldn't touch this crap with a ten foot pole.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 7:37 UTC (Thu) by mbaldessari (guest, #36769) [Link] (17 responses)

"another project from a man that tries to solve
problems where there aren't any". This is probably one of the most clueless comments I've read around here. Audio in Linux needed fixing and albeit PulseAudio has had it quirks, it works much better now, and it went a *long* way at improving the ridiculous audio situation we had before.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 7:57 UTC (Thu) by Hknr (guest, #67789) [Link] (16 responses)

Thank you.
I'll give you an example: I use an external USB-DAC
that directly feeds into my amplifier. With a little
bit of asound.conf tweaking, I get bit-perfect output
from my flac music collection (and even crossfeed support
when I use my headphones).
So why would I want to add a shitlayer on top of that?

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 11:11 UTC (Thu) by Los__D (guest, #15263) [Link] (15 responses)

Wow... You "only" need to mess with some obscure configuration file to make stuff work! Everything is perfect then!

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 11:26 UTC (Thu) by Hknr (guest, #67789) [Link] (8 responses)

Messing with configuration files to make stuff work
is exactly the way we like it in Linux land.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 11:35 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Speak for yourself. I rather have stuff work without messing around with configuration files in my Linux land. Busy work makes no sense to me.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 12:52 UTC (Thu) by nicooo (guest, #69134) [Link]

With alsa you don't need to edit any files for a regular setup. If you want to do something out of the ordinary, using a config file is easier than some complicated gui.

Systemd gets it right by using ini instead of the xml that everything else hosted on freedesktop.org seems to use.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 12:18 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (3 responses)

My attitude to hand-editing configuration files is simple:

The system must allow it.
It should almost never be necessary.

The system should provide tools to make most-or-all commonplace configuration actions, and many less commonplace ones, achievable without using a text editor. If using a text editor to configure the system is necessary, at least one of the following statements is true:

The system's users have unusual requirements not easily predicted by the designers of the autoconfiguration mechanisms and "simplified" manual configuration tools.
The system's configuration has a level of essential complexity high enough that a text editor is the only useful way to configure the system at all, or low enough that you can't plausibly get it wrong in a bad way.
The system is broken.

Some questions that do 3d6 fire damage

Posted Aug 27, 2010 1:20 UTC (Fri) by drag (guest, #31333) [Link] (2 responses)

The other main argument is that hardware is now dynamic.

Here is very common hardware:
* USB headphones with microphones
* USB sound card
* Bluetooth heaphones

Notice how they are all dynamic?

So yeah. Alsa, by itself, can work really well if all you want to do is listen to Flac files over a static configuration... but it's shit if you want to do anything more complicated like:

* play more then one sound simultaneously (I'd like to see you program into your asoundrc file a audio mixer that does not suck)
* use your microphone
* use audio input with more then one application
* Use X11 applications over a network that have audio
* use a USB docking station for your laptop
* use your bluetooth headset
* Be able to switch your bluetooth headset between stereo sound and telephone modes
* configure your laptop's audio output (on the fly) between:
- off
- stereo audio with input
- 4 speaker surround sound
- stereo audio with digital output
- digital output with digital input
* Play your game's audio out through the speakers and then chat with people on your usb headset

And a bunch of other crap people using other OSes take for granted but is nearly impossible to do in Linux with any sort of sanity and when it does works it only works in extremely static and carefully maintained configuration.

And, no, switching to OSS is not going to help any since OSS, even in the newest versions, is less capable and more of a pain in the ass to configure then Alsa is... OH it uses software mixing by default, unlike ancient versions of Alsa. One problem solved and sixty thousand more to go.

Some questions that do 3d6 fire damage

Posted Sep 6, 2010 16:41 UTC (Mon) by nye (subscriber, #51576) [Link] (1 responses)

I'm sure those things would be lovely, if there was more than 50% chance that the piece of shit would produce any fucking sound at all.

Some questions that do 3d6 fire damage

Posted Sep 6, 2010 17:10 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

I am sure there is 98.7 % chance of sound. Much better than ALSA's 76.5% :-)

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 21:20 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

And just how much documentation is there for asound.conf? Sod all useful that I can find, that's how much. There's even a Lisp interpreter in there somewhere, although I'm not sure where. I suspect I'll have to grovel through the source code to figure out the syntax, and life is just too damn short.

I googled for a stanza to force everything through PulseAudio (first hit: pulseaudio.org's Perfect Setup page) and left it at that.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 21:39 UTC (Thu) by sfeam (subscriber, #2841) [Link]

And on that Perfect Setup page you will find the following advice:

KDE 4 uses Phonon as the main audio interface. The Xine backend of Phonon should eventually use PulseAudio automatically, but at the time of writing the pulse plugin for Xine is too unreliable, so it's disabled by default. While waiting for that to get better, Phonon uses Alsa. Therefore, to get Phonon to use PulseAudio, you have to edit your ~/.asoundrc or /etc/asound.conf. However, the normal .asoundrc modifications aren't enough. See #232 (specifically the workaround part). New progress is being made with KDE 4 and Phonon all the time. Please refer to the KDE wiki page for further information and setup instuctions.

... which matches my experience. Getting PA to work with KDE4 is somewhere on the spectrum from painful to impossible. And it doesn't get you away from dealing with the ALSA configuration.

with pulse, it's silent; without sound works

Posted Aug 26, 2010 13:02 UTC (Thu) by sebas (guest, #51660) [Link] (5 responses)

That is to say that even after a couple of months of fiddling with all kinds of configuration options and pulseaudio stuff, my sound was still hit and miss.

I much prefer spending a couple of minutes fixing an ALSA setup than

Luckily, since I switched to a distro that doesn't mandate the use of pulseaudio (openSUSE), my sound problems are simply *gone*.

Lennart's answer, when I inquired personally at a conference, was it's the buggy driver's business. The hardware in question was intel's HDA sound chip, likely the most common piece of sound hardware found in today's laptops.

My experience is as simple as: Without pulse it works, with pulse it doesn't. As much as the previous comments sound like flaming, they do match my experience.

If that's any indication of how problems with systemd are being dealt with, I'll rather not install it.

with pulse, it's silent; without sound works

Posted Aug 26, 2010 13:31 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

That it's an Intel HDA tells you nothing - the HDA spec is pretty much just a semi-defined bit of glue in front of a codec, and there's literally dozens of different codecs. Some of these are more spec-compliant than others and it's not uncommon for them to require chip-specific quirks. See source/pci/hda to get some idea of just how much complexity there is in what looks like a single chip.

with pulse, it's silent; without sound works

Posted Aug 26, 2010 14:00 UTC (Thu) by sebas (guest, #51660) [Link] (1 responses)

Ow, I'm convinced it's rather more complex than I am able to understand -- but that probably goes for the vast majority of the users. The gist is that without pulse it works, and with it, it simply doesn't. And that's also what the user will experience -- a very poor multimedia experience.

with pulse, it's silent; without sound works

Posted Aug 26, 2010 14:29 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

When you say "The user", you mean "A user with this specific codec". The majority of hda codecs work absolutely perfectly with pulse at this point, and it's usually not too difficult to fix the others. But the fact remains that this is the kernel failing to compensate for broken hardware, and while it may be reasonable to use this as a reason to say that Pulse shouldn't be the default it's unfair to blame the problem on Pulse itself.

with pulse, it's silent; without sound works

Posted Aug 27, 2010 17:12 UTC (Fri) by Trelane (subscriber, #56877) [Link]

It should perhaps also be mentioned that "codec" is a specific bit of jargon specific to the HDA spec (available on the intarwebs; this is how I know about these things, although it's been a while and I'd greatly appreciate supplements/corrections where appropriate).

The HDA spec has a tree structure, and one of the nodes is a "codec," referring to a virtualized interface to a block that Does Stuff. This is used to interesting effect with the sound card discussed at http://blogs.amd.com/home/2009/06/16/turning-it-up-to-11/, where the HDA protocol itself is used as a transport/formalization of a higher-level protocol used to drive a particularly novel consumer-level sound card.

IIRC. It's been a bit since I read the specs on this card and therefore also the HDA specs to understand Intel HDA as it was being used here. (Sadly, I never got enough hand-holding to get a driver up and running on ALSA and perhaps also lacked the motivation, not actually having hardware to play/test with.)

with pulse, it's silent; without sound works

Posted Aug 27, 2010 9:46 UTC (Fri) by buchanmilne (guest, #42315) [Link]

Luckily, since I switched to a distro that doesn't mandate the use of pulseaudio (openSUSE), my sound problems are simply *gone*.

So, now you aren't sure if it is different (newer/older) snd_hda_intel drivers, or PA.

On a distribution (Mandriva) which defaulted to PA, but allows very easy switching to straight ALSA, I found (about a year ago) by switching to ALSA that the problems I had with sound input on my laptop were not due to PA but the snd_hda_intel driver needing some tweaks for my hardware (in 2.6.27). Some point releases of 2.6.27 fixed and subsequently broke it again. In more recent kernels (2.6.31 and later) I haven't had these problems (although the mic did sometimes stop working after suspend, unloading and reloading snd_hda_intel fixed it - but I haven't seen this problem on 2.6.33 or later). Immediately after having isolated the problem as being the driver, I switched back to PA, and really don't have any issues (on 4 machines, including my media player which has 5.1 via SPDIF enabled from the XBMC settings).

My experience is as simple as: Without pulse it works, with pulse it doesn't

No, technically, your experience was "On one distro it didn't work, on the other it did, the one where it didn't work used PA, the one where it worked didn't", with undefined definitions of "it" and "work", and no clear identification of the cause besides association.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 7:41 UTC (Thu) by xav (guest, #18536) [Link] (5 responses)

That's strange, because I find that audio cards setup is now a breeze thanks to pulseaudio (one slider for volume, the rest is auto-guessed) whereas before it was a real mess of alsa pseudo-autoconfiguration which never worked anyway, coupled with googling and alsarc tweaking.
Anyway, for me pulse solved problems and didn't cause any.

But I'm not using Fedora, so I probably didn't have to endure the painful beta versions.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 11:54 UTC (Thu) by paulj (subscriber, #341) [Link] (4 responses)

The way volume auto-guessing works in PA is still majorly broken, particularly with multiple applications. I wish PA had an option to *leave my relative, per-app volumes the fsck alone* - but this is apparently a feature. Sigh.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 12:16 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

Flat volumes? That can be turned off

echo "flat-volumes = no" >> /etc/pulse/daemon.conf

Relogin. Although this is often a hardware specific bug in ALSA and should be reported.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 21:30 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

There are HDA codecs that are so broken that they can't set their *volume*?

(Do these things get any testing at all? How does Windows do it, and why can't we use the same technique?)

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 21:39 UTC (Thu) by Trelane (subscriber, #56877) [Link]

http://0pointer.de/blog/projects/decibel-data.html

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 21:56 UTC (Thu) by Trelane (subscriber, #56877) [Link]

http://msdn.microsoft.com/en-us/library/ff536251%28VS.85%29.aspx

http://msdn.microsoft.com/en-us/library/ff536191%28v=VS.85%29.aspx

It looks like, as with all shoddy Works-Fine-With-Windows hardware, the answer is one or more of:

In an INF file
In the driver itself
It doesn't do this at all

This is why vendors have to provide drivers for Windows so that stuff "Just Works"--someone worked around the bugs in software for Windows.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 7:48 UTC (Thu) by niner (subscriber, #26151) [Link] (7 responses)

Well, I for one am glad that PulseAudio finally moved Linux audio forward from the stone age it has so long been stuck in.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 16:47 UTC (Thu) by leoc (guest, #39773) [Link] (6 responses)

Same here. I think the issue with PulseAudio is that of all change: the people who have no problems don't say anything, while the people who do proclaim far and wide that the world is ending.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 17:42 UTC (Thu) by sfeam (subscriber, #2841) [Link] (4 responses)

"Change" is one thing. "Breaking existing setups without providing an escape route" is a bit different. The problem with PulseAudio is not so much that it doesn't work on all systems as that it's so intimately embedded into the desktop that you can't easily disable it on systems where it doesn't work.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 23:47 UTC (Thu) by bangert (subscriber, #28342) [Link] (3 responses)

the solution to a broken pulseaudio is not too turn it off then, but to fix the issue instead. it appears the problem is not pulseaudio but your audio driver, ie. you are barking up the wrong tree...

the reason why pulseaudio cant use your sound hardware is because it does way more than you ever have. this is the good thing and at the same time the reason why your desktop has started to depend on it so much.

Some questions that do 3d6 fire damage

Posted Aug 27, 2010 0:40 UTC (Fri) by sfeam (subscriber, #2841) [Link] (2 responses)

In my particular case, I believe I am barking up the right tree:-) The issues I have seen with PA do not involve problems with communication between PA and the hardware, they involve communication between PA and specific application programs (and/or several intervening layers like phonon or gstreamer). Earlier versions also had a recurring habit of chewing up gobs of CPU time for no apparent reason, but thankfully that seems to have been fixed.

I can comprehend the viewpoint that these (usually older) applications are obsolete and can be replaced by newer equivalents. But this is exactly the viewpoint that worries me, and I'm clearly not the only one. There had better be some compelling advantage to switching to a new component, be it PA or systemd, to justify the disadvantage of breaking the applications people are currently using. I hasten to add that I have no opinion on systemd yet, but certainly PA fails this test.

It's all very well to say that PA "does way more", but that "way more" is stuff that I never wanted in the first place. The capability of doing things I don't want does not compensate for doing a bad job at handling the things I use every day. I'll shut up now, because gripes about PulseAudio are relevant to systemd only to the extent they are examples of what can happen when the goals of the developer diverge from the goals of the end user.

Some questions that do 3d6 fire damage

Posted Aug 27, 2010 9:26 UTC (Fri) by bangert (subscriber, #28342) [Link] (1 responses)

is this your argument: do you want all of us to remain in the audio stoneage, because you use programs that are even older than that?

this is insane.

you can't require that lennart (or whoever wants to move things forward) stays backwards compatible with each and every use case in existance. with the amount of code being produced every single day, that would make progress impossible. just as new code is written, old code dies.

and, given most of the code we use is open, you are free to update any left behind component, if you so wish.

man, would i love it if somebody would modernize/update xfig ;-)

Some questions that do 3d6 fire damage

Posted Sep 3, 2010 18:21 UTC (Fri) by nix (subscriber, #2304) [Link]

you can't require that lennart (or whoever wants to move things forward) stays backwards compatible with each and every use case in existance.

The scary thing about pulseaudio is that modulo broken hardware, broken kernels (both alas common), or people doing things that just can't be virtualized in userspace (there are a few such with OSS and they break with aoss too, only ALSA's in-kernel OSS emulation helps), pulseaudio really does support almost everything. If there's a network protocol out there used for sound servers in more than a handful of boxes, PA seems to support it, and it's sufficiently modular that adding more is pretty easy.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 21:24 UTC (Thu) by ofeeley (guest, #36105) [Link]

PulseAudio has been a boon for me too. I found messing around with sound a complete pain for my simple needs which included occasionally plugging in/out a USB headset for VOIP. Works perfectly on 4 disparate desktops thanks to PulseAudio.

I suspect that the people raging about this are those that have a high level of expertise in audio configuration pre-PulseAudio and are understandably miffed that their investment is somewhat wasted now.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 6:36 UTC (Thu) by michich (guest, #17902) [Link]

systemd is compatible with SysV initscripts, so there's no need to convert all packages.

systemd comes with quite a good amount of manpages.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 10:20 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (3 responses)

We have a complete set of man pages.

Some questions that do 3d6 fire damage

Posted Aug 26, 2010 21:33 UTC (Thu) by nix (subscriber, #2304) [Link]

Quite so. That's one complaint I cannot make about anything you've written: unlike virtually all GNOMEish and KDEish stuff, it *has manpages* and they are *readable* and *accurate*.

Would that everyone else took the same care. Just because it's desktoppy and largely invisible doesn't mean it doesn't need docs: on the contrary, it means it needs *more*, because everyone uses it, and when it breaks and leaves someone stuck, the person stuck will likely not be a geek, and even if a geek would rather not dig into the docs for the desktop environment just to make $whatever work again dammit.

Some questions that do 3d6 fire damage

Posted Aug 27, 2010 20:37 UTC (Fri) by alankila (guest, #47141) [Link] (1 responses)

Lennart, I would like to add some audio DSP capabilities to PulseAudio. I might want a bit of input about that -- I tried sending you an email with some rubbish I had made a month or two ago, but you never responded.

I have since implemented this stuff into Android, and it's about to go live in CyanogenMod 6 that is going to be released, like, tonight. I'd like to see this code also on the Linux desktop. For reference, here's the application I built for Android:

http://bel.fi/~alankila/android-dsp/

I'd specifically need a few pointers about the good way to design this. I'm thinking about making a module that can be loaded into PulseAudio and which listens to dbus for configuration, and something like gnome-volume-control or such application could provide the GUI for settings and send these events over the dbus when it starts up. This would be a close equivalent to how I implemented it on Android.

Some questions that do 3d6 fire damage

Posted Aug 31, 2010 14:59 UTC (Tue) by aquasync (guest, #26654) [Link]

It would be very cool to have a system-wide dsp! Hope something similar makes it in to pulse audio one day.

Please...(again)...

Posted Aug 26, 2010 13:09 UTC (Thu) by corbet (editor, #1) [Link] (14 responses)

I would really like to get back to a place where we can discuss the technical issues without applying terms like "Mr. A**hat" to somebody who has contributed large amounts of code to our community (or to anybody else, for that matter). Can we agree that would make LWN a more pleasant and focused place for all of us?

(FWIW, pulse has worked fine for me for quite some time now. Systemd is also mostly working well now that I've typed the relevant rawhide-only incantations, though I do need to figure out why networking didn't come up on the last boot...)

Please...(again)...

Posted Aug 26, 2010 14:33 UTC (Thu) by mmcgrath (guest, #44906) [Link] (11 responses)

> I would really like to get back to a place where we can discuss the technical issues without applying terms like "Mr. A**hat"

Surely calling people names isn't good, but I share his frustration. No one in Fedora ever has the "should" conversation. It's always technical discussions. So everything that's done gets in. It's both a strength and weakness of Fedora. This has been posted, I'll post it again because IMHO this is exactly what is going on here.

http://home.comcast.net/~tomhorsley/wisdom/braindump/oss-...

Please...(again)...

Posted Aug 26, 2010 21:57 UTC (Thu) by marcH (subscriber, #57642) [Link]

> This has been posted, I'll post it again because IMHO this is exactly what is going on here.

This is both hilarious and quite accurate. It is only missing the last two stages.

First the Developer becomes slightly bored and not interested in re-implementing all the useful workarounds that the original piece of software featured in order to cope with the real world. Because it is so much better to fix the real world instead!

And then the final stage where the Developer becomes really bored, realizing that he has solved all the interesting problems. He then jumps on his white horse and rides to new pastures, to other crucially important pieces to entirely re-design and re-implement. It is very urgent to free users from these other broken pieces since they have been suffering from them since a few decades now! Average, boring people like you and me will be good enough for the mundane task of maintaining the current project.

Please...(again)...

Posted Aug 27, 2010 9:31 UTC (Fri) by cmccabe (guest, #60281) [Link] (9 responses)

That's hilarious. I love the Douglas Adams reference.

Seriously, though, I can understand Lennart's point of view here. With pulseaudio and systemd, he has created code that is better than what came before it. But the problem with straightening out the crooked things is that it causes a lot of short-term pain.

What I've found in the past is that when you make a big change to something, you spend more time handling "transition issues" than you do actually architecting the new solution. Usually you have provide compatibility and "legacy" modes, do extensive testing, and fix a lot of problems that have absolutely nothing to do with anything you've written, but which just happen to crop up when your new solution is place.

As you can probably guess, handling transition issues is *not* the fun part. It's the boring but difficult part. There is often a temptation to skip this part-- just like there is a temptation to put off writing good documentation. But you absolutely must not do this, or else you will make a lot of enemies.

The worst part is that if something breaks, you will be the bad guy, no matter whose fault the problem actually is. It could be a bug in the python interpreter that is being exposed by your kernel change-- and you will get the blame. The only response is to be professional about it-- to offer compatibility modes or workarounds, and get to the root cause of the problem. At some point, this is just the fate of all engineers. You never think about the guy who built your highway onramp-- until something bad happens.

Lennart's flippant response about the "noauto" change suggests that he still has to learn how to really do this right. Hopefully he'll get the hang of it. And then we can finish building that hyperspace bypass. After all, the plans *have* been on display for 50 of your earth years.

Please...(again)...

Posted Aug 27, 2010 10:46 UTC (Fri) by marcH (subscriber, #57642) [Link] (8 responses)

> As you can probably guess, handling transition issues is *not* the fun part. It's the boring but difficult part. [..] But you absolutely must not do this, or else you will make a lot of enemies.

... especially when you replace something inferior, but core and WORKING. You can take whatever risks you want with brand new features, but regressions? Never, ever. Even if you put an extraordinary amount of effort in implementing the best piece of software ever, people will hate you for the tiniest regressions. And you deserve it. Divas seem to forget too easily that normal people have a day job: make the system JUST WORK whatever it takes and no matter how ugly it is in the end.

PS: yeah I know, I should use RedHat. You can save your post.

Please...(again)...

Posted Aug 27, 2010 12:59 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

I would say that "work, just" is more accurate than "just work".

Please...(again)...

Posted Aug 27, 2010 13:20 UTC (Fri) by mmcgrath (guest, #44906) [Link] (6 responses)

> ... especially when you replace something inferior, but core and WORKING.

I would disagree that the current scripts are inferior. People in our field are far to quick to dismiss the value of simplicity. systemd has several more features, I'll certainly admit that. The older / current method was great though. You'd think there was other lower hanging fruit that required attention.

Please...(again)...

Posted Aug 27, 2010 13:30 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

Obviously, people work on what catches their attention. For a hobbyist project, we can't expect anything more. Why complain about that?

Please...(again)...

Posted Aug 27, 2010 13:48 UTC (Fri) by mmcgrath (guest, #44906) [Link] (3 responses)

I can't think of a worse way to design a system whole then what you just described. That's why I complain.

Please...(again)...

Posted Aug 27, 2010 13:51 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I don't see what you are talking about. Much of what you use on a regular basis was designed in the same way driven by self interest and tackling problems they are interested in. It might not be some low hanging fruit that you want to tackle but obviously different people have different interests. If you want to tackle a different problem, go ahead and do that.

Please...(again)...

Posted Aug 27, 2010 14:00 UTC (Fri) by mmcgrath (guest, #44906) [Link] (1 responses)

> Much of what you use on a regular basis was designed in the same way driven by self interest and tackling problems they are interested in.

I agree, and relative quality difference compared to what is available around it has grown wider and wider. The Linux desktop is a wasteland of disjointed features and applications that only sort of work together written by groups that have far more reach then manpower and no central design other then freedom. We've made almost no headway on the desktop in the last _10_ years. We're still sitting at 1%. I'm tired of playing this tune, I need to just accept that.

But now I'm seeing these crazy disjointed desktop bits make their way into core system parts (note: NetworkManager didn't replace network scripts for a reason in RHEL6). So now I worry that where we have made great headway (on the server) is now being put at risk by these silly disjointed 'features'.

Please...(again)...

Posted Aug 27, 2010 14:10 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

And what is the proposed solution here? As long as you are not paying people to work on what you want, it is always going to be a distributed set of components with no central design or authority. It is sort of like evolution, messy and inefficient but noone else has proposed a better way to tackle it without throwing away a lot of money on something that might not pay dividends even years later.

Please...(again)...

Posted Aug 29, 2010 7:31 UTC (Sun) by cmccabe (guest, #60281) [Link]

> I would disagree that the current scripts are inferior. People in our
> field are far to quick to dismiss the value of simplicity. systemd has
> several more features, I'll certainly admit that. The older / current
> method was great though. You'd think there was other lower hanging fruit
> that required attention.

I don't think systemV init scripts are really simpler. They just push the complexity into other parts of the system.

Since they can't represent dependency information, you either have to have a slow boot time or parallelize things by hand. I have had to manually parallelize sysV scripts before, and it's not fun. The system should know what depends on what.

Since sysV init scripts only happen at boot time, or when someone changes the runlevel, you have to have a separate mechanism to handle the addition of hardware at runtime. Sometimes adding that hardware requires starting a daemon-- for example, when it's bluetooth hardware.

SystemD also subsumes portreserve and xinetd. In theory systemD could also handle restarting daemons, although I don't know if that has been implemented yet.

Please...(again)...

Posted Sep 2, 2010 3:22 UTC (Thu) by filteredperception (guest, #5692) [Link] (1 responses)

> I would really like to get back to a place where we can discuss the technical issues without applying terms like "Mr. A**hat" to somebody who has contributed large amounts of code to our community (or to anybody else, for that matter). Can we agree that would make LWN a more pleasant and focused place for all of us?

As someone who succumbed to PA bug rage on bugzilla, I feel a 100+ comment article is a pretty good place to add an extra apology. But you have to understand, that the bug in question, literally involved *painful*, possibly health-damaging audio making its way to my earbuds for the portion of a second it took my brain to rip the things out of my ears. Until that experience, it had never entered my mind that a distro bug was literally a health hazard. In fact, since my bug-rage-rant, I've come to the believe that the intel sound hardware, or perhaps even the sony earbud hardware, are at fault for allowing a software bug to be potentially seriously health damaging. But as many have mentioned, I ran into LP's rather dismissive attitude, which really, in that reactionary timeperiod, rubbed me the wrong way.

I don't even recall how PA was pushed onto fedora, but if there was any way it could have been done, that it could have reduced the number of people whose audio hit __400%__ due to a rhythmbox/pa-flat-volumes bug _instantaneously_, then it really, really, IMHO would have been worth it.

And I have to admit just a little bit of flaring anger at the (ad hominem attack redacted) idea that systemd should be default on in the first release of fedora that it lands in. _Especially_ when it is as easy to leave default off, but turn on as described in this article. I mean, we are talking about such a core piece of the distro infrastructure. Something that decades upon decades of sysadmins have painstakingly all familiarized themselves with. I mean, <seth and amy voice>Really?!?</>, you can't phase it in as default off for one release? <>Really?!?</>.

Honestly I am precisely one of those people being driven away from fedora. I like my bleeding edge stuff, but after suffering the last several releases, I can not tell you how much I look forward to CentOS6, and just saying- go ahead fedora folks, have all the crazy fun you want, just without me, I'll catch up with you in a decade when CentOS7 comes out.

Anyway, I wish systemd the best of luck, and just hope RH facilites COS6 in a timely enough manner that I don't have to touch it for many many years, because it's not solving any problem I knew I had.

Please...(again)...

Posted Sep 3, 2010 15:03 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

My gut reaction is that some parts of the system are so "core" that if you don't trust a candidate for one of those parts enough to make it the default, you shouldn't even make it a conveniently visible option in anything you're going to call a "release".

PID 1 is one of those parts.