Live data from Hacker News

Ask HN: How are you dealing with the M1/ARM migration?

news.ycombinator.com

211–220 of 284 posts

Re: Ask HN: How are you dealing with the M1/ARM migration?

#211
post #197
post #189

Earlier quoted context omitted.

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…

If it was the exactly same thing it would have been called Linux :) You can bend the experience the way you like, you don't have to use it as-is. For example, homebrew can take care of the few of the complaints here. By the way, I thought that apps stopping working randomly was a Linux feature? Then you dive in to to fix it, not really an experience I miss. Also, hunting down software for Ubuntu 14.04 or 18.04 becaus…

> For example, homebrew can take care of the few of the complaints here.

Not really. Homebrew doesn't manage the operating system (which I understand is a desirable kind of separation for some users), and it's also just not comparable to Linux package managers in its technical aspects. The result is that it's just not as reliable, predictable, fast, or complete as virtually any distro package managers on Linux.

> By the way, I thought that apps stopping working randomly was a Linux feature? Then you dive in to to fix it, not really an experience I miss.

Apple takes a pretty radical position with respect to backwards compatibility on macOS, and this has some benefits for Apple as well as developers of greenfield projects on macOS, but it does have some downsides. One issue related to those downsides is that a huge proportion of macOS software aimed at power users whose purpose is to refine or extend the desktop experience relies on undocumented or unsupported APIs to achieve its functionality, because that's all that's available to that end. With every macOS release, such APIs are ruthlessly culled, and at least a few apps are either left without replacement or have to be completely rewritten. (The most annoying one which affected me when I was a daily macOS user was maybe the forced obsolescence of Karabiner, for example.) There's really nothing comparable on Linux, for a range of reasons.

> Also, hunting down software for Ubuntu 14.04 or 18.04 because something that works for one doesn't work for the other is a Linux experience.

That kind of thing can be a serious frustration with proprietary software that only officially targets a specific Ubuntu LTS release, and it used to be especially painful before the the availability of containerized app platforms like Flatpak and Snap. If your work requires you to use software that doesn't support your OS, that is definitely a problem.

> Often you don't have software that simply works on "Linux", you need to find it for specific distro and even specific distro version or compile it from source.

As they say, Linux is not an operating system. Distros are operating systems. Fragmentation is just the obverse side of choice here, but when the Linux userbase as a whole is so small, I get feeling frustrated by that.

As for building software that's unpackaged on your distro of choice: per-distro variations in build instructions are generally not an issue unless you're just following those instructions more or less blindly or by rote. Packaging software can be annoying on very niche distros with small repos just because you have to do it frequently, but it's pretty rare and not very hard to do for the vast majority of software. To me, it doesn't make much sense to choose a platform with inferior tools just because some software you like might be pre-packaged for it, when you can just choose a platform whose package management tooling you actually like, and package the few outstanding odds and ends you need on the platform. (This is generally how I think about choice of distro.)

> Linux is a horrible experience for people who see their computer as tools and don't really like to manage it and want to spend their energy on using that tool to do other things(like designing apps, studying some data, making videos etc).

I think this is really overstated and stereotyped. Even though I'm a Plasma user who has strong preferences for particular distros, you can stick me on any major Linux distro with any desktop environment, and even largely sticking to the defaults there will still leave me feeling much more at home than I can on macOS. It's not about time spent configuring or customizing, and it's not just about a compulsion to tinker, either. It's different, even if you stick to defaults and even across distros. It's a lot of little things but it really adda up to a whole different vibe.

I also want to say that I think the metaphor is misplaced. An OS is not a tool like a hammer is a tool, because it's a whole environment rather than an object. Your workstation OS isn't like a screwdriver or even like a toolbox. It's like your whole garage, your whole studio, the whole warehouse, the whole factory floor. It may not make a lot of sense to care about customizing one specific screwdriver. But caring about being able to freely arrange your workspace is pretty natural, and macOS' differences from Linux are a genuine, substantial culture shock when you're coming from Linux workspaces that have become cozy and efficient to navigate for you.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#212
post #152

There are many comments here that goes: "we had to do all sorts of configuration for this to work, but it's been great and we like it". As a primarily Linux user these feel like very familiar stories. It's kinda refreshing to hear those stories from mac users. Maybe we are not so different after all.

Mac-using devs are mostly Linux-using devs who prefer a non-free distro ;)

> Mac-using devs are mostly Linux-using devs who prefer a non-free distro ;)

A working GUI, to be exact. Source: switched to Macs from Linux in 2013.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#213
In our small backend engineering team, which also takes care of the DevOps work, we just have a multiarch docker image that we use as a base image to build the ARM local dev images and the CI/CD (running on amd64) builds the production images. Everything works flawlessly, docker knows what architecture to build in each case. There was some work we had to put into the base image to make it build multiarch, but then we basically forgot about it

Re: Ask HN: How are you dealing with the M1/ARM migration?

#215

I 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…

Hmm, docker is very buggy for my team and myself on m1. Coming from a x220 where it was flawless, on m1 it quite often just ‘dies’. When you paste the message you get when you run any docker command after that into Google, you see that many people have this issue and the fix is; restart docker. This didn’t happen under Linux. I am not sure if it did happen on x86 Mac as I never used docker there.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#216

Early 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.

They may feel snappy if you go 2G into swap. Not if you go 12G+. My normal stuff uses 20 G ram, and that's without any VMs on. No way that can run smooth on 8G physical ram.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#217

Earlier quoted context omitted.

Alternative theory: Apple doesn't offer an M1 server. Github doesn't offer an M1 build server because M1 servers don't exist.

You can't cross compile on an x86?

Some things can be cross-compiled, sure.

But a lot of projects have tests they want to run on their target platforms.

If you build your Linux release on Windows, you might accidentally release a .zip where your binaries aren't executable. If you set up cross-compiling to Mac 5 years ago and tested it then, perhaps in the meantime code signing has become mandatory. If you build and test on Linux and release to Windows, perhaps you'll get tripped up by filenames becoming case-insensitive.

Some projects are keen on testing on all target platforms to flush out issues like that.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#218
post #18

I tried going from a 2018 MBP to M1 MBA in 2021 and had too many issues to make it my primary machine. Docker and Android development were particularly brutal to get going reliably IIRC. The M1 performed well for the things it could do, but I still needed the MBP (which constantly reached 100% CPU) for other stuff, so I ended up doing a horrible multi-machine setup with Synergy. That was a dark time in my life ;) The…

> Docker and Android development were particularly brutal to get going reliably IIRC.

Android? Android Studio has problems? That would be vital to me if i went Mx.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#219
post #179
post #152

Earlier 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.

I do not find this at all; I use mac for the hardware (stopped using it for years because it got worse; with the m1 air it is top notch again); I do not like the OS coming from a linux background for over 20 years. Good graphical ui I could not care less about outside that, everything is mostly worse. I will install asahi immediately when it is solid enough. In the meanwhile I have to cope with half baked solutions like homebrew, but the hardware is simply unmatched (I have tried many alternatives), so overall it is a positive still. With Linux, this would be the best machine ever made. For me that is; others like UIs of course so then it’s a different story.

Re: Ask HN: How are you dealing with the M1/ARM migration?

#220

At least some aspects of this issue are getting better as we speak. The latest Mac OS (in beta) supports virtualizing ARM Linux but also enables the ARM Linux system to use Apple's speedy Rosetta 2 x86 binary compiler and JIT compiler to run x86 programs within the ARM Linux VM. Based on descriptions, it seems that the rest of the hypervisor VM framework has also matured substantially this release. https://developer.…

> It does binary pre-compilation and cacheing. It also works with JIT systems.

Much more impressively it also leverages a custom hardware x86-like memory model unique to the M1/Apple ARM chips. That's where most of the performance really comes from, as I understand it.

Post reply on HN