This shows the importance of having good quality free software drivers. It is comforting to know that as long as the card runs and I have boards that have PCI-Express slots I can still use my Radeon HD 4670 well down the line. Not to mention all of those R100 and R200 AGP cards I still have about the place.
Also, for what it is worth, although he is not using Linux on it my brother still has a Rage in one of his machines.
As for arguments (some of which people have already given):
1) You aren't paying them, you don't get to say what they do with their time. I don't think you understand how open source works; if you were able to forbid this person from generating a 2000 line patch for Rage128, that DOES NOT mean that he would have made 2000 lines of patches for other projects.
2) In general, I see no reason to drop support for older hardware just because it's old. The rage 128 actually has good enough performance for a quite pleasant desktop experience. This isn't Windows we are talking here, it's just not the Linux way to randomly drop support for older hardware just because.
3) RageXL is based on an even older chip (ATI Mach64), and servers were made with it until at least 2006. The Rage 128-based Mobility M3 and M4 were used through at least 2004, and perhaps more recently. If you want to proclaim a chip as being old and useless, for that purpose it doesn't matter that R128 was *introduced* 14 years ago, what matters is when it went off the market.
Howdy. First post here and my (probably unwelcome) .02 regarding "pointless."
One man's manure is another man's fertilizer.
As someone with ambitions of saving dated hardware from the trash heap and putting it into the hands of young people who otherwise would have nothing, I would classify the the work of Mr. Behan and anyone else supporting dated hardware as invaluable rather than pointless. Further, if a machine is on line and being actively used by young people thanks to open source developers vs. being in the trash heap, I fail to see how that could NOT help advance Linux.
Just my opinion of course.
Off topic - Could someone help direct a noob?
I would like to be able to help with testing efforts for Mr. Behan's exa patch and others, but keep searching my way to confusion. I think "Git For Dummies" is the equivalent of an oxymoron. I don't think I really need GIT. I couldn't code my way out of a barn. Could someone point out search terms that would lead me to the skill set (and any prerequisites) that would allow me to test patches found in GIT? My current skill set doesn't go much beyond installing Debian packages.
Thank in advance.
Are you familiar with any form of version control (e.g. subversion)? If you are familiar with subversion or CVS then I strongly recommend "HgInit" - it's written with mercurial in mind but the ideas are basically the same as git (just ignore the specific commands given, since they aren't necessarily the same). It's written by the guy that wrote Joel on Software, which is an invaluable resource. It helped me get my head from subversion-thinking to git-thinking.
If you're not familiar with version control systems, well, I first learned about subversion and found the ideas behind it relatively easy to understand as it is a bit simpler than git, so I would suggest that as a starting point (naturally others may disagree on this).
You can donload the kernel source directly from http://www.kernel.org/ but the grate thing about using git is that you have an easy way of keeping the source up todate and apply patches. All the commands you need to know to get basic use of git is clone, apply and pull.
then all you would have to do to update the source isCode:
git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
And to apply the patch you runCode:
git apply the_patch_file.patch
archibald and AJenbo:
I knew was asking questions well beyond my current skill set, but now I think I have a clear grip on what "it" is I need to learn. Thank you!
PS: Sorry for straying off topic.