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

201–206 of 206 posts

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

#201

Post by dwaite »

webmobdev wrote: post #199
saagarjha wrote: post #198

Earlier quoted context omitted.

"Virtualization" in this context is not the framework but a custom hypervisor API rather than Apple's, as some vendors implemented on Intel Macs. I agree with your points about this limiting what you can do, but the replacement API is actually fairly decent in this case–there are some things that could be improved but overall it's not actually that bad.

I do believe most of the current VMM apps - Virtualbox, Parallels, VMWare - that run on Intel Mac do offer their own custom hypervisor solution mostly tapping on to "Intel Virtualization solution" ( https://www.intel.com/content/www/us/en/virtualization/virtu... ) through kernel extensions and / or the macOS hypervisor framework (which I think avoids kernel extension). This is possible because Intel is more "open" an…

> This is possible because Intel is more "open" and readily shares their hardware literature / SDKs with developers and that is why we have had many custom, decent and performant hypervisor solution on Intel Macs. But Apple has been loathe to release similar literature for their ARM SoCs because they don't want independent competitive alternatives to their system softwares.

Are you looking for https://developer.arm.com/documentation/100942/0100/AArch64-... ?

Access to virtualization features is provided through the hypervisor framework for both intel and apple silicon products. If you have an existing Intel architecture product you might be upset that Apple is going to disable your ability to use virtualization directly via a kext.

But, I have a hard time imagining someone really wanting to use their own hand crafted hypervisor rather than the one Apple built on Apple Silicon for running on Apple operating systems - especially since Apple has committed to providing additional hard things like paravirtualized hardware.

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

#202

Post by dwaite »

punnerud wrote: post #24

Would not be surprised if they use the open source GPU driver for running Linux: https://news.ycombinator.com/item?id=33019316 Or if this was a push to release the Linux support.

Not really - https://developer.apple.com/documentation/paravirtualizedgra... . They expose a display object which works with Metal primitives.

Supporting the native GPU would mean they would have to get the guests to update for each new GPU. I'm sure Apple loves the idea they could completely rearchitect their GPU for future Apple Silicon, and it would break no preexisting macOS/iOS software

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

#203

Post by dwaite »

TGRush wrote: post #146

I wonder why they would publish this when Asahi is already quite usable, and Intel macs can run Linux natively too Is it THAT much more convenient to do everything in a VM?

Going forward, Apple won't officially support dual boot or alternative operating systems. Unofficially, they'll try their best to leave the options open for third parties like Asahi, but it will never be something they endorse as an option to macOS on their devices.

For example, there will not be an ARM version of Boot Camp published by Apple. If you want to run Windows on an Apple Silicon Mac, it'll likely be running virtualized under macOS or in an emulator under macOS.

If someone wants to write a bunch of drivers and hack a boot loader to get windows running natively - Apple won't stop them, but thats a heck of a lot of work.

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

#204

Post by saagarjha »

dwaite wrote: post #201
webmobdev wrote: post #199

Earlier quoted context omitted.

I do believe most of the current VMM apps - Virtualbox, Parallels, VMWare - that run on Intel Mac do offer their own custom hypervisor solution mostly tapping on to "Intel Virtualization solution" ( https://www.intel.com/content/www/us/en/virtualization/virtu... ) through kernel extensions and / or the macOS hypervisor framework (which I think avoids kernel extension). This is possible because Intel is more "open" an…

> This is possible because Intel is more "open" and readily shares their hardware literature / SDKs with developers and that is why we have had many custom, decent and performant hypervisor solution on Intel Macs. But Apple has been loathe to release similar literature for their ARM SoCs because they don't want independent competitive alternatives to their system softwares. Are you looking for https://developer.arm.c…

There are reasons one might want to do this; for example Apple does not provide access to all hardware performance counters in the guests they set up. This can be important for certain usecases. That said, beyond this there aren't really any good reasons why you should eschew Apple's solution, so once (if?) this is fixed the existing solutions should be pretty solid.

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

#205

Post by dwaite »

riffic wrote: post #95

are darwin-native containers on Apple's road map at all? previously: https://news.ycombinator.com/item?id=28430196

Apple unfortunately does not talk about future product plans. We won't know until hypothetically there is something real.

Given that they focus on units of apps rather than of system containers, I would _suspect_ it would be low priority to support a libcontainer API.

Are you actually wanting a Darwin BSD container layer, or just a more efficient way to run Linux containers?

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

#206

Post by indymike »

hedora wrote: post #155
isoprophlex wrote: post #60

Earlier quoted context omitted.

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 but…

My criteria was simple... if I put it to sleep it mist wake up.
Post reply on HN