4 ms·

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

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 https://github.com/actions/virtual-environments/issues/2187)

brundolf 4y ago
> 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...
- michaelt 4y ago
  Alternative theory: Apple doesn't offer an M1 server. Github doesn't offer an M1 build server because M1 servers don't exist.
  - scarface74 4y ago
    Apple also doesn’t offer an x86 “server” yet Azure DevOps offers Mac build servers.
    - vchuravy 4y ago
      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
      - reaperhulk 4y ago
        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.
      - deleted 4y ago
        [deleted]
      - scarface74 4y ago
        This isn’t true. https://devblogs.microsoft.com/devops/cloud-hosted-mac-agents-for-ci-cd-pipelines/ 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
        Arnavion 4y ago
        Better link: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#hardware 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.
        agsnu 4y ago
        It sounds like they're just using MacStadium.
  - icedchai 4y ago
    AWS offers Mac M1 instances, using Mac Minis. It seems like Github could do it.
    - sofixa 4y ago
      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.
      - icedchai 4y ago
        True, but if they're "server enough" for AWS, I think that says something. The 24 hour thing is a problem though.
  - barkingcat 4y ago
    M1 Mac Mini farms easily solve that question
    - jpalomaki 4y ago
      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 https://www.apple.com/legal/sla/docs/macOSMonterey.pdf (Section 3.)
  - colordrops 4y ago
    You can't cross compile on an x86?
    - michaelt 4y ago
      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.
spockz 4y ago
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.
CoolCold 4y ago
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.

brundolf 4y ago

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

michaelt 4y ago
Alternative theory: Apple doesn't offer an M1 server. Github doesn't offer an M1 build server because M1 servers don't exist.
- scarface74 4y ago
  Apple also doesn’t offer an x86 “server” yet Azure DevOps offers Mac build servers.
  - vchuravy 4y ago
    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
    - reaperhulk 4y ago
      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.
    - deleted 4y ago
      [deleted]
    - scarface74 4y ago
      This isn’t true. https://devblogs.microsoft.com/devops/cloud-hosted-mac-agents-for-ci-cd-pipelines/ 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
      - Arnavion 4y ago
        Better link: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#hardware 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.
      - agsnu 4y ago
        It sounds like they're just using MacStadium.
- icedchai 4y ago
  AWS offers Mac M1 instances, using Mac Minis. It seems like Github could do it.
  - sofixa 4y ago
    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.
    - icedchai 4y ago
      True, but if they're "server enough" for AWS, I think that says something. The 24 hour thing is a problem though.
- barkingcat 4y ago
  M1 Mac Mini farms easily solve that question
  - jpalomaki 4y ago
    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 https://www.apple.com/legal/sla/docs/macOSMonterey.pdf (Section 3.)
- colordrops 4y ago
  You can't cross compile on an x86?
  - michaelt 4y ago
    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.

spockz 4y ago

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.

CoolCold 4y ago

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.