Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://anil.recoil.org/notes/unikernels-test-of-time",
3 "title": "Unikernels wins the ASPLOS most influential paper award",
4 "link": "https://anil.recoil.org/notes/unikernels-test-of-time",
5 "updated": "2025-04-12T00:00:00",
6 "published": "2025-04-12T00:00:00",
7 "summary": "<p>I was gobsmacked to get a note from the SIGARCH <a href=\"https://www.asplos-conference.org\">ASPLOS</a> steering committee that our 2013 paper "<a href=\"https://anil.recoil.org/papers/2013-asplos-mirage\">Unikernels: library operating systems for the cloud</a>" won the <a href=\"https://www.sigarch.org/benefit/awards/acm-sigarch-sigplan-sigops-asplos-influential-paper-award/\">most influential paper</a> award at the conference last week! I couldn't make it to Rotterdam myself due to the <a href=\"https://www.businesstraveller.com/forums/topic/reminder-no-direct-eurostar-amsterdam-rotterdam-london-for-six-months/\">travel time</a>, but <a href=\"https://github.com/mor1\">Richard Mortier</a> was <a href=\"https://mort.io/blog/tdis-accepted/\">already there</a> and so accepted the award on the whole team's behalf!</p>\n<p>My officemate <a href=\"https://en.wikipedia.org/wiki/Simon_Peyton_Jones\">Simon Peyton Jones</a> pointed out to me that these 'test of time' awards are his favourite, as they indicate that a piece of research was actually useful over a number of years to other people in the field:</p>\n<blockquote>\n<p>The ASPLOS Influential Paper Award recognizes historical ASPLOS papers that have had major influence on the field. The Program Committee nominates highly influential papers from any ASPLOS conference that occurred ten or more conferences ago, with the final selections being made by the ASPLOS Steering Committee.\n-- <a href=\"https://www.sigarch.org/benefit/awards/acm-sigarch-sigplan-sigops-asplos-influential-paper-award/\">SIGARCH awards</a></p>\n</blockquote>\n<p>\n<img alt=\"Mort rocking the award with customary peak-geek EDSAC t-shirt\" src=\"https://anil.recoil.org/images/asplos25-award-1.webp\" title=\"Mort rocking the award with customary peak-geek EDSAC t-shirt\">\nMort rocking the award with customary peak-geek EDSAC t-shirt</p>\n<p>My long-time colleague <a href=\"https://github.com/djs55\">Dave Scott</a> wrote up a great overview of why <a href=\"https://dave.recoil.org/unikernels/\">he likes unikernels</a>, especially in areas like <a href=\"https://anil.recoil.org/\">Docker</a> where he is a senior maintainer these days. Dave uses a nice jigsaw puzzle analogy to show the value of a library operating system approach when building complex systems glue; they're good for high assurance applications, for rapid experimentation and iteration, and for deep systems customisation.</p>\n<h2><a href=\"https://anil.recoil.org/#i-almost-rage-quit-academia\"></a>I almost rage-quit academia</h2>\n<p><a href=\"https://github.com/mor1\">Richard Mortier</a>'s <a href=\"https://mort.io/blog/happy-day/\">note</a> brought up some memories about how this particular work made me almost rage-quit academia entirely. Back in 2009 after I returned to academia with <a href=\"https://horizon.ac.uk\">Horizon</a> fellowship, I spent a year of my life working on lots of libraries for the very first iteration of MirageOS, and published a USENIX <a href=\"https://anil.recoil.org/papers/2010-hotcloud-lamp\">workshop paper</a> on it.</p>\n<p>After that, it was time to do the full conference paper, so I spent another year (joined by more colleagues like <a href=\"https://github.com/samoht\">Thomas Gazagnaire</a> and <a href=\"https://github.com/djs55\">Dave Scott</a> in the <a href=\"https://anil.recoil.org/projects/unikernels\">early</a> days) bringing yet more OCaml libraries to life to make the thing actually useful. <a href=\"https://www.lancaster.ac.uk/scc/about-us/people/charalampos-rotsos\">Charalampos Rotsos</a> and <a href=\"https://github.com/mor1\">Richard Mortier</a> spent forever on an OpenFlow implementation in pure OCaml; <a href=\"https://github.com/balrajsingh\">Balraj Singh</a> sorted out the mess I made of the TCP stack congestion algorithms; <a href=\"https://github.com/sos22\">Steven Smith</a> hacked on Xen with me to add immutable pfn support. There was a lot of intense hacking going on.</p>\n<p>We then trimphantly wrote up our work as a submission to OSDI 2012 after staying up all night for several days in a row to get the evaluation done, and... it got rejected. But the paper didn't <em>just</em> get rejected, it got rejected so hard that I couldn't bear to look at another OSDI proceedings for years. So hard that I can still the weight of the punch of that email as I opened it eagerly, a decade on. Some of our colleagues also had rejected OSDI papers that year; the <a href=\"https://www.microsoft.com/en-us/research/project/naiad/?from=https://research.microsoft.com/en-us/projects/naiad/&type=exact\">Naiad</a> paper got six reviews but bounced (later to win best paper at <a href=\"https://sigops.org/s/conferences/sosp/2013/\">SOSP 2013</a>), and <span>Andrew Warfield</span> had another that got nine (!) reviews before being shown the door. But ours got...three reviews indicating it bounced in the very first round, and one review scored us at '1/5', the lowest possible value. It made all that intense work seem like a total waste of our lives.</p>\n<p>But then... one of the reviews shone out like a beacon. It was the longest review, and was <em>full</em> of directly actionable feedback. It began very constructively:</p>\n<blockquote>\n<p>The approach described in this paper is a very reasonable design point,\na natural intersection of the exokernel and libOS and the type-safe OS.\nIt would help to refocus the abstract and intro on the precise benefits that\nUnikernel can provide, and to attribute each benefit to its origin. Let me\ntake a stab at this, based on my read of the paper:</p>\n</blockquote>\n<p>The reviewer then reinterpreted our submission to add more clarity:</p>\n<blockquote>\n<ul>\n<li>"eliminate several classes of security threats via type-safety" -- clearly due to the top-to-bottom use of type-safe OCaml.</li>\n<li>"eliminate several classes of security threats via ... an address-space which can be made immutable" -- is there any reason an analogous technique could not apply to a libOS version of libc?</li>\n<li>"progressive specialization" -- I didn't find this contribution very exciting. It's nice that I can execute the same OCaml app in a Linux context to debug it; perhaps this is especially important since we don't yet have good symbolic debuggers for OCaml apps standing alone in a VM. But it really doesn't seem like a central benefit.</li>\n<li>"developers no longer need to become sysadmins" -- This claim is specious. If a third party packages an app together with a Linux guest-OS stack to become an appliance, there's no reason that appliance would require any sysadmin-ish behavior more than a Unikernel appliance.</li>\n<li>"The resulting unikernels are also highly compact" -- Could this property not also be readily achieved with a tuned libc-based (that is, not type-safe) libOS? How precious is this property? Is the <em>working set</em> actually much smaller? And finally, how much of the reduction is because the rewritten application is much less functional than the industry standard it replaces?\n[...the review continues on for several pages]</li>\n</ul>\n</blockquote>\n<p>Now, I didn't <em>agree</em> with all the points in the review, but they were restructured in such a way that made it clear that the reviewer had really thought about it, and had tried to pull out their own insights from the system construction. We ate up this feedback, and resubmitted it in a matter of weeks to ASPLOS adopting much of the structure suggested by this OSDI reviewer, and the paper got in with accepts across the board.</p>\n<p>The best bit of all this? The OSDI reviewer voluntarily <em>unblinded</em> their review:</p>\n<blockquote>\n<p>Review by Jon Howell <a href=\"mailto:howell@microsoft.com\">howell@microsoft.com</a>, intentionally unblinded.</p>\n</blockquote>\n<p>Jon's obviously an expert in the field (his own 2011 paper on <a href=\"https://dl.acm.org/doi/10.1145/1961296.1950399\">Drawbridge</a> won the ASPLOS influential paper award last year), but it's how much time he took in helping out a sibling system that stuck with me. His kind, constructive and direct review kept me in academia, and although I still haven't met him in person (life got really busy right afterwards with <a href=\"https://anil.recoil.org/notes/docker-buys-unikernel-systems\">Unikernel Systems</a>), I definitely still owe him a pint!</p>\n<h2><a href=\"https://anil.recoil.org/#systems-research-a-decade-or-more-on\"></a>Systems research a decade or more on</h2>\n<p>Mort also <a href=\"https://mort.io/blog/happy-day/\">made me think</a> about what we learnt from all this work that current students might learn from.</p>\n<p>You never know which papers will sink or swim in the fullness of time and most never get that popular outside a small niche, so don't worry about that right now when doing the work! Focus instead of honing your systems intuition for <em>why</em> you're building something, and bring out the <a href=\"https://blog.regehr.org/archives/6\">delta of your contributions</a> clearly in the paper. When you're building a complex system, there's a lot of boilerplate and scaffolding necessary, but the core of the "thing that hasn't been done before" is what you know best, and it can take some time and <a href=\"https://en.wikipedia.org/wiki/Rubber_duck_debugging\">conversations</a> to figure out what that is.</p>\n<p>\n<img alt=\"In the much missed Flying Pig...with Jon\" src=\"https://anil.recoil.org/images/jc-flyingpig-1.webp\" title=\"In the much missed Flying Pig...with Jon\">\nIn the much missed Flying Pig...with Jon</p>\n<p>Back in the day, most of our discussions about systems research happened after a day of deep hacking down at the pub.\nSince the pandemic, we seem to have lost a big chunk of that social discussion around our work collectively. While I still see people regularly for a swift half, it somehow seems more difficult to gather people in general. Part of that is that I don't go into the department much anymore due to the noise and cold (something <a href=\"https://jonmsterling.com\">Jon Sterling</a> also <a href=\"https://amok.recoil.org/@jonmsterling@mathstodon.xyz/114318437109811024\">observed recently</a>), <em>vs</em> my cosy Pembroke office.</p>\n<p>I'm not sure if it's just me or everyone else also feeling this, but I'm so zoned out after even a few Zoom calls that I'm just not very social afterwards. So one thing I'm aiming to do more consciously after Easter is to try to gather people down at <a href=\"https://www.themillpubcambridge.com/\">The Mill</a> more for a swift half (where they serve excellent <a href=\"https://www.guinness.com/en-gb/beers/guinness-zero\">Guinness Zero</a>), and really cut down on remote interactions that aren't necessary.</p>\n<p>\n<img alt=\"In the Kingston Arms...with Jon\" src=\"https://anil.recoil.org/images/jc-kingston-1.webp\" title=\"In the Kingston Arms...with Jon\">\nIn the Kingston Arms...with Jon</p>\n<p>And the last tip is from Barry Schwartz, who noted that <a href=\"https://en.wikipedia.org/wiki/The_Paradox_of_Choice\">the secret to happiness is low expectations</a>. No matter how much works goes into a system, don't bank too much on the big papers making a splash. Instead, enjoy every step of the journey -- from building things, scrapping them, debugging odd failures, throwing ideas around, releasing the software, seeing adoption, scrapping it all and starting again, the whole journey! There will always be a <a href=\"https://link.springer.com/article/10.1007/s40037-021-00670-z\">reviewer 2</a> waiting to ruin your day if you let them, so don't let them in.</p>\n<p>I also wonder how long paper publishing in its current form will survive; with the sheer number of publications coming out these days and the amount of <a href=\"https://anil.recoil.org/notes/ai-contamination-of-papers\">AI generated output</a>, it's difficult to see something published today having the same ramp as the work we did in the past few decades. Instead, adoption and rapid iteration seem to be the way to go. Thankfully, our University intellectual property rights <a href=\"https://www.enterprise.cam.ac.uk/wp-content/uploads/2015/04/IP-Policy-in-Practice-Guidance-Note-25May10-FINAL-CLEAN-Updated-links-August-2015.pdf\">remain liberal</a> (patents aside, but who cares about those these days for software), so there's nothing stopping us!</p>\n<p>\n<img alt=\"In the Mill...with Jon. Remembering our friend Ross!\" src=\"https://anil.recoil.org/images/jc-mill-1.webp\" title=\"In the Mill...with Jon. Remembering our friend Ross!\">\nIn the Mill...with Jon. Remembering our friend Ross!</p>",
8 "content": "<p>I was gobsmacked to get a note from the SIGARCH <a href=\"https://www.asplos-conference.org\">ASPLOS</a> steering committee that our 2013 paper "<a href=\"https://anil.recoil.org/papers/2013-asplos-mirage\">Unikernels: library operating systems for the cloud</a>" won the <a href=\"https://www.sigarch.org/benefit/awards/acm-sigarch-sigplan-sigops-asplos-influential-paper-award/\">most influential paper</a> award at the conference last week! I couldn't make it to Rotterdam myself due to the <a href=\"https://www.businesstraveller.com/forums/topic/reminder-no-direct-eurostar-amsterdam-rotterdam-london-for-six-months/\">travel time</a>, but <a href=\"https://github.com/mor1\">Richard Mortier</a> was <a href=\"https://mort.io/blog/tdis-accepted/\">already there</a> and so accepted the award on the whole team's behalf!</p>\n<p>My officemate <a href=\"https://en.wikipedia.org/wiki/Simon_Peyton_Jones\">Simon Peyton Jones</a> pointed out to me that these 'test of time' awards are his favourite, as they indicate that a piece of research was actually useful over a number of years to other people in the field:</p>\n<blockquote>\n<p>The ASPLOS Influential Paper Award recognizes historical ASPLOS papers that have had major influence on the field. The Program Committee nominates highly influential papers from any ASPLOS conference that occurred ten or more conferences ago, with the final selections being made by the ASPLOS Steering Committee.\n-- <a href=\"https://www.sigarch.org/benefit/awards/acm-sigarch-sigplan-sigops-asplos-influential-paper-award/\">SIGARCH awards</a></p>\n</blockquote>\n<p>\n<img alt=\"Mort rocking the award with customary peak-geek EDSAC t-shirt\" src=\"https://anil.recoil.org/images/asplos25-award-1.webp\" title=\"Mort rocking the award with customary peak-geek EDSAC t-shirt\">\nMort rocking the award with customary peak-geek EDSAC t-shirt</p>\n<p>My long-time colleague <a href=\"https://github.com/djs55\">Dave Scott</a> wrote up a great overview of why <a href=\"https://dave.recoil.org/unikernels/\">he likes unikernels</a>, especially in areas like <a href=\"https://anil.recoil.org/\">Docker</a> where he is a senior maintainer these days. Dave uses a nice jigsaw puzzle analogy to show the value of a library operating system approach when building complex systems glue; they're good for high assurance applications, for rapid experimentation and iteration, and for deep systems customisation.</p>\n<h2><a href=\"https://anil.recoil.org/#i-almost-rage-quit-academia\"></a>I almost rage-quit academia</h2>\n<p><a href=\"https://github.com/mor1\">Richard Mortier</a>'s <a href=\"https://mort.io/blog/happy-day/\">note</a> brought up some memories about how this particular work made me almost rage-quit academia entirely. Back in 2009 after I returned to academia with <a href=\"https://horizon.ac.uk\">Horizon</a> fellowship, I spent a year of my life working on lots of libraries for the very first iteration of MirageOS, and published a USENIX <a href=\"https://anil.recoil.org/papers/2010-hotcloud-lamp\">workshop paper</a> on it.</p>\n<p>After that, it was time to do the full conference paper, so I spent another year (joined by more colleagues like <a href=\"https://github.com/samoht\">Thomas Gazagnaire</a> and <a href=\"https://github.com/djs55\">Dave Scott</a> in the <a href=\"https://anil.recoil.org/projects/unikernels\">early</a> days) bringing yet more OCaml libraries to life to make the thing actually useful. <a href=\"https://www.lancaster.ac.uk/scc/about-us/people/charalampos-rotsos\">Charalampos Rotsos</a> and <a href=\"https://github.com/mor1\">Richard Mortier</a> spent forever on an OpenFlow implementation in pure OCaml; <a href=\"https://github.com/balrajsingh\">Balraj Singh</a> sorted out the mess I made of the TCP stack congestion algorithms; <a href=\"https://github.com/sos22\">Steven Smith</a> hacked on Xen with me to add immutable pfn support. There was a lot of intense hacking going on.</p>\n<p>We then trimphantly wrote up our work as a submission to OSDI 2012 after staying up all night for several days in a row to get the evaluation done, and... it got rejected. But the paper didn't <em>just</em> get rejected, it got rejected so hard that I couldn't bear to look at another OSDI proceedings for years. So hard that I can still the weight of the punch of that email as I opened it eagerly, a decade on. Some of our colleagues also had rejected OSDI papers that year; the <a href=\"https://www.microsoft.com/en-us/research/project/naiad/?from=https://research.microsoft.com/en-us/projects/naiad/&type=exact\">Naiad</a> paper got six reviews but bounced (later to win best paper at <a href=\"https://sigops.org/s/conferences/sosp/2013/\">SOSP 2013</a>), and <span>Andrew Warfield</span> had another that got nine (!) reviews before being shown the door. But ours got...three reviews indicating it bounced in the very first round, and one review scored us at '1/5', the lowest possible value. It made all that intense work seem like a total waste of our lives.</p>\n<p>But then... one of the reviews shone out like a beacon. It was the longest review, and was <em>full</em> of directly actionable feedback. It began very constructively:</p>\n<blockquote>\n<p>The approach described in this paper is a very reasonable design point,\na natural intersection of the exokernel and libOS and the type-safe OS.\nIt would help to refocus the abstract and intro on the precise benefits that\nUnikernel can provide, and to attribute each benefit to its origin. Let me\ntake a stab at this, based on my read of the paper:</p>\n</blockquote>\n<p>The reviewer then reinterpreted our submission to add more clarity:</p>\n<blockquote>\n<ul>\n<li>"eliminate several classes of security threats via type-safety" -- clearly due to the top-to-bottom use of type-safe OCaml.</li>\n<li>"eliminate several classes of security threats via ... an address-space which can be made immutable" -- is there any reason an analogous technique could not apply to a libOS version of libc?</li>\n<li>"progressive specialization" -- I didn't find this contribution very exciting. It's nice that I can execute the same OCaml app in a Linux context to debug it; perhaps this is especially important since we don't yet have good symbolic debuggers for OCaml apps standing alone in a VM. But it really doesn't seem like a central benefit.</li>\n<li>"developers no longer need to become sysadmins" -- This claim is specious. If a third party packages an app together with a Linux guest-OS stack to become an appliance, there's no reason that appliance would require any sysadmin-ish behavior more than a Unikernel appliance.</li>\n<li>"The resulting unikernels are also highly compact" -- Could this property not also be readily achieved with a tuned libc-based (that is, not type-safe) libOS? How precious is this property? Is the <em>working set</em> actually much smaller? And finally, how much of the reduction is because the rewritten application is much less functional than the industry standard it replaces?\n[...the review continues on for several pages]</li>\n</ul>\n</blockquote>\n<p>Now, I didn't <em>agree</em> with all the points in the review, but they were restructured in such a way that made it clear that the reviewer had really thought about it, and had tried to pull out their own insights from the system construction. We ate up this feedback, and resubmitted it in a matter of weeks to ASPLOS adopting much of the structure suggested by this OSDI reviewer, and the paper got in with accepts across the board.</p>\n<p>The best bit of all this? The OSDI reviewer voluntarily <em>unblinded</em> their review:</p>\n<blockquote>\n<p>Review by Jon Howell <a href=\"mailto:howell@microsoft.com\">howell@microsoft.com</a>, intentionally unblinded.</p>\n</blockquote>\n<p>Jon's obviously an expert in the field (his own 2011 paper on <a href=\"https://dl.acm.org/doi/10.1145/1961296.1950399\">Drawbridge</a> won the ASPLOS influential paper award last year), but it's how much time he took in helping out a sibling system that stuck with me. His kind, constructive and direct review kept me in academia, and although I still haven't met him in person (life got really busy right afterwards with <a href=\"https://anil.recoil.org/notes/docker-buys-unikernel-systems\">Unikernel Systems</a>), I definitely still owe him a pint!</p>\n<h2><a href=\"https://anil.recoil.org/#systems-research-a-decade-or-more-on\"></a>Systems research a decade or more on</h2>\n<p>Mort also <a href=\"https://mort.io/blog/happy-day/\">made me think</a> about what we learnt from all this work that current students might learn from.</p>\n<p>You never know which papers will sink or swim in the fullness of time and most never get that popular outside a small niche, so don't worry about that right now when doing the work! Focus instead of honing your systems intuition for <em>why</em> you're building something, and bring out the <a href=\"https://blog.regehr.org/archives/6\">delta of your contributions</a> clearly in the paper. When you're building a complex system, there's a lot of boilerplate and scaffolding necessary, but the core of the "thing that hasn't been done before" is what you know best, and it can take some time and <a href=\"https://en.wikipedia.org/wiki/Rubber_duck_debugging\">conversations</a> to figure out what that is.</p>\n<p>\n<img alt=\"In the much missed Flying Pig...with Jon\" src=\"https://anil.recoil.org/images/jc-flyingpig-1.webp\" title=\"In the much missed Flying Pig...with Jon\">\nIn the much missed Flying Pig...with Jon</p>\n<p>Back in the day, most of our discussions about systems research happened after a day of deep hacking down at the pub.\nSince the pandemic, we seem to have lost a big chunk of that social discussion around our work collectively. While I still see people regularly for a swift half, it somehow seems more difficult to gather people in general. Part of that is that I don't go into the department much anymore due to the noise and cold (something <a href=\"https://jonmsterling.com\">Jon Sterling</a> also <a href=\"https://amok.recoil.org/@jonmsterling@mathstodon.xyz/114318437109811024\">observed recently</a>), <em>vs</em> my cosy Pembroke office.</p>\n<p>I'm not sure if it's just me or everyone else also feeling this, but I'm so zoned out after even a few Zoom calls that I'm just not very social afterwards. So one thing I'm aiming to do more consciously after Easter is to try to gather people down at <a href=\"https://www.themillpubcambridge.com/\">The Mill</a> more for a swift half (where they serve excellent <a href=\"https://www.guinness.com/en-gb/beers/guinness-zero\">Guinness Zero</a>), and really cut down on remote interactions that aren't necessary.</p>\n<p>\n<img alt=\"In the Kingston Arms...with Jon\" src=\"https://anil.recoil.org/images/jc-kingston-1.webp\" title=\"In the Kingston Arms...with Jon\">\nIn the Kingston Arms...with Jon</p>\n<p>And the last tip is from Barry Schwartz, who noted that <a href=\"https://en.wikipedia.org/wiki/The_Paradox_of_Choice\">the secret to happiness is low expectations</a>. No matter how much works goes into a system, don't bank too much on the big papers making a splash. Instead, enjoy every step of the journey -- from building things, scrapping them, debugging odd failures, throwing ideas around, releasing the software, seeing adoption, scrapping it all and starting again, the whole journey! There will always be a <a href=\"https://link.springer.com/article/10.1007/s40037-021-00670-z\">reviewer 2</a> waiting to ruin your day if you let them, so don't let them in.</p>\n<p>I also wonder how long paper publishing in its current form will survive; with the sheer number of publications coming out these days and the amount of <a href=\"https://anil.recoil.org/notes/ai-contamination-of-papers\">AI generated output</a>, it's difficult to see something published today having the same ramp as the work we did in the past few decades. Instead, adoption and rapid iteration seem to be the way to go. Thankfully, our University intellectual property rights <a href=\"https://www.enterprise.cam.ac.uk/wp-content/uploads/2015/04/IP-Policy-in-Practice-Guidance-Note-25May10-FINAL-CLEAN-Updated-links-August-2015.pdf\">remain liberal</a> (patents aside, but who cares about those these days for software), so there's nothing stopping us!</p>\n<p>\n<img alt=\"In the Mill...with Jon. Remembering our friend Ross!\" src=\"https://anil.recoil.org/images/jc-mill-1.webp\" title=\"In the Mill...with Jon. Remembering our friend Ross!\">\nIn the Mill...with Jon. Remembering our friend Ross!</p>",
9 "content_type": "html",
10 "author": {
11 "name": "Anil Madhavapeddy",
12 "email": "anil@recoil.org",
13 "uri": "https://anil.recoil.org"
14 },
15 "categories": [],
16 "rights": "(c) 1998-2025 Anil Madhavapeddy, all rights reserved",
17 "source": "https://anil.recoil.org/news.xml"
18}