Hacker News Reader

Hacker News

Comment by cyborgx7 | Hacker News Reader

Parent Full thread

cyborgx7

This project is only completed when you can recursively keep doing this forever, without it ever breaking.

View on HN

Have you seen The Birth and Death of Javascript? https://www.destroyallsoftware.com/talks/the-birth-and-death...

We know how it would look like! Here is a nice illustration:

https://m.xkcd.com/1764/

To tie this back to Wine, here is what we actually do during some parts of the Proton[1] build process: Run a Debian 9 VM, inside of which we run an Ubuntu 12.04 Docker container (the Steam runtime), which runs an Arch Linux chroot in order to gain a modern cross-compiler. It's a doozy[2]!

[1] Proton is Valve's fork of Wine which ships with the Linux Steam client.

[2] https://github.com/ValveSoftware/Proton/commit/d68e71bed61c8...

Out of curiosity, since you might know: is Proton upstreaming changes or are they going their separate ways?

I'm not informed enough to say whether the fork made sense or not, but my immediate reaction was that using a OS project with immense man hours and effort behind it for commercial gain without contributing back would be very ... questionable.

Yes, of course. Valve is a very good open source citizen. The fork was necessary because we have a fair number of changes that are not appropriate for upstream Wine. As a single example, we integrate closely with the Steam for Linux client for stuff like achievements and multiplayer, which obviously can't go upstream. I'm actually the guy who does the rebases, so I'm very motivated to keep the diff as small as possible :) You might find this article from March interesting: https://www.codeweavers.com/about/blogs/aeikum/2019/3/27/how...

Thanks for the amazing work you guys are doing! I'm keeping an eye on the progress and it's amazing to see: https://boilingsteam.com/proton-keeps-making-its-way-in-comp...

Thanks, that's great to hear!

May I ask why you need that many distributions? It really looks interesting.

Debian 9 for the Vagrant VM, because it was modern at the time (probably upgrading it to Debian 10 soon). Ubuntu 12.04 because that's what the Steam runtime uses, because it was modern at the time and upgrading while maintaining binary compatibility is Hard. Arch Linux because building a modern cross-compiler on Debian/Ubuntu is Hard.

What, did you want good reasons? :)

I tried following those steps and got this error:

https://www.betaarchive.com/imageupload/1299034742.or.31168....

Does anyone know of a workaround?

That's a thing already: http://git.annexia.org/?p=supernested.git;a=summary

Any CPU can only have one hypervisor running at a time. Thus the recursion stops pretty quick.

Actually most modern hypervisors allow nested virtualization.

https://www.linux-kvm.org/page/Nested_Guests

https://communities.vmware.com/docs/DOC-8970

Not even just modern hypervisors. The IBM mainframe hypervisor z/VM (and its predecessor VM/CMS) has supported nested virtualisation for decades. It was an important tool to support its own development (especially considering that mainframes were expensive and not even IBM could afford to give every mainframe OS developer a whole mainframe to themselves.)

Intel and AMD CPUs have supported hardware-accelerated nested virtualisation for quite some time now.

https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w...

https://www.redhat.com/en/blog/inception-how-usable-are-nest...

Cygwin and Wine don't use virtualization. And even if they did, most hypervisors support nesting these days.

Because, of course, its not a emulator

Well, yes and no. On modern enough hardware you can do nested virtualisation, so you can run kvm in esxi on hyper-v if you want. Not that it's very usefull, but it is a fun weekend project nonetheless.

I use nested virtualization for Windows Desktop -> Linux VM -> minikube. Works great.

Obviously you could just run minikube under Windows, but then from the Linux VM you can't "minikube ssh" and whatnot, so nested virtualization makes everything a lot simpler.

You can even do nested virtualization without hardware support, it's just super duper slow and not a lot of hypervisors think it's worth the complexity increase.

Aside from all the other corrections, hardware virtualization support isn't necessary for virtualization.

WSL1 is not a "real" VM. https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process...

Why? There's only one hypervisor involved for the initial "wine" environment.

Neither WINE nor WSLv1 use virtualisation. WSLv2 does use virtualisation however; but WINE still isn't a VM.

I was referring to WSLv2 here, so technically there is a hypervisor involved at the root level hosting the first WINE instance in the chain.

Further recursion WINE => Cygwin => WINE however will not require more nesting of hypervisors.

Reply on news.ycombinator.com