4 ms·

Yet another reason to ditch the antiquated Homebrew, and switch to the cross platform Nix: http://nixos.org/nix http://nixos.org/nix https://github.com/NixOS/

Yet another reason to ditch the antiquated Homebrew, and switch to the cross platform Nix: http://nixos.org/nix http://nixos.org/nix https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs https://blog.errright.com/switching-from-homebrew-to-nix/ https://blog.errright.com/switching-from-homebrew-to-nix/

astrange 10y ago
Remember when everyone switched to Homebrew because Fink/macports were "antiquated", a.k.a. not written in Ruby? It was nice back then. Packages didn't install themselves in /usr/local.
- Washuu 10y ago
  I remember switching from Fink and Macports because most of the time both of them would break or break something important.
- santaclaus 10y ago
  I left MacPorts because the political infighting between package maintainers often left ports hopelessly out of date.
  - tjl 10y ago
    That's basically the main reason why I left MacPorts. The other was the fact that they'd build their own version of already installed programs. The worst offender for a long time was tetex until they finally added support for looking at an existing tetex installation. I also ran into a number of broken ports. I had used Fink, but I ran into issues with its packaging too. So, when I heard about Homebrew, I decided to try it. It's been pretty decent for me so I've stuck with it. The only major issue I've had has been related to Octave, but that's been a problem for MacPorts too as the OS X version isn't as up to date as the Linux version at times.
- deleted 10y ago
  [deleted]
- cstrahan 10y ago
  > Remember when everyone switched to Homebrew because Fink/macports were "antiquated", a.k.a. not written in Ruby? Yes, I must admit I chose the word "antiquated" quite intentionally, as Homebrew seems to get so much attention (for now) because it's written in Ruby and the website (http://brew.sh/ http://brew.sh/) is shiny, rather than technical merits. > It was nice back then. Packages didn't install themselves in /usr/local. You might enjoy Nix, then -- for that reason, and the following: 1. Everything is stored in /nix/store -- nothing ever touches /{local,}/{bin,lib,share} 2. Profiles are symlink forests that merge multiple packages into one FSH[1]-like tree -- each link pointing into /nix/store. When you install a package, a new symlink forest is created replacing the one at ~/.nix-profile (your user profile, being the default). If you request that nix rollback to a previous "generation" of your profile, all Nix has to do is replace the ~/.nix-profile link to instead point at the previous generation's symlink forest (you can think of this as bumping HEAD in git -- it's nearly instantaneous). If upgrading a package goes wrong, just rollback. 3. Because Nix knows the entire dependency graph, its trivial to distribute a build plan across multiple machines (you can set this up to happen by default) 4. We have a continuous integration server (Hydra[2]) that builds and signs all of our packages. Of course, there's nothing stopping you from building from source (or you could run your own Hydra instance, if you so wish). [1]: http://www.pathname.com/fhs/ http://www.pathname.com/fhs/ [2]: http://nixos.org/hydra/ http://nixos.org/hydra/
  - lawnchair_larry 10y ago
    That's the purpose of /usr/local. /nix/store? Really? You can't just make up new root level directories. That's so wrong.
    - astrange 10y ago
      The purpose of /usr/local is for you to put stuff there, but it actually causes a lot of problems if a package manager does it. - your work-issued laptop might have work stuff installed in there, and the package manager will overwrite it - build-from-source package managers like fink/ports/brew are incapable of controlling themselves and always install things you didn't ask them to Since /usr/local is in the default search path for your compiler, that last one means your personal configure script runs are not reproducible, and you'll start linking to packaged versions of libiconv or whatever without meaning to, and your code won't work on other machines or it'll crash unexpectedly. Fink invented /sw for this, MacPorts uses /opt which I think they got from Solaris?
SwellJoe 10y ago
Aren't the majority of Homebrew users on Mac OS X? Does Nix work on Mac OS X? Don't get me wrong: Homebrew is impressive in how many bad ideas it has implemented in a project that is so exceedingly popular; good marketing and ease of use are amazingly powerful. I thoroughly dislike Homebrew, and sincerely hope people choose not to use it, at all (but especially not on servers). And, also don't get me wrong: I really like Nix, and I believe it has mostly right decisions across the board. If I had my druthers, Nix would be what our near-term package management future looks like. But, if we're talking about Mac (and gods I hope there aren't a lot of people using Homebrew on other Operating Systems, particularly Linux, where we have an embarrassment of riches in terms of good, even great, package managers), I suspect recommending pkgsrc would be a better near term solution. It is more mature on OS X, and it has more packages than Nix. And, while it is not as modern as Nix, it is an acceptable package manager on most fronts, and doesn't exhibit Homebrew's alarming lack of foresight on security questions. http://pkgsrc.org http://pkgsrc.org In short: I like Nix a lot. I dislike Homebrew a lot. So, we're agreed on those points. But, for Mac OS X users looking for a better alternative to Homebrew, pkgsrc seems to be the current best choice (Fink is poorly maintained, macports is slightly better maintained, but pkgsrc is a better package manager).
- dewski 10y ago
  Could you provide constructive criticism for why Homebrew is so bad instead of lambast it?
  - cstrahan 10y ago
    Here's why I don't like Homebrew, and why I believe Nix is (almost) strictly an improvement over it: 1. Updating packages is not safe. If I update openssl and the ABI changes, all of my currently installed packages that depend on it are now broken -- time to rebuild everything. I've burned way too many hours on ABI breakage and rebuilding everything. That problem can't happen with Nix because Nix will ensure that each library is linked precisely to the versions of the libs they need. 2. Nix has a continuous integration server (called Hydra[1]) that builds every package, and caches the binaries. Because Nix knows each packages entire dependency graph, Hydra only needs to build just the packages that have changed. When I want to update some packages, I can count on not having to rebuild everything myself. Each binary package is signed, so I know my stuff is coming from the build server, regardless of whether or not I get the files through a cache or third party. I can also run my own Hydra instance to build my OS X and Linux packages, and I can share the binaries with others should I wish. 3. The lack of determinism. With Nix on OS X, packages are built using OS X's native Sandbox APIs to ensure that the build process can only see the dependencies that were explicitly specified. This guarantees that if the build works on my machine, it will work on yours -- whereas I've seen brew formulas under-specify configure flags and such, resulting in the default of linking to non brew installed libraries, causing quite a bit of confusion when things don't work at run time, or just flat out fail to build. 4. Brew is OS X specific. Nix works on OS X, Linux, and a FreeBSD. As someone who deploys to Linux virtual servers, it's nice that I can use the same versions of packages both in development and production. It's not all roses, though. We have a smaller community of OS X users at this point, so not everything works (thus my "almost" qualification). Regarding the underlying tech and the outlook for the future, Nix is a superior tool.
engiqueer 10y ago
See you there! /s
- cstrahan 10y ago
  See me where? I don't follow.

astrange 10y ago

Remember when everyone switched to Homebrew because Fink/macports were "antiquated", a.k.a. not written in Ruby? It was nice back then. Packages didn't install themselves in /usr/local.

Washuu 10y ago
I remember switching from Fink and Macports because most of the time both of them would break or break something important.
santaclaus 10y ago
I left MacPorts because the political infighting between package maintainers often left ports hopelessly out of date.
- tjl 10y ago
  That's basically the main reason why I left MacPorts. The other was the fact that they'd build their own version of already installed programs. The worst offender for a long time was tetex until they finally added support for looking at an existing tetex installation. I also ran into a number of broken ports. I had used Fink, but I ran into issues with its packaging too. So, when I heard about Homebrew, I decided to try it. It's been pretty decent for me so I've stuck with it. The only major issue I've had has been related to Octave, but that's been a problem for MacPorts too as the OS X version isn't as up to date as the Linux version at times.
deleted 10y ago
[deleted]
cstrahan 10y ago
> Remember when everyone switched to Homebrew because Fink/macports were "antiquated", a.k.a. not written in Ruby? Yes, I must admit I chose the word "antiquated" quite intentionally, as Homebrew seems to get so much attention (for now) because it's written in Ruby and the website (http://brew.sh/ http://brew.sh/) is shiny, rather than technical merits. > It was nice back then. Packages didn't install themselves in /usr/local. You might enjoy Nix, then -- for that reason, and the following: 1. Everything is stored in /nix/store -- nothing ever touches /{local,}/{bin,lib,share} 2. Profiles are symlink forests that merge multiple packages into one FSH[1]-like tree -- each link pointing into /nix/store. When you install a package, a new symlink forest is created replacing the one at ~/.nix-profile (your user profile, being the default). If you request that nix rollback to a previous "generation" of your profile, all Nix has to do is replace the ~/.nix-profile link to instead point at the previous generation's symlink forest (you can think of this as bumping HEAD in git -- it's nearly instantaneous). If upgrading a package goes wrong, just rollback. 3. Because Nix knows the entire dependency graph, its trivial to distribute a build plan across multiple machines (you can set this up to happen by default) 4. We have a continuous integration server (Hydra[2]) that builds and signs all of our packages. Of course, there's nothing stopping you from building from source (or you could run your own Hydra instance, if you so wish). [1]: http://www.pathname.com/fhs/ http://www.pathname.com/fhs/ [2]: http://nixos.org/hydra/ http://nixos.org/hydra/
- lawnchair_larry 10y ago
  That's the purpose of /usr/local. /nix/store? Really? You can't just make up new root level directories. That's so wrong.
  - astrange 10y ago
    The purpose of /usr/local is for you to put stuff there, but it actually causes a lot of problems if a package manager does it. - your work-issued laptop might have work stuff installed in there, and the package manager will overwrite it - build-from-source package managers like fink/ports/brew are incapable of controlling themselves and always install things you didn't ask them to Since /usr/local is in the default search path for your compiler, that last one means your personal configure script runs are not reproducible, and you'll start linking to packaged versions of libiconv or whatever without meaning to, and your code won't work on other machines or it'll crash unexpectedly. Fink invented /sw for this, MacPorts uses /opt which I think they got from Solaris?

SwellJoe 10y ago

Aren't the majority of Homebrew users on Mac OS X? Does Nix work on Mac OS X? Don't get me wrong: Homebrew is impressive in how many bad ideas it has implemented in a project that is so exceedingly popular; good marketing and ease of use are amazingly powerful. I thoroughly dislike Homebrew, and sincerely hope people choose not to use it, at all (but especially not on servers). And, also don't get me wrong: I really like Nix, and I believe it has mostly right decisions across the board. If I had my druthers, Nix would be what our near-term package management future looks like. But, if we're talking about Mac (and gods I hope there aren't a lot of people using Homebrew on other Operating Systems, particularly Linux, where we have an embarrassment of riches in terms of good, even great, package managers), I suspect recommending pkgsrc would be a better near term solution. It is more mature on OS X, and it has more packages than Nix. And, while it is not as modern as Nix, it is an acceptable package manager on most fronts, and doesn't exhibit Homebrew's alarming lack of foresight on security questions. http://pkgsrc.org http://pkgsrc.org In short: I like Nix a lot. I dislike Homebrew a lot. So, we're agreed on those points. But, for Mac OS X users looking for a better alternative to Homebrew, pkgsrc seems to be the current best choice (Fink is poorly maintained, macports is slightly better maintained, but pkgsrc is a better package manager).

dewski 10y ago
Could you provide constructive criticism for why Homebrew is so bad instead of lambast it?
- cstrahan 10y ago
  Here's why I don't like Homebrew, and why I believe Nix is (almost) strictly an improvement over it: 1. Updating packages is not safe. If I update openssl and the ABI changes, all of my currently installed packages that depend on it are now broken -- time to rebuild everything. I've burned way too many hours on ABI breakage and rebuilding everything. That problem can't happen with Nix because Nix will ensure that each library is linked precisely to the versions of the libs they need. 2. Nix has a continuous integration server (called Hydra[1]) that builds every package, and caches the binaries. Because Nix knows each packages entire dependency graph, Hydra only needs to build just the packages that have changed. When I want to update some packages, I can count on not having to rebuild everything myself. Each binary package is signed, so I know my stuff is coming from the build server, regardless of whether or not I get the files through a cache or third party. I can also run my own Hydra instance to build my OS X and Linux packages, and I can share the binaries with others should I wish. 3. The lack of determinism. With Nix on OS X, packages are built using OS X's native Sandbox APIs to ensure that the build process can only see the dependencies that were explicitly specified. This guarantees that if the build works on my machine, it will work on yours -- whereas I've seen brew formulas under-specify configure flags and such, resulting in the default of linking to non brew installed libraries, causing quite a bit of confusion when things don't work at run time, or just flat out fail to build. 4. Brew is OS X specific. Nix works on OS X, Linux, and a FreeBSD. As someone who deploys to Linux virtual servers, it's nice that I can use the same versions of packages both in development and production. It's not all roses, though. We have a smaller community of OS X users at this point, so not everything works (thus my "almost" qualification). Regarding the underlying tech and the outlook for the future, Nix is a superior tool.

engiqueer 10y ago

See you there! /s

cstrahan 10y ago
See me where? I don't follow.