Hacker News Reader

Comment by etaioinshrdlu | Hacker News Reader

I don't think I could use a Mac for software development anymore if they switched away from Intel.

So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common.

I also need a Windows VM quite frequently for the odd program that only runs in Windows, or if I need to run Visual Studio one day. Windows is also very important for me to keep around so I can test software products in the same environment as other windows users, and there are definitely a handful of windows users out there.

Sure there may be alternative options in both areas but I'm not interested in solutions that work 80% of the time. I can't let my development environment get in the way of my work.

View on HN

It would be slightly less convenient, but it probably wouldn’t affect your development capabilities so badly. Pretty much any Dockerfile that works on x86 should work on ARM. Linux runs totally fine on ARM. If anything, the worse problems are with Linux desktop and games software that assume ARM == embedded and attempt to use EGL and GLES.

There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues. (The latter is straight up a non-issue with a good CD pipeline.)

Windows 10 also runs on ARM platforms, with the ability to transparently emulate Intel. I’m sure this is or will be usable inside of VMs even if dual booting is not an option.

https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...

Most linux desktops work fine on ARM chips FYI. GPUs in the ARM world are usually just for OpenGL used by video games.

Video decoding/encoding is handled by a VPU (not GPU), HDMI is handled by a separate HDMI PHY, and most of these components have mainline, libre kernel support if you use an Allwinner based single board computer.

Microsoft has started branding some Mali GPUs as DirectX 11 capable, though YMMV on using these features.

Sure, but many games and applications are hardcoded to use EGL and GLES (which is not always available for desktop ARM.) For example, I believe Qt4 makes the assumption that ARM = GLES.

> There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues.

I'm not sure thats true. At the very least its going to suck for the first year as gaps are being filled, but those differences might matter too. I would hate to have to duplicate every single Dockerfile just because of this, as engineering orgs are typically heterogenous (win/lin/mac).

Should not need to duplicate the Dockerfiles; they should work as-is. The repositories may not contain aarch64 builds, but just like docker repos can contain windows container builds alongside linux, they can contain aarch64 alongside amd64, at the same URL, with the same tags, and in fact I think plenty of official images already have that.

Few images should need Dockerfile changes unless they are bootstrapping from scratch. People are already using Docker and Kubernetes on Raspberry Pi and other small ARM devices.

> So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common.

Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Because unless you are, I don't see what the issue would be with multiarch, assuming you don't manually compile the binaries for your containers.

Also AArch64 cloud servers are a commodity available from at least Amazon right now, and the hardware is available on the open market.

Not to mention, if you're running Docker right now, it's not running natively on macOS anyway. If you're just looking to test basic correctness, then surely you can run your dockers in QEMU or whatever AMD64 DBT/emulator is made available. Apple has a history of shipping good emulators (namely Rosetta and the 68k emulator) for their previous architectures when they change ISA.

> Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements?

Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS.

TLS is in just about everything.

You really need to develop and QA on the expected deployment platform

> "Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything."

Sure, but when it comes to platform enablement, that only really needs to be done once per vertical/native dependency. AArch64 has all of those things you listed. Don't know about .NET (though there's not that much .NET development on Linux, at least not when compared with the amount of Node and Java), but OpenJDK, Node, C/C++/Rust/Go toolchains all have mature support for AArch64, among others.

It's obviously less mature than the 40-year-old x86 ecosystem, but it's basically all there. Furthermore, the ease with which new ISAs can be adopted by toolchains and libraries is accelerating, so POWER and RISC-V are also getting there in terms of software availability.

There are so many different flavors of AMD64 that it’s not even a single target from my perspective. Check out the quantity of compiler flags and ifdef statements you see in just about everything.

I’ve seen binaries in production run at 30% of the speed seen DEV/QA. These would also segfault every few hours. But debug builds ran fine in production.

Root cause in that case was the Intel server had some hardware instructions available that the Intel developer and QA systems didn’t. The runtime chose to use these fancy new instructions, which turned out to be a buggy and slow code path.

Again, if you’re not doing DEV/QA on hardware (and OS, dependency, and firmware versions) that differ from production you will eventually be bitten.

Everything is so complex and there are so many layers involved it is impossible to have confidence. Containers make this worse in my opinion by adding another complex (and buggy) abstraction layer.

May be by the time Mac has an ARM processor, your deployment server might also be an ARM server. :)

I don't think I could use a Mac for software development anymore if they switched away from Intel.

A clear message that's been coming from Apple over the past few years is that developers are not a market they care very much about. I strongly suspect a lot of us won't be using Macs for development in the future.

They certainly care about Mac developers and iOS developers.

Looking at the state of documentation and their general lack of responsiveness, I really don't understand where the idea they care is coming from.

Do they? The App store is so full of automatically generated cookie-cutter apps with minor cosmetic differences that no one can really make a successful app any more. It's a lottery of who gets an Editor's Pick. That's not developer friendly.

Really? My iOS devices are full of high-quality applications that I bought on the App Store: Omnifocus, Omnioutliner, IA Writer, Pixelmator, Bear, Devonthink, Carrot Weather, Overcast, and dozens more.

I'm not suggesting there aren't great apps out there - I'm saying they're effectively impossible to find, and new app developers pretty much can't break in any more. There are 100 terrible apps for every good one, and you'll never find some of the best apps out there using the app store because of that noise. Finding new apps is driven by word of mouth, curation, etc. Apple themselves add practically nothing to the ecosystem, and certainly not enough to justify their 30% cut.

The list you added to your post is a good example of this - all those apps are examples of things that had a community outside of the app store before they had iOS versions. They're not good or successful because of Apple, but in spite of Apple.

You know one of the great things about VMs? They're cross-platform. I'm guessing once the same amount of optimization is put into arm has has been put into x86, the performance ought to be comparable. I'm also about 99% sure docker can be run on arm (RPIs support it, right?).

With that said, I sincerely doubt Apple will kill x86 wholesale overnight. I'm guessing there will be a transitional period of quite some time.

Also, windows has been doing a ton of work around getting onto arm. I managed to test on my rpi 3, and it was pretty good. it would probably be very doable.

Cross platform sure, but cross architecture will kill performance.

Not necessarily. JIT ISA emulation that generates native code for the host ISA has been done for ages now.

My understanding is that you could expect, very roughly, maybe a 50% performance hit using best of breed emulators translating from one ISA to an other ISA nowadays.

Reply on news.ycombinator.com