[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: suggestion
> because the code is currently being reviewed and tested for function, not
> for correctness and security.
Well, the question was rhetoric. However, from the tester's point of view,
is functional code correct?
> I would like to suggest that we take one specific kernel version that is
> in
> widespread use TODAY and concentrate on it. in order to avoid duplication
> of efforts, we should follow along with future versions (i.e. read the
> changelog) but stick with the kernel we have choosen.
>
> there are three reasons for this:
>
> 1) it's a hell of a lot easier and less time consuming, because you don't
> have to constantly re-evaluate everything
You contradict yourself. Newer releases will introduce new portions of
code and we'll have to start over again each time.
> 2) it's what people experienced in this kind of work do - see *BSD,
> especially OpenBSD. does anyone remember their kernel-schedule?
Not me. I don't know much of *BSD. I'm trying to figure what _we_ would
need, not them.
> 3) there's no real reason to NOT do it this way.
Same as there's no reason not to start with the code that won't be changed
and proceed to the evolving versions.
> the very large majority of
> production systems are frozen at a some (usually arbitrary) version
> anyways.
Yes. My production system is frozen at 2.0.38. But that's not a majority.
We don't have exact figures at hand, so let's not appeal to any whimsical
majority.
---
"Teddy - I suppose Mummy and Daddy are real, aren't they?"
Teddy said, "You ask such silly questions, David. Nobody knows what
'real' really means. Let's go indoors."
Brian W. Aldiss, Supertoys Last All Summer Long
Kernel-audit: discussion list for security and the linux kernel
Archive: http://mail.nl.linux.org/kernel-audit/