Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unikernels: The Next Stage of Linux’s Dominance (2019)

dl.acm.org

Post reply on HN
Print view View original

91–100 of 187 posts

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#91

Post by masklinn »

nabla9 wrote: post #78
masklinn wrote: post #48

Earlier quoted context omitted.

> 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…

Linux is licensed under GPL-2.0 WITH Linux-syscall-note. >NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work". (even without actual syscall, you can consider unikernels as normal use of kernel)

The original comment specifically put forward the following scenario:

> Unikernels are typically statically linked.

The note you're quoting is about regular software performing regular syscalls which is runtime dynamic linking to the kernel (so much so that multiple OS (e.g. SmartOS, Windows) implemented linux persona which allow running unmodified Linux software against a non-linux kernel).

It does not apply in a scenario where you would statically link to the kernel.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#92

Post by [deleted] »

MrBuddyCasino wrote: post #54

> 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…

[deleted]

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#93

Post by masklinn »

nabla9 wrote: post #75
perbu wrote: post #12

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.

This is not categorically true. Linux is licensed under GPL-2.0 WITH Linux-syscall-note. >NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work". More generally can link LGPL code statically without making resulting binary subject to copyleft or releasing the source co…

> This is not categorically true.

GP provided a clear scenario in which their warning is categorically true.

> Linux is licensed under GPL-2.0 WITH Linux-syscall-note.

The note clarifies that syscalls are interpreted as a form of dynamic linking, which would be quite obvious in retrospect given you can run unmodified linux software on non-linux kernels (https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux).

> More generally can link LGPL

You do realise the LGPL and the GPL are different licenses with different requirements and constraints right? And the linux kernel is not licensed under the LGPL? And that what you quote specifically notes that even under the LGPL, static linking results in a derived work?

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#94

Post by la6471 »

rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

Is the final vision to somehow put together a packager that will put together an application plus UK together to run on any virtual system. Maybe one can extend packer to create this binary similar to how it creates container.Also FaaS providers like AWS lambda or google functions - aren’t they already doing this?

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#95

Post by rectang »

Can a unikernel be used to create a sound/music application which is not afflicted by the latency problems which bedevil such applications when running inside traditional operating systems?

For example, could it be used for a softsynth which takes in midi input and emits digital audio with the OS only contributing guaranteed sub-millisecond latency?

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#97

Post by MichaelMoser123 »

rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

isn't it hard to develop/debug/monitor an application with this approach? I mean you can't just run a debugger as another process and attach to the thing, you can't run tcpdump or strace, nothing of that sort. Also every bad pointer access will require a reboot, wouldn't it? I mean how do you develop an application with this approach?

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#98

Post by gwillz »

neilwilson wrote: post #56

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.

https://twitter.com/cpswan/status/971335126566211585?s=20

Maybe not exactly what you're thinking. But somewhat in the same domain.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#99

Post by fcantournet »

neilwilson wrote: post #56

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.

They also tend to need to be debugged & administered.
Post reply on HN