Come on In; the Unix is Fine! ;-)

https://www.howtogeek.com/4415...

https://manp.gs/mac/

https://developer.apple.com/li...

Of course, there are package managers that make this far easier. Here’s a Popular one:

https://brew.sh/

Enjoy!

Get yourself a used M-series Mac mini and have some fun!

Signing up as a Registered Developer is Free, as are the Tools.

This is the Front Door to the Apple Development Multiverse ( 8-D ). This Site is HUGE

https://developer.apple.com/

Well, I respect your opinion; but in my 50 years of being an Apple User (and the User of other Platforms) I have found that their superior security and almost total lack of Malware, as well as their best-in-class OSes and unbeatable Integration to be well-worth any unobtrusive and anonymized data collection they may do for their own marketing and product development purposes.

Thanks for being a NON-Apple-Using Person WITHOUT some inexplicable vendetta against all things Apple!

Mighty Rare around these here Parts. . . :-)

Not only that, but HFS+ Timestamps simply run out of Dynamic Range in 2040; so. . .

Buy a nice 12 TB HDD from Amazon, do your Conversions, then either return it or turn it into your new Time Machine Backup Drive!

HFS+ Support isn’t going anywhere. Just the HFS+ Encryption Support!

Who knows what will happen when HFS+ Timestamps run out of Dynamic Range in 2040? But until then, Unencrypted HFS+ Volumes continue to enjoy Full Read/Write/Format Support!

In the meantime, this is the recommended answer:

https://support.apple.com/en-u...

They really tried to convert to ZFS.In fact, there was even ONE version of OS X that had experimental Support for it.

Problem was, not only was ZFS not ready for prime time (not supporting Booting, plus large RAM requirements and several Bugs being a few of the problems), But the real Deal-Killer.was the fact that, just about the time Apple started getting serious about ZFS, along came Oracle. . .

Apple in no way wanted to be beholden to the whims of Larry Ellison; so, with that, they rolled-up their sleeves, and spent about a Decade developing APFS in secret. They secretly rolled it out to iOS Users first, then after a couple of years, Made it the Mainline Filesystem for macOS, starting with macOS 10.14 (Mojave) in 2018.

The rest is a pretty happy story. If there were any real horror stories, I don’t think I ever heard them!

Nothing.

Here’s Apple’s Tutorial:

https://support.apple.com/en-u...

The reason why they have that money is that they know when and where to spend it.

Rewriting HFS+ Encryption from the ground-up to support the 1,000 Users worldwide that somehow live in a tiny nexus of those still relying on HFS+Encrypted Volumes; yet for some unfathomable reason, cannot simply convert those Volumes to APFS, with or without Encryption.

Apple has a Step-by Step Tutorial on the Process:

https://support.apple.com/en-u...

  Better hurry; you only have TWO YEARS to get it done!

Not worth it to rewrite from scratch; and too rickety to just ignore it anymore.

You’re exactly correct.

And to make it even clearer, apparently the HFS+ Encryption handling was kind of spaghetti-coded into several places in the OS; and with Apple doing a big push to remove all x86 Support by 2028, I’m sure there has been an additional directive to identify other things that should be looked at while they have the hood open. . .

APFS Encrypted Volumes aren’t going anywhere; nor is full Read/Write/Format support for regular HFS+ Volumes.

Time marches on. . .

Oh just stop it!

They are removing HFS+ Encryption Support because it was apparently a bit of a Kludge; with pieces-parts scattered in Several places in the OS. With the current push to remove all vestiges of x86 Support from macOS in time for macOS 28, I’m sure there was a general call within Apple to also look for deprecated or poorly-implemented stuff for review. II just seems pretty logical to remove some ugly Deprecated Kruft at the same time, no?

OTOH, The reason why general HFS+ Support remains should be obvious to anyone that doesn’t have an agenda to cast every single thing that Apple does as some sort of nefarious plot ; HFS+ was the Flagship Filesystem for Macs going all the way back to the 68k Days. Can you imagine the backlash from Users if they suddenly couldn’t read their legacy (and not-so-legacy) Data?!?

Sheesh! What a Maroon!

They are removing support for the Deprecated HFS+ Encrypted Volumes ONLY.

APFS Encrypted Volumes aren’t going anywhere.

Apple moved from HFS+ to APFS as their Frontline Filesystem for macOS With macOS Mojave (10.14), back in 2018. They actually switched iOS to APFS a few years earlier. Starting with Mojave, Boot Volumes were automatically formatted as APFS.

The sky did not fall. . .

Also, Non-encrypted HFS+ Volumes continue to enjoy full read/write/format support in macOS, and there is no reason to expect that to change anytime soon.

From what I have read, the code that implemented HFS+ Encrypted Volumes was kind of scattered around in several places in macOS, and Apple is currently digging through their OS Code in preparation for final removal of x86 Support in 2028, and consequently, it probably seemed like a good time to do some general housecleaning.

At this point, Apple is giving Users plenty of time to Unencrypt any Encrypted HFS+ Volumes they have, and Move them to APFS.

At this point, APFS is quite sufficiently Battle-Tested.

Says the COWARD.

FOAD.

Apple moved the T2 Functionality directly Into the Apple Silicon SoCs. Even more secure.

As for Data Checksumming, Apple trusts the ECC built into their SSDs to take care of that Task.In their own words, “Our Storage doesn’t Return Bad Data.”

It’s pretty well agreed that actual Bit-Rot-Style Data Corruption in SSDs is all but unknown.They tend to work perfectly, or not at all. So, ZFS-style Data Scrubbing is nothing but a waste of Resources with APFS.

They do, however, Checksum the MetaData of Filesystem Objects.

Here’s a fairly decent explanation of Apple’s Rationale for its design decision regarding Checksumming:

https://ahl.dtrace.org/2016/06...

So much closed-minded thinking regarding Macs around here. . .

DING DING DING!!! We have a winner!

That (T2 incompatibility) is exactly the reason! Plus, I wonder if some of that code was never converted/can’t be converted to ARM?