[nbsande]

Keeping support for near 20 year old consumer grade machines in the kernel seems ridiculous to me. Doing so would bloat the size of the kernel even more than it already is. The more code you have the easier it is for bugs and vulnerabilities to creep in. When people write articles about moving old computers to windows to Linux they generally don't mean 20 year machines. You wouldn't even be able to run a modern browser with 256 mb of ram

[Tepix]

Most of the hardware specific code is in loadable kernel modules, they increase the code size but not the system requirements.

[colejohnson66]

Yes, but those modules need to be maintained as the kernel is updated. If a specific architecture’s tree is abandoned, it would make sense to remove it from the tree until someone picks it up again.

[mschuster91]

The problem: once something is removed from the tree, it is almost impossible to get it back in, since whoever wants to do that has to replay the extreme amounts of refactorings done since the removal.

The Linux kernel famously only guarantees outside stability of interfaces, but in-kernel interfaces are regularly changed - one might suspect intentionally, to make the lives of people doing off-kernel work (such as graphics card drivers) as difficult as possible so that they will eventually open source their code and ship it in the kernel.

[colejohnson66]

How’s that any different than keeping it updated while it’s in the tree? If it’s stale and someone comes along to fix it, it’ll be in the same state it was when it would’ve been removed. Stale code needs to be updated regardless of where it came from.

[mschuster91]

Code that is in the tree will get picked up by everyone who does a refactoring of an internal interface.

Code that is outside of the tree will need someone who goes through all of the refactorings manually.