WSL 2 is a lot like that -- it's a VM in the sense that it uses Hyper-V, but it's super lightweight. And in fact, when WSL 2 is enabled, both Windows AND Linux are running in the same type of VM (separate, obviously), so it's near-native performance in a lot of ways. There are still some I/O issues that the team is actively working on, but early benchmarks are quite promising.
=/
Hoping to run my R code on WSL 2. Glad I got the answer. I wish you guys well on I/O issues.
Is there any performance hit for WSL2 in regard to process forking? I recall that how window and unix deal with process is different (my R code uses mclapply parallel package for unix). I'm curious if there will be any performance hit that stands out versus running on a unix system for parallel/concurrency code.
I can't find that exact thread right now, but here's another one comparing WSL with Windows:
https://www.reddit.com/r/bashonubuntuonwindows/comments/c1r6...
I may disagree with a comment, but that doesn't remotely generate in me an opinion re where it should sit in the tree. I don't think other people should or are likely to find a comment agreeable/interesting/relevant/insightful just because I do. Different strokes I guess.
I see it as a community service.
I havent been on the PC for several weeks, so I don't have a link to my feedback. I'll post next time I'm on.
does this mean there will be issues using VirtualBox if WSL 2 is enabled?
I personally have to reboot when I need to use docker or virtualbox. Very annoying.
[1]: https://twitter.com/tara_msft/status/1125888319974400000?s=2...
Is there a way to suspend windows? From what you say, there is nothing technical preventing this.
You can learn more about the architecture of WSL2 in this video from Build https://youtu.be/lwhMThePdIo
Many of my colleagues use macOS, some use Windows, some Linux. I have a work-issued Mac and a work-issued Surface Book, because it’s important to test compatibility, especially when it comes to CLI stuff, across different platforms. I have Linux VMs and docker containers and WSL configured too.
It's a shame and makes me sad for modern computing.
Not sure if this will mean new architectures, operating systems & better tools.. but one can dream!
Also, nobody ever saw a fireman by hiding inside with their window blinds shut. Take a peek outside, what you see might bring you hope.
I don't have the website anymore, but the basic idea is detailed here: https://grack.com/blog/2011/03/07/abusing-the-html5-history-...
All things have their downsides. There are no perfect things that are nothing but goodness and light.
As they say: Sunshine all the time makes a desert.
1- We have 4/5 mainstream OSes today: Win/OSX/iOS/Android + Linux. In the case of iOS/android: Some users alread switch between the 2.
2- If it have apps is almost all people need. Drivers are not THAT significant IMHO.
3- Chromebook is a thing, despite it sound stupid: A OS that is just a browser.
Web is the 6 truly mainstream "OS".
4- What people need on drivers? USB (and with usb-c), hdmi, bluetooth (maybe?) + wifi. With this alone and you get even better than iPad: Monitors, wireless mouse, keyboards, external storage, and by extension you catch the rest.
5- Printers? By proxy of iOS it can work full wireless with no drivers on device.
So I think a true desktop OS could launch with less worry about legacy hardware.
Where IS the problem is the apps. It need to be better than chromebook, have very great first party apps that cover basics and hopefully, a VM layer so you could run linux and catch the rest.
Do you honestly think there is a single USB-C driver that covers literally everything that can connect over USB? And anything with an HDMI port uses the same driver!?
I think that nail the software (app + dev experience) is a bigger challenge and priority than worry about the (external) hardware.
P.D: One thin I forget to articulate is the possibility to leverage linux as a bridge for drivers (possible)? so the new OS ship a smallish linux just for get compatibility.
> I think that nail the software (app + dev experience) is a bigger challenge and priority than worry about the (external) hardware.
You are ludicrously wrong. Using the Linux kernel as an example, because drivers are in-tree, as of 4.19 (late 2018): https://raw.githubusercontent.com/udoprog/kernelstats/master...
As you can see, drivers are the vast majority of the kernel. And Linux's hardware support is often called out as a reason people use Windows or MacOS!
It’s sad that commercial realities are pushing people to throw away 30 years of progress on desktop UIs, but here we are.
It's not really "just a browser" these days. Runs Android apps, and regular old GNU/Linux desktop apps.
+ FreeBSD
+ OpenBSD
+ NetBSD
+ DragonFlyBSD
+ Minix
+ Haiku
+ Redox
+ Plan 9
+ SeL4
+ Fuchsia
View the kernel API like HTML. Browser diversity is good, but they need to be implementing the same interface if the smaller players want to support any hardware that works with Linux
Edit:
Here is the link to the Microsoft provided VMs:
https://developer.microsoft.com/en-us/windows/downloads/virt...
Given Microsoft's zeal for legacy support I'd say there's a snowball's chance in hell for this, but a man can dream.
The first version of WSL is just another process in task manager, with all the syscalls and filesystems emulated.
(I also want to just be about to plug in my HDMI to my laptop and have it work. Literally the only two things I care about)
I've never used crossover. Thanks, I'll look into it.
There has to be something with Cuda that messes everything up on laptops.
As such, the 'native' docker for windows you linked is actually managing a Linux VM (HyperV or VBox) fot you; the docker server runs on that VM, and the native docker windows binary simply connects to that server.
They also do a lot of tricks to connect networking and file shares with that VM. The file shares part is almost completely non-working in my experience, with scary comments in the bugs like 'doesn't work if your windows password contains certain characters' (it sets up CIFS shares between the Linux VM and some parts of your Windows file system).
So, not sure what docker for Mac looks like, but Docker For Windows is only 'native' in a very hand-wavy sort of way, unless (maybe) if you're running Windows docker containers.
However, we use VMs managed with Salt for our Centos VMs. I never saw the need for Docker. Maybe if I did "web" stuff.
[1] https://engineering.docker.com/2019/06/docker-hearts-wsl-2/
This is what happens in the case of WSL 2; both Linux and Windows (the host OS) run in very (very) lightweight VMs.
There seems to be an assumption that Linux is the ultimate in OSes. But most of the value comes from the large ecosystem and momentum, rather than specific technical advantages.
The value of Linux (to many) rests on its FOSS value system.
This gloomy world of palpable beige-yellow-purple is the world of Microsoft Windows. As a product, it caters exclusively to that clientele, in that environment. To be blunt, above all other design considerations, Windows was built to accommodate the lackluster office drone -- or, more precisely, their bean-counting overlords who wanted to save on user workstations.
Despite attempts to undo this, the design has proven impossible to build upon. How many legitimate improvements in the cutting edge of either academic or industrial compsci have been built on Windows technology, for any reason other than "MS signs my paycheck so I'm contriving this to appear like I'm happy to be using PowerShell"?
MS was able to paper over the deficiencies for a while through sheer force (pushing .NET as a semi-unified computing environment, Ballmer screaming "DEVELOPERS!", etc.), but Windows was in no way prepared for the revolution brought by virtualization in the mid-aughts, and any shred of a hope that MS would somehow recover was utterly and entirely obliterated by the widespread proliferation of containerization. Good luck getting a real version of that working on Windows.
I've said it before and I'll say it again: in about 5 years, I wouldn't be surprised at all to see the new version of "Windows" plumbed end-to-end atop a nix-like kernel, and driven by a hybrid userland comprised of a spit-polished copy-paste from WINE + a grab bag of snippets from the proprietary MS-internal Win32.
The flexibility of the nix model is the indisputable, indomnitable winner here, and it stunned and killed the Goliath in its tracks. This is the ultimate surrender to the open-source model. Windows's top-down, "report to your cube by 8:26am sharp and don't question the men in the fancy suits" approach to computing resulted in a rigid operating system that was unable to keep pace with the technological demands of the many pantheons of loyal corporate drones that comprised their user base. Even strictly-Microsoft shops are forced to give developers MacBooks now, or they're unable to get anyone competent to sign on.
It really couldn't get more poetic than MS desperately integrating Linux into their OS so that people won't switch to the more flexible nix-like systems for their workstations, although I anxiously await MS accidentally linking in a GPL module and thus becoming required to disclose the Windows source code. :)
Meanwhile, per usual, nix-like OSes have been humming for 50-ish years now and show no signs of slowing down. IMO, that's all the objective, borne-out proof one needs to say that for all practical purposes, Windows couldn't stand the test of time.
Please note that this is not about Linux per se, but the overarching design theory and development processes in use in major operating systems, and the massive success it represents for open-source, research-driven systems.
The chapter on "The Windows Way" has been written, and whatever its benefits may be in theory, they don't bear out as sustainable in practice.
It'd be fun to do a macro-scale timeline comparison to Sun. These invincible tech behemoths that cater to their narrow niche become rotting, hollowed-out fossils as the free systems continue to develop and evolve the cutting edge. Microsoft is right on time here, and I fully expect to see them struggle through the next decade or so until Larry Ellison finally puts them out of their misery.
No one can fight against free beer, regardless how bad it might taste, people still go for it.
For some balance, you could consider how Windows got preinstalled on most computers since the 90s and what huge dominance it had in the consumer and also development domains (also thanks to some evil capitalist practices, some might say!). That there are free versions of Visual Studio and other IDEs and dev tooling for various programming languages for Windows just as well. Also, consider that I can buy Windows 10 Professional for $8.90 with 5 seconds of googling.
Maybe Coherent would have survived with such willingness.
Windows revenue grew $925 million. Not to $925 million. By $925 million.
https://www.microsoft.com/en-us/annualreports/ar2018/annualr...
Linux's driver architecture and even app distribution is a fucking nightmare.
I would say this move by Microsoft is the exact opposite, because it maintains Windows at the centre of the picture.
Microsoft is basically saying, look you can have all your Linux goodness and best of all you can access all that goodness using your current Windows desktop.
Using WSL2 the between Windows/Linux are very blurred.
[1] https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...
So for all that just want a local nix enviroment for dev (and to most these means linux), Microsoft has actually beat Apple at this.
I see WSLv2 as more of a concession that a *nix-style interface is what developers want, and that the NT kernel can't deliver that.
The only thing that NT really lacks is a Unix-style TTY subsystem. The interplay in Unix between TTYs, process control, and signals is complex and deep, and none of it lends itself toward abstractions--it's all quintessentially Unix. For almost everything else, NT provides interfaces that can be used to efficiently implement Unix semantics.
Microsoft isn't interested in supporting a modern POSIX environment natively as that would merely accelerate the migration of the software ecosystem away from Windows APIs. IMO, it's why they killed WSL1. WSL1 was de facto a modern, native Unix personality on NT. They may not have managed 100% Linux compatibility, but they could've simply relabeled it Windix or something, used a small team to round things out, and received UNIX V7 certification in a jiffy.
WSL is about managing the shift toward a Linux-based cloud world, capturing as much of that business as they can without unnecessarily risking their existing footprint. WSL2 neatly allows them to maintain Windows API lock-in while also providing substantial value for those needing to develop Linux-based software. WSL1 fell short on both accounts, though standing alone I think it was much cooler technology.
My take on it was that they were never able to implement all the syscalls (WSL just couldn’t reliably run some production server software), and filesystem calls were horribly slow (try npm install on a reasonably large JS project if you have any doubt).
You may be right — but I’d still like to dream that one day Microsoft will release a true Linux (or OpenSolaris, BSD, or whatever!) OS of their own, which their Office apps will fully support. That’ll be the day I weigh another option besides macOS.
Also, don't forget that Windows and NTFS has never been known for performance. Expecting file access to be as fast as ext4 from a Linux kernel was just the wrong set of expectations. If you want Linux performance you need to use Linux, of course, accessing it's own block device directly; and people demanding that are going to get it with WSL2. The cost is that integration will be worse, both in terms of ease of use as well as performance. AFAIU WSL2 is using 9P now and in the future probably virtio-fs (https://virtio-fs.gitlab.io/) or something similar.
People keep saying how lightweight the WSL2 VM is. Well, that's how all modern VM architectures are now. If you launch a vanilla Linux, FreeBSD, or OpenBSD kernel inside Linux KVM, FreeBSD bhyve, or OpenBSD VMM there's very little hardware emulation, if any[1]; they all have virtio drivers for block storage, network, balloon paging (equivalent of malloc/free), serial console, etc; for both host and guest modes.
[1] I don't think OpenBSD VMM supports any hardware emulation.
"The new Windows subsystem for Linux architecture: a deep dive - BRK3068"
The long, laborious ConHost / NT Console subsystem rewrite/refactor over the last few years has moved Windows a lot closer to the Unix PTY system for internal plumbing (while not breaking the NT Object side of things). The fancy new Microsoft Terminal in alpha testing now takes advantage of that.
> WSL1 fell short on both accounts, though standing alone I think it was much cooler technology.
I feel like this is an interesting case where version numbers hurt more than help, because it sounds like WSL1 and WSL2 rather than a pure 2 > 1 are going to be side-by-side for some time now (moving distros between WSL1 and WSL2 is supposedly a simple powershell operation and can be done in either direction) and hints from Microsoft that there may even still be additional investments in WSL1 depending on user use cases and interest.
I think it's good for the NT Kernel to maintain subsystem diversity, and so I do hope that WSL1 continues to see interesting uses, even if a lot of developers will prefer WSL2 more for day-to-day performance.
(But it's more aimed at services, so doesn't do GUI etc.)