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

[Creak]

I must say that both ubuntu and debian are doing pretty well maintaining "old" hardware. Ubuntu has patched ceph to be usable on 32 bit systems, and so has debian, while upstream, they make bug after bug due to wrong size assumptions. 32 bit systems are still very common and very cheap. And I am very thankful, because my 64 bit intel can't cope with the cpu load, but my 32 bit arm has no problem with it.

The CPU performance between x86_64 and ARM is actually more about the CPU architecture than the bus width (32 bits vs 64 bits). ARM has a simpler, more optimized set of instructions while x86_64 has a huge set of instructions (mainly through extensions like SSE, AVX, and the likes). This would actually be the main performance difference (and a huge one). If you take two 64 bits CPUs, one ARM64 and one x86_64, you'll see that, at equal frequencies, ARM will beat of x86_64 easily. The counterpart of that is that most of the programs are compiled for x86_64 only... so we need to wait until we can see official Windows 10 machines sold on ARM64 CPUs; there we might see the real rise of ARM CPUs in the desktop market.

[Creak]

As Danny3 stated, as long as it is usable, bug free and no updates are required because of compiler, kernel or other API changes, why would anyone thinker with the existing codebase? In your view it seems that as long as the date of the repository is changing and/or a file is changed just for the sake of making a change, it might still be included. Creating work where no work is required.

I explained why in my previous answers, but the TL;DR is: because the rest of the Linux ecosystem (e.g. kernel, Wayland) is changing and this asks for constant modifications, even is old code.

[TemplarGR]

If those people want to still use such old hardware, they can simply use an older version of Debian. It is absurd to want to add burden to people because you want to use archaic hardware that is simply useless for modern needs. Such old hardware can barely load a modern browser for fsck sake. Like seriously, just use an older version. It will become unsupported and probably won't get any more security fixes, so what? Your hardware has been obsolete for a whole human generation, and you aren't using it for anything modern (where the fear of malware and other exploits exists).

Seriously, this should have been such a non-issue. Linux users oftentimes are retarded.

[fransdb]

I highly doubt those whispers of dropping support for an architecture as recent as K10 are anything serious assuming you didn't just make that up so you could have an argument. Hardware of roughly that age is, as you said, still very much usable for current day use cases and you can still go out and buy brand new hardware with lower performance than that. This simply isn't true for the hardware that's now being dropped, which is currently only really usable with other equally obsolete hardware. We're talking hardware so old that most of it has already ended up at eWaste recycling plants by now and the rest is mostly lying in people's attics or basements.

The reality is that the more hardware you have to support the harder it gets to make any significant improvements, particularly architectural ones, without breaking something. Fixing stuff that's still maintained is way less of a hassle than unmaintained code as not only do you have people on hand that are familiar with the code in question, even if you have people familiar with the unmaintained code on hand those people won't have it in recent memory is its been years and years since they touched that code.

Follow the suggestion of @skeevy420 and read about it. It is also running longer then the last month. By the way, obsolete hardware does not exist, except in the eye of the beholder. I still run my old Z80 system (1980) every month or so. It has my inventory program running in 64KB, and two floppy disks, written in a language called Pilot. It still runs, no pressing need to rebuild it and having to require hundreds of MB to run nowadays. Making my point that you do not need for every task the newest and fastest hardware.

I do, however, concur with the second part of your posting, it also augments my own first posting.

[allquixotic]

There's already a distribution of Debian for these pieces of hardware that have lost ongoing support. It's called... use the last version that worked. If for some reason you are stuck on 20 year old hardware, why aren't you OK with being stuck on 2 year old software? Old stable releases of Debian won't ever lose the hardware support, so just run the last version of Debian Stable that supports the hardware you use. When that version of Stable is no longer receiving security updates, you're free to either patch software yourself, or pay a company to do it for you.

If you really need long term support of a distro, though, your best bet is either Ubuntu LTS, RHEL, or CentOS. A given major release of these LTS distros receives continuous security updates for a lot longer than Debian Stable on average, and the end date is well known and made very clear ahead of time.

Besides, the requirements for new software releases will continue to increase. Some future release of Debian Stable is virtually guaranteed to default to using a Wayland compositor, which really won't run well on 20 year old hardware like an R128 and a Pentium 4. If you want good performing software on really old hardware, your best bet is to run old software too. It's reasonable to desire continuous security updates for systems of this vintage that nevertheless need Internet access, but eventually you have to be willing to stop using that old hardware and move on, or accept the consequences of being stuck in the past for both software and hardware.

[fransdb]

If those people want to still use such old hardware, they can simply use an older version of Debian. It is absurd to want to add burden to people because you want to use archaic hardware that is simply useless for modern needs. Such old hardware can barely load a modern browser for fsck sake. Like seriously, just use an older version. It will become unsupported and probably won't get any more security fixes, so what? Your hardware has been obsolete for a whole human generation, and you aren't using it for anything modern (where the fear of malware and other exploits exists).

Seriously, this should have been such a non-issue. Linux users oftentimes are retarded.

I take offence to the above posting. Clearly posted by someone who shows lack of empathy.

[birdie]

A perfect example of why the kernel and drivers must be decoupled. Only it'll never happen in the Linux kernel.

Stable API "nonsense" and shit.

[Michael]

A perfect example of why the kernel and drivers must be decoupled. Only it'll never happen in the Linux kernel.

These ones removed from Debian are already classic X.Org drivers outside of the kernel.

[zexelon]

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.

[zxy_thf]

The CPU performance between x86_64 and ARM is actually more about the CPU architecture than the bus width (32 bits vs 64 bits). ARM has a simpler, more optimized set of instructions while x86_64 has a huge set of instructions (mainly through extensions like SSE, AVX, and the likes). This would actually be the main performance difference (and a huge one). If you take two 64 bits CPUs, one ARM64 and one x86_64, you'll see that, at equal frequencies, ARM will beat of x86_64 easily. The counterpart of that is that most of the programs are compiled for x86_64 only... so we need to wait until we can see official Windows 10 machines sold on ARM64 CPUs; there we might see the real rise of ARM CPUs in the desktop market.

It seems you have read too many ARM commercials/lies without thinking.
An "optimized" ISA after stripping out the extensions will only force the CPU run at least three times slower (https://www.extremetech.com/computin...eadripper-cpus . Note: even the slower path has SSE2 built-in).
A really competitive ISA would not be much better than x86, and you're paying all the transition cost just because "it sounds cool".

There is no free lunch.

In addition, Windows (and its users) relies on backward compatibility so much that it is the most unlikely platform whose user base is willing to transit to another architecture.