« A MovableType PlugIn for MicroIDs | Main | Apple at 30 Years »
March CTO Breakfast Report
This morning’s CTO breakfast had around 30 people in attendance. As always, the conversations was geeky and varied. Here are a few things I took notes on.
We had a discussion of Ruby and how it’s always at the bottom of the lisp. The facts of the matter, however that in most Web applications (where Ruby seems to have found it’s sweet spot) the CPU and language aren’t the bottleneck. What is? Database communication. Someone mentioned that this podcast with Jamis Buck that discusses the scalability of Ruby Web apps.
We had lots of discussion on virtualization. I brought up rumors that OS Tiger will include native virtualization. Devlin Daley reported that the Intel Dual Cores that Apple is shipping now contain hardware virtualization primitives. We also talked about running Linux on IBM mainframes and Sun’s Niagara.
Someone asked why disks seem slower. I brought up this interview with Jim Grey. The main trust of the article is that disk density is increasing ten times faster than access speeds. The end result is that we are very close to having what looks, for all intents and purposes, like infinite storage capacity but not being able to access it fast enough. In fact, the speed to density ratio is approaching that of tape.
Daniel Bray wondered if federated databases we one way to deal with this problem. We talked about the possibility of building arrays of microdrives to decrease access time. I brought up some research by Kelly Flanagan that explores putting multiple copies of the same sector on the disk and then seeking to the closest one. This is essentially creating a virtualized array of disks.
Robert Merrill brought up Fon, a share and share alike wireless system. You can use the access points of Fon members as long as you’re willing to let them use yours. Maybe not so helpful in Lindon Utah, but it could be very interesting in an urban setting.
We briefly discussed OpenVPN, a open-source VPN implemented on top of SSL. I’ve been looking for something like this, so I was glad to hear about it. OpenVPN apparently can run as a IP Cop plugin in addition to standalone mode.
Ning came up for the second month in a row. Time to go look at it, I guess. You can move your code, but Scott Lemon has been hacking some apps on it. There’s some danger of lock in because of the proprietary Ning API for data storage. Ning makes money by charging to protect your source (the standard Chicago protection racket business model), additional storage, private URLs, and so on.
For IIW, I put together a map of the hotels nearby. Actually, I stole it from MashUp Camp since they were in the same place and reentering all that data seemed like a waste of time. But they built it using MapBuilder.
Devlin Daley had the closing point and brought up Huddletogether’s LightBox. You have to go see it to understand what it does. Not only is it easily the coolest thing I’ve seen for a few weeks, but it’s also dirt simple to put on your site. Here’s an example of Lightbox with some pictures from ETech06.
Click on an image to view the full sized image. Mouse over the side of the image to see a “next image” arrow that takes you to the next image in the set. Clicking on the X, of course, closes the window and brings back the browser.
There were enough things like this today that I was thinking that it would be a good idea to bring a projector and have a bit of time at the front end for “five-minute demo.” Kind of like open mic night, five-minute demo would have anyone who wanted it five minutes at the projector to demonstrate something cool that they’ve done or that they’ve seen. Let me know your thoughts.
Posted by windley on March 30, 2006 2:42 PM





Comment from Robert Merrill at March 30, 2006 2:56 PM
Great forum this morning, Phil. Thanks for hosting!
Comment from Michael Neale at March 30, 2006 4:13 PM
Interesting comments on scaling with Ruby and the DB being a bottleneck. I had been looking at how ruby scales recently - it just pushes everything out onto the database, which is fair enough I guess.
I was used to building web apps which aggresively cache, and have distributed transactional caches to get rid of the DB bottleneck. I appreciate the back to basics approach of ruby, but I fear that it will have to go through the same growing pains when people really need to scale. Scaling a RDBMS is much much harder then scaling the app tier. (and more expensive).
Comment from Stefan Tilkov at March 31, 2006 7:45 AM
Michael, while I advocated the same position for a long time, I wonder whether it is still true. With today's machines and a typical workload, I think it's hard to come up with requirements that exceed what scaling you can get from your DB in a cost-efficient way.
Comment from Yoz at March 31, 2006 8:26 AM
Let me know if you have Ning-related questions or problems; I'm one of the Developer Advocates.
I wouldn't say that the storage API is proprietary as such; while it's not exactly open in the traditional sense, the spec is fully available for anyone to use and reimplement as they wish. The reason why it's different from others is purely because the underlying storage is different, being a cross-application object store (which *is* proprietary) rather than a traditional per-application relational DB. However, our business model does not rely on API lock-in, and we'd have no problems if anyone wanted to reimplement it for running on top of, say, MySQL, and thus make apps more transportable off the system. We're not interested in keeping customers by locking them in; we want to keep them by being the best option for what they want to do. All of an app's data is already easily exportable in a number of ways, most recently with our Atom API.
Similarly, source "protection" is from viewing and cloning, rather than any kind of editing - no apps can be edited by anyone who isn't the owner. We charge people for not sharing code with others.
Anyway, I'd be happy to chat if you have more questions or need help with experimentation: yoz (at) ning.com.