Forced obsolescence in Linux

Tue Feb 28 00:04:12 MST 2006

On FC4 this is what I get from modinfo for snd-sb16 :

snits at newton:/home/snits/src/linux-2.6.15.4/sound=>modinfo snd-sb16
filename:       /lib/modules/2.6.15-1.1831_FC4/kernel/sound/isa/sb/snd-sb16.ko
author:         Jaroslav Kysela <perex at suse.cz>
license:        GPL
description:    Sound Blaster 16
vermagic:       2.6.15-1.1831_FC4 686 REGPARM 4KSTACKS gcc-4.0
depends:
snd-sb-common,snd-opl3-lib,snd,snd-mpu401-uart,snd-sb16-dsp,snd-sb16-csp
alias:          pnp:cCTL0024dCTL0031*
alias:          pnp:cCTL0025dCTL0031*
alias:          pnp:cCTL0026dCTL0031*
alias:          pnp:cCTL0027dCTL0031*
alias:          pnp:cCTL0028dCTL0031*
alias:          pnp:cCTL0029dCTL0031*
alias:          pnp:cCTL002adCTL0031*
alias:          pnp:cCTL002bdCTL0031*
alias:          pnp:cCTL002cdCTL0031*
alias:          pnp:cCTL0051dCTL0001*
alias:          pnp:cCTL0070dCTL0001*
alias:          pnp:cCTL0080dCTL0041*
alias:          pnp:cCTL0086dCTL0041*
alias:          pnp:cCTL00f0dCTL0043*
alias:          pnp:ctBA03b0dPNPb003*
srcversion:     6E0689729B47273884520A3
parm:           csp:ASP/CSP chip support. (array of int)
parm:           mic_agc:Mic Auto-Gain-Control switch. (array of int)
parm:           dma16:16-bit DMA # for SB16 driver. (array of int)
parm:           dma8:8-bit DMA # for SB16 driver. (array of int)
parm:           irq:IRQ # for SB16 driver. (array of int)
parm:           fm_port:FM port # for SB16 PnP driver. (array of long)
parm:           mpu_port:MPU-401 port # for SB16 driver. (array of long)
parm:           port:Port # for SB16 driver. (array of long)
parm:           isapnp:PnP detection for specified soundcard. (array of
bool)
parm:           enable:Enable SoundBlaster 16 soundcard. (array of bool)
parm:           id:ID string for SoundBlaster 16 soundcard. (array of
charp)
parm:           index:Index value for SoundBlaster 16 soundcard. (array
of int)

On Mon, 2006-02-27 at 20:06 -0700, Victor Odhner wrote:
> Joshua Zeidner wrote:
>  > First off, Microsoft is making that claim.
> 
> That doesn't make it false.  I made an off-handed comment to the
> Slashdot post that was contradicting Microsoft's claims.  That
> post pointed to a very brief article that just said, "I found some
> distros that work OK on old stuff."  But my complaint was based
> on my own experience, having gone through a number of modern
> distros that would not talk to this sound card, and said annoying
> things such as "No soundcards detected".  Gimme a break!  Go
> to a little trouble, you can see that *something* is there, even if
> you can't make a noise with it.
> 
> Oh and by the way, XP can run this old 16-bit sound blaster.
> So there you go.  (Never mind that I can't resurrect his XP setup
> because I don't have the original disk or the key.  Reminded me
> why Stallman rebelled in the first place!  But I digress.... )
> 
> Siri Amrit Kaur wrote:
>  > Have you tried Vector or one of the distros that's optimized for
>  > older hardware?  I think Vector and Slackware still use an older
>  > 2.4.* kernel by default. Maybe it would have drivers . . .
> 
> Similarly, Dennis Kibbe wrote:
>  > I know PLUGers that have installed Slackware on old 486
>  > ThinkPads. ... Many distros (like Slackware, for instance)
>  > have versions going back to release 1.0 still on the servers.
> 
> I don't want a different kernel, I want to add a driver.
> Like I said, I am not interested in distro shopping.  This distro
> does most of what I want done.  The current kernel is set up to
> have drivers added, and the driver is the only change I want to
> make.  Why regress to an older kernel, with bugs that have been
> fixed?  Why can't I just plug in a binary driver, as with Windows?
> 
> Suppose I tried an older distro that worked fine with the sound
> card, but complained that it would not read my USB thumb drive.
> I'm afraid I would have heard the same thing:  Try another distro,
> or upgrade the kernel to get that support.  My complaint is that
> upgrading a kernel *loses* the support for the sound card.
> Ya can't win fer losing.
> 
> ... Which takes us to Kevin Brown, who wrote:
>  > at some point the devs do have to stop trying to keep lesser used
>  > drivers up to date with a newer way of doing things.
> 
> Are you saying the older drivers don't plug in the same way that the
> newer ones do?  Why would they invalidate an API that was working?
> Note, Windows XP did a lot of that, for security reasons; but those
> were old drivers that required dangerous privileges.  I would have
> thought Linux drivers would be safer from the start.
> 
> My lack of this knowledge is probably the reason for my annoyance.
> I'm a developer myself, and I understand that it's hard to make an
> omelet without breaking some eggs.  But when we use "insmod", that
> takes the specified driver and links it into the kernel, presumably
> using a somewhat generalized API.  Right?  Does each driver that
> the kernel's willing to accept require some additional ugliness in the
> kernel, creating a cost that has to be limited by banning some old
> drivers?
> 
> I'm also assuming that the drivers consist of rather primitive and
> self-contained code, so that they do not need to interface with the
> system's standard libraries.  Even if they did, hopefully those APIs
> would remain valid.
> 
> I'm willing to learn . . .
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change  you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> 