Linus Torvalds on Why ARM Won't Win the Server Space • Hacker News Board

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

#541

Post by paulmd » Tue, Feb 26, 2019, 4:42 PM UTC

pjmlp wrote: post #202

paulmd wrote: post #169

Earlier quoted context omitted.

Even in a bytecode language, there is no guarantee that an application is write-once run-everywhere. I converted a small app that was running on Windows with Oracle JDK to run on Linux with OpenJDK and it was not plug-and-play. It was close, but there were a few errors particularly surrounding path resolution (and yes, the Windows application was already using Unix-style paths, this was actually a difference in how p…

The same can happen on the same hardware just by switching versions of the same toolchain. So Linus position is a bit of straw man.

Correct, we need to stabilize all these factors in order to ensure stable, bug free deployment. A Good Post.

Oh, you meant that just because there is one other thing that you might slip up and forget to control for, we shouldn't bother trying to control anything? No, wait, that's actually A Very Bad Opinion.

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

#542

Post by chmod775 » Tue, Feb 26, 2019, 5:59 PM UTC

matchagaucho wrote: post #472

chmod775 wrote: post #468

Earlier quoted context omitted.

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.

Most CDNs are more expensive at 400TB/month than just serving content yourself.

And no Cloudflare's cheap plans are not an option, they'll kick you out.

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

#543

Post by fmajid » Fri, Mar 01, 2019, 10:23 PM UTC

antirez wrote: post #145

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…

Linux' point is that there is hardly any developer-class ARM machines available, just RaspberryPi-class SBCs that use mobile SOCs with the performance of a 2012 vintage smartphone, nothing with the grunt of a Qualcomm Centriq or Cavium ThunderX.

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

#544

Post by pertymcpert » Wed, Mar 06, 2019, 7:45 PM UTC

mehrdadn wrote: post #378

pertymcpert wrote: post #284

Earlier quoted context omitted.

Undefined behavior is not a compiler specific guarantee. UB can change based on almost random factors, especially between newer releases of the same compiler. They are bugs, they were just masked.

If the compiler defines a behavior for some UB, then it's no longer UB. It's been defined for your implementation. It might still be undefined for another implementation but that doesn't mean your code is buggy on the first one.

No, it does not. It's still UB. UB is defined by the standard, not by your compiler's implementation. Certain behaviors may be implementation defined by the standard, those can be defined by your compiler.

But if the standard says it's UB, it's UB. End of story.

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

#545

Post by mehrdadn » Wed, Mar 06, 2019, 8:00 PM UTC

pertymcpert wrote: post #544

mehrdadn wrote: post #378

Earlier quoted context omitted.

If the compiler defines a behavior for some UB, then it's no longer UB. It's been defined for your implementation. It might still be undefined for another implementation but that doesn't mean your code is buggy on the first one.

No, it does not. It's still UB. UB is defined by the standard, not by your compiler's implementation. Certain behaviors may be implementation defined by the standard, those can be defined by your compiler. But if the standard says it's UB, it's UB. End of story.

Where/how do you obtain such confidence in something so wrong? The standard not only doesn't prohibit the implementation from defining something it leaves undefined (surely you don't think even possible behavior becomes invalid as soon as it is documented??), it in fact explicitly permits this possibility to occur -- I suppose to emphasize just how nuts the notion of some kind of 'enforced unpredictability' is:

> Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner...