Pegatron likely to land new MacBook orders from Apple, say sources
macrumors.com
macrumors.com
Actually, maybe dymamic binary translation wouldn't be needed all that often. A new Rosetta would likely also be helped out quite a bit by the fact that modern macOS binaries contain embedded copies of their their LLVM intermediate representation; you could transpile that IR (by patching Intel-targeted intrinsics with ARM polyfills) and then run it through the LLVM optimizer again, and then cache the result. That's a fully static binary translation, and the resulting binaries would probably be pretty fast.
(You'd still need dynamic binary translation for anything with its own JIT, but maybe there are few enough programs with their own JITs—and all such programs are "big" enough in terms of development resources—that Apple can require these to ship an ARM target. In which case, maybe they don't need to build a new dynamic binary translation component at all!)
You might want to go look at Apple's history at how they managed to pull off two of the largest CPU transitions in history almost effortlessly. It's called fat binaries or in Apple's world, universal binary (https://en.wikipedia.org/wiki/Universal_binary).
You don't need to ship two separate copies, you just include a target and Xcode will give you a single copy that works on two separate platforms.
In addition, Microsoft is also going through the same phase with their own ARM branch of Windows 10.
On the other hand, although the ISA is public, I'm guessing the whole boot-process & platform will become more and more closed as apple moves towards custom chips all the way down.
Is there any chance you can still run linux on mac hardware in 5 years ?
Maybe they go to three architectures in the app store, or maybe they only support ARM after 32 bit is dead. Which works out nicely with the recent deprecation of 32 bit apps.
Also, given the Intel OS X project was cooking long before they announced the transition, it’s likely safe to believe that full blown OS X on ARM is already running somewhere in a lab at Apple.
No idea where all the creative types will go if that happens. Apple could indeed be shooting themselves in the foot on this one.
You make a very good point. The dominance of x86 is largely because it forms the long-standing open PC platform, which while Apple and others have been trying to remove "legacy" features from and lock down for a long time, still remains quite well-documented and open in comparison to smartphone/tablet SoCs that have next to no detailed public documentation at all.
Do we open Terminal and go to `brew install` a bunch of development tools... and then it hits us... this machine is cool and all, but half the stuff we need to get work done does not build or run on arm64?
I may have also spoken imprecisely. Ultimately what I mean is this: I can copy a binary or a package compiled for Ubuntu, Debian, RHEL, what-have-you, targeting the Linux kernel, and I can run or install that in Windows Subsystem for Linux as is.
Here is the sources.list from Ubuntu 18.04 on Windows, with comments removed:
deb http://archive.ubuntu.com/ubuntu/ bionic main restricted
deb http://archive.ubuntu.com/ubuntu/ bionic-updates main restricted
deb http://archive.ubuntu.com/ubuntu/ bionic universe
deb http://archive.ubuntu.com/ubuntu/ bionic-updates universe
deb http://archive.ubuntu.com/ubuntu/ bionic multiverse
deb http://archive.ubuntu.com/ubuntu/ bionic-updates multiverse
deb http://archive.ubuntu.com/ubuntu/ bionic-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ bionic-security main restricted
deb http://security.ubuntu.com/ubuntu/ bionic-security universe
deb http://security.ubuntu.com/ubuntu/ bionic-security multiverse
No special sauce. Just Ubuntu packages.It would be a big job, but much of the software on Homebrew is already ARM compatible, and I think there’s a clear path to supporting that, which should make the migration relatively seamless for most developers I’d imagine.
It won’t be without issue, but I don’t think it will hurt macOS as a development OS much in the long run.
Maybe Adobe will finally take Linux seriously if that happens.
The upcoming ARM A67 SoC evolution is expected to be behind Apple soon to be two year old chip: https://www.anandtech.com/show/12785/arm-cortex-a76-cpu-unve...
The term "modified OS X" makes it sound hybrid, but I don't see space in apples line for something between a Mac and an iPad.
There's not technal reason to not go with full macOS. It's Unix and it runs on ARM.
Intel's CPU limitations are at the heart of most of the complaints about Apple's computer line (power vs performance tradeoffs).
Apple will always choose thin (poor heat dissipation) over fast.
Is anyone doing OSX development? Is Apple collecting the LLVM intermediate code for OSX apps like they do for iOS? Its been a few years since I've done OSX/iOS dev, I could be off base. But it has often occurred to me they could use the intermediate code to retarget apps to different
I think this would be a great time for Adobe to partner with Canonical as a supported platform for Creative Suite. With improved funding and work towards getting NVidia and AMD support top of line.
It's not nice for those with unsupported software bit I don't see this holding back Apple.
The actual numbers can be sliced and diced different ways of course, but by any accounting the Mac is small compared to Windows and Linux is much smaller than that. I just don't see the economic motivation for companies like Adobe, particularly when you add in the diversity of Linux versions that would have to be supported. Whether or not Adobe can generate working code on a platform is only a small part of the cost of releasing on that platform. Don't hold your breath...
https://en.wikipedia.org/wiki/Usage_share_of_operating_syste... https://www.statista.com/statistics/670172/united-states-ins...
It could be an opportunity for Adobe, if they played their cards right.
p.s. Please don't be abrasive when posting here. It's against the site guidelines (https://news.ycombinator.com/newsguidelines.html).