The 2013 trash can was the end of the Mac Pro. It was never the same after that. The 2012 and earlier Mac Pros were awesome. I had a 2010 model. Here's what I loved:
• Multiple hard drive bays for easy swapping of disks, with a side panel that the user could open and close
• Expandable RAM
• Lots of ports, including audio
• The tower took up no desktop space
• It was relatively affordable, starting at $2500. Many software developers had one. (The 2019 and later Mac Pros were insanely expensive, starting at $6000.)
The Mac Studio is affordable, but it lacks those other features. It has more ports than other Macs but fewer in number and kind than the old Mac Pro, because the Mac Studio is a pointlessly small desktop instead of floor tower.
That's when they stopped designing computers for the pro market and started selling mid-century Danish furniture that can also edit videos.
I knew it was all over when third party companies had to develop the necessarily-awkward rack mount kits for those contraptions. If Apple actually cared about or understood their pro customers, they would have built a first party solution for their needs. Like sell an actual rack-mount computer again—the horror!
Instead, an editing suite got what looked like my bathroom wastebasket.
When it was introduced, Apple said the trash can was a revolution in cooling design.
Then they said they couldn't upgrade the components because of heat. Everyone knows that wasn't true.
By the time Apple said they had issues with it in 2017, AMD were offering 14nm GCN4 and 5 graphics (Polaris and Vega) compared to the 28nm GCN1 graphics in the FirePro range. Intel had moved from Ivy Bridge to Skylake for Xeons. And if they wanted to be really bold (doubtful, as the move to ARM was coming) then the 1st gen Epyc was on the market too.
Moore's Law didn't stop applying for 6 years. They had options and chose to abandon their flagship product (and most loyal customers) instead.
The biggest issue was actually that the Mac Pro was designed specifically for dual GPUs- in the era of SLI this made some sense, but once that technology was abandoned it was a technological dead-end.
If you take one apart you'll see why, it's not the case that you could have ever swapped around the components to make it dual-CPU instead; it really was "dual GPU or bust".
Somewhat ironically, in todays ML ecosystem, that architecture would probably do great. Though I doubt it could possibly do better than what the M-series is doing by itself using unified memory.
I'll admit that while I've used the trash can but never taken it apart myself. But I can't imagine it would have been impossible to throw 2x Polaris 10 GPUs on the daughterboards in place of the FirePros.
For what is essentially a dead-end technology, I'm somewhat doubtful people would have bought it (since the second GPU is going to be idle and add to the cost massively).
the CPU being upgraded would have been much easier though I think.
Apple even in 2017 had the money and engineering resources to update or replace their flagship computer - whether with a small update to Skylake & Polaris and/or a return to a cheesegrater design as they did in 2019.
But they chose not to. They let their flagship computer rot for over 2000 days.
Aside from the GPU mess, the 2013 was a nice machine, basically a proto-Mac Studio. Aside from software, the only thing that pushed me off my D300/64GB/12-core as an everyday desktop + front-end machine is the fact that there's no economically sensible way to get 4K video at 120 Hz given that an eGPU enclosure + a decent AMD GPU would cost as much as a Mac mini, so I'm slumming it in Windows for a few months until the smoke clears from the next Mac Studio announcement.
At which point I'll decide whether to replace my Mac Pro with a Mac Studio or a Linux workstation; honestly, I'm about 60/40 leaning towards Linux at this point, in which case I'd also buy a lower-end Mac, probably a MacBook Air.
I'm in the Linux desktop / Mac laptop camp, and it works well for me. Prevents me getting too tied up in any one ecosystem so that I can jump ship if Apple start releasing duds again.
> you can say put "please verify whether it is still present" via bot before doing so. Which apple did
No, that's not what Apple did. They said, "Please verify this issue with macOS 26.4 beta 4", a very specific version, implying that they actually fixed the bug in that specific beta version (spoiler: they didn't). And I would have to go out of my way to install that specific beta just to "verify" the bug. Moreover, they gave me only 2 weeks to verify before closing the bug that they hadn't responded to at all in 3 years.
They suddenly created artificial urgency for no apparent reason.
> But the mistake OP is making is assuming this one thing that annoyed him somehow applies to the whole Apple org. Most issues were up to engineers and project managers to prioritize, every team had their own process when I was there.
Except this same shit keeps happening with multiple teams.
Judging from your mention of QuickDraw, which was removed entirely from macOS in 2012, perhaps your Apple experience is now out of date.
> That the ~50000 engineers at Apple are conspiring to close your tickets in the exact same way. It's ridiculou
It's pretty clear from experience that the organization policy is to not provide feedback on bug submissions. Getting a 'check it if still reproduces or we'll close it in two weeks' message after 3 years is actually a fast turnaround.
Best I've gotten was on an issue I routed to a friend who worked at Apple who promised it would get looked at, but that I wouldn't hear back.
Microsoft wouldn't fix my issues either, but at least they got back to me in a timely fashion. Usually telling me it was a known issue that they weren't going to fix.
You don’t hear back because almost always your bug is a duplicate of some other one. They can’t share the original with you because it contains data from another customer or from inside the company.
Almost nobody is the first reporter in an OS with billions of users. The only useful thing about those long dupe lists was being able to scan them for one with easier repro steps.
But sometimes that duplicate marking is wrong or some subtly different issue so they ask you if it still reproduces in whatever version contains the fix before closing it.
That makes sense. But when you take 3-5 years to respond to my bug report, I'm going to take at least 3 months to respond to your response. And I'm probably not filing more bugs, because chances are I won't be at my current employer by the time you reply.
When you consitently burn bug reporters, sooner or later there's nobody to file bugs.
Because that's probably how long it took for someone to prioritize it.
Even if it's not fixed by the dupe ticket, the volume of bug reports makes it almost certain another ticket for the same issue will come up. And if it doesn't then it probably wasn't that relevant to anyone.
Not my tickets specifically. I don't think they're out to get me individually. On the contrary, this is a common practice, which affects many developers. I just happen to be relatively loud, as far as blogging is concerned.
Yes I understand that. ~50000 engineers aren't conspiring to close all tickets that way. It's a stupid line of thinking.
More than likely your steps to reproduce are too laborious to receive attention relative to the value fixing the bug would provide. That's why they're asking you to verify it still happens. Seems pretty simple right?
There's also a strong chance your ticket was linked as a duplicate of some other issue that was fixed in the beta and they want you to verify that's the case but they won't expose their internal issue to you for a variety of reasons.
> ~50000 engineers aren't conspiring to close all tickets that way.
I didn't say that either. It's happened to me only sporadically, but multiple times.
I agree with you that teams within Apple manage their own tickets. Perhaps some individual teams are declaring bug bankruptcy at some point, so only their bugs would go out for verification. I don't really know. I wish I did. What I do know is that multiple teams have done this at different points.
There's indisputably a company-wide DevBugs canned response for this. It's the same exact language every time. You can even Google it.
> If you demand that I work with some ancient version, I then have to install and uninstall said program every time I work on your ticket specifically.
You completely missed the point of the blog post. Apple was in the process of developing macOS 26.4 beta 4, and they wanted me to install the beta just to "verify" the bug.
Apple could test my bug with 26.4 beta 4 a heck of a lot easier than I could. Nobody was asking Apple to install some ancient version.
> my effectiveness is measured by how many tickets I close.
That was one of the points of the blog post: this is a perverse incentive from management.
Note what you did not say: "my effectiveness is measured by how many bugs I fix." So engineers are incentivized to close tickets even if the bugs they report are unfixed. This is how a company ends up with crappy, buggy software.
The parent comment is talking about the broader practice of people telling you to update and then repro again. That's a completely legitimate thing to ask, given both the perverse corporate incentives and the basic reality that version toggling makes a tech far less efficient at solving all tickets, not just yours.
Apple did not say they couldn't reproduce it. Neither did they say that they thought they fixed it. They refused to say anything except "Verify with macOS 26.4 beta 4".
> and even if they are 100% reproducible for the user, it's not always so easy for the developers
It's not easy for the user! Like I said in the blog post, I don't usually run the betas, so it would have been an ordeal to install macOS 26.4 beta 4 just to test this one bug. If anything, it's easier for Apple to test when they're developing the beta.
> the most "efficient" thing is just to ask the user to re-test.
Efficient from Apple's perspective, but grossly inefficient from the bug reporter's perspective.
> realistically I can't really do anything with it
In this case, I provided Apple with a sample Xcode project and explicit steps to reproduce. So realistically, they could have tried that.
I suspect that your underlying assumption is incorrect: I don't think Apple did anything with my bug report. This is not the first time Apple has asked me to "verify" an unfixed bug in a beta version. This seems to be a perfunctory thing they do before certain significant OS releases, clear out some older bug reports. Maybe they want to focus now on macOS 27 for WWDC and pretend that there are no outstanding issues remaining. I don't know exactly what's going through their corporate minds, but what spurred me to blog about it is that they keep doing this same shit.
> Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.
I'm not going to lie. That's not who I am. If Apple really wants to close a bug report when the bug isn't fixed, that's on their conscience, if they have one.
reply