Live data from Hacker News

Apple: No Macintosh Forks. But the iPad...

mondaynote.com

61–70 of 166 posts

Re: Apple: No Macintosh Forks. But the iPad...

#61
post #4

I don’t think the argument holds very well. Apple has made three processor architectural changes including one on the current OS. “Too complicated” doesn’t really align with the execution history Apple has. The fat binary support Apple has is a huge tool and the ability to add instructions and optimizations to their chips to help with x86 emulation is a big deal. I don’t know if Apple will ever actually do this, but…

Apple has made two transitions while retaining compatibility, in one case with emulation of the old architecture being around the speed of the previous (68k to PPC) and in the other with emulation being faster than the previous architecture (PPC to x86). There's no ARM that's fast enough to emulate an x86 in the same power envelope, so right now any transition would either require all performance sensitive apps to be ported or would result in machines that were slower for many tasks.

Bear in mind that both previous transitions were due to the processor line Apple was using being effectively EOLed (explicitly in the case of 68k, more implicitly in PPC - nobody was interested in making CPUs that had the appropriate performance/power ratio for consumer machines). Apple is doing great things with ARM, but they're not /that/ far ahead of the rest of the industry that they can pull off a seamless transition in the near future.

Re: Apple: No Macintosh Forks. But the iPad...

#62
post #4

I don’t think the argument holds very well. Apple has made three processor architectural changes including one on the current OS. “Too complicated” doesn’t really align with the execution history Apple has. The fat binary support Apple has is a huge tool and the ability to add instructions and optimizations to their chips to help with x86 emulation is a big deal. I don’t know if Apple will ever actually do this, but…

Furthermore I predict that Apple won’t treat it like a transition, rather it will be a long term dual platform strategy. They’ll encourage developers to build fat binaries and have good x86 translation support in the interim. But it’ll be long term, at least five years. Standard iMacs and MacBooks will be moved over to ARM quickly, higher-end iMacs and possibly some MBP SKUs a few years later, pro devices will stay I…

There’s definitely some common threads with this and Apple’s push to have apps use bitcode. It would make this duality a lot easier from an app distribution perspective without the need to have an emulation layer. My only guess as to why Apple hasn’t required bitcode by now is the sheer number of 3rd party libraries out there that aren’t built with bitcode enabled.

Re: Apple: No Macintosh Forks. But the iPad...

#63
post #34

Earlier quoted context omitted.

I can't help but feel T2 chip is just another cynical ploy to gradually kill off third party repairs by baking software functions into proprietary hardware that only the manufacturer have access to. It may be a sound security decision, but I have doubts whether it's worth it for the end user. It also goes against a wider industrial trend of moving from ARM to RISCV and other architectures. On the other hand, do all t…

> It also goes against a wider industrial trend of moving from ARM to RISCV and other architectures. Is this really already an industry trend? It feels more like some parties experimenting with the platform, not necessarily with intentions to move to it wholesale at any point in the future. But I'm probably missing stuff, since I'm not following that space well.

The short answer is that since RISC-V is open source, it's a bypass around all the IP restrictions that are coming from the US-China tradewar and all the Chinese silicon companies want everything to be RISC-V yesterday and it's a strategic priority.

Re: Apple: No Macintosh Forks. But the iPad...

#64
post #56
post #52

Earlier quoted context omitted.

Both times were out of necessity though.

Arguably, the necessity here would be energy consumption, thermal performance and potentially speed?

That's not really necessity unless you can show that the current values for those 3 are insufficient and that an Axx transition will produce big gains in at least 2 of those 3 areas, is it? Even if native apps compiled and written for the Axx architecture have better energy and thermal performance, what about all the x86 apps that have to be emulated? There'll be a tax for that. It could be worse. Intel-based macs are probably wasting some power that Axx would theoretically not waste, and Axx might theoretically have better thermals, but there's not some massive demand for Apple to upend the whole ecosystem like that. Does Apple have competition threatening to steal their lunch because Macbooks' battery life isn't long enough? Not really, no?

Re: Apple: No Macintosh Forks. But the iPad...

#65

> Today, I’ll contend that moving the macOs to an Axx processor is a fantasy, it’s too complicated and will never happen, at least no time soon. Mac users are wedded to x86 processors for the foreseeable future. No wonder Be Inc went belly up. Apple had switched before from architecture.

To imagine that the transition from ppc to x86 is remotely comparable to a present-day x86-to-ARM transition is utterly absurd. Basically everything has changed: Hardware architectures, software architectures, OS design, etc. The amount of software out there for x86 macs is massive and end users are going to expect all that stuff to work (even if they'll grumble and accept it when Apple tells them that only 50% of it will work). You're also having to maintain compatibility with a massive set of third party hardware used by creatives, developers and enthusiasts - are you gonna run those drivers in an emulator? In kernel mode?

This would be an undertaking beyond any past one, because in the past computers were much simpler and Apple controlled a bigger part of the picture. Now they're shipping elaborate GPUs and hardware stacks that mash together chips from various vendors and there's a ton of third party hardware and software all working on top of it. If they don't keep most of that working users won't stand for it. Something like "we need to get AMD or NVIDIA to provide us a top-tier video driver for the Axx instruction set and convince them not to demand a king's ransom for it" would not have been an obstacle in the PPC days but it's unavoidable now unless they want to ship their own GPU too (which they could do, but again, compatibility)

Re: Apple: No Macintosh Forks. But the iPad...

#66
post #62

Earlier quoted context omitted.

Furthermore I predict that Apple won’t treat it like a transition, rather it will be a long term dual platform strategy. They’ll encourage developers to build fat binaries and have good x86 translation support in the interim. But it’ll be long term, at least five years. Standard iMacs and MacBooks will be moved over to ARM quickly, higher-end iMacs and possibly some MBP SKUs a few years later, pro devices will stay I…

There’s definitely some common threads with this and Apple’s push to have apps use bitcode. It would make this duality a lot easier from an app distribution perspective without the need to have an emulation layer. My only guess as to why Apple hasn’t required bitcode by now is the sheer number of 3rd party libraries out there that aren’t built with bitcode enabled.

they are forcing notarization in the next OS-X update. this means they can eventually force bitcode.

Re: Apple: No Macintosh Forks. But the iPad...

#67

ARM on the Macbook Pro would put a lot of software shops (I'm guessing tech and design firms are the main purchasers of Macs) using Docker in an awkward spot with their containers not running on dev machines.

Those shops are deploying into Linux servers anyway, so they would be better off supporting an Linux OEM.

We use our Macs for Design (Sketch, Zepplin, Adobe), Web (via Java) and native iOS/macOS development, I am yet to hear anyone caring about docker beyond conference talks.

Re: Apple: No Macintosh Forks. But the iPad...

#68

Earlier quoted context omitted.

The only way to access the soldered-in NAND storage is through the T2 chip, which encrypts everything on-the-fly with a unique burned-in AES key. The T2 also acts as the SSD controller, controlling the raw NAND chips. You can see this in an iMac Pro teardown, as the removeable "SSDs" in it only have flash chips on them, no controller. The T2 is not involved with memory access AFAIK though. As for I/O, it does handle…

That's consolidating some controllers. It probably has more to do having fewer parts, fewer vendors, and better repair lock-in. It's not really an architectural step towards replacing the CPU--it's a southbridge with better marketing.

> It's not really an architectural step towards replacing the CPU--it's a southbridge with better marketing.

Except it locks out any OS not Windows or MacOS from using it.

Southbridge didn’t have hardware mechanisms in place to intentionally lock Linux out from using the machine’s (rather expensive) internal storage.

Re: Apple: No Macintosh Forks. But the iPad...

#69
It’s amazing to think the iPhone launched without copy and paste and now it’s a prominent feature on the iPadOS sales page.

I’m a bit happy we’re movinf back to just letting people do stuff and let the developers figure out how to make it work.

Re: Apple: No Macintosh Forks. But the iPad...

#70
post #39

Earlier quoted context omitted.

The only way to access the soldered-in NAND storage is through the T2 chip, which encrypts everything on-the-fly with a unique burned-in AES key. The T2 also acts as the SSD controller, controlling the raw NAND chips. You can see this in an iMac Pro teardown, as the removeable "SSDs" in it only have flash chips on them, no controller. The T2 is not involved with memory access AFAIK though. As for I/O, it does handle…

Seems like a distinction without a difference. On any PC with an SSD there is "a controller" and "some NAND" the difference with the recent Apple gear is they've changed which part you can remove and replace, and which you cannot. My computer also has NAND you can only address through a dedicated controller that handles the encryption, but I don't think of it as indicative of a revolution.

I don’t think anyone buying a MacBook even knows about this or is calling it a revolution.

The OP is the first I’ve heard make a big deal about this and the follow up comment is basically saying that he’s overstating the relevance to some ARM migration. I wouldn’t take random Internet comments too seriously.

Post reply on HN