More eyeballs please, nom nom

It’s always a little disturbing getting a peek inside the sausage factory, especially when it comes to software and developers I have irrational faith in – like any project involving cryptography. We would all like to believe that “given enough eyeballs, all bugs are shallow,” and that open sourcing your software means you can have as many eyeballs as you like.

This quote from Theo De Raadt in reply to a question about the alleged IPSEC backdoor reminded me uncomfortably of the reality of open source:

> where would you start auditing the code? It’s just too much.

Actually, it is a very small part of the tree. If we all do our part, it will get better. It still won’t be perfect. It is just too big.

For some reason, this exchange shocked me – the IPSEC code in BSD is simply too large to review every line given the number of developers they have. But… but… it’s… cryptography… Yes, Valerie, there is no Santa Claus!

This reminds me of something I’ve been worrying about for a while: the VFS could use more eyeballs. Al Viro and Christoph Hellwig are absolutely heroic developers who work way too hard, but the volume of work they have to deal with is just too big for two human beings. Right now, outstanding patch sets to the VFS include Nick Piggin’s VFS scaling work, David Howells’ d_automount() rewrite, and union mounts.

Exercise for the reader: How do we attract more developers to the VFS?

2 thoughts on “More eyeballs please, nom nom”

  1. How do we attract more developers to the VFS? Lower the learning curve. Kernel hacking, and file system hacking, feels like rocket science… (or magic, whichever is harder to do.)

  2. In a word, mentorship

    The VFS is one of the scarier places in the kernel to hack, and for good reason – there’s a lot going on there.

    There’s just a large body of knowledge you need to be able to do anything useful – not so much how things work, the stuff you can get reading the code, but the why of it – history. To the extent a lot of that stuff is written down it’s scattered around on mailing lists, it’s not particularly accessible for anyone trying to learn their way around.

    But you’re asking for something harder – not how do we educate people well enough to do useful work, but how to get people both qualified and experienced enough to vet other people’s work.

    And as someone on the outside looking in, if you even had any interest in that kind of thing, how’d you go about making a living at it? There’s obvious markets for writing device drivers, implementing random functionality – but that kind of deep design type work – even if you have the aptitude for it, and you were masochistic enough, the path to a paying job ain’t an easy one.

    Anyways, what’s the point? The VFS is mature – there’s not a lot of exciting, user visible stuff going on there anymore, and it seems to me like it’s pretty well mined out in that respect. There’s cool functionality in there (the shared subtree stuff) that hardly anyone even knows about.

    Although, if someone could figure out a way to break backwards compatibility and fix stuff analagous to plan9, without breaking stuff too much… I can dream, can’t I? Get rid of the inode/dentry split, the readdir stuff… Life would be awesome :p

Comments are closed.