The Future of Docker Desktop for Windows
engineering.docker.com
engineering.docker.com
If I was on VM-Ware's executive team, I'd be seriously thinking about filing an anti-trust complaint and the open source community should be thinking about whether submarining virtualbox is worth what Microsoft is doing here.
Wait really? That doesn't seem right, why would they have the host running under part of hyper v when hyper v is optional? This would mean the entire foundation shifts when you enable or disable hyper v
To say nothing of the madness of using it on a laptop with several network adapters when the guest OS only wants to acknowledge one.
I concurrently build vagrant boxes (using Packer) for VirtualBox, VMWare and Parallels on macOS.
My point is that it's fundamental to the way the tech works.
Sure, a level 1 HV makes a lot of sense for a VM host.
For this, not so much.
Most likely in the next few years Hyper-V will become non-optional and Windows will always be virtualized when you run it. That's a big architectural shift that will enable lots of cool new scenarios, but it requires a level 1 hypervisor.
But sure, keep down voting because someone said your dumpster fire OS is crap.
(and yes, ESXi is a type 1 hypervisor--it's definitely something Microsoft could enable more broadly, instead of limiting the scope to Hyper-V nested setups)
I'm learning a lot from this conversation, thanks.
(Not sure about nesting other hypervisors.)
To me, it seems like the use of Hyper-V was probably necessary to get the tight integration they needed to make the use of WSL 2 as seamless as it is today with the lightweight containers.
VBx also have some extra goodies like the built-in DHCP-server, host-only networking and so on which Hyper-V seems to be lacking.
It's great and seamless, just pass `-accel whqx` (instead of `-accel hax` or `-accel kvm`).
There are working binaries here: https://shadycode.com/qemu-binaries-for-windows-64-bit-with-...
I've been doing that for years now (I originally built my own Docker client binary for the Mac and pointed it to a Linux box, did the same when I ran Parallels on my Mac, and still do it occasionally with ARM boxes at home). People forget that Docker was designed as a client-server solution, and that the server bit works fine.
You can ask your sysadmins to set up a VMware instance running boot2docker and link it directly to your Windows workstation.
The article is about two things:
1. WSL 1 was not enough to run docker on it 2. WSL 2 is what was needed and with it Docker can use it and replace the Linuxkit based bits it currently ships, and get other improvements along with it.
You mean the product they've all but abandoned?
https://arstechnica.com/information-technology/2016/01/vmwar...
>submarining virtualbox
Oracle will manage that on their own regardless of what Microsoft does. They already started by making the extension pack free to download but licensed so they can catch unsuspecting users in one of their famous audits.
Starting a new terminal with wsl1 takes so long and I'm less than happy with all terminal emulators.
ConEmu has broken copy paste, alacrity doesn't have proper tiling... Heck, I've started using hyper of all things.
I realize that I probably never be happy on Windows when I can actually use i3wm at home, but if it could just suck less I'd be so ecstatic.
It has 4 different paste methods in the settings, I encountered the bug on all at work. I've used it without encountering the bug before though, but I haven't figured out what causes it.
https://github.com/microsoft/terminal
You still have to build it from source in VS 2017 or 2019, and there are a few rough edges (currently only middle click for copy/paste), but it's a great start. They should have some official binaries up pretty soon.
https://dev.azure.com/ms/Terminal/_build/results?buildId=203...
This way you are registering the app directly instead of installing the appx.
https://www.microsoft.com/en-us/p/windows-terminal-preview/9...
Although I admit, sometimes the BSD toolchain poses some rather hilarious speedbumps. At that point WSL can be smoother? Weird.
Can you go into more detail about why that's the case — package selection, versioning policies, etc.? The main thing I've typically found is testing version-matched deployments and Docker has made me care about that a lot less.
If the IT department prepared a pre setup image, all you need to do is boot it up.
Second, why use a cross platform app inside VM? Using the VM only for command line interface through SSH will get rid of any lag. You can share the host OS file system inside the VM and use GUI app on the host OS against native file system and you won't have to worry about filling up VM disk.
Connecting some $1k MacBook Air to an external monitor + keyboard would get you a decent desktop experience which you can even take it out. Not sure how that is any expensive.
[0] https://code.visualstudio.com/docs/remote/remote-overview
Also, copy/paste works perfectly and I found that fewer of the default keybindings conflict with those in my shell, tmux and vim.
https://github.com/mintty/wsltty
I've found it to be the most consistent and performant. Still not the same as being in a native Linux environment, of course, but it's the closest I've been able to get in Windows.
[0] https://magit.vc/manual/magit/Microsoft-Windows-Performance....
I've hence been avoiding volumes for things other than static files or backup/restore directories.
> Also, bind mounts from [Docker on WSL2] will support inotify events and have nearly identical I/O performance as on a native Linux machine, which will solve one of the major Docker Desktop pain points with I/O-heavy toolchains.
I use wsltty for the terminal, it's pretty minimal, but better than the windows terminal.
> ...because WSL 2 works on Windows 10 Home edition, so will Docker Desktop
Glad to see this too:
> bind mounts from WSL will support inotify events and have nearly identical I/O performance as on a native Linux machine
The running theory is that they want HyperV on for all installs (like turned on by default).
One of the rare things to feel upbeat about is that we have great choice when it comes to OSes.
As a former Windows user, then macOS convert, I look at what's happening on Windows with envy. macOS is getting prettier and perhaps more consistent, but buggier. It's very frustrating. I've had so many problems with security updates, with both the latest and other supported versions. Apple support is terrible these days. I filed a bug report with them and weeks later they give me absolutely lame replies.
The only thing that gives me pause, still, about Windows 10: it updates when it wants to and that is difficult to turn off (you can set your network to "metered" and I hear that will do it). Also the telemetry. I feel like it spies on its users more than Apple's product does.
It really ruins it.
And some people can't even try to switch out of Windows.
Compare that to a rolling release distro like Arch or fast moving one like Fedora or slower moving Ubuntu LTS that gets HWE stack upgrades life is really easy. You get a built in hypervisor (KVM) that can be used by the Android emulator, your libvirt VMs and docker. Want to run dtrace/bpftool - no need to compromise security. Need latest GCC - easy enough to get - it goes on and on. Not to mention the package managers are pretty good on all Linux distros now a days.
With Windows the downside was that WSL 1 was slow and macOS was faster than that although slower than Linux for FS operations etc. But now with WSL2 pretty much matching native Linux performance and allowing you to use docker natively - it suddenly becomes a much better option - can buy cheaper hardware that does what you want to without relying on Apple to give you the right keyboard, # of ports etc.
I am optimistic for WSL2 because while Linux was an option I was given it was very much a "Do so at your own peril we have a lot of homegrown tools that are not tested outside Windows and macOS". In a year or so maybe I'll switch to Windows w/ WSL2 or just back to Linux but there was no good reason to rock that boat at this time.
The comments make it pretty clear how the Github crew feels about it, but I’m curious the response over here.
Now, fingers crossed for transparent inotify...
The idea of nuking the linux environment gets easier when you run one natively as you start to understand the system better.
I understand the idea where everyone wants to have the same ecosystem to run things on (docker) but the best part of linux was the fact it wasnt the same as windows
This convergence of the operating systems is concerning
Power management seems OK but I dunno how that relates to the fan controller because in Linux my laptop sounds like a jet engine 90% of the time while in Windows it rarely spins up.
I have more issues with windows than I do linux but I have been using linux on a desktop for ~15 years or more now ( would say 19 but there was a BSD period in there )
Note: this is all for personal projects on my home desktop, my work laptop is Windows and I have no problems with it for my current position.
You would need PCIe pass through, so the VM could control the GPU. For that, you would need either separate GPU, or a GPU that supports SR-IOV, and a board that supports IOMMU.
ROCm specifically is not only userland, but also a kernel driver (amdkfd/amdgpu). To use it, you are going to dual boot into native Linux for a while.
Where you'll run into issues is on the NVIDIA side. They deliberately cripple their consumer drivers to prevent use in virtual environments to extract licensing dollars.
(Haven't tried AMD but last I remember, their cards don't support being pushed around by the IOMMU. Could be wrong.)
[1] https://docs.microsoft.com/en-us/windows-server/virtualizati...
https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq#can-i-...
For me, it feels it could be the opposite with Windows potentially impacting how Linux moves forward by having more devs using WSL instead of actual Linux and not actually optimizing for native Linux support.
For an example, Valve's Proton vs. native linux games, if I was a game dev, I wouldn't bother porting any Windows games to Linux, just rely on Proton instead.
I see what you mean, but on the other hand, most game development studios already didn't bother to port anyway.
ls works in Power Shell (though I believe it's just an alias)