Linus Torvalds on Why ARM Won't Win the Server Space
realworldtech.com
realworldtech.com
Do I really want to be debugging why node-gyp fails to compile scrypt on the ARM distro on the new Amazon A1 ARM instance (which it did in my case)? And if I solve that, what about the other 2451 dependencies? Let's pessimistically say there's a 1% failure rate, I'll be stuck doing that forever! Nah, I'll just go back to my comfy x86 instance, life's short and there's much code to write :)
I think I'll side with Linus on this one. I saw first-hand how non-existent the x86 Android market was, despite Intel pouring megabucks into the project. If the developers don't run the same platform, it's not going to happen, no matter how great the cross platform story is in theory. Even if it's as simple as checking a box during upload that "yes, this game can run on X86", a huge chunk of the developers will simply never do that.
The good news is that Clang can cross-compile fairly easily. Much better than gcc.
The bad news is that there are a surprising number of missing libraries on Ubuntu/ARM64. For example, Eigen3. And although the code is fairly compatible, there's some extra cognitive load in learning to debug on ARM. For example, calling a virtual function on a deleted object crashes differently.
I'm willing to put up with it for ARM's advantages in battery-powered applications, but I wouldn't just to save a few bucks on cloud servers.
Doesn't that refute Linus' argument, not strengthen it? Almost all Android developers develop on x86. Intel thought, as Linus apparently does, that this would drive adoption of x86 on phones. It didn't.
Intel even got competitive in power efficiency and it wasn't enough to save them. In fact, I remember folks on HN predicting the imminent death of ARM all the way up to Intel throwing in the towel.
I think Linus is wrong here. His argument made sense in the '90s, but it's 2019. The ISA just doesn't matter that much anymore.
Not sure if this is sarcasm or not, but if your project have that many dependencies not wonder it is hard to port anywhere.
Can you not develop on an ARM emulator? Or just buy an ARM machine for dev work?
It's very easy to disagree with him, because the server market doesn't work the way he think it does.
Google, Amazon, Microsoft and Facebook collectively purchased 31% of all the servers sold in 2018. The market for server hardware is dominated by a handful of hyperscale operators. The "long tail" is made up of a few dozen companies like SAP, Oracle, Alibaba and Tencent, with the rest of the market practically representing a rounding error.
These customers are extraordinarily sensitive to performance-per-watt; for their core services, they can readily afford to employ thousands of engineers at SV wages to eke out small efficiency improvements in their core services. They aren't buying Xeon chips on the open market - they're telling Intel what kind of chips they need, Intel are building those chips and everyone else gets whatever is left over. If someone else has a better architecture and can deliver meaningful efficiency savings, they'll throw a couple of billion dollars in their direction without blinking.
This is not theoretical - Google are on the third generation of the TPU, Amazon are making their own ARM-based Graviton chips and Facebook now have a silicon design team led by the guy who designed the Pixel Visual Core. It's looking increasingly certain that Apple are moving to ARM on the desktop, which further undermines the "develop at home" argument.
ARM won't win the server space, because nobody will win the server space. With Moore's Law grinding to a halt, the future of computing clearly involves an increasing number of specialised architectures and instruction sets. When you're spending billions of dollars a year on server hardware and using as much electricity as a small country, using a range of application-specific processors becomes a no-brainer.
Are Alibaba and Tencent Really in the long tail? I believe Tencent could be since it is about 3rd of the size of Alibaba, but if I remember correctly Alibaba will overtake Google by 2019 ( They had ~90% growth in 2018 ), and 2018 were already close to matching Google's Cloud Revenue.
I wonder if OVH is also big in the list. And Apple? Surely the Server Back End to services 900M iPhone users can't be small. How do they compare to say, Google in Server Purchase Terms?
It turned out that the power supply on their server was malfunctioning sometimes delivering too little power. Specially when taking the code paths my IP phone triggered.
The server software was built in php. It's not often you start looking for a bug in PHP but end up switching a capacitor in the PSU.
My point is that even if your write in php, php is running C libraries, that is running ASM that is running hardware and every part of this chain is important. There's no such thing as "works everywhere", it's just "have a very high chance of working everywhere".
(off-topic) thanks for the sds library. I'm a heavy user of it.
About SDS: glad it is useful for you!
Of course it didn't hurt that x86 quickly became the price/performance leader for servers, but he makes a good case that this will continue for at least the near future.
Platform portability issues have got easier with better adherence to standards and where you have largely the same code running across different ISAs (and no endianness issues between x86 and Arm) but the popularity of things like Docker suggest many devs do care about reproducible production environments.
The bigger issue is really that ARM servers aren't that much cheaper than x86 servers today, and its very likely a lot of that difference in cost is just Intel's synthetic market advantage that would disappear if ARM actually started becoming a threat (which has already started happening due to AMD becoming a threat). Phoronix did a synthetic benchmark of AWS's A1 instances, versus the C5 Intel and C5A AMD instances [1]; they're nothing special at all, even with price taken into account.
Maybe that'll change in the future, but now that AMD is in a competitive state, that's pushing Intel into high-gear and its hard to say that ARM will have any effect on the server market in the short-term.
[1] https://www.phoronix.com/scan.php?page=article&item=ec2-grav...
Which is also interesting because there was a time before that where being on the same platform as the deployment environment was sometimes considered nigh impossible, such as the early days of the "microcomputer" revolution where a lot of software was written on big iron mainframes to run on much more constrained devices (C64, Apple II, etc). It's interesting to compare the IDEs and architectures of that era and how much cross-compilation has always happened. There doesn't seem to be a lot of computing history where the machine used to build the software was the same machine intended to run the software, it's the modern PC era that seems the unique inflection point where so much of our software are built and run on the same architectures.
(A lot of the modern tools such as VMs like the JVM and CLR are because of the dreams and imaginations of those developers that directly experienced those earlier eras.)
It's interesting how that tide shifts from time to time, and we so easily forget what that was like, forget to notice the high water marks of previous generations. (Even as we take advantage of it in other ways, we cross-compile to mobile and IoT devices today we'd have no way to run IDEs on, and would rather not try to run compilers directly on them.)
Nowadays you will be running on a CentOS/Debian server or a Windows desktop, on an AMD64 compatible CPU. Not so long ago, there were tens of Unix and Linux variants with significant differences. It was impossible to support half of them.
I think that that's the point. Portability to platforms with a strong tooling and usage base even in a different sector is ok and safe. The problem is when you try to do something like x86 -> Itanium or alike, that could take some time to stabilize.
Having a cheap, viable ARM-native development platform drastically increases the chances of ARM-only killer apps to exist, this would be an advantage over the currently dominant x86 (just as there were Windows-only and Linux-only killer apps that cemented their ascent). However, if everyone is cross-compiling due to the cost, it means ARM will always be a secondary platform (at most)- it can't win by being the Windows Phone of platforms.
[edited for clarity]
If ARM comes anywhere close to viable enough to be "winning", there will be a good market for dev platforms, and somebody will step in and fill the need. Heck, some are even arguing here that the Pine64 already meets that need.
Right now ARM probably outnumbers x86 in number of machines running Linux by a very large margin. In my backpack there is one x86 machine and two ARM ones and that doesn't count the one that's in my hand
It all depends on what chips become available at what price. All cloud providers do lots of hardware design for their own metal. I'd they tell you that their next data center will be primarily ARM, they create a market for a million unit run of whatever CPU they choose.
Working on a non-x86 platform makes you a second class citizen, you will experience issues that others have already ironed out on x86. Software has a long tail of niche code not actively maintained but still heavily used. It doesn't make sense to switch to ARM there.
If it's not much better then people will not switch due to these small annoyances, and there doesn't seem to be any fundamental reason for it being much better (Intel and AMD are perfectly capable of producing top-performing x86 CPUs, and the architecture should not matter much).
There might be different implementations depending on the architecture in some library you use. Also even with higher-level languages like Java it is possible to observe ISA differences: e.g. memory ordering.
I had the pleasure (?) of working on a C/C++ codebase that compiled on Windows and ten different flavors of Unix. It was all "portable", but all over the place there was stuff like
#if defined AIX || defined OSF1
short var;
#else
int var;
#endif
Yeah, cross platform is never as simple as same platform.
C++ is a different matter, but C++ portability is a headache even if you stay on Linux. Likewise, trying to maintain OS-level portability of monolithic codebases between Windows and Unix is a fools errand, which is why Windows Subsystem for Linux (WSL) is likely to only get better.
I don't see ARM displacing X86 on VMs offering like EC2 any time soon, an ARM offering will exists (and it already exists in fact), but it will remain a small portion.
However, some parts of a cloud offering are completely abstracted from the hardware: DNS, object stores, Load Balancers, queues, CDNs... for these, from the point of view of a developer, CPU architecture doesn't matter at all and if the cloud provider find it more interesting to use ARM (maybe with some custom extensions), it will probably switch to them.
From there, it can gradually go to services where architecture kind of matters, but not necessarily, like serverless, or Postgres/MySQL as a service.
And while it grows, ARM CPUs will improve for other use cases, and maybe overtake X86 VMs.
The other possibility is a massive cost reduction like 3 to 4 times cheaper for equal performances, but it's not really the case right now. Also, given the all the wasted money I've seen on AWS ("app is leaking memory? just use a 64GB instance"), I'm not sure it's a good enough incentive. However we are specialist at being penny wise and pound foolish.
The fact that we're talking about ARM makes this even more important. You're having to compete against x86, which requires increased core counts, and a lot more optimization and potentially even redesigns of your software to make your higher level environment to be perceived equal to x86. Businesses will need this, your boss will ask if ARM is as fast as x86 and they won't care to quibble about technological differences if you can't just get the same output speeds as their old, trusted hardware. There is only so much your language can do to cover your butt. At some point you'll have to be aware of your environment to compete.
It's not simple nor something devs will ever want or care to do in a big web app with several binary dependencies.
Just consider that a single Node app's binary deps could trivially include the entirety of Chrome itself, not just in the form of Node's v8 engine, but e.g. as the PDF rendering "headless chrome" wrapper Puppeteer.
And that's just the tip of the iceberg, add DBs, extensions, Python backend scripts, etc etc, and few will bother.
iOS seems like a huge counterexample (as you note.)
For Android development on the other, you don't have a good simulator, and the out-of-the-box dev experience relies on an x86 emulator of the ARM environment. In practice this means that in your day-to-day Android development, you're running the compile-run-test cycle by looking at your actual ARM device all the time, because the emulator is dogshit. I wouldn't really call it cross-platform development in any traditional sense, it's more like remote development, and a bad experience.
I wouldn't be comfortable with an underlying architecture change to ARM for at least years to come and the usage decision would be based on general consensus on reliability that follows.
I feel like this shouldn't matter really, but people are amazingly lazy/developer time valued highly.
Source for this? Seems like pure speculation.
I'm looking forward to embedding Redis my Android app :)
I think maybe Linus T. is getting old, out of touch, and closed-minded, and I think we should be open to change and care less about every random thought he blows off.
Quote source: https://www.linux.com/news/linus-compares-linux-and-bsds
>"This isn't rocket science. This isn't some made up story. This is literally what happened"
right? I mean, I can see arguing that going up into the cloud is different in some ways then going down to smartphones (although the high end ones are now going to outperform plenty of old dev machines in burst power). There are certainly differences in scaling and such. But the maturity of the tech for cross development of high level software isn't the same as it was in that era either. And if we're talking about bottom-to-top revolutions, embedded and smartphones seem to be at a lower level and much higher volume then PCs.
Finally there is clearly an upcoming disruptive fusion event coming due to wearable displays. When "mobile" and "PC" gets merged, it certainly looks like ARM is in a strongly competitive position for some big players, and having more powerful stuff up the stack will matter to them as well.
None of which is to say he won't be right at least in the short term, but it still is kind of odd to not even see it addressed at all, not even a handwave.
It goes beyond the different instruction set of course and most of the time this is indeed mostly irrelevant (unless you've arrived at processor-specific optimizations), but the "develop on the same platform you are running on" still has the least painful workflow IMHO.
I wouldn't mind an ARM-based Mac though ;)
This is Jeff Atwood's argument: https://blog.codinghorror.com/the-tablet-turning-point/ ; Apple tablet performance at Javascript is now catching up to and exceeding desktop performance. Apple have also sunk a lot of money into developing their own processor line, and they have experience in force-migrating all their customers between architectures. At some point you might not be able to buy an Intel-based Apple laptop any more. Given the immense brand loyalty among web developers, they are likely to shrug and carry on .. and start demanding ARM servers with high Javascript performance.
Interestingly there's also https://stackoverflow.com/questions/50966676/why-do-arm-chip... . See also on HN front page https://www.axios.com/apple-macbook-arm-chips-ea93c38a-d40a-... "Apple's move to ARM-based Macs creates uncertainty"
(BTW the link is now slashdotted, I am using https://web.archive.org/web/20190222120214/https://www.realw... )
NDK level programming is explicitly only allowed for scenarios where ART JIT/AOT still isn't up to the job like Vulkan/real time audio/machine learning, or to integrate C and C++ from other platforms.
In fact, with each Android release, the NDK gets further clamped down.
I would like a better NDK experience, in view of iOS and UWP capabilities, on the other hand I do understand the security point of view.
> End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.
The vast majority of code is delivered as either source (python, ruby, etc) or bytcode, JVM, Scalia, etc.
And the Xeon class machines folks deploy to in data center envs is a world apart from their MacBooks.
These truths are true for Linus, but not for the majority of devs.
Even those creating native binaries, this is done through ci/cd pipelines. I have worked in multi arch envs, Windows NT 4 on mips/alpha/x86, iOS, Linux on arm. The issues are overblown.
Disclaimer: I'm a HPC system administrator in a relatively big academic supercomputer center. I also develop scientific applications to run on these clusters.
> Linus is mostly wrong except for HPC. Very few dev pipelines for folks result in native executables. The vast majority of code is delivered as either source (python, ruby, etc) or bytcode, JVM, Scalia, etc.
Scientific applications targeted for HPC environments contain the most hardcore CPU optimizations. They are compiled according to CPU architecture and the code inside is duplicated and optimized for different processor families in some cases. Python is run with PyPy with optimized C bindings, JVM is generally used in UI or some very old applications. Scala is generally used in industrial applications.
> And the Xeon class machines folks deploy to in data center envs is a world apart from their MacBooks.
No, they don't. Xeon servers generally have more memory bandwidth, and more resiliency checks (ECC, platform checks, etc.). Considering the MacBook Pro have a same-generation CPU with your Xeon server with a relatively close frequency, per core performance will be very similar. There won't be special instructions, frequency enhancing gimmicks, or different instruction latencies. If you optimize well, you can get the same server performance from your laptop. Your server will scale better, and will be much more resilient in the end, but the differences end there.
> Even those creating native binaries, this is done through ci/cd pipelines.
Cross compilation is a nice black box which can add behavioral differences to your code which you cannot test in-house. Especially if you're doing leading/cutting edge optimizations in the source code level.
This wasn't showstopping by any means, but it did take a couple of hours to tweak it until it ran properly, and this was just a small webapp not really doing anything exceptional.
Our main line-of-business app (on Java) runs on SPARC/Solaris in production, so we have on-premises test servers so we can test this... and yes, there have been quite a few instances where we identified significant performance anomalies between developer machines running x86/Windows and our Sparc/Solaris test environment, and had to go rewrite some troublesome functions.
Even if your code is Java bytecode, that's still running on a different build of the JVM, on a different build of the OS (possibly a different OS). There is opportunity for different errors to crop up. They might be rare, but they'll be surprising and costly when they happen exactly because of that.
we had those problems when developing in scripting language on windows a code that will run on linux because at some point we needed something that called native and would make us problems with different behavior. after some of that experience we tried to get everybody the same environment that is close to what will run in production.
So while Linus opinion is to be respected, mainframes, and the increase in smartphones, smartwatches and GPS devices use of bytecode distribution formats with compilation to native code at deployment time, shows another trend.
I think fundamentally, the error he's making is comparing the current market to the late 90s/early 2000s market. Back then a RISC Unix machine cost thousands of dollars. It was cost prohibitive to give one to each dev/admin. Nowadays a RISC Linux PC is $5.
The starving college kid in a Helsinki dorm working on his EE degree can't afford 600-1000 dollars for another Laptop/Desktop to experiment with. A 35 dollar ARM SBC and a monitor that doubles as his TV is right in his price range...
That doesn't invalidate his point. He's just saying that is basically what needs to happen for ARM servers to start taking off. The next step is for companies to start deploying ARM workstations. That part still seems to be a good way off, MS abandoning their Windows ARM port didn't help the cause.
This is patently false. Mobile developers do test their apps on smartphones, eventhough google and apple offer VMs. You'd be hard pressed to find a mobile app software house that doesn't have a dozen or so smartphones available to their developers to test and deploy on the real thing.
I'm not sure I agree with. My coding environment is on x86, and I build on x86, but my Run/Debug cycle is on ARM. No one is really encouraged to test on the simulator even though it's available, you are almost entirely asked to test on your actual arm device and run it and see the results of your work.
Linus is making the argument that people want their release builds to run in the same environment as their daily test builds, and I don't see smartphone development as an exception to that rule.
I don't see this happening. PCs are tools for getting real work done. Mobiles are mostly communication and entertainment devices.
I like to fall back on this Steve Jobs quote, employing a car/truck metaphor for computers:
When we were an agrarian nation, all cars were trucks, because that's what you needed on the farm. But as vehicles started to be used in the urban centers, cars got more popular … PCs are going to be like trucks. They're still going to be around, they're still going to have a lot of value, but they're going to be used by one out of X people.
There’s already a whole generation or two who will likely have little to no experience with PCs.
Communication is also work, especially as you go up the management value chain. I think maybe people should refer to the thing that PCs do and mobiles don't as "typing".
If we're trying to predict the future, I think one effective approach to try to not be trapped in the present paradigm is to try to extrapolate from foundations of physics and biology that we can count on remaining constant over the considered period. Trying to really get down to the most fundamental question of end user computing, I think it's arguable that the core is "how do we do IO between the human brain and a CPU?" With improving technology, effectively everything else ultimately falls out of the solution to creating a two-way bridge between those two systems. The primary natural information channel to the human brain is our visual system with audio as secondary and minimal use of touch, and the primary general purpose output we've found are our hands and sometimes feet, with voice now an ever more solid secondary and gestures/eye movements very niche. Short of transhumanism (direct bioelectric links say) those inputs/outputs define the limits of out information and control channels to computers, and the most defining of all is the visual input.
Up until now, the screen has defined much of the rest, and a lot of computer can be thought of "a screen, and then supporting stuff depending on the size of the screen." A really big screen is just not portable at all, so the "supporting stuff" can also be not portable which means expansive space, power, and thermal limits as well as having the screen itself able to be modularized (but even desktop AIOs can pack fairly heavy duty hardware). Human input devices can also be modularized. Get into the largest portable screen size and now the supporting gear must be attached, though it can still have its own space separate from the screen. But already the screen is defining how big that space is and we're losing modularity. That's notebooks. Going more portable then that, we immediately move to "screen with stuff on the back as thin and light as feasible" for all subsequent designs, be it tablets, smartphones, or watches. The screen directly dictates how much physical space is available and in turn how much power and how much room to dissipate heat. And that covers nearly the entire modern direct user computing market.
Wearable displays, capping out at direct retinal projection, represent a "screen" that can hit the limits of human visual acuity while also being mobile, omnipresent, and modularized. I'm really actually kind of surprised how more people don't seem to think this represents a pretty seismic change. If we literally have the exact same maximalized (no further improvements possible) visual interface device everywhere, and the supporting compute/memory/storage/networking hardware need not be integrated, how will that not result in dramatic changes? It's hard to see how "Mobile" and "PC" won't blur in that case. Yeah, entering your local LAN or sitting at your desk may seamlessly result in new access and additional power becoming available as a standalone box(es) with hundreds of watts/kilowatts becomes directly available vs the TDP that can be handled by your belt or watches or whatever form mobile support hardware takes when it no longer is constrained to "back of slab", but the interfaces don't need to necessarily change. Interfaces seem like they'll depend more on human output options then input, but that seems likely to see major changes with WDs too, because it will also no longer be stuck in integrated form factor.
WDs definitely look like they're getting into the initial steeper part of the S-curve at last. Retinal projection has been demoed, as well as improvements in other wearables. We're not talking next year I don't think or even necessarily the year after, but it certainly feels like we're getting into territory where it wouldn't be a total shock either. And initial efforts like always will no doubt be expensive and have compromises, but refinement will be driven pretty hard like always too. I don't think the disruptive potential can possibly be ignored, nobody should have forgotten what happened the last few such inflection points.
>I don't see this happening. PCs are tools for getting real work done. Mobiles are mostly communication and entertainment devices.
This line of reasoning though is fantastically unconvincing. Heck even ignoring the real work mobiles are absolutely being used for, and given the context of this article, I pretty much heard what you said repeated word for word in the 90s except that it was "SGI and Sun systems are tools for getting real work done, PCs are mostly communication and entertainment devices".
Why couldn't ARM-based servers do the same thing? I understand why a generic ARM-based CPU might not win against a generic ARM-based x86 CPU at running cross-compiled code in Linux. But what if the server has a custom ARM-based chip that is a component of a toolchain that is optimized for that code, all the way down to the processor?
Imagine a cloud service where instead of selecting a Linux distro for your application servers, you select cloud server images based on what type of code you're running--which, behind the scenes, are handing off (all or part of) the workload to optimized silicon.
I don't have the technical chops to detail how this would work. But I think my understanding of Apple's chip success is correct: that they customize their silicon for the specific hardware and software they plan to sell. They can do that because they own the entire stack.
I think if any company is going to do that in the server space, it would have to be the big cloud owners. No one else would have the scale to afford the investment and realize the gains, and control of the full stack from hardware to software to networking. And sure, enough, that is who are embarking on custom chip projects:
https://www.thestreet.com/opinion/why-tech-giants-are-design...
So, maybe the result won't be simply "ARM beats x86," but rather "a forest of custom-purpose silicon designs collectively beat x86, and ARM helped grow the forest."
ARMv7: 98.1%
Intel x86: 1.7%
There may be people somewhere doing Android/ChromeOS/Fuchsia development on ARM Chromebooks, following the Google model of using a mostly cloud-based toolchain together with a local IDE. There’s none of this happening inside Google itself, though, yet—but that’s just because Google issues devs Pixelbooks, and they’re x86 (for now.)
But, since Pixelbooks (and ChromeOS devices in general) just run web and Android software (plus a few system-level virtualization programs like Crouton) there’s nothing stopping them from spontaneously switching any given Chromebook to ARM in a model revision. So, as soon as there’s an ARM chip worth putting in a laptop, expect the Pixelbook to have it, and therefore expect instant adoption of “native development on ARM” by a decent chunk of Googlers. It could happen Real Soon Now (hint hint.)
<quote>End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.</quote>
Between that and the much-rumored ARM Macs, this could turn pretty quickly...
I have an Acer R13 w/ MediaTek ARM SoC. It's alright, better than the comparables with Intel N-series CPUs, but it ain't no i5.
Exactly. Linus' point is that Arm has no real advantage in the server space to compensate for the problems with cross-development. That's completely different for smartphones, which is why Arm won that space.
You don't have much choice now sure, but it's not as if there weren't any efforts at x86 smartphones (like the ZenPhone). Nor is it as if there wasn't a long run up of phones leading to the modern smartphone either. And even in this how is not directly relevant to the case of x86?
I mean, we're directly doing a comparison to the RISC/MIPS/etc era yeah? Couldn't back then someone say "well but with PC you don't have a choice, so it's different"? x86 got heavy traction on the back of WinTel, then moved up to bigger iron, which didn't really fight hard in the lower end lower margin space. Does there really seem to be no deja vu with that vs ARM gaining heavy traction in iOS/Android/embedded then moving up to PCs and servers, where Intel/AMD didn't really play in the lower end lower margin space? There was a period with plenty of choice in servers, but then x86 won.
And again it's not as if someone can't come up with compelling arguments, x86 has some real moats even beyond pure performance. There is enormously more legacy software for x86 for example, and the ISA for it will be under legal protection for a long time to come which complicates running it on ARM. But it's hard to say how much that matters in much of the cloud space, particularly if we're imagining 5-10 years further down the line. x86 takeover didn't happen overnight either, and the first efforts were certainly haphazard. But momentum and sheer volume matter. It just seems like something that needs to be addressed at any rate, more deeply then you have and certainly more then Linus did.
>And the only way that changes is if you end up saying "look, you can deploy more cheaply on an ARM box, and here's the development box you can do your work on".
Sure, as soon as these merge and you have a development platform as productive as a desktop computer that allows you to natively build for ARM, then absolutely, it could displace x86. And maybe when (if) the two platforms really merge that could be a real possibility.
And speaking of x64...
> It's why x86 won. Do you really think the world has changed radically?
No, x86 is loosing to x64. And at some point another instruction set will supplant x64.
Intel tried "another instruction set" (Itanium) and nearly lost the market to AMD (AMD64)
His thesis is that if you want a platform to take off, start shipping developer boxes of the platform. So mobile and pc will merge when and only when you can do all your development on a mobile platform.
I don't think ARM can rule with Java ( that already supports it) and Swift/c ( limited hardware).
I don't think ARM can rule with Java ( that already supports it) and Swift/c ( limited hardware)
Secondly, it seems likely that there will be ARM MacBooks by 2020, that kind of instant market penetration for arm in the dev space might mean the exact opposite of what he's saying; why would I deploy on x86 when all of my development is on my ARM machine already?
In the 90s you could see a shift from people having a SPARC workstation in their office for service development, to just using a x86 PC with Linux or Windows on. Then after while developing for Linux/x86 and deploying to Solaris/SPARC made little sense, so you just put it on Linux/x86 in the end. The thing is maybe 95% of things just work and you spend all your time sorting the other 5%.
Well, that is not the exact opposite of what he's saying! He actually mentioned that. That is merely one of his points and it is true.
Linux said: "Without a development platform, ARM in the server space is never going to make it."
It's totally happening for reals this time. Just look at .. like .. Raspberry Pi...
Want an iPod/iPhone like phenomenal opportunity?
Go all in on ARM chips and ship out MacBooks with next gen performance. Alongside, develop server grade ARM chips and make it easy for the army of devs weilding the shiny Macs to deploy straight to it. Impress with performance - you get to take the cake and eat it too.
I doubt an operation guy like Tim Cook will understand such a strategy.
Additionally, Linux is the server platform, abstracting the ISA to a large degree, particularly with regards to what most people consider web applications development, tooling, etc. Docker and Kubernetes serves as this paper for many, as well.
This all will matter in the coming rise of Risc-V devices, as this ISA begins to eat parts of the ARM empire.
Linus would know a thing or two about challenging X86 (transmeta) and this probably shows in his display of his emotional wounds. I don't think his fear holds for all time nor in the coming decade.
I have a slightly different take. Arm on the server has a chance now because cloud and thin clients are increasingly common and so even your "at home" machine, as he calls it, could be in the cloud, the same arm machine used for deployment.
> I can pretty much guarantee that as long as everybody does cross-development, the platform won't be all that stable.
He's saying that until ARM platform arrives on desktop, it's unlikely to be successful in the server market. He's not making any assumptions about whether or not PCs are going to turn to ARM.
Ubuntu is pretty unsuited for servers IMO. It's just complex and error-prone, IMO. The packages aren't always server-quality.
But it's great for the desktop IMO, because Canonical actually tests against real hardware for you.
So the fact that people use Ubuntu for desktop/laptop development makes it popular in the cloud, which I've always felt was unfortunate.
You could do some extra work to test your web app on a more minimal distro or on a BSD, but why bother? Ubuntu works to a degree, so you save that step. Same with x86.
I agree that I use Ubuntu on server because I use it on the desktop, that makes sense.
However, when I installed Ubuntu Server 18.04 recently it was delightful. There was this simple feature they added which automatically pulled down my ssh key from my GitHub account. During the install it asked me to enable the semi-recent kernel livepatching (and old fashioned unattended-upgrades) it even suggested plexmediaserver as a snap package - which was my goal.
Of course installing actual servers is a bit archaic in the age of docker, but it made me feel like I made the right choice of OS.
But I think they can mostly improve things "on top", but not the foundations. Patching over problems by adding layers on top generally isn't great for stability, and is bad for debuggability.
I'm comparing Ubuntu to BSDs, where there's actually a manual, and files are put in consistent places. (as far as I understand, I have less experience with them.)
It's also most of the same reasons that Docker switched its default image from Ubuntu to Alpine some years ago. Alpine is just smaller and makes more sense. Ubuntu does a lot but it's also sprawling and inconsistent.
Off the top of my head:
- Starting services is a weird mix of init scripts and Upstart. And now they're switching to systemd. When they switch they don't update all the packages. There are some weird compatibility shims.
- When you apt-get install apache2, it actually starts the daemon. (This is a problem with both Debian and Ubuntu.) This is bad from a security perspective. A lot of people don't know what's running on their systems in practice and what ports are open, and then they have to set up an extra firewall, which is more complexity.
- the file system is generally a mess, e.g. /etc. There seem to be multiple locations for everything, e.g. bash completion scripts. I think this is a function of the packages being old and patched over.
In general the documentation feels scattered and incomplete. The common practice seems to be googling stuff and pasting things in random files until it works. And then automating that with a Docker container.
That's now traditionally how servers were administered pre-Google :) System administration knowledge / quality seems to have taken a nosedive with the rise of the cloud and cheap hosting. I'm not saying that it's all bad, but it's a downside.
The great thing about Debian and Ubuntu is that there is so much software packaged for it. I think that's generally the reason that people use it. There is a network effect in the package ecosystem.
And you can run Linux on that Yoga. It's just Windows for ARM that is the disaster...
I'm guessing it'll be as easy to run Linux on an arm MacBook as it is to run Linux on an iPad.
https://venturebeat.com/2018/11/01/ipad-pro-a12x-benchmarks-...
You'll probably be able to run Windows 10 on a future Apple ARM-based laptop, though I imagine the problem will be getting Windows drivers for the GPU.
As a result, a colleague developed android-xfstests[3] so we could actually do the necessary testing on an ARM platform. If we had this at the time when we were first trying to launch File Based Encryption for Android, it would have avoided a huge amount of hair pulling.
[1] https://source.android.com/security/encryption/file-based [2] https://thunk.org/gce-xfstests [3] https://thunk.org/android-xfstests
CI platforms make it super easy.
Cloudflare made a big effort to make all software run on x86 and aarch64, and it wasn't that hard at all. Most things today work out of the box.
Many things that don't work, were not very robust to begin with, and fixing them to work on both platforms only made the software better as a whole.
Cloudflare could move to ARM servers in a days' notice, and would already do that if Qualcomm hasn't closed the Centriq shop.
The only real advantage I see for Intel today is AVX512, which can't be beat for some workloads, SVE would be able to compete for some workloads, but not all. However most workloads don't use vector processing instructions anyway. Still, I hope ARM improves their SIMD architecture further.
As for the ALU performance difference, it is very easy to bridge. As evident by Apple's CPUs and Qualcomm Centriq simply having four ALU units gets you to about the same ALU performance as Intel.
Branch prediction, cache performance and the interconnect are still much better at Intel processors. However Intel already peaked branch prediction performance, so the difference can only get smaller with time.
You build and test in the cloud nowadays. Heck, you might develop on MacOS, and deploy on Linux. There are places where it matter, SIMD processing for instance, or low-level kernel development. But if you are on any kind of VM system, or ecosystem with a good compiler history, you are likely to have a smooth ride.
If, in addition, the price point of the ARM machines are at 2/3 of the X86-64 ones, you are in trouble. x86 had another important point up its sleeve: price. And I might expect this was a confounding variable in Linus argument. Not only did you have the x86 at home. It was also like 1/8th of the price of an Alpha, PA-RISC or Sparc machine in price point. And at the time, x86 was dog slow compared to Alpha, and its I/O was laughable compared to HPPA/Sun.
If you have a sizeable invoice at AWS, and you can shave the EC2 price by 2/3rds, you are going to have a lot of wiggle room to make sure your system runs on that aarch64.
I know lots of developers who work on macOS, and deploy to Linux. Back when Mac was PowerPC, I knew lots of developers who worked on PowerPC, and deployed to x86. Or worked on 32-bit, and deployed to 64-bit. Or worked on single-core, and deployed to multi-core. Or green threads to kernel threads. Or big RAM to small RAM. Or the opposite of all of these.
This disaster he anticipates just doesn't seem to be a problem in practice. It's nice when your server is exactly the same as your workstation, but it's never been required. Even today, I have x86-64 on my desk and x86-64 on my server, but they're not the same CPUs, and they don't have the same features (or core count, or RAM, or OS, or ...).
> Which in turn means that cloud providers will end up making more money from their x86 side, which means that they'll prioritize it, and any ARM offerings will be secondary and probably relegated to the mindless dregs (maybe front-end, maybe just static html, that kind of stuff).
Are databases also "mindless dregs"? There's a lot of Postgres/MySQL/Mongo/... instances out there, and even if you're worried about the costs of porting, you only need to port those once (which AFAICT is already done for all of the major ones).
If my database service told me they could cut my price by moving my Postgres instance to ARM, I'd click that button in a heartbeat. I have zero fear that anything would be fishy due to it being a different architecture than my workstation.
> Do you really not understand? This isn't rocket science. This isn't some made up story. This is literally what happened, and what killed all the RISC vendors, and made x86 be the undisputed king of the hill of servers, to the point where everybody else is just a rounding error.
I've worked with many companies, and in every case, going with x86 was 100% because of price. We didn't avoid SPARC or POWER or Itanium servers because of endianness or any other technical reason. It was just a lot more expensive.
Likewise, we switched the servers to 64-bit when it was cost effective, not at the same time that our workstations switched.
So let's say the developers of PostgreSQL or Prometheus or JIRA or Mattermost or any one of numerous others were to come to their audience and say, "we support ARM 100%, you can run our software on ARM in production with no issues, and in fact it's the favored deployment model because it'll cut a significant slice off your operating costs." Does Linus seriously think that, what, customers aren't going to run ARM servers because they can't run the vendor's binary on their development machines?
Maybe there's a chicken-or-the-egg problem here. But just off the bat, PostgreSQL and Prometheus are both supported and built for ARM. There are non-official binaries available for many other projects. Developers are using cheap Raspberry PIs as local desktop development platforms. The more development the ARM ecosystem sees, the easier it'll be for enterprises to justify moving away from x86.
IMHO this is still a problem, it is easy to get RPi-style devices but for development a more powerful device would be great, however this is much harder to get. Sure, cross-compilation works but is usually tedious to setup and work with.
I've had the chance to work on one of these powerful ARM servers for some time. I was connected via ssh and mostly working with tmux+vim, I could compile natively with all these available cores and memory - development was a breeze.
Nevertheless there were some pain points compared to x86: Often no ARM64 binary packages, except for the packages provided by the distro. No precompiled binaries. Software wasn't working/building e.g. because Fedora on ARM64 uses 64K page size. perf didn't support as many performance counters as on x86. Sometimes I would've really liked to use rr (the reverse debugger) but it only supports x86. Pretty sure I've encountered more pain points that I don't remember and also I think I didn't discover all of them.
Development is almost exclusively done on x86. So it is only natural that x86 is the most tested and optimized architecture. This wouldn't be a problem if your offering would be much better/cheaper in some way and although I think ARM servers can compete in certain areas it doesn't seem to provide enough benefit to be worth the trouble. I agree with Linus that they should be focusing on developers and software and let the machines bubble up into the server segment.
So, give fedora a try on aarch64 again, with F29, its almost at 100% package parity with x86 once you remove packages specific to x86. ARM/linaro/etc have been hard at work for the past few years getting the long tail of compilers/libraries working enough that all the higher level stuff has a change to generally work.
The perf thing is a problem because there are a lot of microarch specific counters, but frequently they don't get published by any particular cpu vendor. So, your left in the dark about them. The best solution at the moment is call your vendor and demand a more complete list.
Didn't Linus recently go to sensitivity training or something? I think he missed out on the bigger picture.
It seems like his argument is more about shaming anyone who disagrees with him, instead of expressing an opinion.
People may be offended if they identify their ideas too much, but that's insensitivity from their part.
What they should do is make RISC-V useful for computing at the edge - applying computation to areas where it's previously been infeasible (eg. smartwatches, wearables, RFID, drones, vehicles, etc). Developers go where the end users are. If a new end-user market opens up that suddenly needs a lot of software, developers will buy the same ISA that their customers are using. And then there will be strong pressure to run the other software that developers write (eg. servers, as Linus notes) on the same ISA to prevent cross-development.
However, I think that Windows on ARM will soon become a real thing, this could bring the developers, it will also help the ARM devices spread among Linux users.
Regarding what Linus wrote, I do not buy it. There is so much stuff can run without cross-compilation: js and other scripts, java, c#. Also look at things like Android and iOS, you are already happily developing for ARM, you can develop for servers with the same approach.
My ARM64 development machine is a Pinebook, ARM32 a Cubietruck. Both have only 2GB of RAM and could really do with more. At least the Cubietruck has SATA so mine has a SSD.
Windows an ARM has been a real thing for years, and it is horrible. Nobody in his right mind would use this for development.
Allowing to debug, experiment, without relying on centralized hosting providers -- would be a huge boon to Risc-V.
Early adaptors will be developers, than their family/friends circle. Then there will be Risc-V-First movement (mirroring mobile-first movement), and there it will start...
> So RISC-V CPU designers should aim for the developer market then? First win the hearts and minds of developers, then everything else will come.
Linus is then ignoring the single biggest factor in this equation: performance-per-watt. ARM offers better performance/watt numbers than anything Intel can provide right now. Recent offerings on the server space suggest ARM is managing to scale up without sacrificing too much on that front, and Intel doesn't seem to be keeping up.
If you're operating a data centre, power supply is the single hardest limit to your capacity to scale up. Putting up another building at a pre-existing site is cheaper and easier than finding a way to pipe more power into it, so it doesn't even matter that much that servers are individually less powerful.
Google is investing in ARM, Facebook is investing in ARM, and I can only imagine several other big players are looking into it too. I wouldn't write it off this easily.
As compared to how easy it is to buy a decent quality $119 motherboard + $179 AMD Ryzen quad core CPU.
Not just that it was literally impossible to buy a motherboard+cpu for any reasonable price, for a midtower desktop PC format. Also near impossible to buy a 'cheap' 1RU server or similar for any sort of reasonable price, as compared to $400 Dell R620 with two-socket, 8-core-per-socket older Xeons I could buy on eBay.
There is a very real chicken-or-egg problem with economies of scale. If the top ten Taiwanese based motherboard manufacturers don't think it will make money to build boards for it, they just won't. Super low quantity of 'evaluation' boards that you have to 'contact a sales rep' to acquire are not going to gain widespread adoption.
A NUC can be had for about $120 that sips power and has full hardware support for storage, pcie, graphics and is seamlessly compatible with the entire software ecosystem.
ARM is more comfortable with vendors ie soc, routers, nas vendors than supporting an open platform with access to optimized drivers and off the shelf parts. Thus the entire mobile ecosystem is closed and tightly controlled. Even early devboard makers like Odroid have moved to an Intel platform for their latest N1 dev board.
Go definitely is the easiest, it's built in:
GOOS=linux GOARCH=arm go build
cargo build --target aarch64-unknown-linux-musl
Having said that, docker is perfectly usable on arm, just no one bothers to.
Most server code is CPU architecture independent, and largely operating system independent. It's written in Python, Java, JavaScript, C#, PHP. Most of it is also already cross-developed on macOS or Windows, then deployed on Linux. The fact that all 3 run x86 doesn't make this much easier. Increasingly it's also targeting server-specialized hardware that isn't practical to carry with you (8 GPUs won't fit in a laptop, and Google won't even let buy their TPUs)
If CPU-native development is important, that's actually a good sign for ARM servers. Laptops and desktops are increasingly going to be ARM powered over the next few years.
Sure it will take more than a few tenth of a percent of mac developers but it won't need total domination like x86 either. But just imagine if Apple really just switches its MacBook (not even the Air or Pro ones) to ARM64 that would already be millions of users. A lot of devs will at least try to compile their app for that platform for the first time. Quite some developers will be curious and get one just to test their software on it. I am pretty sure this is going to help the adoption of ARM64 way more than a slightly improved CPU or another experimental support by a cloud provider.
Personally I don't care too much about ARM64's success (although more competition would certainly be great), I am more rooting for RISC-V and I hope they follow a more developer-first strategy.
And if Apple switches pro line to arm, they’ll probably lose all non iOS/macOS developers. So, good luck to them then there.
We have vendors ardently trying to get us to commit to their specific environments, like NVIDIA, but they've been dropping bricks on their feet by not actively encouraging software developers to not target specific versions of CUDA. Anyone running TensorFlow knows how much this sucks. After a while, people are going to get fed up with the problems that come from a poor yet popular implementation and are going to start preferring less popular, yet less proprietary, more deployable solutions.
The idea that Intel and AMD can continue to keep the x86 platform performance advantageous forever is pretty ridiculous. We are already seeing Arm CPUs which are significantly better than x86 in performance per watt. How long will it be until we have high end consumer Arm and low end server Arm that completely overlap x86? One year? Two? Three? Possibly four?
x86 isn't over - that's not what's happening here. But it certainly hasn't "won" forever.
You don't try to develop to the details of an architecture. You even try not to. Then you try to run it on a different architecture, and you find (some of) the places you developed to your specific architecture even though you didn't mean to.
And that's why Linus is right. It's easy to be architecture-specific by accident. It's really hard to not. And it's going to take time and effort to go to a different architecture. In the real world, few people want to waste their time doing that.
But developers can ssh to the cloud, and develop there, right?
I don't feel like that's true. I don't have data to say otherwise, but my impression for the majority of non-tech businesses I encounter is that they are very much still Windows shops, and still on-prem.
To your last point, if that is true, then what will the differences be when both the OS and CPU architectures are different? I suspect it will create even more headaches.
I don't see ARM winning the server space anytime soon or ever considering how established and dominant x86 is.
Then why do they insist on 32GB i9 laptops running MacOS or Linux? One must assume that there is some practical purpose, unless one is rather cynical and believes that maybe the just like shinnies.
When I want to test C++ stuff on ARM, I connect an android device, because that's somehow less painful.
I don't think it's as black and white as wanting the same CPU and OS on your deployment platform and development platform. When it comes to mobile development, having those two be completely different is the norm. It's not much of a problem in practice. The differences between different platforms with the same cpu architecture and OS from different vendors is a much bigger headache than the difference between each of those and the windows or mac + intel laptops the software is being developed on. The difference between windows and macs still causes some headaches of course but is mostly managable. If it works on Linux it generally also works on mac. And if it doesn't that's a good sign of immaturity. All I'm saying here is that most mainstream technologies work across all three of those without much headaches.
Even if that's technically true, there's no reason there can't be ARM workstations. There aren't many because they're still generally slower, but there's no fundamental reason (that I know of) why an ARM workstation can't work just as well as an x86 workstation in almost every case.
This stuff was "dark arts" that we committed to muscle memory in the 90s, and no normal mere mortal will ever learn why the safe mode menu existed, how to hotkey into a boot selection menu, or to boot up a live disk to restore system files. None of that is possible with, say, u-boot. You need to know the kernel load addr, the partition layout, and a ton of crap that just isn't portable from one device to another, and that that's AFTER your done fighting the thing for root access!
Arm workstations Just Won't Work the same way those super permissive x86 workstations did, and that will make them crap for developing on.
Are ARM CPUs more power efficient than x86 CPUs? That could be the deciding factor on whether it will take over.
He’ll be right until he is wrong.
I agree I will not even think of optimizing my code to run on POWER, SPARC, or ARM and that I won't care where my software runs enough to create a market for these, but I don't care enough to keep an x86 market either.
Having said that, it would be good for those who propose new architectures to ensure there is a ready supply of entry level machines for enthusiasts and early adopters. Seeding these groups will ensure their architectures and software is more thoroughly used and tested.
Linus very much sounds like a grumpy old man saying "get off of my lawn!" (as he usually does).
The person running the infra for S3 or GitHub needs to think like Linus because they need to worry about that system level compatibility. But if I write an app using say node+s3 I trust that even though I develop on x86 I can run it under node on Arm.
> This is true even if what you mostly do is something ostensibly cross-platform like just run Perl scripts or whatever. Simply because you'll want to have as similar an environment as possible,
I guess if you're doing stuff with low-level packages using node-gyp or C++ bindings then sure, but pure node-based workloads don't care about the architecture and, as you said, are expected to work everywhere.
However, there is an elephant in the room today: smartphones. ARM processors are suddenly a huge market, allowing for higher R&D expenses. And basically everyone already owns an ARM-powered device, most developers are actually developing for ARM today when they build apps.
So, and there I agree with Linus again, what is a bit missing is ARM-based desktop hardware. The best thing ARM could do to push their cloud processors would be to make affordable motherboards with their processors available to hobbyists and enthusiasts. But ARM is coming to the desktop anyway, be it through the ARM-based Windows laptops or that Apple builds an ARM-based Mac. And then the x86-architecture will come under severe pressure.
I remember joking that writing code for the Xeon Phi would be useful because that was probably what a Core i15 would look like. Now we have Xeon Platinums with similar core/thread counts, but only on the very high end while 8-thread machines are mainstream with 12 being seemingly the next step.
On ARM we have something interesting with the asymmetric cores, something Intel has only hinted they plan to pursue. Some tasks can go to slower cores that sip power while others may be better suited to beefy cores that can do speculative execution on deep pipelines and that could heat a small house.
He is talking about cross-development issues in ARM ecosystem. He has valid points and good suggestions.
Now 20 years later the private pools have faded into the background and the public pool is a lake but its inhabitants are disconnected from the past, only vaguely aware of the era of private pools and couldn't care less how the public pool came to exist. Their reality takes for granted this huge public pool's existance on which they can build and sail their boats, so Linus's arguments are unlikely to resonate.
Users will gladly wade into a private pool this time by cloud providers and that suits closed vendors like Arm who maintain tight platform control - billions of phone socs with zero open drivers - just fine. It's like every generation has to make the same mistakes and go through the same cycle of pain or it slips generational memory.
All devs had SPARC machines and no intention to move to x86 on the desktop, until after Intel steamrollered the performance contest.
I am fine with x86 being successful - there are good reasons for it. I don't get why there's this ARM push in the PC and servers market. It's not making anything better.
What push? There's a rumor that Apple might make an ARM-based laptop, and there's a bit of dabbling with ARM-based servers, but there doesn't seem to be any real push for it. More like hedging bets if Intel continues to shit the bed on 10nm. Except AMD's Epyc looks to be the real contingency plan for that now anyway.
I don't see any reason to expect Apple's motivations for using ARM (more control over hardware) would apply to anyone else, and Apple is the only one with an ARM CPU design that is even worth discussing in a laptop anyway.
So... I wouldn't expect the other 90% of the laptop market to follow, much less any of the desktop/workstation market.
Linus is overestimating the amount of native code being produced.
Intel and PC makers also charged less for hardware. I always wanted one of those RISC systems. They cost upper four to five digits. On the high end, NUMA machines cost around six or more digits. People started building Beowulf clusters out of Intel boxes to knock off digits. Clustering got big. So, it was cheaper on small and large end to run Intel.
Compatibility with dominant system and low cost. Maybe add that they kept optimizing for workloads like gaming on top of that.
https://www.datacenterknowledge.com/amazon/aws-launches-clou...
https://www.datacenterknowledge.com/archives/2017/03/13/arm-...
right now these are niche servers (much like the first x86 servers years ago)
Eh, Android's existence is a pretty big counterpoint to that. And you could just run an ARM VM on your desktop if it's that important to you.
Personally I think ARM could be leapfrogged by RISC-V, though it will take longer than people predict.
For the low-end deeply embedded space, I could see RISC V becoming a significant player in the next 5 years. ARM is relatively expensive there (it's cheap compared to Intel for servers, but at the low end it's more the IBM of Microsoft of old), and there's less need for their ecosystem (most 3rd party software is open source). The Cortex M are less flexible then some competitors in their configuration, and designing good small CPU IP is doable at the low end. So all the small custom designers (Andes, BA semi, Cortus...) can rally around RISC V and have cheap and flexible design, with a good shared software ecosystem. Today it's still one or the other.
At the high-end it's very different. To be competitive one has to take advantage of the latest process nodes, and work well ahead of time with fabs and EDA vendors on the next node(s). This is highly labor intensive, and it takes deep pockets and a lot of resources. ARM is already there, and well entrenched. Getting enough money to replicate this on the RISC V side will take a loooooong while, if it ever happens. Unless a deep pocketed company decides to use RISC V and go their own way, but it seems very unlikely. Look at how even Qualcomm reduced its work on custom ARM cores for their high end, and now do tweaks on ARM designs.
But personally I'm fine with this. It's mostly at the low end / embedded that I feel there's a need for more competition.
1. OS/X is Unix[tm] and linux is a "Unix clone" so the operating system works the same and (for purposes of this debate) both run on the X86 ISA.
2. The first thing all the macbook developers do is install Homebrew or equivalent and install all the same packages that are installed in their linux deployment environment.
At that point, their OS/X development environment is effectively indistinguishable from their linux deployment environment.
Apple will ship MacBooks on ARM in 2020, which will have comparable performance with superior battery life. Windows-based laptop vendors will switch to ARM to catch up; the desktop market will follow the laptop market, as it already does.
ARM's performance-per-watt advantages already make it a compelling cross-compile target today; when everybody's developing on ARM, it will be a no-brainer.
https://gizmodo.com/linux-founder-takes-some-time-off-to-lea...
¹ http://landley.net/toybox/about.html - see the Why section
The assumption would be there, that the cloud market will continue to grow at its current rate and continue to be the valuable market it has been.
What scares intel most is that a new market will emerge for middle and high power compute spread more broadly, and this market will grow explosively faster than data center ever did.
The question is whether these new cores will bring about a new way of structuring the data center, where it is decentralized and spread out more instead of stuck in one building.
A good example is the infrastructure that must go into place to support 5G and self driving cars. Every lamppost will have a server on it.
Arm winning servers becomes irrelevant in that world. If fog / Edge / infrastructure combo blow up the way mobile did, Intel’s little data center slice won’t matter.
Developers will only adapt when there is a big new market to write software for. Data center by itself not sufficient to motivate the change needed.
Heck, even full-blown VMs (the real ones, that docker partially replaced) are mostly useless, for performance reasons.
It seems somewhat clear that some percentage of developers are interested in a fundamentally higher abstraction than what operating systems have classically provided. In a world where that's true for not just a small few but for most developers, it seems that something like processor architecture could be abstrated away. It's not like it's particularly easy to replicate serverless deployment environments on developer machines today, and yet it persists.
If you want to win servers, you basically need to win developers too. So in the ghost world where ARM is dominating on the server, we're all writing code on ARM desktops.
Are there any thumb drive ARM computers? (Preferably with 64-bit ARMv8 processors to match emerging server platforms.) With pluggable ARM mini-computers it might be easy to develop for ARM.
Raspberry Pi would be interesting, but they have old 32-bit processors and I'm not sure how well they interface with a normal computer. Servers are using 64-bit ARMv8.
Maybe smartphones would work as pluggable mini-computers? I heard that OnePlus devices were explicitly root-friendly, but I've never tried it.
It matches my mindset. I am also looking for the good arm laptop. I do not need anything fancy: 4GB of ram (or better), 64GB SSD, wifi, bluetooth, usb (3 if possible), audio jack, good screen, usable keyboard, good touchpad.
Almost all the processor market is ARM already. Scale wins.
ARM desktops are likely if not inevitable.
X86 is not one unified platform.
Cloud hardware will become specialised and not like the hardware in your desktop.
There are lots of developers who developing on MacOS so why BSD server usage is very low than?
https://preshing.com/20121019/this-is-why-they-call-it-a-wea...
I do agree with the idea that a cross-compiled environment makew your target environment “more distant” and this is less efficient. However I don’t think that’s at all what’s limiting ARM from cracking the server market.
20 years later we have finally reached this point for business applications, be them in Java, Python, PHP or some other VM based SDK.
The mainstream development future is in Lambdas and other such containerised technologies. If you can run Docker or similar "home" you can also deploy. Our DevOps models have radically changed and not sure if he realises this.
Latter half of 1990's, by my recollection. The history is well-documented. JDK 1.0 shipped in 1996, and that's when The Java Language Specification was first published also. The "write once, run anywhere" started to be heard soon after.
As you mention lambdas take it to the next level, and in such future Linux might not even matter anymore, hence his point of view.
Saying there's no ARM "at home" is closed-minded to say the least - it's already here - clusters of ARM boards are everywhere, laptops are rapidly gaining ground and I'm currently buying the parts for my first desktop-class ARM machine.
Someone please tell him what LLVM bytecode is, probably he doesn't know because he uses GCC, Apple showed recently how that can leveredged in scale, with Apple Watch's architecture change overnight.
ARM and RISCV are here.
Everyone's first thought (including the other two answerers here!) was that this would allow Apple to change processors entirely: if they wanted to make an Intel iPhone, for instance, they could just tell the App Store to start converting apps' bitcode to Intel machine code instead of ARM machine code for the new phones, and every app would instantly be "updated" for the new processor.
But in practice, this doesn't seem likely. Even with LLVM's unusually clean separation between frontend and backend, the frontend actually does know certain things about the processor it's targeting (mainly details about its memory layout, or special processor features it can use to make certain code faster). These things get baked into the bitcode, and in practice ensure you can't really mix-and-match frontends and backends as freely as you would like. So suddenly switching processors entirely probably isn't in the cards.
What's more likely is that it will allow Apple to make smaller improvements to their processors and then roll them out to existing apps. ...
I tend to agree that it will suffer. But you can get ARM chromebooks, a bunch of vendors offer ARM-based Windows laptops, and Apple is planning on leveraging their SoC on OS X computers. So it may not necessarily be cross-development for long.
Also there is no need for anybody to "win" anything. ARM and Intel servers could be just used for different purposes and each find their own niche.
Torvalds seems to me in a similar position
The onlything i would run locally would be the frontend, and it is web/mobile anyway.
If you're selling ARM/RISC-V laptops, developers will not care because their prod apps are deployed on x86....
> This is true even if what you mostly do is something ostensibly cross-platform like just run perl scripts or whatever.
Please tell me this is irony.
If smartphones came with display ports, many more people could have a PC experience without having a PC.
ARM's forte is in tons of lightweight cores, compared to intel's small number of powerfull cores. There are tons of small mom n pop websites that have short burst of usages, followed by long bursts of calm. So why not give every site on a big server it's own small core, say for 60 seconds? After that you shut the core down, zapping all caches etc...
Things like meltdown and spectre simply disappear if the attacking code runs on a different core, so such an architecture would be good at isolating security sensitive data. In these GDPR times, it seems a good match for small sites, and one that Intel can't provide with their good but power-hungry cores.
> And the only way that changes is if you end up saying "look, you can deploy more cheaply on an ARM box, and here's the development box you can do your work on".
So sure, if RISC-V laptops become inexpensive and accessible for developers so they can develop and target the same platforms, absolutely, it _could_ take over.
> That's bullshit. If you develop on x86, then you're going to want to deploy on x86, because you'll be able to run what you test "at home" (and by "at home" I don't mean literally in your home, but in your work environment).
This is why having a compilation target that works the same way everywhere would be so valuable. We're some ways away from this, but I think WebAssembly offers hope here.
As for the rest of the article, it'd be best if we could have a discussion style where people don't preemptively paint people who disagree with them, or who have a different perspective, strategy, or end goal, as "idiotic" and "stupid", or posit that people have a "total disconnect to reality." This is known as poisoning the well. It does not advance the discussion. In fact it is specifically designed to limit and stop the discussion. The reality is that it simply makes people angry and polarized, amps up the stakes, and ultimately leads to a toxic culture.
Thankfully, I think HN has a better culture. Linus can do better, IMO.
Why does WebAssembly offer more hope than the JVM, or interpreted languages that we already have? It will still have to interop with native libraries to get work done.
It's amazing how everyone from Steve Jobs to Bill Gates to Linus Torvalds is labeled as "toxic" and yet the "toxic" environment they created led to substantial advancements.
And poisoning the well ( or any ad hominem derivatives ) doesn't stop discussion, it generally leads to more discussions - though often times more contentious and off topic. And though I agree that it can make people angry, polarized and amp up the stakes, those aren't necessarily bad things. Most of the time, it is actually a good thing and a basis for competition.
Finally, I'd say HN has a different culture, not necessarily better. Also, what you are doing could be viewed as a form of shaming and virtue signaling. And at the end of the day, if you don't like linus's style of communication, you don't have to read or listen to it.
I don't understand the mentality of "I don't like it so you should change".
People are not generally writing platform specific anything these days, this would be an exception not the rule.
That said, there are a lot of things that need to be done under the hood to facilitate 'our view on the world on ARM' ... and it might take time.
Once AWS starts to release a bunch of stuff on ARM - and the stacks we love and need are solid on them ... I suggest that could be the ARM wave that changes serverland.
I want a RISC-V workstation, and if the counterpart on the server side existed, that'd probably be the change I'd make (if any).