Linux app VMs
Similar to the Linux driver VMs issue, the Linux app VMs will make Linux-only programs run on Redox.
Why? some programs rely on Linux kernel technologies/interfaces to work, like containers and filesystems.
FreeBSD and NetBSD have a Linux compatibility layer to run unmodified Linux binaries using their ported Linux kernel API, it's possible because the BSDs design is similar to Linux, thus a kernel module is developed without massive changes.
Even with that kernel module, some Linux programs don't work, this kind of implementation can't be done on Redox without massive changes, because it's a microkernel with much more simplicity.
Filesystems rely more on the kernel APIs than other programs, all development is focused on these APIs, even if you port a filesystem to other OS, it will be hard/time-consuming to adapt the new changes from other OS if it's a big/complex filesystem.
To mitigate this you can use a FUSE driver or a VM, FUSE is an universal API but lack some filesystems and the drivers can be unmaintained easily.
A VM will bring many filesystems and their improvements over the time with a small configuration effort, at the cost of some overhead (can be optimized).
Like the Linux driver VMs proposal, the Linux app VMs can be simple and made for a specific use-case, we can have a specific daemon VM for Flatpak, other for Docker, other for Snappy, etc.
Each daemon VM will be optimized/built for his specific necessities, that way we reduce memory usage, CPU time, bugs and complexity.
Daemon proposals
-
flatpakd (a VM for Flatpak applications) -
snappyd (a VM for Snappy applications) -
dockerd (a VM for Docker applications) -
podmand (a VM for Podman applications) -
genericd (a VM for any application)
Suggestions
- Flatpak, Snappy, Docker and Podman binaries can be static linked to relibc.
- Remove the GNU/Linux userland libraries/tools from VM images.
- We could have an option to have one VM per app.
Using one VM per app we will have the VM crash isolated on the program, but it will use more memory and CPU.