A more useful metric [LWN.net]

A more useful metric

Posted Sep 10, 2008 5:01 UTC (Wed) by paulj (subscriber, #341)
In reply to: A more useful metric by drag
Parent article: Kernel security, year to date

He's assuming an audience for his comment, a sceptical or even hostile audience at that. It's a pretty obvious rhetorical device.

I despise myself slightly for adding to it, but do we really need to open a *second* sub-thread commenting on the style of spender's commenting? His posts are otherwise are very relevant and interesting, and the true audience here are surely intelligent enough to be able to sidestep the style issues...

(Log in to post comments)

A more useful metric

Posted Sep 10, 2008 9:05 UTC (Wed) by nix (subscriber, #2304) [Link]

His posts are very intelligent and interesting, but they lead to only two questions that I can see, one of which has been answered and the other of which may have no answer:

- can we fix the bugs? obviously yes, but then we get accused of cover-ups unless we raise the roof over every single bug: and see past posts from Al Viro about why it's ridiculously impractical to go via vendor-sec for every such bug: if major kernel developers refuse to use it because it's such an embargoing straitjacket, then castigating people because they don't use it is a waste of time.

- can we change things so that the bugs aren't introduced so fast? Maybe, but so far no method has been proposed that doesn't have the kernel developers recoiling in horror, and if a magic development method was known that avoided all security holes and didn't utterly devastate development rates, everyone would already be using it. (e.g. formal proving of absolutely everything from the spec on down reduces security holes, but is horrible for development. Multi-person review of every change, a-la OpenBSD, does the same, but a chronic lack of reviewers makes that hard: and areas like mm are sufficiently subtle that few people are qualified to be reviewers at all.)

Going back to even/odd doesn't strike me as being likely to happen, given that that system was imploding under the much lower change load that preceded git. A more rapidly alternating .26-is-stable .27-is-unstable scheme might work, but I'm not sure what that means other than giving a formal number to the post-merge-window -rc1 kernel, and I'm not sure how *that* would help. (It might encourage people to test the -rcs, I suppose!)