On Fri, 2009-02-06 at 16:03 +0100, drago01 wrote: > Currently we have: > > CONFIG_SOUND_OSS_CORE=y > CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=m > CONFIG_SND_PCM_OSS=m > CONFIG_SND_PCM_OSS_PLUGINS=y > CONFIG_SND_SEQUENCER_OSS=y > > this cause the OSS compat modules to be loaded on every system (that > has sound), even thought most people do not require this (pure oss > apps aren't used that often). See also: https://bugzilla.redhat.com/show_bug.cgi?id=472741 And the related discussion on this list ("F11: OSS and pulseaudio conflict" in November). > If its really needed we have aoss and padsp to run such apps for > people that really needs them, without having this modules loaded on > every system running fedora. > > Besides apps that just open /dev/dsp are unlikely to "just work" in a > default setup due to pulseaudio. > > 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. Completely agree.

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. > Completely agree. 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. Jon.

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.

Jon, I would argue that this should likely be a Fedora local change, since it's really up to the individual distro to make sure all shipped software is up to date...

Warren Togami wrote: > 1) Keep the OSS kernel modules. > 2) alsa-plugins-pulseaudio ships /etc/modprobe.d/blacklist-oss-sound, > thereby preventing loading of these kernel modules and interfering with > pulseaudio daemon. > 3) If the user wants to use an OSS sound application they can use padsp > manually. > 4) Native OSS comes back if the user uninstalls alsa-plugins-pulseaudio, > which also makes it so nothing uses pulseaudio for sound output. The problem with that is that they will continue saying "PulseAudio broke my apps". If we just remove OSS sound support entirely, they won't have a reason to blame PulseAudio anymore.

On Fri, 2009-02-13 at 10:22 +0100, Kevin Kofler wrote: > Warren Togami wrote: > > 1) Keep the OSS kernel modules. > > 2) alsa-plugins-pulseaudio ships /etc/modprobe.d/blacklist-oss-sound, > > thereby preventing loading of these kernel modules and interfering with > > pulseaudio daemon. > > 3) If the user wants to use an OSS sound application they can use padsp > > manually. > > 4) Native OSS comes back if the user uninstalls alsa-plugins-pulseaudio, > > which also makes it so nothing uses pulseaudio for sound output. > > The problem with that is that they will continue saying "PulseAudio broke my > apps". If we just remove OSS sound support entirely, they won't have a > reason to blame PulseAudio anymore. I love that logic. And by love, I mean I really don't. PulseAudio is great, but there is a use case for OSS without PA in the loop still.

And I fail to see why breaking those apps is a win - if you're that worried, pop up a notification to alert the user that something else has grabbed the audio device away.

Skype? I use skype-static, which is the only way of having sound on both speakers.

I think we should enumerate which applications still use oss before killing it. Ordinary people are much more loyal to applications than distributions.

Le Lun 16 février 2009 10:49, Bastien Nocera a écrit : > Which apps? And please don't tell me "internal apps that I've never > seen > actually running and that nobody told me about". > > OSS is dead on Linux, let's get rid of it, and see who actually cares. > My guess is close to absolutely no one. OTOH as long as PA has a longlist of hardware it can't drive, Alsa without PA is necessary.

Please bring gnome-mixer back :p -- Nicolas Mailhot

On Mon, 2009-02-16 at 09:49 +0000, Bastien Nocera wrote: > On Fri, 2009-02-13 at 10:16 -0500, Jon Masters wrote: > > On Fri, 2009-02-13 at 10:22 +0100, Kevin Kofler wrote: > > > Warren Togami wrote: > > > The problem with that is that they will continue saying "PulseAudio broke my > > > apps". If we just remove OSS sound support entirely, they won't have a > > > reason to blame PulseAudio anymore. > > > > I love that logic. And by love, I mean I really don't. PulseAudio is > > great, but there is a use case for OSS without PA in the loop still. > > Where is there still a need for it? Apps that are still using OSS had > about 8 years to switch to ALSA, why do you think they'd be doing it > now? I don't. That's the shocking thing about ABIs between kernel and userspace - we kind of guarantee them not to break randomly. I've got plenty of applications that don't use ALSA and never will (some of them from great Linux companies long since no longer with us) and yet it would be nice if we didn't just stop them from working on a whim. I'd much prefer to replace OSS support with e.g. the CUSE solution in a future Fedora instead. But like I said, I don't /really/ care that much. This is kind of a "won't somebody please think of the children" response I suppose. > > And > > I fail to see why breaking those apps is a win - if you're that worried, > > pop up a notification to alert the user that something else has grabbed > > the audio device away. > > Which apps? And please don't tell me "internal apps that I've never seen > actually running and that nobody told me about". Old Linux games, lots of commercial stuff. Jon. -- fedora-devel-list mailing list fedora-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

King InuYasha wrote: > Quite a few of the older Loki games use OSS > Do any of those Loki games work on modern distros? It seems glibc changes made it impossible long ago. Warren -- fedora-devel-list mailing list fedora-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jon Masters wrote: > some of them from great Linux companies long since no longer with us And that's exactly why proprietary software is bad. Once the company goes belly up, nobody can fix it anymore. (And yes, software which uses obsolete APIs is broken.)

Jon Masters wrote: > But, you know, it's their choice to write proprietary software using > ABIs that were promised to them to be stable at the time. GNU/Linux ABIs are not stable forever nor should they be.

Olivier Galibert (galibert(a)pobox.com) said: > stable, but the things on top of it...). Dumping something as > cost-less as OSS for cosmetic reasons just means you don't care about > compatibility or users in general. Which wouldn't be a first for > Fedora, mind you. Notwithstanding whether or not it should be removed, an ABI feature that *breaks* other applications when used can't really be described as 'cost-less'.

Olivier Galibert wrote: > The kernel ABIs are stable forever and should be. Nonsense. Try running an a.out executable on a current GNU/Linux.

Olivier Galibert (galibert(a)pobox.com) said: > > Nonsense. Try running an a.out executable on a current GNU/Linux. > > CONFIG_HAVE_AOUT and CONFIG_IA32_AOUT are still there in the kernel > configuration. Your point is? ... and we disable them. So, why is disabling them OK, and disabling OSS not? Bill -- fedora-devel-list mailing list fedora-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

King InuYasha wrote: > Because, a.out format is just a binary format, which is relatively easy to > replace, while OSS is something that deals with hardware. In some cases > (rare as it is), ALSA just doesn't work while OSS _does_ work. A case in > point, one of my desktops has a VIA board, which breaks horribly in ALSA > with its integrated audio. However, OSS works fine with it. PulseAudio can > output to OSS as well as ALSA, right? In cases like this, I usually > default PulseAudio to the OSS sink instead of the ALSA one. ALSA isn't the > end all sink solution. If we want to disable it, we need to be certain > that everything is on par with OSS or better. ALSA just isn't there yet, > sorry people.... The "OSS" in current Fedora kernels is not OSS at all, it's ALSA's OSS emulation. So I don't see how it would work any better than ALSA itself does. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

King InuYasha wrote: Because, a.out format is just a binary format, which is relatively easy to replace, while OSS is something that deals with hardware. In some cases (rare as it is), ALSA just doesn't work while OSS _does_ work. A case in point, one of my desktops has a VIA board, which breaks horribly in ALSA with its integrated audio. However, OSS works fine with it. PulseAudio can output to OSS as well as ALSA, right? In cases like this, I usually default PulseAudio to the OSS sink instead of the ALSA one. ALSA isn't the end all sink solution. If we want to disable it, we need to be certain that everything is on par with OSS or better. ALSA just isn't there yet, sorry people.... What percentage (if any) of Fedora users actually *USE* hardware that requires such archaic code? This same blasted discussion (obsolete or not?) seems to come up every damn year... and it's getting really fucking old. If we must lose 5% to keep the other 95%... I say drop the 5% like hot potatoes. What's the point in carrying legacy cruft that should have died before 64bit came out? What's the point in carrying code for machines only the biggest of geeks even bother to look at? I can, somewhat, understand still supporting Pentium 3 (and up) era machines... but, quite frankly, anyone who still uses older machines (older than P3) is either ancient themselves... or in the group of insane geeks (of whom, btw,* I am a member*) who, most likely, know how to support their old crap. There are plenty of other distros out there whose GOAL it is to support such archaic machines... but a distro with the stated GOAL of providing a testbed for the latest and greatest software (and/or being a center of development)... should not even *ATTEMPT *to carry such cruft. You people are utter fools to think you can support both. Lyos Gemini Norezel -- fedora-devel-list mailing list fedora-devel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list

Olivier Galibert wrote: > CONFIG_HAVE_AOUT and CONFIG_IA32_AOUT are still there in the kernel > configuration. Your point is? No reasonable distro still enables them.

Which apps? And please don't tell me "internal apps that I've never seen actually running and that nobody told me about".