Yes true, but the reason of "no commits, so it must not be in use!" is not sound. Maybe it's good enough, it doesn't need a constant slew of commits because those CPUs aren't as broken as Intels? The attidute to just fork it because the users of the unpopular stuff can just support it themselves assumes that the users can support it themselves or have the amount of free time to do so. The Linux and open source philosophy is not merely "fix it yourself, if you can!", but it also includes "we support unpopular stuff that the big commercial companies won't", "we can make your old hardware work again", and "we don't treat our users like shit".
I think the argument is more "no commits, so it must not be actively maintained!" - and if it's not being maintained, then little or nothing will be lost if they drop it and let whoever IS still using that old hardware to also use the old kernels.
Also, it's not like there's a huge security risk leaving some of these architectures with kernels that are no longer updated. Sure you can get your 30+ year old whatever working agian, but you're probably not going to be using it for anything worth worrying about,
Even that logic is broken. No recent commits MAY mean not maintained, nobody cares OR it might mean it hasn't been broke in a long time, so nothing to fix.
I haven't performed maintenance on the light in my utility room in well over a year. I *DO* use that light daily. It just hasn't burned out since I replaced the light emitting heat globe with LEDs.
This is sort of the difference between FreeBSD, NetBSD, or OpenBSD in some ways. PC-centric versus traditional suport platforms versus platforms we think are interesting.
Having old stuff around is informative too. Otherwise you get newcomers complaining about having to use strange macros even though they're no-ops on Intel. Not so far fetched because I have heard similar sorts of complaints from various noobs in the past ("htonl is stupid!").
the reason of "no commits, so it must not be in use!" is not sound
I think the argument is more "no commits, so it must not be actively maintained!"
Which might also not be accurate. No commits might mean that it's darn near perfect if the hardware hasn't changed (and we're talking about older hardware).
So if someone wants their 32-bit Sparc support but also able get the latest USB drivers and network stack fixes... Maybe the real problem is that too much just got shoved into single code tree and that it wasn't made to be more modular from the start?
Yes true, but the reason of "no commits, so it must not be in use!" is not sound.
But that's not the reason. They're using that as a search criteria to draw up a list of candidates for removal. It is entirely sound to look for things that haven't been updated for a long time to build up a list.
Given how much the kernel ABI changes, if they haven't been touched for 5 or more years, then chances are no one is developing them enough to notice any breaking ABI changes.
"we support unpopular stuff that the big commercial companies won't"
And they have been supporting it. They've been supporting it for 5 to 10 years without any problems.
The 5-10 years sounds like a long time. But... I am involved with issues at work where something drops support after 5 to 10 years and we're scrambling. 10 years may be a long time for a PC, but it's a short time for a lot of things, such as lifetime of embedded devices, certificates, licensed customer support, and so forth.
Given how much the kernel ABI changes, if they haven't been touched for 5 or more years, then chances are no one is developing them enough to notice any breaking ABI changes.
The kernel ABI doesn't change all that much. At least, at the architecture HAL level. The kernel needs very little of the HAL, and big changes to the HAL aren't very common because doing so will break every architecture.
The rest of the kernel ABI is hosted by the kernel itself - things like driver APIs are well above the architecture HA
There is a point where the 1o year old hardware that is based on non-replacable hardware has too high a maintenance cost. How much of the modern kernel is dead-weight, there because the 386 Intel processors are still in use, but no longer sold.
"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:yes please (Score:5, Insightful)
Yes true, but the reason of "no commits, so it must not be in use!" is not sound. Maybe it's good enough, it doesn't need a constant slew of commits because those CPUs aren't as broken as Intels? The attidute to just fork it because the users of the unpopular stuff can just support it themselves assumes that the users can support it themselves or have the amount of free time to do so. The Linux and open source philosophy is not merely "fix it yourself, if you can!", but it also includes "we support unpopular stuff that the big commercial companies won't", "we can make your old hardware work again", and "we don't treat our users like shit".
Re: (Score:2)
I think the argument is more "no commits, so it must not be actively maintained!" - and if it's not being maintained, then little or nothing will be lost if they drop it and let whoever IS still using that old hardware to also use the old kernels.
Also, it's not like there's a huge security risk leaving some of these architectures with kernels that are no longer updated. Sure you can get your 30+ year old whatever working agian, but you're probably not going to be using it for anything worth worrying about,
Re: (Score:2)
Even that logic is broken. No recent commits MAY mean not maintained, nobody cares OR it might mean it hasn't been broke in a long time, so nothing to fix.
I haven't performed maintenance on the light in my utility room in well over a year. I *DO* use that light daily. It just hasn't burned out since I replaced the light emitting heat globe with LEDs.
Re: (Score:2)
This is sort of the difference between FreeBSD, NetBSD, or OpenBSD in some ways. PC-centric versus traditional suport platforms versus platforms we think are interesting.
Having old stuff around is informative too. Otherwise you get newcomers complaining about having to use strange macros even though they're no-ops on Intel. Not so far fetched because I have heard similar sorts of complaints from various noobs in the past ("htonl is stupid!").
Re: (Score:2)
Re: (Score:2)
the reason of "no commits, so it must not be in use!" is not sound
I think the argument is more "no commits, so it must not be actively maintained!"
Which might also not be accurate. No commits might mean that it's darn near perfect if the hardware hasn't changed (and we're talking about older hardware).
Re: (Score:2)
So if someone wants their 32-bit Sparc support but also able get the latest USB drivers and network stack fixes... Maybe the real problem is that too much just got shoved into single code tree and that it wasn't made to be more modular from the start?
No need to fork - just tell Arnd "I'm using that" (Score:2)
> The attidute to just fork it
There's no need to fork anything. Just tell him "I'm still using a prima2" and it stays in.
Re: (Score:2)
Yes true, but the reason of "no commits, so it must not be in use!" is not sound.
But that's not the reason. They're using that as a search criteria to draw up a list of candidates for removal. It is entirely sound to look for things that haven't been updated for a long time to build up a list.
Given how much the kernel ABI changes, if they haven't been touched for 5 or more years, then chances are no one is developing them enough to notice any breaking ABI changes.
"we support unpopular stuff that the big commercial companies won't"
And they have been supporting it. They've been supporting it for 5 to 10 years without any problems.
"we don't treat our users like shit".
The companies that sup
Re: (Score:3)
The 5-10 years sounds like a long time. But... I am involved with issues at work where something drops support after 5 to 10 years and we're scrambling. 10 years may be a long time for a PC, but it's a short time for a lot of things, such as lifetime of embedded devices, certificates, licensed customer support, and so forth.
Re: (Score:2)
The kernel ABI doesn't change all that much. At least, at the architecture HAL level. The kernel needs very little of the HAL, and big changes to the HAL aren't very common because doing so will break every architecture.
The rest of the kernel ABI is hosted by the kernel itself - things like driver APIs are well above the architecture HA
Re: (Score:2)