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.
> 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.
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.
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?
Readit News
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...)"
The "arch" utility is your escape hatch to switch the preferred arch for the spawned process and all of its children.
Thanks for sharing that will definitely come in handy!
> 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 Comment
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.
[1] https://wiki.gentoo.org/wiki/Project:Prefix
[2] https://github.com/fishman/timebomb-gentoo-osx-overlay
I moved over from Homebrew to Nix around 5 months ago, haven't since needed to use Homebrew except for casks.
[0] "Support for Apple Silicon (aarch64-darwin)" https://github.com/NixOS/nixpkgs/issues/95903
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.
Examples off the top of my head:
[1]: https://github.com/Homebrew/brew/pull/9172#issuecomment-7299...
[2]: https://github.com/Homebrew/brew/issues/9177#issuecomment-72...
[3]: https://github.com/Homebrew/brew/issues/9099#issuecomment-72...
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.
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.
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.
Deleted Comment
http://pkgsrc.org/
No binary packages yet, but using it from source is pretty much a matter of downloading and extracting the 'current bz2', then:
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: Full documentation, including on how to create your own packages:http://www.netbsd.org/docs/pkgsrc/
Current source works fine
file htop returns
htop: Mach-O 64-bit executable arm64
So this version of brew is compiling native arm64 code.
Zsh from Homebrew: /usr/local/bin/zsh: Mach-O 64-bit executable x86_64
Apple's Zsh:
The Homebrew team is making progress; I've been seeing Big Sur "bottles" for a couple of days now.https://github.com/Homebrew/brew/issues/7857
ffmpeg has so many configure options, I always avoid building it with brew.
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.
https://github.com/Homebrew/brew/issues/7857
But I still wanted ARM binaries, the ones I did (htop, imagemagick, tmux etc) all worked.
https://www.macports.org/install.php
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]
[1] https://developer.apple.com/documentation/xcode-release-note... under Apple Clang Compiler:
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)
[2] https://developer.apple.com/documentation/macos-release-note... under Kernel:
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)
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.
However, Parallels and VMWare Fusion will. You'll also have other solutions around.
Also, no App Store requirement on macOS at all.
--edit-- Sweet it works.
cd /Applications; ditto --rsrc --arch arm64 GarageBand.app GarageBand-arm64.app
You can boot either architecture from a Big Sur drive.