To be honest, I would prefer to have my guts sprayed with honey and exposed to a large colony of ants.

agreed, WSL1 was an ambitious, cool project

Agreed, but I could never get past the thought “all the friendliness of Unix, all the security & stability¹ of Windows”!

--

[1] never trust an OS that can't reliably be left alone for 24 hours without rebooting itself while you aren't looking

If windows is certified to run the US military its secure and stable.

Debatable.

In any case: How do I get the version+configuration used on US military installations on my machine?

The stripped down very carefully configured Windows the military uses isn't the same Windows most people/businesses are using.

I need to get my hands on that Windows Military Edition®

Do they use LTSC or something else?

To be fair it's quite impressive WSL1 got this far, but ultimately it was doomed from the start if one targets perfect compatibility.

Given there's no "Linux specification" the spec is the actual code, nooks and crannies and all, down to nitty gritty details and implicit behaviours that end up indirectly getting relied upon. The only solution is to basically implement these in excruciating details, which may or may not possible depending on the Windows things being wrapped. Then the question of intellectual property, copyright, and licensing come in, as MS would have to ensure that it's a clean room implementation or be subject to GPL terms (cue the Oracle Java vs Android shenanigans).

So at some point it makes sense to just throw a VM at the job, cleanly separating realms, sidestepping any legal landmines, and ensuring perfect compatibility, especially as the whole HyperV infrastructure is quite solid and used throughout the MS ecosystem as a general strategy, e.g the Xbox uses HyperV to isolate games and apps.

Tangent: I wish (the VM part of) WSL2 would be available on Xbox, allowing one to run Linux while keeping the whole regular OS and features!

WSL1 was a dead end, not because of compatibility but because of performance, especially when it comes to file system access and process operations. Windows is supremely complex in both, with things like filesystem filters, fused fork+exec+setuid+setcap+doWindowsStuffThatDoesntHaveUnixEquivalents syscalls, all of which you cannot avoid. If you layer a Linux syscall personality on top of that, things will get molasses-slow quickly.

Correct - the semantics are simply too different to directly emulate. The simple fact that starting processes takes much longer in Windows cripples naive implementations, for example.

"fused fork+exec" otherwise known as "process creation" (that is one thing i'll give windows credit for)

To be fair, at least on the syscall side, WSL1 was built in kernel space on Pico Processes, not regular NT processes. They very much were able to avoid the windows cruft. It really seemed to be the long tail on compat and the impedance mismatch on the vfs layer that killed it.

Wine does all of that though for Windows, even when the syscall structure and caveats or compatibility fixes for the Win32 APIs are unknown.

With Linux, all the syscalls and their bugs are documented, at least in the commit history, if not the man pages.

Wine is an amazing piece of software,but it’s still easy to find issues in many apps. Microsoft wanted something it could sell as a general Linux replacement, so it needed close to 100% compatibility.

My point still stands — Linux syscalls are documented, the Win32 APIs and syscalls aren’t.

> Linux syscalls are documented

It doesn't mean they are implementable atop NT/Windows kernel facilities, semantics, and behaviours, in which case it's an alternative implementation to maintain that foregoes integration.

While Wine's effort and compatibility levels achieved are impressive, they actually prove my point: compatibility is a constant fight, there are a ton of tunables (some automated), and it's still not perfect (which is what a VM gives you for essentially free).

There's more than "basic" syscall interface to it though, there's the whole implementation of features (that are GPLv2 licensed) e.g btrfs? iptables? ebpf? ptrace? hold my beer; run kernel-backed wireguard in WSL2? no problem; alsa? you betcha; real time facilities? sure! custom kernel with a missing feature like usb passthrough? be my guest; contribute to the linux kernel code? entirely possible. It's all there, today, and not at the mercy of MS's will or ability to implement this or that.

yeah, windows already ran in hyper-v anyway for protection of high-level processes at the hypervisor level, so it probably wasn't even that much of a leap to introduce other VMs alongside windows (aka WSL2)

WSL v1 hasn’t gone anywhere. It likely won’t until they fix the issues with v2 and VPNs.

I'd never used WSL1, but I use WSL2 at work (where I'm forced to use Windows). It's OK. I don't understand all the fanfare about it, though, because it's only OK. I still need to have a real Linux system around. WSL2 isn't an adequate replacement.