Comment by porcoda | Hacker News Reader

Comment by porcoda | Hacker News Reader

Parent Full thread

I'm in a similar boat - love the performance/battery of my M1 MacBook Air, but the ecosystem is just too messy at the moment for me. I have a few tools I need to use that haven't yet been making official Apple Silicon releases due to GitHub actions not supporting Apple Silicon fully yet. The workaround involves maintaining two versions of homebrew, one for ARM and one for x86-64, and then being super careful to make sure you don't forget if you're working in an environment that's ARM and one that's X86. It's too much of a pain to keep straight for me (I admit it - I lack patience and am forgetful, so this is a bit of a "me" problem versus a tech problem).

My solution was to give up using my M1 mac for development work. It sits on a desk as my email and music machine, and I moved all my dev work to an x86 Linux laptop. I'll probably drift back to my mac if the tools I need start to properly support Apple Silicon without hacky workarounds, but until GitHub actions supports it and people start doing official releases through that mechanism, I'm kinda stuck.

It is interesting how much impact GitHub has had by not having Apple Silicon support. Just look at the ticket for this issue to see the surprisingly long list of projects that are affected. (See: https://github.com/actions/virtual-environments/issues/2187)

I’m having the same issue on azure devops. The only way forward seems to be is running your own ado agents on arm machines you managed to arrange. Arm on Azure is a private beta that you have to subscribe for.

That wouldn’t be too much of an issue if you could just cross compile like you can with go. However graalvm can’t do this yet.

Can you describe in a bit more details on this case? I'm trying to understand for myself, would it hit any problem for our dev team anytime soon - so far I've heard no complains/requests from them about Apple Silicon - should we get prepared for that or it's very specific case?

In nutshell I don't see how having Apple Silicon locally makes the problem - if your non local env (dev, prod, stage) is running on x86 Linux or even arm Linux, shouldn't be any issue to build for that architectures on your build farms anyway.

I may be missing some important part here.

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

Apple also doesn’t offer an x86 “server” yet Azure DevOps offers Mac build servers.

Yes because Microsoft got a special license from Apple that allows for the virtualization of Mac OS on non Apple hardware...

The rest of us is still running on racks of Mac Minis

This isn’t true.

https://devblogs.microsoft.com/devops/cloud-hosted-mac-agent...

> Please be aware that during this preview, our Mac hardware is hosted in third party datacenters in the United States and your build and release data could cross geopolitical lines. After each build completes, its macOS VM is reimaged, leaving no trace of your data on the agent. For more information, see where VSTS data is stored. Our Mac datacenters will expand to other geographies soon

Better link: https://docs.microsoft.com/en-us/azure/devops/pipelines/agen...

>Agents that run macOS images are provisioned on Mac pros with a 3 core CPU, 14 GB of RAM, and 14 GB of SSD disk space. These agents always run in the US irrespective of the location of your Azure DevOps organization.

It sounds like they're just using MacStadium.

Do you have a source for this claim? As far as I’m aware Azure racks mac minis and has no special license, but I’d be fascinated to be wrong.

AWS offers Mac M1 instances, using Mac Minis. It seems like Github could do it.

Mac Minis aren't servers though - they suck in terms of redundancy, density, form factor, "lights out" management. It's fascinating the effort made by some ( like AWS, Mac Stadium, Scaleway) to try to force Mac Minis and Pros to be server-ish.

And Apple's EULA makes them basically unusable as short term rented servers, there's a minimum of 24h which is ridiculous.

True, but if they're "server enough" for AWS, I think that says something. The 24 hour thing is a problem though.

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.

M1 Mac Mini farms easily solve that question

The comments on the github issue claim Apple ToS says you need to rent the machine to customer for 24h at a time.

”(ii) each lease period must be for a minimum period of twenty-four (24) consecutive hours;

(iii) during the lease period, the End User Lessee must have sole and exclusive use and control of the Apple Software and the Apple-branded hardware ”

https://www.apple.com/legal/sla/docs/macOSMonterey.pdf (Section 3.)

Reply on news.ycombinator.com