Debian Dropping A Number Of Old Linux Drivers Is Angering Vintage Hardware Users

[geearf]

I think it's important for some distributions to keep old hardware functional, but I doubt we need all distributions to do so.
Having written that, I always viewed, I guess wrongly, Debian as such distribution.

If the current maintainers don't want to do so, well let the people outraged do it or fund someone to, that should please everyone (but the ones enjoying only free work for them of course)

[oiaohm]

I think it's important for some distributions to keep old hardware functional, but I doubt we need all distributions to do so.
Having written that, I always viewed, I guess wrongly, Debian as such distribution.

Debian snapshot system will keep the existing support around for basically ever.

There comes a line in the sand problem.

The old drivers being removed are all "User Mode Setting"(UMS) drivers. These required the X11 server to run as root so any security fault in the X11 server is made way worse by this. The newer "Kernel Mode Setting"(KMS) drivers don't require X11 server to run as root and also can be used by Wayland compositors..

So we are to the point that someone need to step up with those old drivers and write new drivers to support the old hardware or the old hardware has to go out of usage because keeping existing old drivers past this point no longer makes sense.

Please note X11 conference 2 years ago said at some point UMS drivers were going to cease support at some point as they are only in basic maintenance mode not promised to work any more and distributions should start the process of not including them any more.

So everyone had a 2 years head up on this. No one has stepped up to update those UMS drivers to KMS to get into the supported driver pile.

[ehansin]

That's assuming that the original/older distro that ran on that hardware is still available somewhere.

When I started looking into getting Linux running on my 25-year old Alpha, I would've been happy to install Debian and call it a day. Debian 5 (lenny) is the last version that had Alpha support. It was EOL'd back in 2012 and the repositories have been taken offline. Even if I wanted to install it (which I did), I can't, since the repositories no longer exist.

So I grabbed Gentoo and started compiling a fully modern GNU/Linux stack for that machine (distcc and a cross-compiler to my 16-thread Ryzen made this less terrible).

Point taken, it would need the repos around, or just a snapshot of where things ended up, archived somewhere. I did think of that a little, but didn't go there. I would think it would not be hard. but maybe there is a lot of storage, I don't know.

[geearf]

Debian snapshot system will keep the existing support around for basically ever.

There comes a line in the sand problem.

The old drivers being removed are all "User Mode Setting"(UMS) drivers. These required the X11 server to run as root so any security fault in the X11 server is made way worse by this. The newer "Kernel Mode Setting"(KMS) drivers don't require X11 server to run as root and also can be used by Wayland compositors..

So we are to the point that someone need to step up with those old drivers and write new drivers to support the old hardware or the old hardware has to go out of usage because keeping existing old drivers past this point no longer makes sense.

Please note X11 conference 2 years ago said at some point UMS drivers were going to cease support at some point as they are only in basic maintenance mode not promised to work any more and distributions should start the process of not including them any more.

So everyone had a 2 years head up on this. No one has stepped up to update those UMS drivers to KMS to get into the supported driver pile.

Oh I did not know they were UMS drivers, yeah that makes more sense.

Thank you!

[stiiixy]

Originally posted by zexelon View Post
Un-maintained "legacy" code is a security risk. Even if it passes all the regression testing and what not, its still sitting there causing "side affects". Shrinking a code base is always the best move, however obviously a balance between compatibility and maintainability must always be struck.

If someone is still using 20 year old hardware, they should really be running 20 year old software on it in my opinion. Software and hardware are always intrinsically linked. The fact that you can even get a modern distro running on 20 year old hardware is a testament to how much legacy code is still in the Linux system... I highly doubt you would get Windows 10 running with any drivers on a 20 year old system.... havent tried it myself though so maybe its possible.



There is no chance in hell of running Windows 10 on anything 20 years old. Back then high end PCs used to have around 128MB of RAM. Windows 10 need 1GB baseline, and that's the absolute minimum, anything lower and you will be hitting virtual memory even when loading the interface at startup....

I have in my possession a Pentium III 1200MHz with 512GB RAM in one of two slots. The motherboard cant handle two 512's due to an imposed limitation by Gigabyte. However, motherboards from this era most certainly could handle upwards of 2GB or 4GB, depending on desktop or workstation marketing.

[elvis]

I'm willing to bet that the majority of people complaining have made no contribution whatsoever. If they really want it, they can donate, or maintain those drivers themselves.

The nature of open source is accessibility. Writing driver-level, kernel-level code is not within the realm of all users, and sometimes money is hard to come by too. "Pay up or shut up" isn't a valid motto for the open source community.

Hardware still running these display cards likely perform far worse than Raspberry Pi's. Furthermore, you can buy super-cheap AMD laptops these days (even cheaper 2nd hand), with graphics cards that will destroy all of these.

Keeping old hardware working is about more than performance. I have old gear lying around because of obscure data transfer ports that don't (and can't) exist on modern platforms or Raspberry Pis. The performance sucks and I'd gladly upgrade, but only if the physical interfaces I need for various hardware interfaces existed on these newer platforms (which they don't).

I can certainly run older Linux distributions on said hardware, but that also brings with it challenges over time (security, compatibility with other tools and hardware, etc). I'm already seeing that where I'd love to run F2FS on a very old embedded system, but am struggling to find a kernel that will support both it and the limitations of the hardware. And that's not even "very old" kit. (Acknowledging that this particular example is merely a want and not a need).

While I understand that enormous driver bases for hardware that grown infinitely aren't a viable solution long term, merely stripping support out is pretty rough. Perhaps there could be a middle ground where this code is moved out of the main Linux Git project and into some side project? Tools like DKMS and others exist to make compiling, inserting and maintaining kernel modules in parallel with a modern running system less cumbersome.

I'm convinced there's a solution outside of the false dichotomy of "in-kernel or doesn't exist at all".

[lowflyer]

... (watching this peacock-fighting) ... Oh my ... I am so glad I left debian years ago for good.

[oiaohm]

The nature of open source is accessibility. Writing driver-level, kernel-level code is not within the realm of all users, and sometimes money is hard to come by too. "Pay up or shut up" isn't a valid motto for the open source community.

Pay up or shut up is a common historic model of all software development.

Keeping old hardware working is about more than performance. I have old gear lying around because of obscure data transfer ports that don't (and can't) exist on modern platforms or Raspberry Pis. The performance sucks and I'd gladly upgrade, but only if the physical interfaces I need for various hardware interfaces existed on these newer platforms (which they don't).

I really have a hard time believing that claim. Just as a warning I have pcie to ISA and pcie to pci converters. Modern platforms with pcie you can plug a hell lot into with the right converters. There are arm platforms with pcie 3.0 that I have used those converters with.

http://arstech.com/install/ecom-prodshow/usb2isar.html

This is a one of the most fun. Yes you can plug ISA cards into that usb2isar then use them with the Raspberry PI. Lot more can existed connected to a Raspberry Pi than most people can think as well. Like the Raspberry PI 4 cpu in fact has pcie of course its not exposed but there are other arm chips with pcie exposed and it fairly simple to get a pcie to pci card. Insanely rare is if you have a agp card to pcie converter they do exist.

I don't have a pc expansion card at this time that I cannot put on a modern bit of hardware with adaptor of some form. Maybe you don't have the right collection of adaptors. I have to work on legacy computer controlled mills and other things. The collection of data transfer ports I need to be able to use is insanely long last count was over 3000 different cards with different ports that I need for work and I connect them all to modern hardware using adapters.

Perhaps there could be a middle ground where this code is moved out of the main Linux Git project and into some side project? Tools like DKMS and others exist to make compiling, inserting and maintaining kernel modules in parallel with a modern running system less cumbersome.

This does not work for UMS drivers. These are drivers that run in users space that do the horrible access like /dev/mem and directly alter memory to control stuff. From a security point of view its been recommend to disable /dev/mem for ages. Debian kernel still has /dev/mem on to support UMS drivers. This is not a case where you can fork the existing driver and keep it going. Why because the existing drivers design is old and insecure so it only works when you downgrade your system security at some point distributions have to say no more to downgrading system security.

Some drivers like the UMS drivers that debian removing here just get to age where they are technically insecure only option to be secure is either remove them or someone write new versions from basically scratch using more modern methods.

I'm convinced there's a solution outside of the false dichotomy of "in-kernel or doesn't exist at all".

In kernel with the Linux kernel gives you something semantic patches.

https://www.kernel.org/doc/html/latest/dev-tools/coccinelle.html

Yes the fun on coccinelle so drivers in mainline Linux kernel being updated going forwards in a lot of cases require very little workload because most of their code updating is done by these semantic patches. Now out of tree maintained drivers the party developing a new coccinelle patch mainline does not see the out of tree code so cannot pick up that what they are doing is going to break the out of tree driver absolutely. Of course if the developer making a new cocinelle patch and see some mainline driver is going to die from it they can change what they are doing so it does not.

The dichotomy is not 100 percent false there is a practical problem you miss. Code developers cannot see means they cannot see they adversely effected something and that adversely effected something should cause them to take the change they want to do back to the drawing board and come up with a different way.

[Djhg2000]

... (watching this peacock-fighting) ... Oh my ... I am so glad I left debian years ago for good.

I have to agree with this. When I started using pure Debian a decade ago it was not the same Debian as today.

Gone are the days of stability being the main focus. Nowadays the public facing side is all politics and the very talented developers are being pushed aside to make room for the "new kids" (which may or may not be a TV show reference).

Out of curiousity, which distro did you move to?

[ssokolow]

I really have a hard time believing that claim. Just as a warning I have pcie to ISA and pcie to pci converters. Modern platforms with pcie you can plug a hell lot into with the right converters. There are arm platforms with pcie 3.0 that I have used those converters with.

http://arstech.com/install/ecom-prodshow/usb2isar.html

This is a one of the most fun. Yes you can plug ISA cards into that usb2isar then use them with the Raspberry PI. Lot more can existed connected to a Raspberry Pi than most people can think as well. Like the Raspberry PI 4 cpu in fact has pcie of course its not exposed but there are other arm chips with pcie exposed and it fairly simple to get a pcie to pci card. Insanely rare is if you have a agp card to pcie converter they do exist.

I don't have a pc expansion card at this time that I cannot put on a modern bit of hardware with adaptor of some form. Maybe you don't have the right collection of adaptors. I have to work on legacy computer controlled mills and other things. The collection of data transfer ports I need to be able to use is insanely long last count was over 3000 different cards with different ports that I need for work and I connect them all to modern hardware using adapters.

You clearly haven't spent any time on retro-tech forums where this sort of thing gets discussed. Here's one answer to someone asking how to do what you describe on the Retrocomputing Stack Exchange.

There's basically two possibilities you may find:

1. The ISA card is a fairly trivial piece of hardware, using I/O ports or memory-mapping only. In this case, it is pretty likely an USB-to-ISA or PCI-to-ISA adapter will work. It is, however, also pretty likely a modern PCI-express or USB replacement is cheaper, thus rendering the adapter useless.
2. The ISA card is not-so-trivial, might use DMA or even take over the bus completely, as many of the more complicated co-processor cards do. I happen to have a Motorola 68040 card on an ISA slot that does take over the bus completely and talks to the graphics card and disk controllers directly - something like that would be worthy of spending quite some of money for an adapter card - I don't, however, know of any adapter card that would support such a setup.

The above, either too simple to justify the cost of an adapter card, or too complicated that it is really working, is probably the main reason such ISA adapters are no longer available in the market.
Your best possible options are either buying a relatively modern used PC that still has ISA slots (they're still available on eBay, if you're lucky, you'll find a very small and relatively recent Pentium board like they were used for PoS systems, that's what I did), or investing in a more modern setup, you can still buy new ISA-PC setups targetted at the embedded market (at a price, however).

If you had, I'd expect you or someone you've interacted with to have chimed in with a rebuttal and a link to the adapters you use to solve the problem.