5 ms·

Well that is pretty nice. WSL gets that much more exactly like Linux. What I really appreciate about WSL is that you get the accessibility of a bunch of OSS pr

Well that is pretty nice. WSL gets that much more exactly like Linux. What I really appreciate about WSL is that you get the accessibility of a bunch of OSS projects and a machine which has legit drivers for all of its component bits. What this means to me is that searching for a "linux laptop" won't be a chore, if it runs the latest Windows it will run Linux. And I can do development on the Linux side while communicating with senior management in power point on the Windows side :-). If they come up with a better/credible USB allocation scheme it will be icing on the cake. I also think they should buy one of the X server vendors and bundle it (comments about X.org from Redhat not withstanding) I use Xwin32 on my laptop with WSL and its pretty seamless in terms of things that want to pop up a GUI.

scardine 7y ago
There are a few annoyances with WSL2. For me the most important are: 1. You can't connect to a port listening on WSL localhost like in WSL1, you have to figure out the WSL IP address and use that. 2. From WSL you can't connect to a Windows TCP port on localhost, you must figure out the Windows IP (cat /etc/resolv.conf) and use that. 3. The WSL remote interpreter on PyCharm is not working anymore. The suggested workaround is "use SSH remote interpreter" but given #1 you can't connect to localhost (and the WSL IP changes every time you restart it) In order to use the SSH remote interpreter in my favorite IDE I'm using this script (on Windows): import subprocess import re output = subprocess.check_output('wsl.exe ifconfig') match = re.search(r"\sinet\s+(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s", output.decode('utf-8')) if match: ip = match.group(1) with open(r"C:\Windows\System32\drivers\etc\hosts") as i: content = i.read() new_content = re.sub(r"(172.\d+\.\d+\.\d+)\s+wsl", f"{ip} wsl", content, re.M) if new_content != content: try: with open(r"C:\Windows\System32\drivers\etc\hosts", "w") as o: o.write(new_content) except PermissionError: print(new_content) First I use the Windows Scheduler to start SSH (wsl service start ssh) on logon. Then this script is executed on logon with elevated privileges to update the hosts file. Instead of "localhost", I use "wsl" and it works well enough for me while I wait for the fixes. Despite the above, the combo Windows 10 + WSL2 is the best "Linux Desktop" for me.
- dehrmann 7y ago
  > you must figure out the Windows IP The existence of c:\Windows\System32\drivers\etc\hosts cracks me up. Supposedly [citation needed] Windows uses/used part of the BSD network stack.
  - deaddodo 7y ago
    It (like most every OS) used the BSD TCP/IP stack because it worked and didn’t have license encumberances. They switched to their own stack in Vista though.
  - nolok 7y ago
    Ahhh, the eternel dilemna they face. Either recreate the wheel and get complaints about that, or re-use the wheel and have people "crack up" about you doing that.
    - dehrmann 7y ago
      What cracks me up is the irony of seeing ...\etc\hosts on Windows, not the entire decision.
      - nolok 7y ago
        Then I don't understand your comment. What's the irony in there ? Or do you mean humor instead of irony / is it not irony at all ?
        toyg 7y ago
        The irony is that “etc” makes no sense whatsoever in Windows, and particularly in that place. It probably came about because it was easier to have it there than to patch whatever bit of code they borrowed, and it’s now likely vestigial, but probably there is too much stuff relying on it to change things. The irony is in an OS trying extremely hard to not be a unix, ending up with unixy folder names because laziness.
- 7y ago
jayd16 7y ago
So how do the drivers work? Is Microsoft implementing and integrating cross platform drivers? Have they somehow made Linux a microkernel that uses windows drivers through a shim?
deleted 7y ago
[deleted]
h1d 7y ago
That was possible for quite some years if you'd just used any VM solution locally and just SSH into it. At least VMware has decent file system performance when VirtualBox doesn't.
nickpsecurity 7y ago
I always thought someone could try one of these driver-reuse techs with Windows drivers. I recently posted two examples elsewhere: https://www.usenix.org/legacy/events/osdi04/tech/full_papers/levasseur/levasseur.pdf https://www.usenix.org/legacy/events/osdi04/tech/full_papers... https://os.inf.tu-dresden.de/Studium/KMB/WS2012/06-Drivers.pdf https://os.inf.tu-dresden.de/Studium/KMB/WS2012/06-Drivers.p... Well, a mix of Windows and Linux drivers where we use Linux whenever it works well enough. Windows when it doesn't. Might also be able to tie that in Windows Embedded to trim as much fat out of the driver VM as possible.
nickpsecurity 7y ago
So, you buy Windows to get better hardware compatibility for your Linux system on top of whatever Windows ecosystem brings you. I did something like that with non-Windows VM's. Although I couldn't find the link, there was an academic prototype you might have liked that used virtualization to reuse Windows drivers in other OS's or VM's. Seems like there could be a market for that where it's combined with recent enhancements in efficiency targeted toward people like you that want more compatibility. What do you think?
- ChuckMcM 7y ago
  In general I think it is an interesting idea. There has always been an economic issue with hardware manufacturers who were unwilling to expose too much information in an open source driver, and security issues of running a binary blob at ring level 0 in the kernel. Microsoft puts itself in the middle of that by certifying a driver through a vendor sign up / certification process, and since it doesn't require the vendor to release source, the vendor can keep that information secret. As a result you have more drivers for more hardware created under the "Made for Windows" driver development plan than you do from enthusiastic reverse engineering efforts in the Linux camp. To the extent that you can capture the value of Microsoft's oversight without having to pay the 'tax' of a Microsoft OS, you add value for the end users.
  - nickpsecurity 7y ago
    There's another potential advantage. Thanks to SLAM, the Windows drivers have some strong verification against that interface. If one implements it well, then they get both benefits of Windows hardware in general and extra robustness of their driver verification. As in, drivers might be better than Linux drivers without such interface verification. The drawback being whatever in middle interfaces the Windows interface to the non-Windows VM's might introduce bugs. It must be correct and compatible.

scardine 7y ago

There are a few annoyances with WSL2. For me the most important are: 1. You can't connect to a port listening on WSL localhost like in WSL1, you have to figure out the WSL IP address and use that. 2. From WSL you can't connect to a Windows TCP port on localhost, you must figure out the Windows IP (cat /etc/resolv.conf) and use that. 3. The WSL remote interpreter on PyCharm is not working anymore. The suggested workaround is "use SSH remote interpreter" but given #1 you can't connect to localhost (and the WSL IP changes every time you restart it) In order to use the SSH remote interpreter in my favorite IDE I'm using this script (on Windows): import subprocess import re output = subprocess.check_output('wsl.exe ifconfig') match = re.search(r"\sinet\s+(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s", output.decode('utf-8')) if match: ip = match.group(1) with open(r"C:\Windows\System32\drivers\etc\hosts") as i: content = i.read() new_content = re.sub(r"(172.\d+\.\d+\.\d+)\s+wsl", f"{ip} wsl", content, re.M) if new_content != content: try: with open(r"C:\Windows\System32\drivers\etc\hosts", "w") as o: o.write(new_content) except PermissionError: print(new_content) First I use the Windows Scheduler to start SSH (wsl service start ssh) on logon. Then this script is executed on logon with elevated privileges to update the hosts file. Instead of "localhost", I use "wsl" and it works well enough for me while I wait for the fixes. Despite the above, the combo Windows 10 + WSL2 is the best "Linux Desktop" for me.

dehrmann 7y ago
> you must figure out the Windows IP The existence of c:\Windows\System32\drivers\etc\hosts cracks me up. Supposedly [citation needed] Windows uses/used part of the BSD network stack.
- deaddodo 7y ago
  It (like most every OS) used the BSD TCP/IP stack because it worked and didn’t have license encumberances. They switched to their own stack in Vista though.
- nolok 7y ago
  Ahhh, the eternel dilemna they face. Either recreate the wheel and get complaints about that, or re-use the wheel and have people "crack up" about you doing that.
  - dehrmann 7y ago
    What cracks me up is the irony of seeing ...\etc\hosts on Windows, not the entire decision.
    - nolok 7y ago
      Then I don't understand your comment. What's the irony in there ? Or do you mean humor instead of irony / is it not irony at all ?
      - toyg 7y ago
        The irony is that “etc” makes no sense whatsoever in Windows, and particularly in that place. It probably came about because it was easier to have it there than to patch whatever bit of code they borrowed, and it’s now likely vestigial, but probably there is too much stuff relying on it to change things. The irony is in an OS trying extremely hard to not be a unix, ending up with unixy folder names because laziness.
7y ago

jayd16 7y ago

So how do the drivers work? Is Microsoft implementing and integrating cross platform drivers? Have they somehow made Linux a microkernel that uses windows drivers through a shim?

deleted 7y ago

[deleted]

h1d 7y ago

That was possible for quite some years if you'd just used any VM solution locally and just SSH into it. At least VMware has decent file system performance when VirtualBox doesn't.

nickpsecurity 7y ago

I always thought someone could try one of these driver-reuse techs with Windows drivers. I recently posted two examples elsewhere: https://www.usenix.org/legacy/events/osdi04/tech/full_papers/levasseur/levasseur.pdf https://www.usenix.org/legacy/events/osdi04/tech/full_papers... https://os.inf.tu-dresden.de/Studium/KMB/WS2012/06-Drivers.pdf https://os.inf.tu-dresden.de/Studium/KMB/WS2012/06-Drivers.p... Well, a mix of Windows and Linux drivers where we use Linux whenever it works well enough. Windows when it doesn't. Might also be able to tie that in Windows Embedded to trim as much fat out of the driver VM as possible.

nickpsecurity 7y ago

So, you buy Windows to get better hardware compatibility for your Linux system on top of whatever Windows ecosystem brings you. I did something like that with non-Windows VM's. Although I couldn't find the link, there was an academic prototype you might have liked that used virtualization to reuse Windows drivers in other OS's or VM's. Seems like there could be a market for that where it's combined with recent enhancements in efficiency targeted toward people like you that want more compatibility. What do you think?

ChuckMcM 7y ago
In general I think it is an interesting idea. There has always been an economic issue with hardware manufacturers who were unwilling to expose too much information in an open source driver, and security issues of running a binary blob at ring level 0 in the kernel. Microsoft puts itself in the middle of that by certifying a driver through a vendor sign up / certification process, and since it doesn't require the vendor to release source, the vendor can keep that information secret. As a result you have more drivers for more hardware created under the "Made for Windows" driver development plan than you do from enthusiastic reverse engineering efforts in the Linux camp. To the extent that you can capture the value of Microsoft's oversight without having to pay the 'tax' of a Microsoft OS, you add value for the end users.
- nickpsecurity 7y ago
  There's another potential advantage. Thanks to SLAM, the Windows drivers have some strong verification against that interface. If one implements it well, then they get both benefits of Windows hardware in general and extra robustness of their driver verification. As in, drivers might be better than Linux drivers without such interface verification. The drawback being whatever in middle interfaces the Windows interface to the non-Windows VM's might introduce bugs. It must be correct and compatible.