The systrap backend of gvisor is quite an interesting middle ground for process isolation - faster than the ptrace backend and does not need KVM support on the host
We have tried to address this by upstreaming Linux kernel patches that improve its performance, but have been turned down by kernel maintainers due to gVisor being a wholly-owned Google project.
This and the act of donating it to cncf / Linux Foundation made it looks like a hostage situation. I hope those patches will get merged soon. Anyone got a link
It has always been the principle in the Linux kernel to only allow contributions which solve problems for multiple stakeholders, not just for one company and their project.
It has always been the principle in the Linux kernel to only allow contributions which solve problems for multiple stakeholders, not just for one company and their project.
This is a great principle! If only it was enforced consistently 🥲
I am not an expert, but GKH stance is that driver code needs be integrated into the existing kernel code architecture, which usually means hardware manufactures cannot carry over code from their Windows drivers (which they usually would like to).
Also the kernel does not accept code contributions to support proprietary drivers. Vendors successfully circumvent this by moving this code into the firmware.
I've always been fascinated by gVisor. The article mentions being able to run gVisor on macOS... but I guess it could go even further? I know Windows would be difficult, but maybe possible? Or perhaps other more-UNIX-like operating systems could use it to get Linux compatibility?
I've long wished a UNIX-like userland environment- ideally based on WASM. Imagine if there was a Debian port to such a WASM-based, UNIX-like userland environment. You could have development environments a bit like NixOS devshells, but that you could zip up and use across macOS, Linux, Windows, etc.
rrampage | 20 days ago
The systrap backend of gvisor is quite an interesting middle ground for process isolation - faster than the ptrace backend and does not need KVM support on the host
srcreigh | 20 days ago
Thanks for mentioning this. This may be useful for my older homelab mini PCs.
sluongng | 20 days ago
This and the act of donating it to cncf / Linux Foundation made it looks like a hostage situation. I hope those patches will get merged soon. Anyone got a link
JulianWgs | 20 days ago
It has always been the principle in the Linux kernel to only allow contributions which solve problems for multiple stakeholders, not just for one company and their project.
intelfx | 20 days ago
This is a great principle! If only it was enforced consistently 🥲
freddyb | 19 days ago
except drivers, I guess?
JulianWgs | 19 days ago
I am not an expert, but GKH stance is that driver code needs be integrated into the existing kernel code architecture, which usually means hardware manufactures cannot carry over code from their Windows drivers (which they usually would like to). Also the kernel does not accept code contributions to support proprietary drivers. Vendors successfully circumvent this by moving this code into the firmware.
mxey | 19 days ago
I feel like that’s not a great combination with “we don’t provide a stable API, just upstream your kernel modules”
ianloic | 20 days ago
My recollection was that they dumped a giant patch set that wasn't even indented to kernel standards....
koala | 20 days ago
I've always been fascinated by gVisor. The article mentions being able to run gVisor on macOS... but I guess it could go even further? I know Windows would be difficult, but maybe possible? Or perhaps other more-UNIX-like operating systems could use it to get Linux compatibility?
I've long wished a UNIX-like userland environment- ideally based on WASM. Imagine if there was a Debian port to such a WASM-based, UNIX-like userland environment. You could have development environments a bit like NixOS devshells, but that you could zip up and use across macOS, Linux, Windows, etc.
m_a_r_k | 19 days ago
Theres always WSL on windows, you could run gVisor through it
koala | 19 days ago
I mean, WSL2 is already a Linux VM, that already gives you Linux compatibility :)
(WSL1 was closer to what I propose.)