User: Password:
Subscribe / Log in / New account

A more useful metric

A more useful metric

Posted Sep 9, 2008 21:47 UTC (Tue) by drag (guest, #31333)
In reply to: A more useful metric by spender
Parent article: Kernel security, year to date

> So if you're patting yourselves

Who are you talking to?

(Log in to post comments)

A more useful metric

Posted Sep 9, 2008 21:58 UTC (Tue) by sbishop (guest, #33061) [Link]

Those of us reading LWN...

So Spender isn't a writer; that's fine. But his comments provide enough content to justify content in return, I think.

A more useful metric

Posted Sep 9, 2008 23:13 UTC (Tue) by ballombe (subscriber, #9523) [Link]

That just a new fad on lwn comments: Meta-trolling.

Instead of trolling, accuse someone else of trolling! You get basically the same result but you have 'the moral high ground'(tm).

If you are lucky, people believe you were responding to a comment that have been deleted (!) and you can enjoy the ensuing confusion.

Maybe I am old fashioned, but I find trolls less painful than self righteous meta-trolls. (this post is intended as a meta-meta-troll).

A more useful metric

Posted Sep 9, 2008 23:50 UTC (Tue) by drag (guest, #31333) [Link]

Well thanks for the attention!


A more useful metric

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

I never meta-troll I didn't find annoying.

(sorry sorry)

A more useful metric

Posted Sep 10, 2008 5:01 UTC (Wed) by paulj (subscriber, #341) [Link]

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...

A more useful metric

Posted Sep 10, 2008 6:31 UTC (Wed) by drag (guest, #31333) [Link]

Sure sure. All apologies.

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!)

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds