The problem is that most developers won't have any way of testing how changes will affect that old hardware and they can waste a lot of time over trying to keep it working.
The problem is that most developers won't have any way of testing how changes will affect that old hardware and they can waste a lot of time over trying to keep it working.
But that's the mantra of the Linux community: open up your hardware and put your drivers in the kernel and the community will maintain it. Just because the code that supports that hardware hasn't had any changes doesn't mean it's not used. Most of these aren't particularly old and saying "oh just use an older and less secure kernel then" is not a viable solution.
The other solution, other than using an older kernel, would be to let Arnd know that you're using whichever CPU. That is if it's a CPU that can even support 16MB of RAM or so - several of these can't.
yes please (Score:5, Insightful)
It's causing bloat and maintenance headaches, get rid of it! It's an old CPU, it can use an old kernel.
Re: (Score:2)
Re: (Score:2)
The problem is that most developers won't have any way of testing how changes will affect that old hardware and they can waste a lot of time over trying to keep it working.
Re: (Score:0)
The problem is that most developers won't have any way of testing how changes will affect that old hardware and they can waste a lot of time over trying to keep it working.
But that's the mantra of the Linux community: open up your hardware and put your drivers in the kernel and the community will maintain it. Just because the code that supports that hardware hasn't had any changes doesn't mean it's not used. Most of these aren't particularly old and saying "oh just use an older and less secure kernel then" is not a viable solution.
Or just raise your hand (Score:2)
The other solution, other than using an older kernel, would be to let Arnd know that you're using whichever CPU. That is if it's a CPU that can even support 16MB of RAM or so - several of these can't.