That is the point. It is nonsense to delegate your responsibility to something that is neither accountable nor reliable if you care about not tanking your reputation..
Every time you run `wsl --install <distro>` you are creating a new VM. Every time you run `wsl --unregister <instance id or name/>` your are removing a VM.
It is these two operations at the heart of OP's app.
WSL2 distributions share the same Linux kernel. They only get their own root filesystem with a Linux userland (/bin, /usr, /lib etc), and some WSL config meta data. This is then stored as a virtual disk image (which is probably where your belief comes from). But the kernel runs in a single utility VM. The distros share that kernel instance and they are separated via namespaces only.
This makes running multiple WSL2 distributions in parallel very performant btw, as there is no world switch.
I stand corrected. It makes sense that it is a chroot/rootfs rather than fully independent VMs.
re: side-by-side running, I always get socket and/port port problems when doing that. Without having looked into it at all I figure it is NAT collisions.
Okay, are you guys using wrong terminology? Are you talking about a filesystem image as a "VM", because that would not be correct. A "Virtual HD" (VHD) is not a VM. Do you think a WSL2 distro instance is a "VM" because it's persistent? Did you know Docker containers can be persistent as well, people just choose as a best practice not to use it like that? Does that make them magical VMs?
WSL2 has a single VM running as the process vmmem (or vmmemWSL in the newest versions). This is the single Linux kernel that will be shared by every WSL2 instance. It will also be the instance that hosts Docker containers as well. I mean, I'm just echoing myself and apologies for the repetition, but this is just easily confirmed, utter factual truth.
A rootfs is not a VM. WSL2 and containers have different nuances about their filesystem and isolation (WSL2 instances is aware of other instances, for instance, as a design aspect, and WSL2 persists rootfs changes while docker as a best practices does not), but they're more alike than different. And they share little in common with something like VirtualBox or vmware, which actually isolate every such system as VMs.
Again, sigh, if you install 10 WSL2 "distros", you will have 10 rootfs overlays on your drive, and 10 persistence VHD files. When you run these the VM they all run under in the shared vmmem instance, which is the single utility Linux VM.
Is there a way to visualize this on a running system or some documentation that describes it? I'm not familiar with the plumbing here but did try to find some documentation.
"WSL 2 uses virtualization technology to run a Linux kernel inside of a lightweight utility virtual machine (VM). Linux distributions run as isolated containers inside of the WSL 2 managed VM. Linux distributions running via WSL 2 will share the same network namespace, device tree (other than /dev/pts), CPU/Kernel/Memory/Swap, /init binary, but have their own PID namespace, Mount namespace, User namespace, Cgroup namespace, and init process."
"WSL 2 runs all distros in the same utility VM, sharing the same Kernel."
If you run multiple distros take a look at the process manager and find the single vmmem or vmmemWSL (newer versions have the latter). That single instance is all of the instances, and all of the docker containers you might be running as well, each with namespace isolation (with WSL2 having intentional bridging between them for convenience). Visualise it by doing something intensive in any of them and seeing the single process react, because that's the single utility VM responsible for all of them. Further while starting up the first WSL2 instance or Docker container is expensive, requiring the initialisation of all of the resources for the utility VM and the memory to support it, subsequent iterations are much less expensive.
Thanks, it wasn't out of doubt that I asked, but it seemed having a reference to point at would help resolve the contention. The Docker blog post covered a lot more detail, even about WSL2, which was really informative and I hadn't seen.
I wonder exactly how much work "container" is doing in that Microsoft blog post's description, because it doesn't seem like it's the same kind of environment as a runc or containerd container?
I also wasn't quite sure how much detail to infer from the behavior of vmmemWSL or vmcompute.exe, because my casual understanding is that there's some adaptation layer that handles mapping Linux calls to Windows calls. It seems reasonable to allow for process mapping or accounting shenanigans for any number of good reasons.
>there's some adaptation layer that handles mapping Linux calls to Windows calls
This was how WSL1 functioned. It used a shim layer, and honestly it was pretty neat for a lot of the basic stuff. It fell apart if you were doing more complex/advanced stuff, however, as there were many missing cases and exceptions.
WSL2 instead uses that utility VM, with a couple of special Microsoft kernel drivers to interact with the host system.
Since using jj I'm on the lookout for some kind of setting that will exclude the .jj folder from the repo _and_ any operation including git clean, without having to add it to the repo. I.e., make it completely invisible to git including `git clean -xdf`!
At the moment I'm making do with aliasing `git clean -e .jj`
> In the 20 years I've worked in software. I've never even seen a shop that works this way. From 20 person teams to 10,000 employee companies. Maybe I've been lucky. but to me it reads as a straw man. Something to punch against that doesn't really exist
30 years ago it was the norm. It really is true that the industry (standard) has shifted a lot in that time.
But I work at a place like this right now. I was hired by the new CTO to help them change this, having spent the previous 20 years actively avoiding places just like this.
Project-based planning by a roomful of not-technical people: Funding, scope, design, shape of team, deadlines, tech stacks, vendors etc. all "locked in" before any engineer is even approached, let alone asked for input.
I cannot overstate how uncanny it feels to be working here - like I have actually time travelled back to the 90s.
IMO saying a framework is a dev tool is like saying a cake mix is a cooking tool, because it allows you to be more productive when making a cake. Sure, if you look at it a certain way, it is correct. But that isn't the way the term is usually used.
Same with Extraordinary Attorney Woo and a lot of "originals" on netflix. They'll just buy the rights to air something and then slap their name on it like they made it. That said, I actually appreciate them looking for good media produced overseas and buying up the rights to those shows to bring them to the US. It's a good thing (although it'd be nice if put some effort in making sure there are always quality subs) but it can cause some people to think netflix is producing more good shows than they actually are.
I've worked at many big banks and corporations. They are all held together with the proverbial sticky tape, bubblegum, and hope.
They do have multiple layers of redundancies, and thus have the big budgets, but they won't be kept hot, or there will be some critical flaws that all of the engineers know about but they haven't been given permission/funding to fix, and are so badly managed by the firm, they dgaf either and secretly want the thing to burn.
There will be sustained periods of downtime if their primary system blips.
They will all still be dependent on some hyper-critical system that nobody really knows how it works, the last change was introduced in 1988 and it (probably) requires a terminal emulator to operate.
I've worked on software used by these and have been called in to help support from time to time. One customer which is a top single digit public company by market cap (they may have been #1 at the time, a few years ago) had their SAP systems go down once every few days. This wasn't causing a real monetary problem for them because their hot standby took over.
They weren't using mainframes, just "big iron" servers, but each one would have been north of $5 million for the box alone, I guess on a 5ish year replacement schedule. Then there's all the networking, storage, licensing, support, and internal administration costs for it which would easily cost that much again.
Now people will say SAP systems are made entirely of dict tape and bubblegum. But it all worked. This system ran all their sales/purchasing sites and portals and was doing a million dollars every couple of minutes so that all paid for itself many times over during the course of that bug. Cold standby would not have cut it. Especially since these big systems take many minutes to boot and HANA takes even longer to load from storage.
It started long before that. Cloud meant they were under drastic threat of being abandoned, because the cloud was (and still is) dominated by linux compute.
DotNet were shook, and shook bad. They went all out to make their runtime "cross-platform" because they faced an existential thread from lamdba+node.
The rise of the MBP also saw their dotnet ecosystem under thread from the other end of the stick - the developer end. Visual Studio cannot run on macos, so competitor IDEs that can were rising in their numbers. Hence the push for VSCode to try and claw back some IDE market.
Wait.. are we talking about LLMs or humans here?
reply