Re: debootstrap and cdebootstrap vs systemd
On Fri, Nov 07, 2014 at 08:30:32PM +1100, csirac2@yahoo.com.au wrote:
> Apologies in advance. You really hit a nerve here.
>
> Kernel 3.7 was released December 2012. Debian project created a dependency on this for the default init system roughly 15 months later. Which is fine, and perfectly understandable. It makes sense. I don't want to argue that.
Well I know wheezy runs fine on a 3.0 kernel. Not sure how much further
back you can go. Of course that was as far as I can tell released Around
August of 2011, so only another year and a bit longer.
> But please don't make light of the situation for those who can't apt-get install hardware-redesign beg-silicon-vendor-for-updates port-and-re-validate-custom-undocumented-modules go-back-in-time-and-teach-hardware-engineers-linux-kernel-lifecycle
If udev decides to stop supporting kernels without some useful recent
feature, do you expect Debian to keep patching to code to support older
kernels that even Debian has no intention of using in new releases?
What would be the point of that?
> 3.7 is less than 2 years ago even today, apparently even that is a blip in many embedded hardware solutions' life-cycle. Some manufacturing sectors are still selling m68k and Z80 CPUs. For SoCs though, it seems the tradition is: fork a particular Linux kernel release, mangle it beyond recognition, throw it over the wall and then act like customers are speaking an alien language if they ever ask for updates.
>
> "Don't accept old kernels" is almost equivalent to telling many unrelated businesses in a particular ecosystem to burn their investments and start again from scratch, just because the SoC and/or board vendors have a broken business model. And that's hard to explain to business people and even hardware engineers that a chip/board/subsystem is "unsupported" even though supply guarantees stretch out to the year 2020 and beyond.
Well if you don't try to explain it, you will be stuck with the problems
forever.
Where I work we make it clear to the suplier that support for the chip has
to be mainlined to Linus's tree, or we don't want to deal with the chip.
We know what it is like to deal with a vendor kernel that isn't maintained
and we don't want to do that. We want nothing to do with SDKs or
BSPs either. They are not useful for long term maintainance of a product.
They are harmful.
> And for all I know, perhaps these businesses deserve everything that happens to them, who knows.
Sounds fair to me. They are doing things wrong and hurting their
customers.
--
Len Sorensen
Reply to: