Agreed. Operating systems abstract resources, the fact that we needed containers and VMs point to the fact that the first set of implementations weren't optimal and needs to be refactored.

For VMs, security is the one concern, the others would be more direct access to lower levels and greater access to the hardware and internals than just a driver model.

For containers I'd say that the abstraction/interface presented to an application was too narrow: clearly network and filesystem abstractions needed to be included as well (not just memory, OS APIs and hardware abstractions).

I imagine that an OS from the far future could perform the functions of a hypervisor and a container engine and would allow richer abilities to add code to what we consider kernel space, one could write a program in Unikernel style, as well as have normal programs look more container-like.

> one could write a program in Unikernel style, as well as have normal programs look more container-like.

Projects similar to this exist today with https://nanos.org/.

You can run any typical web app (without having to re-write it) in a POSIX compliant Unikernel on most major cloud providers and bare metal. Each service runs in its own Unikernel.

I had its creator on my podcast the other day at: https://runninginproduction.com/podcast/79-nanovms-let-you-r...

Cool. Thanks for the Nanos pointer!

Sadly, two generations of programmers probably need to die first, before we adopt the RnD that's been done in the last decade or three, or for what's been done the systems that languish in the shade of UNIX to be done again in the mainstream.

Most people use containers as a packaging format - instead of .tar.gz.

People run containers with host networking and bind-mounting everything and nobody minds.

(The story for hosting providers is a bit different, but they're not the main driver for Docker adoption.)

(I'm not holding my breath for the refactor though... We're stuck at a local maximum and we're better at adding stuff,rather than removing/refactoring them.

Also- just about EVERYTHING is built on top of these current layers)

Genode is a project in Germany I've been watching for a while... right now I think they are the best chance of getting there. They've been making it closer and closer to the point where I can latch onto it and start using it.

There has to be a microkernel at the bottom of everything, which rules out anything Linux based. Genode does use Linux drivers though, in a contained way.

Yeah, Genode looks awesome, I've been rooting for it for a while.

I love their approach to hierarchical distribution of resources.

I'm embarrassed to admit that I haven't actually booted and played with it yet.

You just subsume layers. Maybe as simple as Xen++ with a containerd frontend.

Yeah, sounds like a good approach.

I liked the direction Joyent was taking with Iluminos and Triton.

Problem is the fact that the tech is tied to a market, which has different rules and rates of evolution.

Best bet for a refactor is with a new market/platform.

It's not just security. There's incompatible dependencies. Virtualization allows you to run Windows and Linux on the same server, 40 different C libraries with potentially incompatible ABIs, across X time zones and Y locales, and they'll all work.

You can provide the same level of replication and separation of dependencies in an OS, but at a certain point you're just creating the same thing as a hypervisor and calling it an OS and the distinction becomes academic.

I think that eventually every OS will converge on the same API, for now there's APE - Actually Portable Executables from the Cosmopolitan C library to get one code base working everywhere without a ton of ifdefs.

We've had capability based security frameworks aka MAC (ex: AppArmor) in Linux since 1999 or earlier. Containers (which also existed long before docker) have been popularized for convenience, and virtualization would still be useful for running required systems that are not similar to the host. If anything it looks like we're going towards a convergence with "microvms".

Capabilities are like taking a $5 bill out of your wallet, handing it to your child, and letting them buy ice cream with it.

You delegate $5, nothing more than $5 can possibly leave your wallet as a result.

AppArmor is like putting a vault around the ice cream truck and giving a strict list of who is allowed to buy what ice cream. Hardly the same thing.

Ehh, isn't MAC nearly the opposite of capability based security though? At the core of capability based security is that you don't separate authority to access a resource from your designation of that resource. MAC though seems to go all-in on separate policies to control what gets access to what.

A convinience that only exists when the target hardware and underlying kernel are compatible with the development environmnet, when that isn't the case, oopla, a VM layer in the middle to fake the devenv, or in the devenv to fake the serverenv.

It already exists in the IBM mainframe. But nobody wants to write apps for it..

Who would want to use those weird, outdated languages and technologies, though?

It's better to use a modern DevOps stack involving Kubernetes, Ansible, YAML, Jinja2, Python, cron jobs, regexes, shell scripts, JSON, Jenkinsfiles, Dockerfiles, etc.

Yep. At this time it wouldn't be great to just imitate the best mainframes compartmentalization, because we have much better experimental systems. But they are still much better than anything common on commodity hardware.

Likely because IBM mainframes are outside of the reach of hobbyists and SMEs.

No, it's because the "capabilities" built into mainframes aren't accessible by users, only the system administrators. The granularity just isn't there.

That too. But I'd argue that not being able to access or set up a mainframe due to its unaffordability or esotericism is a much more powerful barrier, that makes granularity a moot point.

Virtualization, no. A hypervisor running a Windows kernel and a Linux kernel side by side is not about capability-based security. You can even see it like cap-based security approach: VMs only see what the hypervisor gave them, and have no way to refer to anything that the hypervisor did not pass to them.

Containers, yes. They are a pure namespacing trick, and can be replaces by cap-based security completely.

Also, VM's make multitenancy really easy.

It allows you to divide up physical computing power across multiple people/organizations etc.

Containers make this kind of distinction far more hazy.

Emulation and API compatibility layers can be done in more ways than an hypervisor-based VM. And many of those other ways perform better.

What are they? Why the hypervisor approach is the standard then?

You can already make Linux run any binary you want for the same CPU architecture, for example, wine uses this functionality. You can make it run natively binaries from other architectures with a rewriting VM like qemu (although I'm not sure qemu itself can port binaries between architectures, just that it's rewriting VM). Your VM can enforce security with a sandbox instead of a hypervisor, like the Java, C#, node ones do.

Hypervisor is not the standard, it's one of the many ways people do it right now.

I am fairly certain that virtualization is going to be a core tenet of computing up to and including the point where the atoms of the gas giants and Oort cloud are fused into computronium for the growing Dyson solar swarm to run ever more instances of people and the adobe flash games they love.

I highly doubt that. If so inclined you can do that today with SEL as the granularity and capability is there, but how long would tuning it in would take? What about updates - will it still work as expected? What about edge cases? What about devs requiring more privilege than is needed?

Agreed 100%, but you still are going to get the old-timers who insist that virtualization and containers just make things more difficult and that their old school approach is the best.

Good, that's a very universal interview question that will get me a practically direct answer to the actual question. It's not easy today... I'm asking about JS/HTML/CSS if the candidate isn't web-oriented, but what do I ask the JS guys? Perhaps a view layer bait?

going by how the web is doing today, the refactor you refer to will never be done.