anttiok

5 ms·

1.
by anttiok 10y ago
IMHO, this is the most useful systems paper ever written. Rump kernels were designed on the listed principles. (if the implementation managed to follow the principles is of course another matter ...)
2.
by anttiok 10y ago
There's a growing number of users, but they aren't centrally collected. I've actually thought about creating a "Who uses rump kernels" page, but haven't gotten around to it. No better time than now to do that
3.
by anttiok 10y ago
Correct. links with some more information on a conceptual level: http://wiki.rumpkernel.org/Repo#the-big-picture http://wiki.rumpkernel.org/Info:-FAQ
4.
by anttiok 11y ago
If I had a time machine, the first thing I'd do is s/rump/& kernel/ in all old writings. The second thing I'd do is make a case for writing creat with an e.
5.
by anttiok 11y ago
Follow the "Getting Started" link on rumpkernel.org. That page includes both short and long reading (should you get more interested ;), and also some "hands on" tutorials should you learn about things better that way (I
6.
by anttiok 11y ago
If it's not an instance of a selection of components running on top of externally scheduled threads, it's not a rump kernel in my book. So, strictly speaking no, but the answer really depends on what you want to convey by "b
7.
by anttiok 11y ago
What porting? We have quite a few pieces of software in rumprun-packages which require ZERO (0) porting or patches to function as unikernels, e.g. haproxy, mpg123 and php. Feel free to check them out for yourself if you don't want to
8.
by anttiok 11y ago
That, and my name not being Antii (as already mentioned in the discussion). Pick whichever reason suits your agenda ;-)
9.
by anttiok 11y ago
Assuming that was directed at me, what's "the comment"? Anyway, that's the right direction if that's what you want you want to accomplish. Otherwise it's the wrong direction. sincerely, anti
10.
by anttiok 11y ago
I sort of agree with you and I sort of don't. For example, I think an interesting future path for the Rumprun unikernel (which, I always stress, is not the same thing as a rump kernel) is running without the POSIX-y userspace interf
11.
by anttiok 11y ago
No, a rump kernel is not an unikernel, check the FAQ linked from http://rumpkernel.org/ However, you can use rump kernels as a major component of a unikernel implementation. A rump kernel provides environment-agnostic driv
12.
by anttiok 11y ago
When all of the "kernel" exists to service that single application alone, does it matter? Where does the kernel start and the application/libraries end? Who says that a protection barrier is even best suited for every appli
13.
by anttiok 11y ago
With gdb, prints, and lots of thinking. In other words, pretty much like you'd debug one elsewhere, except instead of "run" in gdb you need "target remote <guest-gdbserver -address>".
14.
by anttiok 11y ago
Personally I'd like to see disjoint drivers and operating systems. No single OS model solves all problems. Of course no driver code scales to unlimited uses, but at least steps should be taken to ensure that current driver code goes
15.
by anttiok 11y ago
We have at least redis in rumprun-packages -- https://github.com/rumpkernel/rumprun-packages/tree/master/r... -- which AFAIK was packaged based on a non-toy need. Yes, the need for persistent storage for
16.
by anttiok 11y ago
Ah, yes, I definitely remember you and your work, just didn't realize it was the same person. Hop on to irc again some day or start a thread on the mailing list, and we can brainstorm about the best solution.
17.
by anttiok 11y ago
Can you expand on that idea? For Rumprun, it's not very many minutes of work to set things up so that you have a lower readonly file system layer (immutable across restarts) and then a memory file system on top of that (for purposes o
18.
by anttiok 11y ago
Do you know anyone who's even tried to make Java work on Rumprun? I only tried Python, that worked out of the box. From what I've been following others, e.g. Erlang, Rust and Javascript (node.js) more or less provided the same e
19.
by anttiok 11y ago
Notably, there's ongoing work (with an already functional result) to run Mirage on top of the low-level drivers provided by Rumprun. The idea in doing that is enabling the "top-level" Mirage stack to run in environments for
20.
by anttiok 11y ago
"a" is sort of orthogonal to rump kernels, but yes, you can run at least file system drivers transparently as userspace servers (just give -o rump to mount(8)). I've also run a USB modem driver as a userspace server, in the
21.
by anttiok 11y ago
I think we're in rough agreement. "The author's" assumption is that getting rid of unnecessary moving parts is an improvement. Having many slightly different copies of the same functionality in the stack is not redundan
22.
by anttiok 11y ago
The folks at genode.org are also relying on capabilities for the system. Maybe they have some ideas on how to relate it to application/service programming, and more importantly, how to get from current reality to "good enough&quo
23.
by anttiok 11y ago
(author. thanks for the kind words). I think desktop-style devices are going more in the direction of being personal. And where they aren't, probably in the majority of cases you don't want the OS to mediate access poorly. I&#x
24.
by anttiok 11y ago
Your statement "rump kernels do not have fork" is not entirely accurate in the context. Rump kernels do support fork. However, it is not conceptually a rump kernel's business to provide fork. So it's actually the
25.
by anttiok 11y ago
The community didn't reinvent "ASIC". It was my joke, but humour is difficult ... Read the conclusions of my dissertation. Then realize that the cloud is just one form of special-purpose hardware. Then be me trying to ton
26.
by anttiok 11y ago
Yea it took a while. I often joke that it took two weeks to get things working, and four years to make it maintainable. In reality, the first version did take two weeks, but maintainability grew with completeness and correctness. It also
27.
by anttiok 11y ago
Not to downplay the prior art, but I'm not sure I can call rump kernels an evolution of the previous work. I certainly hadn't heard about OSKit at least in 2009 (since it's not cited in my 2009 USENIX paper), despite going t
28.
by anttiok 11y ago
The point of rump kernels is not leveraging the whole stack from $OS. It's leveraging the unmodified drivers from $OS without the wholesale import of policies from $OS . Sure, driver kits are an old idea, but starting from OSKit in
29.
by anttiok 11y ago
[I'm the author]. The core tech description is still (mostly) valid, but the general ecosystem has exploded far beyond what is discussed in the thesis. See http://rumpkernel.org/ for a description of current reality
30.
by anttiok 11y ago
Check out the "Comparison with other unikernels" section in the post.

More ›