Announcement

Collapse
No announcement yet.

Microsoft Confirms WSL To Co-Exist With WSL2, Other Windows Subsystem for Linux Details

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by SystemCrasher View Post
    Any estimate when MS would replace NT kernels with Linux? Would be next logical thing to do after dropping IE... . Though I'm pretty sure MS could turn even Linux into backdoored, vendorlocked something.
    Really WSL 1 they tried that vendorlocked path. WSL2 they are having to use a GPLv2 Linux kernel and have to document all there kernel level modifications.

    I am kind of waiting to see if virtualbox or vmware fork WSL2. Remember both refuse to work with Linux kernel KVM so working with hyper-v is unlikely even if MS provides API/ABI.

    Next I don't think its going to be exactly MS replace NT kernels with Linux. Lets look at Valve for a moment as soon as WSL2 can run graphical programs and sound I could see Valve and other old game distributors in there with bells on to run legacy Windows program inside wine inside WSL2.

    Yes we could wake up to a stupid day where more Windows games run inside WSL2 and Linux than what in fact run on Windows NT kernel.

    Leave a comment:


  • SystemCrasher
    replied
    Any estimate when MS would replace NT kernels with Linux? Would be next logical thing to do after dropping IE... . Though I'm pretty sure MS could turn even Linux into backdoored, vendorlocked something.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by thunderbird32 View Post

    Which means I'll have to stick with the original WSL, as long as it's available. Pity.
    why you need WSL if you are using Vbox or VMWare?

    Leave a comment:


  • c117152
    replied
    It's very surprising to see Microsoft taking a hint from Google's playbook and allowing two competing projects using different technical approaches for the same job to co-exist.

    Nothing negative to say for once. Good for them.

    Leave a comment:


  • thunderbird32
    replied
    Due to the Hyper-V usage of WSL2, WSL2 will not work when VirtualBox or VMware software is active
    Which means I'll have to stick with the original WSL, as long as it's available. Pity.

    Leave a comment:


  • oiaohm
    replied
    I lived it as well. Really worse I had to work with them. Reality is Interix/Windows Services for Unix has the same file system issues as WSL 1. Yes 1996 Interix and WSL 1 when building from source has basically all the same problems. These problems never went away. This is why 10 years ago I was messing around with colinux attempt to get myself out of pure hell.


    Originally posted by kpedersen View Post
    And as a bonus (to show how FreeBSD friendly Microsoft Research used to be):
    I hope you were being sarcastic.

    The Shared Source CLI use the non-free Microsoft Shared Source Common Language Infrastructure license. This license allows modifications and redistribution of the code for personal or academic usages, but they can't be used for commercial products
    FreeBSD is classed as a commercial product if you look up the legal defines of that. So stacks of stuff freebsd and Linux could not use. This license makes CDDL that ZFS is under look good.

    Originally posted by kpedersen View Post
    Microsoft POSIX layers are not new. They are in fact standards that Microsoft has an active interest to adhere to.
    Total falsehood. Don't think these lies will fly for anyone who had to work with the stuff. https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem This is the only time it was true. IEEE Std 1003.1-1990. Once you get to Interix and Windows services for Unix its still only has conformance to IEEE Std 1003.1-1990. So where are your newer versions of Posix that right Microsoft served up broken.

    POSIX.2 Shell and Utilities (IEEE Std 1003.2-1992) not once does Interix or Windows services for Unix pass this.
    Yes there are quite a few more Posix standards that the windows implementations never had.


    Yes most Linux distributions are way higher on Posix conformance than windows was once you cross 1993.

    Originally posted by kpedersen View Post
    The fact that Linux is currently more trendy than UNIX is simply a means to an end, which is POSIX compatibility. Nothing more (and just a little bit less .
    Linux is a little more than Trendy. Microsoft this time has to make it work right. Not say hey you can just rebuild that program with custom code so it works on our non conforming bit of crud.

    This should make it more than clean why 10 years ago I was looking at colinux.org and praying it would get somewhere because everything Microsoft was offering back then was total junk. It was simpler back then to rewrite the program in win32 than deal with the mega nightmares Windows Services for Unix would throw up and I suspect this was intentional.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by WLBI View Post
    Don't think so? Did you think about WSL 10 years ago?
    Think about it? No. I lived it!

    Check out these MS technologies:



    And as a bonus (to show how FreeBSD friendly Microsoft Research used to be):
    https://en.wikipedia.org/wiki/Shared...Infrastructure

    Microsoft POSIX layers are not new. They are in fact standards that Microsoft has an active interest to adhere to. The fact that Linux is currently more trendy than UNIX is simply a means to an end, which is POSIX compatibility. Nothing more (and just a little bit less .

    Leave a comment:


  • chithanh
    replied
    Maybe this will finally allow running 16-bit Windows applications on 64-bit Windows through Wine. Until now, this has been prevented by missing modify_ldt syscall. Although modify_ldt has security implications, so maybe Microsoft will not enable it.

    Leave a comment:


  • numacross
    replied
    Originally posted by DoMiNeLa10 View Post
    Running multiple QEMU machines at once doesn't prove anything. The problem is that a hypervisor takes control of the hardware that handles virtualization, and only one hypervisor can do so at a time. If you were to try running virtualbox while you have QEMU VMs running, you'd simply get an error message for the same reason WSL2 can't work while other hypervisors are running.
    That's not entirely true since hypervisors can expose the virtualization extensions to a guest, which then can itself start accelerated VMs. This feature is experimental in KVM, VMware supports it from Workstation version 8 and ESXi 5.0 and Hyper-V since Windows 2016.

    The limitation for WSL2 might be artificial to cut down on support cost, because nested virtualization has more strict requirements (usually requiring EPT and shaky support for AMD-v). Or they are reusing the micro VM used for security handling in Enterprise versions of Windows which kind of loses its point from the security perspective when the entire system is running in a hypervisor itself.

    Leave a comment:


  • roketscyntist
    replied
    This isn't great. Currently I'm using vagrant is WSL to test deployments and boxes in VirtualBox. The prospect of going pure Hyper-V for all my VMs isn't appealing.

    Leave a comment:

Working...
X