3 ms·

FreeBSD has this today - https://wiki.freebsd.org/Linuxulator https://wiki.freebsd.org/Linuxulator

• joveian 4y ago
  VMs with some level of integration along the lines of what Microsoft did with WSL2 is a safer approach.
  • 999900000999 4y ago
    How hard is this for a new OS to implement ? I imagine the biggest barrier to adoption is always application support. If I can run chrome on an OS you made last week, I'll be set
    • joveian 4y ago
      Hardware support is always a big issue with a new OS designed to be run directly, it is much easier for a new OS to start the other way as a VM run by a more mature OS. Getting qemu working is also quite a bit of work, although Xen Dom0 support would be easier. There are security implications of the hosting implemention as well. However, long term a general purpose OS will almost certainly want to support VMs so the extra work to do a WSL2-style integration is less than trying to keep up with the large number of complex Linux system calls for direct binary compatability and there are also major security implications to doing things that way.
      • 999900000999 4y ago
        Would it be possible to implement a VM host in C or something that can compile for a different platforms? I've never designed an OS so I might be off base here.
        • joveian 4y ago
          This is what most of the existing open source operating systems are and it is much easier to contribute to those or fork one that does most of what you want. If you are aiming at a POSIX system then there is a fair amount of work but you at least then get a huge amount of already written software that you can run (IIUC Redox is aiming for this but written in Rust). A structure like Qubes OS would make it easier to do something less like POSIX while still running some existing software. If you are interested in OS design, I suggest taking a look at NetBSD. It is a full OS supporting a bunch of different platforms all in one source tree and not quite as complex as Linux while still supporting most software the works on Linux. It has a nice crosscompile system and "rump kernels" that allow large parts of the kernel to be run in userland for testing (I think GNU Hurd also uses this for some device support). I think it has had at least a couple hundred active volunteer developers at any particular time for about three decades now (vs 7 years with mostly one developer it looks like for Redox). It is really quite a lot of work. src/sys is the kernel and src/sys/arch has the platform specific code, such as: https://nxr.netbsd.org/xref/src/sys/arch/amd64/ https://nxr.netbsd.org/xref/src/sys/arch/amd64/ https://nxr.netbsd.org/xref/src/sys/arch/x86/ https://nxr.netbsd.org/xref/src/sys/arch/x86/ x86 has the generic x86 support shared between 32-bit and 64-bit systems while amd64 has the 64-bit specific stuff. The rest of the tree is relatively easy to understand as well (e.g. most devices are under src/sys/dev), although a few things are in less than optimal place due to NetBSD still using CVS (there are git and hg mirrors so no need to learn CVS). The tech-* mailing lists can have interesting discussions. https://mail-index.netbsd.org/ https://mail-index.netbsd.org/ https://netbsd.org/ https://netbsd.org/ For Linux, LWN is a great resource for learning about OS stuff with in depth summaries of disscusions on many topics as they come up: https://lwn.net/ https://lwn.net/ It looks like Redox has a web forum, subreddit, and gitlab issues: https://redox-os.org/community/ https://redox-os.org/community/
          • 999900000999 4y ago
            Thank you ! If never been good at C, but I'm enjoying reading though this