On Fri, Nov 07, 2014 at 08:30:32PM +1100, csir...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107145016.gr24...@csclub.uwaterloo.ca
