Running GUI Linux in a virtual machine on a Mac
developer.apple.com
developer.apple.com
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.
Because VirtualBox is not a CPU emulator, unlike QEMU, MAME/MESS, and other emulators. Virtualization software such as Fusion and Parallels run VMs of operating systems that match the architecture of the host OS. Intel VMs like those in VirtualBox will not run on Apple Silicon, and Apple Silicon VMs won't run on Intel. The CPU instruction sets are not compatible, nor can Rosetta 2 solve this.
But an OS is arguably a tool used to run architecture compatible software, and much software will compile on different architecture platforms, so while it may not be possible to run VirtualBox on Apple Silicon, it may be possible to recompile whatever software is running on the virtual OS to native Apple Silicon. This is true for 10s of thousands of ports managed by MacPorts and much of the code available on GitHub, but it probably isn't true for proprietary software where the source code is unavailable.
But both VMWare and Parallels for example have made ARM on ARM virtualisation releases of their existing x86 on x86 products.
So if you need something like a sandbox or IR workstation, you can have plenty of virtual environments, just not with VirtualBox as supporting software and type 2 hypervisor.
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.
Newsflash: program for one processor's instruction set won't work on another processor.
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 actually supported, and to add the clarification when this is not the case, because some might also expect this could be the case with say Virtualbox.
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.
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).
Imagine it like this:
┌─────────────────────────────────────┐
│higher-level software to abstract it │
├────────────────────────────▲────────┤
├───▼─────────────────────────────────┤
│low-level software to make use of it │
├────────────────────────────▲────────┤
├───▼─────────────────────────────────┤
│hardware with virtualisation support │
└─────────────────────────────────────┘
So if you have libvirt, you have a high-level abstraction for multiple hypervisors (like KVM and Xen) which in turn know how to interact with various hardware implementations to actually have it act the way we want it.
On macOS there were essentially two low-level implementations, one for ARM and one for Intel, and a higher-level abstraction, Hypervisor.framework, that lets you simply "create" virtual machine instances, which then make use of the various virtualisation features depending on the underlying hardware.
In the early days, the implementations between AMD and Intel were so different that you often needed specific builds for one or the other implementations, and you couldn't have both loaded at the same time (even if just 1 active and every other implementation inactive).
Quote:
There has been no port to M1/M2. All there has been is early work that does nothing useful but somehow escaped the stables. You can safely forget all about it for now.
[0] https://forums.virtualbox.org/viewtopic.php?f=15&t=106919
Virtualizing OpenCore and x86 macOS on Apple Silicon (and even iOS!) https://khronokernel.github.io/apple/silicon/2021/01/17/QEMU...
Run Tiger, Leopard, or any Mac OS X PowerPC version on M1 https://tinyapps.org/docs/tiger-on-m1.html
While ARM virtual machines are limited to Monterey and higher on Apple silicon[0], emulation works just fine for x86, PowerPC, etc.
Here's a video I cobbled together of UTM running Tiger on an Apple silicon Big Sur host: https://tinyapps.org/screenshots/tiger-on-m1.mp4
and another of the same host running Windows XP: https://tinyapps.org/screenshots/20210522-utm-xp.mp4
[0] https://kb.parallels.com/125561 "To run a macOS Monterey VM on Mac computers with Apple M1 chips, Parallels Desktop 17 uses new technology introduced in macOS Monterey, that's why it is not possible to run earlier versions of macOS on a Mac with Apple M1 chips."
Having since learned that they are open source I think I'll look into UTM again, but even as a novice I didn't find it too difficult to use libvirt.
https://en.wikipedia.org/wiki/Binfmt_misc
(To be clear, this is for running Linux x86 inside Linux arm64 VMs on an Apple Silicon host)
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 yet released in stable macOS) Rosetta for Linux translation.
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.
That is entirely untrue: https://docs.docker.com/desktop/install/mac-install/
Hell, it’s even on Windows.
Pretending that the Mac and Windows versions somehow aren't using Linux VMs behind the scenes is of no use to anyone. It's a convenience for users when they can get by with ignoring the VM layer, but a detriment when we see people start talking as though Docker for Mac is functionally different from a Linux VM running Docker, and start assuming that enhancements to running Linux VMs under macOS would be inapplicable to and incompatible with "Docker for Mac".
I really doubt that's the case if you run native Windows containers on Windows.
So while there is in fact an exception to my previous generalization, there's still no cross-platform compatibility magic to Docker aside from that of virtual machines. If the container OS is different from the host OS (or a different version of the OS, for Windows containers), then using Docker is an instance of using VMs, not an alternative to VMs.
For example, docker-desktop on arm-mac can run x86_64 images by leveraging binfmt-qemu within docker's VM. Changing that to use binfmt-rosetta should have huge gains (as there's specific hardware support to enable rosetta).
Yes it's easier to use docker. Hopefully this trickles down so that you get the benefits of this while not changing your usage at all.
I can say that documentation (and examples) are quite nice and easy to follow, I managed to start Linux VM with Rosetta support, and SSH, in 1-2 hours.
Geekbench numbers were quite close when running in VM (via Rosetta) and natively, they were only a few percentages slower in VM, so it stands to reason that computation heavy workload would run great.
However, using development tools regularly resulted in segmentation fault or crashing for other reasons (e.g. when doing `npm install`). I didn't dig deeper to figure out what are the reasons for this.
Additionally, real-world (from developer's point-of-view) workloads such as running web servers, building software, or running tests, were quite slow compared to running in an ARM VM.
I ran x86_64 geekbench in a Linux/aarch64 VM using both Rosetta and QEMU binfmt_misc support and found that Rosetta outperformed QEMU by about 3x. The extra speed is welcome, but I do hope that all the dirty tricks Rosetta uses are eventually able to be used by both non-apple implementations of x86_64 emulation and on non-apple ARM CPUs.
This is pretty exciting, and appears to be a macOS answer to libvirt
Running Intel Binaries in Linux VMs with Rosetta
https://developer.apple.com/documentation/virtualization/run...
Why the "scare quotes"? Sounds totally justifiable. Third party kernel extensions have always have had issues with both security and stability.
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.
Which is all ok till you consider that experienced developers that make good system software can offer better software than Apple, which often may have no incentive to support softwares that isn't aligned with their business interest. Application firewalls is an example, because they can also prevent Apple software and services from data-mining a users personal data. (You may trust the Apple codebase on which all Application firewalls on macOS are forced to run, but what if I don't and want alternative? And if you say, "Then don't use macOS", note that's a very anti-consumer view and is toss to everyone's consumer rights). Virtualisation is another example where non-Apple options can be better than Apple's as Apple would prefer that you do everything on their OS than use alternate ones. Or when you don't want to use Apple software because of the terms you have to accept to use it.
Not much more "anti-consumer" than "if you prefer formal attire, then just don't buy Levi's - as opposed to insist the make black suits and bow ties".
Though I understand the convenience - I'd like to have the option myself in some cases.
What I dont like is third party companies forcing you to install a kext if you want to use their product, for non essential reasons (that could be handled in userland). At least this forces them to work with userland APIs (looking at the "haxie" peddlers out there).
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.
Apple definitely cannot write bug-free code, but your claim that third-party software worked fine without issues is factually incorrect. Third party kernel extensions have historically been a major source of instability and crashes.
That's a misunderstanding of what I was trying to convey. To clarify - I was specifically talking about existing application firewalls and VM applications for macOS that use / used kernel extensions and already have a large userbase on macOS. Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Especially when we consider how such a move is also anti-competitive and anti-consumer, and thus helps Apple's business.
Forcing developers to make an expensive migration from their own tried-and-tested and stable codebase over which they have full control, to use Apple's OS API's is a developer hostile move. Even more so when you consider that a developer will now have to rely on Apple to fix bugs or add new features - which Apple may have no inclination to do so so if it feels it isn't aligned to their own business interest (thus anti-competitive).
I personally have been using some of these applications that install custom kernel extension, and my macOS (3 versions of macOS over a period of a few years) has never crashed or become unstable because of them, so far. If an application that used a kernel extension made my system unstable or crashed it, I obviously wouldn't use it and will uninstall it. But completely taking away my choice as user to customise my OS with kernel extensions, and reducing my choices (as a customer) by taking away the ability of developers to offer a non-Apple custom software solution that is better is also obviously anti-consumer.
Thats not what they are saying though. They are saying, when we have official userspace API, we will remove access to the old kernelspace API.
Thats not to say the kext is bad or evil. It is to say you won't be able to accomplish it in a kext using public api anymore.
Were there badly written kexts before? Were there kexts with interactions? Were there kernel API and whole subsystems kept in for years because some popular enterprise product refused to update?
Absolutely. I'll refrain from mentioning the one I had in mind which hit all three checkboxes.
As far as I can tell, nobody has made a third party virtualization solution for Apple silicon nor is anyone really looking to do so. I don't think this conclusion is particularly surprising.
To be clear, I don't believe there is anything wrong with Apple offering built-in OS API solution for applications like firewall, virtualisation, graphic engines etc. The problem is when they say you can only use those and don't allow competition.
When a particular type of software on macOS is forced to use just one particular API, it stunts all such softwares using the APIS as they can't really offer any major distinction and can only offer the limited features the API provides. Worse still is when such practices is actually meant to restrict competition to protect their business interest. For example, it is clear that Apple is pivoting more and more into commercialising user privacy (monetised through its services) and advertising (by data mining personal data through these same services). In such a case, existing softwares that offer privacy protections (like application firewalls and even alternate operating systems on macs) are examples of competing system softwares that impede this goal. Obviously Apple cannot directly ban these softwares without negative user backlash. But it can ensure that such softwares are crippled by forcing users to use limited API's and / or by limiting the operating environment they run on. (The frog is slowly boiling - https://en.wikipedia.org/wiki/Boiling_frog - and we developers and users are slowly losing more a more control over our Apple computers and device).
Apple has great developers and they can surely build a decent hypervisor API solution. But we'll never know if it is the best if no custom alternates are allowed (either due to lack of hardware literature or due to Apple policies restricting such custom alternatives).
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.
I’ve long thought it would be interesting to release Linux native apps in this sort of wrapper to the App Store.
If you're seeing it use the hypervisor framework, it's possible that's changed since I set mine up and they just haven't seen fit to advertise that change on the web site, which still claims that it's "based on qemu."
(I'm using UTM 3.2.4... just because that's what I used to migrate my data from my old linux laptop to my new mac, and I haven't needed to change it.)
It's testing that's the problem really, where you really need the hardware.
I think UTM's arm64-macos guest support on arm64-macos12 hosts already use the macOS virtualization framework? Or is it hypervisor framework? Either way performance is very good.
We’ve been using it experimentally to run an ephemeral instance of Firefox that we can programmatically inject DNS and CA certs into, for localhost HTTPS development. It’s not documented yet, but the config is here: https://github.com/drifting-in-space/plane/pull/201
Mac and Windows frequently perform non-consensual changes to my workstation. On the other hand, GNU/Linux is challenging for me to get working 100% on bare metal.
This setup is reasonably fast for my work, which is mostly text editing.
This is indeed cool, but RAM on Apple Silicon is relatively low (with only 8Gb in some models) if I allocate more than 2Gb to a VM, the base desktop will struggle.
Or if this was a push to release the Linux support.
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
If only you could use a real window manager in OS X....
For Kubernetes, I use Rancher Desktop (which can also do some docker magic)
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 development by about one day, per developer, per week. I was kind of surprised it was that much time, but looking back, there really are quite a few differences between the GNU userspace and MacOS.
It's been mostly painless for me, minus the usual audio/Bluetooth snafu. Even those don't happen enough for me to be too concerned.
I will look in the logs. I am also planning to “upgrade” to Ubuntu 22.10 when it comes out since it will ship with an Ubuntu-patched 5.19 kernel. Failing that, if I don’t find anything in the logs or don’t have time to find a root cause (more likely), I may have to give up and switch to Windows 11 (sigh).
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?
No. All of the above have been fine - save hibernate. Standard kit is a multidevice logitech bluetooth keyboard and mouse... no issues. A couple of the devs on my team use bluetooth headsets, and that too is no problem. The LG Gram gets about 16-19 hours on a battery, so we've not had drain issues. Audio hasn't been a problem. We did have issues with hibernation when we switched, and solved it by disabling hibernate, and setting the machine to sleep when the lid shuts. I've left my laptop in the bag, sleeping all weekend and had 70% battery on Monday morning. Incidentally, the battery is really not critical... 65W USB3 chargers are cheap so we mostly run plugged in.
Your mileage may vary. Incidentally, LG is making a great machine right now. Huge 17" display, metal case, keyboard has a numeric keypad, great battery life, and it weighs 1 oz more than a 13" Macbook Pro. Oh, and lots of ports.
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: < 5% battery drain per day suspended. Zero wakeups in bag, less than one failed resume from suspend per year (> 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.
This is why GNU/XNU OS distros should be a thing. I think this would satisfy most that want a fully functional "Linux" on Apple Silicon, being in its entirety OSS plus the ability to gain a fully compliant UNIX specification in stride, at least in practice if not actually registered.
Which is why GNU’s core utilities don’t ship in macOS and why the outdated Bash 3.2 (GPLv2) still ships in the latest versions of macOS.
It’s also why ZSH, which uses a variation of the MIT license, is now the default shell when Bash was the default for many years.
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 least two projects derived from it, making it far easier to install and boot, OpenDarwin and PureDarwin. PureDarwin[3] had a couple of bootable releases, but I haven't heard much about it since their last release years ago, but their site says they've been working on drivers and a modified XNU to work without Apple's closed source portions.
IIRC, way back during the end of PPC, I was able to install and boot Darwin CLI on an x86 (probably 486 or Pentium something), but without any drivers, I couldn't do anything with it other than boot it and explore the filesystem. I couldn't even get it to network, so I couldn't install MacPorts, lost interest pretty quickly. It looked exactly like booting Mac OS X without Quartz, Apple's pretty command line.
But the PureDarwin release had X11, and by the screenshots, looked pretty neat. I intended to try PureDarwin's Xmas release in a vm back in the late 2000s, but I was jerked around a lot back then with living arrangements and never got back around to it. PureDarwin's later releases had a lot more functionality.
[1] https://opensource.apple.com/source/xnu/xnu-2050.18.24/
Is it THAT much more convenient to do everything in a VM?
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.
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 wants to develop something like a program that manages virtual machines or that hosts and runs one.
https://mkyong.com/mac/virtualbox-running-slow-and-lag-on-ma...
as well as others suggested on the VirtualBox forums, but couldn't get it running smoothly. I didn't have any trouble with a similar setup several years ago.
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.
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?
Yes. And there have been several examples of small or independent developers cobbling together VM applications based on Apple’s frameworks in the last year or so. I do my know how many will actually survive but there is quite a bit of developer interest.
> 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 don’t know about VMWare, but Parallels does this (for money, I am not a fan of their subscription model). AFAIK the best free equivalent is UTM, which can use either Apple’s frameworks or QEMU: https://mac.getutm.app/ .
> 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?
I would try UTM, personally.
previously: https://news.ycombinator.com/item?id=28430196
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?
Previously, the bar was at the firmware level, where you will never fully control the black boxes governing the security chips, DRM implementations and real time OSes running on the microcontrollers inside the CPU.
Now the OS (especially on Apple devices) is almost becoming like the firmware layer itself, so deeply integrated and locked to the machine, but with the freedom to run other OSes/environments on top.
At least you can (usually) still unlock the OS level...
I am not at all concerned about the privacy of Apple occasionally verifying the developer certificates I use on my computer. I think they have much better things to do then log this information and try to link it back to me. I mean, if they want to know which software I run they have many more — and much better — options to collect my private data than using OCSP. In the end, this is about trust more than about anything else. A Linux software repository could also be collecting data about which packages you download. Second, OCSP is a standard protocol for certificate checking in the web. I mean, Firefox is using it. So is Firefox bad for privacy now? Besides, I think it's entirely silly to be concerned about OCSP privacy when we have things like unencrypted DNS lookup still being the normality.
Look, I fully understand that some people dislike the idea of their OS periodically checking certificates on their computer. Fortunately, there are plenty of systems on the market that can cater to different needs and expectations. You decide what is a concern for you and what not. If you are privacy-oriented to the fault, you probably want to use some secure version of Linux with IP anonymisers, manually installed software and of course everything strictly audited. Most people don't care about this stuff.
curl-7.81.0$ ./configure --help | grep -i apple
--with-secure-transport enable Apple OS native SSL/TLS
Let no crucial technology fall into the hands of the un-corporate?
Like there are options for containers, it is great to have another option for virtual machines.
In macOS itself the main goal is to get third parties out of the kernel to the greatest extent possible, which makes perfect sense. Third parties, ideally, should be operating solely in userland, because otherwise you get pointlessly insecure nonsense like cloud file storage apps installing kernel extensions (like Dropbox used to on macOS).
No, they didn't because a Mac computer that is fully locked like the iDevices wouldn't have been popular and would have meant a lot of bad publicity for the M1 mac desktops. Apple Silicon M1 / M2 macs can only run crippled versions of other OSes and macOS is being slowly converted to be more and more like ios. It's the Boiling Frog strategy - https://en.wikipedia.org/wiki/Boiling_frog - to ensure that they don't scare away their users. With soldered harware, no viable alternate OSes, and taking away developer options from macOS, all Apple Silicon M1/M2 macs are now just a few more steps away from becoming like the iDevices.
Approximately nobody would have passed on a Mac because it could not boot Windows or Linux. This has been more or less the state of Macs since the release of the first M1 devices, and they sell rather well. There is demonstrably quite a lot of interest for these devices running macOS.
> Apple Silicon M1 / M2 macs can only run crippled versions of other OSes
How so? What do they do to cripple other OSes?
> It's the Boiling Frog strategy
Quoting Wikipedia for common phrases does not make you more credible. Again, people have been saying that for more than a decade. It is not inconceivable that it could happen in the future, but then anything could happen in the future. And in the meantime you still sound like a broken clock.
> to ensure that they don't scare away their users.
The whole history of iOS demonstrates the opposite. As said in the parent comment. They’ve had opportunities to actually go to that direction. Nobody was expecting third-party OS support.
You keep implying that there are ulterior motives without a shred of justification. Why do you think that? What power do they get by doing this?
Also, it does not prevent things like Little Snitch or the various Objective See tools from being developed. There are no fewer firewall apps than there used to be. There are no fewer virtualisation applications either.
What you don’t get is that they started from the position that kernel extensions were an attack vector and a factor of instability. Then, they started addressing each use case for kernel extensions by providing user-level facilities. You probably set the cursor at a different location on the security spectrum, but it does not mean that you are any more right than they are.
> They are slowly squeezing macOS to make it more and more like ios.
Some people have been making that tired claim for more than a decade now. You’be had year to see how it works and where they are going, and it keeps not happening. Why do you think this is more credible now?
While there is demand for the latter (as demonstrated by the herculean efforts going into Asahi Linux), most people buying Macs are probably there at least partially for macOS and the ecosystem it fits into, as well as for the ability to run commercial software packages without a compatibility layer like WINE. All things considered it's probably generally easier to make headless Linux containers run acceptably on non-Linux hosts than it is to get complex UI software running acceptably under WINE or a Windows VM.
When I spent some time and installed Linux on my MacBook Pro 2015 some people came asking for instructions (and were mostly deterred by the compiling needed to build a driver for the webcam).
Macbooks are unrivaled for their hardware (pretty much any other laptop sucks), the software is meh and keeps getting worse.
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.
You can also run FreeBSD: https://dan.langille.org/2018/10/02/running-freebsd-on-osx-u...