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

https://dl.acm.org/doi/abs/10.1145/3317550.3321445

by todsacerdoti • 6 years ago

247 175 6 years ago

dl.acm.org

rwmj24• 6 years ago

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

tasubotadas• 6 years ago

What is a unikernel and why it's good?

stingraycharles• 6 years ago

Yeah I’m kind of amazed they don’t start out with explaining this. Usually there is at least a one-line explanation.

From Wikipedia:

“A unikernel is a specialised, single address space machine image constructed by using library operating systems. A developer selects, from a modular stack, the minimal set of libraries which correspond to the OS constructs required for their application to run. These libraries are then compiled with the application and configuration code to build sealed, fixed-purpose images (unikernels) which run directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.”

rwmj24• 6 years ago

https://en.wikipedia.org/wiki/Unikernel

Whether it's good depends on what you're doing. UKL will[1] allow you to link a regular server application to Linux and then run that single binary on baremetal or in a hypervisor, and give you a decent performance boost over running the application on top of a normal kernel. How much of a performance boost depends a great deal on the program, almost everything will be a few percent faster, and some applications a lot more.

[1] I'm using the future tense here because although we do run real programs with it today there's still a bunch of development work to do before it works smoothly. The code is: https://github.com/unikernelLinux

perbu3• 6 years ago

Basically you replace the system calls into the kernel with library calls. So you end up with a single binary that contains both the application as well as the operating system functionality.

This can lead to some rather spectacular performance benefits. One thing is that you remove the syscall overhead, but more importantly you can do a lot more optimizations at the compiler/linking steps.

You can remove complex code that tries to dynamically model the world with rather plain code that does just what it is supposed to. With IncludeOS (C++17 unikernel) we did make a firewall implementation that instead of using complex data structures relied on preprocessing the rule set and translate it into C++ code. The code to do this was quite simple and resulted in pretty amazing figures wrt number of rules per packet per second. Metaprogramming can sometimes deliver amazing results.

Similar things can be done in a traditional kernel as well and we've seen eBPF firewall implementations that are able to get similar numbers. On the flip side eBPF and it's firewall implementation is order of magnitude more complex. However, you can push eBPF code onto the networking card which can be a huge benefit. And ofc you could make a kernel module that implements a specific firewall ruleset and get similar performance without eBPF.

I like unikernels because I feel I can understand them better. You can reason about them and they are easier to optimize for very specific workloads.

So why aren't we using them? Likely because we know Linux so well and we've invested a lot in it. It runs everywhere and is extremely well supported. Bringing a new operating system to market is challenging, bringing a new operating system with a entirely different architecture is even harder. Even if it, on a purely technical level, could yield better results.

k__• 6 years ago

Think of it as "Your app runs like an operating system".

Instead of installing an OS and installing your app on that OS, the OS is a library you use to talk to the hardware.

It's good for two reasons.

First security, if you only use the HDD and network, you don't have to include code for display or mouse etc. which could be a security risk.

Second, it's faster, because you don't have to do syscalls, since your app IS the OS, syscalls don't need to get out of userspace.

texascloud• 6 years ago

Only reading the abstract, are you saying a different branch/fork of Linux could be maintained to be a unikernel?

Rotten194• 6 years ago

(Not the author) No, the paper describes a small patch to Linux (~20 lines) + modifications to glibc that enable using Linux as a unikernel. Their goal is to have the modifications upstreamed so that Unikernel linux could be a GCC target etc.

rwmj24• 6 years ago

The changes to Linux are fairly small and the aim is to get them upstream. There's also a forked glibc and the changes there are a bit larger, although also hopefully upstreamable.

pinopinopino2• 6 years ago

Really cool work!

Is there really a support layer for Emacs in the kernel?

Now the real question. You are statically linking against a modified glibc, so they make calls to your kernel library instead to the system call and you can do some nice optimizations along the way. Which I think make sense.

I can see this is cool for things that directly interface to glibc, but do you think this is viable for applications using multiple layers between the kernel and the application?

rwmj24• 6 years ago

At the moment you must go through glibc. For example issuing SYSENTER or INT 80h will not work.

We have only run C applications so far, so I'm unsure how it will all work for servers written in other programming languages. I think applications which rely on complex multi-process middleware (like Java JBoss, etc) will be hard or even impossible to port.

xfs3• 6 years ago

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?

perbu3• 6 years ago

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.

rwmj24• 6 years ago

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.

joosters• 6 years ago

What are the plans regarding multithread / multiprocess support?

On the face of it, multiprocess support might seem a bit stupid, but it would greatly help the porting of more complex applications. The 'processes' wouldn't need virtual address space or memory protection, just give them a block of memory and pick a CPU to run the code.

If you have multithreading, do you need any scheduling code, or can you just pick a CPU for each thread and leave them to run? What about the kernel's own threads & processes?

rwmj24• 6 years ago

I don't know where things will go in the future, but now: Multiprocess no. fork() will fail. Pthreads works already.

arbarb3• 6 years ago

UKL is multi threaded, not multi process because there is no fork. Plus it's a Unikernel i.e., just one process. You don't need any scheduling code, Linux does it like it does normally for kernel and user threads.

MaxBarraclough3• 6 years ago

What do you make of the highly critical Assessing Unikernel Security paper [0]? Have things changed since its publication?

[0] https://www.nccgroup.trust/globalassets/our-research/us/whit... , from https://news.ycombinator.com/item?id=19738905

rwmj24• 6 years ago

I can't read that paper. Firefox says the HSTS cert is wrong.

Edit: Thanks for the updated link. UKL can be compiled with usual hardening features like ASLR, stack hardening, RELRO.

As I said here (https://news.ycombinator.com/item?id=23202042) I'm dubious about the security story around unikernels, but most of the issues in this paper are not relevant to UKL specifically.

eyberg9• 6 years ago

You might enjoy reading my response to that:

https://nanovms.com/dev/tutorials/assessing-unikernel-securi...

transpute• 6 years ago

Thanks for taking questions. Are there outstanding work items for QEMU being statically linked with a unikernel?

rwmj24• 6 years ago

It's not really something that anyone in the project has thought about. Running the vmlinux on baremetal is actually more interesting to us.

wltprgm• 6 years ago

Correct me if I am wrong, Unikernels are basically allowing binary to run at Ring 0?

What do you think about WASM in the kernel with the same high level concept with Unikernel? link in the below

https://destroyallsoftware.com/talks/the-birth-and-death-of-...

rwmj24• 6 years ago

I'm not sure I can say anything intelligent about WASM in the regular kernel, but from a UKL point of view we're talking with Enarx and they're going to join us on one of our regular meetings in a few weeks. For more info on Enarx and web assembly see: https://www.youtube.com/watch?v=5wrQSe-IdMI

eyberg9• 6 years ago

I'll admit I don't know much about WASM but access to raw sockets and 32bit only sounds extremely limiting.

Until those are dealt with wasm will never move past it's current status quo - malware in the browser.

snvzz• 6 years ago

Why Linux?

Solutions based on Netbsd's rumpkernels exist. There's nothing about unikernels that says Linux.

rwmj24• 6 years ago

Linux is the most mainstream Unix-like server operating system. We're making only minimal changes to Linux and hoping to get them upstream. (The NetBSD rumpkernel is a bit different from this by the way.)

la6471• 6 years ago

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?

rwmj24• 6 years ago

I wouldn't say the final vision is clear yet, but what I'd like to see would look something like a "liblinux.a", and you would compile your application using your normal compiler, and link it to this library to end up with a vmlinux that would run in a VM or on baremetal.

Actually achieving this is tricky: At the moment you need to use special compiler flags and a completely different link line from normal. Then there's the issue of how/whether the library Linux is configured generically or you somehow allow people to set CONFIG_* options.

MichaelMoser123• 6 years ago

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?

rwmj24• 6 years ago

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.

wildmusings• 6 years ago

You can debug a normal kernel over the network. I imagine you can do the same with a unikernel.

heavenlyblue3• 6 years ago

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

eyberg9• 6 years ago

One of our engineers spent yesterday debugging a networking issue on Google Cloud for Nanos.

Not saying it is easy but at the end of the day it's just engineering work.

throwaway8943455• 6 years ago

Probably best to use a memory safe language so you don’t have bad pointer accesses and generally minimize debugging significantly.

slim• 6 years ago

I guess you would use an emulator to debug. Which seems like good workflow design to me.

zarkov993• 6 years ago

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?

rwmj24• 6 years ago

About the source code, all I can really say is that's our aim at the moment - to have the same source compiled for both non-unikernel and UKL targets. Note that really what we're aiming for is to recompile common servers out of the box with no changes, or the minimal changes possible.

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.

reubensutton2• 6 years ago

My gut instinct is always that using traditional kernels in a unikernel way is a bit suboptimal because it doesn’t become a “library operating system” in the same way that Mirage does.

rwmj24• 6 years ago

Only the bits of Linux which are used are linked in, same as when you link together any program. The big advantage of using Linux is driver support - you can run a UKL application on baremetal, linking to the drivers needed to run on the target hardware.

reubensutton2• 6 years ago

Oh! That’s very cool

masklinn6• 6 years ago

While that's true, the flip side is that "traditional" kernels have much better hardware (and general) support because they benefit from the long history of the "main project".

Stripping down traditional kernels to work as unikernels is not a new thing: https://github.com/rumpkernel/rumprun

brmgb• 6 years ago

Does it really matter ? Are people actually planning of running unikernel on bare metal a situation where you would need significant tooling to manage them ?

MirageOS was initially clearly designed to run on top of an hypervisor. The idea was going from host os, guest os and application to just host os and unikernel.

As I see it, it was a different way of solving the same problem containers are now used for : do you really need both a host os and guest os when all you want is isolation ? Using container is pushing isolation in the kernel while losing the actual virtualization (in a way merging host os and guest os) while unikernel is pushing the useful part of the guest os into the application (merging guest os and application) keeping the benefits of full virtualization. I think it's why Docker bought the company making MirageOS.

I don't really see where rump kernels sit there. Clearly there is interest as people are working on them but I fail to see where they would be useful.

perbu3• 6 years ago

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.

lmm• 6 years ago

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.

dathinab• 6 years ago

But what about the cloud and auto scaling wouldn't that count as distribution (through for internal use only)?

posix_me_less• 6 years ago

Well yes, if you want to distribute binaries to people and keep the source private (like in 90's), copyleft unikernels isn't the way to do that.

Unikernels are viable even if they don't allow you to do that, for many reasons - performance, workload isolation, ease of installation.

vbezhenar3• 6 years ago

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.

masklinn6• 6 years ago

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").

nabla95• 6 years ago

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 code. Increasing number of programmers don't know what object file is anymore (they didn't learn to program in C/C++) and this causes endless confusion.

https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

masklinn6• 6 years ago

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?

08-15• 6 years ago

Using copyleft code means the whole resulting binary is subject to copyleft.

No. That's formally wrong, and it doesn't imply what you think it implies.

Using copyleft code means that if you distribute the resulting binary, you also have to distribute the corresponding source code. If you can't do that, you can't distribute the binary.

Is that a problem? No. You distribute object files and libraries, accompany the copylefted libraries with their source code, and let the end user link them together statically. Problem solved. Arguably, that's how all software installation on Unix should work; it solves so many other problems, too.

x3blah2• 6 years ago

"Also known as rump kernels a name inspired by the infamous purge of royalists from Parliament following the English Civil War this process involves creating a fork of an existing kernel codebase and manually purging it of the components deemed unnecessary to the target unikernel."

That appears to come from the FAQ on Github for "rumprun" dated 2015.

Rump kernels were introduced in NetBSD in 2009. It was an described then as an acronym for runnable userspace meta programs.

https://blog.netbsd.org/tnf/entry/runnable_userspace_meta_pr...

I have not used rumprun for Linux but I still use the rump utilities included with NetBSD.

ncmncm5• 6 years ago

Full article text:

http://sci-hub.tw/10.1145/3317550.3321445

Maybe link the top-level post there?

x3blah2• 6 years ago

There is a link to the PDF on the page. No ACM membership required.

https://dl.acm.org/doi/pdf/10.1145/3317550.3321445

ncmncm5• 6 years ago

The link was not obvious to me. What is supposed to be wrong with using Sci-hub?

ncmncm5• 6 years ago

When I make a system where a unikernel could do the job, I usually want a full OS for program setup and initialization, and then an isolated core for the main loop, sharing (single-writer) memory pages with other, less performance-critical processes for logging, stats reporting, and any needed file system activities.

The makers of top-performing NICs have been quite good at providing direct user-space access to their hardware, typically by exposing a ring buffer in shared memory, and maybe mapping device registers too, so that the process on the isolated core never does another system call until shutdown weeks later.

It is some hassle to get customers to add boot flags (isolcpus=, nohz_full, rcu_nocbs=, rcu_nocb_poll, hugepages=, etc.), and to put any mapped files in /dev/shm or /dev/hugepages so the kernel won't invent excuses to block the procees, and to direct irqs to other cores; but unikernel setup is probably not simpler.

So, I'm not sure what a unikernel would get me. Portability, or independence from proprietary drivers?

xfs3• 6 years ago

Recently I found out ebpf jitting will cause interprocessor interrupts even with all the isolation configs available today. There's probably many more places where such interrupts could be generated and not handled by the current isolation mechanism. Not saying a unikernel is directly a solution but CPU isolation isn't perfect either and could use something from a unikernel.

bitcharmer• 6 years ago

I don't think the tuning you refer to is sufficient to bring the platform noise to levels required for some workloads. You will still see a lot of system call interrupts, TLB shootdowns, timer events, etc. Funnily enough yesterday I published an article tangential to this problem field.

http://bitcharmer.blogspot.com/2020/05/t_84.html

I'm not an expert on unikernels but my assumption is that you will see none of that OS jitter.

xfs3• 6 years ago

Good writeup, but is there any mitigation for TLS shootdowns?

ncmncm5• 6 years ago

If you have only one thread running in the process, memory usage is static, any mapped pages are writable only by the one process and are not backed by external storage, you have turned off timer interrupts and rcu reaps, and do not perform system calls, where are these TLB shootdowns and timer interrupts coming from?

axegon_• 6 years ago

Full disclosure: I have only briefly fiddled with unikernels. And in all honesty, I think there could be a good real life application for them. But the biggest problems I see is that even though they have been around for a while, building them is still incredibly complex and time consuming and there isn't a core community behind them and looking at it, it seems like they are starting to suffer from the javascript syndrome - hundreds of single maintainer or micro-communities doing their own thing and putting a sticker("unikernel" in this case) on top. As I said I haven't paid a whole lot of attention to them and I'm hoping someone is addressing these issues.

heavenlyblue3• 6 years ago

Isn’t that’s what this whole thread about? Making it easier by providing Linux as a compilation target.

eyberg9• 6 years ago

Well one of the problems here is that it's kernel work and not everyone has the skillset to do that work, worst no one wants to fund it.

However, the tooling is changing.

moonbug• 6 years ago

three objections: tooling, tooling, and tooling.

steeve• 6 years ago

Obligatory plug for Elias Naur's unik, a unikernel written almost entirely in Go, which can link with and run unmodified Go binaries: https://git.sr.ht/~eliasnaur/unik

Demo with virtio-gpu support: https://twitter.com/eliasnaur/status/1249765031299952646

MrBuddyCasino4• 6 years ago

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 some overlap with containers, and at this point, replacing them will require something a lot better.

FeepingCreature• 6 years ago

Who exactly would make that claim?

Didn't you hear? Some.

toyg• 6 years ago

Top men. Top. Men.

microcolonel3• 6 years ago

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 context switch costs). Now, if you just want to manage backpressure over the network, an application-hosted networking stack is probably a fine solution, but if you want to accurately translate disk backpressure to network backpressure it gets more complicated.

There are heaps and heaps of ordinary programs written for preemptive systems that would see noticeable, tangible benefits to users if they were run instead on unikernels; but the main thing halting adoption is the inconvenience of adapting programs. I tried getting Capstan/OSv to work the other day and the documentation dragged me through several apparently-outdated methods of achieving the same thing, all of which failed in incomprehensible ways. Tooling for these things could use a lot of work.

MrBuddyCasino4• 6 years ago

So, a niche technology for a handful of HFT firms, betting platforms and hyper-scale cloud vendors. Those already use non-mainstream tech (eg LMAX disruptor) to achieve max performance.

This is all nice and good, but the Unikernel guys claim since 20 years its the next big revolutionary thing. In the real world, the evolutionary approach using containers has turned out to solve the problems most people care about.

Don’t get me wrong, this is fascinating stuff. But there is a difference between „changes mainstream computing“ and „cool tech to shave off another millisecond of latency“.

eyberg9• 6 years ago

If you get a chance let me know what you think of our take on https://ops.city && https://github.com/nanovms/nanos .

trasz2• 6 years ago

It’s much easier to tweak a normal kernel (or just use whatever is already there, eg real-time scheduling to get rid of preemption) than move to a unikernel.

GregarianChild2• 6 years ago

I'm interested to learn why unikernels would be better at handling backpressure. Because there are fewer sources of interrupts that might interfere with each other?

arbarb3• 6 years ago

Who exactly would make that claim?

Will Serverless End the Dominance of Linux in the Cloud? https://dl.acm.org/doi/pdf/10.1145/3102980.3103008

eyberg9• 6 years ago

Security (general lack of user-land and in-ability to run more than one program), server density (run thousands of vms/box).

digi-cat• 6 years ago

https://www.nccgroup.trust/uk/about-us/newsroom-and-events/b...

egh5oon• 6 years ago

That does very little for security, if it's not a net negative at all.

Most attacks aim at executing arbitrary code in the process space of the application being targeted. The lack of user-land does not help.

neilwilson• 6 years ago

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.

gwillz• 6 years ago

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

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

fcantournet• 6 years ago

They also tend to need to be debugged & administered.

eyberg9• 6 years ago

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.

wmf• 6 years ago

So you're saying unikernel experts ended up writing a non-unikernel database. There's a lesson right there.

nick_kline2• 6 years ago

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 much flexibility to modify the os via config changes, adding new monitoring or whatever if you had the db directly connected to the os. I'd hate to give that up for more efficiency. There's a lot of 'strength' in an OS separating various things from the database itself, giving that flexibility.

A modern DB needs efficient interaction with the OS of course, but I'd say based on experience at many companies a bigger challenge than raw efficiency is the ability to implement changes in the db itself. I've worked on 4 or 5 major databases and we can always identify many ways to improve execution, plan selection, various aspects of the db, it's just the giant challenge to alter a big code base that blocks improvements more than OS layers. Improving plan choice can make queries thousands of times faster - but you have to be able to implement it.

DrScump• 6 years ago

  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).

smabie• 6 years ago

kOS (k language as a standalone OS) was a project but I guess it got canned. Unfortunate, I would love to have tried out a standalone kdb+/q installation.

edjrage• 6 years ago

So apparently you need cookies to show text.

"We use cookies to ensure that we give you the best experience on our website.

It seems your browser doesn't support them and this affects the site functionality."

cm2187• 6 years ago

The site has just the right number of modal windows hiding the content: a cookie consent form, a covid 19 information at the bottom, and some recommendations on the right, and if scroll back up the site banner...

sigwinch28• 6 years ago

The old dl.acm was no amazing bit of modern design, but it was definitely much better than this mess.

Yet again the ACM showing how out-of-touch it can be with its members and patrons.

ancarda• 6 years ago

Eh, sounds like every other website to me.

Wouldn't people say ACM are out of touch if they don't adopt all the common junk you see on websites? Their website is so out of date it doesn't have a cookie banner! Best I get my information from somewhere that keeps up with the times ... and the law!

folex• 6 years ago

https://www.researchgate.net/publication/332329656_Unikernel...

researchgate is much much nicer, and gives a lot of info: citations, related papers, you could go see info about authors, ask questions, see what project this paper is on. Researchgate allows discovering interesting papers in a seamless maner.

rectang5• 6 years ago

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?

EnigmaCurry• 6 years ago

is that not what the linux realtime patches do? https://wiki.archlinux.org/index.php/Realtime_kernel_patchse...

rectang5• 6 years ago

I've been researching this for a long time, and it's unclear to me whether Linux with PREEMPT_RT patches would meet that sub-ms requirement. I see numbers all over the place from various sources, from sub-millisecond to more than 10 ms.

10 milliseconds is often considered the threshold of human perception with regards to audio latency. (It's possible that it's lower under some circumstances, but 10 ms is a good enough approximation for my purposes.) My goal is to create a sound/music tool which runs lots of DSP and which has a total system latency of under 10 milliseconds, including OS, application (including intrinsic latency of DSP procedures), hardware, and sound in air (about 1 ms per 3 meters).

When I read about latency, I often see "we're at 6-9 ms, that's good enough because it's not perceptible". Unfortunately, that's not good enough if there are several components which contribute to total system latency and they are all pushing 10 ms. Hence, my sub-ms requirement for the OS.

Committing to a platform will be a costly choice. I don't want to invest in writing for realtime Linux only to find that I really need to run a hardcore RTOS, or run dedicated DSP chips, etc.

That's why I'm interested in whether running a unikernel can offer stronger guarantees.

jibanes• 6 years ago

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

rwmj24• 6 years ago

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.

gandalfgeek• 6 years ago

If you're too lazy to read the whole paper I've made a quick explainer video:

https://youtu.be/3NWUgBsEXiU

sureshv• 6 years ago

Wonder how this differs from exokernals: https://pdos.csail.mit.edu/archive/exo/

GregarianChild2• 6 years ago

Exokernels are orthogonal to unikernels.

Unikernels run exactly one application, but can be based on an arbitrarily complicated OS (specialised) to that one application. Exokernels can run arbitrarily many applications, but OS functionality is minimal and limited to ensuring protection and multiplexing of resources.

Specialising a rich OS (such as Linux) to a single application might yield OS functions that are as restricted as those you find in an exokernel.

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

Related Stories