felipehuici

27 ms·

1.
by felipehuici 5y ago
Definitely agree, in fact we tend to use the term "massive consolidation", where we run thousands of VMs on a single server, thus saving costs. Unikraft unikernels are a perfect fit for this since they consume little memory and bo
2.
by felipehuici 5y ago
For a while nanovms was based on Rump[0], which had terrible performance. The new version of nanovms[1] we haven't benchmarked but we should; having said that, even the founder says they "[...] have spent very little time benchmar
3.
by felipehuici 5y ago
We also have support for EXT2/EXT4 but it's not open source yet.
4.
by felipehuici 5y ago
Hi, no, the statement wasn't to isolate the kernel code from the application, since it's all in the same address space. Instead, it's to reduce the possibility of bugs (but again, not in the application), and reduce the vecto
5.
by felipehuici 5y ago
Agree, we're working on an embedded page, we intend to release the code during our May release. Also agree with having a page about the different languages we currently support (c/c++, Lua, Go, Python, Ruby) and others we're
6.
by felipehuici 5y ago
Yes, in fact we have some early support for Firecracker, where we can at least boot some basic Unikraft images with it (e.g., see page 10 of this paper[0], FIgure 10, where we get the shortest boot times with Firecracker). We're still
7.
by felipehuici 5y ago
Code clean up, commit history clean up, more testing and perhaps a bit of re-basing (it was built against a somewhat older version of Unikraft).
8.
by felipehuici 5y ago
Hi, support for the RPI and perhaps another device should be out by release 0.9 in May, along with the documentation at the link you posted (the code's working, but it needs clean-up).
9.
by felipehuici 5y ago
Yes, correct, Unikraft generates an OS that is customized to the needs of particular applications.
10.
by felipehuici 5y ago
You can think of the VMM as the toolstack that executes the moment you send a command to start a VM up. Once it's done it hands over execution to the actual VM (i.e., the OS within the VM). Thus the total boot time is the sum of the VM
11.
by felipehuici 5y ago
Agree that one of the major downsides of most unikernel projects so far has been how difficult/time consuming it was to create each unikernel -- oftentimes for each application. That's one of the explicit goals of Unikraft, to mak
12.
by felipehuici 5y ago
It's also worth mentioning that a hypervisor's API, like Xen's, is much more stable; the Linux one is constantly growing.
13.
by felipehuici 5y ago
Well, I'm pretty sure this wasn't their intended purpose :). To some extent, they come from the observation that the hypervisor already provides strong isolation, and so having things like multiple memory address spaces, syscalls,
14.
by felipehuici 5y ago
Hey, yes, you could and in some cases it might make sense (e.g., you need to do some packet processing as one app but you also want the control plane as another app in the same unikernel). Generally speaking unikernels have a single memory
15.
by felipehuici 5y ago
Yes, that's right. If you do not include a module that could potentially be used, you'd be missing that symbol and it would not compile.
16.
by felipehuici 5y ago
Typically unikernels have a single application in them because then you can fully specialize the entire image to the needs of that single application. Having said that, it is entirely possible to place multiple applications in one unikernel
17.
by felipehuici 6y ago
I suppose the right answer is "it depends". For most unikernels the answer is no: they are highly specialized, often targeting a single application or language, and built on top of small/basic OSes. Some of them have targeted
18.
by felipehuici 6y ago
The automotive domain definitely use them (e.g., Open Synergy and others), since their efficiency means they consume fewer resources on ECUs, and their relatively small Trusted Computing Base (TCB) not only reduces exploits but also means c
19.
by felipehuici 6y ago
A hello world unikernel was reported to take 4 ms a few years back ( http://cnp.neclab.eu/projects/lightvm/lightvm.pdf ). Here's a more recent project: http://www.unikraft.org/ .
20.
by felipehuici 6y ago
No, it was not Jitsu. Jitsu is based on MiragOS/OCaml, Erlang-on-Xen was also a Xen-based unikernel like MirageOS but was (as you can guess) Erlang specific. I think you can now find it at https://github.com/cloudozer&#
21.
by felipehuici 6y ago
Interesting, do you have any references explaining how/why z/TPF is a unikernel? Thanks!