131–140 of 187 posts
I'm one of the authors on this paper, so ask away if you have questions.
Earlier quoted context omitted.
I'm curious what you think of PipeWire: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Per... It claims to get near Jack latency, while implementing a more generic audio graph with better security than PulseAudio. In regards to Linux scheduler performance, do you have any experience with SCHED_DEADLINE?
We don't use SCHED_DEADLINE with audio, because things are driven by hardware interrupts/requirements, which makes SCHED_FIFO more appropriate ("wakeup! time do the work! right now! until it's done!"). macOS doesn't really have SCHED_FIFO, so we end up forced to use something to deadline scheduling there. It works fine. I commented a lot on PipeWire when it started. Thankfully Robin Gareus and others managed to get i…
I'm one of the authors on this paper, so ask away if you have questions.
How transparent could the deployment target choice be? Could you deploy roughly the same source code to unikernel and non unikernel targets? Also, what exactly are these enormous performance benefits?
Performance benefits: In truth we're still measuring this, there is a very smart student at BU who is investigating this and coming up with results for a forthcoming paper which I don't want to preempt too much. Almost all applications should see a small benefit, say of the order of 5%, but it's hoped that some will see a much larger benefit, and that it should be possible to make modest modifications in order to enjoy large benefits (perhaps only compiler and linker flags and such like).
These are very much hopes rather than firm promises at the moment.
> Unikernels have demonstrated enormous advantages over Linux in many important domains By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"? > causing some to propose that the days of Linux's dominance may be coming to an end Who exactly would make that claim? So, besides performance : what actual, real-life problems does this solve? I think there is s…
> So, besides performance: what actual, real-life problems does this solve? Well, don't go jumping to "besides performance". Dennard scaling is dead, and the things that can interrupt your program in a full preemptive kernel system are myriad. Furthermore, even if your application properly manages and produces backpressure, the OS can introduce buffering where you don't want it, often by necessity (to avoid massive c…
Earlier quoted context omitted.
Another performance benefit (unsurprising in highsight) comes from removing KPTI and similar Spectre mitigations. These have really made system calls in regular kernels expensive.
On the other hand if you run only one application on your VM you can just disable them, because one you have access to the userspace application there is nothing else on the machine to steal via side channel attacks.
Seems to me that a unikernel database should be the first application. Databases tend to bypass practically all the facilities of a kernel anyway. It’s often surprised me that they haven’t merged before now.
There is plenty of work in this area. The team behind OSv ending up writing https://www.scylladb.com/ because of their earlier interest in databases.
> Unikernels have demonstrated enormous advantages over Linux in many important domains By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"? > causing some to propose that the days of Linux's dominance may be coming to an end Who exactly would make that claim? So, besides performance : what actual, real-life problems does this solve? I think there is s…
> So, besides performance: what actual, real-life problems does this solve? Well, don't go jumping to "besides performance". Dennard scaling is dead, and the things that can interrupt your program in a full preemptive kernel system are myriad. Furthermore, even if your application properly manages and produces backpressure, the OS can introduce buffering where you don't want it, often by necessity (to avoid massive c…
Earlier quoted context omitted.
As the program and kernel run in a single address space, yes there is no separation from your application corrupting parts of the kernel. I'm not very convinced about the security story around unikernels, but for balance the other side of the argument is that there's much less code around in a unikernel - no shell, no command line tools at all, no compilers or interpreters, just the code required to run the program a…
Wouldn’t directly linking system calls make every address space more unique and thus make it harder to write (generic) exploits for?
Earlier quoted context omitted.
There is plenty of work in this area. The team behind OSv ending up writing https://www.scylladb.com/ because of their earlier interest in databases.
So you're saying unikernel experts ended up writing a non-unikernel database. There's a lesson right there.
Unikernels are typically statically linked. Using copyleft code means the whole resulting binary is subject to copyleft. Free software is great, but not everyone is in the position where they can release all of their code all the time. For a unikernel to be viable it can't have copyleft code in it.
Depends what you're using it for. If you're just running it as a server then (non-A) GPL code is fine since you're not distributing the program.