20 ms·

Homebrew 1.9.0

241 points by mikemcquaid 8y ago

sashk 8y ago
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 8y ago
  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-search-casks-takes-most-time/3291 https://discourse.brew.sh/t/solved-brew-search-is-too-slow-s...
  - sashk 8y ago
    That explains everything... Thanks.
nxrabl 8y ago
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 8y ago
  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 8y ago
    Seconded. Scoop.sh is spectacularly simple and to the point for all the areas where chocolatey feels needlessly complex.
- skrebbel 8y ago
  It's not windows support, it's WSL support.
- deleted 8y ago
  [deleted]
zchrykng 8y ago
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 8y ago
  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 8y ago
    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.
daveFNbuck 8y ago
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 8y ago
  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 8y ago
    If the scope has grown and you're all a single team, shouldn't that be reflected in the mission statement?
    - Hackbraten 8y ago
      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.
chmaynard 8y ago
> brew link --force will not link software already provided by macOS. An explanation for this change would be useful.
- Spiritus 8y ago
  If I had to guess. Probably to prevent tainting the base system.
  - danieldk 8y ago
    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 8y ago
      That's the exact reason why I consider MacPorts much more elegant.
  - dnate 8y ago
    Most likely. I still remember the incident where I upgraded my system wide python installation manually and had to reinstall mac os
- Hackbraten 8y ago
  From https://github.com/Homebrew/brew/pull/5383 https://github.com/Homebrew/brew/pull/5383: > This would have avoided Homebrew/homebrew-core#34754 which links to: https://github.com/Homebrew/homebrew-core/issues/34754 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.
  - mikemcquaid 8y ago
    Yup, this exactly.
balac 8y ago
I wonder why Linux users would want to use Homebrew? Are the packages not available via the normal Linux package managers?
- sambe 8y ago
  Some people don't have root access.
- chenzhekl 8y ago
  Homebrew can be used as a package manager for C/C++ projects development and meanwhile doesn't mess up the system.
- starbugs 8y ago
  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.
  - AnIdiotOnTheNet 8y ago
    Generally speaking all that documentation should consist of is "click this link to download <thing> for <os>" and maybe "extract its contents somewhere". Anything else is over-complicating the situation for no good reason. Unfortunately that has become such an ingrained part of the open source culture that we keep imagining things like this are a good idea.
- danieldk 8y ago
  Homebrew on Linux (known as Linuxbrew) does not require root access. Of course, Nix also works without root and has many other benefits ;).
  - whenov 8y ago
    However, Nix requires you to create a /nix directory, which is not possible in some cases.
bhaak 8y ago
> 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)?
- amypinka 8y ago
  From: https://docs.brew.sh/Linuxbrew https://docs.brew.sh/Linuxbrew > 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.
- Hackbraten 8y ago
  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 8y ago
    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 8y ago
      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.
ris 8y ago
My saviour when forced to use a Mac recently has been Nix. Homebrew has only ever caused me pain.
favadi 8y ago
Technically speaking, why would anyone wants to use brew on linux over snap or nix?
- yxhuvud 8y ago
  To have a common dev environment setup with their mac using colleagues.
  - edude03 8y ago
    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)
LeonM 8y ago
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
- verisimilitude 8y ago
  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] [1]: http://www.launchd.info http://www.launchd.info
- clessg 8y ago
  Ha, I wish I knew about that command earlier. I was wondering where all my disk space was going. ==> This operation has freed approximately 41.3GB of disk space. Automatic cleanup would have saved me a lot of confusion.
- kri3v 8y ago
  ==> This operation has freed approximately 3.3GB of disk space. Wow, thanks
- mr_custard 8y ago
  Wow. That's so true. I just got back 5GB. I didn't know about this. Thanks :-)
- mikemcquaid 8y ago
  I'm excited about it. `brew upgrade` now runs `brew update` and if you set the environment variable `brew upgrade` will run `brew cleanup` too.
  - 8y ago
__lm__ 8y ago
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 8y ago
  > 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 8y ago
    > 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 8y ago
      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.
paultopia 8y ago
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/
- jxy 8y ago
  Save your time and soul. Just use MacPorts.
- Mister_Snuggles 8y ago
  > "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?
nisuni 8y ago
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.

241 points by mikemcquaid 8y ago

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 8y ago
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-search-casks-takes-most-time/3291 https://discourse.brew.sh/t/solved-brew-search-is-too-slow-s...
- sashk 8y ago
  That explains everything... Thanks.

nxrabl 8y ago

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 8y ago
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 8y ago
  Seconded. Scoop.sh is spectacularly simple and to the point for all the areas where chocolatey feels needlessly complex.
skrebbel 8y ago
It's not windows support, it's WSL support.
deleted 8y ago
[deleted]

zchrykng 8y ago

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 8y ago
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 8y ago
  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.

daveFNbuck 8y ago

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 8y ago
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 8y ago
  If the scope has grown and you're all a single team, shouldn't that be reflected in the mission statement?
  - Hackbraten 8y ago
    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.

chmaynard 8y ago

> brew link --force will not link software already provided by macOS. An explanation for this change would be useful.

Spiritus 8y ago
If I had to guess. Probably to prevent tainting the base system.
- danieldk 8y ago
  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 8y ago
    That's the exact reason why I consider MacPorts much more elegant.
- dnate 8y ago
  Most likely. I still remember the incident where I upgraded my system wide python installation manually and had to reinstall mac os
Hackbraten 8y ago
From https://github.com/Homebrew/brew/pull/5383 https://github.com/Homebrew/brew/pull/5383: > This would have avoided Homebrew/homebrew-core#34754 which links to: https://github.com/Homebrew/homebrew-core/issues/34754 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.
- mikemcquaid 8y ago
  Yup, this exactly.

balac 8y ago

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

sambe 8y ago
Some people don't have root access.
chenzhekl 8y ago
Homebrew can be used as a package manager for C/C++ projects development and meanwhile doesn't mess up the system.
starbugs 8y ago
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.
- AnIdiotOnTheNet 8y ago
  Generally speaking all that documentation should consist of is "click this link to download <thing> for <os>" and maybe "extract its contents somewhere". Anything else is over-complicating the situation for no good reason. Unfortunately that has become such an ingrained part of the open source culture that we keep imagining things like this are a good idea.
danieldk 8y ago
Homebrew on Linux (known as Linuxbrew) does not require root access. Of course, Nix also works without root and has many other benefits ;).
- whenov 8y ago
  However, Nix requires you to create a /nix directory, which is not possible in some cases.

bhaak 8y ago

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

amypinka 8y ago
From: https://docs.brew.sh/Linuxbrew https://docs.brew.sh/Linuxbrew > 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.
Hackbraten 8y ago
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 8y ago
  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 8y ago
    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.

ris 8y ago

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

favadi 8y ago

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

yxhuvud 8y ago
To have a common dev environment setup with their mac using colleagues.
- edude03 8y ago
  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)

LeonM 8y ago

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

verisimilitude 8y ago
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] [1]: http://www.launchd.info http://www.launchd.info
clessg 8y ago
Ha, I wish I knew about that command earlier. I was wondering where all my disk space was going. ==> This operation has freed approximately 41.3GB of disk space. Automatic cleanup would have saved me a lot of confusion.
kri3v 8y ago
==> This operation has freed approximately 3.3GB of disk space. Wow, thanks
mr_custard 8y ago
Wow. That's so true. I just got back 5GB. I didn't know about this. Thanks :-)
mikemcquaid 8y ago
I'm excited about it. `brew upgrade` now runs `brew update` and if you set the environment variable `brew upgrade` will run `brew cleanup` too.
- 8y ago

__lm__ 8y ago

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 8y ago
> 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 8y ago
  > 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 8y ago
    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.

paultopia 8y ago

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/

jxy 8y ago
Save your time and soul. Just use MacPorts.
Mister_Snuggles 8y ago
> "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?

nisuni 8y ago

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.