It's still a year or two away for things to be ready to own an M1 for development with the types of topics listed above.
Ask HN: How are you dealing with the M1/ARM migration?
181–190 of 284 posts
Re: Ask HN: How are you dealing with the M1/ARM migration?
#182The 8GB M1 versions don't have enough RAM for a lot of dev work, doing pretty ordinary things created a lot of RAM pressure when I had one. I later bought Max with 64GB, and that has been brilliant. I gave up on the idea of using Docker almost immediately.
Early on there were major issues if you were targeting x86-64 systems code in C++. A lot of common tooling was broken for months on end. Time has solved some of these problems but ultimately I wrote code to support native ARM targets as first-class code citizens. There was a significant learning curve (I was not fluent in ARM64 ISA) but now that everything is ported, running native, and the tooling has finally started to catch up, it works pretty smoothly and I don't have much to complain about. The x86 emulation has limitations so native is the only way to go for many things, and you'll still want to test some code on real x86 server hardware.
That said, the latest OS on (at least) the M1 is noticeably buggy. Lots of behavioral artifacts that I wouldn't expect. Not sure if it is the hardware or the software, or both. Nothing catastrophic, just annoying.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#183Some of our 3rd party dev packages don't have M1 support, and docker cross-compilation for M1 has been a nightmare. 8GB RAM is too low as well. Our team is staying on just Intel mac/win/linux computers until we have the resources to address the M1 issues.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#184I got an M1 MacBook Pro from work last year, and expecting to pay the price for being an early adopter, I set up my previous Intel-based MBP nearby in case I ran into any problems or needed to run one of my existing virtual machines. (I do varied development projects ranging from compiling kernels to building web frontends.) In reality I have hardly turned on the Intel MBP at all since I got it. At all. Docker and VM…
Rosetta is definitely not flawless. This type of jit/translation does have limits.
Often times people experience different levels of difficulty using Apple Silicon precisely because my workload is not yours, and yours is different again from OP's
So I feel this particular Ask HN is more about wondering how different everyone's workflows are, and how that impacts M1 usage.
I envision that workflow options/pathways will start converging into one "way" which is the Apple way. You already are getting shunted into relying purely on Metal for gpu acceleration and you see the various plurality of gpgpu libraries start converging on only the Apple blessed/authorized and optimized version.
There are people fighting against this, for example the Linux on Apple Silicon project bringing up the GPU, but it's slow going.
Give it another few years, and people will stop using x, y, or z frameworks, and only use whatever API's Apple gives us, because that is the Apple Way.
Proceed at your own peril. The future is fast, but there is only one road.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#185Earlier quoted context omitted.
> It is interesting how much impact GitHub has had by not having Apple Silicon support Putting on my tin-foil hat for a sec: GitHub is owned by Microsoft, who would really stand to benefit from slowing down Apple Silicon adoption a bit...
Alternative theory: Apple doesn't offer an M1 server. Github doesn't offer an M1 build server because M1 servers don't exist.
M1 Mac Mini farms easily solve that question
Re: Ask HN: How are you dealing with the M1/ARM migration?
#186Early reviews said that even the base 8GB RAM models were snappy, despite the small amount of RAM. I went in believing that, but turns out it was anything but. Maybe it was my specific usage (Firefox with tons of tabs, Electron apps open all the time) but it feels much more sluggish than my previous 2013 iMac. Next one I get is definitely going to have 16GB minimum, maybe 24GB.
This is where marketing hits reality.
There are no magical computers, just a great Reality Distortion Field that's still at work.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#187We had an engineer in India get an M1 MBP last month and most things worked, but the docker container for MS SQL had big issues and he had to get an Intel MBP to be able to work. I suspect that those issues will dissipate with time. Right now, I find it annoying that the only OTP auth apps that are available for the Mac require Apple Silicon as they're essentially iPhone apps with new skins. I really want to be able…
Get an external key like a yubikey and that would handle multifactor authentication/otp like a champ.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#188Re: Ask HN: How are you dealing with the M1/ARM migration?
#189Earlier quoted context omitted.
Mac-using devs are mostly Linux-using devs who prefer a non-free distro ;)
That’s not that far from the reality. It’s essentially like using a Linux with really good graphical UI, ecosystem/3rd party integrations that just works and fully supported stellar hardware. After all, macOS is certified Unix and Linux is Unix-like.
As a Linux user who has run a Mac daily for work before, I don't really feel this at all.
To me, the core of the Linux experience consists mostly of things that are not part of macOS:
- uniform, comprehensive, robust package management, including for the system software
- GNU coreutils and related utilities (sed, grep, find, etc.)
- good filesystems
- 'root is root'; no policy or other bullshit restricting what root can do by default
- lots of featureful, performant terminal emulators (to the point that the DE default is almost always fine)
- some choice w/r/t desktop experience
- popular apps don't just entirely stop working between OS releases
- pretty much everything is discoverable and configurable if you're determined
Using Linux just feels good to me, and using macOS really doesn't, even after a year or more 'living in it' every day. Uniform, automated software management is at the heart of it for me. But regardless, using macOS doesn't really feel similar to using Linux to me, even with highly opinionated desktop environments which are not my favorites, like GNOME.
Re: Ask HN: How are you dealing with the M1/ARM migration?
#190On the whole it's been good. I work on scientific software, so the biggest technical issue I face day-to-day is that OpenMP based threading seems almost fundamentally incompatible with M1. https://developer.apple.com/forums/thread/674456 The summary of the issue is that OpenMP threaded code typically assumes that a) processors are symmetric and b) there isn't a penalty for threads yielding. On M1 / macOS, what happen…
Can you not do this using the CPU affinity environment variables and just ignoring the efficiency codes? I was under the impression you could bind to specific cores with: GOMP_CPU_AFFINITY=“1 2 5 6” With thread 1 bound to core 1, thread 2 on core 2, thread 3 on core 5, thread 4 on core 6. I don’t have an M1 to play around on but I’d have assumed that the cores are fixed IDs. Aside from that, if the workload is predic…
[deleted]