Ask HN: Homebrew for Linux?
I recently discovered this project called linuxbrew (https://github.com/Homebrew/linuxbrew), and it is still under active development.
I do use Homebrew for Mac, but on Linux, I am comfortable with the manual installation process.
Is this really required for Linux, considering the current scenario? Is it worth the wait and excitement.
33 comments
[ 0.24 ms ] story [ 86.5 ms ] threadUsing Arch I'm in love with Pacman and AUR, and apt and the other package managers are great/just fine too. They aren't exactly hard to learn so the only way I see Homebrew being needed is if it provides a great GUI with more accessible depth compared to existing alternatives.
apt has synaptic
Homebrew replicates the behaviour of Linux package managers for Mac.
If you're using redhat or a distro based off of redhat (Centos, ClearOS, Fedora) then you use the yum package manager.
Finally you have arch linux which uses pacman and yaourt (for non-official packages).
EDIT:
It seems that people think I meant "GUI" when I said UI. I strictly meant User Interface; in this case, the command line is the front-end to the user interface. I feel that homebrew has a better CLI than things like apt-get or pacman.
OS X has a design philosophy of simplicity for the average user. Putting commom settings into guis, and having the more complex ones in terminal. Homebrew follows this. Its great for installing, removing, and searching, but if you want to do something complex have fun.
Desktop Linux distros caters to the power user. Its idea is why have lots of GUIs which hide the 'advanced configuration', and instead uses command line. Lots of UX design has gone into these commands to insure that they remain simple enough.
Finally windows on the other hand decided to avoid the terminal at all costs. They decided to put every single setting into a gui with little consideration on what the 'average' user will use.
The output of a `brew install` command is much easier to parse than the output of a `apt-get install` command. So is the output of a `--dry-run`.
The UI for dependency conflict resolution in `apt-get` is bizarre. And the one in `aptitude` isn't much better.
I also like that brew is built on git. This is part of the UI for managing versions (the other being the semi-undocumented and unpublicized `brew switch` command), and `brew` is a lot more understanding of being able to switch between versions of packages on the fly.
Description: simple and unified package management for Debian Wajig is a single commandline wrapper around apt, apt-cache, dpkg, /etc/init.d scripts and more, intended to be easy to use and providing extensive documentation for all of its functions.
If you're using Debian or Ubuntu, you should use the APT package manager. A good tutorial can be found here: https://help.ubuntu.com/community/AptGet/Howto
If you're Fedora or Red Hat, you should use yum, which a tool for the RPM package manager. Here is a list of basic yum commands: http://yum.baseurl.org/wiki/YumCommands
You can find more explanations/tutorials if you search using queries like "apt tutorial ubuntu" or "yum tutorial red hat." Hope you get acquainted quickly!
This might raise the question: Why make Homebrew work on Linux if other package managers exist already and work really well? I can think of a couple reasons: 1) fun experimentation, and 2) the fact that Homebrew formulas are Ruby code, which many people find more approachable to write than APT or RPM packages. My opinion is that it would be fun to see Homebrew on Linux, but it's not necessary given that existing package managers work very well, and many developers are willing to do the work of packaging for the rest of us.
1) You need the newest version (ffmpeg for example is something that is often out of date on linux distros, or what about the latest and greatest gcc or llvm, or...) 2) Your distro doesn't have it as a package. Case in point, debian (wheezy) doesn't have ag (the silver searcher). After getting some issues fixed on linuxbrew, I was able to do "brew install ag" on my debian an there it was, a fresh silver surfer.
So I don't agree with most posters claiming or implying that homebrew for linux is useless. The closest (and arguably better) you can get is either Archlinux or Gentoo (of which I prefer Arch, which I used for a long time), but if you don't have free choice of distro, linuxbrew gets you quite far.
Now, many package managers like apt-get use curated databases for their packages. But in my view, this just is not enough. Homebrew's respect of the user's system is just superior.
It's actually not that bad. You can tell npm where to install "global" packages in the .npmrc file:
and then just add the bin sub-directory into your $PATH.> Now, many package managers like apt-get use curated databases for their packages. But in my view, this just is not enough. Homebrew's respect of the user's system is just superior.
Agreed. This matters even more as a lot of packages are available only through PPAs.
A couple of other interesting projects in the Linux software installation space, which I have been using recently:
* fpm ("Effing Package Management"): https://github.com/jordansissel/fpm/wiki
Can be used to generate deb or rpm packages given a source directory or existing package of various types. (For example, generate an RPM from a Rubygem.)
I use this frequently to quickly create distro packages from software which only has source available, then put them in a yum repository on S3 for my private projects. (Creating package repositories is so easy, and signing them isn't much harder. It's really worth doing.)
* EasyBuild: https://github.com/hpcugent/easybuild
EasyBuild automates building software from source, and provides a framework for automating a variety of complex build processes. It's targeted at high-performance scientific computing, where many of the applications have arcane or bizarre build processes, and includes modules for a huge variety of scientific apps.
The big advantage (IMO) is that EasyBuild integrates with Environment Modules [1], which makes it easy to work with many different versions of the same software side-by-side. EB doesn't put everything in the same tree; each package is installed into its own directory and Environment Modules is used to manage the PATH, LD_LIBRARY_PATH, etc. "module load hdf5/1.8.11" and you're good.
I use it extensively both on my laptop and on some of the compute clusters I manage, where users frequently need to be able to switch library and application versions quickly and easily.
One workflow I've been experimenting with recently: Use EasyBuild to build and install all packages into locations in /opt on a dev machine, then use fpm to package them and upload into my repo. Reproduce the system by installing the relevant packages from yum, and still get the flexibility of using Environment Modules.
[1] http://modules.sourceforge.net/
sudo apt-get update
sudo apt-get install python-software-properties python g++ make
sudo add-apt-repository ppa:chris-lea/node.js
sudo apt-get update
sudo apt-get install nodejs
https://github.com/joyent/node/wiki/Installing-Node.js-via-p...