Possibly helpful to some macOS folks: I converted all of my cronjobs to launchd agents/daemons and the increased dependability has been helpful, since I use a laptop which sleeps a lot.
What I mean: "Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the computer wakes up. If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep."[1]
I wanted to comment about this as a LPT because of past experiences, then went to run `brew update` and `brew upgrade` which took more than an hour because it had to build a new version of LLVM from source... Then I ran `brew cleanup` and boom, 4.4GB of free space on a MacBook Air with a small disk.
Overall I hate how slow brew is, especially `update` should be 10x faster, it should maybe warn about source builds that could take forever, and it should maybe give a summary like `apt` whether there are packages to be `autoremove`d.
Upgrading Postgresql between major version requires previous version to be installed[1]. With auto-cleanup, when new version is installed, old will be uninstalled automatically, unless they added some exclusion mechanism for it, but I don't see anything about it in "postgres" formula[2].
I really wish these release notes would explain what is going on for people who don't know the internals of homebrew. Especially since homebrew force-updates itself and there's no way for users to avoid these changes.[1]
There are several updates in here that make me worry that this is somehow going to break my environment or otherwise bite me in the ass when I do something innocent like install Ghostscript and find that Emacs no longer works and to figure out how to fix it's going to be hours of reading github issues. Which is an experience I've had before, repeatedly.
"brew update no longer migrates legacy keg symlinks, tap names, repository locations, cache locations or cache entries."
Is this going to break something I installed years ago? Maybe the homebrew maintainers know, but average tool users don't.
"Homebrew/homebrew-core requires all formulae to be open source by the OSI definition."
Does this mean that something I used homebrew to install in a previous version will no longer be getting updates? Will things that depend on it still be getting updates? Does whether or not updates happen depend on some random committer's legalistic interpretation of an open source definition? Why exactly is this kind of purist decision being imposed on users?
[in 2.0]
"brew cleanup will be run periodically and for trigger individual formula cleanup on reinstall, install or upgrade. You can enable this behaviour now on 1.9.0 by setting the HOMEBREW_INSTALL_CLEANUP variable."
So you're going to periodically make maintenance changes to my system without my permission. Goodie.
Someone really needs to write a guide to migrating away from homebrew for people in the unfortunate situation of having used this tool for a long time, and find it taking more and more liberties with one's computer, but also having numerous essential packages now managed by it and not sure how to move to alternatives without weeks of breakage.
> Especially since homebrew force-updates itself and there's no way for users to avoid these changes.[1]
This is not true. `man brew` documents how to disable auto-updates.
> Why exactly is this kind of purist decision being imposed on users?
Because there's a lot of current debate about whether things being relicensed under the Commons Clause is "open source" or not and we'd rather lean on an established, well-documented authority on what that definition is. Additionally, part of our agreed membership of the Software Freedom Conservancy (who help us with a lot) involves ensuring our core formulae are open source software.
> So you're going to periodically make maintenance changes to my system without my permission. Goodie.
Again, `brew man` documents how to disable this.
---
The complaint behind the individual complaints is "why doesn't Homebrew work the way I want it to". That's a reasonable complaint and there may be better tools for you to use rather than Homebrew but we're going to continue to build Homebrew to work in a way that works best for the majority of our users and avoids our (entirely voluntary) maintainers having to deal with the same issues again and again.
>So you're going to periodically make maintenance changes to my system without my permission. Goodie.
I suspect this is partly because the cache can consume a huge amount of disk space over time and many users might never run `brew cleanup` or doesn't even know about it. And then wonder where all their disk space has gone.
> "brew update no longer migrates legacy keg symlinks, tap names, repository locations, cache locations or cache entries."
The biggest thing that has kept me on MacPorts and away from Homebrew is that I don't understand half of the terms that they use.
What is a keg? What is a tap? From the article you linked, what is a cask? What is the Caskroom? Elsewhere I've heard talk of "bottles" - what is a bottle, in this context? What are formulae?
Good job! Homebrew is, at least for me, essential for using macOS as a true *nix, and most of the changes (implemented or proposed) seem good (e.g., the ability to automatically run cleanup)
I am a little bit worried for the removal of all options that is planned for the 2.0.0 version: I have some formulae installed from source (with additional options) and I like the flexibility that they give. Hopefully the migration to an "options-free" Homebrew will be smooth and some alternative when options are needed (not requiring a lot of third-party taps) will emerge.
Homebrew has gone out of its way to make this more difficult lately, to the point where 'brew doctor' complains when HOMEBREW_BUILD_FROM_SOURCE is set, and now it's deprecated.
Homebrew's bottle infrastructure is a tempting target if you want to get malware deployed to Macs, and as best I can tell, there is scant documentation out there about what they do to secure it. For all I know, the bottles are built on some random bozo's Mac.
The snarky side of me thinks that if build from source is discouraged then the program should rename itself to Macrobrew (as I'm sure Budwiser would sue their pants off if they used that name).
We're using analytics data to ensure that the most commonly used options (or those that don't add extra dependencies) are enabled by default. We're doing our best to make it a smooth migration (and given we're 95% of the way there already and you hopefully haven't noticed problems: I'm confident).
For many distributions (redhat, ubuntu lts, debian) packages can grow rather old. If you want something more up-to-date, linuxbrew can help. I suppose that's less useful on rolling distros like gentoo or arch.
Consider someone writing a guide on how to install packages on multiple platforms. You only need one guide and not three based on brew. Especially interesting for Windows 10 IMO.
For many packages it is difficult to get packaged for all Linux distributions. Hence if your package does not get packaged for a particular Linux distribution users can still install your package using homebrew.
Package managers can only offer what they are feeded with. And that does not include all software in all incarnations. A usual problem is that certain distributions are lacking newer versions. Or the ability to install multiple versions parallel. Something like homebrew is a solution for this.
I think this is a testament of Homebrew its success. Build a package manager for a OS that doesn't natively has one (macOS) and eventually expand to OS's that do have one (linux), because users request it / like Homebrew.
There are many small utilities that's not available especially if you stick to LTS. (Even ripgrep isn't available on 18.04. I feel this more when these 'remake better alternatives with rust/go' movement started to occur.)
And all you can do is hopefully find a trustworthy PPA that gets timely updates or you end up downloading it yourself and get them updated manaually.
I wanted to use Linuxbrew but this seems still not too mature.
Really not a fan of the removal of options, imo it is one of the greatest perks of homebrew. Can I manually build my own software? Yes. Do I want to have to maintain a tap for every single thing I want to use options on? No, I do not.
This move along with the python2 vs python3 change that was made previously has left a seriously sour taste in my mouth about Homebrew. I'm actively looking at other options.
> Homebrew 1.9.0 no longer runs on 32-bit Intel CPUs.
Where does this constraint come from? Homebrew is written in Ruby.
To cut down on compilation from source issues? Or Homebrew uses language features from Ruby versions greater than what Apple shipped in their latest 32-bit supported OSX versions (as homebrew insists on using the system default binaries)?
Homebrew builds individual binary bottles per package and per macOS version, but not per target architecture.
In other words: at bottle creation time (server-side), Homebrew tells the compiler to output code that runs on older CPUs. The downside of this is that end users who install bottles never get to enjoy the benefits of latest CPU instruction sets, such as SSE 4.1/4.2.
From time to time, Homebrew raises the bar to keep the balance between performance and compatibility. From Homebrew 1.9.0, bottles are built to use the features of the Penryn/Core 2 microarchitecture or higher, or in other words: Homebrew no longer supports CPU microarchitectures older than Penryn/Core 2.
> Linuxbrew does not currently support 32-bit x86 platforms. It would be possible for Linuxbrew to work on 32-bit x86 platforms with some effort. An interested and dedicated person could maintain a fork of Homebrew to develop support for 32-bit x86.
Chocolatey is... ok. It works, mostly, but it's a common occurrence for upgrades to fail because the package maintainer forgot to update the hash, or the program's built-in autoupdater already ran and moved things around, or a phantom .install dependency is missing, or some other inscrutable problem. Competition will be good for it (and the developer sells a premium version, so I do expect proper competition). All the other package management tools on windows have fairly tiny repositories and are, as far as I can tell, optimized for the workflow of sysadmins building images.
I wonder if Brew has any plans to support that package management framework Microsoft is apparently still working on? (https://github.com/OneGet/oneget)
How php is handled by Homebrew has changed last year. Now you do
brew install [email protected]
It was my understanding that if you wanted in your PATH you just did `brew link --force [email protected]`. That's not possible anymore? (Since MacOS provides a php binary) What's the recommended way for easily getting a specific version of php in your PATH?
tl;dr One user had binutils force-linked, causing cmake to pick up the user-installed flavor of binutils, altering cmake’s behavior and causing issues.
It is not a good idea to change the provided software versions that other parts of the base system can rely on. I would go further than that, modern OS design should make every part of the operating system immutable by default. We could get rid off entire class of security problems if it was like that.
Remember that Homebrew by default records some of your usage data via Google Analytics. Disable that if you are not comfortable, or switch to MacPorts.
It's a bit weird how they're announcing a new mission statement about how this is a small focused project for macOS at the same time they're announcing Windows and Linux compatibility.
Hi. I am one of the Linuxbrew maintainers. I understand that this may seem contradictory.
Linuxbrew has existed since a few years now (https://github.com/Linuxbrew). We just merged the linux part of the code into the main brew repo.
https://github.com/Linuxbrew/homebrew-core, where the formula reside, is still a separate project. But we all work closely together. The 4-5 linuxbrew maintainers joined the homebrew team and we are now a single team.
This does not add too much work for the initial homebrew maintainers.
The scope has grown a little bit, but nothing to be worried about. And the windows part is "just" Linux running on Windows, so actually there is not much difference there. That part is not so well tested though, because we do not have so many users on Windows, but we hope to be able to improve this part if needed.
On the other side some decisions have been made lately: less from source builds, less options ... this will reduce our workload too.
It loads all "casks" when doing search. I don't know if it did it in earlier version, but now `brew search` takes more than minute on my system (mostly because of apfs on hdd)
[+] [-] LeonM|7 years ago|reply
Since I don't install 'mission critical' application through brew, I've always had the following command run daily though a cronjob:
[+] [-] verisimilitude|7 years ago|reply
What I mean: "Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the computer wakes up. If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep."[1]
[1]: http://www.launchd.info
[+] [-] bump-ladel|7 years ago|reply
[+] [-] stabbles|7 years ago|reply
Overall I hate how slow brew is, especially `update` should be 10x faster, it should maybe warn about source builds that could take forever, and it should maybe give a summary like `apt` whether there are packages to be `autoremove`d.
[+] [-] mikemcquaid|7 years ago|reply
[+] [-] ungzd|7 years ago|reply
[1] https://www.postgresql.org/docs/11/pgupgrade.html
[2] https://github.com/Homebrew/homebrew-core/blob/master/Formul...
[+] [-] mr_custard|7 years ago|reply
[+] [-] clessg|7 years ago|reply
==> This operation has freed approximately 41.3GB of disk space.
Automatic cleanup would have saved me a lot of confusion.
[+] [-] Hoasi|7 years ago|reply
[+] [-] kri3v|7 years ago|reply
Wow, thanks
[+] [-] paultopia|7 years ago|reply
There are several updates in here that make me worry that this is somehow going to break my environment or otherwise bite me in the ass when I do something innocent like install Ghostscript and find that Emacs no longer works and to figure out how to fix it's going to be hours of reading github issues. Which is an experience I've had before, repeatedly.
"brew update no longer migrates legacy keg symlinks, tap names, repository locations, cache locations or cache entries."
Is this going to break something I installed years ago? Maybe the homebrew maintainers know, but average tool users don't.
"Homebrew/homebrew-core requires all formulae to be open source by the OSI definition."
Does this mean that something I used homebrew to install in a previous version will no longer be getting updates? Will things that depend on it still be getting updates? Does whether or not updates happen depend on some random committer's legalistic interpretation of an open source definition? Why exactly is this kind of purist decision being imposed on users?
[in 2.0] "brew cleanup will be run periodically and for trigger individual formula cleanup on reinstall, install or upgrade. You can enable this behaviour now on 1.9.0 by setting the HOMEBREW_INSTALL_CLEANUP variable."
So you're going to periodically make maintenance changes to my system without my permission. Goodie.
Someone really needs to write a guide to migrating away from homebrew for people in the unfortunate situation of having used this tool for a long time, and find it taking more and more liberties with one's computer, but also having numerous essential packages now managed by it and not sure how to move to alternatives without weeks of breakage.
[1] https://paultopia.github.io/posts-output/anti-homebrew/
[+] [-] mikemcquaid|7 years ago|reply
This is not true. `man brew` documents how to disable auto-updates.
> Why exactly is this kind of purist decision being imposed on users?
Because there's a lot of current debate about whether things being relicensed under the Commons Clause is "open source" or not and we'd rather lean on an established, well-documented authority on what that definition is. Additionally, part of our agreed membership of the Software Freedom Conservancy (who help us with a lot) involves ensuring our core formulae are open source software.
> So you're going to periodically make maintenance changes to my system without my permission. Goodie.
Again, `brew man` documents how to disable this.
---
The complaint behind the individual complaints is "why doesn't Homebrew work the way I want it to". That's a reasonable complaint and there may be better tools for you to use rather than Homebrew but we're going to continue to build Homebrew to work in a way that works best for the majority of our users and avoids our (entirely voluntary) maintainers having to deal with the same issues again and again.
[+] [-] Spiritus|7 years ago|reply
I suspect this is partly because the cache can consume a huge amount of disk space over time and many users might never run `brew cleanup` or doesn't even know about it. And then wonder where all their disk space has gone.
[+] [-] Mister_Snuggles|7 years ago|reply
The biggest thing that has kept me on MacPorts and away from Homebrew is that I don't understand half of the terms that they use.
What is a keg? What is a tap? From the article you linked, what is a cask? What is the Caskroom? Elsewhere I've heard talk of "bottles" - what is a bottle, in this context? What are formulae?
[+] [-] jxy|7 years ago|reply
[+] [-] __lm__|7 years ago|reply
I am a little bit worried for the removal of all options that is planned for the 2.0.0 version: I have some formulae installed from source (with additional options) and I like the flexibility that they give. Hopefully the migration to an "options-free" Homebrew will be smooth and some alternative when options are needed (not requiring a lot of third-party taps) will emerge.
[+] [-] ohithereyou|7 years ago|reply
Homebrew has gone out of its way to make this more difficult lately, to the point where 'brew doctor' complains when HOMEBREW_BUILD_FROM_SOURCE is set, and now it's deprecated.
Homebrew's bottle infrastructure is a tempting target if you want to get malware deployed to Macs, and as best I can tell, there is scant documentation out there about what they do to secure it. For all I know, the bottles are built on some random bozo's Mac.
The snarky side of me thinks that if build from source is discouraged then the program should rename itself to Macrobrew (as I'm sure Budwiser would sue their pants off if they used that name).
[+] [-] mikemcquaid|7 years ago|reply
[+] [-] wbl|7 years ago|reply
[+] [-] balac|7 years ago|reply
[+] [-] alanfranz|7 years ago|reply
[+] [-] starbugs|7 years ago|reply
[+] [-] walki|7 years ago|reply
[+] [-] PurpleRamen|7 years ago|reply
[+] [-] microtonal|7 years ago|reply
Of course, Nix also works without root and has many other benefits ;).
[+] [-] rickette|7 years ago|reply
[+] [-] h1d|7 years ago|reply
And all you can do is hopefully find a trustworthy PPA that gets timely updates or you end up downloading it yourself and get them updated manaually.
I wanted to use Linuxbrew but this seems still not too mature.
[+] [-] chenzhekl|7 years ago|reply
[+] [-] tomaspollak|7 years ago|reply
[+] [-] sambe|7 years ago|reply
[+] [-] yumyai|7 years ago|reply
[deleted]
[+] [-] zchrykng|7 years ago|reply
This move along with the python2 vs python3 change that was made previously has left a seriously sour taste in my mouth about Homebrew. I'm actively looking at other options.
[+] [-] Hackbraten|7 years ago|reply
I really encourage you to create a tap for the formulas you like to customize. Taps are a powerful, much overlooked feature baked into Homebrew.
[+] [-] bhaak|7 years ago|reply
Where does this constraint come from? Homebrew is written in Ruby.
To cut down on compilation from source issues? Or Homebrew uses language features from Ruby versions greater than what Apple shipped in their latest 32-bit supported OSX versions (as homebrew insists on using the system default binaries)?
[+] [-] Hackbraten|7 years ago|reply
In other words: at bottle creation time (server-side), Homebrew tells the compiler to output code that runs on older CPUs. The downside of this is that end users who install bottles never get to enjoy the benefits of latest CPU instruction sets, such as SSE 4.1/4.2.
From time to time, Homebrew raises the bar to keep the balance between performance and compatibility. From Homebrew 1.9.0, bottles are built to use the features of the Penryn/Core 2 microarchitecture or higher, or in other words: Homebrew no longer supports CPU microarchitectures older than Penryn/Core 2.
[+] [-] amypinka|7 years ago|reply
> Linuxbrew does not currently support 32-bit x86 platforms. It would be possible for Linuxbrew to work on 32-bit x86 platforms with some effort. An interested and dedicated person could maintain a fork of Homebrew to develop support for 32-bit x86.
[+] [-] mikemcquaid|7 years ago|reply
[+] [-] nxrabl|7 years ago|reply
Chocolatey is... ok. It works, mostly, but it's a common occurrence for upgrades to fail because the package maintainer forgot to update the hash, or the program's built-in autoupdater already ran and moved things around, or a phantom .install dependency is missing, or some other inscrutable problem. Competition will be good for it (and the developer sells a premium version, so I do expect proper competition). All the other package management tools on windows have fairly tiny repositories and are, as far as I can tell, optimized for the workflow of sysadmins building images.
I wonder if Brew has any plans to support that package management framework Microsoft is apparently still working on? (https://github.com/OneGet/oneget)
[+] [-] chmaynard|7 years ago|reply
An explanation for this change would be useful.
[+] [-] Spiritus|7 years ago|reply
[+] [-] afraca|7 years ago|reply
It was my understanding that if you wanted in your PATH you just did `brew link --force [email protected]`. That's not possible anymore? (Since MacOS provides a php binary) What's the recommended way for easily getting a specific version of php in your PATH?
[+] [-] Hackbraten|7 years ago|reply
> This would have avoided Homebrew/homebrew-core#34754
which links to: https://github.com/Homebrew/homebrew-core/issues/34754
tl;dr One user had binutils force-linked, causing cmake to pick up the user-installed flavor of binutils, altering cmake’s behavior and causing issues.
[+] [-] StreamBright|7 years ago|reply
[+] [-] nisuni|7 years ago|reply
[+] [-] favadi|7 years ago|reply
[+] [-] ris|7 years ago|reply
[+] [-] daveFNbuck|7 years ago|reply
[+] [-] iMichka|7 years ago|reply
Linuxbrew has existed since a few years now (https://github.com/Linuxbrew). We just merged the linux part of the code into the main brew repo.
https://github.com/Linuxbrew/homebrew-core, where the formula reside, is still a separate project. But we all work closely together. The 4-5 linuxbrew maintainers joined the homebrew team and we are now a single team.
This does not add too much work for the initial homebrew maintainers.
The scope has grown a little bit, but nothing to be worried about. And the windows part is "just" Linux running on Windows, so actually there is not much difference there. That part is not so well tested though, because we do not have so many users on Windows, but we hope to be able to improve this part if needed.
On the other side some decisions have been made lately: less from source builds, less options ... this will reduce our workload too.
[+] [-] sashk|7 years ago|reply
I recall that some commands where much faster. It takes on average 2.5 seconds to do brew search.
$ time brew search mpv ==> Formulae mpv
==> Casks mpv brew search mpv 2.34s user 0.59s system 67% cpu 4.348 total
This is not autoupdate — this is with set HOMEBREW_AUTO_UPDATE_SECS to 14400.
[+] [-] ungzd|7 years ago|reply
https://discourse.brew.sh/t/solved-brew-search-is-too-slow-s...