4 ms·

This makes me sad. Now, most will say "but why, 1995 is ancient history, no such hardware exists anymore". The thing is ... should Linux get rid of what is old

This makes me sad. Now, most will say "but why, 1995 is ancient history, no such hardware exists anymore". The thing is ... should Linux get rid of what is old? I understand you have a smaller kernel when you have less code, less cost to maintain, I get it. Still, I wonder whether this should be the only allowed opinion. Would it not be better to, kind of, transition into a situation where any hardware built in the future, would be supported? So in 2050, we'd not say "damn, computers from 2026 are obsolete now". We could say "no problem, linux is forever". Everything is supported. I actually would prefer the latter than the "older than 30 years, we no longer support it".

jamesgeck0 5mo ago
That date feels a little bit late. The PS/2 devices that superseded the bus mouse started appearing around 1987. There were certainly still bus mice around in 1995, but they were thoroughly obsolete.
bigfishrunning 5mo ago
> Would it not be better to, kind of, transition into a situation where any hardware built in the future, would be supported? easier said then done -- the kernel's internal interfaces aren't static, they change often. The project has never committed to stabilizing it's driver api, so every driver takes non-zero work to maintain. I would assume computers that are still running these old ISA mouses (mice?) probably are also running an older version of linux; and if they're running a new kernel then it'll be somebodys job to port the drivers forward. There's some likelihood this will end up maintained by someone out-of-tree, which is a nice way of saying "we've sent your dog to a farm upstate..."
- sockaddr 5mo ago
  To add to this, as long as the diff representing the removal of the driver is kept in the git history it would be trivial for someone in the far future to say to an AI agent: "Please take this linux source and patch the Bus mouse driver back in but match the new driver interface". With code preserved in git history it's never actually "removed". It's just, disconnected.
wang_li 5mo ago
The real issue is that they don't have stable intra-kernel ABI/APIs. It should entirely be the case that technologies that are 10+ years old are stable and a clean abstraction layer can be created. You maintain the abstraction layer and all the things on the other side of it don't have to track random kernel changes. Things like this just keep working indefinitely.

jamesgeck0 5mo ago

That date feels a little bit late. The PS/2 devices that superseded the bus mouse started appearing around 1987. There were certainly still bus mice around in 1995, but they were thoroughly obsolete.

bigfishrunning 5mo ago

> Would it not be better to, kind of, transition into a situation where any hardware built in the future, would be supported? easier said then done -- the kernel's internal interfaces aren't static, they change often. The project has never committed to stabilizing it's driver api, so every driver takes non-zero work to maintain. I would assume computers that are still running these old ISA mouses (mice?) probably are also running an older version of linux; and if they're running a new kernel then it'll be somebodys job to port the drivers forward. There's some likelihood this will end up maintained by someone out-of-tree, which is a nice way of saying "we've sent your dog to a farm upstate..."

sockaddr 5mo ago
To add to this, as long as the diff representing the removal of the driver is kept in the git history it would be trivial for someone in the far future to say to an AI agent: "Please take this linux source and patch the Bus mouse driver back in but match the new driver interface". With code preserved in git history it's never actually "removed". It's just, disconnected.

wang_li 5mo ago

The real issue is that they don't have stable intra-kernel ABI/APIs. It should entirely be the case that technologies that are 10+ years old are stable and a clean abstraction layer can be created. You maintain the abstraction layer and all the things on the other side of it don't have to track random kernel changes. Things like this just keep working indefinitely.