1. 50
  1.  

  2. [Comment removed by author]

    1. 8

      I think that they solve two related but separate problems. Homebrew is a package manager, just like apt on Debian/Ubuntu or yum on Red Hat. I guess that the idea behind making brew available for linux is to offer a universal package manager that is independent from the linux flavor being used.

      For what I understand of nix, brew doesn’t offer the same rollback, side-by-side installations, per-project management that nix offers. brew just installs the latest package. nix was designed to solve issues with current package management options, including brew. Maybe someone with more experience with nix can offer a more well-rounded comparison.

      1. 5

        I asked an experienced Nix user about this. He said Nix has poor support for MacOS, you probably want to use Homebrew instead. I investigated package managers for Windows, and it looks like a wasteland, at least in terms of supporting the packages I care about. So I think the appeal of Homebrew on Linux is the ability to get the same packages on MacOS and Windows.

        1. 6

          Nix packages definitely get a bit less love on macOS, but it’s still fantastic even if you have to write some custom rules yourself. Pinterest uses Nix to ensure reproducible build environments for CI and the iOS engineers. I use Nix to create a cross-platform reproducible dev environment for myself (my shell environment, Vim with YouCompleteMe et al). I’m able to switch between macOS and Linux environments without feeling like I have to change my workflow.

          Having said that, I haven’t been able to replace brew entirely on macOS yet.

          1. 1

            I use Chocolatey package manager for Windows. https://chocolatey.org/ Most of the time it works okay and it’s improved quite a bit the last years.

          2. 3

            Homebrew has significantly more packages (I’ve never found a package it didn’t have) but you can’t get any older version of a package. As a workaround, every version of every package you’ve ever installed stays installed but not linked into PATH.

            1. 1

              You can point it at an old version of the build script in git, but it’s a PITA.

          3. 5

            I see comments here asking about cross-platform (Mac/Linux) package managers, but no one has mentioned pkgsrc

            Joyent host binaries for SmartOS/Illumos, Mac and even RHEL all via pkgsrc here: https://pkgsrc.joyent.com/

            1. 3

              I heard that homebrew was an awful package managers by some compared to, say, apt. Is this true, if so, why?

              1. 11

                It’s fucking ridiculous how bad this thing is, and the issues around how it’s run are almost as bad as the technical ones.

                For years it was a source only tool - it did all compilation locally. Then they caught up to 1998 and realised that the vast majority of people want binary distribution. So they added in pre-compiled binaries, but never bothered to adapt the dependency management system to take that into account.

                So for instance, if you had two packages that provide the same binary - e.g. mysql-server and percona-server (not sure if that’s their exact names in Homebrew), and then wanted to install say “percona-toolkit” as well, which has a source requirement of “something that provides mysql libs/client” - the actual dependency in the binary package would be whatever had been installed on the machine it was built on. This manifested itself in an issue where you couldn’t install both percona-server and percona-toolkit from binaries.

                When issues like this were raised - even by employees of the vendor (e.g. as in https://github.com/Homebrew/homebrew-core/issues/8717) the official response was “not our problem buddy”.

                No fucks given, just keep hyping the archaic design to the cool kids.

                I haven’t even got into the issue of permissions (what could go wrong installing global tools with user permissions) or the ridiculous way package data is handled on end-user machines (git is good for some things, this is not one of them)

                If you get too vocal about the problems the tool has, someone (in my case, the founder of the project) will ask you to stop contacting them (these were public tweets with the homebrew account referenced) about the issues.

                1. 4

                  it’s good, easy to use and has a big community with well maintained list of packages. It’s the main package manager for macos. It’s been there for a long time in the macos ecosystem and is much better and easier to use than the older solutions we had such as macport. A cool thing is it has a distinction between command line tool and libraries vs desktop applications (called casks)

                  example; you can install wget with brew install wget, but you’d install firefox with brew cask install firefox.

                  I would stick to linux system’s default package manager, but maybe it’s worth giving it a try I guess.

                  1. 3

                    A cool thing is it has a distinction between command line tool and libraries vs desktop applications (called casks)

                    Why is that cool? It seems pretty pointless to me.

                    1. 2

                      Yeah distinction between them at install tine isn’t that cool, but the fact it does support installing desktop apps is nice. No need for a different tooling like snap does. And you get to know where it’s going to be installed according to the command used. Desktop apps are usually located in /Applications on macos and cli tools are in linked in /usr/local/bin

                  2. 4

                    Pro:

                    • Has every package imaginable (on Mac)
                    • Writing your own formulae is stupidly easy

                    Con:

                    • You can only get the latest version of packages due to how the software repo works.
                    • It’s slower than other package managers

                    Meh:

                    • Keeps every single package you have ever installed around, just in case you need to revert (because remember, you can only get the latest version of packages).
                    • Might be too easy to add formulae. Everyone’s small projects are in homebrew.
                    • The entire system is built on Ruby and Git, so it inherits any problems from them (esp Git).
                    1. 1

                      Someone told me that it doesn’t do dependency tracking, does that tie in with:

                      Keeps every single package you have ever installed around, just in case you need to revert (because remember, you can only get the latest version of packages).

                      Also, I’m not very knowledgeable on package managers, but not being able to get older versions of a package and basing everything on Git seems kind of a questionable choice to me. Also, I don’t like Ruby, but that’s a personal matter. Any reason they chose this?

                      1. 1
                        • You can only get the latest version of packages due to how the software repo works.
                        • Keeps every single package you have ever installed around, just in case you need to revert (because remember, you can only get the latest version of packages).

                        This is very similar to how Arch Linux’s pacman behaves. Personally, I would put both of these under the “pro” header.

                      2. 4

                        The author of Homebrew has repeatedly said this himself (e.g. in this quora answer). He usually says the dependency resolution in Homebrew is substantially less sophisticated than apt.

                        Homebrew became successful because it didn’t try to be a Linux package manager. Instead it generally tries to build on top of MacOS rather than build a parallel ecosystem. The MacOS base distribution is pretty big, so it’s dependency resolution doesn’t need to be that sophisticated. On my system I have 78 Homebrew packages, of those 43 have no dependencies and 13 have just 1.

                        Homebrew Cask also supports MacOS native Application / installer formats like .app, .pkg, and .dmg, rather than insisting on repackaging them. It then extends normal workflows by adding tooling around those formats.

                        So, yes, Homebrew isn’t as good at package management compared to apt, because it didn’t originally try to solve all the same problems as apt. It’s more of a developer app store than a full system package manager.

                        Linuxbrew still doesn’t try to solve the same problems. It focuses on the latest up to date versions of packages, and home dir installations. It doesn’t try to package an entire operating system, just individual programs. I doubt you could build a Linux distribution around the Linuxbrew packages, because it doesn’t concern itself with bootstrapping an operating system. Yes, it only depends on glibc and gcc on Linux, but that doesn’t mean any of the packages in Linuxbrew are set up to work together like they are on an actual Linux distribution.

                        1. 2

                          I don’t want to rag on the homebrew maintainers too much (it’s free software that’s important enough to me that it’s probably the second thing I install on a new mac), but I do have one big UX complaint: every time I run a homebrew command, I have no idea how long it will take. Even a simple brew update can take minutes because it’s syncing an entire git repo instead of updating just the list of packages.

                          brew install might take 30 seconds or it might take two hours. I have no intuition how long it will take before I run it and am afraid to ctrl-c during the middle of a run. I’ll do something like brew install mosh and suddenly I’m compiling GNU coreutils. Huh?

                          While I’d wish they’d fix this variance head-on, at minimum I’d appreciate if it did something like apt and warn you if you’re about to do a major operation. Admittedly apt only does this with disk size, but homebrew could store rough compile times somewhere and ask if I’d like to continue.

                          1. -3

                            I think it’s awful because it’s written in Ruby and uses Github as a CDN.

                            1. 0

                              This comment isn’t helpful. Please be more constructive.

                              1. 0

                                Who are you to judge? He wanted opinions, I gave mine.

                                The Ruby VM is awfully slow and using Github as a CDN is so bad it requires no elaboration.

                                1. 3

                                  Saying it’s slow is much more helpful than what you said above.

                                  1. 1

                                    Yeah.

                          2. 2

                            Well, this is really exciting. I probably won’t convert to windows, but I have complained that amazing tools like this don’t exist on Windows. I’m really happy that I can’t make that argument anymore. This will hopefully help my windows dev buddies and I more proficient

                            1. 10

                              It says that Windows 10 is supported through the Windows Subsystem for Linux. If that is the only way it is supported you can already use apt.

                            2. 2

                              The one slightly surprising change to me was the removal of options from the formula hombrew-core. The discussion isn’t linked in the post, but you can see more about it at https://github.com/Homebrew/homebrew-core/issues/31510. Note that you can still install from HEAD though.

                              1. 2

                                Despite commentators here generally touting the idea of having a cross-platform package manager, one can clearly see a theme in the comments:

                                • snap and flatpack fail to get traction across Linux
                                • nix is available on Mac but lacks adoption

                                Which is to say, it doesn’t look like most users actually want a cross-platform package manager.

                                Even more, users of various language ecosystems seem to be quite content with having another, language-specific package manager alongside the system one.

                                1. 2

                                  We need more shots at having a cross-(Linux-)distro (if not crossplatform) package manager since flatpak and snap don’t seem to get much traction. Homebrew might have some advantage by starting with a non-zero marketshare.

                                  1. 9

                                    Nix is on a good path, it supports all Linux distros and macOS, has really good support for cross compilation, and has a lot of up-to-date packages (source: https://repology.org/).

                                    1. 2

                                      Nix supports macos and fulfills all criteria, but just has no adoption, so I wouldn’t bet on it. It’s really about size of package repo and afaik homebrew blows all other cross-platform options out of the water there.

                                      1. 6

                                        According to repology (https://repology.org/repositories/statistics), Homebrew has 4,694 packages (78.6% up to date), and nixpkgs unstable has 49,637 (84.3% up to date). If it is about size of package repo, I hope you take a look!

                                        1. 2

                                          That seems… off. Debian unstable is ~29,000. Does Nix consider different versions to be different packages or something?

                                          1. 6

                                            No. We package all of the haskell package set, plus all the emacs modes. I we ignore having packaged some of these collections, we have about 23,000 packages.

                                            1. 1

                                              Interesting, is the “normal” stuff in there, like Firefox? I looked at Nix years ago but I found it too complicated to set up compared to just using APT, given that I don’t really care about rolling things back (now that I’m thinking about it, the only time I can ever remember having something broken by a package manager was when I used Arch for awhile).

                                              1. 6

                                                Interesting, is the “normal” stuff in there, like Firefox?

                                                You bet! On Linux, you’ll get firefox no problem: nix-shell -p firefox.

                                                For macOS, Nix is very good for getting dev tools, but I’d still get .app’s from Homebrew or the app store.

                                                1. 3

                                                  Could you sum up why I should try using Nix instead of Homebrew on MacOS? I’m genuinly interested in switching over if it offers benefits over Homebrew.

                                                  1. 7
                                                    • Allows you to use older versions without problems, hell I can easily get an emacs build from 2009! Very useful for older projects or across different machines.
                                                    • There’s no problem dealing with many different versions of the same package at once. I could have 10 different packages all having a different version of gcc or clang and I won’t even notice.
                                                    • Customize builds easily. Useful for using forks of projects, using alternate dependencies, or changing configure flags.
                                                    • Reproducible builds. A nixpkgs revision can be enough to reproduce a build, no more Builds on My Machine (tm).
                                                    • Pin exact versions of packages, always creating the same environment. Really useful for development with other people.
                                                    • Easily and atomically roll back updates without any traces left behind.
                                                    1. 2

                                                      Hmm, that sounds good. There isn’t any tradeoff whatsoever?

                                                      1. 2
                                                        • It is very different from what you’re probably used to, making it harder to learn.
                                                        • The documentation could be better.
                                                        • The majority of users are on Linux, so the amount of packages that work on macOS isn’t as high, but it’s slowly getting there with more automated building happening.
                                    2. 3

                                      Why do we need cross-Linux package managers? The package manager is arguably the main thing that differentiates the various Linuces (it certainly isn’t the kernel).

                                      1. 1

                                        I used snap a little and found it’s nice. Intellij points to it for command line installation in their docs, that’s nice and easy to use, but I don’t like the extra parameter that is usually required for all apps. I wish this was specified in the package installation file instead so end user wouldn’t have to bother.

                                      2. 1

                                        This would/could be a great way to distribute internal tools to all different platforms in use – just have a privat tap and it should work, no?

                                        1. 2

                                          Simplicity of hosting your own tap is definitely a good advantage. The fact that brew will use local git directly is nice. It makes it easy to consume private repos and leaves the authentication to the right tool instead of using an opinonated new authentication way of consuming private taps