Run FreeBSD 13.1 for ARM64 in QEMU on Apple Silicon Mac with HVF Acceleration
gist.github.com
gist.github.com
GNU's Not Unix
FWIW, ZFS has actually been available on macOS for a long time in various iterations (MacZFS, Z-410/ZEVO, and now OpenZFS [0]). I ran it for around 11 years on a number of systems with almost all of my data on it (home folder, applications, /opt for MacPorts etc) and it was a tank. Fun project and well worth checking out. I'll always regret the various factors that meant Apple didn't adopt it as their native FS.
----
If Apple supported ZFS as a first class in-kernel fs type, I'd be delighted.
I have already moved large zfs systems between FreeBSD and debian repeatedly. Snapshots are just ace! (by move I mean zfs export, move hard disks or re install OS and zfs import. zfs snap; zfs send | zfs recv is a different kind of "move" which I also do a lot)
I do miss some aspects anyway in terms of the ease of spinning up/cloning independent FS for projects, VMs etc and having them right there instantly, with their own snapshot policies and rollback chains. Obviously can still do that on a NAS and expose it but it's not at all as frictionless a process. I also miss not being able to do restores as easily, but Apple has steadily killed a lot of the convenience Macs had there and really wants you on the rails of their scheme, so it's better to just try to move as much custom stuff as possible outside the root fs entirely then overlay mount or point to different paths instead. I do still use it on my older MBP but I don't know how that'll survive transition to the AS era. Previously you could through some effort boot off it even, but my assumption is that will be utterly dead going forward so at most it'll be partitioning the internal drive.
From my admittedly biased perspective APFS kind of sucks, it still sees data corruption, it's much harder to repair than HFS if something breaks since Apple doesn't bother to document or stabilize stuff anymore. I still think moving away from normalization was stupid. Overall though it is what it is, and it's Apple's native choice and it mostly doesn't get in the way. I know there's some clever stuff to do with CoreStorage as well and some people have played with using that along with ZFS but I have not.
So yes, guess that turned into a very long way to say that I would indeed miss it if it ever comes to that.
----
0: No issues saturating a 10G fiber link or 8g FC, and I've seen demoes hitting over 11GB/s (88 Gbps) on a Mac Pro 2019 with a higher end FC that I can't afford.
Running docker containers in a Linux VM works OK, but it makes me sad because I don't actually need or want another kernel beside Xnu. For that matter, I don't even need or want docker itself, just a container feature.
Though speaking of Linux, I actually wouldn't mind having BSD's Linux compatibility layer on macOS either.
That's not how jails work.
Note that macOS' Xnu kernel supports BSD system calls (e.g. chroot(2)), and macOS includes a BSD userland which I think is largely derived from FreeBSD.
In principle it should be possible (though non-trivial) to add support for the relevant BSD system calls such as jail(2) and jail_attach(2), as well as the appropriate sysctls to enable BSD jails to actually run natively on macOS.
(For comparison, Linux implements containers primarily via the unshare(2) and setns(2) system calls, as well as /proc and cgroups. It's more of an a la carte approach since there are a number of independent namespaces supported by unshare(2). And bind mounts, overlayfs and the older unionfs, and the venerable chroot(2). Etc.)
To me it seems that supporting the BSD system calls and infrastructure would be a reasonable evolution of macOS' BSD subsystem.
Moreover, as you note, macOS could add an Apple-specific native container feature or framework. Consider that macOS already has a lower-level Hypervisor framework as well as a higher-level Virtualization framework which provided an easy to use API for creating VMs. They could implement their own Container framework or perhaps adapt or extend the existing Virtualization framework.
Less than 1% is confirmed to be UNIX or Unix-like and non-Linux. The top operating systems in order are: 0.3% BSD (97.8% of which is FreeBSD),[251] <0.1% Darwin,[252] <0.1% HP-UX,[253] <0.1% Solaris,[254] and <0.1% Minix.
[1] https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
Honestly, until I got the 10G fiber, I never really tested macOS like this. I have no local tests which could generate that sort of throughput.
The ability to test applications in a native FreeBSD environment? This is just running another OS within macOS same as one might run Windows or Linux images. It's useful for development all on one system, certain kinds of isolated deployments and so on. Also I use it for doing another layer of runs of certain things before pushing out to deployment, you can virtualize a router/firewall like OPNsense or VyOS for example, load your live config, and experiment before sending it out to metal. This is just someone playing around with yet another way to do it. I use VMware myself right now on an x86 Mac but there are lots of choices and it's nice to see more stuff heading over to AS as well.
From your comment though it's not clear to me if you're confusing this with running an alternative OS on the metal, as the Asahi Linux folks are working on? If that's what you were thinking, then the answer would be that longer term having Linux and FreeBSD on AS hardware could help extend its life (Apple won't support them forever anymore then they do any Macs), Mac Minis at least might be useful little appliance systems (eyeballing numbers so far an M1 Mini could in principle compare favorably as a firewall say to a lot of x86 systems in the same power/heat/physical size), and of course some people simply would prefer to stick to another OS they're at home in but also like the Apple hardware. Nothing wrong with that.
[1] https://blog.uidrafter.com/scripted-virtualbox-vm-installati...
And macOS itself I don't use anymore, it's become too locked-down and too minimalistic for me. I want full control over my computer. So I'm on FreeBSD now for my main driver.
However running it on an ARM Mac would be an option for me if it were well supported.
But the entire OS is certainly not FOSS and it limits me very much in what I can do with my computer, unless I switch off its security completely. It's an all or nothing model.
POSIX compliance is not something I actually care about. Having full control of my computer is.
Also looks like macOS still supports union mounts and chroot.
That includes all of the dd commands. These run as they should on macOS with the syntax given in the guide.
Assuming you are using the same version of macOS as me; macOS Monterey Version 12.5
But networking in general appears to work, aside from the ping strangeness.
For example, using pkg to install packages works fine. Likewise, portsnap fetch extract, and when you build packages from ports the system is able to fetch over the network without apparent issues.
Edit: I cleaned up the comments on the gist a little, leaving the ones that are still relevant (the ones about ping), while removing some comments that were talking about problems that are out of date.
I didn't even know you could remove comments on a gist. TIL.
-netdev vmnet-macos,id=net,mode=bridged -device virtio-net-pci,netdev=net
Note: You'll need to run QEMU as root to use vmnet, non-root usage requires an entitlement.