> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?
GNU/Hurd on the desktop.
Unikernels: The Next Stage of Linux's Dominance [pdf]
11–20 of 104 posts
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#12Earlier quoted context omitted.
In this case the authors themselves put the pdf on their website. In the general case, you can almost always download the article from scihub by searching for the DOI of the publication.
> In this case the authors themselves put the pdf on their website. OT: This should honestly be a criminal offense, at least if done before a year passes. The publisher does valuable work in vetting contributions and checking the paper before publishing. They shouldn't be cheated out of their fair share of money that comes with due process just because authors go rogue.
If "authors go rogue" they have recourse today.
But determining whether or not authors have "gone rogue" depends on their agreement with the publisher. You do not have a basis for claiming they have done so unless you know whether or not they have obtained permission or whether or not they never handed over rights in the first place.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#13Earlier quoted context omitted.
In this case the authors themselves put the pdf on their website. In the general case, you can almost always download the article from scihub by searching for the DOI of the publication.
> In this case the authors themselves put the pdf on their website. OT: This should honestly be a criminal offense, at least if done before a year passes. The publisher does valuable work in vetting contributions and checking the paper before publishing. They shouldn't be cheated out of their fair share of money that comes with due process just because authors go rogue.
Can't really say if this is sarcasm or not, but journals are paid to do that checking, it's not free, and they use unpaid people for peer review, so I'd say they aren't really losing money.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#14> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?
research papers I would guess.
And stuff like SQL Server for Linux or the original WSL implementation, via picoprocesses.
Or the Docker TCP/IP stack on macOS, using parts of MirageOS.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#15The article is Tl;Wbmloc;Dr (too long, way beyond my level of comprehension, didn't read), so forgive any stupid questions. Could the unikernel technology be used to build extremely small Linux distros that contain just the bare minimum to satisfy all dependencies for running say a single software or a small group of them. I'm not interested in virtual machines for network related services but rather in small embedde…
This is how embedded linux systems are built already, AFAIK. There are vendors, such as MontaVista, that provide a toolchain to build images in this manner. There are free software alternatives too to do that, such as Embedded Gentoo.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#16> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?
I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance…
Except that those amazing debugging capabilities are also possible, as anyone that used Erlang, Java or .NET debugging capabilities in production is aware of.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#17The article is Tl;Wbmloc;Dr (too long, way beyond my level of comprehension, didn't read), so forgive any stupid questions. Could the unikernel technology be used to build extremely small Linux distros that contain just the bare minimum to satisfy all dependencies for running say a single software or a small group of them. I'm not interested in virtual machines for network related services but rather in small embedde…
It doesn't really make much difference in terms of size in itself, I suspect. You're still carrying along the whole kernel and the application code, they're just linked together into a single binary. You can certainly then trim things down a lot by stripping the kernel to its bones by removing drivers etc., but you can do that even without linking it together, and you can go a lot further than what the normal kernel configuration mechanism allows if you're prepared to strip out functionality you know you'll never need, but I'm hard pressed to think of approaches like that which you can apply to the kernel that will only work if you move your application code to kernel space.
In the past I've brought up Linux on embedded boards with 4MB RAM and 4MB flash for both the kernel and the application, and we gained most by linking statically to a smaller libc on the user side and stripping out drivers on the kernel side, ditching bash for ash (currently dash) and using a stripped down barebones init. We could have ditches ash and init as well and booted straight into the app, but ash made debugging and testing slightly easier and we could fit it in. 4MB at the time was not even a challenge.
I think the gap from something that you can fit a Linux kernel and an app mashed together into a unikernel up to being able to run them separately will be very small, so in most instances if you can make it work as a unikernel odds are you can produce a nearly a small solution without it.
Going full on unikernel potentially costs you a lot of resilience against failure, it's not just about security. The main reason for wanting to do it is to reduce the amount of context switches and data copying to reduce latency.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#18Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#19The article is Tl;Wbmloc;Dr (too long, way beyond my level of comprehension, didn't read), so forgive any stupid questions. Could the unikernel technology be used to build extremely small Linux distros that contain just the bare minimum to satisfy all dependencies for running say a single software or a small group of them. I'm not interested in virtual machines for network related services but rather in small embedde…
It doesn't really make much difference in terms of size in itself, I suspect. You're still carrying along the whole kernel and the application code, they're just linked together into a single binary. You can certainly then trim things down a lot by stripping the kernel to its bones by removing drivers etc., but you can do that even without linking it together, and you can go a lot further than what the normal kernel…
It probably helps security a ton if you are the only binary: there is no shell, no other executables, and you can even disable fork() and exec() system calls.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#20> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?
I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance…
Unikernels also run on bare metal, so it's not about swapping one sort of protection for another. Besides the differences in protection and separate processes, unikernels can do anything an OS can do. Some unikernels will run application software with no changes (but obviously things like fork don't work anymore).
The point (for me at least) is discarding features that you don't need in return for performance and simplicity gains. Those gains are not insubstantial when you're scaling your system and you don't want to spend your money on admin staff.