lobsters score: 1 · tags: virtualization, windows
WSL is central to our commitment to making Windows the best place to build, run and manage Linux workloads.
This is one of the most bonker sentences i’ve ever read.
score 1 · canonical
I think it’s just an acknowledgement that Linux is where people run their code and Windows needs to be able to support that if they want to keep marketshare for developers.
score 1 · canonical
Everything I use runs in either a browser or on a Linux VM. Why am I still on Windows lol
score 1 · canonical
The first two sentences:
WSL is central to our commitment to making Windows the best place to build, run and manage Linux workloads. As AI, cloud-native development, containers, and open-source ecosystems continue to converge on Linux, more developers are choosing to perform these workloads directly on Windows devices.
were absolute gobbledygook. I wonder if that is as painful to write as it is to read. The linked architecture blog post makes a much clearer introduction. If you read it instead of the introduction, then read the New Commands and Enterprise Manageability sections, you’re both in for a less painful read and are more likely to come away understanding whether you need to care about this.
score 1 · canonical
Seems like a convenient alternative to the normal route of installing a linux distro in WSL, then installing docker engine.
score 1 · canonical
The ‘normal’ flow on Windows is to use Docker Desktop, which does this for you. The same is true on macOS, where Docker Desktop uses Virtualization.framework to manage a Linux VM. This is now problematic because Docker Desktop has a license that requires paying per seat for companies above a certain size (including Microsoft, which actually pays the license). I suspect that developing this cost less than Microsoft’s annual license fee to Docker.
It looks as if this uses the same one-VM-for-all-containers model as Docker Desktop. Apple’s Container tool instead uses one VM per container, which is a better security model. I haven’t looked in detail at how Docker Desktop works on macOS, but Podman’s
podman machinecommand defaults to mounting the user’s home directory and a bunch of other things in the VM so that bind mount into individual containers. This means that a container escape in the Linux VM can give you complete read-write access to the entire home directory. In contrast, Apple’scontainertool attaches host filesystems on demand and isolates them to each VM, so a container escape in the VM can access only files exposed to the container (a VM escape can still damage a lot more things, but that’s harder).
score 1 · canonical
deleted by creator
At first I thought this might be a stunning return to the WSL 1 architecture where Linux syscalls were translated into Windows syscalls at the container boundary, but reading the architecture blog post makes clear the containers are all running in the WSL 2-style heavily-paravirtualized Linux VM on Hyper-V, just with container control machinery located outside the VM in Windows itself instead of inside the VM like before.
score 1 · canonical
I prefer to run Windows virtualized rather than Linux because Windows is a terrible hypervisor. It has an incredibly slow file system, constantly updates, reboots a lot and sends large amounts of telemetry.
score 1 · canonical
Why are you worried about commenting on news about WSL then? It seems pretty irrelevant to you.
score 1 · canonical
Having a preference does not mean I do not use it. My broader point is that if Microsoft goes in the direction of reducing Windows to a hypervisor for a Linux userland because they cannot design or maintain a coherent userland anymore, then you might as well run Linux.
score 1 · canonical
For some reason, I highly doubt that will happen. They will sooner turn the Windows Userland into a single Copilot chat prompt.
score 1 · canonical