4 ms·

This seems to be the same fundamental story as WSL1 versus WSL2 elsewhere. Worse being better, the latter’s clunky VM-based approach won out over the more elega

by thom 1y ago

This seems to be the same fundamental story as WSL1 versus WSL2 elsewhere. Worse being better, the latter’s clunky VM-based approach won out over the more elegant syscall translation layer of the former.

kokada 1y ago
I am not sure if I consider the VM approach necessary worse than a syscall translation, especially considering that both Android and Linux are moving targets. It is different from creating an emulator for a console, that you can assume that the hardware/software will never change (or at least for modern consoles, it will never change for a specific version of game). Also VMs can be really fast thanks to virtualization instructions and para virtualization techniques.
- ChocolateGod 1y ago
  > both Android and Linux are moving targets Existing Linux syscalls rarely change and never in a non-backwards compatible way, extra options are added.
  - yjftsjthsd-h 1y ago
    And there's enough use of long lived distros (RHEL being the extreme case, but also Ubuntu and Debian) that most software supports older Linux versions. In fact, in the case of this particular discussion (Android compatibility), it's quite normal (unfortunately) to have ancient kernels. And also user apps rarely care about the kernel and just use the Android APIs that sit on top of it, so I'm skeptical that AoW would actually need to worry about rapidly changing its kernel emulation.
  - dwattttt 1y ago
    They don't, but a Linux userland sure does. WSL1 was plagued by a change glibc made around nsleep & realtime clock usage, causing random programs to just fail under WSL1. At that point, either Linux distros have to consider Windows' "almost" Linux kernel as a target to support, or what Microsoft did, which was to use a VM and a "real" Linux kernel.
    - Hilift 1y ago
      Microsoft created a doozy of a bug when OpenSSL changed gmt_unix_time to a random value. They were using that for startup sync of hosts. Strategically, I don't think WSL is a real product that would be customer facing due to "WSL has been designed and built to use with inner loop development workflows. There are design features in WSL that make it great for this purpose but may make it challenging for production-related scenarios compared to other products." https://learn.microsoft.com/en-us/windows/wsl/faq https://learn.microsoft.com/en-us/windows/wsl/faq
hypercube33 1y ago
Windows 11 had a flavor of this - Windows Subsystem for Android and it was neat. I think they hid it behind the Amazon app store but you could side load apk files.
rustcleaner 1y ago
I, a once proud Gentoo GNU/Windows user myself for a bit back in the Win7/2008R2 era, too was disappointed when they strangled SUA to death and took the easy way out with VMs. Would have been way cooler to keep the POSIX subsystem and have a versatile kernel. Microsoft could have pivoted towards the FOSS ecosystem with a hybrid Win32/POSIX environment.

by thom 1y ago

kokada 1y ago

I am not sure if I consider the VM approach necessary worse than a syscall translation, especially considering that both Android and Linux are moving targets. It is different from creating an emulator for a console, that you can assume that the hardware/software will never change (or at least for modern consoles, it will never change for a specific version of game). Also VMs can be really fast thanks to virtualization instructions and para virtualization techniques.

ChocolateGod 1y ago
> both Android and Linux are moving targets Existing Linux syscalls rarely change and never in a non-backwards compatible way, extra options are added.
- yjftsjthsd-h 1y ago
  And there's enough use of long lived distros (RHEL being the extreme case, but also Ubuntu and Debian) that most software supports older Linux versions. In fact, in the case of this particular discussion (Android compatibility), it's quite normal (unfortunately) to have ancient kernels. And also user apps rarely care about the kernel and just use the Android APIs that sit on top of it, so I'm skeptical that AoW would actually need to worry about rapidly changing its kernel emulation.
- dwattttt 1y ago
  They don't, but a Linux userland sure does. WSL1 was plagued by a change glibc made around nsleep & realtime clock usage, causing random programs to just fail under WSL1. At that point, either Linux distros have to consider Windows' "almost" Linux kernel as a target to support, or what Microsoft did, which was to use a VM and a "real" Linux kernel.
  - Hilift 1y ago
    Microsoft created a doozy of a bug when OpenSSL changed gmt_unix_time to a random value. They were using that for startup sync of hosts. Strategically, I don't think WSL is a real product that would be customer facing due to "WSL has been designed and built to use with inner loop development workflows. There are design features in WSL that make it great for this purpose but may make it challenging for production-related scenarios compared to other products." https://learn.microsoft.com/en-us/windows/wsl/faq https://learn.microsoft.com/en-us/windows/wsl/faq

hypercube33 1y ago

Windows 11 had a flavor of this - Windows Subsystem for Android and it was neat. I think they hid it behind the Amazon app store but you could side load apk files.

rustcleaner 1y ago

I, a once proud Gentoo GNU/Windows user myself for a bit back in the Win7/2008R2 era, too was disappointed when they strangled SUA to death and took the easy way out with VMs. Would have been way cooler to keep the POSIX subsystem and have a versatile kernel. Microsoft could have pivoted towards the FOSS ecosystem with a hybrid Win32/POSIX environment.