Live data from Hacker News

Running GUI Linux in a virtual machine on a Mac

developer.apple.com

51–60 of 206 posts

Re: Running GUI Linux in a virtual machine on a Mac

#51

The fact that Apple is working on virtualisation shows that there is a user demand for running alternative OSes on a Mac desktop. And yet, instead of opening up their hardware just a bit (by making available some hardware literature on their ARM SoC) to system developers, they'd rather offer a more convoluted way of running other OSes only on their terms and control. It's all about having control over your personal d…

> And yet, instead of opening up their hardware just a bit (by making available some hardware literature on their ARM SoC) to system developers, they'd rather offer a more convoluted way of running other OSes only on their terms and control. It's all about having control over your personal data folks

I think the better argument is that it is what Apple says it's about, security. For the same reasons, we don't see Windows source code, nor are internally discovered Linux kernel security bugs advertised until they're fixed.

I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special...one reason I refuse to bother with the whole security circus is that I think it glorifies—and thus encourages—the wrong behavior. It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important. In fact, all the boring normal bugs are way more important, just because there's[sic] a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking. -Linus Torvalds, 2008

Instead of rolling over and vulnerably showing soft underbelly, armadillos fold in half, tuck in their legs and head, curling their tail beside the head and pull in tight, so that only their leathery armor shell is exposed. If they did what you wanted them to do, their species wouldn't exist for very long.

Re: Running GUI Linux in a virtual machine on a Mac

#53
post #47
post #17

Earlier quoted context omitted.

The only problem: becoming root doesn't mean you now control the device (you paid for).

I feel like I pretty much have full control over my Mac laptop. Why would you expect to fully control a machine from inside a VM anyway? Sounds like a massive security risk too.

Security is entirely orthogonal here. It's like saying you're ok with not being able to enter your own house because of security.

Re: Running GUI Linux in a virtual machine on a Mac

#55

compiling curl today on linux, I see Apple has an internal SSL/TLS curl-7.81.0$ ./configure --help | grep -i apple --with-secure-transport enable Apple OS native SSL/TLS MSFT is adding new signing keys to build and boot Ubuntu. Perhaps Apple wants to play, too and add their own signing keys to build and boot linux, openssl and libssh. Let no crucial technology fall into the hands of the un-corporate?

The Microsoft equivalent of this is SecureChanel and none of this has to do with signing keys or booting.

Re: Running GUI Linux in a virtual machine on a Mac

#56
post #42

Wow, you can use Rosetta to run x86 Linux binaries inside the VM on ARM? That seems pretty awesome. https://developer.apple.com/documentation/virtualization/run...

Maybe I'm missing something, what are the actual commands for running a Linux x64 binary on macOS ARM?

You don't run the Linux x64 binary on macOS ARM. You run the Linux x64 binary on Linux ARM inside a VM on macOS ARM.

Re: Running GUI Linux in a virtual machine on a Mac

#57
post #49
post #42

Earlier quoted context omitted.

Maybe I'm missing something, what are the actual commands for running a Linux x64 binary on macOS ARM?

You can do this in UTM, it's a GUI that wraps QEMU.

Has anyone seen a guide to installing OpenBSD on M1 Mac using UTM?

Re: Running GUI Linux in a virtual machine on a Mac

#58
It seems there is some confusion of what this page is about or why it might be relevant. This is not about an end-user product to run desktop virtualisation, but it is a page for developers in the Apple ecosystem to programmatically make use of OS-native virtualisation to create virtual machines with graphics output.

The value in this is not as much that "it is possible" because there are plenty of implementations of this possibility, but it's more about the vendor-native support, vendor-native documentation and examples and the signal it gives about the current state of support.

In the wild, an end-user (that includes developers, it's not a derogatory term, it simply mens the person the product is intended to be used by) might see applications like UTM, Veertu, Q and others use this under the hood.

VirtualBox doesn't work on ARM by the way, they only release for x86(_64). So it can only virtualise, and only on x86 hosts for x86 guests.

Re: Running GUI Linux in a virtual machine on a Mac

#59

Does this have to be this complex? Can't I just fire up a VirualBox as I do on Linux and Windows and go ahead?

I think this code is for who make VirualBox or similiar management software instead of end user. It basically demonstrate how to use macos's api to launch a virtual machine.

Re: Running GUI Linux in a virtual machine on a Mac

#60
post #13

So we can finally have docker for Mac that doesn't run egregiously slow?

Our solution was to run Linux native on all dev machines. Docker really is a Linux tool and it works much better under Linux. We were running JetBrains IDEs and doing mostly Go, Python and JS development, so the switch was pretty easy and painless. The switch also dramatically reduced developer time spent solving Mac/Linux incompatibilities in tooling, and let us focus more on our product. Overall we accelerated deve…

I swear I'm not trying to be facetious, not trying to stir the same old tired "hurrr year of the linux desktop" shit...

I have to ask: you accelerate development by 1 day/week, but do your devs lose any time with the accumulation of tiny annoyance such as sorting out bluetooth/audio/hibernation/battery drain?

Post reply on HN