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)
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 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.
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
cd pkgsrc/sysutils/nnn
bmake install clean
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:
/bin/zsh: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit
executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/bin/zsh (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/zsh (for architecture arm64e): Mach-O 64-bit executable arm64e
ffmpeg has so many configure options, I always avoid building it with brew.
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.
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.
how about stuff like python, webservers or java apps running in x86-64 linux docker containers?
very curious what the effects are of the new arch on common developer use cases. (without having to recompile/rebuild everything for apple arm)
The only problem I see is if you have a mix of different architectures wrt libraries.
No x86 virtual machines though. Apple doesnt allow emulation and virtualisation together.
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.
What are they?
We’re now using `/opt/homebrew` for the (still experimental) ARM native Homebrew flavour.
On Linux, you’re free to choose whatever prefix you like. On Linux, Homebrew always builds from source, no matter the prefix.
And for what I do, the default ffmpeg in Homebrew works fine.
yes, the drop shadow is automatic if you use the window capture mode.
1. Press CMD + Opt + 4 to enter selection mode
2. Press Space to switch to window selection mode
3. Hold Opt and click
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.
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`
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.
[1]: https://github.com/LnL7/nix-darwin/blob/master/modules/syste... [2]: https://github.com/nix-community/home-manager/blob/master/mo...
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.
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.
% sw_vers
ProductName: macOS
ProductVersion: 11.1
BuildVersion: 20C5048k
% ls /Library/Python/
2.7
% ls /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/
Headers Python3 Resources Versions
% ls /System/Library/Frameworks/Python.framework/
Python Resources Versions % 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
% /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'
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.