Live data from Hacker News

Linus Torvalds on Why ARM Won't Win the Server Space

realworldtech.com

471–480 of 545 posts

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#471

I disagree with Linus for a couple of reasons. The main one being that not every service in a product needs to be running ARM for it to be useful. There is nothing preventing heterogenous solutions in the cloud and if third parties vet their code on ARM then deploying your DBMS on ARM and your web server on x86 (or whatever services most of your business logic is in) is totally valid for cost or performance reasons.…

Yeah... 2019 is the Year of ARM On The Desktop. As is 2018, 2020, 2021, 2022...

It's totally happening for reals this time. Just look at .. like .. Raspberry Pi...

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#472

Earlier quoted context omitted.

more expensive than...running everything yourself Only if you value your time at zero.

This is so utterly untrue and directly related to what Linus was talking about. Those bare-metal servers are basically 1:1 what you are developing on. I can install an instance of my application on them in minutes. It's AWS that takes significantly more time to set up and learn . Most people using AWS are spending big bucks on an 'automatically scaling' architecture (that never just works ) that will cost them many t…

8 servers fixed capex is not comparable to the opex of 8 peak servers.

If bandwidth is your highest cost, that's a completely separate problem that likely requires CDN. Neither x86 or ARM is going to reduce that cost.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#473

Earlier quoted context omitted.

Node and Ruby applications do fail on ARM though, when it comes to native libraries and extensions. And now your whole distro is different than your development machine, which adds complexity. 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 pessimistic…

> what about the other 2451 dependencies Not sure if this is sarcasm or not, but if your project have that many dependencies not wonder it is hard to port anywhere.

You must be new to the mess that is the node package ecosystem...

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#474
post #301

Earlier quoted context omitted.

Node and Ruby applications do fail on ARM though, when it comes to native libraries and extensions. And now your whole distro is different than your development machine, which adds complexity. 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 pessimistic…

I'm suffering through this now -- I have a custom C++ Node exception that needs to run on both x64 and ARM. The ARM cpu is onboard a mobile robot, where I care about power draw. 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…

> The good news is that Clang can cross-compile fairly easily. Much better than gcc.

How so? The complications in cross compiling come from setting up all the system libraries, not the compiler and linker.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#475
post #386

Earlier quoted context omitted.

Android uses bionic.

Yes, and..? Bionic is Android's libc. libc is just the name of the C standard library, not any particularly C standard library. You might be confused and thinking of glibc, which is a particular libc implementation.

And as such it is only required to expose ISO C functions.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#476
post #438
post #301

Earlier quoted context omitted.

I'm suffering through this now -- I have a custom C++ Node exception that needs to run on both x64 and ARM. The ARM cpu is onboard a mobile robot, where I care about power draw. 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…

eigen3 is header only isn't it?

Yes, but only once you run the `configure` so that it chooses the right inline assembly blocks for your system.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#477
post #301

Earlier quoted context omitted.

I'm suffering through this now -- I have a custom C++ Node exception that needs to run on both x64 and ARM. The ARM cpu is onboard a mobile robot, where I care about power draw. 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…

> The good news is that Clang can cross-compile fairly easily. Much better than gcc. How so? The complications in cross compiling come from setting up all the system libraries, not the compiler and linker.

I remember getting annoyed needing a windows driver that was part of an open source package. That needed autotools to build. I got annoyed trying to make it compile under mysys/MinGW. So I built a gcc cross compiler under linux. Compiled the damn driver and it just worked(tm).

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#478
post #302

Earlier quoted context omitted.

This honestly depends on what undefined behavior we are talking about. Sometimes it will be guaranteed to behave a certain way on a compiler. A few will also be the same across compilers if your compiling for the same architecture. However, I do agree that cross compiling is good for finding bugs like this. And really if we are letting the compiler or architecture define undefined behavior, I find it better to break…

> This honestly depends on what undefined behavior we are talking about. Sometimes it will be guaranteed to behave a certain way on a compiler. That is implementation defined, not undefined, behavior.

That's at least unnecessarily splitting hairs and possibly missing the point, considering that some compilers allow you to turn undefined behaviour into implementation-defined behaviour using an option. -fwrapv comes to mind.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#479

Earlier quoted context omitted.

Developers don't develop on Surface books, and Macbooks are in low percentages. The majority of people in the world writing code are using x86 PCs and Microsoft and Apple aren't about to change that with any *Book. Linus' premise that everyone will continue to use x86 for development is because they will. There's no incentive for companies or individuals to go switch out all of that x86 hardware sitting on desks and…

> Macbooks are in low percentages For some reason Macbooks seem disproportionately represented amongst web developers. All the agencies I know in Sydney and Melbourne are full of macbooks. > There's no incentive for companies or individuals to go switch out all of that x86 hardware sitting on desks and in racks with ARM alternatives which will offer them lower performance than their already slightly aged hardware at…

Agreed, at the last 5 software companies I've worked at, the only people without Macs were the sales people.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#480

It's extremely hard to agree with Linus on that. One problem in his argument is that he believes that everybody has a kernel hacker mindset: most today's developers don't care about environment reproducibility at architecture level. The second problem is that he believes that every kind of development is as platform sensitive as kernel hacking, and he even makes the example of Perl scripts. The reality is that one ye…

>It's extremely hard to agree with Linus on that. 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 Tence…

>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.

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?

Post reply on HN