File systems seem to be a particular weakness of Apple. HFS+ is pretty terrible. APFS is better, until something goes wrong and then it's just as terrible. Add "network" and the situation is 10x worse. I recently gave up on Time Machine (via Samba) entirely because it would regularly corrupt itself and destroy all my existing backups.
But a few weeks before release, Sun was acquired by Oracle.
It was going to take months of further negotiations to nail it down. Apple-sourced ZFS on macOS was canceled.
ZFS had been released by Sun before the Oracle Situation under their MIT-like CDDL.
I suppose when Big Tech is involved, they rattle patents at one another until the dust settles with handshakes and payouts all around. I'm speculating here. But I was told that the CDDL was not considered sufficient for Apple to support its own development efforts.
ZFS is relatively complicated, but it generally works. At the time, Apple was shipping servers with iSCSI SAN and a GUI comparable to Disk Utility.
Really a shame. I was running native ZFS on my Mac Pro that summer. Eventually migrated those pools to Open Solaris and eventually to Linux.
ZFS looked promising and capable at the time. Do you have any recommendations for today?
It can feel like until there's a bit more clarity or certainty publicly, or personally running multiple backups on different file systems is the default start, which isn't always ideal.
I like storage to become, and remain an appliance.
Something is deeply broken with Samba in macOS, all Samba versions and all macOS versions.
It just never works. And just when you think it's finally reliable and has worked for a while, it breaks in new unexpected ways. Sometimes hanging the whole machine. This was with both macOS as a server and a Linux server (less issues with Linux, but still broken).
Samba isn't great on other OSs either, but not as broken as on macOS. At this point I've given up on Samba completely, and consider it something I won't use again.
Hmm interesting. Can you expand more. I've been using samba continuously on Mac for a few years now. It's been good for me so far. There is the need to reconnect every once in a while due to sleep and wake but other than that it's been consistently good
I've never relied on Time Machine as a sole format of backup. If I ever used it I made sure the Time Machine backups were sent to a non-apple storage device.
Carbon Copy Cloner was excellent at creating a bootable backup, and Super Duper seemed very serviceable too.
I haven’t had that level of issues with CIFS on Apple platforms in general.
For most of iOS 18 there was a bug where iOS and iPadOS simply couldn’t connect to Samba shares on Linux but that has since been resolved.
Apple does implement some custom functions that make CIFS (Samba or Windows based) shares less performant than Apple platform served shares in certain situations. Especially for server side copy. TrueNAS has recently patched this so that it works.
Adopting/inheriting a CIFS-backed Time Machine share is needlessly precarious.
> For most of iOS 18 there was a bug where iOS and iPadOS simply couldn’t connect to Samba shares on Linux but that has since been resolved.
Yes, exactly. That bug also affected macOS Sequoia but IIRC could be worked around (not on iOS though). And that was just the latest series of bugs, the pattern repeats itself every once in a while and it got worse after they discontinued Mac OS X Server and their own Time Capsule. Every few months something breaks.
E.g. just in March 2025, the 13.7.5 update to Ventura (last OS supporting a 2017 Mac) broke SMB filesharing for many users. There was a workaround, but it was only fully fixed in 13.7.7 four months later.
The fruit extensions are useful for performance, but don't really help with connection issues / hangs. Aside from that, the main usecase they enabled in the past was working Timemachine backups, but my long-term experiences with Timemachine over the network (with Mac OS X Server, fully supported by Apple at the time) were less than stellar and so I'm not doing that ever again either.
Overall, it's just not a level of reliability I'm comfortable with for a network filesystem implementation.
I find the other side of Samba can often have issues but updates have to be tested and managed carefully.
If/where there's hotfixes or patches needed, seeking scripts that can run when waking seem to be the only way to ensure any connectivity remains in place when opening one's laptop.
Hard agree. Apple has lost my data on multiple occasions. I resized my Time Machine partition and that silently corrupted most of my backups.
Apple is the only company that makes such terrible file systems. I have resized partitions on NTFS and EXT3 and never lost any data. Apple is uniquely terrible in terms of file systems and data integrity in general.
I didn't know about that. I don't use windows at all, but have a Synology with a bunch of drives and use it with SMB for my multiple Macs and apple devices, haven't had any larger issues and things seem to work fine. Should I be switching to NFS ?
It seems to be OK when there is plenty of free space but once Time Machine needs to prune older files it starts having problems (at least in my experience).
compared to the majority of consumer laptops, doesn’t apple have an exceptional track record on this topic?
their software-hardware design philosophy is unmatched in the consumer space i would say. the fact that the transition from intel chips to arm chips went as smooth as it did is a testament to my point.
> The disk which I have such problems with is a little unusual in that it’s partitioned into two: a small HFS+ volume, and a much larger APFS container.
So is this the actual bug then? Because I just used Disk Utility (in Tahoe) to check and repair an AFPS volume and it appeared to do the right thing, with the caveat that I had to "eject" it manually since Disk Utility complained that stuff was using it. Presumably, booting into macOS Recovery would've worked, too.
If the author's reading, is there a way we can help amplify any existing bug report(s)?
The year is useful in the title when the article provides out of date information. This isn't the case here and adding a ' (2021)' would have made the title less informative because people would assume the problem would have been fixed by now.
> The year is useful in the title when the article provides out of date information.
No, that's not the reason for the HN convention. Why would someone even submit an article with out of date information?
The reason for the convention is that "news" is generally expected to be new, so when it's not new, HN readers want to be informed of that fact, and they can react to the submission accordingly. It's a simple courtesy to readers.
This reply misses the point, because my reply was to rahimnathwani who said:
> The year is useful in the title when the article provides out of date information.
In other words, rahimnathwani was suggesting, incorrectly, that appending the year is necessary only when the article submitter knows that the article provides out of date information.
In that context, when I asked rhetorically, "Why would someone even submit an article with out of date information?" I meant why would someone knowingly submit an article with out of date information? Thus, your examples are not applicable to the debate about when an article submitter should append the year to the article title, because in your examples, the out of date information is submitted unknowingly:
> Obviously because people don't check or don't know or don't understand assume it's still valid.
Of course people unknowingly submit out of date information. If you thought I was suggesting otherwise, that's a misunderstanding of the argument.
Fun fact: it's not only submitters that append a date to an article, it's also HNers who either update directly or suggest to submitters to add it themselves _after it has been posted_.
So that's the case my comment was about (which was precisely the case of TFA, since people were discussing adding the date after it was posted).
rahimnathwani submitted the article. I personally replied to rahimnathwani, the submitter, suggesting that the year (2021) be appended after it was posted. So, your so-called "fun fact" describes the very situation that I already participated in. You're explaining something that is not only totally obvious to me already but in fact should be totally obvious to everyone, including yourself, since it occurred just a few comments earlier in this discussion thread!
Again, though, the publication date has absolutely nothing to do with whether or not the information is out of date.
Oops, didn't notice it was you who posted the suggestion.
What I was getting at, in any case, is that it sometimes the need to add the date after-the-post-is-up can arise. To that, the objection that "but who would post outdated information knowingly" is moot.
In the general case, I stand by what rahimnathwani said, that "the year is useful in the title when the article provides out of date information".
You might think "that's not the reason for the HN convention". It might not even be the canonical reason PG or whoever established the convention.
Nonetheless, it's a solid idea, and it probably should have been the reason for the HN convention to begin with.
I don't care nor have a use for a date stamp on evergreen or still relevant content. Even if it's older article or post someone posts here. I do have a use for a date stamp of a post with information that's potentially out of date, whether the OP includes one, or someone here adds it.
> What I was getting at, in any case, is that it sometimes the need to add the date after-the-post-is-up can arise. To that, the objection that "but who would post outdated information knowingly" is moot.
I am the person who asked rhetorically, why would someone even submit an article with out of date information, in the same comment where I suggested adding the date after the post is up. Thus, it was not an objection to adding the date after the post is up, and again, you've unfortunately misinterpreted the context. https://news.ycombinator.com/item?id=45324088
> I don't care nor have a use for a date stamp on evergreen or still relevant content. Even if it's older article or post someone posts here.
You're free to disagree with the HN convention. However, this is not the place to argue with it. I would recommend creating your own HN submission for that. The only reason I'm still here is to clarify my previous comments in this thread, which I believe I've done now.
History is not the same as out-of-date information.
The submitted article is not an historical review. If there was an article written explaining how Disk Utility had a bug, but the bug is now fixed, that might be interesting. On the other hand, to submit an article about a bug that no longer exists, with no explanation, would simply be misleading, out-of-date information. In this case, however, the bug still exists presently, so it's not history either.
> I did not say the submitted article was history.
I did not say that you did say that.
> I answered why someone would submit an article with out of date information.
And I explained why history is not the same as out of date information. Thus, you have not explained why someone would submit an article with out of date information.
Submitting history is fine. Submitting out of date information is not fine, and it wasn't done in this case, because the information continues to be accurate.
I did not say you said I said that. My point was it was irrelevant.
> And I explained why history is not the same as out of date information. Thus, you have not explained why someone would submit an article with out of date information.
There is nothing to explain. Some history is on topic. History includes articles with out of date information. Consider the 1st Linux announcement.[1]
> History includes articles with out of date information.
Yes, but a lot of out of date information is of no historical interest. That's the distinction I was getting at when I said that history is not the same as out-of-date-information.
What's distinctive about history is that we recognize it as history. In other words, when we take an interest in a document as historical, we don't assume that it describes the current state of affairs. Nobody is misled in that respect.
Notice that this submission has the year (1991) appended, which is all we wanted in the first place. It's simply standard practice on HN and has nothing to do with whether the information included is out of date, contrary to what rahimnathwani was arguing. Indeed, someone could publish a blog post in 2025 that includes out of date information (of no historical interest), but it wouldn't receive a (2025) label on HN, because the label is not an indicator of out of date information, just the publication year.
The windows approach seems most sustainable: best to use the OS for the core OS and add third party utils for the rest to maintain functionality, including running a few small vms to keep everything packaged up and running.
A few years back I found a bug that would make deleted photos show up in the Photos app on iPhone simply by putting transparent PNGs into the photo library. I reported it to Apple via web, no response. I called their support and talked to a very nice guy who had an in-depth conversation with me about it and even watched a video I made showing the bug. He said he was taking the issue "up the chain." About 6 months and two .x.x releases later and the bug still existed. I reported it again, no response.
So I emailed AppleInsider who did a short article about it and within two weeks another .x.x release came out and the bug was fixed.
Sadly I think this is one of the only ways to get big tech companies to take action these days. Cant tell you how many times I have read about Comcast, Verizon, etc screwing someone over and being unreasonable about it until theres an article on ArsTechnica or some similar site about it.
These companies don't care about having reliable products, they care about the average consumer having the perception that their products are reliable.
This is the reason security researchers started demanding deadlines before publishing their findings publicly. Forcing them to do damage control by publishing their dirty laundry turned out to be the best way to motivate companies to listen to reports.
Apple basically stopped working on non-BS macos features 10-15 years ago. The FDE unlock on boot ssh was literally shocking for this reason. Apple’s software priority is iOS DAU.
I needed to resize my APFS partition to install Asahi Linux.
The Asahi installer couldn't resize the partition due to some orphan inodes or something.
Rebooting into Recovery mode and using Disk Utility (GUI) and diskutil (CLI) didn't fix the issues.
But `fsck_apfs -y` did the trick. I had to first do `diskutil unlock volume -nomount` as it was an encrypted volume.
Where were you two weeks ago! Gonna try it
Rather, where were they three years ago?
Is fsck* on the floss side?
No. fsck_apfs is an Apple tool.
File systems seem to be a particular weakness of Apple. HFS+ is pretty terrible. APFS is better, until something goes wrong and then it's just as terrible. Add "network" and the situation is 10x worse. I recently gave up on Time Machine (via Samba) entirely because it would regularly corrupt itself and destroy all my existing backups.
macOS Snow Leopard almost adopted ZFS.
But a few weeks before release, Sun was acquired by Oracle.
It was going to take months of further negotiations to nail it down. Apple-sourced ZFS on macOS was canceled.
ZFS had been released by Sun before the Oracle Situation under their MIT-like CDDL.
I suppose when Big Tech is involved, they rattle patents at one another until the dust settles with handshakes and payouts all around. I'm speculating here. But I was told that the CDDL was not considered sufficient for Apple to support its own development efforts.
ZFS is relatively complicated, but it generally works. At the time, Apple was shipping servers with iSCSI SAN and a GUI comparable to Disk Utility.
Really a shame. I was running native ZFS on my Mac Pro that summer. Eventually migrated those pools to Open Solaris and eventually to Linux.
ZFS looked promising and capable at the time. Do you have any recommendations for today?
It can feel like until there's a bit more clarity or certainty publicly, or personally running multiple backups on different file systems is the default start, which isn't always ideal.
I like storage to become, and remain an appliance.
I’m managing hundreds of terabytes on (Open)ZFS in 2025. It’s as promising and capable as ever.
It doesn’t really have a stable and battle tested competitor in the FOSS arena considering its feature set.
(Of course there are things like Lustre and Glustre, but these are orthogonal solutions for different use cases.)
It's still promising and capable. Development is active and ongoing. I'm quite happy using it.
The path we've collectively chosen as an industry is to push those responsibilities further up the stack into the application layer.
No widely-deployed filesystem before or since ZFS is in the same league.
I love TrueNAS community which runs on ZFS for my NAS system.
For workstations I just use the distribution default. APFS on Mac, NTFS windows, and my Linux distro happens to use btrfs by default.
Something is deeply broken with Samba in macOS, all Samba versions and all macOS versions.
It just never works. And just when you think it's finally reliable and has worked for a while, it breaks in new unexpected ways. Sometimes hanging the whole machine. This was with both macOS as a server and a Linux server (less issues with Linux, but still broken).
Samba isn't great on other OSs either, but not as broken as on macOS. At this point I've given up on Samba completely, and consider it something I won't use again.
Hmm interesting. Can you expand more. I've been using samba continuously on Mac for a few years now. It's been good for me so far. There is the need to reconnect every once in a while due to sleep and wake but other than that it's been consistently good
I've never relied on Time Machine as a sole format of backup. If I ever used it I made sure the Time Machine backups were sent to a non-apple storage device.
Carbon Copy Cloner was excellent at creating a bootable backup, and Super Duper seemed very serviceable too.
I haven’t had that level of issues with CIFS on Apple platforms in general.
For most of iOS 18 there was a bug where iOS and iPadOS simply couldn’t connect to Samba shares on Linux but that has since been resolved.
Apple does implement some custom functions that make CIFS (Samba or Windows based) shares less performant than Apple platform served shares in certain situations. Especially for server side copy. TrueNAS has recently patched this so that it works.
Adopting/inheriting a CIFS-backed Time Machine share is needlessly precarious.
> For most of iOS 18 there was a bug where iOS and iPadOS simply couldn’t connect to Samba shares on Linux but that has since been resolved.
Yes, exactly. That bug also affected macOS Sequoia but IIRC could be worked around (not on iOS though). And that was just the latest series of bugs, the pattern repeats itself every once in a while and it got worse after they discontinued Mac OS X Server and their own Time Capsule. Every few months something breaks.
E.g. just in March 2025, the 13.7.5 update to Ventura (last OS supporting a 2017 Mac) broke SMB filesharing for many users. There was a workaround, but it was only fully fixed in 13.7.7 four months later.
The fruit extensions are useful for performance, but don't really help with connection issues / hangs. Aside from that, the main usecase they enabled in the past was working Timemachine backups, but my long-term experiences with Timemachine over the network (with Mac OS X Server, fully supported by Apple at the time) were less than stellar and so I'm not doing that ever again either.
Overall, it's just not a level of reliability I'm comfortable with for a network filesystem implementation.
I’ve had zero problem with macOS client against a Gentoo Linux samba server (with the apple extensions enabled for Time Machine, too).
Maybe your distro’s samba is out of date?
Never had a problem with Samba, though my use was modest (accessing some office shares, checking some files, etc).
I don't compile off of a Samba share for example, or do operations involving tons of small files frequently.
OS X used to use Samba, but Samba went GPL v3 so the rolled their own server implementation (smbx). The client is based on freebsd's code, I believe. https://github.com/apple-oss-distributions/SMBClient
I find the other side of Samba can often have issues but updates have to be tested and managed carefully.
If/where there's hotfixes or patches needed, seeking scripts that can run when waking seem to be the only way to ensure any connectivity remains in place when opening one's laptop.
Hard agree. Apple has lost my data on multiple occasions. I resized my Time Machine partition and that silently corrupted most of my backups.
Apple is the only company that makes such terrible file systems. I have resized partitions on NTFS and EXT3 and never lost any data. Apple is uniquely terrible in terms of file systems and data integrity in general.
I started using carbon copy cloner after the first time time machine corrupted the backup drive.
It seems quite fitting for a company which had been trying to deemphasize file management nearly since the original Mac.
Why Samba? That is not used unless you must support windows. NFS would probably better option for Linux, *inx and Mac.
I didn't know about that. I don't use windows at all, but have a Synology with a bunch of drives and use it with SMB for my multiple Macs and apple devices, haven't had any larger issues and things seem to work fine. Should I be switching to NFS ?
I wouldn't connect to SMB from Mac or Linux by choice on devices I control and could have them use another scheme.
I'd use SMB only if I had to connect to some corporate server on Windows, or if whetever system I connected to didn't support anything else.
It seems to be OK when there is plenty of free space but once Time Machine needs to prune older files it starts having problems (at least in my experience).
Samba is used for Windows support.
“Terrible” is a bit strong. If it’s good enough for John Siracusa it can’t be “terrible”.
When using Apple hardware, don't expect things to work if they're not relevant to 95% of their customers.
compared to the majority of consumer laptops, doesn’t apple have an exceptional track record on this topic?
their software-hardware design philosophy is unmatched in the consumer space i would say. the fact that the transition from intel chips to arm chips went as smooth as it did is a testament to my point.
of course, they are not perfect.
As long as you are on the happy path. If you diverge, wheels fall off.
> The disk which I have such problems with is a little unusual in that it’s partitioned into two: a small HFS+ volume, and a much larger APFS container.
So is this the actual bug then? Because I just used Disk Utility (in Tahoe) to check and repair an AFPS volume and it appeared to do the right thing, with the caveat that I had to "eject" it manually since Disk Utility complained that stuff was using it. Presumably, booting into macOS Recovery would've worked, too.
If the author's reading, is there a way we can help amplify any existing bug report(s)?
Why post this with invalid title? It should be in 2021 it was impossible…
It's still impossible. See my other comment:
(EDIT: corrected link to comment)
https://news.ycombinator.com/item?id=45322650
By HN convention, the submission title should still have (2021) appended.
The year is useful in the title when the article provides out of date information. This isn't the case here and adding a ' (2021)' would have made the title less informative because people would assume the problem would have been fixed by now.
There was no good reason to add the year.
> The year is useful in the title when the article provides out of date information.
No, that's not the reason for the HN convention. Why would someone even submit an article with out of date information?
The reason for the convention is that "news" is generally expected to be new, so when it's not new, HN readers want to be informed of that fact, and they can react to the submission accordingly. It's a simple courtesy to readers.
>No, that's not the reason for the HN convention. Why would someone even submit an article with out of date information?
Obviously because people don't check or don't know or don't understand assume it's still valid. It happens all the time.
The actual question is why would anyone even think that people would not submit articles with out of date information?
This reply misses the point, because my reply was to rahimnathwani who said:
> The year is useful in the title when the article provides out of date information.
In other words, rahimnathwani was suggesting, incorrectly, that appending the year is necessary only when the article submitter knows that the article provides out of date information.
In that context, when I asked rhetorically, "Why would someone even submit an article with out of date information?" I meant why would someone knowingly submit an article with out of date information? Thus, your examples are not applicable to the debate about when an article submitter should append the year to the article title, because in your examples, the out of date information is submitted unknowingly:
> Obviously because people don't check or don't know or don't understand assume it's still valid.
Of course people unknowingly submit out of date information. If you thought I was suggesting otherwise, that's a misunderstanding of the argument.
Fun fact: it's not only submitters that append a date to an article, it's also HNers who either update directly or suggest to submitters to add it themselves _after it has been posted_.
So that's the case my comment was about (which was precisely the case of TFA, since people were discussing adding the date after it was posted).
I'm truly baffled by this reply.
rahimnathwani submitted the article. I personally replied to rahimnathwani, the submitter, suggesting that the year (2021) be appended after it was posted. So, your so-called "fun fact" describes the very situation that I already participated in. You're explaining something that is not only totally obvious to me already but in fact should be totally obvious to everyone, including yourself, since it occurred just a few comments earlier in this discussion thread!
Again, though, the publication date has absolutely nothing to do with whether or not the information is out of date.
Oops, didn't notice it was you who posted the suggestion.
What I was getting at, in any case, is that it sometimes the need to add the date after-the-post-is-up can arise. To that, the objection that "but who would post outdated information knowingly" is moot.
In the general case, I stand by what rahimnathwani said, that "the year is useful in the title when the article provides out of date information".
You might think "that's not the reason for the HN convention". It might not even be the canonical reason PG or whoever established the convention.
Nonetheless, it's a solid idea, and it probably should have been the reason for the HN convention to begin with.
I don't care nor have a use for a date stamp on evergreen or still relevant content. Even if it's older article or post someone posts here. I do have a use for a date stamp of a post with information that's potentially out of date, whether the OP includes one, or someone here adds it.
> What I was getting at, in any case, is that it sometimes the need to add the date after-the-post-is-up can arise. To that, the objection that "but who would post outdated information knowingly" is moot.
I am the person who asked rhetorically, why would someone even submit an article with out of date information, in the same comment where I suggested adding the date after the post is up. Thus, it was not an objection to adding the date after the post is up, and again, you've unfortunately misinterpreted the context. https://news.ycombinator.com/item?id=45324088
> I don't care nor have a use for a date stamp on evergreen or still relevant content. Even if it's older article or post someone posts here.
You're free to disagree with the HN convention. However, this is not the place to argue with it. I would recommend creating your own HN submission for that. The only reason I'm still here is to clarify my previous comments in this thread, which I believe I've done now.
> Why would someone even submit an article with out of date information?
The incredulous tone of this hypothetical worries me, because I think this actually happens with troubling regularity.
> Why would someone even submit an article with out of date information?
Anything that good hackers would find interesting is on topic.[1] This includes some history.
[1] https://news.ycombinator.com/newsguidelines.html
History is not the same as out-of-date information.
The submitted article is not an historical review. If there was an article written explaining how Disk Utility had a bug, but the bug is now fixed, that might be interesting. On the other hand, to submit an article about a bug that no longer exists, with no explanation, would simply be misleading, out-of-date information. In this case, however, the bug still exists presently, so it's not history either.
I did not say the submitted article was history. I answered why someone would submit an article with out of date information.
> I did not say the submitted article was history.
I did not say that you did say that.
> I answered why someone would submit an article with out of date information.
And I explained why history is not the same as out of date information. Thus, you have not explained why someone would submit an article with out of date information.
Submitting history is fine. Submitting out of date information is not fine, and it wasn't done in this case, because the information continues to be accurate.
> I did not say that you did say that.
I did not say you said I said that. My point was it was irrelevant.
> And I explained why history is not the same as out of date information. Thus, you have not explained why someone would submit an article with out of date information.
There is nothing to explain. Some history is on topic. History includes articles with out of date information. Consider the 1st Linux announcement.[1]
[1] https://news.ycombinator.com/item?id=6276961
> History includes articles with out of date information.
Yes, but a lot of out of date information is of no historical interest. That's the distinction I was getting at when I said that history is not the same as out-of-date-information.
What's distinctive about history is that we recognize it as history. In other words, when we take an interest in a document as historical, we don't assume that it describes the current state of affairs. Nobody is misled in that respect.
> https://news.ycombinator.com/item?id=6276961
Notice that this submission has the year (1991) appended, which is all we wanted in the first place. It's simply standard practice on HN and has nothing to do with whether the information included is out of date, contrary to what rahimnathwani was arguing. Indeed, someone could publish a blog post in 2025 that includes out of date information (of no historical interest), but it wouldn't receive a (2025) label on HN, because the label is not an indicator of out of date information, just the publication year.
That link does not go to a comment.
I think he means https://news.ycombinator.com/item?id=45322650
Sad how a large company such as Apple cant be bothered to fix many reported bugs.
The windows approach seems most sustainable: best to use the OS for the core OS and add third party utils for the rest to maintain functionality, including running a few small vms to keep everything packaged up and running.
This article is from 2021. I’m curious if the problem has been addressed since then
I faced the problem today on Tahoe. See my other comment:
https://news.ycombinator.com/item?id=45322650
Reminds me of https://apple.stackexchange.com/q/311843/26185
tl;dr:
- Missing disk space can be related to a broken filesystem
- APFS tooling is currently really bad, you probably need to erase the volume and reinstall to fix any filesystem problem
... and this was in 2018 and I fear not much changed.
I've reported a trivially reproducible mmap issue that causes Darwin to spiral into locking up with no apparent reason. "Not a vulnerability".
I also reported a bug in Safari HTTP proxy handling that prevents encryption. No reply.
I provided source code, and reproduction steps for both.
Fuck Apple
A few years back I found a bug that would make deleted photos show up in the Photos app on iPhone simply by putting transparent PNGs into the photo library. I reported it to Apple via web, no response. I called their support and talked to a very nice guy who had an in-depth conversation with me about it and even watched a video I made showing the bug. He said he was taking the issue "up the chain." About 6 months and two .x.x releases later and the bug still existed. I reported it again, no response.
So I emailed AppleInsider who did a short article about it and within two weeks another .x.x release came out and the bug was fixed.
Sadly I think this is one of the only ways to get big tech companies to take action these days. Cant tell you how many times I have read about Comcast, Verizon, etc screwing someone over and being unreasonable about it until theres an article on ArsTechnica or some similar site about it.
These companies don't care about having reliable products, they care about the average consumer having the perception that their products are reliable.
This is the reason security researchers started demanding deadlines before publishing their findings publicly. Forcing them to do damage control by publishing their dirty laundry turned out to be the best way to motivate companies to listen to reports.
Apple basically stopped working on non-BS macos features 10-15 years ago. The FDE unlock on boot ssh was literally shocking for this reason. Apple’s software priority is iOS DAU.