On Tue, May 02, 2006 at 05:06:24PM -0600, Archaic wrote: > > It is a no-brainer. The problem is in that they don't seem to do much > testing. They spit out versions left and right instead of slowing down a > bit, doing some testing, and then releasing. Obviously some like the new > release method cause they are doing it that way. I happen to not like > it because we are about to release a book that once released will be > static? How long should a book editor have to follow a kernel branch > just to keep the errata page up to date? And what qualifies as errata? > Obviously security fixes, but what else? Everything? Once this book is > released, how many regular lfs-dev readers will still track 2.6.16 when > the latest and greatest is 2.6.17 or higher? We can't simply assume that > slapping a new kernel onto an old host will work, especially with > non-static device nodes. When will the next incompatible change happen > in udev?
Like everything else in software libre, it relies on volunteers. That's why it's a good idea for people who have the time and resources to test -rc kernels - sometimes the bugs get fixed! As to the next incompatible change, I have no more idea than you do, although I've seen one or two attempts in other areas get stamped on. But, over time vulnerabilities in *all* old kernels will come to light. At the moment, we seem happy to let people stick with the kernel they built when they built LFS. And to some extent the udev change was overstated - I initially avoided 2.6.15-rc kernels except on my old system with static devices, but after a comment on the kernel list I tried it with the old udev - yes, it was messy in the error messages and logs, but the system worked adequately. But, my focus is narrower : while the -stable team are maintaining the kernel version we are using, we should take advantage of their work and drop the new point releases straight into the book and point our readers to using the latest available - it won't buy us a lot, because -stable will be supporting 2.6.17 within a few weeks, but it might help, and it might help to alert our readers that the kernel is vulnerable like everything else. > > Of course, if you are volunteering to track the kernel changes in > released books and keep the errata up to date, that would be welcomed. > ;) Never trust a backport from somebody who doesn't even understand the vulnerability reports (e.g. on the series of keyring bugs). Realistically, the only way to keep on top of known vulnerabilities is either to use the latest kernel, or to rely on a distro for backports. So no, I'm not volunteering. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
