Hello, On Sat, Feb 03, 2018 at 09:43:33PM +0000, Michael Fothergill wrote: > I am trying to suggest one would want to move faster than the approximate > cycle time of new stable releases here.
You have been repeatedly told that the updates will appear as security updates in Debian stable when the kernel team judges they have had an appropriate amount of testing. Security updates do not wait for the next stable release, nor even the next stable point release. You are writing vastly more text in this thread than any other single correspondent but you don't appear to be particularly familiar with your subject matter. I suggest that for a newcomer trying to follow your long and winding tale thinking it is somehow representative of Debian, *that* would seem like an odyssey, and there's just no need. The answers were all given in the first few posts and the rest of it is a combination of you misunderstanding what Debian is, and you wishing Debian was something that it's not. > I am concerned about new users and what they would have to to > install the current kernels (ie use a separate live sid > distribution (correctly and helpfully referred to by Andy) to > compile the new kernel and then transfer it to the stable > install). Well I didn't say you needed a live distribution, I suggested a chroot would be the normal way. Unless you consider a chroot to be a live distribution, which I personally would not, but it is debatable. To me a live distribution is something you boot into, whereas a chroot is a lightweight thing that you just create, launch processes in and then throw away. No rebooting, etc. Telling people that they need "a live sid distribution" implies a lot more work than is actually required. > That does not seem to me to be ideal for a new user. Hence my > comment about it not being fit for purpose at present. The Spectre bugs are quite unusual in that they need a kernel update *and* a new compiler to build it with (and microcode updates too). That is a really exceptional set of requirements and it would be inappropriate to design your whole distribution around that being a normal state of affairs. The mere fact that the Debian kernel team is waiting a little while before pushing new packages into stable does not for me render the entire distribution "not fit for purpose" - nor even the kernel team's processes. *Someone*'s got to do that work and I'd rather Debian's kernel team did it than have the latest upstream stuff thrown at the general user base. Other distributions which track upstream more aggressively are designed for that. It's part of their contract with their users. Proposals to make some sort of rolling release version of Debian that more closely follows upstream have been made many times but have never come to much. For example: <https://lists.debian.org/debian-devel/2015/03/msg00045.html> > It has been suggested to me others on the site that eventually the > GCC 7.3 compiler might be introduced into Debian Buster whereupon > it could be used to compile the latest kernels. I don't know what the plans are for gcc but that would make things a little easier, yes. However the route to a fix for the majority of Debian users will be to receive new binary kernel packages from a security update. Which is even easier. > The odyssey is debian itself as I see it. …because you went on a learning experience and instead of doing what multiple people suggested, went down some very long dead ends of your own. If you want to make genuine constructive suggestions for how things could be improved, I think you should start by identifying what exactly the deficiencies are. A lot of this thread seems to have been along the lines of "it's too hard to build Debian kernel packages that are fixed against Spectre and Meltdown", but the point is marred by a) you taking a lot of wrong turns, and b) the Spectre bugs being quite exceptional in how they can be mitigated. Having to build a chroot and then rebuild a kernel package with the gcc inside that chroot sounds tricky but it's actually fairly easy once you've done it once. Given how rare it is to need to do that, I'm not convinced it is that onerous or that it is any kind of condemnation of Debian. If that is *not* what you consider the deficiency to be, can you succinctly explain what it is? Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting