Earlier quoted context omitted.
> Right now I’m using a full VM. WSL2 is also a full VM
Is that so? Isn't it more like a bridge between Linux and Windows kernels, so that stuff is ultimately delegated to Windows?
WSL 1 was. WSL2 is a VM.
Windows Subsystem for Linux GUI
211–220 of 473 posts
Re: Windows Subsystem for Linux GUI
#212Earlier quoted context omitted.
> Right now I’m using a full VM. WSL2 is also a full VM
Is that so? Isn't it more like a bridge between Linux and Windows kernels, so that stuff is ultimately delegated to Windows?
A bridge between kernels is how most VMs work these days. The kernel inside the VM has special drivers for extra-simple 'hardware' that the host OS provides.
As opposed to WSL1 where there's a wine-esque module in the windows kernel, and there is no linux kernel at all.
Re: Windows Subsystem for Linux GUI
#213[deleted]
Re: Windows Subsystem for Linux GUI
#214Earlier quoted context omitted.
> Right now I’m using a full VM. WSL2 is also a full VM
Is that so? Isn't it more like a bridge between Linux and Windows kernels, so that stuff is ultimately delegated to Windows?
WSL1 was done that way (though with a compatibility shim not a real linux kernel), but it had a number of shortcomings, primarily that I noticed in file io performance, but also in compatibility as they had to map all the syscalls themselves.
https://docs.microsoft.com/en-us/windows/wsl/compare-version...
Re: Windows Subsystem for Linux GUI
#215Earlier quoted context omitted.
How much of that effect do you think is due to recent Windows versions not playing nicely so you still get some hassle anyway and/or to improving options to run Windows virtually on a Linux host with close to native performance and compatibility?
What do you mean by "not playing nicely". With UEFI boot you can dual boot all day. There is no need to modify MBR. So nothing gets overwritten on updates.
I didn't say dual booting was itself the source of the danger (though it is true that in days gone by that was also a source of problems).
The issue I had in mind was the unrestricted hardware access that Windows has if it is running natively. This is an operating system that has literally pushed updates that inadvertently deleted user data, among other severe problems, and that will deploy its updates automatically to many users. Dual booting won't ensure the integrity of your system against that kind of threat. Running Windows in a virtual environment means it can't damage the rest of your system even if it deploys a seriously broken update without warning. And that kind of virtualisation is getting more practical all the time even if for now it remains the preserve of serious Linux hackers.
Re: Windows Subsystem for Linux GUI
#216Earlier quoted context omitted.
> Right now I’m using a full VM. WSL2 is also a full VM
Is that so? Isn't it more like a bridge between Linux and Windows kernels, so that stuff is ultimately delegated to Windows?
It is, just with some fancy integrations that makes it more comfortable - for example memory reclamation. But it's all a fancy VM in the end.
Re: Windows Subsystem for Linux GUI
#217Re: Windows Subsystem for Linux GUI
#218Earlier quoted context omitted.
Perhaps it needn't be; I, with my negligible OS dev experience, just like microkernel architectures better. It seems more sensible to have microkernels managed by a microkernel loader. This might be an opinion I come to recant in time. The core of my position is that Microsoft needs to stop doing Microsoft things if they want to be taken seriously as a good faith actor, but I'm not holding my breath. Until they make…
Providing POSIX and Linux-specific APIs does actually place them into Linux ecosystem. Programs bult for Linux suddenly can be run for Windows users. That's a boost in adoption potential for Linux programs (large part of the ecosystem). And adoption is very impotant for further development and success of software. On the other hand, for Linux users this makes Windows more attractive - why not choose Windows for your…
Yeah, that's what gets me: it's obviously engineered to drive traffic one way without giving anything back to the community. I'm sorry, but I'm not interested in APIs to interact with a black box. Until Microsoft makes Windows user-controllable, I will never treat it with respect.
I do see your point, however, and I hadn't thought it of that way; do you see anywhere the community might pick up on this for some benefit?
Re: Windows Subsystem for Linux GUI
#219Earlier quoted context omitted.
Linux and Windows use mutually exclusive permission/ACL bits, even on the same NTFS filesystem.
> even on the same NTFS filesystem can you explain a bit how this works?
I think they use extended attributes in NTFS to provide the Linux file system permission.
https://docs.microsoft.com/en-us/windows/wsl/file-permission...
Re: Windows Subsystem for Linux GUI
#220Earlier quoted context omitted.
Are you talking about WSL1 or WSL? Wsl2 is much much faster due to having a virtualized real linux kernel running
WSL2 disk access from the Windows side is very slow. It's the reciprocal problem of WSL1. WSL2 Linux apps now get proper performance now but if your IDE is on the Windows side, access time to project files on native Linux partition is terrible.
...actually e.g. VS Code has a really great split backend, so you can actually have the frontend "properly" on Windows anyway, and yet still use WSL2.
My own case was something different: annoyingly configured automated browser tests with Cypress. Just running them inside WSL and letting that start a browser on the distro itself was the most comfortable way to debug these.