Re: Forced obsolescence in Linux

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Gerard Snitselaar
Date:  
To: Main PLUG discussion list
Subject: Re: Forced obsolescence in Linux
It is fairly common for kernel subsystems to undergo serious changes
between major kernel versions. If you do a search you will see that
drivers had to be changed between 2.4 and 2.6:

http://linuxdevices.com/articles/AT4389927951.html


The internals of a driver might not need to change, but the way it
interfaces with the rest of the kernel could very well need it.

It seems that the sb16 is supported by ALSA:

http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs

You probably just need to compile the driver for the kernel.




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 -
> To subscribe, unsubscribe, or to change you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>


---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss