On 3 February 2018 at 23:14, Andy Smith <a...@strugglers.net> wrote: > 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. > OK I am incorrect here. > > 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. > > I agree it is only temporary. I don't a dramatic solution but perhaps bending the rules a bit for a while because it's a funny problem but I see that is pehpas not really needed. > 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. I did not think that at all. Really not. It was just having to sid in some way to make the new kernel for a while in some cases I now realise with a chroot I see now not a live distribution. > *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. > Only wanting kernels quicker so chrooting not needed. > > 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. > I don't think its much harder than in gentoo which I have already done. Trying with GCC was making it more difficult than is now necessaruy and is fair comment. > > 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. > "Condemnation" is too harsh a word. All I wanted was earlier new kernels but you have pointed out they are comgin soon above. OK, I agree a chroot is *a lot* simpler than a live distribution of sid etc. I use it all time with gentoo and chroot into gentoo from debian all the time when gentoo has problems Sorry about that. > > If that is *not* what you consider the deficiency to be, can you > succinctly explain what it is? > I think we should leave it at that. Cheers MF > > Cheers, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > >
