With the advent of any-arch binaries, and fast emulation (qemu wasm), it probably won't matter if it is x86 or not.

Why advent? That was already standard on OpenSTEP.

Can you explain? I vaguely recall using it on sparc workstations a couple decades ago, but I wasn't coding for that target. A quick wiki read says it was an API framework that was "endian free" and that it trageted the three architectures that next ran on. Was it doing emulation for software using it? Or was it, itself a single binary? Or both?

You had all binaries on the same executable.

https://en.m.wikipedia.org/wiki/Mach-O

And NeXTStep OpenSTEP's predecessor had already implemented it.

Might have been, I mentioned OpenSTEP, because NeXTSTEP didn't need to be cross platform, that requirement only came to be with the former.

NeXTStep was cross architecture I ran and compiled Objective-C code on HPPA, i386 and 68000 machines. I suspect I built for SPARC as well

I stand corrected.

Multitasking can go to hell I guess.

Why? You can easily implement a scheduler. And there's multiple cores. And potentially multiple instances on the hypervisor.

"Easily" is doing a lot of work there.

Yeah I re-read it later and was like.. ok, fine, I should put "easily" in quotes ;-)

Still, it's entirely feasible.

I mean, if you have one task to do only, multi-tasking is kind of pointless yes

It is nice to be able to listen to a podcast in the background while playing a game, and have the sound come out the same speakers/headphones. It's much harder to do that if the game runs bare metal.

Each of those services can be a unikernel being managed by a type 1 hypervisor.

Absolutely. But I think I'm correct in saying if today I wanted to play a game shipped as a unikernel, it would be pretty difficult to have the game and spotify running. First we need a spotify unikernel, then we need people to accept having to use the new unikernel version of spotify just when they play the game(s), maybe get used to the spotify unikernel not having access to graphics hardware, etc. Or we run spotify in a traditional OS in the hypervisor and lose all the benefits we were shooting for in the first place.

Technically all manageable, but that wasn't the aspect I was focusing on, rather the reality that we couldn't just do this today, or even really all that soon.

Alternatively, PCs become games consoles when running games, and you just can't do multitasking, just like you mostly can't on a PS2, etc. Honestly, I think this would be the most likely outcome if games went down this road.

In a way it is a return to the days of playing games in 8 and 16 bit platforms. :)

Generally speaking multi-tasking includes both multi-processing and multi-threading. Many unikernel projects support multi-threading so languages like Go/Rust can work very very well when deployed as unikernels. As for scripting languages like javascript, python, ruby they are inherently single-process regardless so you have to horizontally scale those. (eg: instead of having N servers having nginx front-end X app servers you just right size your workloads and spin up as many app servers you need behind a load balancer)

There's only one project I'm aware of that does multi-processing: https://cybersecurity.springeropen.com/articles/10.1186/s424... .

Define multitasking :)

There was a company (sadly defunct) that was building Erlang unikernels, and you can't say Erlang doesn't have multitasking.

Why would you need an OS when you're running on bare metal? Isn't the whole idea of an Operating System managing shared and limited resources?

It's also about hardware abstraction. You don't want to rewrite your network stack for each platform but the unikernel can handle that.

It doesn't have to be unikernel either, Linux without anything else, your code being PID 1 is also good: no cruft and extra services that can be security holes, but great platform support, optimized network stack etc.

Of course if you just run on one hardware why not, just write the drivers you need.

How would something like this support logging, telemetry, debugging, etc as part of enterprise-grade software clusters if it has “no other services”?

It manages the services itself. Your app is one level down the totem pole. The http bit is just another service managed by your app.

An OS includes a kernel. A kernel cannot control hardware without drivers.

What if one could run an application without a full kernel, using only the drivers needed for a single application.

It is not a full kernel with a full set of drivers. Maybe we can call it a "unikernel".

Yeah an OS seems redundant here if you can just write freestanding bins.

Isn't this, in a very roundabout way, an echo of docker? Or at least the abstraction Docker relies on?

I definitely see this as an alternative route from docker containers / WASM.

Yes, containers and unikernels are possible answers to the same issue. If you consider an application running on a virtualised OS you have three layers: hypervisor, os, application with some duplication of functionality between the hypervisor and the os.

From there, if you want to simplify you can either add hypervisor-like isolation functionalities to the OS (containers) or move the little that’s actually needed from the OS into the application (unikernels).

That’s why Docker bought MirageOS a few years ago.