Live data from Hacker News

hdiutil is deprecated in macOS 27 Golden Gate

lapcatsoftware.com

61–70 of 106 posts

Re: hdiutil is deprecated in macOS 27 Golden Gate

#61

Earlier quoted context omitted.

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…

> 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

Re: hdiutil is deprecated in macOS 27 Golden Gate

#62
post #45
post #38

Earlier quoted context omitted.

diskutil is for disks (e.g., volumes) while hdiutil is for disk images ("file system as a file"). They're not two versions of the same thing, so it doesn't make sense to dub deprecating hdiutil as "progress."

The former has been taking the latter’s job for years now. Nobody really cares that they were originally for separate things.

What are you talking about? You can't operate on disk images with diskutil outside of the few commands diskutil image gives you. For example, if you need to check whether or not a disk image is encrypted, you can use hdiutil info and hdiutil isencrypted. If you use diskutil image info, you may be prompted for a password, which doesn't make sense to handle in a program.

A disk image is not just a fancy disk. Disks and disk images operate on different planes, which is why the distinction between diskutil and hdiutil exists.

Re: hdiutil is deprecated in macOS 27 Golden Gate

#63
post #60

I like how the $4.5T company can’t pay for the 100 engineering hours a year to maintain this, or just fork over the Claude tokens to do it, while they keep telling us how productive AI is making them (which, to be clear, has indeed made me a lot more productive).

The greed is as endless as the earth is old.

Re: hdiutil is deprecated in macOS 27 Golden Gate

#64
post #4

Earlier quoted context omitted.

Agreed. seatbelt/sandbox-exec has been “deprecated” for many, many years yet it still underlies all of the system’s sandboxing and Claude et al. use it for their own sandboxes. (And so do I — writing seatbelt rules is the only chance I get to write lisp-flavored anything these days.)

This is only tangentially related, but libuv and mio's Windows implementations use the undocumented AFD readiness-based poll interface [1], since there isn't a documented readiness-based interface on Windows. The undocumented interface is now effectively stable since, among other reasons, Microsoft uses Tokio in some of its products. [1] https://github.com/tokio-rs/mio/blob/master/src/sys/windows/...

libuv does all sorts of shenanigans, like using the undocumented fields in STARTUPINFOW the CRT uses to pass file descriptors to processes inheriting handles so that you can open whatever file descriptor you need in your children processes like in POSIX

But Microsoft kind of expects this crap and will support it until the end of time; Apple can't give a crap until and will readily break programs even when they use legal APIs

Re: hdiutil is deprecated in macOS 27 Golden Gate

#66
post #61

Earlier quoted context omitted.

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…

> 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 case…

x86 translation will be slimmed down but remain for compatibility with the Game Porting Toolkit[0]. Their reasoning is likely that they want to limit the set of libraries that they ship x86 slices for as much as reasonably possible because each supported architecture multiplies surface area across the entire system.

It’s also notable that virtualizing macOS on macOS has now been officially supported and easy for several years, so it’s possible to just spin up a VM running an old version of macOS for software that requires Rosetta. Some kind of containerization probably isn’t a bad idea in that situation anyway, as software that’s gone so long without updates likely carries a number of vulnerabilities.

And on that note, the highly permissive state of desktop OS security as it had been for the 2000s and 2010s was never going to last. It’s been proven repeatedly that third party software must be treated adversarially, both because the big guys like Adobe can’t be trusted to keep their fingers to themselves and the little guys and FOSS projects sometimes fall victim to supply chain attacks. The OS must try to limit the blast radius where possible.

[0]: https://developer.apple.com/games/game-porting-toolkit/

Re: hdiutil is deprecated in macOS 27 Golden Gate

#69
post #5

> 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.

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.

Your comment is irrelevant because your MBA left support eras ago and is riddled with bugs and security vulnerabilities at this point.

Apple also does a poor job at long term software support or granting users the ability to run Linux, especially the newer the systems get.

Post reply on HN