Unikernels: The Next Stage of Linux’s Dominance (2019) • Hacker News Board

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

#181

Post by DrScump » Sun, May 17, 2020, 9:31 AM UTC

nick_kline wrote: post #154

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.

I think this is the paper https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-h... . There's a great summary by cormacrelf below of some of the details. This kind of things comes and goes across the decades. Back in the 90s it was common for databases to implement their own file systems or memory management, but gradually the OSs of the day added features make this unnecessary. As we found then, you lose so mu…

  Back in the 90s it was common for databases to implement their own file systems or memory management

Informix in the mid/late 1980s initially had Shared Memory implementations in UNIX platforms that supported it. Then, the Turbo/OnLine/IDS servers added the option of raw disk partition use for database spaces to avoid filesystems altogether (and do raw unbuffered I/O).

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

#182

Post by rwmj » Sun, May 17, 2020, 9:34 AM UTC

Someone wrote: post #167

rwmj wrote: post #105

Earlier quoted context omitted.

All good questions without a clear answer at the moment. Bad pointers in the application can overwrite kernel data structures because everything runs in a single address space.

The unikernel idea is 20-ish years old. I think those good questions cannot be much younger. Because of that, I think “without a clear answer at the moment” is worrisome. Are there partial answers to these questions?

I mean "without a clear answer" for UKL which is only just over a year old and still in active and early development. There will probably be a way to attach gdb at some point.

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

#183

Post by rwmj » Sun, May 17, 2020, 9:34 AM UTC

heavenlyblue wrote: post #108

MichaelMoser123 wrote: post #97

Earlier quoted context omitted.

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?

> Also every bad pointer access will require a reboot, wouldn't it? Hm, isn’t reboot just slightly more complicated than restarting your application? And most of the today’s apps would still require “rebooting” be it a container or a virtual machine

Containers get "rebooted" when they go wrong too, so I'm not sure this is so different.

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

#184

Post by rwmj » Sun, May 17, 2020, 9:40 AM UTC

jibanes wrote: post #96

this is excellent, where is the code, do you have examples?

https://github.com/unikernelLinux

We have memcached compiled for UKL but for some reason Ali has made that repo private (it's under the same namespace as above). I will ask him if he can make the other repos public this week.

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

#185

Post by rbanffy » Sun, May 17, 2020, 9:44 PM UTC

zarkov99 wrote: post #173

rbanffy wrote: post #143

Earlier quoted context omitted.

> debugging and development on a normal host and only deploy on a unikernel when you are stable? Sure! And, still, when you deploy, it fails. At least one of your assumptions that led to your conclusion that your development/testing environment is equivalent to the production one are flawed. Find which ones.

That is not a new problem. To some extent it already happens with debug and release builds, with running on a VM vs a real host, running on a different distribution than the one you developed in, etc. If the performance gains are significant in some domains that would be more than enough to pay for the extra pain.

> running on a VM vs a real host, running on a different distribution than the one you developed in

Except that, in those cases, you can connect to the server and spin up a shell and actually get an idea, from the file system, from logs or from any of the many ways you have to inspect a system. All that you'll need to provide to your unikernel.

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

#186

Post by throwaway894345 » Mon, May 18, 2020, 9:03 PM UTC

rbanffy wrote: post #185

zarkov99 wrote: post #173

Earlier quoted context omitted.

That is not a new problem. To some extent it already happens with debug and release builds, with running on a VM vs a real host, running on a different distribution than the one you developed in, etc. If the performance gains are significant in some domains that would be more than enough to pay for the extra pain.

> running on a VM vs a real host, running on a different distribution than the one you developed in Except that, in those cases, you can connect to the server and spin up a shell and actually get an idea, from the file system, from logs or from any of the many ways you have to inspect a system. All that you'll need to provide to your unikernel.

Not much of a problem in theory; just include the relevant library.

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

#187

Post by masklinn » Thu, May 21, 2020, 7:18 AM UTC

nabla9 wrote: post #104

masklinn wrote: post #91

Earlier quoted context omitted.

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

> It does not apply in a scenario where you would statically link to the kernel. That's not the interpretation everyone else uses.

That's completely irrelevant to this discussion.

It's a well-defined axiom of the original comment, and we're discussing logical consequences of that axiom. If you want to disagree with the original axiom then go and do so to the original comment.