Stickiness of architecture is a change from how Rosetta worked in the PowerPC to Intel transition: in macOS Big Sur child processes will prefer the arch of the parent process if one is available to maximize compatibility. So for example launching x86_64 sh will cause a python invocation from that shell to also be x86_64.

The "arch" utility is your escape hatch to switch the preferred arch for the spawned process and all of its children.

Would be easy to make iTerm2 launch arch -x86_64 <shell>

I haven't tried this (don't have an M1 to hand!) but:

iterm2 -> Preferences -> Profiles -> General

Change the "Login Shell" drop down to "Command" and then enter `arch -x86_64 /usr/local/bin/zsh` or whatever your shell is.

Would `arch -x86_64 $SHELL` work?

In theory yes, since it inherits the shell env from the parent.

Haven't got the $$$ to test though.

EDIT: you could also craft an oneliner if $SHELL is not defined, something like:

`ps -T $$ | awk 'NR==2{print $NF}' | arch -x86_64 $0`

Just tried and it works :) .. Nice.

Well, this is something nice. Looks like it will help developers transition to the new architecture.

Does this make brew compile subsequent binaries in x86 though? Or is it purely cosmetic.

Homebrew maintainer here. We don’t officially support Big Sur yet, but installing it via Rosetta will cause it to fetch x86 bottles instead of ARM ones. At least, that’s the plan.

Off-topic: Thanks for working on Homebrew btw! It just occurred to me that I've never donated despite using it so much but now I have. Link for others:

https://github.com/homebrew/brew#donations

Thank you for the kind words, and for the donation!

Ah.. I've extracted homebrew manually and it's been compiling ARM binaries for me - which is what I wanted it to do.

If you’re ok with numerous formulae still breaking, you’ll be fine.

Seemed to work fine for me... I'm now trying to install both versions of brew and spin up terminal sessions accordingly.

Are these 'good practices' for Arm Macs?:

1) When spinning up an iTerm session, figure out if it's 'Darwin x86_64' or 'Darwin arm64' - and configure paths accordingly. so they use the right brew binaries.

2) Easily double check what version of a running package/keg based on what arch is displayed in Activity Monitor.

3) That way, you can just use brew with Rosetta to start (which I did) then build up native arm Brew over time. and let the Rosetta brew fall away.

Does this plan include differentiating at the Casks as well? (Thanks for the work on homebrew, I live by it - its key to my use of MacOS ..)

Casks are typically precompiled application binaries, and I assume most applications (that choose to support M1) will be Universal Binaries soon. Casks would not need to change anything.

Would you mind sharing how you disable that?

Is this actually GDPR compliant as it is?

  Homebrew gathers anonymous aggregate user behaviour 
  analytics using Google Analytics. You will be notified the 
  first time you run brew update or install Homebrew. 
  Analytics are not enabled until after this notice is shown, 
  to ensure that you can opt out without ever sending 
  analytics data.

That is from the Homebrew site.

If it doesn't ask for consent and stores PII then no, it's not.

Homebrew does not and has never stored any PII. You can read exactly what we store here[1].

[1]: https://docs.brew.sh/Analytics

It's a Google Analytics client (using curl), so they punt on the GDPR issue to Google, who has a little "scrub client IP" checkbox in GA, which Homebrew has checked.

This is fine, because Google can be trusted to come into possession of your uniquely-identified tracking data, and then immediately delete it, without letting military intelligence log it in the process. They have no reason to share it (other than the legal compulsion that FAA 702 provides) or keep it around, as it would not profit them in any way (other than their multibilliondollar advertising business).

Awesome! I didn't know that.

Thanks for sharing that will definitely come in handy!

Be warned that:

> Homebrew maintainer here. We don’t officially support Big Sur yet, but installing it via Rosetta will cause it to fetch x86 bottles instead of ARM ones. At least, that’s the plan.

It will create X86 binaries instead of ARM ones. (which might be a plus at the current moment)