Full article text: http://sci-hub.tw/10.1145/3317550.3321445 Maybe link the top-level post there?
There is a link to the PDF on the page. No ACM membership required.
Unikernels: The Next Stage of Linux’s Dominance (2019)
41–50 of 187 posts
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#42Unikernels 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.
> but not everyone is in the position where they can release all of their code all the time. you lost your repository credentials? What prevent you from releasing code "all the time"?
Show me where Microsoft releases all of the source for Windows, or Apple, for Mac OS and iOS.
What's preventing them from releasing code "all the time"?
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#43I'm one of the authors on this paper, so ask away if you have questions.
Is it correct to think of it as application code running as PID 1 in kernel space? Can I fork or create threads? Can I directly access kernel's internal APIs like a kernel module?
Not quite. Everything runs as PID 0. :-)
There are no processes here. Everything runs inside the kernel. You don't have exec(), fork() or similar.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#44Earlier quoted context omitted.
Is it correct to think of it as application code running as PID 1 in kernel space? Can I fork or create threads? Can I directly access kernel's internal APIs like a kernel module?
Not quite. Everything runs as PID 0. :-) There are no processes here. Everything runs inside the kernel. You don't have exec(), fork() or similar.
Is this just bare metal embedded development, with a nice HAL?
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#45Unikernels 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.
You can write proprietary kernel drivers. Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#46Unikernels 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.
> but not everyone is in the position where they can release all of their code all the time. you lost your repository credentials? What prevent you from releasing code "all the time"?
> What prevent you from releasing code "all the time"?
Sometimes the same thing that prevents you from giving away all the results of your work for free. Can I have a copy of the code you're writing for your employer now? Surely everything you work on is made freely available to the public in its entirety. I hope you weren't just virtue signaling but doing the opposite in exchange for a salary.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#47I'm one of the authors on this paper, so ask away if you have questions.
Is it correct to think of it as application code running as PID 1 in kernel space? Can I fork or create threads? Can I directly access kernel's internal APIs like a kernel module?
> Is it correct to think of it as application code running as PID 1 in kernel space?
getpid exists and returns a number - in fact it can return any number you like :-) Everything is linked into a single vmlinux which runs in a single address space. (As an aside I'll have to remember to ask Ali if he's thought about what number getpid() should return in UKL - I guess returning 1 would cause least surprise)
> Can I fork or create threads?
Fork no, threads yes. Threads are implemented using kernel threads.
> Can I directly access kernel's internal APIs like a kernel module?
Yes, although whether this is a good idea is another matter. Note that it's still Linux so internal APIs are unstable and can go away or change their meaning at any time, so if your application starts to rely on internal APIs you could quickly get into trouble.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#48Unikernels 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.
You can write proprietary kernel drivers. Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations.
> You can write proprietary kernel drivers.
IIRC you can write proprietary kernel modules, which are loaded at runtime.
> Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations.
Because the kernel is licensed under GPLv2. If you statically link to the kernel, then all interpretations of the GPL are that your work is a derivation and must be GPL'd (at least assuming it is "distributed").
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#49Unikernels 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.
> but not everyone is in the position where they can release all of their code all the time. you lost your repository credentials? What prevent you from releasing code "all the time"?
> What prevent you from releasing code "all the time"?
That you don't have the rights to it, and / or that the code was written under a contract or grant which prevents its release.
Re: Unikernels: The Next Stage of Linux’s Dominance (2019)
#50Earlier quoted context omitted.
Not quite. Everything runs as PID 0. :-) There are no processes here. Everything runs inside the kernel. You don't have exec(), fork() or similar.
Is this just bare metal embedded development, with a nice HAL?
We're hoping that many regular server-type applications can be ported simply by recompiling them.