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.
Generally, if nobody touched a particular piece of kernel code for years then it is either completely perfect or completely unused. Determine which and act accordingly.
There's the third possibility that the code is buggy, but still very much used in some very specialized setting which only exercises a tiny subset of its functionality.
IMLE that's like 99.99% of cases. Linux is a general purpose OS, yet it's mostly used in very specialized, embedded settings.
I wish that people would give up on this "code cleanup" obsession, which most of time means "let's fuck up stuff we don't have a clue about".
You've got the wrong idea about how the kernel process works, and the wrong idea about the importance of code cleaning. Very wrong. Dangerously wrong. Hope you're not fucking anything up where you work.
Most of the "code cleaning & refactoring" pushers aren't able to understand & DEBUG old code at all (or write completely new code), but they have to do something to leave their mark and be in the "process".
Most of the "code cleaning & refactoring" pushers aren't able to understand & DEBUG old code at all (or write completely new code), but they have to do something to leave their mark and be in the "process".
What are you going on about? In the kernel community such a person would be exposed immediately and invited to get lost. People can't just send in their shitty code you know, it has to go through a maintainer. And maintainers that fuck up by letting shit through do not last long, nor do their checkins.
"It's the best thing since professional golfers on 'ludes."
-- Rick Obidiah
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.
Re: (Score:3)
Generally, if nobody touched a particular piece of kernel code for years then it is either completely perfect or completely unused. Determine which and act accordingly.
Re:yes please (Score:1)
There's the third possibility that the code is buggy, but still very much used in some very specialized setting which only exercises a tiny subset of its functionality.
IMLE that's like 99.99% of cases. Linux is a general purpose OS, yet it's mostly used in very specialized, embedded settings.
I wish that people would give up on this "code cleanup" obsession, which most of time means "let's fuck up stuff we don't have a clue about".
Re: (Score:2)
You've got the wrong idea about how the kernel process works, and the wrong idea about the importance of code cleaning. Very wrong. Dangerously wrong. Hope you're not fucking anything up where you work.
Re: (Score:1)
Right, I was trying too hard to be kind.
Most of the "code cleaning & refactoring" pushers aren't able to understand & DEBUG old code at all (or write completely new code), but they have to do something to leave their mark and be in the "process".
Re: (Score:2)
Most of the "code cleaning & refactoring" pushers aren't able to understand & DEBUG old code at all (or write completely new code), but they have to do something to leave their mark and be in the "process".
What are you going on about? In the kernel community such a person would be exposed immediately and invited to get lost. People can't just send in their shitty code you know, it has to go through a maintainer. And maintainers that fuck up by letting shit through do not last long, nor do their checkins.