141–150 of 194 posts
Using WSL should be a very last resort anyway. Just use Linux straight on your hardware if you have a choice and ditch Windows.
Earlier quoted context omitted.
It’s a shit show. Can’t trace packets either via wireshark on the host and tcpdump doesn’t work on the guest. I’ve gone back to virtualbox and eviscerated WSL. Another total waste of my life.
Conceptually this makes sense. It doesn't really run Under windows, it runs beside windows. Unlike WSL1 which was basically part of Windows. It's strange tcpdump doesn't run though as WSL2 is running a real kernel. Personally I really liked the resource efficient WSL1 approach and I lament that they dropped it. But I know for some usecases (e.g. docker) a real Linux kernel was needed.
Using WSL should be a very last resort anyway. Just use Linux straight on your hardware if you have a choice and ditch Windows.
Why? In my opinion Linux desktop environments are terrible compared to Windows. How's the display scaling these days? Is it still a better experience to run a 4k monitor at a lower resolution? What's the Nvidia driver situation? Still janky because their drivers are doing their own thing?
Earlier quoted context omitted.
Yeah, I have a few things that keep me in Windows. The primary users of the apps I work on are all on Windows, so having a Windows box around tends to be useful to check everything is good. ArcGIS - Windows only, has enough issues as it is, virtualizing it doesn't tend to go well. Though you can do something like VMWare Fusion mostly successfully. MS Office - Yes there are alternatives, but we sill operate primarily…
If they can't work in Wine, you can always run the outliers in Windows VM on Linux, instead of doing the reverse :)
And anyway, just the way it lets me manage multiple instances of Linux is far superior to anything I experienced on Mac or Linux itself. By the current standards, Wine is just _painful_ to use. Meanwhile Windows window management and the terminal app have made great strides in last couple years.
This is the exact reason I didn't try running weird VPN configs like this. The reliable way is to run Linux inside a VirtualBox and have it connected to VPN on its own. Currently, I run Linux on a Xen domU and configure VPN client inside the guest. PS: I don't want all my traffic to go through VPN. Especially things like Netflix or Youtube where VPNs are blocked (and VPN BW is lower anyway).
WSL2 _is_ Linux inside a VM that's a peer of Windows. Having it connect to VPN on its own is _exactly_ what you have to do.
I used to run Linux VM inside HyperV before WSL2 released, and it worked like a charm. WSL2 just adds a lot of hacks to integrate Windows & Linux experience.
A bit off topic, but this sort of transparency is why I don't mind paying $6 / mo for a vpn when mullvad's competitors are much cheaper. Their wireguard support is great, and their speeds are much faster than what I got through openVpn on pia.
I love everything about Mullvad except their device limit, which is unfortunately a deal breaker for me. 5 is completely inadequate for my use cases.
The host OS image, dom0, also routes its network traffic through that VM, to get updates. (It doesn't trust the updates it gets that way; it checks their signatures.)
QubesOS provides another VM as a dedicated firewall just to route untrusted guests' traffic through, first. With enough cores, it all runs fast.
For many users, all guest VMs are untrusted. Dodgy programs like browsers get their own VMs, spun up as needed and discarded. That does take a fair bit of RAM; my maxed-out 16GB laptop notices the strain. But memory is cheap these days, if you have the sockets to put it in.
As an aside, dom0 also mediates access to the UI hardware, including display RAM. Each guest can run X, but its pixels are copied to the real display by dom0. Guest VMs can't see one another's pixels or input traffic. dom0 also mediates access to audio and video streams, and can route them to selected VMs as needed. (In a future release they plan to manage the display in its own VM, because display drivers are a big attack surface of their own.)
It all works astonishingly well.
Incidentally, this model of a hypervisor with all the user-level OSes as VMs, including the host, originated at IBM in the 1960s. That worked in a megabyte or two, which seemed like a lot at the time.
Earlier quoted context omitted.
If they can't work in Wine, you can always run the outliers in Windows VM on Linux, instead of doing the reverse :)
WSL2 is by far superior to running Windows in a VM, mostly because it's not "just" Linux in VM. And anyway, just the way it lets me manage multiple instances of Linux is far superior to anything I experienced on Mac or Linux itself. By the current standards, Wine is just _painful_ to use. Meanwhile Windows window management and the terminal app have made great strides in last couple years.
So if you do need to run something that's Windows only but can work in Wine, I'd totally recommend running using Wine ditch Windows for good. For me it's a benefit, not a hindrance.
And you can run multiple VMs on Linux too if you need actual Windows still (KVM, virt-manager and etc. are quite handy).
Earlier quoted context omitted.
> windows firewall rules should not in any case be applied to traffic coming from a VM I can't agree with this. Everything is running on Windows. The VM runs on Windows and WSL exchanges data with Windows all the time. That the data on the Windows side can leak because I installed a Microsoft-approved product from the Microsoft store on a Windows box with a Microsoft firewall is unacceptable.
Here’s the issue with your issue: if you are using WSL2 (or other various win10 configurations involving hyper-v), then windows is not running on bare metal anymore. In this scenario, windows is just another guest operating system subject to a hypervisor. Windows is a VM, and your in-VM firewall applies to the VM in which its running. This is how you get real linux “on” windows - the on part is an illusion, trickery…
Earlier quoted context omitted.
But legit question, why would you want to play a game in Linux and not in Windows? I’m not even being rhetorical, I’m genuinely curious if there are games with significantly better performance under Linux (and I’m assuming we would have to be talking about using an AMD card so I’m also curious if that performance under Linux is better than an Nvidia card under either OS), because maybe there are and I’m just totally…
Because Linux is my OS of preference in general, so I play games on it as well. But it's good to clarify a few things to avoid confusion: 1. You can use Nvidia on Linux, including for gaming. Nvidia's problems are related to lack of support for modern features (Wayland use cases and so on) caused by the fact that their blob driver in not upstreamed. But it's usable otherwise. 2. AMD drivers are open source and upstre…
And again, I understand Linux is your chosen OS — I’m happy you’re so happy. My question was why a person who is using WSL2 would want to run a game in Linux instead of inside Windows. I understand you can game in Linux. That’s not the question. The question is why would a person run a game inside Linux, which is running side-by-side Windows, run the game in that subsystem instead of just using Linux.
I didn’t know if there was a place where a game would get better performance in Linux, making that a better target.
I just don’t understand the criticism of doing something inside a subsystem that could be done just as well/better outside the subsystem. If you don’t want to use WSL2 or Windows or macOS or anything else, that’s fine. But for people who DO choose to use it, I don’t understand why “games inside Linux are slower inside of it” makes much sense.