Game consoles, and back in the day most MS-DOS, Amiga and Atari Games that only used hardware directly with OS services could in retrospective be considered some form of unikernels.
Amiga games used to be written such that they would boot the computer from floppy.
It's from an era before ubiquitous MMUs, even in IBM mainframes. It therefore was structured as a library OS, with even less separation between it and the application code than even MSDOS and it's applications.
Transaction Processing Facility: A Guide for Application Programmers by R. Jason Martin is a decent book I'd recommend on the subject.
I believe Cisco had an unikernel running on Vmware for SDN vSwitches.
Makes sense: you "only" need to move packets from some vLan to another vLan/vNic after applying policies... and you can forget about supporting hardware modules alien to you.
The automotive domain definitely use them (e.g., Open Synergy and others), since their efficiency means they consume fewer resources on ECUs, and their relatively small Trusted Computing Base (TCB) not only reduces exploits but also means certification is cheaper/faster.
Very interesting. As an application dev I'm curious to know what it would take to have a, let's say, Actix-web stack bundled with a unikernel, or a MeiliSearch engine bundled with a unikernel.
Both of these now live in Docker containers along with a whole Alpine system. I'm correct to believe that unikernels could change this, right?
Lwt [1] based web frameworks can be used on MirageOS if they provide an interface that allows someone to swap out the unix dependent pieces. One such framework is Opium [2], that provides most of its features in a unix independent code library `opium_kernel`. Its fairly straightforward to run an opium app on mirage. This example needs to be updated to the newest apis in the released version of Opium but this can provide some hints about how to run an opium app on mirage: https://github.com/anuragsoni/ocaml-opium-unikernel.
If a lower level web toolkit is sufficient then ocaml's cohttp [3] library has been available on mirage for quite some time now.
The `opium_kernel` example I linked to above is running on top of https://github.com/dinosaure/paf-le-chien which is a mirage layer for httpaf. Opium itself has also moved to using httpaf as the underlying layer.
There was an example running on erlang-on-xen (later renamed ling) which spawned a vm per request. When not hammered by traffic from aggregator sites, it could respond in a few milliseconds.
No, it was not Jitsu. Jitsu is based on MiragOS/OCaml, Erlang-on-Xen was also a Xen-based unikernel like MirageOS but was (as you can guess) Erlang specific. I think you can now find it at https://github.com/cloudozer/ling .
I suppose the right answer is "it depends". For most unikernels the answer is no: they are highly specialized, often targeting a single application or language, and built on top of small/basic OSes. Some of them have targeted various levels of POSIX compatibility, e.g., OSv (http://osv.io/) and HermiTux (https://ssrg-vt.github.io/hermitux/) though they don't always support a large number of syscalls/applications. An older project was Rump (largely abandoned), which used the NetBSD kernel to be (mostly) POSIX compatible, though performance wasn't great and it's largely abandoned. An active project targeting at least partial POSIX compatibility is Unikraft (http://www.unikraft.org/).