7 ms·
There's also the "arch" command, to run commands under rosetta2 I just installed Homebrew on my new m1 MacBook Air with: $ arch -x86_64 /bin/bash -c "$(curl -
by ryancnelson 6y ago
There's also the "arch" command, to run commands under rosetta2
I just installed Homebrew on my new m1 MacBook Air with:
$ arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh https://raw.githubusercontent.com/Homebrew/install/master/in...)"
- Aperocky 6y agoDoes this make brew compile subsequent binaries in x86 though? Or is it purely cosmetic.
- woodruffw 6y agoHomebrew 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.
- Aperocky 6y agoAh.. I've extracted homebrew manually and it's been compiling ARM binaries for me - which is what I wanted it to do.
- Hackbraten 6y agoIf you’re ok with numerous formulae still breaking, you’ll be fine.
- frakkingcylons 6y agoOff-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 https://github.com/homebrew/brew#donations
- woodruffw 6y agoThank you for the kind words, and for the donation!
- sneak 6y agoPlease make Homebrew’s telemetry opt-in instead of opt-out. I encourage you to follow the good example of how Debian runs popcon (popularity contest). By having your default be assuming user consent to surveillance, you have produced spyware that reports a user’s track log history to Google via IP geolocation and a persistent unique machine identifier included with the request to Google Analytics every time the user installs a package using brew. I assume most Homebrew users are ignorant of this fact, because you never demanded informed consent before doing it. You are part of a troubling and growing trend of remote developers misusing the computers of their users simply because network requests are, by default, invisible to the user. Most users will never consent to such a thing if they are aware of it occurring. It would be quite nice if, in my new machine setup checklist, I not have to include separate steps to disable my package manager’s spying on my activities in addition to the steps I already have to take to disable the macOS’s spying on my activities.
- dividedbyzero 6y agoWould you mind sharing how you disable that?
- lightbulbjim 6y agohttps://docs.brew.sh/Analytics https://docs.brew.sh/Analytics
- Fnoord 6y agoIs this actually GDPR compliant as it is?
- disgruntledphd2 6y agoIf it doesn't ask for consent and stores PII then no, it's not.
- sneak 6y agoIt'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).
- somesortofsystm 6y agoDoes 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 ..)
- KMnO4 6y agoCasks 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.
- dgdosen 6y agoSeemed 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.
- JoshuaMulliken 6y agoAwesome! I didn't know that. Thanks for sharing that will definitely come in handy!
- Aperocky 6y agoBe 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)
- deleted 6y ago[deleted]
- xenadu02 6y agoStickiness 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.
- api 6y agoWould be easy to make iTerm2 launch arch -x86_64 <shell>
- unix-boomer 6y agoWell, this is something nice. Looks like it will help developers transition to the new architecture.