Rendered at 20:10:44 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
nrabulinski 1 days ago [-]
Given xip has been deprecated for a long time now, yet still is the format Xcode is distributed in, I highly doubt hidutil will ever disappear from macOS. Apple just won’t really update it anymore, just like they haven’t changed xip (not like hidutil has seen any significant changes, but still)
bbatsell 1 days ago [-]
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.)
sunshowers 23 hours ago [-]
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.
> 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.
qalmakka 21 hours ago [-]
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
24 hours ago [-]
dieulot 1 days ago [-]
Similarly, launchctl has long-deprecated subcommands. I initially tried using the new subcommands, ran into issues, and told myself I should have known the “deprecated” ones were the way to go, now and forward.
oefrha 21 hours ago [-]
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).
akerl_ 19 hours ago [-]
"can't" here isn't really the right word. They obviously could, in the same way that a company making $4.5 million could.
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.
dosisking 16 hours ago [-]
> 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
akerl_ 7 hours ago [-]
That was the joke, yes.
ranger_danger 14 hours ago [-]
Whose to say that more HN posting isn't more productive? /s
altairprime 16 hours ago [-]
Refusing to maintain something isn't some sort of 'poorness signal', it's a wealth-neutral choice that could have any number of contextual drivers. Apple may not be eligible for 'too poor to maintain it' but invalidating one potential motivation leaves many others unaddressed and offers no useful argument against removal.
a012 19 hours ago [-]
Not working in a $4.5T company but often I found that people rather don’t _want_ to maintain the code than can’t
compiler-devel 21 hours ago [-]
The greed is as endless as the earth is old.
Shank 16 hours ago [-]
Is it also not greedy to demand virtually unlimited support from companies? Why should Apple spend money on this random utility that virtually nobody uses?
saagarjha 14 hours ago [-]
Because I use it and pay them money for that?
xethos 12 hours ago [-]
Yes, you've made the right call trusting Apple with this, the company with famously-good backwards-compatibility and long-lived support for third-party software /s
uinibubhb 19 hours ago [-]
[flagged]
binaryturtle 23 hours ago [-]
So I guess ram disks are deprecated too? (AFAIR hdiutil was the only way to create them)
plorkyeran 23 hours ago [-]
This is one of the things the new `diskutil image` subcommand mentioned in the article supports: `diskutil image attach ram://${size}m`.
anonymousiam 19 hours ago [-]
RAM itself is deprecated. All the new systems have about one fourth of the RAM they had two years ago.
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.
lukeify 23 hours ago [-]
> Yes, Apple requested an iOS sysdiagnose for a macOS bug
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.
eptcyka 9 hours ago [-]
We’ve received many an email urging us to reach out to Apple via Feedback Assistant. We of course have, multiple times. We’re told that we will strike gold if we just resubmit a bug report to some other part of the company. Yet, the APIs are still broken, and break again with new releases. Sometimes they get back to us to clarify something, often they do not. Some things have been fixed, most have not.
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.
kibwen 22 hours ago [-]
It's just not worth it for individuals to volunteer their time for the benefit of the world's most valuable company.
jstsch 1 days ago [-]
Was the error visible somewhere through Console.app? This is a major annoyance for me with Cocoa/AppKit apps that basically have terminal usage secondary.
StilesCrisis 23 hours ago [-]
"Despite giving Apple 100% reliable steps to reproduce, they asked me if the issue still occurred in the latest beta, and if it does, then I should submit an iOS sysdiagnose." No one looked at your repro steps, and no one researched your bug. They're just looking to cull the bug list. If you don't respond immediately, your radar is closed.
boredatoms 23 hours ago [-]
Gotta pump those metrics for the PMs
natbro 22 hours ago [-]
smells more like an auto-respond or ai-respond to extant issues. we will farm out reproducing this bug to the OG, both to save us time and because if they don't complain it must be a signal this isn't important anymore.
StilesCrisis 21 hours ago [-]
This pattern predates AI. It's just something they do with all idle radars when new OS releases launch. The fact that it was bucketed under iOS means they did literally zero investigation.
22 hours ago [-]
dreamcompiler 22 hours ago [-]
Sometimes I almost believe there are whole sections of the Apple Ring building where the employees are so immersed in IOS that they're unaware MacOS exists.
miniBill 13 hours ago [-]
I understand that your comment is meant as a joke but... all the people working on iOS use macOS daily. On their Mac. That they work on.
23 hours ago [-]
DrJokepu 1 days ago [-]
> 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.
detourdog 24 hours ago [-]
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.
II2II 23 hours ago [-]
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.
cosmic_cheese 22 hours ago [-]
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.
philistine 22 hours ago [-]
Yeah, Apple is very weary of breaking user functionality. They'll just break your app's ability to run.
cosmic_cheese 22 hours ago [-]
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.
II2II 21 hours ago [-]
> 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.
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.
> It’s also notable that virtualizing macOS on macOS has now been officially supported
FWIW, limited to two macOS VMs per host unless you hack it.
mrtesthah 22 hours ago [-]
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.
steve_adams_86 1 days ago [-]
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.
VCFundedGenYer 19 hours ago [-]
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.
steve_adams_86 18 hours ago [-]
The comment is a question; I’m not sure why one answer or another would make it irrelevant.
cindyllm 19 hours ago [-]
[dead]
bigyabai 24 hours ago [-]
> It’s not super current and not all apps work
That's an enormous concession, relative to Windows or Linux.
mschuster91 24 hours ago [-]
> 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...
doodlesdev 23 hours ago [-]
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.
cavem0nkey 23 hours ago [-]
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.
serf 22 hours ago [-]
>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.
mschuster91 22 hours ago [-]
> 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.
preg_match 21 hours ago [-]
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.
select1 24 hours ago [-]
[flagged]
deathanatos 18 hours ago [-]
I play a number of commercial games on Linux. The best behaved ones are the native ones (Factorio, Stardew, Celeste), though the Proton/Wine-based ones (Noita, Enter the Gungeon) usually do alright as well.
Netflix's problem is Netflix's problem. There is no technical reason why 1080p (and probably 4k) can't work on Linux, today. That's just plain ole head-up-DRM-ass, and Linux can't fix stupid.
select1 1 hours ago [-]
[dead]
bel8 24 hours ago [-]
That's another goalpost. That's because DRM doesn't go well with Open source.
fragmede 24 hours ago [-]
Netflix works, just not 4k. Blender and Davinci Resolve say there's commercial software, just not actual Photoshop.
23 hours ago [-]
bigyabai 24 hours ago [-]
Correct, you have just successfully identified the reason why Windows exists. Well done!
pudgywalsh 1 days ago [-]
> 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.)
cosmic_cheese 22 hours ago [-]
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.
Command-line tools are fine like this; a full-fledged GUI apps, not so much on account of how Cocoa/AppKit/UIKit evolved. Your x86_64 slice would have to deal with all shenanigans between 10.7 and 26, and I suspect it’s not fun at all.
cosmic_cheese 4 hours ago [-]
It's certainly more challenging for user-facing apps with UIs, but still doable. XLD does it. The key is to keep the UI simple, avoid chasing design trends, and avoid custom widgets.
jtbayly 22 hours ago [-]
I have had to get rid of several computers recently that will not run Windows 11. They weren’t 12 years old.
amelius 22 hours ago [-]
Consumer electronics, what do you expect ...
24 hours ago [-]
varispeed 23 hours ago [-]
Any reason to "upgrade"? I am still on Sonoma and don't see a point updating the system.
kdkdkwjfkw 1 days ago [-]
[flagged]
user19282 1 days ago [-]
I read this as hidutil and had a mini heart attack.
VCFundedGenYer 20 hours ago [-]
Of course, right as I discover this tool and start using it to make ISO files, it's deprecated.
delduca 23 hours ago [-]
Rosseta too
trueno 12 hours ago [-]
this ones gonna fuck me up. i actually think this one is going to destroy some goodwill, it specifically is worth maintaining...forever. and they have the resources to do it.
swozey 19 hours ago [-]
Been raving about my $3500 2021 (maybe 2020) m1 max 64gb outlasting the Windows x86 laptops I'd probably have replaced 2 maybe 3 times by now, but it absolutely feels slower this year to the point I reinstalled macos for the first time.
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.
fps-hero 19 hours ago [-]
Tahoe has destroyed macOS performance. I’m running a maxed out last gen intel and was getting stuttering and slide showing straight out of the update. It was completely unusable until I turned on reduced transparency.
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.
sleepybrett 19 hours ago [-]
could his root owned file problem be solved with a heaping helping of sudo?
pudgywalsh 1 days ago [-]
Pepperidge Farm remembers when they removed the Telnet client (and ntpd, and a half dozen other things) from the OS and didn't warn anyone.
select1 24 hours ago [-]
Totally normal. March of progress. Old stuff goes away.
KlayLay 23 hours ago [-]
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."
Klonoar 22 hours ago [-]
The former has been taking the latter’s job for years now.
Nobody really cares that they were originally for separate things.
KlayLay 21 hours ago [-]
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.
doodlesdev 23 hours ago [-]
If diskutil actually did everything OP looks for that was available in hdiutil, that's correct. If you read the post though, you'll see that diskutil has many limitations compared to its predecessor.
applfanboysbgon 22 hours ago [-]
Progress is when we make things worse just because we can.
Username relevant as always.
stasomatic 22 hours ago [-]
[flagged]
oefrha 19 hours ago [-]
Great, let’s deprecate everything never used by stasomatic, that will give us a much leaner OS.
uinibubhb 19 hours ago [-]
[flagged]
lapcat 18 hours ago [-]
> It's in vogue to rag on Apple because of its size/influence/market cap.
Article author here. I've been a Mac developer and blogging about the Mac since 2006, before iPhone was even announced, when Apple was much smaller in size/influence/market cap. Nothing about my blog is "in vogue".
> I've used hdutil perhaps never.
Why are you commenting on an article about hdiutil, which you've never used and can't even spell?
And why would you think that a technical comparison of the hdiutil and diskutil command-line utilities would be an effective way to "rag" on Apple? I use hdiutil every day, so that's why I'm concerned.
stasomatic 9 hours ago [-]
Hi lapcat, apologies, I meant no disrespect to you in my comment. I had a knee jerk reaction to what seemed to me "another Apple bad" post and exercised bad judgement. Cheers.
lapcat 8 hours ago [-]
Thank you. I appreciate the comment.
It's just frustrating that knee-jerk reactions are ubiquitous in the Hacker News comments, on every popular submission, despite the site guidelines urging the opposite.
stasomatic 8 hours ago [-]
In my case, this forum is habit forming to engage in the comment section. If a post has enough comments, to me it signals it's an interesting topic, never mind if I don't know anything about the subject matter, there might be very smart folks sharing knowledge. Comments can veer wildly off the original topic and I find that also appealing. This is "unfair" to the submitted post, of course, but ... HN is still here.
Now back to hdiutil.
lapcat 6 hours ago [-]
> Comments can veer wildly off the original topic
I'm not complaining about tangents, though, but rather about dismissive insults. A tangent is a conversation starter, whereas a knee-jerk dismissal is a conversation stopper.
UqWBcuFx6NV4r 21 hours ago [-]
[flagged]
haunter 1 days ago [-]
[flagged]
kdkdkwjfkw 1 days ago [-]
[flagged]
bigyabai 24 hours ago [-]
I don't think they're wrong. Apple is very open about their desire to depreciate legacy tech like OpenGL and HFS to promote proprietary alternatives.
There's a perennial churn of "Apple depreciated my favorite feature!" (I used to be one of them) and most of those people (including myself) eventually accept an alternative.
fragmede 24 hours ago [-]
It's not like ifconfig and sysvinit are well supported in Linux these days. I mean, you can, but let's not pretend that things never ever change (eg systemd and Wayland) on Linux either. Can I get non-interger display scaling yet?
sunshowers 24 hours ago [-]
> Can I get non-interger display scaling yet?
I'm using 1.25 scale on Niri + DMS right now, on a dual 4k monitor (G9 57) at 240Hz. Probably the most demanding single monitor setup right now.
[1] https://github.com/tokio-rs/mio/blob/master/src/sys/windows/...
> 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 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
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.
Brother, it’s Apple. Any backwards compatibility is purely incidental.
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.
[1] https://www.macintoshrepository.org/25973-f-script
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.
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.
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...
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.
Netflix's problem is Netflix's problem. There is no technical reason why 1080p (and probably 4k) can't work on Linux, today. That's just plain ole head-up-DRM-ass, and Linux can't fix stupid.
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.
[0]: https://tmkk.undo.jp/xld/index_e.html
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.
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.
Article author here. I've been a Mac developer and blogging about the Mac since 2006, before iPhone was even announced, when Apple was much smaller in size/influence/market cap. Nothing about my blog is "in vogue".
> I've used hdutil perhaps never.
Why are you commenting on an article about hdiutil, which you've never used and can't even spell?
And why would you think that a technical comparison of the hdiutil and diskutil command-line utilities would be an effective way to "rag" on Apple? I use hdiutil every day, so that's why I'm concerned.
It's just frustrating that knee-jerk reactions are ubiquitous in the Hacker News comments, on every popular submission, despite the site guidelines urging the opposite.
Now back to hdiutil.
I'm not complaining about tangents, though, but rather about dismissive insults. A tangent is a conversation starter, whereas a knee-jerk dismissal is a conversation stopper.
There's a perennial churn of "Apple depreciated my favorite feature!" (I used to be one of them) and most of those people (including myself) eventually accept an alternative.
I'm using 1.25 scale on Niri + DMS right now, on a dual 4k monitor (G9 57) at 240Hz. Probably the most demanding single monitor setup right now.