Skip to main content

HotOS XIII Call for Papers

I am pleased to announce that the call for papers for the Thirteenth Workshop on Hot Topics in Operating Systems (aka HotOS XIII) has been announced. I am fortunate to serve as the program chair and we have put together a fantastic program committee for the workshop, which will be held from May 8-10, 2011 in Napa Valley (think good wine and fantastic food... No promises yet on whether Thomas Keller will be doing the catering). While it's a long ways off, it never hurts to start thinking ahead about what you want to submit! The paper deadline is January 15, 2011.

A few words about HotOS and my own philosophy behind the workshop. HotOS has been the flagship venue for bold new ideas in the systems community over the years. It is often the first place that we hear about new projects and exciting ideas, and it's also a place for grad students to float their crazy thesis plans before submitting full papers to places like SOSP and OSDI. Just to be clear on the format: HotOS submissions are five-page position papers, which are not to be confused with miniature versions of full conference papers (i.e., with half-baked ideas and none of the graphs). The best submissions to HotOS are those that challenge widely-held assumptions, make a clever or unorthodox argument, and get people thinking and talking. In my opinion, the ideal HotOS paper has a strongly-worded idea that gets people working on new problems, without concern for how practical the idea is in the short term. Graphs and early prototype results are actually a negative here -- if your idea has progressed to that point, it is probably not a good candidate for HotOS.

One common complaint about HotOS is that it is sometimes heavily loaded with "SOSP preprints," and indeed, there is a pretty high conversion ratio from HotOS paper to SOSP paper in the same year. Not everyone thinks this is a bad thing and I agree this does serve a certain purpose. As program chair I plan to exert my influence to keep things focused on the bleeding edge, but I also respect that different members of the TPC will have their own taste for different styles of papers.

Beyond the technical content, HotOS serves an important role of building ties between members of our community, and especially to help grad students get a chance to engage, mano a mano, with more senior folks in the field. Mentorship is an incredibly important part of the workshop. I'll never forget my first HotOS and the chance to bat around ideas with such luminaries as Jay Lepreau. There is also a fair bit of, shall we say, enology involved at HotOS, which certainly makes things more interesting (distributed hash tables have never been more fascinating!). There is a huge difference between meeting folks at a 400+ person conference versus a small workshop where people are more likely to let their guard down.

I want to build upon this tradition and make HotOS more inclusive to new folks and less-represented research groups. I am going to be on the lookout for unusual, bold, oddball papers from outside of the "conventional" systems community, with the hope of shaking things up a bit, but it's safe to say that there will be plenty of familiar faces as well. If you have a nutty idea, by all means submit it. I'm going to try to tease apart novelty from "solid work" in the reviewing process, and take a range of papers that have different kinds of strengths. We'll also be inviting some folks who don't submit papers at all just to be sure we have a good mix of disciplines and groups represented.

If you have thoughts or suggestions for HotOS, please feel free to drop me a line or post comments here. And I look forward to your submissions!


  1. This is the most energizing CFP I've ever seen, particularly for grad students. Thanks Matt!

  2. Michael MitzenmacherApril 8, 2010 at 6:02 PM

    Does this mean you'll perhaps be more open to more theoretical papers, where there may not be a plan for an implementation -- indeed, it may not be clear how to implement the underlying idea -- if it fits your criteria: "challenge widely-held assumptions, make a clever or unorthodox argument, and get people thinking and talking."?

  3. Your plan is admirable, but I speculate it's hard to reject a 5-pages "summary" of a soon-to-be SOSP paper in favor of a genuine position paper. I'd therefore be rather surprised if you achieve your goal; though I certainly hope you would. One thing is for sure though: it'd be easy to measure your success. Good luck!


Post a Comment

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…