11 ms·

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

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

Androider 8y ago
On a related note, if Apple does switch to ARM chips for their laptops, that will make mainstream ARM server-side development more viable than any cross-platform story ever can. Or kill the Mac desktop. One or the other :)
- rbanffy 8y ago
  If that happens, a lot of low level programming will be done ARM-first. A lot of Swift and Objective-C code will be built, tested and run primarily on ARM.
- vbezhenar 8y ago
  I don’t think that it would kill desktop, but I’m sure that unless ARM will be much faster, developers will use x86 macs for a long time.
  - nicoburns 8y ago
    Apple's latest iPad processors are competitive with low-end laptop x86 processors. And they have a much stricter power budget than a laptop. If Apple wants to go this route, then they probably have the capability to build the chips to support it.
    - jecxjo 8y ago
      The part you're discounting is just how resource intensive desktop apps are and how much optimization goes into iOS apps. To really see the benefit of changing they would need to add a lot of cores, and then cross their fingers that 3rd party app developers know how to do true multi-core development.
      - nicoburns 8y ago
        I don't know about that A-series chips are competive with low-end intel in single-threaded performance. And they keep getting faster each year. If that team were to design a bigger core aimed at laptops, then I wouldn't be surprised if they could make it competitive.
- josephg 8y ago
  When that happens we’ll also see a big push to add ARM support to all the native nodejs modules that are out there. (And I assume Ruby, Python, Go, etc packages). Linus’s prediction is based on the premise that everyone will continue to use x86 for development. But that’s probably not going to be the case for long. Multiple sources have leaked the rumour that Apple will release an arm MacBook next year. And I wouldn’t be surprised if Microsoft has an arm surface book in the wings too. [1] https://www.macrumors.com/2019/02/21/apple-custom-arm-based-chips-2020/ https://www.macrumors.com/2019/02/21/apple-custom-arm-based-...
  - alias_neo 8y ago
    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 in racks with ARM alternatives which will offer them lower performance than their already slightly aged hardware at initially higher costs. I can forsee _some_ interest in ARM cloud, and I don't think it'll be the issue Linus claims at higher-than-systems-level, but I absolutely would bet on x86 going nowhere in the human-software interface space in the foreseeable future.
    - josephg 8y ago
      > 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 initially higher costs. Uh, why are you assuming ARM laptops will have lower performance and a higher cost compared to x86 equivalents? The ARM CPU in the iPad pro already outperforms the high end intel chips in macbook pros in some tests. And how long do you think Apple will continue to sell intel-based macbooks once they have ARM laptops on the market? Maybe they'll keep selling intel laptops for a year or two, but I doubt they'll keep refreshing them when new intel processors come out. When Apple moved from powerpc to intel they didn't keep releasing new powerpc based laptops. Once web development shops start buying laptops with ARM chips, it will be a huge hassle if random nodejs modules don't build & work on ARM. At this point I expect most compatibility issues will be fixed, and that will in turn make deploying nodejs apps on arm a more reasonable choice. Obviously we'll see, and this is all speculation for all of us. But I think its a reasonable path for ARM chips to invade the desktop.
- mullingitover 8y ago
  I consider myself a pretty average Mac user, and I've already been turned off by the last couple rounds of Macs that Apple has shipped. Messing up the one remaining upside, x86 compatibility, would be be the straw that broke the camel's back. They still only have single digit market share in desktop computing, this could be the death blow for their platform.
  - lrem 8y ago
    I'm on a 2013 retina, because nothing in the meantime offered incentive to switch. I'm wondering how a switch to ARM would affect that.
    - ct520 8y ago
      They can make ultra slim butterfly keyboard that feels like Cement when you type on it
  - riffraff 8y ago
    But what if the switch to arm comes with a lot more battery life and great performance? Not all Mac users are devs.
    - jecxjo 8y ago
      I wouldn't imagine you'd get a lot of performance boost from the change. You'll see battery life but that assumes they aren't looking to run a crazy number of cores to make it compete with the x86. And they only way that massive core counts help is if the software is designed to utilize them correctly. Its not that all users are devs. Its that all devs might not be able to make their software work well under that environment.
      - koffiezet 8y ago
        Knowing Apple, they would just go for the 'even lighter' approach, and insert a battery half the size of the current-ones... A battery lifetime of 8 or 12 hours is plenty, and going beyond that isn't that much of a marketable strategy, unless it has to become 24h+ or something. A lower weight approach however would also mean a lower BOM for Apple, and more profit, while being able to shout "1/3rd lighter!" - and that's an easy sell :)
- kakwa_ 8y ago
  It will most likely kill apple laptops as a developer platform. Unless you are deeply disconnected from the hardware, CPU architecture does matter. Most developers using macbooks I know have VMs for either Windows or Linux works. It might be conceivable to use the ARM port of <Insert your Linux distribution here>, or the ARM version of Windows 10. But it would also require a good desktop virtualization solution for ARM. If Apple release its own solution or creates a partnership with let's say VMWare to release something at the same time an ARM macbook comes out, it might work, but barely, and I'm not sure if developers are at the top of Apple's priority list. In the end, with the Linux subsystem in Windows, choosing Windows as a development platform might make more sense. As a side note, if Apple switches to ARM, I foresee a lot of cringing. The switch from ppc to intel was annoying for a lot of Apple users at the time, but there were a lot of goodies (bootcamp, better autonomy, better performance, VMs) that kind of made it up for it, basically, nothing was lost in term of possibilities, a few were actually gained, and only the transition was a bit painful. With a switch to ARM, you may gain a little in term of autonomy, but with macbook pro already at +8 hours (~a work day), not sure it's a game changer, at best you will stay the same in term of performance, and you will lose in compatibility with other OSes.
  - manicdee 8y ago
    I can imagine a neat divide here between “MacBook” (based on ARM, 15 hour battery life) and MacBook Pro (based on Intel i7, 6 hour battery life, optimised for VMs).
  - Moto7451 8y ago
    I think kill is too strong. Certainly some developers will need to be on an Intel chip, but not all. How many developers use their laptops as a dumb SSH terminal? While some C extensions to scripting languages will need some love, the majority of major interpreted or VM driven languages work already. My feeling is it will be net zero as far as ARM servers are concerned until the hardware is made and is viable. Perhaps Apple ARM laptops will help with marketing ARM as a viable option, but we already develop on OS X in order to deploy to Linux without any great calling for OS X servers. Cloud server “hardware” has also drifted from what you see in real hardware. There are numerous times in my career I’ve had to explain to deveopers of all experience levels that their SSD is several orders of magnitude faster than the tiny EBS volume they’re reading from and writing to. In short, I think architecture mismatch just isn’t that important to most Web App oriented companies. My girlfriend works at a travel industry giant and they’re at the opposite end, putting IBM mainframes to good use. They don’t have much use for Macs and most of their developers seem to be on Windows instead of anything resembling what they’re deploying on. For the segment of our industry that does care, they’ll have options and will choose them regardless of what Apple, Google, and Microsoft do with ARM, Intel, Power, MIPS and other architectures.
ams6110 8y ago
> now your whole distro is different than your development machine Can you not develop on an ARM emulator? Or just buy an ARM machine for dev work?
- Wowfunhappy 8y ago
  Aside from the fact that emulation is slow (and thus more annoying to test), now you have to contend with emulator bugs. Is your software crashing because your code is bugged or because the emulator is bugged? Or worse: your software may only be working because of an emulator bug.
  - erik_seaberg 8y ago
    Or your software may be working because the emulator was correct where your hardware stepping may be wrong (e.g., FDIV).
- Androider 8y ago
  Of course I can, but the question is why would go out of my way to do any of that? I was interested in trying the state of server-side ARM for my mostly-interpreted language, and I pretty much immediately found that it doesn't Just Work. I had a vision of spending many hours searching, creating and +1:ing GitHub issues and tracking discussions around "why package X doesn't work on ARM" and the developers saying at best "happy to accept patches" (which btw is the mantra for why "why package X doesn't work on Windows", and why you don't want to develop with Node on Windows to this day despite all of Microsoft's ecosystem work). Nope, not worth it. I'm not interested in supporting ARM just for it's own sake. A 30% discount on the cloud instances is also not nearly enough for me or my team of developers to be spending any significant amount of time on this, solving problems unrelated to our core business. Let's see again in a few years. Of course, if ARM development machines become mainstream by way of Apple, then the calculation changes completely.
  - acqq 8y ago
    > if ARM development machines become mainstream by way of Apple, then the calculation changes completely. That's the biggest chance for ARM: having the notebooks/desktops that are good or even better for most potential users.
tlb 8y ago
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'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.
- sriram_sun 8y ago
  How about using CMake to download and cross-compile the 3rd party dependencies? I've worked on a couple of robotics applications (C++). I wouldn't depend on Ubuntu for packages. You'll lose the flexibility to choose package versions, apply patches etc.
- ekiwi 8y ago
  Have you tried compiling with address sanitizer? https://clang.llvm.org/docs/AddressSanitizer.html https://clang.llvm.org/docs/AddressSanitizer.html Unfortunately C++ code is only portable if it is free from undefined behavior. Fortunately there are many tools now to debug these kinds of errors: https://blog.regehr.org/archives/1520 https://blog.regehr.org/archives/1520
  - saagarjha 8y ago
    The Undefined Behavior Sanitizer might be more useful in this case: http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
- cozzyd 8y ago
  eigen3 is header only isn't it?
  - snovv_crash 8y ago
pcwalton 8y ago
> 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. 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.
- admax88q 8y ago
  Phones are different than servers though. The primary customer of a phone is Joe Somebody who doesn't know or care about architectures, only battery life and cost. Well ARM wins there. The primary customer of servers is developers who care less about cost and more about time to market.
  - Wowfunhappy 8y ago
    To add on to this: developers don't get choose what architecture a customer's phone uses. If they could, perhaps they would choose x86. For servers, developers are often the customers of their own software.
  - stickfigure 8y ago
    I'm a developer deploying code to JVMs running in a PaaS (Google App Engine). I don't know or care what the architecture is.
    - matchagaucho 8y ago
      Likewise... most of my code runs on Lambda JVMs now. If AWS switches to running JVMs on ARM, and passes the cost savings onto me, I'd be in no position to argue.
      - 8y ago
ozim 8y ago
I don't have production experience with ARM unfortunately but Raspberry Pi is huge... Linux on desktop sucks if you have any laptop or something like this, but specific hardware just like RPi, everything works for my needs. I have node.js, .net core, python and loads of software that just works for me on ARM. Let alone I have Synology with ARM processor. Making servers is a lot easier than making consumer grade laptops or desktops. I agree with Antirez, there is so much space to try out stuff on cheap ARM with RPi and other SBC it just going to roll over x86 because ARM is going to be ubiquitous with phones and SBCs. That is why x86 won with SPARC and PowerPc, it was just in more places.
- jecxjo 8y ago
  I ran Pis at home for a bunch of services and I agree it did a great job. But when you put actual loads on it the device craters because they are so under powered. This is where THE issue is going to be. To get speeds you expect out of server hardware its not just about making a 64 core ARM. Single Core ARM vs Single Core x86 has an obvious winner. So you need to make node and .net core and python and everyone else really push their limits on using multiple cores without developers knowing about it. But that is just the first step. You then need developers who write applications on top of those languages be multi-core aware and design their applications to fully use the huge number of cores. At that point you'll loose a lot of your power efficiency because you'll need a lot more hardware running to do the same tasks. You'll also need developers who know how to think in an extremely multi-core way to get the extra performance boost.
  - ct520 8y ago
    Nah bro I just hand it to my paas and the magical unicorn make it work awesomely quick and faster then competition dollar for dollar eye roll
  - vbezhenar 8y ago
    Well, servers typically care about throughput and not latency. So if your ARM server will process 10000 requests per second with each request taking 100 ms and your x64 server will process 8000 requests per second with each request taking 80 ms for the same price, ARM will be preferred. There are exceptions, of course, but generally server workload is an ideal case for multi-threaded applications, because each request is isolated. That's why server CPU's usually have a lot of cores but their frequency is pretty low.
tybit 8y ago
I think it will be interesting to see how this plays out in different ecosystems. I’d hazard a guess that ecosystems like Go, JVM and .NET will fare much better in an arm world, compared to languages that more commonly pull in native binaries.
titanix2 8y ago
> 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.
- ummonk 8y ago
  You must be new to the mess that is the node package ecosystem...
intellix 8y ago
node-gyp has caused me headaches everywhere

Androider 8y ago

On a related note, if Apple does switch to ARM chips for their laptops, that will make mainstream ARM server-side development more viable than any cross-platform story ever can. Or kill the Mac desktop. One or the other :)

rbanffy 8y ago
If that happens, a lot of low level programming will be done ARM-first. A lot of Swift and Objective-C code will be built, tested and run primarily on ARM.
vbezhenar 8y ago
I don’t think that it would kill desktop, but I’m sure that unless ARM will be much faster, developers will use x86 macs for a long time.
- nicoburns 8y ago
  Apple's latest iPad processors are competitive with low-end laptop x86 processors. And they have a much stricter power budget than a laptop. If Apple wants to go this route, then they probably have the capability to build the chips to support it.
  - jecxjo 8y ago
    The part you're discounting is just how resource intensive desktop apps are and how much optimization goes into iOS apps. To really see the benefit of changing they would need to add a lot of cores, and then cross their fingers that 3rd party app developers know how to do true multi-core development.
    - nicoburns 8y ago
      I don't know about that A-series chips are competive with low-end intel in single-threaded performance. And they keep getting faster each year. If that team were to design a bigger core aimed at laptops, then I wouldn't be surprised if they could make it competitive.
josephg 8y ago
When that happens we’ll also see a big push to add ARM support to all the native nodejs modules that are out there. (And I assume Ruby, Python, Go, etc packages). Linus’s prediction is based on the premise that everyone will continue to use x86 for development. But that’s probably not going to be the case for long. Multiple sources have leaked the rumour that Apple will release an arm MacBook next year. And I wouldn’t be surprised if Microsoft has an arm surface book in the wings too. [1] https://www.macrumors.com/2019/02/21/apple-custom-arm-based-chips-2020/ https://www.macrumors.com/2019/02/21/apple-custom-arm-based-...
- alias_neo 8y ago
  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 in racks with ARM alternatives which will offer them lower performance than their already slightly aged hardware at initially higher costs. I can forsee _some_ interest in ARM cloud, and I don't think it'll be the issue Linus claims at higher-than-systems-level, but I absolutely would bet on x86 going nowhere in the human-software interface space in the foreseeable future.
  - josephg 8y ago
    > 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 initially higher costs. Uh, why are you assuming ARM laptops will have lower performance and a higher cost compared to x86 equivalents? The ARM CPU in the iPad pro already outperforms the high end intel chips in macbook pros in some tests. And how long do you think Apple will continue to sell intel-based macbooks once they have ARM laptops on the market? Maybe they'll keep selling intel laptops for a year or two, but I doubt they'll keep refreshing them when new intel processors come out. When Apple moved from powerpc to intel they didn't keep releasing new powerpc based laptops. Once web development shops start buying laptops with ARM chips, it will be a huge hassle if random nodejs modules don't build & work on ARM. At this point I expect most compatibility issues will be fixed, and that will in turn make deploying nodejs apps on arm a more reasonable choice. Obviously we'll see, and this is all speculation for all of us. But I think its a reasonable path for ARM chips to invade the desktop.
mullingitover 8y ago
I consider myself a pretty average Mac user, and I've already been turned off by the last couple rounds of Macs that Apple has shipped. Messing up the one remaining upside, x86 compatibility, would be be the straw that broke the camel's back. They still only have single digit market share in desktop computing, this could be the death blow for their platform.
- lrem 8y ago
  I'm on a 2013 retina, because nothing in the meantime offered incentive to switch. I'm wondering how a switch to ARM would affect that.
  - ct520 8y ago
    They can make ultra slim butterfly keyboard that feels like Cement when you type on it
- riffraff 8y ago
  But what if the switch to arm comes with a lot more battery life and great performance? Not all Mac users are devs.
  - jecxjo 8y ago
    I wouldn't imagine you'd get a lot of performance boost from the change. You'll see battery life but that assumes they aren't looking to run a crazy number of cores to make it compete with the x86. And they only way that massive core counts help is if the software is designed to utilize them correctly. Its not that all users are devs. Its that all devs might not be able to make their software work well under that environment.
    - koffiezet 8y ago
      Knowing Apple, they would just go for the 'even lighter' approach, and insert a battery half the size of the current-ones... A battery lifetime of 8 or 12 hours is plenty, and going beyond that isn't that much of a marketable strategy, unless it has to become 24h+ or something. A lower weight approach however would also mean a lower BOM for Apple, and more profit, while being able to shout "1/3rd lighter!" - and that's an easy sell :)
kakwa_ 8y ago
It will most likely kill apple laptops as a developer platform. Unless you are deeply disconnected from the hardware, CPU architecture does matter. Most developers using macbooks I know have VMs for either Windows or Linux works. It might be conceivable to use the ARM port of <Insert your Linux distribution here>, or the ARM version of Windows 10. But it would also require a good desktop virtualization solution for ARM. If Apple release its own solution or creates a partnership with let's say VMWare to release something at the same time an ARM macbook comes out, it might work, but barely, and I'm not sure if developers are at the top of Apple's priority list. In the end, with the Linux subsystem in Windows, choosing Windows as a development platform might make more sense. As a side note, if Apple switches to ARM, I foresee a lot of cringing. The switch from ppc to intel was annoying for a lot of Apple users at the time, but there were a lot of goodies (bootcamp, better autonomy, better performance, VMs) that kind of made it up for it, basically, nothing was lost in term of possibilities, a few were actually gained, and only the transition was a bit painful. With a switch to ARM, you may gain a little in term of autonomy, but with macbook pro already at +8 hours (~a work day), not sure it's a game changer, at best you will stay the same in term of performance, and you will lose in compatibility with other OSes.
- manicdee 8y ago
  I can imagine a neat divide here between “MacBook” (based on ARM, 15 hour battery life) and MacBook Pro (based on Intel i7, 6 hour battery life, optimised for VMs).
- Moto7451 8y ago
  I think kill is too strong. Certainly some developers will need to be on an Intel chip, but not all. How many developers use their laptops as a dumb SSH terminal? While some C extensions to scripting languages will need some love, the majority of major interpreted or VM driven languages work already. My feeling is it will be net zero as far as ARM servers are concerned until the hardware is made and is viable. Perhaps Apple ARM laptops will help with marketing ARM as a viable option, but we already develop on OS X in order to deploy to Linux without any great calling for OS X servers. Cloud server “hardware” has also drifted from what you see in real hardware. There are numerous times in my career I’ve had to explain to deveopers of all experience levels that their SSD is several orders of magnitude faster than the tiny EBS volume they’re reading from and writing to. In short, I think architecture mismatch just isn’t that important to most Web App oriented companies. My girlfriend works at a travel industry giant and they’re at the opposite end, putting IBM mainframes to good use. They don’t have much use for Macs and most of their developers seem to be on Windows instead of anything resembling what they’re deploying on. For the segment of our industry that does care, they’ll have options and will choose them regardless of what Apple, Google, and Microsoft do with ARM, Intel, Power, MIPS and other architectures.

ams6110 8y ago

> now your whole distro is different than your development machine Can you not develop on an ARM emulator? Or just buy an ARM machine for dev work?

Wowfunhappy 8y ago
Aside from the fact that emulation is slow (and thus more annoying to test), now you have to contend with emulator bugs. Is your software crashing because your code is bugged or because the emulator is bugged? Or worse: your software may only be working because of an emulator bug.
- erik_seaberg 8y ago
  Or your software may be working because the emulator was correct where your hardware stepping may be wrong (e.g., FDIV).
Androider 8y ago
Of course I can, but the question is why would go out of my way to do any of that? I was interested in trying the state of server-side ARM for my mostly-interpreted language, and I pretty much immediately found that it doesn't Just Work. I had a vision of spending many hours searching, creating and +1:ing GitHub issues and tracking discussions around "why package X doesn't work on ARM" and the developers saying at best "happy to accept patches" (which btw is the mantra for why "why package X doesn't work on Windows", and why you don't want to develop with Node on Windows to this day despite all of Microsoft's ecosystem work). Nope, not worth it. I'm not interested in supporting ARM just for it's own sake. A 30% discount on the cloud instances is also not nearly enough for me or my team of developers to be spending any significant amount of time on this, solving problems unrelated to our core business. Let's see again in a few years. Of course, if ARM development machines become mainstream by way of Apple, then the calculation changes completely.
- acqq 8y ago
  > if ARM development machines become mainstream by way of Apple, then the calculation changes completely. That's the biggest chance for ARM: having the notebooks/desktops that are good or even better for most potential users.

tlb 8y ago

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

sriram_sun 8y ago
How about using CMake to download and cross-compile the 3rd party dependencies? I've worked on a couple of robotics applications (C++). I wouldn't depend on Ubuntu for packages. You'll lose the flexibility to choose package versions, apply patches etc.
ekiwi 8y ago
Have you tried compiling with address sanitizer? https://clang.llvm.org/docs/AddressSanitizer.html https://clang.llvm.org/docs/AddressSanitizer.html Unfortunately C++ code is only portable if it is free from undefined behavior. Fortunately there are many tools now to debug these kinds of errors: https://blog.regehr.org/archives/1520 https://blog.regehr.org/archives/1520
- saagarjha 8y ago
  The Undefined Behavior Sanitizer might be more useful in this case: http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
cozzyd 8y ago
eigen3 is header only isn't it?
- snovv_crash 8y ago

pcwalton 8y ago

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

admax88q 8y ago
Phones are different than servers though. The primary customer of a phone is Joe Somebody who doesn't know or care about architectures, only battery life and cost. Well ARM wins there. The primary customer of servers is developers who care less about cost and more about time to market.
- Wowfunhappy 8y ago
  To add on to this: developers don't get choose what architecture a customer's phone uses. If they could, perhaps they would choose x86. For servers, developers are often the customers of their own software.
- stickfigure 8y ago
  I'm a developer deploying code to JVMs running in a PaaS (Google App Engine). I don't know or care what the architecture is.
  - matchagaucho 8y ago
    Likewise... most of my code runs on Lambda JVMs now. If AWS switches to running JVMs on ARM, and passes the cost savings onto me, I'd be in no position to argue.
    - 8y ago

ozim 8y ago

I don't have production experience with ARM unfortunately but Raspberry Pi is huge... Linux on desktop sucks if you have any laptop or something like this, but specific hardware just like RPi, everything works for my needs. I have node.js, .net core, python and loads of software that just works for me on ARM. Let alone I have Synology with ARM processor. Making servers is a lot easier than making consumer grade laptops or desktops. I agree with Antirez, there is so much space to try out stuff on cheap ARM with RPi and other SBC it just going to roll over x86 because ARM is going to be ubiquitous with phones and SBCs. That is why x86 won with SPARC and PowerPc, it was just in more places.

jecxjo 8y ago
I ran Pis at home for a bunch of services and I agree it did a great job. But when you put actual loads on it the device craters because they are so under powered. This is where THE issue is going to be. To get speeds you expect out of server hardware its not just about making a 64 core ARM. Single Core ARM vs Single Core x86 has an obvious winner. So you need to make node and .net core and python and everyone else really push their limits on using multiple cores without developers knowing about it. But that is just the first step. You then need developers who write applications on top of those languages be multi-core aware and design their applications to fully use the huge number of cores. At that point you'll loose a lot of your power efficiency because you'll need a lot more hardware running to do the same tasks. You'll also need developers who know how to think in an extremely multi-core way to get the extra performance boost.
- ct520 8y ago
  Nah bro I just hand it to my paas and the magical unicorn make it work awesomely quick and faster then competition dollar for dollar eye roll
- vbezhenar 8y ago
  Well, servers typically care about throughput and not latency. So if your ARM server will process 10000 requests per second with each request taking 100 ms and your x64 server will process 8000 requests per second with each request taking 80 ms for the same price, ARM will be preferred. There are exceptions, of course, but generally server workload is an ideal case for multi-threaded applications, because each request is isolated. That's why server CPU's usually have a lot of cores but their frequency is pretty low.

tybit 8y ago

I think it will be interesting to see how this plays out in different ecosystems. I’d hazard a guess that ecosystems like Go, JVM and .NET will fare much better in an arm world, compared to languages that more commonly pull in native binaries.

titanix2 8y ago

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

ummonk 8y ago
You must be new to the mess that is the node package ecosystem...

intellix 8y ago

node-gyp has caused me headaches everywhere