Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running GUI Linux in a virtual machine on a Mac

developer.apple.com

Post reply on HN
Print view View original

151–160 of 206 posts

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

#151

Post by coldtea »

philipkglass wrote: post #105
coldtea wrote: post #100

Earlier quoted context omitted.

> You can, but running Linux with a graphical desktop on VirtualBox under MacOS has become extremely sluggish in my experience. Huh? It's actually faster than ever, and near native experience. And the post is not about "how to run" a virtual machine as an end user or dev (for that the way the parent describes is still the suggested way). It's about how to program running it under the hood if you're a developer who wa…

I'm only referring to the VirtualBox experience asked about by qwerty456127. Running e.g. Debian with Gnome under MacOS became extremely sluggish for me. The screen re-renders slowly, like running a remote desktop over a slow network link. I did a lot of searching and setting-tweaking when I encountered the problem earlier this year. I never found a satisfactory resolution. I tried this fix: https://mkyong.com/mac/vi…

Ah, sorry, glossed over the Virtualbox part - thought it was about generally about running a VM on a Mac.

I used to use Virtuabox on x86 Mac until 3-4 years ago, don't know if it was changed - but then again, I used it for headless Linux only.

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

#152

Post by coldtea »

webmobdev wrote: post #140
coldtea wrote: post #99

Earlier quoted context omitted.

> are no longer allowed to have their own custom kernel extensions for "security" and "stability" Why the "scare quotes"? Sounds totally justifiable. Third party kernel extensions have always have had issues with both security and stability.

It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worke…

>It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software.

They don't have to be "the only one who knows how to write such bug-free or secure system software".

They just have to disallow a class of potentialy buggy and insecure software running with kernel level access, and that's enough to keep tons of additional attack vectors off the OS.

I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension.

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

#153

Post by [deleted] »

chrisseaton wrote: post #84
Maursault wrote: post #82

Earlier quoted context omitted.

> But both VMWare and Parallels for example have made ARM on ARM virtualisation releases of their existing x86 on x86 products. Right, but the VMs themselves are not cross platform. ARM Linux won't work in Intel VMWare, and x86 Linux won't work in ARM VMWare. I am sure you knew, or course, but as you pointed out there is confusion below about VirtualBox working on Apple Silicon.

> ARM Linux won't work in Intel VMWare Newsflash: program for one processor's instruction set won't work on another processor.

[deleted]

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

#154

Post by coldtea »

chrisseaton wrote: post #98
coldtea wrote: post #96

Earlier quoted context omitted.

If only it was that clear cut. As you well know, with Rosetta and other technologies (heck, also Wine) that's just not true. With Rosetta you can take any (or most) Mac programs compiled for x86 and just run them on M1 ARM. Support gets even deeper, as with the Rosetta update you will be able to even run x86 binaries inside a hosted ARM virtual machine (!). So it makes sense for people to be confused as to what's act…

> Well, with Rossetta and other technologies (heck, also Wine) that's just not true. Rosetta takes an instruction stream from another processor and translates it to an instruction stream for another processor - that's exactly what I mean - it needs translation.

Sure, and I know you know it.

But it's exactly the availability of said translation that makes the claim "program for one processor's instruction set won't work on another processor" less clear cut than the "news flash" sarcasm implies.

Doubly so since this translation is often automagical and transparent to the one using it (so they expect it to just work in all cases).

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

#155

Post by hedora »

isoprophlex wrote: post #60
indymike wrote: post #41

Earlier quoted context omitted.

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?

I get the impression that sleep doesn’t work properly on any current Intel laptop, regardless of OS.

I’d love to hear of a counter example. Use case is close it and stick it in my bag most nights, leave it plugged in and suspended others.

Acceptance criteria: 99.9% resume reliability). After resume, network / vpn reconnects without intervention in under 10 seconds, and no apps are janky.

Bonus: pressing the power button once when it is off must cause an led or screen to turn on within 1 second every single time.

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

#156

Post by qwerty456127 »

coldtea wrote: post #100
philipkglass wrote: post #64

Earlier quoted context omitted.

You can, but running Linux with a graphical desktop on VirtualBox under MacOS has become extremely sluggish in my experience. I don't know whether newer releases of MacOS or VirtualBox itself are to blame. It was much snappier 8 years ago even though I had a significantly slower laptop then.

> You can, but running Linux with a graphical desktop on VirtualBox under MacOS has become extremely sluggish in my experience. Huh? It's actually faster than ever, and near native experience. And the post is not about "how to run" a virtual machine as an end user or dev (for that the way the parent describes is still the suggested way). It's about how to program running it under the hood if you're a developer who wa…

> It's about how to program running it under the hood if you're a developer who wants to develop something like a program that manages virtual machines

Has somebody already done that perhaps? Is there a reasonable alternative to VirtualBox/WMWare using the optimal way to run a VM on a Mac? I don't mind paying if it's worth it.

I have zero experience of Mac development but I am going to need to run Windows 7 (to use IE6 with old crypto to access an outdated state-ran system) on an M2 MacBook next week. What's the best way to achieve that?

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

#157

Post by mbreese »

webmobdev wrote: post #140
coldtea wrote: post #99

Earlier quoted context omitted.

> are no longer allowed to have their own custom kernel extensions for "security" and "stability" Why the "scare quotes"? Sounds totally justifiable. Third party kernel extensions have always have had issues with both security and stability.

It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worke…

This isn’t the way Apple wanted it to work. In a perfect world vendors would write good kernel extensions that were stable and wouldn’t crash a system.

Instead, in the real world we got vendors that wrote horrible and unstable code that was required by IT departments. For example, instead of implementing a firewall using Apple technologies, in a stable manner, we got an “enterprise” firewall kext that would crash whenever a USB network card was plugged in. And I mean crash the computer. My USB-C dock was absolutely worthless because of this exact issue.

Vendors forced this on Apple. IT departments that were primarily Windows shops would just blame Apple instead of the vendor. Because their software worked for Windows, so why was it only a problem for Apple? I know the IT department at my $WORK had this mentality.

Now at least I have a stable system and I don’t miss not being able to add my own kexts.

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

#158

Post by alwillis »

Maursault wrote: post #148
alwillis wrote: post #144

Earlier quoted context omitted.

I should have been more clear: Apple has and continues to ship GPLv2 software but not GPLv3, since one interpretation of that license is that by including GPLv3 code in macOS, they’d be required to make the source code to at least the entire Darwin (the Unix layer underneath the GUI) operating system available, which is something they probably don’t want to do. Which is why GNU’s core utilities don’t ship in macOS an…

> Darwin (the Unix layer underneath the GUI) operating system available, which is something they probably don’t want to do. Darwin is open source, and Apple did make Darwin available[1][2], but the issues are it takes some skill, experience, and understanding to put it all together and build it, and many parts have become closed source since Apple first released. Also, there are basically no drivers for anything. At…

I did say at least Darwin… the rest of macOS would probably have to open sourced if it included GPLv3-licensed code.

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

#159

Post by geofft »

wtallis wrote: post #120
zakjan wrote: post #112

Earlier quoted context omitted.

It seems overly complicated. Is there any benefit over using Docker?

I'm not sure what you think Docker on a Mac does. Docker is a Linux-specific piece of software, and the only way to use it within macOS is to run a Linux virtual machine, with Docker running inside the Linux VM. If the containers you want to run with Docker are x86 software, that Linux VM either needs to be an x86 Linux distro running in qemu emulation of a full x86 machine, or an ARM Linux distro using the new (not…

Well, kind of. Docker is a product, with official support for Linux containers on Mac (and Windows containers on Windows!). Docker for Mac comes with a Linux VM as a feature of the product; you don't need to install it yourself inside a VM (though that works, too).

It does sound like adding Rosetta binfmt_misc support would allow Docker for Mac to ship an ARM64 kernel/VM image instead of an amd64 one and benefit from some performance boost, but potentially at the risk of reliability/fidelity. The entire idea of Docker is that the kernel ABI is a (supposedly) stable interface, and even if your userspace changed around it, a Docker container would have its own userspace and wouldn't care. Running a different-architecture kernel and dynamically translating it necessarily means that there will be visible differences in the kernel ABI. Sure, you can translate those differences, but that gets you farther from the promise.

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

#160

Post by saagarjha »

oneplane wrote: post #87
chrisseaton wrote: post #83

Earlier quoted context omitted.

Doesn't AArch64 support the same virtualisation primitives that VirtualBox uses on AMD64?

Yes and no. Similar in functionality, different in implementation. So you do get things like IOMMU etc. but you need a different software implementation to make use of it, even if only to use the different ISA and setup procedures. Imagine it like this: ┌─────────────────────────────────────┐ │higher-level software to abstract it │ ├────────────────────────────▲────────┤ ├───▼─────────────────────────────────┤ │low-l…

Hypervisor has a core API that is shared across Intel and Apple silicon (e.g. hv_vcpu_run) and then each platform has its own additions on top of this (for example, on Intel platforms you can prod the VMCS). On top of this is the Virtualization framework, which provides a largely unified API to run VMs (dealing with things like screens, pointing devices, etc.) that and treating the actual virtualized processor as an implementation detail, besides you having to provide an image that matches the host architecture. The linked code here uses Virtualization.
Post reply on HN