Hacker News Reader

Comment by smoldesu | Hacker News Reader

I mean, here's an inconvenient truth: the software I use on a daily basis doesn't work on ARM. The software I develop at work doesn't run on ARM.

If there was a laptop that could replace my T460s with 20 hours of battery life, I'd buy it in a heartbeat. Unfortunately, an x86 laptop with 4 hours of battery life is always going to be more productive than an ARM Macbook/Raspberry Pi for my purposes. I don't think that's denial, it's just the transactional cost of Apple continuing to cut people out of their ecosystem. That's a perfectly fine decision for them to make, but if you can't argue that Apple Silicon will work for everybody, you're defending a moot point. They could make a laptop with 100 hours of battery life, but if it can't run my Docker containers for work, then it can't replace what I have already.

View on HN

Doesn't work on ARM, or doesn't work on Mac?

Basically everything I've tried has worked on my Apple Silicon Mac, including x86_64 Docker containers using Docker Desktop. I'm sure there are applications that don't work, but I've yet to run into one first hand and I'm a software dev.

We lost several weeks for about 10 new devs at my company who started in May/June because Apple only sells M1 now, so that’s what the new devs got, but all the old devs have x86. Poetry+geospatial libs+other stuff didn’t work at all and the new devs struggled to fix it because while they may have had 5, 10, 20 years of software experience, they didn’t know all our stack and didn’t know M1. The remote environment made debugging very slow.

In retrospect we probably should have forced all devs to switch to M1 at once and upgraded everyone’s laptop, but we saw all these posts about how everything works on M1 and that just wasn’t the case at all in our experience.

It sounds like you ought to be gotten at least one experienced team member an M1 laptop, and asked them to spend a 2-3 days making sure that you software runs smoothly on it.

Our software at work didn't work out of the box on M1, but fixing it was fairly trivial and mostly involved upgrading library versions (although we use Node not Python which admittedly tends to be better at portability). But someone completely new to the codebase definitely isn't the person to be fixing these issues.

I mean, there is certainly a class of issue that can be fixed on ARM, you're not incorrect there. Rosetta is not a panacea though, and ARM will not be there to save you when you're trying to spin up a half dozen Docker containers to run your testing framework locally. There are genuinely some issues on M1 that are too big to bikeshed, most of which unfortunately come down to software compatibility and instability. For a lot of companies, you either get an x86 workstation or you don't do local dev. That's unfortunately the status-quo when dealing with traditional, legacy codebases, and it kinda puts the Macbook Pro on the same level of usability as an iPad or Raspberry Pi. Still cool and situationally useful, but if I'm just going to SSH into $OTHER_MACHINE for all of my work, I may as well just get a different laptop.

Totally, as I said in my comment, I would have done that in retrospect. The trouble was that we didn’t see that as a risk, since everyone was telling us that there wouldn’t be any issues

> but if it can't run my Docker containers for work

I don't understand; Docker Desktop for Apple Silicon runs x86 containers out of the box

At slower speeds, enough that depending on what you're doing, it's not usable.

And it's not guaranteed to work anyway. We had some processes which I guess were compiled to use instructions that qemu wasn't emulating, so they would crash with illegal instruction errors.

Another annoyance is that your package repo may not actually publish arm versions of packages you use. This is usually the case for older stuff, e.g. MySQL 5.x was not released for arm and won't compile without backports. So, to fix the performance issues with emulation you may need to build some things yourself. Not a big deal, but also not an out of the box experience.

I'm genuinely curious what you need Docker and x86 together for.

Most Docker use cases tend to be server related and most hiccups running those on ARM have been solved by now (partly due to pushes for AWS Graviton cost savings and performance increases too, not just Apple).

Isn't that why they made Rosetta?

https://developer.apple.com/documentation/apple-silicon/abou...

If your software runs on x86 Mac, it should run on Apple Silicon.

yes, but at the cost of giving up a lot of that perfomance benefit. Rosetta is acceptable performance usually, not good performance.

Sorry, I don't see how apple has cut anyone out of their ecosystem, unless your opinion is that Apple should simply have stuck with intel, despite their own hardware being better by every metric?

As for cutting people out: every piece of software, including x86 I have tried has worked without a hitch. If your problem is that you need an x86 VM, then yeah you're kind hosed unless maybe intel&amd decided release their ISA royalty free?

Alternatively, you could just not write awful architecture dependent software, like all those developers happily using ARM laptops without a problem are mysteriously capable of.

I have a T460s and I’ve never come close to 20hours of battery. Wtf are you doing

I run Docker containers on my M1 every day for work. There's almost zero compatibility issues with M1 Macs.

If you've got arm64 images, it works great. If you have x86_64 images, it probably still works, but it's not a guarantee - we definitely have images at my workplace which do not work emulated - and it's substantially slower than on an x86 machine. On top of it being slower anyway, since Docker for Mac is running the daemon in a VM.

I'm really happy the M1/M2 exists, and I have access to an M1 MBP, but I'd still rather have a nice Linux laptop. Especially for containers.

Edit: One severe (to me) incompatibility I ran into with the M1 MBP is that it would not run my dual monitors (dell, displayport) through either of the TB3 docks (belkin, caldigit) I had available. I ended up replacing the monitors. Worked fine with the x86 MBP.

Regarding ARM docker images, can't you just update them to support ARM same as any non-Docker software you use?

Regarding Docker on Mac I totally agree. It's not worth it. At my workplace we simply run everything natively. We have to use Macs because we do iOS dev, but if we didn't then I'd definitely be tempted to get a linux laptop. May stick Asahi on my machine once the GPU support is ready.

Only if the software is published for ARM. See my other reply in this thread - you may be stuck using some older software that was never published for ARM, so while you can get it working, it may be on you to backport fixes and compile packages to build a new image yourself.

It can absolutely be done, though. It's just not necessarily as simple as "install the ARM one".

Yep. A lot of times, your legacy test suite will depend on some obscure Oracle Docker image that hasn't been updated since the late 'oughts, and unless you get it running then your tests won't run. On x86, this really isn't a problem. On Linux, you don't even need QEMU to get things working.

I wish this world was friendlier to the RISC ISAs of the world, but CISC supremacy is still real, and can hurt you.

Slightly facetious, but do you port MKL to ARM?

More seriously, it wouldn't surprise me that there is a fair bit of software out there that is written with assembly or x86 intrinsics which isn't worth the time porting, especially if you're not going to deploy on ARM.

The non-pro/max/ultra M1 and M2 chips do not support more than two monitors. Which on a laptop means you get one external monitor.

This makes me reasonably angry, because I use dual 4K displays.

I know; this was an M1 Pro (16" MBP).

CalDigit support told me that it happened on the M1 Pro systems if the make/model of the monitors was identical, but I don't think that's true, because I replaced two identical monitors with two newer identical monitors and both of those work through a CalDigit TS3+.

You have never used an arm64 MacBook. Otherwise, you would know that almost all compatibility issues have been solved long time ago.

And for many of us the software we use can run on ARM but it's extra work to make it run and that has to be factored in.

Reply on news.ycombinator.com