Competition is great, but this also seems like a rather big setback to the goal of having multi-cloud applications, in instances where the app can only run on x86-64.
Writing architecture-specific code is what would be a setback to that goal. Either write portable code, or be prepared to translate non-portable parts to new CPUs from time to time.
Of course, which is sort of the point: ARM is way behind with Linux packaging and distribution. Every vendor has their little tarball of junk that runs on their SoC or device or whatever. There's no architecture-unified distro you can install on everything. And this is where it gets hurt, because while Raspberry Pi can get away with handing out tarballs, no one is going to bet a datacenter install on anything other than RHEL or Ubuntu or whatever.
Debian and Ubuntu have had ARM ports for years. Prospective server vendors will need to address the driver situation but once you've booted the userland is highly portable.
Fedora has too, I believe. But that's sort of missing the point. Userspace ports got done years ago because they're the easy part. The hard part is the system integration that you sweep away as a "driver situation" to be dealt with by "vendors".
And so far there's no significant entry here for the ARM world. So you can't roll up a server install or Docker container that isn't, fundamentally, a hacked up tarball from some random vendor. And the market doesn't trust that.
The post I was replying to was explicitly talking about distributions, packaging, etc. I wasn't saying that there are no problems but disagreeing with the assertion that the problem is higher-level rather than lower level.
As for sweeping anything away, it's true that there's work involved but it's not like we're starting from scratch in 1985. There's a lot of industry experience supporting new hardware and any company serious enough to be bidding on a Microsoft order for a boatload of Azure servers isn't going to walk away because they can't figure out how to package up some drivers.
If you were talking about the mobile 32-bit world, you would be correct.
The 64-bit world is very different. It is very homogeneous, it looks like an x64 server basically. Userspace actually wasn't ported that long ago. Fortunately now all the major Linux players fully support ARM64 servers (you can download an ISO and install on any ARM64 server without any voodoo, just like x64).
This is correct. However, it's important to point out that the .NET native compilation can also target ARM architectures. For native development in C++, one would need to build and distribute ARM-targeted binaries also in order to actually be "universal".
This is why using some kind of bytecode as portable binary format has been a long tradition on mainframes, almost since the early days, when it was executed via microcode.
Modern computing has just been catching up with them.
For the emulated apps, sure. But apps compiled directly to the new architecture will gain a lot and benefit from the new architecture. Microsoft is big on backwards compatibility, so adopting a new architecture would be a complete non-starter if it weren't for an emulator.
I think the point is that Microsoft can how ship Surface devices with ARM chips that can occasionally run x86 applications when needed. And it also allows Microsoft to ditch Intel if they really wanted to.
Hopefully they get it right this time. The last ARM Surfaces (Surface RTs) were hot garbage, barely functional enough to do email and a little web browsing on.
Actually they were better than that. Users loved them (check out the star ratings on user reviews) and some are still in use.
The design was fundamentally flawed for other reasons, but they performed reasonably well compared to rival tablets, while also offering multiple log-ons, multi-tasking and full Microsoft Office, which those other tablets lacked. They also supported Active Directory, ditto.
Maybe I got a bad one then, but I was not real impressed with mine.
1.) Keyboard constantly flakes out and stops working - or the keyboard and touchpad works, but the touch screen stops working.
2.) Extremely limited software choices. You're stuck with whatever small subset of the garbage in the Windows Store was cross-compiled for Windows RT. Stuck with IE, no options to get Chrome or Firefox or something that works a little better.
3.) Extremely anemic performance. Mine chokes and dies trying to read email (in the godawful Metro Mail app) and browse the ticketing webapp that my company uses.
4.) Suffers the brunt of the awful Windows 8 Metro UI design changes.
5.) The operating system is effectively dead in the water, and won't be getting updates.
6.) Microsoft took a $900 million write-down on the product[1].
I haven't seen the keyboard problem. The main one I saw was a disappearing mouse pointer, which was fixed by removing and re-attaching the keyboard. Weird.
You could try a software reset for the performance problems, bearing in mind that the updates will drive you mad. Unfortunately you can't fix the slow CPU or the too-small RAM. However, the current performance should still compare reasonably with another 2012 tablet.
> The operating system is effectively dead in the water, and won't be getting updates.
Look out for Windows 10 on the Snapdragon 835 later this year ;-)
> Microsoft took a $900 million write-down on the product
Yes, I bet that hurt, even when you have the odd $100 billion in spare cash.
I agree with almost all you say, but you couldn't AD join a Surface. If that were to have been enabled by Microsoft, my conjecture is that it would have become the tablet for business as the market was still open at that point.
I don't think you'd run an entire OS like this. But some processes might not have been ported to ARM and those need an emulation layer. Think Apple's Rosetta for running PowerPC binaries on Intel processors to make the switch less painful.
Project Skybridge was cancelled as far as I know. [0] Not sure if we see something like that in the future, considering how quiet AMD is about their ARM plans. Although a ARM chip with really good power efficency would be nice below Ryzen.
Finally, we’ll note that this roadmap is empty of any mentions of project Skybridge. CEO Lisa Su has commented that AMD has decided to change their focus away from Skybridge based on customer feedback. Customers were telling AMD that they didn't necessarily need socket compatible solutions, so AMD is going to work on differentiated solutions. That said, given that Skybridge was announced last year and planned for 20nm, I suspect that it has also become a victim of the short lifespan (and underperforming nature) of 20nm, leading to it being downplayed in favor of 14nm prodcts.
On the same motherboards? That's rather impressive, if the same motherboard can support two different chip architectures. Having an ARM chip that just happens to use an AM3/AM4 socket is less impressive.
I'm purely a layman in this space, but I don't see why it would be impossible. Pretty much all modern CPUs are actually SoCs. Modern peripheral connections like PCIe and USB 3 have direct access to the CPU rather than going through custom bridge chips, simplifying board design and making it possible to use the same board for two architectures. Audio and network chipsets don't care what architecture the CPU uses.
Again, I'm far from an expert but it seems like a simple enough solution.
As someone with a lot of experience in board bring-up, trust me, the hard part isn't grabbing AMD's reference board, sticking on an audio chip and a wifi chip and sending it over to a board manufacturing shop.
The hard part is wrangling the software: BIOS, drivers, testing and more testing, patches, microcode updates. Finding out that your wifi chip vendor has moved the chip to end-of-life just before you were ready to ship would be a non-issue if the software part were faster.
