Maturity of the Apple Silicon builds

[Sharko]

This is a question for Mr. Lundman, and the other principal developers. And I recognize that there probably isn't a precise answer, but I'm still interested in whatever perceptions or opinions you might have to share on the topic.

I'm sure that I'm not alone in wondering about Intel versus Apple Silicon builds: are the Apple Silicon builds as robust as the Intel builds? Are there any extra OpenZFS on OS X risks in switching over to Apple Silicon at this point (beyond the risks that come with the fact that buying a new machine dooms you to being forced to run the latest buggy MacOS sometimes)? Have we reached the point where Apple Silicon builds are the dominant focus of development, and the Intel builds are a lesser focus?

Like a lot of us here, I've been running O3X on a MacPro 5,1, now with OpenCore. However, I can see the end of the road is in sight for my 5,1: I've got one more year of Monterey support and then it's over. I like being able to upgrade my machine with new RAM and disks and even processors. But continuing with a supported Intel platform like the 2019 Mac Pro is unbelievably expensive, even for a used machine. For roughly half the price of a used, entry-level 2019 Mac Pro (~$4k) I could get a reasonably tricked out MacBook Pro that would be future-proofed longer than the 2019 Mac Pro is likely to be supported - but I can only envision doing that if the O3X project is optimistic about supporting Apple Silicon.

Thanks for your thoughts.

[lundman]

So I do have M2mini and M2 macbook as my main work machine, but development and debugging I do in VMs (Win10) using Catalina.

So you could say I do development/debug on Intel, and compile on arm64 when I am happy with it.

Mostly because Catalina is the last macOS that lets me load and unload kexts without rebooting. Soon I will have to give up on this though, Catalina is quite old now.

I was hoping the arm64 VMs "use" would mature before that time. At the moment I can run arm64 macOS VMs fine (as in host is M2 arm64, and macOS VM client is arm64), but they do not allow you to load kexts, so no ZFS on the client when using VMs. (and no snapshots, which is useful for development). This would force me to debug on M2mini hardware, which isn't quite as convenient. But soon, maybe in the next year, I will use arm64 for development, and just compile for Intel.

As for the source differences between Intel and arm64, there are actually very few. Most trouble was from the memory page size change (4096 -> 16384), as we had some assumptions using 4k in the init code. But now that the initial porting to arm64 is done, there is practically no difference between the architectures. All the arm64 fixes we were forced to make, we applied to Intel (back in Catalina days). Even assembly work for arm64 has been done, so there should not be any penalty to going arm64.

I can't speak for future though, Apple can still just turn off kext support whenever they want. (I have hesitated to spend money on Apple for this very reason, but the M1/M2 cpu is *nice*).

[stevez]

Thank you for continuing this work, it is very much appreciated!

My road to Apple was caused mainly from needing 12Gb Video RAM for video editing. I was going to buy a, at the time new, RTX4000 series card which had 12Gb for my Supermicro workstation with endless RAM and storage running FreeBSD and Linux. But literally within 15 seconds it was sold out. Then the choice was to spend upwards $1,000 to buy from a scalper or get a whole new computer in the form of the M1 Mini. The mini seemed too hyped, but it every editor on Mac swore on it and that's where my road lead to. Now I have an Ultra and am very happy with it.

But missing all along has been ZFS, I even heard from some rumor that some Apple devs wanted to use it but Apple (legal?) were too concerned about the licensing.

Then I discovered your work and I'm sitting here viewing to find a good point to start using it. My server is using ZFS (SmartOS) for data security, which is my primary purpose for using it. Of course all the other nice feature are icing on the cake.

I see your point with Apple being able to change at any point and stop using kexts. My (very limited) understanding of kext is that it supports or facilitates kernel extensions, and I'm guessing there's a LOT of code written using it. Is there any sense from Apple and their view of the future of kext? (I'm sure I'm not the first one to look into that.) Is there any other tool competing with kext that could reasonably become a roadblock in the future?

The reason for the questions is of course me trying to get an assessment or prediction of what it would mean for me to start using OpenZFS for Mac. As in future liabilities.

Being able to switch storage to ZFS would be a big relief that is long coming (back).

Thanks again!

[caylakling]

{post deleted by moderator}

[Sharko]

The availability of Apple Silicon builds for OpenZFS on macOS is a significant development for users of Apple Silicon-based Macs.The Apple Silicon builds have been appreciated by users who have made the switch to Apple Silicon machines.It's worth noting that Apple's transition to Apple Silicon has introduced changes and uncertainties, such as the potential for Apple to make changes that could impact the use of kernel extensions . Super Scammy Site

@caylakling: thanks for contributing nothing useful to the forum. Get lost.

So, now I get what these ChatGPT scammers are doing! If you click on the Quote button for one of their posts (and their have been more than a few of late), you will see that they're hiding a link at the end of the posting by using a size=1 bracket around the link. In this posting I changed the name of the link target in the quoted area, and set the size to 100... voila, link is visible now. I suppose this is some form of search engine optimization enhancement scam.

[nodarkthings]

Well done, Kurt!