That said I will agree with other comments here, the version numbering is weird. I can't even tell _how_ to tell what version of WSL I have. Versioning is still an unsolved problem even for tech giants I observe.
"I'm already using WSL2, how old is this news? wink, wink"
With Mac OS I still like the Mac terminal more than the Windows terminal and just SSH into Linux boxes.
Still, for me, nothing beats a Linux desktop with i3wm on it.
If you need to keep doing this, I warmly recommend Mosh instead. https://mosh.org/
Mosh backed up with either tmux or screen is handy indeed.
(WSL2 is a lightweight VM in a traditional VM sense.)
Let alone if you use nodejs and have tens of thousands of files in node_modules. 'npm install' will cost you a whole 5 minutes.
From Windows (such as in Explorer) accessing WSL1 Linux files the safe way passes through a Plan9-derived file server as intermediary. This is surprisingly quick, but not without overhead. (But you can if you need to, do some unsafe operations directly on the files in NTFS.)
WSL2 when accessing Windows files accesses them through a Plan9-derived file server as intermediary. This is surprisingly quick, but not without overhead. WSL2 when accessing Linux files is using a Linux filesystem in a virtual hard disk file (VHD) similar to any other VM technology. Using a Linux file system it naturally exhibits POSIX semantics and is fast in the way Linux operations are expected to exhibit in lots of little files scenarios.
From Windows (such as in Explorer) accessing WSL2 Linux files passes through a Plan9-derived file server as intermediary. This is surprisingly quick, but not without overhead. Some operations Windows can do directly via VHD support in Windows.
It's a pity because Windows would benefit from faster file IO in general but it seems like they gave up on improving things as being too hard.
"Transaction" is a useful analogical word here for all of that complexity because how a mini-version of the CAP theorem trade-off space can be seen to apply to file systems. Windows heavily, heavily favors Consistency above all else in file operations. Consistency checks of course slow down file opening (and other operations too). POSIX heavily favors Availability above all else and will among other things partition logical files across multiple physical inodes to do that. Neither approach to "file transactions" is "better" or "perfect", they are different trade-offs. They both have their strengths and weaknesses. Using tools designed for one is always going to have some problems operating in the other. POSIX tools are always going look at Windows as "slow file IO" because it doesn't hustle for availability. Windows tools are always going to look at POSIX as willfully dangerous when it comes to file consistency. At the end of the day these filesystem stacks are always going to be different tools for different jobs.
You think there's any chance Microsoft ever expands their 9p support to allow users to mount arbitrary 9p filesystems?
I don't know anything directly about Microsoft's 9p plans, but the blogs give an impression they are considerably pleased at the 9p file server for what they've been using it for (especially these cross-platform communications) and they might use it for other things.
https://devblogs.microsoft.com/commandline/a-deep-dive-into-...
It would be pretty wild if Windows supported arbitrary 9p filesystems, but it is a kernel-level driver and they do seem interestingly confident in it.
> Ubuntu 20.04 vs. Windows 10 WSL/WSL2 Performance In 170+ Benchmarks
Virtualization is so efficient nowadays that it's much performant to go that route vs porting where often there will be difficult to debug performance regressions and bugs. So what WSL provides instead is much tighter integration between that linux VM and windows (including performant filesystem access, etc.).
Soon people will be forced to use it in particular contexts, let's say for the DRM Subsystem For Windows Subsystem For Linux. And since you need the DRM Subsystem For Windows Subsystem For Linux to run those few pieces of crucial software, WSL becomes your daily driver. Then MS starts shipping their own downstream distro with even more extensions that hook into Windows...
That’s what WSL is like
wsl --version
Well, this is Microsoft we're talking about. Think about Windows versions. Xbox versions. Or how to figure out where 64bit and 32bit goes on Windows [1]
It's in their DNA :)
[1] http://piers7.blogspot.com/2010/07/64-bit-explained.html
Why does that happen? It feels like the only reason WSL exists in the first place is to help sidestep the monumental bureaucracy in fortune 100 companies that see Linux as nothing more than a risk. Its a methodone for companies that want devops, but are too calcified and encumbered to really do much besides lip service.
E.g. try to find a sane and maintainable method for allowing non-root users to install Postgres. podman/Docker work for something like that, but what about VSCode? People can download a tarball, but I think the sandbox requires a setUID for some kind of security something.
You can give people sudo rules, but sudo whitelisting is prone to ways to escape from the command and open a shell.
WSL works because the company can control the hypervisor host strictly, and let the guest VM be more lax. The same would be true of a Linux VM inside a Linux host, but WSL lets the Windows people use Windows and the Linux people use Linux.
It's not an unsolvable issue, but I can see why companies are interested in having a single device management suite that allows end users to use Windows or Linux (ish).
The easiest way would be usermode package managers like Nix, Guix, or Homebrew.
> People can download a tarball, but I think the sandbox requires a setUID for some kind of security something.
I'm not sure what you mean, but you don't need root to use user namespaces (sandboxing) on any remotely recent Linux kernel.
> Most distros have a poor security model for allowing partially-trusted users. [...] You can give people sudo rules, but sudo whitelisting is prone to ways to escape from the command and open a shell.
The same product my employer just rolled out for managing this on Windows has a native Linux version. I assume it must have competitors.
> WSL lets the Windows people use Windows and the Linux people use Linux
No it does not. It lets the Windows people use Windows and the Linux people still have to use Windows, and a fucked up Linux VM that can't access their hardware, has to contend with Windows broken-ass networking stack, operates extemely slowly on files that are stored where the corporation wants people to store source code (i.e., on the Windows side), etc.
> WSL works because the company can control the hypervisor host strictly, and let the guest VM be more lax.
Why? Don't all of the material issues w/r/t endpoint management (data exfiltration, update management, anti-virus, idk) recur inside the VM anyway?
The insanity of the usermode packagers is that they're not popular enough to be easy to hire for (probably excepting Homebrew, though I've never seen it on Linux). I can grab a random resume from a stack and be almost positive that they know how to install and upgrade software with apt/yum.
I would bet the percentage of candidates who can compile Postgres and use outweigh the number that can install and use Postgres from Nix.
> I'm not sure what you mean, but you don't need root to use user namespaces (sandboxing) on any remotely recent Linux kernel.
Nah, it's not user namespaces, it's some kind of Electron sandboxing that it wants setuid root for (I have no idea why). https://stackoverflow.com/questions/66816019/how-to-run-star... has the error in question.
> The same product my employer just rolled out for managing this on Windows has a native Linux version. I assume it must have competitors.
I'd be curious how that works. I've seen things in the space that have tried via intercepting kernel syscalls (SELinux, AppArmor), but those seem like failed projects to me. I've never worked anywhere that has them turned on, though maybe that's sampling bias.
> No it does not. It lets the Windows people use Windows and the Linux people still have to use Windows, and a fucked up Linux VM that can't access their hardware, has to contend with Windows broken-ass networking stack, operates extemely slowly on files that are stored where the corporation wants people to store source code (i.e., on the Windows side), etc.
I'm not saying it's perfect, but I'll take it over being forced to use Windows or Mac natively. At least it's familiar, even if it is slow.
> Why? Don't all of the material issues w/r/t endpoint management (data exfiltration, update management, anti-virus, idk) recur inside the VM anyway?
Some do, some don't. You can prevent people from plugging in a 4G dongle to exfil data. You can force VM traffic to go through the host networking stack so it gets scanned by endpoint protection. For a lot of compliance stuff, it's enough that the software works on the physical host even if it can't do anything with the VM. E.g. compliance might say that all hosts have to run anti-virus, but the physical machine is the "host" so it's okay if the guest VM doesn't run anti-virus. Same with software auditing; it's enough for the procurement people that it runs on the Windows host.
Most of the pragmatic issues recur inside the VM, but a lot of organizationally imposed ones go away. I'm not saying it's logical, but I've yet to win an argument with compliance.
True and very unfortunate. Hopefully this changes as (tools like) Nix and Guix continue to grow and develop! They're really well-suited to this.
> I would bet the percentage of candidates who can compile Postgres and use outweigh the number that can install and use Postgres from Nix.
I think installing and using Postgres from Nix is definitely easier, although sure, fewer devs might already know that they can easily do it.
> I'm not saying it's perfect, but I'll take it over being forced to use Windows or Mac natively. At least it's familiar, even if it is slow.
Yeah, I think we're agreed. I'm just feeling especially frustrated with the setup lately.
> Most of the pragmatic issues recur inside the VM, but a lot of organizationally imposed ones go away. I'm not saying it's logical, but I've yet to win an argument with compliance.
That's true. I hope it stays that way.
At a guess, you've been in that scenario, and it may well have been handled badly ( and i'll grant you it often is ), but you might also have taken it just a little bit personally?
It's not my current job, but I've been doing various forms of sysadmin for a long, long time.
Biggest security/outage risk in most companies I've work at?
Me. My teams.
Even after we've spent years and millions of dollars addressing those risks.
But it's not about trusting your devs, even if somehow, you think you can trust all of them, and all your future hires, every day, forever (!?!?!)
It's whether or not you trust all the software on their machine, everyday, forever. Which is just as ridiculous a statement.
Isolated dev environments aren't that hard to setup if you really need HW access.
Do it right and you might even end up with something better than local.
And no, I don't have admin on my current work laptop either.
Yes, it's occasionally annoying, and we have tighter controls than that, i cant do a bunch of things that most envs would allow without thought - and I occasionally set of alarms that trigger the security folks to have a word, which is also occasionally annoying.
Reassuring too tho.
And actually, slightly disappointed that's it's generally just a phonecall, and polite conversation, rather than black masked ninjas rappelling down from the ceiling yelling at me to step away from the keyboard, but you can't have everything I guess.
Some companies have compliance/insurance concerns that require things to be set up a certain way, and to prevent users from undoing them. E.g. full disk encryption might be required, and users prevented from undoing that. Maybe there's some kind of audit agent that needs to run, and you don't want users removing it.
Others don't want engineers breaking their desktops, or setting things up in a way where it's going to break the automation. E.g. systemd-networkd is centrally managed, but some user hates it so they're using network-manager instead, and now they can't connect to the network because network port control got turned on. Amortize that across several thousand engineers and you can waste a lot of man-hours because people aren't using the tools they're supposed to.
I like having full root/admin permissions, but I don't really need or want 95% of the permissions it gives me. Linux makes it hard to delegate the 5% I actually want/need without giving me the other 95% that are basically only ever going to be problematic.
I.e. https://www.manageengine.com/mobile-device-management/what-i... lists ChromeOS, but not "Linux" systems, while ManageEngine of the leading products as far as I know.