[Raion]

macOS Big Sur just announced and it's the first to run on ARM devices, though not exclusively. I have no doubt in mind that Apple is trying to further close off their platforms. Hackintosh will soon be dead.

Let's talk about our thoughts.

[commodorejohn]

I'm honestly surprised it took them this long; I figured this was in the cards years ago. They probably could've done an iBook/Powerbook type split with consumer-level Macs running on their own ARM solutions five or six years ago and left the media-professional workstation hardware on x64 until the performance caught up.

Anyway, yeah, ever more the walled garden, sadly. I'd like to think that it at least represents a step towards breaking the x86/64 hegemony in the rest of the personal-computer market, but unfortunately everybody else's experiments with non-Intel PCs seem to be just as proprietary and locked-down as anything Apple does... :/

[Irinikus]

It may be the start of something good, as Apple will start to innovate again!

[weblacky]

As someone who's nearly finished their new macOS/Windows software product (less than a year away from functionally complete, after working on this for 6 years!), I'm trying my best not to totally freak out and break down! I'm hoping x86 emulation works for several years and I PRAY that FSF GCC catches up...and is still object-compatible with Clang (Xcode compiler version, provided by Apple) when it does catch-up. If it's not object compatible, I'll have to switch to heavily using platform dynamic libs (but that will still work for me...as long as I can link it all somehow).

See in order to write my product I couldn't use Xcode, Swift, Obj-c, etc...because none of that crap works on Windows. So the "just recompile" horseshit, won't cut it for a cross-platform developer like myself. I'm just one person (not a team of people). I can't be writing two version of the application, in two completely different languages. I choose one, and just isolated platform differences (and used wxWidgets) to have (basically 85%) common source tree. All compiled/linked by the same GCC compiler (just on different platforms) with minor differences in what compiler compiles the static libraries I use. While it's possible to program everything in C/C++. It would take a genius to do so correctly doing as much threading and communication as I have done. And I know I'd fail pretty hard/fast trying. If I didn't need to heavily thread, I wouldn't have that tooling requirement.

I hope all my MacOS work isn't ruined. An application that works great, until they pull "Rosetta 2" support (just like last time) after only two years from ARM, isn't going to go over well with users! I'm hoping that statement was misinformation. Because, If Apple Intel products and ARM products exist at the same time (same MacOS versions, overlapping), if support life isn't shortened for Intel, then to drop the support for ARM running an older Intel-only binary...when currently supported older Intel hardware on the current OS can do it, would show a divide in abilities.

The point of my application is dual platform interfacing (native binaries) with ease. So while I use the latest CLANG compiler to form MacOS specific object files, (because you can no longer compile MacOS Kernel/System/Cocoa libs with current headers under GCC, the syntax hacks in Clang are unsupported in GCC). I've been using GCC to produce the final binaries, that I link in G++ to the native LibC runtime and MacOS-only libs provided by Apple. I just (three months ago), go my build system totally off GCC standard libs for MacOS (still require the GCC basic static lib) but none of the stdlibc++ or any of that, it's all native (restricted) dynamic Clang-RT runtime provided on macOS....until now.

Now I HAVE TO HAVE a FSF GCC supporting Ada 2012 on MacOS ARM, in order to build my product Core, then link it to Clang-provided object files, I could perform several interfaces with dynamic loading and such. But I still need to compile my core code natively on MacOS ARM.

I'm really worried how long it will take before I hear anything from GCC maintainers (or AdaCore) on this topic. A year at least....I might be able to survive if AdaCore comes out with a commercial compiler...but I'd have to double-down my risk and come up with a huge amount of cash to license that compiler + support (last prices I heard were about 5 years ago and were several, tens, of thousands of dollars. Until the FSF gets the compiler commits a year later, I'm out. My application does have a usefulness as a Windows-only application. But was really only innovative with the fact that it works between Windows and MacOS with the single license and purchase (allows seamless platform usage, that was my selling point). Now I'm worried. This is either a good thing or a really bad thing...depending on my tool chain maintainer's response.


As a consumer, I'm actually very interested! If these new SOCs aren't shit, or do the "double the speed every year, buy a new Apple every year" yank job that iPhones did for a long while. I'd be a player. I wish they had given real details, but if they don't provide an HUGE core count...I'll be waiting for as long as I can before any purchase. I don't want an 8-core ARM...I want a 16/32/64 core ARM for the hassle and BS this is going through. I don't want an iPad processor (sharing same IC), the keynote mentioned the word "Family" so I assume multiple processor versions are going to be presented. If I have options, I'll feel better.

One thing that bothers me is virtualization, we all noticed the "see it's Linux, BS". Well Linux already ran on ARM...so what. As a cross-platform developer...I need both MacOS & Windows. I'd be OK with a "fairly quick" x86 emulation. I don't need to do anything but code and compile and do basic tests for my software. Anything more and I can remote into a Windows machine for full testing and whatever. But if I can't build my product for BOTH OSes on the same machine. That's a really, really, hard issue - because I could before!

If I was an up-and-running business...maybe I'd have to money for several machines and a blazing fast hosting/remote ISP where I just use a chromebook with remote desktop to develop on both platforms. But being what I am (pre-startup) and being able to build my product fully on a single machine...isn't something I'll give up without a real fight. Hopefully basic/slow but stable x86 emulation will allow slow-moving Windows installs and that would be enough.

Here's Hoping,

[jan-jaap]

The transition you knew was coming. Let's see:

1. I didn't watch the talk, but I'm going to assume they will continue to make premium laptops.

2. Let's hope the UNIX userland and the Terminal stay. That's a deal breaker for me.

3. We'll be able to run IOS apps on the MacBook. Does that mean we get a touch screen? Best Fiends on my laptop, that's going to be the end of my productivity.

[Raion]

I'll say what I say all along: macOS doesn't feel like UNIX and technically it isn't UNIX; Open Group certifications are meaningless. I stopped working in tech support so I ditched my mini, I don't need macOS anyways. I'm not into any part of the apple system, not even phones.

I've never been particularly interested in the walled garden aspect since about 2013. MacOS isn't anywhere near what I'd consider a "good" operating system, considering it is so anti-power user and 90% of it is aesthetics. Considering I'd use Windows or (gods above) GNU/Linux over it.

They only have announced an ARM powered mini thus far. I assume they'll be offering more. I didn't watch the talk but recaps didn't mention touch screens.

[Irinikus]

I’m rather excited at the prospect of huge multi-core ARM machines.

I’m still going to get the new Mac Pro as soon as economically possible, however this will be delayed due to the Onyx purchase!

For me, it’s Apple, what else?!!!

[Raion]

I didn't notice Weblacky's post, but hopefully they go about this smarter than just straight emulation. In particular, they could use a !FX32 approach like Windows on Alpha did, or they can use a binary translation layer like IBM i does.

[GeekLucanis]

There has been talk on the macrumors forums that they are bringing Rosetta back for the emulation layer. and FX!32 is used on Windows ARM as well.

[jan-jaap]

The technology behind (the original) Rosetta is the same that was used by SGI QuickTransit.

Pure emulation is very slow, so QuickTransit does some optimizations:

• First of all, it tries to run as much as possible as native code. So in the case of IRIX QuickTransit, you'd get IA64 versions of libc.so and libGL.so with it for example.
  
• Then, rather than pure emulation (like Bochs), it does a dynamic translation to the target. A bit like a JIT.
  

In the end, IBM acquired Transitive. It makes sense that Apple made a deal with them.