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.
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:
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.
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.
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.
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).
> 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)
I wonder if Nix on macOS could become a better homebrew-killer by supporting Apple Silicon first. We already do aarch64-linux natively and some iOS cross compilation, so that should give us a head start.
I was using gentoo-prefix for the longest time on MacOS.
I never got why homebrew got so popular given how terrible it is. But it was more accessible to people unfortunately. I spent some time trying to become a Gentoo developer for a while and then just gave up because there was no response.
I used to updated the clang patches to make newer clang versions compile things on osx before most of those things made it upstream.
I think it's vastly superior to macports and while I find nix interesting I don't really find it that practical. I think what makes homebrew more popular than the rest is how many precompiled packages exist. If gentoo-prefix had the same amount of precompiled packages, then I'd think it would definitely be much better for most users.
Installing a package is enough. For example, if you install the emacs package, Emacs.app would be available in ~/.nix-profile/Applications/Emacs.app.
If you want to launch apps you've installed with Nix using Lanchpad or Spotlight, you can use nix-darwin[1] or home-manager[2] to create a symlink in ~/Applications, though the latter seems to have temporarily disabled this feature due to conflicts between the two.
> Installing a package is enough. For example, if you install the emacs package, Emacs.app would be available in ~/.nix-profile/Applications/Emacs.app.
Right. I'm using home-manager on darwin and various apps like Emacs, Alacritty, Kitty are supported. However, many GUI apps are not, such as Firefox, so that's why I'm still using Homebrew's cask.
I'm glad I'm not the only one hating homebrew. It's become very anti-user in the past few years under the new maintainers. Even the original maintainer has said publicly that he doesn't like the direction the new maintainers took homebrew. All the changes the current maintainers of homebrew have made have been in the direction of "make maintaining homebrew easier so we get less questions" without any thought to the user experience those changes cause.
> without any thought to the user experience those changes cause.
Sorry you get that impression. As one of the maintainers, my impression is that each decision happens in good faith, and usually follows a controversial discussion, which puts user experience on par with maintainers’s well-being.
That’s not to say your feelings aren’t valid. I can see how some unpopular decisions may come across as rude, thoughtless or selfish. I’m aware that this is still a huge issue, and my feeling is that we still have a lot to learn in order to get better and more transparent at communicating.
I’m thankful for feedback like yours (even though I strongly disagree with the part that I’ve quoted). You can be sure any such feedback has a real, positive impact on where we’re heading as a project.
What we need is a cross platform package manager that installs stuff in the same place and make stuff behave the same, so shell configs can be unified between OS and not have "if" all over and expect same environments.
nix is almost that, except some packages are too old but otherwise, I have it running identically on macOS and Linux.
Homebrew puts stuff in some weird location that is /home/linuxbrew/.linuxbrew/ on Linux and that alone puts me off and it breaks if I change that location. No idea why they don't just use a path like /opt/homebrew/ for both OS and be done with it.
Over here I’m dying to port ArchMac to aarch64, which should be reasonably quick... if I had access to Apple Silicon hardware.
Being a lonely maintainer means I’m a bit (a lot) late on package versions and some areas are hacking, but it works on Big Sur already. But then again I’m also most probably the sole user and only target audience given the popularity of alternatives.
No binary packages yet, but using it from source is pretty much a matter of downloading and extracting the 'current bz2', then:
cd pkgrsc/bootstrap
./bootstrap --prefix=/opt/pkg
The default prefix is /usr/pkg, but that's protected by macOS' SPI. You might want to add /opt/pkg/bin and sbin to your $PATH. Then to install a package:
cd pkgsrc/sysutils/nnn
bmake install clean
Full documentation, including on how to create your own packages:
Thanks so much for the comment - I was trying to do that with the stable source yesterday evening with no success. Saw your tweet too, but don't have Twitter to ask you over there.
That's not needed though, I manually extracted brew to /opt/homebrew per https://docs.brew.sh/Installation, and it works just fine in the native terminal.
file htop returns
htop: Mach-O 64-bit executable arm64
So this version of brew is compiling native arm64 code.
Keep in mind that if you're using a Homebrew version of something Apple ships with macOS, for now, you'll get x86-64 binaries while Apple's version is a universal app and will run natively on the M1.
Zsh from Homebrew: /usr/local/bin/zsh: Mach-O 64-bit executable x86_64
No, not even close. There is more that doesn't work than works. Of what I use, all I got was python3 and git. But no python3.8, no ffmpeg, no erlang, no gnutls, and on and on.
I looked through brew.sh. Apologies if I'm missing something, but I don't think I am.
There's something really offensive about apple being too cheap to just pay some homebrew devs. And dumping the work of the arch swap onto charity effort.
I just linked you to the official page which shows what works and what doesn't work, and your response is that you're still right and everything works?
Not all the ports in macports are big sur ready for x86.
There are some dependencies in autoconf about warnings vs errors in defining implicit functions that has caught out some ports and others that use the "search for the .so" instead of dlopen to check for a library.
clang now defaults to error if you turn on the implicit-function-definition warning. [1]
Big Sur doesn't actually store the .so files for system libraries, it has one big .sym/.so for all of them. [2]
Clang now reports an error when you use a function without an explicit declaration when building C or Objective-C code for macOS (-Werror=implicit-function-declaration flag is on). This additional error detection unifies Clang’s behavior for iOS/tvOS and macOS 64-bit targets for this diagnostic. (49917738)
New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)
AS has support for virtualisation so VirtualBox will probably make it, but most likely only for running operating systems that run on ARM. There's very little preventing VB for being used as a tool to run the ARM versions of Linux or your favourite flavour of BSD, but Windows probably won't work (not until MS releases a download for Windows on ARM, at least). So, VirtualBox itself will work, but using it to run Windows applications won't.
The same is true for Docker, when someone gets a Linux VM to boot, Docker becomes a possibility just like on a normal version of macOS.
In the end I think it's only a matter of time before someone manages to combine Rosetta and virtualisation instructions (even though Apple says they don't support it) and fast-ish x64 emulation becomes a possibility. It will likely require some huge hacks that won't be allowed into the app store, but if Apple doesn't lock down the platform more with upcoming OS releases, developers and other technical-minded people will run that stuff just fine.
Huh, so Apple is installing both the ARM and x86 version of apps, even on ARM computers. I guess that makes sense for portability, but I don't know if other parts of the root filesystem are one architecture only, such as the path to the kernel (unless that's a fat binary too?).
I good case where this would be necessary is if anything has in process plugins - I saw at least one review where the person had to restart their app (final cut maybe?) because the codec was an x86 binary - which it seemed to do more or less automatically.
Would running X86 require licensing? If Intel doesn't say anything then could Apple in a couple of years develop their own X86 CPU by turning Rosetta into a hardware solutions?
Technically it should be possible - as Transmeta has done something similar, but cannot find if they got a license from Intel or it was not needed.
https://en.wikipedia.org/wiki/Transmeta
It’s likely not what Apple needs, though. They probably need a solution they can maintain long enough to let the transition through, but not any longer. They’d drop support for x86 as soon as enough applications gain support and existing x86 products get dated. Maybe 5 years?
Apple deprecated direct access to system-provided interpreter installations, which is a good thing. Interpreter support was not and will not be a problem, the implication of the deprecation is you should install your own copy of those interpreters instead.
Yes, I understand that we can and should always install our own, and I have for years either with Homebrew or Conda. (Actually most of my development is python on Linux via Vagrant).
But on the M1 Mini, out of the box, you can open Terminal, and python3 launches the Python 3.8 REPL. Python 2.7 also launches out of the box. So, can you explain what you mean by "direct access" not being allowed? I'm not following your distinction.
It's damn convenient having python always available when managing a fleet of Macs with JAMF.
I can imagine many existing tools still rely on the commands being directly accessible on PATH, and Apple may be reluctant to break them outright even that’s the goal. They are declared deprecated so people would refrain from using them for new things, and move old things away from them. That’s basically what deprecation means in software, as I understand it. Those commands wouldn’t be called deprecated if Apple breaks them outright.
Ok. Well, I don't have the Xcode command line tools installed. This is what I see:
% ls -l /usr/bin/python*
lrwxr-xr-x 1 root wheel 75 Jan 1 2020 /usr/bin/python -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
lrwxr-xr-x 1 root wheel 82 Jan 1 2020 /usr/bin/python-config -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
lrwxr-xr-x 1 root wheel 75 Jan 1 2020 /usr/bin/python2 -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
lrwxr-xr-x 1 root wheel 75 Jan 1 2020 /usr/bin/python2.7 -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
lrwxr-xr-x 1 root wheel 82 Jan 1 2020 /usr/bin/python2.7-config -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
-rwxr-xr-x 1 root wheel 137536 Jan 1 2020 /usr/bin/python3
lrwxr-xr-x 1 root wheel 76 Jan 1 2020 /usr/bin/pythonw -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7
lrwxr-xr-x 1 root wheel 76 Jan 1 2020 /usr/bin/pythonw2.7 -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7
% ls -l /usr/bin/pip*
-rwxr-xr-x 1 root wheel 137536 Jan 1 2020 /usr/bin/pip3
I had assumed that /usr/bin/python3 was part of the system, since it is not a symlink. But then when I do this, I see it is indeed hitting Xcode:
% /usr/bin/python3
objc[12852]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x20ab7e7a0) and ?? (0x1143782b8). One of the two will be used. Which one is undefined.
objc[12852]: Class AMSupportURLSession is implemented in both ?? (0x20ab7e7f0) and ?? (0x114378308). One of the two will be used. Which one is undefined.
Python 3.8.2 (default, Oct 2 2020, 10:45:41)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print(os.environ['PYTHONPATH'])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/os.py", line 675, in __getitem__
raise KeyError(key) from None
KeyError: 'PYTHONPATH'
So Xcode is definitely involved.
EDIT: So I uninstalled Xcode. /usr/bin/python3 is there, but it is clearly a stub file of some sort. If you run it without Xcode or Xcode command line tools installed, you get a popup to install the command line tools. So python3 is not part of the system, but the stubs for it are. Thanks for the patience.
Even more interesting, if you have Xcode, but not the command line tools, the stub launches Python3.8 from the Xcode installation. Once you install the command line tools, it then switches to launching that version. Presumably this is all because of the read-only system volume.
I'm trying to run some python code (from Pycharm). Since the specific version of tensorflow i need is not compatible with M1, I already get stuck at import tensorflow.
How can i tell my mac to Rosetta 2?
I know when I want to run something specific from the terminal, I can use "arch -x86_64"... but what do I do here?
i guess the gcc bench confirms, "yep, it's not native." cool that they do as much transpilation as possible at install time, and then jit the rest at runtime though. i'm curious how this all works in context of linux container runtime and if there are additional overheads...
all that said, i think the big screwup here is that the SoC only supports two displays where the intel chipset supported three or four. only being able to drive a single external display (after years of supporting multiple) is pretty bad, i doubt jobs would have let that one slip... (no matter how much cool engineering went into making the arm arch a reality)
I haven't kept up too much about how they did this. Is this ultimately just about faking uname(2) in the homebrew scripts? I would imagine Apple would make the mach-o loader transparently run rosetta when they see an x86 binary in response to execve(2). In other words, why doesn't it "just work"?
Homebrew is just Ruby, so there’s no way for macOS to independently know that it should present a fake x86 system to this particular Ruby script (or shell script). But when you run an x86 binary, it should just work like you describe.
This is because it tells Terminal (a universal binary) to launch in Rosetta, which will impose the preference on anything run inside of it. By default binaries with an arm64 slice will launch that preferentially.
when software like brew finally becomes available on Apple Silicon natively. How can I delete all this stuff I need to download under Rosetta? I don't want to have duplicate stuff
FWIW: The guidelines ask you not to post comments like this --- they attract lots of attention, because more people have opinions about the arrow keys than about how to run x64 apps on ARM processors, but it's a Notion page and the author doesn't control what Notion does with the arrow keys, so this comment adds nothing to the thread.
Right, I didn't know what Notion was and since the author posted in the comments too I thought this was the author's personal blog or something.
Indeed, I got way more upvotes for this than for any other comment I posted recently (currently 13 points, edit 1 hour later: now 5 points. But usually 1 or 2, or when I'm lucky 3 points). People: don't upvote comments like mine :p
Notion is a notes app first and foremost but it’s possible to post a link to your notes publicly. It’s a neat feature but I didn’t realize they did that to the arrow keys
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/in...)"