On Sat, 2015-04-18 at 08:39 +0000, Antti Kantee wrote: > I think it's becoming even clearer now that they're a stepping stone > between the 60s/70s style operating systems and the future way of > running software. You can't just throw away the (pre)historic OS, > because then you lose the drivers with the bathwater.
Well said. > If the first edition of the book wanted to know "how could we improve > monolithic kernels to extract their maximal potential", the second > edition will be more along the lines of "how do we want to run software > *and how to get there*". Finding an equally accurate ending for the > conclusions/futurework in the upcoming 2nd edition is going to be > challenging, though ... > That's the question I'm interested in finding the answer to as well. I certainly have ideas about this but will save those for later, hopefully after I've made enough mistakes to have learned a thing or two. > The repo rototill was unfortunate, but it was necessary, since we didn't > really fully understand the scope of things until recently. The rumprun > repo provides a rump kernel based unikernel for various platforms. The > name is sort of a mnemonic too: instead of running an application you > rumprun it. It's the only repo you really need to care about if you > want to [rump]run applications. If you're confused as to why the 1st > edition of the book doesn't talk about rumprun, it hadn't been invented > back then. That makes sense... my only question about that is, what is the status of rumprun-posix? Is that still necessary and/or useful for testing applications in userspace? Or should I just go straight onto xen/baremetal? > As for porting, well, porting is sort of a naughty word around here. We > explicitly want to avoid the situation where you need to *port* software > to rumprun. Instead, POSIX software that is unikernel-compatible (*) > should just work out of the box, give or take some adjustments that > should be upstreamable. The current status is that you can more or less > compile simple programs with "make" and run them with "rumprun". We're > still trying to figure out a number of things, like the exact syntax of > rumprun, how to build unikernels with >1 application (which doesn't > directly fit into the paradigm where "make" produces a [rump]runnable > binary), etc. For some of those problems there are ideas floating > around, but reporting experimental data in the form of "i'm trying to > run this application, i'm running^Wbumping into these problems" is > extremely valuable for us now. > > *) we don't exactly know what that means yet, but something along the > lines of "doesn't fork and exec all over the place and doesn't assume > virtual memory" Got it... porting is out... rumprun is in. And I will definitely do my best to give you some meaningful feedback. Thanks, Ben
