Warning: You are using macOS 11.
We (and Apple) do not provide support for this old version.
It is expected behaviour that some formulae will fail to build in this old version.
It is expected behaviour that Homebrew will be buggy and slow.
Do not create any issues about this on Homebrew's GitHub repositories.
Do not create any issues even if you think this message is unrelated.
Any opened issues will be immediately closed without response.
Do not ask for help from Homebrew or its maintainers on social media.
You may ask for help in Homebrew's discussions but are unlikely to receive a response.
Try to figure out the problem yourself and submit a fix as a pull request.
We will review it but may or may not accept it.
Yea the homebrew dev team is pretty user hostile tbh.
The more you read their github, the more you realize how insufferable and arrogant they are. It leaves a very bad impression.
Also, if you are not going along in the upgrade rabbit race, homebrew gets really annoying and actually in your way at some point.
I see myself moving to macports soon, if brew gets worse and the stability of my setup is compromised (lots of php versions with valet for example).
I guess brew is now more targeted at “prosumers” now since it is imposing unnecessary limits on what “pro” users want and need.
Of course the devs dont need to support everyone and answer every feature request.
Its more nuanced than that.
As a dev, i like a stable environment and i dont like to do big updates all the time, since that means i have to spend hours updating my setup again. Everytime i run brew im scared it will hose my PHP versions, etc, since it auto updates everything.
To install old PHP versions one needs to hack the install files to make it work.
If you bring up any of these issues you are screamed down by the devs as “you should always be on the latest versions anyway bla bla”… but that is just not a realistic scenario in the real world. Legacy code is everywhere.
In the end brew is not really for pro users, but, as i said, maybe for people using it to install youtube-dl or whatever.
Once the pain of reinstalling and hacking it to make it work becomes too big then i will switch.
I'm glad we have both Homebrew as well as MacPorts. It's like having options to choose a bleeding-edge or stable distro. I prefer the former (as a dev, who often wants to use reasonably new features and libraries - and honestly despite keeping up in versions I can count the breakage to my workflow in the past decade on one hand, at least I'm not a JavaScript developer) but I totally respect the latter as well, so I'm glad we can each have what we need.
The homebrew team seems incredibly burnt-out, to the point of hostility. I've really enjoyed the nixpkgs community so far and encourage others to check it out; it hasn't replaced homebrew entirely for me (yet), but it's getting closer every day.
I want to like Nix but those installation instructions for macOS (and their removal friend) are just crazypants as compared to the `sudo mkdir /nix && sudo chown $USER /nix` from the Linux version
And that's not even getting into the "waaa?" from `du -hs /nix` although I am open to that being a misleading number due to hardlinks and other trickery that du may not correctly surface
> And that's not even getting into the "waaa?" from `du -hs /nix` although I am open to that being a misleading number due to hardlinks and other trickery that du may not correctly surface
Nope, du counts hardlinks correctly when it encounters the same inode multiple times in the course of fulfilling a single invocation.
> Files having multiple hard links are counted (and displayed) a single time per du execution.
Nix's disk usage profile is pretty similar to Flatpak's, or to a collection of closely related Docker containers. The difference between no Nix install and having one isn't huge. But your first installed Nix package will pull in very low level common dependencies— on Linux, everything between whatever application and the kernel (and on macOS, a bit less). Your next application will come with a smaller increase. Once you have a handful of programs installed, you no longer have big downloads for individual additions. When you have a lot installed, the difference isn't that huge, proportionally.
Over time, your Nixpkgs version will rotate and you can end up with deps from old versions of Nixpkgs, which can take up a lot of extra space. But that's easy enough to manage by pinning Nixpkgs.
If you ever uninstall programs, Homebrew's broken uninstallation functionality can very quickly make a Homebrew installation much (up to several times) larger than the equivalent Nix one once you have more than a handful of packages installed.
Yeah, that's a long-running and pretty much unfixable issue as macOS updates overwrite /etc/zshrc. AFAIK, the determinate systems installer does somewhat resolve this as you can just run it again and it will fix the issue.
The default installer is not idempotent yet (and my work on trying to resolve that has stalled, unfortunately, see https://github.com/NixOS/nix/pull/7603), so trying to run it again to fix this issue will result in errors.
Yeah, I generally uninstall (with the remaining nix-installer binary on the nix volume) and then reinstall. It would be great if the installer were idempotent and I could just re-run the installer!
> And that's not even getting into the "waaa?" from `du -hs /nix` although I am open to that being a misleading number due to hardlinks and other trickery that du may not correctly surface
Are you running garbage collection? It gets out of hand if you keep all versions, but you don't need to do that
are we reading the same instructions? i struggle to see what makes a curlbash leading into a few interactive prompts “crazypants”; it's the same story with brew and gentoo prefix
One of the problems with OSS burnout is this many-to-one relationship with the users and maintainer. It’s sort of like the relationship between an outfielder and the bleacher crowd at a baseball game.
Maintainers get requests to do things they have no interest in, like maintaining software for OSes past a certain date. That doesn’t sound so bad, but there are a lot, and they can even be mean. The maintainer can block these users individually, but it’s different users all the time, so that doesn’t stop it.
So, the maintainer addresses the user base, the whole crowd all at once. The problem is most of these users haven’t seen these interactions, so the message seems hostile. Having someone say “I owe you nothing.” seems really weird when you’ve never asked them for anything. Or, if they list of all the ways and reasons for you to not contact them it looks hostile. The users don’t see the fan next to them throwing a beer can at the center fielder.
It's not burnout. The homebrew team have been insufferable and egotistical for a long time.
Max Howell (founder of homebrew) went to interview at Google, shoved a coding exercise back in their faces, made a snotty comment about how all the engineers at Google using Macs use his code and how dare they blah blah greatest engineer in the world blah blah, and walked out the door.
That coding exercise was likely given to him precisely because all the google engineers had a lot of experience using brew, or they did it as ego check to see if he'd be insufferable to work with.
Howell failed to realize that and instead went and bragged about it on twitter, almost certainly confirming for the hiring committee that things had worked exactly as designed.
Whole lot of fucking sass from a man who either didn't care or didn't know about the security implications of making a directory in the default path user-writeable, thus making probably hundreds of thousands of developer's systems less secure:
This is very reductive. For anyone not familiar with the story, Howell's experience at Google was the original source of the "Invert a binary tree on the whiteboard" meme. Opinions on his experience were all over the map, with very thoughtful people defending Google and other thoughtful people criticizing them.
And for what it's worth, Howell did say he regretted his tweet, and that he wasn't up to snuff technically (in the Quora link in a sibling comment to this one).
I am glad that there are people like Max Howell who write such (for me) great package managers. In opposite to what you write, here in a quote reply he comes across as very friendly: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
PS: if really a lot of Googlers use brew I hope they also generously support the project (do. Apple)
Macos 12 will run on most Macs from 2015 and later.
8 year old hardware isn't Earth shattering, but it's also not a "hostile" period of time for a non-commercial open source project to support. And it's certainly not "new hardware every year".
Completely agree. I have two perfectly good but now unsupported 5K iMacs from 2015 and 2017 in my household, both don't get any more upgrades. Heck, I would even pay up to 100 EUR/USD for longer support. But that's probably not a viable business case for Apple anymore.
Have you tried to install some Linux distro (like Fedora or Ubuntu) on it? If your workflow allows it, of course. I found how well Linux works on my relatively old Apple hardware. And I can use it most of the time, just need to learn some new tools, as many I’m familiar with are macOS only.
I know my way around Linux, as a server OS at least. The issue with switching is more about my previous investment in buying and learning dozens of third-party apps. I also must say that I value the integration between macOS and iOS a lot.
Once my (i)Macs stop receiving security updates though, I might try a Linux distro, just to give them a second life.
By upgrades you mean upgrades that change the major OS version, right?
Those both should still be getting security updates. Ventura just updated to 13.6 this morning, Monterey updated to 12.7 a few days ago, and Big Sur updated to 11.17.10 a little over two weeks ago.
Big Sur is expected to stop getting security updates in a couple months. Monterey will probably get them until sometime in the last quarter of 2024, which would be the end of the line for 2015 5K iMacs. 2017 5K iMacs should get Ventura security updates through the last quarter of 2025.
Indeed, and I hope Ventura will get at least two years of security fixes.
It's still my impression, that the 2017 Macs (sold by Apple well into 2018), should have made the cut for Sonoma. I don't even care about any of the new features. I'm more interested in bug and security fixes. So hopefully I have more time to hunt for the perfect display that can adequately replace the 5K 27" of my current setup. And I know there is the Studio Display. But that one is too expensive for me.
The lack of an iMac 5K replacement is basically the reason why I'm preparing to leave Macs and the whole apple ecosystem behind.
As far as I'm concerned, when the main use of your computer is focused around text, because of Apple technological choice when it comes to scaling for HiDPI display you need a 5k27" display if you don't to want compromise in macOS. Otherwise with a cheaper 4k display your choices are between a much reduced workspace or get constant font blurriness.
Windows doesn't have this problem and I say that as someone who has historically prefered how macOS handle fonts (still do but only on capable hardware).
The way I see things Apple is completely responsible for this problem and should also be responsible for providing a decent solution at a reasonable price.
But currently the cheapest option (Basic M2 Mac Mini + Studio Display + Keyboard & Mouse) 2642€ instead of the previous 2100€ (inflation is unhinged in Apple land) and on top of being much more expensive for a way more locked down configuration (previously RAM was freely upgradable and SSD upgrade was involved but doable) it is not faster in a way that match the price increase or even better than what Intel has been doing. In fact the truly faster is mostly single thread performance (42% better), multicore is a just bit faster (21%) and GPU is actually slower (-14%).
In other words : for much more money you gain a bit not in way that is change what it possible to do with the computer but you also lose in a way that make some things you could do before worse (gaming and generally). That is on a
Lifelong customer, got my first own mac at 15, which was an ibook and also my first personal computer at all. I also bought the second gen ipod (first gen didn't get much availability in france) and even imported the first gen iPhone
I too have been looking into what can replace the 5K 27" iMac display, because my 2017 5K iMac display has developed a column of bad pixels about 30% in from the right side.
It's been that way for about a year and a half now and has not gotten any worse so I don't think I'm in any danger of suddenly needing a new Mac. The way my iMac happens to be on my desk I'm directly in front of a spot about 30% in from the left and most of my main focus is on the left side, so the bad pixels aren't too annoying.
The 27" 5120 x 2880 display has definitely spoiled me. I want something with a similar density and not much bigger or smaller than 27".
These seem to be the choices currently:
1. Apple Studio Display. As you've noted it is expensive. It also comes with a stand that does not have a height adjustment. Add $400 to get it with Apple's height adjustable stand. (Or for $0 get it with Apple's VESA mount adaptor instead of the standard stand, and buy your own stand. If you can find a VESA compatible height adjustable stand for less than $400 this is cheaper than buying Apple's stand).
One thing to not if like me you would really like a monitor that you can keep using for a very long time is that in 2021 Apple made a change to AppleCare. It used to be that you could buy at most a small fixed number of years of AppleCare. Now you can keep renewing AppleCare indefinitely.
For the Studio Display it is $49.99 per year. If the Studio Display is fine for someone except for the price, it might be worth considering if that plus $49.99 per year, which should let you keep it working for a long time, would make it worth it.
2. LG UltraFine 27MD5KL [1]. Supposedly this is the same LG panel that Apple used in the 5K 27" iMacs. Just under $1300. Seems to get good reviews.
3. Samsung ViewFinity S9 [2]. This is new. $1600 so same as Apple's price for the Studio Display, but the S9 is height adjustable and VESA compatible so no paying extra if you want height adjustability.
LG UltraFine 27MD5KL is on my shortlist. One downside is that it hasn't been updated in a while. Upside is, you can get them second hand for 30-40% less than it currently retails for.
The Samsung display seems nice. But how long is Samsung going to support the devices OS? The price is also not competitive in my opinion. For 1600 I would prefer the Studio Display, even if it's not height adjusted.
I will probably wait for the next Mac mini model with the M3 SOC. Luckily I'm not in a hurry.
I have used it before and, in my experience and everyone else I know who has used it, the vast majority of time the newer versions run absolutely fine with no issues. Occasionally some newer features don't work, but I'd but confident that 2015/2017 iMacs would be able to run the latest version no problem.
I used Dosdude's patches to install Mojave on a 2011 Mac mini. That worked well. Thanks for mentioning OpenCore-Legacy-Pather. I have it on my radar, just didn't have the time to look into it more thoroughly.
My issue with Nix is that you are forced to install packages in a global location. Why is it that every package manager assumes I’m an administrator on my machine? Even if I am, how does it make sense to take over a global directory as a single user?
Nix leverages hardcoded paths inside the binaries and other outputs it builds in order to ensure determinacy. Nix packages are not always trivially relocatable. Consequently, reliance on the binary caches means different users have to rely on the same path to the Nix store, since it's part of all those outputs.
You can build Nix with a custom store prefix and run it that way if you're willing to build from source.
In practice, Linux users don't really have to contend with that tradeoff because you can relocate a Nix store wholesale using a bind mount, or a user namespace (unprivileged chroot), or various fakeroot tricks to run a Nix store in your homedir as if it lives in /nix. Unfortunately macOS just doesn't have any of those mechanisms.
If macOS some day gets first-class container support and, consequently, relevant user-facing primitives for user-mode chroot, then unprivileged, cache-friendly Nix installation methods for macOS will doubtless follow. I hope both happen!
I have a bad habit of writing user-mode when I mean 'unprivileged' in the sense of 'not as root' and I don't think the word really works that way. I did it again here! Whoops.
I think he may be referring to installing Nix itself, which does require root even if the intention isn't to install anything system-wide. I did once think about modifying the nix installer to let me set an arbitrary nix store because I wanted nix packages in a docker container I was debugging, but never really got around to it. Let me know if you know of somebody else who tried this.
So this is possible, but there are a lot of caveats. First, the installer itself explicitly says:
```
# Please don't change this. We don't support it, because the
# default shell profile that comes with Nix doesn't support it.
readonly NIX_ROOT="/nix"
```
I haven't seen any configurations where the entire /nix is relocated, but nix _does_ support relocating the store with the environment variable `NIX_STORE_DIR`.[1]
However, this means that you can no longer use the the binary cache and *everything* you install has to be compiled from scratch, including glibc. The reason is that nix usually patches paths like `/bin/myprogram` to `/nix/store/1238f...-myprogram-1.2.3/bin/myprogram` in everything that depends on `myprogram` during build time to isolate the build outputs from the system. If you change your store, all those paths will now be invalid, including the hash part.
So using a nix store that isn't `/nix/store` is possible, but I don't think anyone is actually doing it except in a few select scenarios.
You can also compile nix itself with a different root. That will work as expected, but you still have the issue that you need to compile everything you install yourself.
Now that's interesting. I use Homebrew in a similar way. It does mean I have to compile a lot of things from scratch, but Homebrew has knowledge of which packages are relocatable and which aren't, so I get to use binary "bottles" for about 25% of the packages I install. I'll have to give this a try.
Homebrew is the same, there is no good way to have Homebrew installation shared among multiple users on a single machine, much less to have separate packages for each of them.
Agreed, but it's at least possible. My usual install is just cloning Homebrew to ~/homebrew and setting up a symlink. It's far from ideal, due to the number of packages I need to build from source, but it works, and it's allowed me to function normally in tightly controlled environments.
As far as I can tell, the initial installation for Nix doesn't allow this, though iFreilicht pointed out some options that I haven't seen before, so I may be wrong.
These warnings keep getting longer every homebrew release. You may want to try macPorts, which goes out of their way to explicitly support releases all the way down to 10.5.
One of the cooler experiences I've had with MacPorts was seeing some people go out of their way to ensure builds still worked on PPC Tiger and PPC Leopard.
I remember seeing SBCL builds broken on Darwin/ppc for a long while, and eventually SBCL decided to drop support for Darwin/ppc altogether. Still, these ports maintainers did not give up and eventually found a way to fix SBCL builds on PPC: https://trac.macports.org/ticket/65484
I recall seeing some work to bring back PPC support upstream, but I am not sure what the progress on that is. It's still cool seeing downstream users fix builds that simply didn't work (and to the point where upstream decides to remove support entirely since they couldn't build it anyway).
the issue i found is that you have to basically rebuild your basic unix network tools from the ground up, including ssl and curl and so forth, because the TLS version used by the builtins on 10.old.whatever, not to mention the certificates, no longer work with modern websites and FTP sites are slowly dying off. then you have to figure out which version of those tools are compatible with each other and with 10.version.you.are.using
there are a lot of scripts out there to mitigate this but the boot-strapping is always a bit of a bother. like the script i wrote, my first instruction was "So... you go download chrome for 10.x for PPC... you can find it here in the old forgotten wasteland of google on a deserted old site that might not exist much longer... and by the way this is not secure at all"
like, you just cannot do this securely. cellularmitosis has made leopard.sh linked below, of course the first step is to download from an http site.
its kind of one of those things that have changed about the web, the cultural shock.... nowdays basically so much is based on an account, or at the very least ssl. back then nobody gave a **.
so to actually use a g5 on the modern web, like ... can you log into a video site to watch a video? well only if you dont care about being hacked when you type in your user id and password to the video site. can you shop? only if you dont care about being hacked. same.. can you browse literally anything? google will constantly harass you into logging in. so will basically everything else. and if you dont your experience will suck.
can you... write code for a g5 and try to back port modern algorithms to it? sure just log in to .. .github... on your.. insecure machine that could easily be hacked. and lose your github account to hackers. then you can cry about it after you login to social media. on your hacked account. so maybe not. then you can post about it on hacker news... where of course your account has been hacked by a keylogger.
if your machine doesnt crash because someone installed a bitcoin miner into it, or a tor node, or bittorrent or god knows what that could get you arrested.
the modern web is just such a pile of degenerate criminality and scammers and thieves and robbers, not to mention the spy agencies of various governments, that basically that is the main thing driving old systems off of it. its not that its not possible to optimize code or write new code for old platforms. its that the basic machine running an old OS is compromised at a fundamental level, open to the world for exploitation if you dare to type anything into it that is the least bit private or confidential, and its connected online.
100%! Jordan Hubbard co-founded FreeBSD, created the original FreeBSD ports system (on which the entire idea of package management is based), then worked on the BSD technology team at Apple where he made MacPorts.
port is the standard macOS package manager! port is the standard macOS package manager! port is the standard macOS package manager!
Wow! That's quite impressive. Meanwhile there was a latent bug in the Homebrew formula for Rust that affected 10.13 for a year until I finally spent a few hours to investigate it.
"If you see a Homebrew maintainer walking down the street in your direction, find the nearest wall and bury your face in it in shame and deference until they pass."
That's probably because MacPorts was built by (and for) actual Apple employees, whereas Homebrew was built by someone unrelated who even had to start his own company because FAANGs wouldn't hire him.
But they are definitely at the top end of the compensation and job-security scale, which someone responsible for such a popular piece of infrastructure surely deserves.
All I see is, they protect themself from each and every script kiddy that runs to reddit or github when something doesn't work because of their own config issues.
There are two versions of Perl, awk, and Ruby in a fresh Sonoma install. I would say that moving Python away into XCode tools was an easy thing to do, but to rip the others away, it will take quite an effort.
I predict that Apple will admit defeat at the very least with Perl, one of the biggest beneficiaries of the Lindy effect. It has entrenched itself so much that you won't just yank it away without some serious bleeding.
Also, there is jsc if JavaScript is what floats your boat, although it's buried quite deep.
Oh oh, it's getting closer. Currently on MacOS 12 with my trusted 2015 Macbook Pro. It still goes strong, but looks like the next major release may see the end of homebrew for this one. There's really no issue with this computer other than 16gb of RAM being a bit tight when every modern app is using Electron. Oh well, see how we go.
(Message also for your parent) Last week, I saw the writing on the wall. I installed OpenCore-Legacy-Patcher on two MBPs from 2015, updating 12.7 to 13.6. It is a MBP 13" 2015 (early 2016 variant) and a MBP 15" 2015 (late 2015?). Works very well but you need to follow the guide. Both machines are still working well, 'cept for the battery (already replaced on the 13"). Esp the 15" is still in good condition, my wife happily uses it and insists on needing a 15". So a replacement would be expensive.
Can confirm Ventura runs great on a mid-2015 MacBook Pro 15 inch (MacBookPro11,4). Mine has 16gb of RAM and an i7 which probably helps (also added a modern 1tb NVMe drive via an adapter). I use it for a dedicated music production setup and only ever hear fans when installing something or during updates.
My only advice for someone new to OCLP/unfamiliar with Mac boot loader in general (like me one week ago) is that the OCLP boot screen during setup looks very similar to the native MacOS boot picker and went through four different flash drives trying to follow the instructions thinking it wasn't booting properly from the drive. Look closely at the instruction screenshot to distinguish them.
You can just build the latest tarball from source with `./configure && make && make install` [1]. I did so just now without any issues. (You’ll need to install Xcode and the Developer Tools first if you don’t have them already.)
I remember this being a huge issue with MacPorts. It would never keep up with the damn releases, so if you were working on a beta OS, you were hosed until they caught up.
It is, but it is mostly an issue with not having enough resources for the prebuilt images. They haven’t released a package installer for Sonoma yet, but AIUI the minimal required fixes have been in the MacPorts core for several weeks.
There are likely to be more issues related to Apple's switch to the `prime` linker.
(I’m a port contributor and am on macports-users where this issue has come up twice. There is what I think is excessive concern about the macOS beta NDA preventing the creation of a package installer until after GA when it no longer applies. A bigger problem is the availability of sufficient build hardware as they have a smallish Mac mini multi-booting into 11, 12, and 13.)
I've been using MacPorts on beta releases for the last several years, and it does a pretty decent job. I wouldn't say it's significantly behind the competition.
Why would anyone hate homebrew? The only issue I had was a few years ago when they changed from running as root to running as user and it broke some permissions. Then they released a guide on fixing the problem and that was it.
More recent packages, for one. I need to use Ubuntu 20.04 for work, and it's easier to get the latest versions I want from linuxbrew than from apt. E.g. clang is on 10.0 from apt and 16.0 from brew. Similarly, fish is 3.1.0 vs 3.6.1.
The Homebrew UX is great as long as you're on their happy path. Speaking from experience, as soon as I see the warning message I shared at the top, Homebrew gets way worse.
For instance, installing ripgrep now requires building the latest version of Rust from source, which takes three hours per Rust version; installing Pandoc requires building and storing the whole GHC; etc.
macOS or MacOS but never MAC OS or MACOS. MAC is an acronym for Media Access Control (as in: MAC address), Mac (or mac) is an abbreviation of Macintosh.
I'm surprise Apple doesn't, even unofficially, upstream fixes to Homebrew before a new macOS version is released. Why let Homebrew break for so many macOS users on day 0? I know Apple is secretive about unreleased products, but the type of fixes for Homebrew wouldn't reveal too many Apple secrets. Do Apple engineers not use Homebrew on their own Macs while developing macOS?
I see other replies as well, but I just want to tell you guys I came here to recommend mac ports. It’s a shame brew is so popular and mac ports having only a fraction of that attention.
I assume that the message means that Homebrew is incorrectly identifying the installation of MacOS Sonoma as “out of date”, and that means updating Hombbrew is a side-effect of updating the OS.
Once again a good time to remember that there were multiple perfectly good package managers available when Homebrew was invented, they were more future-proof (by eg not putting files in /usr/local), and everyone only switched to it because for some reason Ruby programmers wanted all of their tools to be written in Ruby (and possibly by people with waxed mustaches.)
I switched to it because it worked much better out of the box and required next to no fiddle-fucking to install tools I need, so I can spend my time doing what I'm actually paid for, and good at. I have no idea whether the alternatives improved in the intervening 10-ish years, any I have no good reason to look into it since homebrew still works.
That's great until homebrew breaks in some fucked up way (which a few years ago it used to do often), or they break a package (ditto) and you try to report that to them, and they act like insufferable little shits back (and don't fix the problem.)
It reminds me of my boss emailing gnu.org to tell them one of their mirrors was down and got a nastygram back that said "It's spelled GNU/Linux" and the mirror went unfixed.
I don't care what language Homebrew uses, it just works. When I got my M1 MacBook in 2021 I saw some of this negativity about Homebrew, and since I was doing a clean install anyway I decided to try out MacPorts. I quickly ran into problems and switched back to Homebrew and it's been smooth sailing.
What problems did you run into? I've been using MacPorts for years at this point since Homebrew can never seem to install libraries in a way that pkg-config, gcc, and ld can find them. (Yes, I'm aware there is a subcommand in brew to manually print the paths to libraries, this is still not ergonomic compared to MacPorts where I install a library and it more or less "just works" when I want to use it).
Also, Homebrew attempting to nuke /usr/local on uninstall left a quite bad taste in my mouth. I had installed MacTeX before Homebrew, and thankfully MacTeX had proper file permissions set up, so my TeX installation was left in-tact. Still scary knowing that this is just done in the background without warning (unless the operation fails with errors).
It makes a mess out of iconv because it's not compatible with the OSX bundled version. Without digging into it further it seems like the macports iconv headers and libraries shouldn't be in the default search path.
Ultimately users will go where the package maintainers are. There are more people out there willing and able to write Ruby today than Perl (Fink) or TCL (MacPorts).
I'm sure someone will start a macOS package manager based on python and yum to signal the waning days of those technologies.
MacPorts has 36k active ports. Estimates I see online for the number of Homebrew formulae are less than 5k. TCL isn’t difficult to write and most Portfiles are just a bunch of whitespace-aligned key-value pairs.
I'm secretly hoping for a makepkg / pacman-based replacement to homebrew, to have the same set of commands and package naming conventions across mac / win / linux
I switched because Macports reliably borked itself doing ordinary operations every 4-6 months, and Brew didn’t. That was like 2012 to be fair, but Brew’s never given me much trouble and the package selection is insanely good, so I’ve had no reason to look at other options since.
Its being in ruby is a strike against it, for me. I use it anyway. It’s probably my favorite package manager, all things considered, and I’ve used a lot.
Homebrew built almost everything from source back when everyone was already migrating to it. Fink and MacPorts being frequently broken was really the big driver, IMO.
As for why Homebrew packages seemed to be broken less often, I can only speculate. At least one big benefit it had was being on GitHub. A lot of folks were already familiar with how to cut a PR. Not so with how to submit a Portfile patch to the MacPorts Trac.
I'm sure some Ruby programmers were attracted to Homebrew because it felt more familiar than something written in a language like Tcl.
But Homebrew's fundamental tradeoff w/r/t purity was also a huge boost to installation speed at a time when most package managers for macOS still required you to build most things from source.
That and the slick, user-friendly UI were probably the biggest factors for Homebrew's success when it came out.
I use both MacPorts and Homebrew. By and large, I prefer MacPorts (because I can pin a package and it will stay pinned, whereas Homebrew will upgrade a package if it happens to be a dependency of something else) but there are numerous packages and casks only available in Homebrew.
I wonder why there aren't more "casks" for MacPorts. On my work MacBook, I've got Firefox, Google Chrome, Orbstack, and Visual Studio Code installed via brew casks, and none of them are present in the MacPorts catalog. Maybe I should step up and learn how to package things for MacPorts...
I think that, by and large, MacPorts wants to ultimately build things. I was just looking at the MacVim port and it does not have a way of downloading the Release from GitHub (as far as I can tell). It will download a precompiled binary from the MacPorts build farm, but it has Sparkle disabled, etc., so it is managed fully from MacPorts.
It would be an interesting discussion to have, as they do have some of that sort of thing (the 1Password CLI, for example), but I don’t know what the general policy would be.
I’d love to see MacPorts get more funding for build resources and to potentially add that, because the way that Homebrew works occasionally leaves things broken (`pipx` venvs are a great example).
