Hi,
I happened to write a project status report last August. Given the
significant project milestones reached recently, and also given the
overflow of project status reports around the turn of the year, I
thought I'd make "The August Report" a repeat tradition. The link to
the 2014 post is below, but I will summarize the relevant parts in this
post, so you need to click the link only to verify that I am not
cheating in my summaries.
http://permalink.gmane.org/gmane.comp.rumpkernel.user/416
Reading over the post and reminding myself of the contents, it is quite
amazing how accurately the todo list worked out. I wrote that we should
work towards [the Rumprun unikernel] being usable with the "make/sh/run"
skill set. We have achieved that. People have been showing up in the
community and telling about running services I have never even heard
about. It is great to have enabled folks to unleash their own expertise
in building better services. Equally cool has been hearing that
multiple companies have started projects to replace their existing
general purpose OS based services with ones based on the Rumprun
unikernel. Thanks go to the pioneers who made things possible by
testing a bunch of software and reporting/fixing problems.
I also wrote that there were no big rototills coming up. There actually
was one. It was unifying the Xen and baremetal source trees. The two
trees performed essentially the same function, but with independent
copies of the same sources, and those sources were diverging at a
disturbing rate. Pulling them back together earlier this year was
painful and took more than trivial effort, but it really was worthwhile
considering how much easier it is to do development now without all the
"oh was this fixed in the other tree?" nonsense. After all, the main
idea of rump kernels is that things which do not need to be forked are
not forked due to arbitrary laziness; "sweat saves blood, blood saves
lives, brains save both", to use a military parallel. With properly
future-tuned brains Xen and baremetal would never have been separate,
but that was one of those hard-to-foresee mistakes. The important thing
is that it's fixed now.
We did not start hosting various rumpkernel.org bits on anything built
on top of rump kernels. A year ago the problem was mostly technical:
how to build things. With the developments over the previous 12 months,
building is trivial. The problem is now more in logistics: since the
free, open source hosting services do a good job, we would need to
negotiate similarly free contracts with cloud provides, go over the
toothing steps, etc. Besides, I see the metric of success not as
solving problems we define, but rather as solving problems that others
define. Maybe we will just wait for the various hosting services to
start using rump kernels, thereby addressing the issue ...
Despite the recent focus on cloud-side unikernels, the goal of rump
kernels is still to provide driver-type components for any purpose and
make drivers a "solved problem". The world does need more than one set
of drivers to choose from -- monoculture is bad -- but that is another
thread. Be the driver source what it may be, unikernels are just one
puzzle piece in the post-1960's, post-timesharing-OS model for
computing. I was planning to write a long rationale for "the future of
computing etcetc yaddayadda", but since I noticed I'd written one
already last year, I'll save some sweat and blood by reusing it. (nb.
it's a new instance of the paragraph, not a fork)
=== snip from 2014 ===
My prediction is that over time the significance of operating systems as
we know them will diminish. I expect that as we move more and more from
computers to computing devices and the cloud, more and more people will
realize that they are running traditional operating systems only for
drivers, and simply do not need an operating system. The need for
drivers will of course remain, as they are needed to interoperate.
=== snip from 2014 ===
Not to worry, no architectural sacrifices in rump kernels will be made
to favor one use of drivers over another use. That said, unikernels are
the low-hanging fruit of what you can do with rump kernels, so I expect
focus to continue to be in that department.
So what is in store for the next year, again more of the same without
major rototills? Yes, but let me be more specific.
For one, I am really pleased about how we managed, after some number of
iterations, to figure out the toolchain bits for compiling applications
for the Rumprun unikernel. There we were shooting for a known target:
how to make the process of compilation as close to what is expected when
compiling applications for just any current-day OS. After compiling,
you need to run/deploy the binary. We have a working draft
implementation of how to deploy those binaries on the cloud. That draft
is not even close to what can be considered finished. I do hope that we
can figure it out during the next year. A year sounds like a long time
for figuring out how to run some binaries, but there are a few details
to consider. First of all, we are no longer shooting for a known
target. Second, we are shooting for the minimal target, not the maximal
one. Adding options and flags and toggles and switches would get us
somewhere quickly, but at the expense of the end result being unusable
since nobody can understand it.
Beyond the cloud, it is likely that within the next year we will see
corporations deploying embedded/IoT type systems with rump kernels as
the driving force. Recent ARM support for the Rumprun unikernel shows
that the stack can work both in the embedded space and the cloud space.
It really is stunning to witness how few lines of code you need to run
real world applications on bare metal if you can assume drivers being
provided as components.
In summary, more of the same for the next 12 months please, with
side-orders of a few new innovations and tons of deployment.
- antti
