Macintosh Forks
mondaynote.com
mondaynote.com
1. Much like during the PPC-to-X86 transition, Apple will need to emulate Intel x86-64 on ARM64 at reasonable speed so that legacy software will continue to function. But we haven't seen any such technology yet. (That's not to say it's impossible, just not in view at this time.)
2. Developers will instantly lose their ability to virtualize x86-64 hardware. No more Docker, no more Windows virtualization. A lot of people, particularly developers, who use the Mac today will lose significant functionality.
3. Thunderbolt is an Intel technology and only works with the x86-64 architecture. Apple will have to come up with some viable replacement for it.
2. From our perspective this is the deal breaker, but the question is how much Apple cares about us.
3. Intel has said they're opening Thunderbolt since the start, they finally donated it to the USB IF and supposedly you're seeing it on some AMD-chip motherboards now
x86 emulation is already close to a proven technology. Even though it hasn't reached real adoption yet because there is no open source version, there are some commercial offerings for Linux. Microsoft has x86 emulation built into the ARM version of Windows. I have no doubt that Apple could build a version of this as well (they probably already have).
2. With x86 emulation this point is mostly moot, although it will be slower. But then again Windows is also becoming ARM compatible.
3. Thunderbolt 3 is not Intel-exclusive. It does not only work with the x86-64 architecture. It's an open standard.
This is NOT the case with x86->ARM. Apple's ARM chips are impressive and are approaching Intel's chip in some areas if you benchmark in certain ways and ignore the areas where they fall short. I think people underestimate the gap. Maybe one day ARM while be fast enough to make switching worthwhile and emulate x86 acceptably, but it is not this day.
I would say it is more likely that Apple will end up releasing some sort of cross-CPU .NET/JavaVM-esque technology that compiles software locally if they really want to merge the product lines. But I am not even convinced that Apple wants to merge the two lines.
Probably impossible, but I wonder if something clever could be done at the microcode level (mostly) so that a core could switch instruction sets. The Apple ARM instruction set would be the native, optimized one, but the x64 IS would run acceptably.
It has the same specs of a good laptop, the type cover is sturdy (but easily replaceable in the worst case), removable for tablet use and the screen doesn't wobble a bit.
I consider it a lot more flexible (and studry, since there is no hinge to break) than a traditional laptop.
Yes, the screen could be larger.
The type cover is not only "good enough" for all but full-time use, it's also upgradeable — which I've taken advantage of — and easily replaceable in the case of damage.
As for the screen size, I agree in part…but if it were any bigger, it wouldn't fit perfectly in the back of my camera bag, which, for my purposes, is a significant benefit.
This coming from someone with a mechanical keyboard, two pointing devices (Magic Trackpad and wired, many-buttoned mouse), and a 55" 4K display on his desk.
[1] And using the Microsoft Bluetooth folder…also a surprisingly usable device given the limitations inherent in its design…as a temporary alternative.
A clamshell has better balance because of the battery and internals in the keyboard half instead of in the screen. It has better screen angles and is usually smaller and lighter than both parts of a detachable.
It doesn't work at all as a tablet though, and a touchscreen is an afterthought.
I paired a bluetooth mouse to mine on the iPadOS beta and have been using it for work for a couple of weeks. Much nicer to use than my work-supplied Surface Pro which isn't saying much, since they are awful at using on your lap).
So Mac laptops just got simpler and saner. [...]"
I would guess the analogy of "simpler and saner" would be streamlined, more homogeneous.
The term "fork" is also misleading. All what is needed is once more universal/fat binaries which work on both architectures. macOS cannot be forked in the traditional FOSS sense; there are too many proprietary components for that.
A little of history on the author, Jean-Louis Gassée, can be found here on Wikipedia [1]
This has a double meaning, because the original "fat binaries" used the resource and data "forks" to store the difference versions. In fact, I thought you had misunderstood until I checked the article.