bmalehorn

Would you mind sharing what AI note taking app do you use?

Interesting - would you mind sharing a link?

Cool, thanks for sharing. It's these kind of experiences that I was hoping to gather from making this post.

Did you notice at the end that you did NOT end up choosing ARM? You ended up going with x86_64 because that's what made more sense for your backend. That's part of my point - developers should choose their backend architecture based on the performance and pricing of their backend, not their development laptop. And if that decision is "we should keep using x86", then there will be a big performance hit in development.

Thanks, I didn't know about c6g, m6g, r6g. I've updated the post to remove this mention - I only counted a1 instances.

That still leaves storage optimized and GPU optimized instances missing. I'm guessing storage should be easy enough to add, but what about GPU?

From my novice experience with GPUs, they need finicky drivers that must be ported by the GPU manufacturers, so I figure it might take a while to get competitive ARM GPU instances.

Awesome, thanks for testing this out!

A 3x slowdown is not as bad as 6x, but it's still quite a bit. I also saw a slowdown of ~4x when I tried this experiment on a native Linux x86_64 running ARM - perhaps the Mac -> Linux virtualization slowed it down further.

5x may have been a bit alarmist, but regardless we should brace ourselves for a big performance hit on x86_64 virtualization.

I ran this on a Linux laptop - it looks like it's running qemu-user-static:

    root        9934  103  0.0 125444  6664 pts/0    Rl+  12:25   0:12 /usr/bin/qemu-aarch64-static /usr/bin/gzip

So it might be that Docker already runs a native x86_64 Linux, then uses qemu-static binary translation.

Author here.

> 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling.

Yup, performance benchmarks are inherently flawed and nobody knows anything right now without the hardware. However if ARM -> x86 emulation is anything like x86 -> ARM emulation, I would expect a really big performance loss.

> 2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case.

Ah actually I address this in the article, and even run an arm64 image. The short version is, it would be a lot of work to convert your whole backend infrastructure to ARM just because you got a new laptop.

> 3. You won't be able to use most software because they don't release ARM binaries ... and the example uses `wget` && `tar xf`, with no binary signature check. As someone who has been porting stuff from x86_64 to aarch64 for a couple of years, I admit I've seen this pattern frequently. The most obvious solution is to build from sources, which would have been better off on x86_64 too, instead of fetching a prebuilt (and unverified) binary from the internet. Maybe there are some CPU flags the compiler could notice and apply optimizations which are not included in the prebuilt binary.

Yes, if only everything were built from source! I'm not saying there's no solution, just that the solution would be a lot of work. If the library is obscure enough and the errors are strange enough, it might be so much work as to be impossible to the busy web developer.

My goal was to write a kind of hand-wavy article to get people talking about this problem.

Author here.

I'm glad somebody said something! Yes the gzip perf test is pretty silly, but illustrates a significant difference. /dev/urandom throughput on this setup was about 100 MB / s so it wasn't a bottleneck for this test - the bottlneck was gzip.

Feel free to come up with a performance test yourself! I personally want to know what an HTTP test would look like. You can run an ARM image by running:

    docker run -it arm64v8/ubuntu

Unfortunately, Rosetta 2 is not going to help here. Rosetta 2 translates x86 -> ARM, but only on Mac binaries. It does not translate Linux binaries, and cannot reach inside a Docker image.

Author here. That's a major point of the article - "are we screwed?" I'm not an expert on virtualization but I wanted to see some discussion on this topic, because it feels like we might be screwed and nobody is talking about. Anyway I was happy to see Docker worked, at least on a basic level.

The speaker mentions that Redis, MongoDB and background jobs were replaced by Erlang.

What does he mean by that exactly? Erlang provides some persistent state storage? Or is he just saying he used Erlang database drivers to access Redis / MongoDB?

> I would rephrase as companies whose express intent is to manipulate people's habits for their own gain. Entertainment is fine as long as it's done in relative good-faith (not gambling or manipulative microtransactions).

Wondering - is Netflix a good company? On one hand, they're a straightforward entertainment company, but on the other hand they optimize content and suggestions on maximizing viewing hours. Their goal is to change habits to watch more and more Netflix.

How about Apple? They sell hardware and software that people like and they try to respect user privacy. But they design their software to aggressively lock users into their own platform and prevent them from trying competitors.

> It can be about empowering people to manage and utilize their own information. It can be about empowering people to create new information.

This is almost exactly Google's mission statement, but most people here would put Google in the gray area.

My point is, almost no company's goal is to make peoples' lives worse. But all companies are fundamentally trying to manipulate people to buy more of their product. The question is if most customers feel good about the company after the transaction, if they feel like they were manipulated "too much".

It sounds like you're skeptical about companies that affect people's habits. So avoid these terms:

- finance

- advertising

- entertainment

I'd focus on companies that sell to other businesses. Changing the habits of businesses is usually considered a good thing.

And sell something less abstract. If you sell laptops, routers or office chairs, nobody's going to think you're a bad person. Just maybe a bit boring.

Software-only products are all about information. It's about gathering information about people (gray area) or understanding lots of information about people (gray area). So work for a company that does something in the physical world.

This is a nice article, with a comprehensive if long history of npm and node.

I agree with the author that there will one day be a reckoning with npm, inc - they'll shut down abruptly, or do something people are really unhappy with.

However, I'm afraid the package manager proposed at the end will have a lot of trouble gaining traction. It sounds like package maintainers will have to port their packages to the new package manager. Worse, developers won't be able to build, say, React until all 1000 of its indirect dependencies have been ported.

This will take a gargantuan effort to port over, all to avoid a vague future threat. I know it's "the right thing" to use this more decentralized system, but I can't see us getting to there from here with all the pain in between.

I think this is a more likely outcome:

1. npm, inc does a bad thing that makes people angry 2. A community-governed, charity-hosted registry appears. This registry includes everything in registry.npmjs.org, plus exclusive packages 3. users and authors switch to new community registry

In fact, we may already be poised for this coup. Did you know that 1/3 of all package installations go through registry.yarnpkg.com?