My advisor chaired SOSP this year and asked a bunch of the PC members to give talks about their work during the morning after the meeting. He did a similar thing 3 years ago for SIGCOMM as well and it’s a lot of fun and just stunningly cool to have this number of good talks in a single half-day.
Andrew Myers presented Civitas which is an approach to doing verifiable voting with a bunch of fancy crypto. The two really cool things they did were (1) actually implementing the protocols and pieces of what they propose and (2) providing coercion resistance. It’s cool stuff, but is way complicated. There provide more assurances than any “real world” voting systems presumably because they don’t assume control of the voting location anymore.
Nickolai Zeldovich presented work on how to make security plans explicit to avoid the frustratingly simple security bugs with SQL injection and cross-site scripting attacks. It seemed relatively straightforward and simple if a significant implementation effort, but that’s exactly what we need. The idea is basically to formalize the idea of having export filters for sensitive data and pass those filters along with the data even when you push it out to the file system or the database. They do it with something like 15,000 lines of changes to the PHP interpreter and see about 30% performance overhead for real workloads. Simple idea seemingly done right and actually built.
Peter Chen talked about how he teaches computer systems to freshman with a little programming experience. The course is crazy ambitious and involves designing their own simple microprocessor, building device drivers in assembly, and finally building some kind of music synthesizer (whatever the students want that to mean) all in a 13 week semester class. The demos he gave were really cool, and he claimed that it wound up being a reasonable amount of work for students. About 12 hours/week in 4 person groups. Cool if he’s telling the truth.
John Osterhout talked about why we should build high-performance data stores in the data center/cloud computing world by keeping all data in DRAM. The idea here is that you can cram 64 GB of DRAM “cheaply” in a 1u server and at the same time disks aren’t getting any faster. We should (and already are in many cases) be storing anything for which performance matters entirely in DRAM. There was a lot of good discussion about various things like the energy costs involved, whether the workloads really demand that everything be in RAM, how much of this is already being done and so on. He also has the quote of the day with: “I am the energy anti-Christ.” Single DRAM DIMMs cost something like 10 watts. Its much more energy expensive to store data in ram, but is apparently actually cheaper in terms of operations per second.
Dave Anderson talked about FAWN which is replacing traditional servers with 10-20 little wimpy boards with embedded CPUs and some big piece of flash memory attached to them. Claims (somewhat convincingly) that they get a 10x improvement in energy costs for big data operations. The key point he makes is that there’s a huge imbalance between CPU, storage throughput, memory throughput, etc. and it’s easier to bring these into balance (and thus become more power efficient) with wimpier nodes. Very cool stuff made surprisingly real, though still mostly proof of concept. People commented at the end that this is really a solution to pin bandwidth and bus latency and happens to help with power.
Mothy Roscoe presented and interesting vision of the future of cloud computing where we talk about what a personal “computer” will look like as we go forward. He defines computer (somewhat aptly) in as the combination our data and what we do with it, so this likely spans you phone, laptop, home server as well as some VMs in the cloud and possibly services. What they actually built is Rhizoma which basically runs as a “sidecar” to what you really want and acquires resources for you based on a constrained-logic program policy that you express about the kinds of resources you want and the value you place on them. Think of it as the brain of the cloud which intelligently moves your stuff around as the situation changes. Cool idea, some preliminary data about it moving around PlanetLab as load and network conditions changed gives an idea that this might do something like reasonable.
Steve Hand talked about his experience with the start up around Xen and basically told the narrative of how they got there and what they did. The story was interesting, but I’m a lot less able to condense it down, so instead I’ve mostly just transcribed some of his notes along with his 8 lessons in the slides.
- Play to your strengths. Hire where you know what’s going on and where you have contacts, connections, etc. Don’t let VCs, CEOs, CTOs throw you into growing too quickly in ways that aren’t going to obviously help.
- Ambition can be deadly. Took 1 year to release a buggy, over ambitious, so-so product.
- Vet your co-founders. Abrasive, megalomaniacal, bullying people will cause you problems. Not-so-smart people hire people who are less smart than they are and so on. Eventually VCs helped to push out the CEO and CTO.
- Smart business folk exist. There are very good business people out there, but not very many of them.
- OSS is (mostly) good. Viral marketing/coverage saves money, gets you mind-share. The fact that other people can (and do) take your code, this means you need to (and are driven) to maintain your edge. Problem with weak offerings diluting brand needs to be dealt with.
- People are everything. Hire the best people you can, they are your entire capital especially when you’re open source, not patents. Both engineers and management.
- Ship products early and often. One in ten start ups actually ever ship a product of any kind. First release was 21 months after founding of company and they sold only 5 copies. Aimed for 3 month release cycle: 4 weeks dev, 4 weeks test, 4 weeks package/ship. Helped a lot!
- Arranging a marriage. Needed to find somebody who didn’t offend anyone they had to work with. Citrix wound up being a good choice.
