News for hackers. Stuff that matters.

A comment on Sandboxing and workload isolation. Parent comment

Re:Sandboxing and workload isolation by jnwatson on Thursday July 30, 2020 @05:20PM (#24002954)
Containers are the API hack we put in because we couldn't change POSIX. The isolation and packaging were available in 90's era capability-based OSes (and 70's mainframe OSes), but backwards compatibility is more important than anything else, so we build matryoshkas of OSes inside OSes.
[ Parent | on HN ]
Re:Sandboxing and workload isolation by drybjed on Thursday July 30, 2020 @07:07PM (#24003797)
If I'm not mistaken, the current stack for a containerized multi-host environment could be roughly described as:

UNIX-like Linux kernel -> POSIX environment -> Kubernetes API -> Docker/CRI-O runtime -> POSIX environment -> Applications

From the developer perspective only the last POSIX layer is relevant, all the layers below are efforts to strong-arm old UNIX paradigms into 21st century compute/storage/network architecture. Could it be possible to replace this huge layered stack with something lighter that is better designed for the current compute/storage/networking paradigm in the cloud/data center and supports the POSIX compatibility layer for applications? For example:

Harvey OS -> orchestration API -> APEX -> Applications

Plan 9 -> orchestration API -> APE -> Applications

Clients could still rely on the desktop Linux distribution, Android or some other OSes.

[ Parent | on HN ]