Bill Studenmund wrote:
> 
> Note: the kernel it's running, even though it was "current" at the time,
> really is a 1.6 kernel. So all the fixes applied to 1.6 apply to it; we
> don't need the latest & greatest kernel to be safe.
> 
> Also, if the advisories are being applied by patch rather than
> bulk-update, then the kernel version won't change.
> 
Which was contrary to my thoughts, as I'd expect the machine that 
generated the updates to use those updates itself....


> I think that the time to update will be after 2.0 comes out. While you're
> right that "eating our own dogfood" is good, this is a production machine.
> So updating before or during a release isn't so good. :-)
> 
Yet, that's different than the 1.6 release, where they used 1.6 to 
build 1.6 and its successors....

Yeah, I was certainly burned using -current in production machines this 
past year (by the bad ffs compatibility).  The described update process 
is completely unworkable for remote POPs.

Fortunately (depending on the point of view), we're closing a couple of 
POPs and replacing them with extended reach.  Now, I'm swapping them out 
1 by 1 and shipping them here to wipe and install 2.0 -current.  

Oh well, that's the same as I had to do when the same machines were 
taken over by the OpenBSD OpenSSH exploit a few years back. (sigh)


> Now if we had a second machine (and admin resources) to experiment on,
> that'd be different.
> 
I wonder what happened to the older machines just swapped out for 
anoncvs?  Maybe something is available out there after all? 

MANY THANKS for the friendly and informative answer! :-)


Thor Lancelot Simon pontificates:
> 
> I know you're plenty well-informed, and plenty intelligent, to 

<ad hominem attack elided>

Your disparaging tautology is deliberately offensive.
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32