Slashdot Mirror
Linux Support Fades For 3Dfx Voodoo, Rage 128, VIA
An anonymous reader writes "The developers behind the Mesa 3D graphics library, which provides the default graphics driver support for most hardware on Linux (and BSD/Solaris), has ended their support for older hardware. Being removed from Mesa (and therefore versions of Linux distributions) is support for hardware like the 3Dfx Voodoo, Intel i810, ATI Rage, and S3 Savage graphics processors. Also drivers being dropped were for Matrox and VIA graphics. Mesa developers also decided it's time to end support for the BeOS operating system. Dropping this code lowered the developers' responsibility by some 100k L.O.C., so maybe we will see GL3 support and OpenCL in Linux a bit sooner."
I agree, but I'd love to see someone (with time, experience, and more knowledge than I) take it a step further: A Linux distro to work on ancient machines, with the latest feasible versions of software.
When I volunteered in Africa in 2009, one of my projects was to set up a computer lab, populated with donated machines. These computers were old. The newest one was manufactured in 2003. The oldest was 1997. I ended up installing Ubuntu and Edubuntu, then stripped down the core as much as I could while still keeping things clean. The machines still take several minutes to boot fully.
What I'd love would be a distro designed for just such situations. On install, it would determine what kind of hardware you have available, and only install things that will work well. Support for really old hardware would be patched in for the distro, probably with only major bugs receiving repair attention. If a package isn't likely to run well on your system, it will alert you before installing.
You do not have a moral or legal right to do absolutely anything you want.
Because if it hasn't been changed in 7 years, then chances are that nobody really knows the code. Consequently nobody is checking it nor is anybody likely to be paying attention to any breakage which might occur if they change the infrastructure and ultimately it's one more area in which a security vulnerability could pop into existence when somebody changes some other code.
Having essentially dead code in a project isn't a wise idea in most cases. But beyond that it's extra bandwidth that's not necessary for nearly everybody.
Code that was mostly unmaintained and didn't receive new feature support work in years.
Code that works doesn't need new features.