undefined | Better HN

0 pointsyjftsjthsd-h5y ago0 comments

That requires that ARM images are available, which will take time and always have a disconnect. It also violates the idea of being able to run the exact same image on your laptop (ARM Mac) and in prod (x86 server).

0 comments

7 comments · 4 top-level

jrockway5y ago· 2 in thread

You can run on ARM servers in production. They're even cheaper than x86 servers. (Though also slower, at least AWS's version.)

Realistically, ARM is probably the future, and just needs something to push society in the direction of the future. A lot of people use Macs, so this forces people to become interested in switching, which has some value. Remember when the original iMac had USB instead of ADB ports? Everyone was mad about it. But USB was the future -- you can plug that iMac's mouse into pretty much any computer you have and it still works.

(I've been wanting an ARM desktop for a while, but it seems there is trouble standardizing something like BIOS/UEFI, and the CPUs you can buy are more expensive and slower than x86 alternatives. I'm also not sure if anyone ever decided what the standard "ARM" configuration looks like... binary calling conventions, endianness, supported instructions? But, if Apple can make a competitive ARM chip, so can others, and the standards will follow. We'll see!)

vbezhenar5y ago

> You can run on ARM servers in production. They're even cheaper than x86 servers. (Though also slower, at least AWS's version.)

Where can I buy ARM server comparable with x86 server on performance? I'm not interested with clouds, I want bare metal server. I'm not aware of any server brand like HP or Dell producing ARM servers. I'm also not aware of any CPU manufacturer producing computer desktops with ARM comparable with x86, outside of Apple macs. I'm not convinced that ARM is the future. For me the future is both architectures co-existing.

viraptor5y ago

> I'm not interested with clouds, I want bare metal server.

You can have both.

https://aws.amazon.com/blogs/aws/now-available-bare-metal-ar...

1 more reply

raverbashing5y ago· 1 in thread

> It also violates the idea of being able to run the exact same image on your laptop (ARM Mac) and in prod (x86 server).

99% of people are running node/python/RoR/PHP on Ubuntu/Debian/Arch. It works the same for most cases. (possible caveat: I'm not sure if numpy and TensorFlow is supported already but it probably is)

But for basic stuff, it's a non-issue

yjftsjthsd-hOP5y ago

You still can't use the same container image across architectures, even if the important parts are interpreted code. You can package the architecture-independent parts for both x86 and ARM, of course, but as you sort of touch on, that still leaves dependency issues and surprise differences in the platform ("oh look, this is so fast on my mac where there's hardware acceleration for the C library used in this hot path" followed 3 weeks later by, "why is this so slow on our x86 servers?").

sitkack5y ago

It wasn't though, the same Dockerfile, but not the same image. The images are ephemeral and stateless, being only a projection of the Dockerfile.

tasogare5y ago

Running the same image on dev machine and prod was an illusion brought by the fact the underlying architecture was the same. It’s not reasonable to expect images to magically be cross-architecture.

j / k navigate · click thread line to collapse