Skip to main content

HotOS 2009, Day One

The Twelfth Workshop on Hot Topics in Operating Systems (HotOS) is under way this week in Ascona, Switzerland, at a former nudist colony called Monte Verità. (Sadly, this aspect of the locale has not had much influence on the attendees.) HotOS is about pushing the boundaries of our field and defining new research agendas. It is typically held in a remote, beautiful location and involves an unhealthy amount of alcohol. It's also by invitation only and you usually have to get a paper accepted to attend. This year there were 84 paper submissions and 22 papers accepted.

A few highlights from Day One...

Adam Greenfield, Nokia gave a keynote talk on The Elements of Networked Urbanism. Adam painted a very broad picture of the impact of new technologies on how people in cities connect, share information, and learn about their environment. Of course, this topic is near and dear to my heart since one of my projects is building a city-scale wireless sensor network. Adam's premise is that every physical object in a city (fire hydrants, streetlights, slabs of pavement) will be networked and addressable, turning them into networked and interactive resources, not just passive objects. (Personally, I think this a bit off mark --the fact that you can give every physical object an IPv6 address doesn't mean it makes any sense to talk to it. The real issue is the protocol, not the addressing.) Adam touched on many issues -- technical, legal, social, and economic -- tying into this vision. I wish he had said more about how this will impact the poorest denizens of the world's cities, and though he mentioned the slums of Mexico City, Manila, and Nairobi, it wasn't clear how "networked urbanism" help these people very much.

Margo Seltzer got the technical sessions off to a great start with a talk on Hierarchical Filesystems are Dead. She probably made it through two slides before the ornery audience started peppering her with questions - exactly what I like to see at HotOS. Her basic argument is that files are objects with multiple attributes and forcing them into a hierarchical namespace conflates naming and storage. The proposed approach is to allow users to build their own personalized namespaces for objects (in any structure they see fit) and apply well-established techniques from the Web (like bookmarks and search).

Colin Dixon argued that we should banish network middleboxes as too expensive, complex, and difficult to manage. The talk was focused on enterprise networks (Cisco middleboxes cost several thousand dollars) and ignored the prevalance of cheap (essentially free) middleboxes in home networks. He argued that end hosts are overprovisioned so it's better to run middlebox services at the edge where they are easier to manage. (I'm not sure I buy this. It seems easier to manage a single middlebox than a bunch of possibly misconfigured end hosts.) Also, the assumption of overprovisioned hardware doesn't necessarily hold for smartphones, which are increasingly important as network clients. (Colin's response to my question on this was that you should run a proxy for smartphones. But that's a middlebox. This probably deserves a bit more thought.)

Bingsheng He from Microsoft Research Asia talked about a new apporach for optimizing dataflow queries in clouds, called wave computing. The basic idea is to co-optimize multiple concurrent queries running within a framework like DryadLINQ or MapReduce to reduce redundant computation and I/O. It wasn't clear to me how this relates to conventional multiquery optimization in database systems; Bingsheng's response was that this is a hybrid approach between conventional query optimization and streaming query optimization.

Byung-Gon Chun from Intel Research Berkeley made the case for automatic partitioning of smart phone apps between the phone and a back-end cloud. The idea is to run a "clone" of the phone image in the cloud and use it to do things like background processing, verification, and running heavyweight computations that you can't do on a phone. The proposed approach involves partitioning and migration of process state between the phone and the cloud. This strikes me as unnecessarily complex. After all, most smartphone apps are already partitioned between the phone and a back-end service -- Byung-Gon suggested that this was painful and complex for programmers, but thousands of iPhone apps and hundreds of millions of users of services like Facebook suggest otherwise.

Prabal Dutta from Berkeley made the case that mobility changes everything in sensor networks. He focused on "mobiscopes" involving mobile sensors that collect data from their environment and exchange messages opportunistically. The key idea is that if a sensor can detect and characterize its own mobility, the networking stack can use this information to do a better job at link estimation, routing, and so forth. He described some cool new hardware that has a hardware vibration detection circuit that can wake itself up when it starts moving.

Jason Waterman gave the talk for our paper on Peloton. He got a lot of good questions, mostly dealing with concerns about the overhead of our proposed global tuple space for sharing resource state across nodes. Michael Scott made the point that a "one size fits all" approach probably won't work well. That's undoubtedly true, just as it is true for the wide range of services we have built up in more conventional distributed systems (RPC, shared memory, you name it). The question is whether the overhead of our underlying mechanisms can be recouped through better coordination between nodes in managing their resources.

Over dinner, I got a chance to gab with Mothy, Dave Anderson, Garth Gibson, Prabal, George Candea, Michael Kaminsky, and Shivnath Babu on a wide range of topics, including my wacky idea about "The Next Billion Programmers". I'll blog on that one later.

Comments

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…