> To conclude, I don’t understand why hdiutil needs to be deprecated when the same functionality will live on in diskutil. For some reason, Apple seems intent on breaking longtime workflows and scripts.

Brother, it’s Apple. Any backwards compatibility is purely incidental.

Diskutil has been around for over a decade and slowly getting features that hdiutil was missing.

Things change but this is hardly some sort of sudden rug pull by Apple.

Given Apple's reputation as of late, I was mildly shocked to learn that I could connect a SATA optical drive to my Mac with a USB-SATA bridge, right click on an image in the Finder, and tell it to burn the image to DVD. This is under the latest beta of macOS.

You can call it incidental if you want, but it generally takes some effort to ensure everything works. That's especially true when you consider how much has changed since optical drives were common.

As for other forms of disk images, such as software distribution, those are still a common thing in macOS.

iPods and AirPort Express units from 20+ years ago still work in modern macOS too. Things have been shuffled around some (iPods are now managed with the Finder instead of in Music.app) but they still work.

I would agree with the idea that they're not bothered about breaking workflows, particularly those involving command line tools, but hardware compatibility isn't nearly as bad as the internet might have one think. Source compatibility isn't all that bad either, many ancient Objective-C/AppKit codebases can be made to compile in an evening. It's mainly binaries that break.

Yeah, Apple is very weary of breaking user functionality. They'll just break your app's ability to run.

Frankly, I don't think it's practical to expect operating systems to continue to run binaries perfectly in perpetuity. It's an enormously burdensome expectation that holds development of the platform hostage.

Usually all it takes to keep one's software running on macOS is compiling against the latest SDK once every ~5 years. Depending on the nature of the app, source changes often aren't even required. As a dev I don't think that's too much to ask.

> Frankly, I don't think it's practical to expect operating systems to continue to run binaries perfectly in perpetuity.

A lot of that is going to depend upon perspective.

Take something that is coming up: Apple has mentioned that Intel application support is going to end in the next release, or about 8 years after the introduction of the M1. Eight years may sound like a good run, but there are all sorts of edge cases: software that doesn't receive updates because the publisher is no longer in business, or software developers who are providing updates under a disagreeably different business model (ahem, subscriptions). Some software may have been released Intel only after the release of the M1, simply because the developer wasn't going to test a new architecture immediately after its release.

I'm not going to pretend that I know how much software that affects, because there was a 12 or 13 year gap in my use of Macintosh. Something I did notice after my return to macOS was the absence of software due to earlier changes in the platform. An more exotic example is F-Script[1]. Not only is the project gone, but the change in the security model pretty much ensures that nothing like it will ever exist again. A more common example will be games, where only a select few will receive updates a couple of years after its release.

[1] https://www.macintoshrepository.org/25973-f-script

Apple unfortunately takes the opportunity of you compiling against the newest SDK to change and break all kinds of undocumented behaviors your app has been depending on, which almost always negotiates source code changes. If you’re lucky you’ll actually notice the changes; more than likely your app just appears more unstable and buggy to your users.

Haven’t they actually done a relatively good job in this regard in many ways? I can still use my 12 year old MacBook Air. It’s not super current and not all apps work, but it’s actually still a decent Apple experience. Same with our old iPad. They kept it updated way longer than I expected.

> It’s not super current and not all apps work

That's an enormous concession, relative to Windows or Linux.

> That's an enormous concession, relative to Windows or Linux.

Windows yes, but Linux... no, at least if it's open source.

Closed source apps that compile fully static, these tend to be stable and Just Run in my experience... but open source apps? Good luck trying to bring these to even compile 10 years afterwards without going through an insane dance with Docker...

While that's absolutely correct, you're arguing with a strawman. Take a look at the original quote:

   > I can still use my 12 year old MacBook Air. It’s not super current and not all apps work, but it’s actually still a decent Apple experience.
The point is I can run the latest Linux distributions and software on a 12 year old computer with no issues whatsoever.

You might be able to do that in Windows, if you bypass TPM and CPU requirements or if you stay with Windows 10 extended updates.

You won't be able to in macOS without OpenCore Legacy Patcher and a lot of faith in your God of choice.

Couldn’t agree with this more. Stuff I wrote 25 years ago for NT4 still actually works on windows 10 without a recompile.

The Linux situation reminds me of unix back in the 90s even across distributions.

>Closed source apps that compile fully static, these tend to be stable and Just Run in my experience... but open source apps? Good luck trying to bring these to even compile 10 years afterwards without going through an insane dance with Docker...

who cares?

when a closed source app fails the door is shut for good on self-remediation, unless you want to reverse engineer/break the law.

when an open source app fails to compile you can choose to put the time in to get the thing working. it's not a shut door, it's just a long path.

> who cares?

The problem is that most software people use for work is going to be closed source because the vendor wants to make money on these juicy business contracts.

Linux makes a point of being very difficult to be used with closed source stuff, in kernel and userland alike (getting static compilation to work is an utter PITA), and that is a reason why commercial software written for Linux is rare, and that in turn is the dominant reason why Linux adoption on the workstation has been very slow for a very long time - until a lot of business applications shifted to the browser, making the client OS platform all but irrelevant.

It’s trivial to use containerization technologies like flatpak to get software to run on any Linux distro. Companies don’t put in the effort, even though it’s much easier than maintaining deb and rpm packages.

On Linux, there aren't 'apps' that normal people want. Basic things like 'functional 1080p/4k Netflix' and 'commercial software' aren't really a thing.

Netflix works, just not 4k. Blender and Davinci Resolve say there's commercial software, just not actual Photoshop.

[deleted]

That's another goalpost. That's because DRM doesn't go well with Open source.

Correct, you have just successfully identified the reason why Windows exists. Well done!

> Haven’t they actually done a relatively good job in this regard in many ways?

No.

Can't run current versions of any apps including Chrome, Edge, and Safari.

Meanwhile the hardware is perfectly fine and could run a supported version of Windows or Linux.

Call me when Apple has a "LTSC" version of their OS. (Spoiler: they won't, ever. Supporting Apple in an enterprise is nothing short of a nightmare.)

This is partially on third-party devs' shoulders. There are community-maintained backports of Chromium and Mozilla for old versions of macOS, which means it isn't strictly impossible, but Google and Mozilla just don't bother and cut off compatibility earlier there than on other platforms.

It's even possible to build Mac apps to run on everything from OS X 10.4 (2005) through macOS 27 (2026) across PowerPC, Intel, and Apple Silicon in a single binary. See XLD[0], which does exactly that.

[0]: https://tmkk.undo.jp/xld/index_e.html

I have had to get rid of several computers recently that will not run Windows 11. They weren’t 12 years old.

Consumer electronics, what do you expect ...

Any reason to "upgrade"? I am still on Sonoma and don't see a point updating the system.

[deleted]

[flagged]