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.
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.
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.
(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.
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".
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.
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.
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.
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?
It's going to take a decade to refactor things to remove that layer. Once done, you'll be able to safely run a process against a list of resources.