On Tue, May 02, 2006 at 04:39:28PM +0100, Ken Moffat wrote:
> At last, I'm *really* subscribed from this address, so I'll have
> another go at trying to send this :)
>
> Now that we have maintenance of the stable kernel, I think we
> should point people to the latest incremental release of the same
> kernel version. So, if we release a book with 2.6.16.12 and
> subsequently 2.6.11.{13,14,15} are released, I'd hate to think that
> people would religiously follow the book and not use the later
> versions.
>
> Mentioning stable releases has a number of implications:
>
> (i.) The editor's guide says we should build with the new version
> before putting it in the book. I humbly submit that we should make
> an exception for stable kernels and put them in as soon as they
> appear - the changes are tiny, to deal with known issues, and
> sometimes they are security fixes.
I disagree. There is no stable 2.6 upstream kernel. That is intentional.
The 4th dotted increment (since the 3rd is patchlevel, what is the 4th
called? micro?) means nothing to kernel devs anymore. It is not just for
bug fixes. New features are often added or at least heavily modified
from 2.6.xx.y to 2.6.xx.y+1.
> To be clear, I'm not saying 2.6.17 should go in as soon as it
> appears, only that while we are on 2.6.xx.y we should move the book
> to 2.6.xx.y+1 as soon as that is released (with the presumption that
> we won't get as far behind kernel releases as we were with the udev
> problem).
Actually, I prefer waiting a week. They have been known to release
multiple new versions in a week and giving it a few days helps to see if
they spotted something after the fact (rant: what happened to upstream
auditing. It appears to be non-existant).
> (ii.) Because the changes are tiny, I assume SBU and space
> measurements can be carried forward - I think the figures for
> 2.6.16.5 were mine, in which case they are accurate for that version
> on my machine with my .config but may have only a glancing relevance
> to your figures.
SBU timings can never be close for the kernel. A wide sweeping range of
times can be mentioned just to avoid support questions, but trying to
check the accuracy of it is futile. Now that there are 2 targets for
barebones and build-everything, those would be good for the low/high in
the book, but both are still impractical and therefore not really worth
much.
> (iii.) The stable patches are created against the base version, so
> if you patch from 2.6.16.5 to 2.6.16.12 you need to have both
> patch-2.6.16.5.bz2 and patch-2.6.16.12.bz2, and to reverse the first
> one. This still catches people out, so I think it is worth putting
> in the book.
Did I miss the part where the book recommends using patches to update
the kernel? If it is in there, your comments are valid. Otherwise, I
don't see the need.
> So, although it isn't strictly related to the stable kernel issue, I
> would like to also propose that at the end of the book we add some
> text encouraging people to (a) monitor what is happening in the kernel
> re vulnerabilities and issues,
http://www.linuxfromscratch.org/lfs/view/development/chapter09/whatnow.html
> and (b) try out test (-rc) kernels [ because they do need testing ] if
> they are prepared to do the necessary background reading to follow
> what is going on, and prepared to handle reporting bugs on lkml.
I disagree. It isn't the readers responsibility to test rc kernels nor
the book's responsibility to entice them into doing so. We aren't
creating kernel developers.
--
Archaic
Want control, education, and security from your operating system?
Hardened Linux From Scratch
http://www.linuxfromscratch.org/hlfs
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
