[miohtama]

> It's sad to see old hardware support getting dropped like that.

The problem is that someone needs to work to support different hardware architectures. More exotic hardware, more complicated and expensive the work becomes.

People who run these 32-bit machines are unlikely to vouch in terms of work contributed or money contributed to get the people paid for this work, so it is better to drop the support and focus the same developer resources on areas which benefits larger user base.

[snvzz]

the real problem is Linux is written in such manner that APIs change very often, and code all over the place including drivers is monkeyed without testing and often broken, sometimes in very subtle and hard to debug ways.

It is an overall design issue. Linux has a huge maintenance burden.

[miohtama]

Indeed it is. I am not sure if BSD people have better support for legacy hardware. Outside BSD, there is no competition for open source operating systems, or generally legacy PC hardware systems overall as Windows support was dropped long time ago.

[themafia]

The kernel APIs change never and 32bit support is still within the kernel without any issue at all. How does this implicate drivers?

The rest is user space code. Usually in C. Which has plentiful facilities for managing this. We've been doing it for decades. How is it a sudden burden to continue?

Where are the examples of distributions failing because of this "issue?"

[adrian_b]

The internal kernel API used by device drivers changes at every version, even at minor versions.

If you maintain an out-of-tree driver, it is extremely likely that it will fail to compile at every new kernel release.

The most common reasons are that some definitions have been moved from one kernel header to another or some members have been added to a structure or deleted from it, or some arguments have been added to a function invocation or deleted from it.

While the changes required to fix a broken device driver are typically small, finding which they are can require wasting a lot of time. The reason is that I have never seen any of the kernel developers who make these changes that break unrelated device drivers writing any migration document that instructs the device maintainers how to change the old source code to be compatible with the new interfaces.

Normally there is absolutely no explanation about the purpose of the changes and about what the users of the old API should do. Only in rare cases scanning the kernel mail messages may find some useful information. In other cases you just have to read the kernel source, to discover the intentions of whoever has changed the API.

That does the job eventually, but it consumes far more time than it should.

Even in-tree drivers for old devices, which may no longer have a current maintainer, will become broken eventually.

[miohtama]

If you think it is not a burden you are free to maintain yourself. This is the core value promise of open source.

[themafia]

> are unlikely to vouch in terms of work contributed or money contributed

Unlikely? Did anyone bother to ask?

[guappa]

Yes

[themafia]

They must not have done a very good job then.