
Homebrew 1.9.0 - mikemcquaid
https://brew.sh/2019/01/09/homebrew-1.9.0/
======
LeonM
Automatic cleanup sounds like a major improvement. It's almost scary how much
disk space is used by Brew if you don't/didn't run cleanup periodically.

Since I don't install 'mission critical' application through brew, I've always
had the following command run daily though a cronjob:

    
    
      brew update && brew upgrade && brew cleanup

~~~
stabbles
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.

~~~
Hackbraten
You may know it already but as a PSA: you can usually avoid source builds on
`brew install` and `brew upgrade` if you do it without options (such as
`--with-lldb`). Unless you customize your installation using options, Homebrew
will install your package from bottle, which is infinity times faster than
building from source.

------
paultopia
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.

[1] [https://paultopia.github.io/posts-output/anti-
homebrew/](https://paultopia.github.io/posts-output/anti-homebrew/)

~~~
mikemcquaid
> 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.

~~~
dilap
As someone who _uses_ homebrew religiously, but isn't familiar with the inner-
workings, I'll second the sentiment that some _whys_ on the changes would be
much appreciated.

Otherwise it just looks like a bunch of scary behavior changes w/o a clear
upside.

~~~
dickeytk
that's a really good suggestion. As someone that writes a lot of changelogs,
they would really benefit from including _why_ and not just _what_.

I do think, however, that users greatly underestimate how much time it takes
to write up a good changelog. Even one that is as simple as this.

~~~
mikemcquaid
Yeh, that's it in a nutshell, unfortunately. I wish I had more time to write
great changelogs for Homebrew but I don't :(

~~~
dilap
Not for me to tell you how to prioritize your time, of course, but I'll just
say in my experience programmers tend to vastly over-index on the importance
of stuff like crushing code and under-index on the importance of stuff like
communicating w/ the community. Non-tech tasks are still hugely important.

Cheers, and thanks for your work on homebrew. It really is a great tool.

~~~
mikemcquaid
Thanks for the kind words.

For what it's worth, I really do value this stuff which is why we have release
notes at all, a Discourse forum, etc. most of which I've setup and run :)

------
__lm__
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.

~~~
ohithereyou
> I have some formulae installed from source

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
> there is scant documentation out there about what they do to secure it

We have private operations documentation and have had private security reviews
of our infrastructure. We are actively moving away from self-hosted
infrastructure this year.

~~~
ohithereyou
Do you have published security reviews of your infrastructure? Otherwise
you're asking us to just trust you.

Note: I'm not denying that you have a stellar track record, but it would be
nice to have more evidence that this is not down to luck or obscurity but is
instead due to process, best practice, and understanding of risk.

~~~
mikemcquaid
Almost everything we have is open for you to examine (including the code,
obviously). If you're not willing or able to do that: yes, you have to trust
us (like you do with pretty much all software and infrastructure you don't
personally control).

~~~
_mdpn
Yes, I know that I have to make a judgement call about whether or not to trust
infrastructure I don't own, and I have made that judgement, but I'm asking for
myself and others if the Homebrew project haa any additional information I and
others can use to make that evaluation.

It is frustrating that you are being so opaque and dismissive. You still
haven't answered my earlier question if the Homebrew project has published a
summary of the results of these security reviews (I understand not posting the
entire review publicly). A quick Google search did not turn up anything, which
is why I am asking.

For contrast: I can find out the build process for a Debian package from their
website[1]. While they do have some private operation documentation, they also
publish the process by which packages get pulled into their system, built, and
pushed to the mirrors[2][3]. They have documentation for how to replicate
their build environment and build packages on my own[4]. This documentation is
open, and I can verify packages with it as they move toward reproducible
builds[5]. I understand that Debian is a much larger operation with a much
longer history. I understand that it takes time to develop these things. This
is not an attack on the Homebrew project or the work they do.

[1]
[https://www.debian.org/devel/buildd/](https://www.debian.org/devel/buildd/)

[2]
[https://www.debian.org/devel/buildd/operation](https://www.debian.org/devel/buildd/operation)

[3]
[https://wiki.debian.org/Teams/FTPMaster](https://wiki.debian.org/Teams/FTPMaster)

[4] [https://wiki.debian.org/BuilddSetup](https://wiki.debian.org/BuilddSetup)

[5]
[https://wiki.debian.org/ReproducibleBuilds](https://wiki.debian.org/ReproducibleBuilds)

~~~
mikemcquaid
It is not my intention to be dismissive. I admire the work Debian has done on
the above but they are a project with many more maintainers and a lot more
resources. We have some documentation for our process already under
[https://docs.brew.sh](https://docs.brew.sh) but ultimately if it's not good
enough for you we need people who are willing to step up and do the work to do
so.

~~~
ohithereyou
I understand you do not intend to be dismissive, however, not answering a
simple yes or no question in your last two responses appears to be dismissive.
I could not find any information about the security audits performed and a
summary of their results, so I ask again; is there a summary of the security
audits published publicly?

I have looked at the Homebrew docs page. There is a document linked that
describes how bottles are built[1], but it's not clear who has access to it
and what safeguards are in place to prevent a malicious maintainer from
spreading malware through it (such as who reviews the commits) and it doesn't
list the precautions taken by bintray to prevent and detect tampering with
packages (and a user has to trust that they as in place, sufficient, and trust
bintray to not tamper with them). Another page says that most formula pull
requests need to be reviewer but does not go over what this entails[2].

This alarming text, however, does appear in your maintainer guidelines [3]:

>Verify the formula works if possible. If you can’t tell (e.g. if it’s a
library) trust the original contributor, it worked for them, so chances are it
is fine. If you aren’t an expert in the tool in question, you can’t really
gauge if the formula installed the program correctly. _At some point an expert
will come along, cry blue murder that it doesn’t work, and fix it. This is how
open source works._ Ideally, request a test do block to test that
functionality is consistently available.

Is there a set of maintainers who handle security sensitive formula, like
openssl, gnupg, and tor?

[1] [https://docs.brew.sh/Brew-Test-Bot](https://docs.brew.sh/Brew-Test-Bot)

[2] [https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-
Request](https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request)

[3] [https://docs.brew.sh/Maintainer-
Guidelines](https://docs.brew.sh/Maintainer-Guidelines)

~~~
FullyFunctional
I had exactly the same security concern. It seems it would be quite easy to
slip in an attack via brew.

I had an experience years ago where I discovered the lack of quality control:
a typo (presumably) caused a package to regress back a couple of years. My
issue used wording like "Are you serious?" which was taken as offensive and I
was banned, unable to even apologize or defend myself from resulting attacks.

brew is convenient and I still use it, but I have a much higher degree of
trust in packages shipping with OS distributions.

~~~
mikemcquaid
> It seems it would be quite easy to slip in an attack via brew.

You can put your money where your mouth is and consider submitting one to our
HackerOne. Otherwise: perhaps it's not "quite easy" after all.

------
balac
I wonder why Linux users would want to use Homebrew? Are the packages not
available via the normal Linux package managers?

~~~
alanfranz
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.

~~~
AnIdiotOnTheNet
I think that's a good example of how the whole paradigm of package management
as an application distribution mechanism (at least as implemented) is really
terrible. What good is all this management if I have to bypass it and
everything it supposedly provides just to get up to date software, or two
versions of the same software?

~~~
alanfranzoni
I totally agree with you. I think it's pretty pointless to have terabytes of
repos for software that then grows stale.

But distributions often say that it's the only way to keep the whole
"ecosystem" of a distribution stable.

So? What I think is that Linux "distributions" are growing less and less
useful nowadays. On the desktop, no Linux was able to gain significant
traction, and many developers are just using Macs and Windows with WSL.

On the server side, ways to "build your own distro" for creating a tuned stack
for your purposes ( read: docker images ) exist and seem more useful than
standard distro components. Nixos is another take.

Yes, "just apt install foo" is nice, until it isn't. I think we're at a
tipping point between the old and new approach.

~~~
jancsika
> But distributions often say that it's the only way to keep the whole
> "ecosystem" of a distribution stable.

In practice, it doesn't work. I did a Debian Stretch `apt-get upgrade` and it
pulled in a new version of firefox-esr that _did not run_ on my Rockchip
Chromebook. Debian was forced to do it because it was end-of-life for the
older firefox-esr, and Debian's security backports policy doesn't scale for
projects like Chromium and Firefox.

------
zchrykng
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.

~~~
Hackbraten
It’s less than 12 months until Python 2 will no longer be maintained.
[https://pythonclock.org/](https://pythonclock.org/)

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.

~~~
zchrykng
My objection is more about how it was handled on a communication and technical
level than any of the specifics of switching to Python 3 over 2.

------
bhaak
> 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)?

~~~
Hackbraten
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.

~~~
bhaak
Your explanation makes sense for bottles, not for Homebrew itself. Homebrew is
still at its core "build from source".

This is exactly what the bottle bot does, building the same formulas you have
on your machine. Why should this no longer work?

~~~
Hackbraten
Unless the user sets specific build options, or runs `brew install --build-
from-source`, Homebrew installs core packages from a bottle hosted on Bintray
by default.

While I agree in that building from source is somewhat at Homebrew’s core (as
that’s what happens at bottle creation time), the intention is to deliver core
packages to end users via bottle as often as possible.

------
nxrabl
Windows support! That's a surprise.

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](https://github.com/OneGet/oneget))

~~~
karenpls
Did you take a look at scoop.sh? I find it very useful commpared to
chocolatey. It only installs portable versions, requires no admin and has
everything my dev heart needs. Even installing stuff like miniconda and fluttr
is a blaze.

~~~
skrebbel
Seconded. Scoop.sh is spectacularly simple and to the point for all the areas
where chocolatey feels needlessly complex.

------
chmaynard
> brew link --force will not link software already provided by macOS.

An explanation for this change would be useful.

~~~
Spiritus
If I had to guess. Probably to prevent tainting the base system.

~~~
danieldk
It depends on the defintion of _taint_. Homebrew cannot touch the base system,
since it lives in /usr/local in macOS. Also macOS SIP prevents modification of
most system files.

One major problem is that system and Homebrew versions of library may have
incompatible ABIs.

~~~
zakk
That's the exact reason why I consider MacPorts much more elegant.

------
nisuni
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.

------
favadi
Technically speaking, why would anyone wants to use brew on linux over snap or
nix?

~~~
yxhuvud
To have a common dev environment setup with their mac using colleagues.

~~~
edude03
Nix actually does run on OSX, at the company I work at we have about 25
engineers, 20 using macs, 5 using Linux and we use nix to keep the dev
environment across all of our computers (and CI)

------
ris
My saviour when forced to use a Mac recently has been Nix. Homebrew has only
ever caused me pain.

------
daveFNbuck
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.

~~~
iMichka
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](https://github.com/Linuxbrew)). We just merged
the linux part of the code into the main brew repo.

[https://github.com/Linuxbrew/homebrew-
core](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.

~~~
daveFNbuck
If the scope has grown and you're all a single team, shouldn't that be
reflected in the mission statement?

~~~
Hackbraten
While I’m as excited about the Linux part as my fellow maintainers are, I feel
it’s important to set reasonable expectations.

Currently, about 25 % of Homebrew’s active maintainers work on the Linux/WSL
part. I don’t believe that ratio is going to change much during 2019.

If Linux and Windows were to become part of Homebrew’s mission statement, it’d
be all too easy for Linux/WSL users to interpret that as Homebrew committing
to the same level of support to which macOS users are accustomed at this time.

I feel there’s no way we’d be able to deliver on that commitment and not
disappoint users. We want happy users.

------
sashk
Is it me or homebrew became slower recently?

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
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)

[https://discourse.brew.sh/t/solved-brew-search-is-too-
slow-s...](https://discourse.brew.sh/t/solved-brew-search-is-too-slow-search-
casks-takes-most-time/3291)

~~~
sashk
That explains everything... Thanks.

