[RFC] disable OSS sound support

[Dan Williams]

On Thu, 2009-02-12 at 23:55 -0500, Jon Masters wrote:
> Ok...before I get into a dialog know that I don't /really/ care about
> this one way or the other, so whatever collective wisdom decides is
> cool.../but/...
> 
> On Thu, 2009-02-12 at 22:09 -0500, Warren Togami wrote:
> > Jon Masters wrote:
> > > On Fri, 2009-02-06 at 18:44 +0000, Bastien Nocera wrote:
> > > 
> > >>> So my proposal is: Disable this options in rawhide (and those F11) and
> > >>> add a note to the release notes that people can use padsp/aoss to make
> > >>> oss apps working.
> 
> > > As I pointed out on IRC, it's just a modprobe rule loading these OSS
> > > modules, so removing them from the kernel is a heavyweight solution to
> > > your problem. You could trivially add a rule to remove them or change
> > > the existing ones.
> 
> As I said before, this is just a modprobe rule loading the OSS modules.
> I'll probably remove it upstream and in Rawhide but I really don't see
> why you guys are so nuts about killing it. Very little uses OSS these
> days, but there is software out there that still relies on it (until
> there's a direct replacement without padsp hacks) and works well. You
> seem to be arguing that a user /might/ elect to start some software we
> don't like, so we should ban that activity.
> 
> > https://bugzilla.redhat.com/show_bug.cgi?id=472741#c9
> > Let us please go ahead with my proposed simple solution.
> 
> How about we just leave it as it is until there's a direct OSS
> replacement? I look at that bug and I see "er, someone had a problem
> with some OSS software" being taken as "let's all go crazy". If there
> were 50 people tracking it who cared then cool, but there are 5, and all
> of those are @redhat.com anyway.

If there's no technical replacement possible?  OSS makes some
assumptions that simply can't really be made anymore.  The only way to
put pressure on those apps to fix their code (and start using ALSA) is
to pull the support for OSS.  Otherwise people will just go on using the
apps and nothing will ever get better.  Same sort of thing with V4L1;
it's a horribly, horribly broken API that simply does not meet the needs
of todays applications; if it sticks around forever then there's no
incentive to update V4L1 stuff to use V4L2.

Dan