hdiutil is deprecated in macOS 27 Golden Gate
lapcatsoftware.com
lapcatsoftware.com
[1] https://github.com/tokio-rs/mio/blob/master/src/sys/windows/...
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
> https://learn.microsoft.com/en-us/virtualization/windowscont...
> Decoupling the User/Kernel boundary in Windows is a monumental task and highly non-trivial, however, we have been working hard to stabilize this boundary across all of Windows to provide our customers the flexibility to run down-level containers. Starting with Windows 11 and Windows Server 2022 we are enabling the ability to run process-isolated WS2022 containers on Windows 11 hosts.
But there's a near infinite number of things they could do; they're constantly choosing which to actually do.
AI has made my life more productive and I could use the time it's saved me to go for a run, but here I am.
So in reality, AI has not changed your productivity at all, because you are using the extra time you saved to post on HN
Something about some insider B2B deals for data centers, blah blah blah.
I expect a flood of cheap RAM, SSDs, and GPUs to hit the scene within about two years, after the AI boom goes bust.
Dealing with Apple's labyrinth maze that is Radar/Feedback is an exhausting nightmare, honestly. It leaves users intentionally blind as to the state of any FB's they raise, and (presumably unintentionally) gaslights users who attempt to improve the state of Apple's declining software products by repeatedly asking them for spindumps/sysdiagnoses that will subsequently either be ignored (sometimes for years), or re-requested in a future release.
I gave up attempting to engage with it years ago. Apple don't want technical feedback unless it's P1 security.
I understand the realities of sifting through millions of reports, but the futility of being told to report harder and fighting with UX breaking bugs does not inspire confidence in Apple’s software teams. The bugs I am referring to are interactions where an app cannot update automatically or manually if you set this one flag, or your socket never fires any callbacks if you set the one cool flag, or this view mostly always fires a callback on dismissal, but not always. Some things we can work around, with varying degrees of effort. Some we cannot. It is very clear to me that nobody tests the things we run into, for I cannot imagine how anyone would let this stuff pass into production otherwise.
I don't know what they're doing but if they think I'm going to drop $6k for the similar m6 max now doing some planned obsolescence stuff I'll never be able to prove they're out of their minds.
I've heard golden gate is much faster than Tahoe but we'll see.
Colleagues on much better spec’d M1/2/3 all noted similar, but not quite so drastic, slow downs.
The hugest issue is search appears to be universal broken. Spotlight doesn’t work, finder doesn’t work, email doesn’t work. The other day I had to login to Gmail through the web app for the first time in about 5 years to find an email I knew existed that mail decided didn’t exist.
Insult to injury is the search indexing service appears to be somewhat responsible for slowdowns. It’s right up there with the famous “windows updating in the background” slowdowns.
Brother, it’s Apple. Any backwards compatibility is purely incidental.
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.)
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.
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...
> 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.
The Linux situation reminds me of unix back in the 90s even across distributions.
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.
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.
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.
Things change but this is hardly some sort of sudden rug pull by Apple.
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.
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.
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.
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.
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/
FWIW, limited to two macOS VMs per host unless you hack it.
Nobody really cares that they were originally for separate things.
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.
Username relevant as always.