Hacker News Reader

Comment by naaaaak | Hacker News Reader

> We would frequently run into bugs that had been reported on openradar for years without having been addressed.

In over a decade of submitting bug reports to Apple, they've only ever fixed a few of my issues. Most of my reports are easy to reproduce and test. I'm better off spending my time doing clean room reimplementations of whatever their API promises or just scrapping whatever I wanted to do than even wasting time reporting bugs.

"Radar Radar Radar" is all they ever ask. I don't care anymore. The whole process is opaque with no guarantees of a fix or a workaround; it'a unworthy of my time. They have over $100 billion in cash - about time they start testing and fixing more of their own issues.

View on HN

My general algorithm is : Q: is this problem likely to appear on HN? If YES then no need to submit radar report; if NO then problem affected user base too small to escalate radar report thus no point wasting time with submitting a radar report.

In fairness, this applies to any large company. What gets the grease is volume field reports from Customer Support, not bug reports from developers, no matter the level of detail.

I have an outstanding Radar report of a problem with the Fusion drive from at least Yosemite on; on a full SSD in the CoreStorage volume, allocating a file buffer larger than the 4GB copy partition will instantly hang the file system, effectively disabling the computer. You can't even reboot, hard power cycle is the only solution. This isn't in general a good way to create a file, but Transmission does exactly this, unfortunately.

> : Q: is this problem likely to appear on HN? If YES then no need to submit radar report

If everyone follows your algorithm then you will have efficiently implemented the Bystander Effect.

Someone still needs to submit it to HN, effectively becoming Radar for the most high-profile issues.

> They have over $100 billion in cash - about time they start testing and fixing more of their own issues.

Why would any organization with all that cash worry about fixing issues. They were showered with money in spite of those issues, so they must not matter.

So if anything, the bigger and richer they get, the less inclined they are to fix issues. Unless they perceive that there is a looming threat, and certain issues are seen as connected with it.

HFS+ in general makes my butt pucker. It's the only one that occasionally eats itself under regular use. Usually so badly that a restore from backup is the only solution.

It's not like Apple doesn't have the cash either. They could take some of the money that is trapped overseas for tax reasons and open up a field office somewhere (Ireland? China?) who's only job is to run through Radar from top to bottom and close out/fix every issue.

You're in luck, there's the new APFS in store for macOS 10.13 :)

My guess is they switch the numbering system over and call it macOS 11. There's no sign of Apple breaking from the lockstep yearly releases with iOS feature integrations, and next year is their one shot to make the version numbers line up.

Even though AppleTV nigh unto runs iOS, and you could even sort of ask the system what version of iOS-ish it is running, the version numbers for tvOS were always annoyingly not the same as iOS ones (I think always earlier by a major revision).

Let's just say that I have no intention of trusting a new Apple filesystem with important data anytime soon.

I don't think APFS does user data checksumming. It only checksums filesystem metadata, but not user data.

What do you mean by 'eats itself'? I haven't had any big issue with HFS+ since 10.3, before that only on 10.2 and OS 9.1 once.

MacOS refuses to recognise that there is even a filesystem on the drive, and if you have to do recovery it involves just scanning the remnants filesystem looking for magic numbers without any metadata (like filenames!). I've seen it happen on three different laptops now (not all mine unfortunately, mine are at least backed up!).

The recovery tools are kind of touchy too, they only work on certain versions of MacOS and are kind of difficult to track down. The only saving grace is that Time Machine is so easy to use that people sometimes actually turn it on.

Microsoft did and does today. Personally, I've submitted 6-7 bugs to them over the years, for Windows and other products, have gotten patches delivered in weeks, and rolled into a normal update roll up on 3 occasions. With a security issue, the program manager for the product called me back personally and arranged to have engineers onsite work with our folks in mitigation.

Having a support contract helps a lot. Apple doesn't really even offer that.

With one fairly epic failure from them, my employer was big enough to get a sad Apple guy to fly up and express his heartfelt sorrow. Very touching. His SE helpfully suggested that we restore our phones (15,000 of them). That was about the extent of it.

It's just their way, each vendor is uniquely obnoxious. But the unpredictability limits what you can do with their products.

Does any major desktop system have a working bug-process? Microsoft seems to respond with "reinstall and don't call us again", the various Linux distributions let the ticket wait for a few years, then mass close them with "applies to old version". Apple's "tennis with the Pacific Ocean"-response to tickets has already been widely discusses in this thread.

I mean, that is a great point. Bug fixing in general is not a sexy part of hackerdom. No one remarks about how great project X is with replying and fixing their bugs. It's like a working toilet, people only care once it no longer works.

> the various Linux distributions let the ticket wait for a few years, then mass close them with "applies to old version".

How recent is your experience, I have found this not to be really true anymore, at least for the past few years.

This is an issue in the kernel. You don't report this to the distro vendor but to the appropriate kernel mailing list. In this case the interface to user space is broken AND it's a regression, so it would be appropriate to cc: Linus. Chances are high it's fixed in the next -rc release (i.e. within a week).

Reply on news.ycombinator.com