Re: [Bug 623] New: Volume not remembered.

[Martin J. Bligh]

>> You turn it off once, and your distro keeps it that way. Doesn't seem
>> that onerous to me. 
> 
> Okay, so now your distribution is aware of this configuration
> issue.

Can be. But does something sensible without it.
 
>> Indeed. Initial impression of people upgrading a kernel from 2.4 to 2.5/6
>> is that "sound doesn't work in 2.5/6". Not good.
> 
> ... but now it isn't. What gives ?

Not sure what you mean. Load kernel, load xmms. hit play. Sound comes out.
Goodness.
 
> (Besides, you've just added the "silent" flag as another config item
> besides the volume setting, using different interfaces, different
> permissions, etc.)

Yeah. But the default options now do something non-confusing.
 
>> And all for the fact that when the user sets up the system, it just
>> works. With sensible defaults. Instead of being an elitist piece of
>> crap that only l33t g33ks can use.
> 
> Fine. But this discussion isn't about the end-user experience,
> but about where a certain parameter should be set, and what its
> transient default value should be.

Umm. This discussion is exactly about the end-user experience.
And it's not a transient default ... it's the initial default.

> Unexperienced users will just install a set of packages to upgrade
> to a new kernel. So this change can just be included in one of
> these upgrades. No superhuman effort needed.

So we can fix it in userspace, and decided a sensible non-zero default
there, but are somehow incapable of doing that *inside* the kernel? Sorry,
I don't buy that. 

There is a middle ground between "clueless newbie" and "geek who spends
their whole life configuring Linux, and is happy to change 2000 settings on
every install" ... something like "person who just wants to get on with it,
and not fiddle endlessly with things that should just work".
 
> As far as those are concerned who painstakingly build their own
> kernel, update the things listed in Documentation/Changes, avoid
> suble traps like CONFIG_SERIO_I8042, don't get confused by needing
> new module utilities, etc., I'm fairly confident that they'll
> consider setting the volume a rather minor challenge.
> 
> And you could even take the sting out of this one by adding an
> appropriate warning to Documentation/Changes. That's a about all
> the kernel-side support this issue deserves.

The old "document the bugs" arguement. I've been there before - Dynix/PTX.
We ended up with 1000 pages of utter crap for users to wade through as
"release notes". I got into the habit of taking a printed out copy to
meetings and whenever anyone uttered the phrase "but it's documented in the
release notes" I could thump the monster down on the table and say "find
it". They never could by the end of the meeting.

Bugs should be fixed, not documented.

M.