151–160 of 420 posts
Earlier quoted context omitted.
They mean MS replacing the Windows kernel with Linux kernel. Which doesn't sound as crazy as it did just a couple of years ago. Just put all the Windows crap in a VM, similar to WSL2.
"Just put all the Windows crap in a VM" - if Windows such a crap why even mention it? Just put Linux on your PC and be happy.
Earlier quoted context omitted.
Well, if you want to use multimedia and do web development on the same machine, what are you going to do? Linux support is somewhere between nonexistent and utterly broken for the first one and the same can be said for the second on Windows. So your choices are, 1. run Linux primary, put Windows in a VM 2. run Windows primary and put Linux in a VM 3. Give up and just run a separate Linux server.
Or use macOS ;)
Earlier quoted context omitted.
> Presumably, this also means you have to have Hyper-V enabled, crippling all other VM software How does hyper-V cripple other VM software? I just had to enable it to use a prebuilt VM I need, now I’m a little worried
Last time I checked (months ago) VirtualBox just couldn't run under Hyper-V. If you Google around you'll see lots of threads, e.g. https://superuser.com/q/1208850 Apparently they claim that as of February 19, 2020, they've "Restored the ability to run VMs through Hyper-V, at the expense of performance". https://www.virtualbox.org/wiki/Changelog-6.1
Earlier quoted context omitted.
Thanks. This information is important to me. I abbandoned WSL2 because it couldn't work along VMWare but the tide seems to have changed.
Ever since Docker became a popular tech, VMware has had little choice: I need docker for my job, so I can't use VMware. That doesn't get them the dollars they want.
On a Win10 host, I want to edit code in sublime and have the runtime environment in linux. I want fast code search and fast build times. I've found no way to accomplish the above. Code in Windows + Windows Sublime means build in WSL will be slow because cross-os i/o Code in Linux + Windows Sublime means code search will be slow because cross-os i/o Code in Linux + Linux Sublime + Winodws Xserver means interface is la…
What Electron-related problems have you had with VSCode? I've been using it as my primary for a few years now and it's been nothing but stellar. And that integration sounds incredibly cool.
Given your comments, I just installed it right now to try it out again. I like the built in terminal & git integration. Code search performance is excellent (w/ code hosted in WSL) due to this new client/server model... and there was no input lag in the editing window.
The only lag I noticed was in CTRL-P selector, but that's a small compromise given the client/server model solves the real time waster.
I think I'm going to try it out over the next few weeks :)
Earlier quoted context omitted.
It needs a VHD, which requires setting aside a partition of your disk, meaning you can't dynamically share space with your Windows files. That's a huge downside for me. (By "partition" here I'm just referring to the English sense, not the MBR/GPT per se.) You also can't nor search/modify your Linux files directly from Windows like I mentioned. The 9P server with WSL1 has been so slow as to be unusable for some direct…
It's a resizable VHD that handles its business in the background, so I don't understand the complaint. And you can access your Linux files in Windows just fine when using WSL2. Just go to `\\wsl$`. WSL2 is the first thing to legit make me reconsider my daily-driver Fedora setup in...well, since I started using it in ~2016. I just do not think about it, it's great.
And yes the \\wsl$ is the 9P server I just tried to explain is incredibly slow compared to normal files on WSL1. I haven't tried WSL2 yet but I don't expect going through a VM would be faster.
Earlier quoted context omitted.
WSL was very cool from a pure tech standpoint, but I've never been clear what the actual use case for it was. WSL2 seems to be more along the lines of coLinux, which I felt the same way about when it was new.
Well, if you want to use multimedia and do web development on the same machine, what are you going to do? Linux support is somewhere between nonexistent and utterly broken for the first one and the same can be said for the second on Windows. So your choices are, 1. run Linux primary, put Windows in a VM 2. run Windows primary and put Linux in a VM 3. Give up and just run a separate Linux server.
2006 was for me the turning point where Linux was only used via VMs or some remote box.
WSL2 is just fine, I don't need to mess with VMWare any longer.
And if I am not doing Linux deployments, I can do plain Windows development, like I have done since Windows 3.0.
For the Linux desktop experience I have a surviving ASUS netbook.
Earlier quoted context omitted.
Or use macOS ;)
I will the moment you give me a mac with a seven row keyboard and a trackpoint.
Most people choose their laptops based on the OS, not on the pointing device.
Earlier quoted context omitted.
WSL was very cool from a pure tech standpoint, but I've never been clear what the actual use case for it was. WSL2 seems to be more along the lines of coLinux, which I felt the same way about when it was new.
The usecase was Apple has Terminal.app, Windows has MS-DOS. Tell me which you would rather use for node and or docker development.
Earlier quoted context omitted.
It's a resizable VHD that handles its business in the background, so I don't understand the complaint. And you can access your Linux files in Windows just fine when using WSL2. Just go to `\\wsl$`. WSL2 is the first thing to legit make me reconsider my daily-driver Fedora setup in...well, since I started using it in ~2016. I just do not think about it, it's great.
It shrinks the VHD automatically?? And yes the \\wsl$ is the 9P server I just tried to explain is incredibly slow compared to normal files on WSL1. I haven't tried WSL2 yet but I don't expect going through a VM would be faster.
I never used WSL1 in anger, but accessing WSL2 over the \\wsl$ is not particularly slow. It's not as fast as native, but I don't notice it. I do almost all of my access of files on the Linux image via a terminal and VSCode-over-WSL-Remote, though.