I believe it was the first RISC that Apple prototyped building a Mac around, including a 68K emulator. IIRC from Gary Davidian’s CHM oral history, it was corporate dealmaking that led to AIM and PPC more than any technical negatives for the 88K.

https://computerhistory.org/blog/transplanting-the-macs-cent...

Yeah, this is probably closest to the right answer. Apple DID choose the 88K, and then changed. Reportedly they put some 88K systems in a Mac chassis.

I do wonder what the exact reasons were. Maybe the PPC (complete systems) could be made cheaper? Maybe Apple was worried about relying on a single vendor? I am kind of skeptical of the “corporate dealmaking” angle, because it seems like there are valid technical reasons to NOT choose the 88K. Namely, that it requires companion chips, and the whole system (board + chips) ends up being complicated and expensive.

The report says it broke when updating from macOS 15 to 26, so not a minor patch update. I'm a bit surprised no one noticed this earlier though, since 26 has been out since September and in beta since June.

AppleScript doesn’t have any NeXT heritage, it comes entirely from classic MacOS (debuted in System 7.1)

Sure, but you can feel some emergent philosophies that are starting to converge and there are recognizable aesthetics.

This leak has been floating around for years, and it's not even close to everything (i.e. no GUI pieces)

Apple is shipping code built with this, and is supporting it for developers to use (see https://developer.apple.com/documentation/xcode/enabling-enh...)

Huh? They're all linked from https://support.apple.com/en-us/102662

"Use a web browser for older versions" was not working for me the other day, though I now cannot remember if it was when I was dealing with a Safari version with old/unusable SSL. I was able to load the webpage, though, so SSL was working there, and therefore something was different about the download links than the page itself.

CarPlay supports that, the car just needs to pass it through. I believe Ford and Toyota both do.

The original article is here, and it unfortunately is just as confusing: https://www.reuters.com/business/intel-ceo-says-company-will...

Of course Intel has been designing and selling GPUs for years, I guess Lip-Bu means they're going to start manufacturing them as well? Or they're going to be data-center focused now?

Since he was touting that they recently hired a well-known GPU architect, it seems unlikely that this is merely about them using their own fabs for discrete GPUs instead of having integrated GPUs being the only ones they fab themselves. Some kind of shift in product strategy or reboot of their GPU architecture development seems more likely, if there's anything of substance underlying the news at all.

But this news is somehow even less comprehensible and believable than usual for Intel, whose announcements about their future plans have a tenuous connection to reality on a good day.

Are you talking about Starliner? Starliner's 2 flights have been problematic to say the least, but Orion's single (uncrewed) flight went pretty well.

And Lockheed and Airbus are the prime contractors on Orion, not Boeing.

Yeah, totally borked that one up. Apologies to the Orion team for erroneously tagging them with Boeing's baggage.

Various anticheat/DRM schemes actually do direct syscalls on Windows, so Proton has patches that use seccomp to trap them and jump to the intended Nt* syscall. There was actually a feature added to the Linux kernel a few years ago (syscall user dispatch) so that Wine could stop using seccomp for this, but Wine is still not using it.

Upstream Wine also supports direct syscalls on x86_64 macOS. macOS syscall numbers have a high bit set, so Windows syscall numbers (0 to ~300) are invalid macOS syscalls, that triggers SIGSYS, and then Wine jumps to the Nt* syscall.