Ask HN: Homebrew for Linux?

13 points by jalan ↗ HN
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 ] thread
Why wouldn't you use the package manager that your distro comes with?
I'm limited by my phone atm, but does this thing have a GUI?

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

> I'm limited by my phone atm, but does this thing have a GUI?

apt has synaptic

If you're going to run Arch then you should really stick with being comfortable with the CLI. There's no telling when something will break the upstream GUI packages, or something wont load on boot and you're stuck in single user mode.
Homebrew for Mac doesn't, so it would be odd for this one to.
On Ubuntu or Debian? Use apt-get. On RedHat or CentOS? Use yum.

Homebrew replicates the behaviour of Linux package managers for Mac.

I agree, but homebrew replicates only a small part of that the linux package managers do.
If you need the most packages and the quickest then you should use ARCH linux. Otherwise use your package manager (like others have pointed out)
The linux package managers are significantly better than homebrew/macports. If you're using Debian or a distro based off of Debian (Ubuntu, CrunchBang, ...etc) then you can use apt-get or aptitude.

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

If you really want to build from source, there is always Gentoo as well.
portage also supports custom packages in additional port trees similar to homebrew.
I disagree with the first sentence:

    > The linux package managers are significantly better than homebrew/macports
I think homebrew has an infinitely better UI than apt-get (I use both OS X and Ubuntu full-time at work, OS X and Arch at home). Where the Linux package managers are better is stability; homebrew doesn't have rigid enough testing practices to support the aggressiveness in which they update packages. But that falls on the devs and not the tool.

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.

After using os x for a bit w/homebrew, I'd sum it up like this:

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.

Have you used synaptic?
Used it once.....yeah
I was asking dljsjr to find out what (s)he prefers in the homebrew ui over synaptic. Synaptic just gets things done without getting in the way.
See my comment about clarifying UI vs GUI.
Can you provide some examples of where you think homebrew has a better UI than apt-get? I can't think of anything in homebrew which feels significantly easier than apt-get or yum.
`brew search` + `brew info` is about a million times more sane than `apt-cache show`, which I find sucks (is usually too aggressive or too specific in its fuzzy matching) and is poorly named. Plus, why the hell have apt-get and apt-cache separated in to two commands? Insane.

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.

Sure, apt-get is crap but there are other package management UIs on Linux such as zypper which are fantastic.
Try wajig:

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.

Actually, package managers are core to most Linux distributions! That's been the case long before there was ever Homebrew for OS X. You should almost never have to manually install from source if you're installing anything relatively well-known.

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.

I use linuxbrew to manage installations under my home directory because I don't have root privilege. And I found that quite useful. But if you have root privilege, there is no reason not to use package manager provided by the distro.
Though I agree that in most cases package managers fulfill this need perfectly well, there are cases in which homebrew does provide something unique. Which is the reason that I contributed a tiny bit to linuxbrew (reporting bugs and suggesting fixes).

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.

It's not clear if you are asking about Homebrew or Macports. If you're asking for a Linux wrapper around Macports, I think you've found it. If you're asking for a cross-platform build system, NetBSD's pkgsrc (http://pkgsrc.org) supports Linux -- though there is no pkgsrc Homebrew equivalent that I know of.
The best feature of homebrew, in my opinion, is that it doesn't require sudo for installation of any package -- in fact, it complains if you try to install something with sudo. Contrast that, say, with npm -g. Most npm -g installs will fail without su, unless you are willing to spend a half hour reconfiguring where dependencies install--pretty fucked in my opinion, as you could potentially install something really nasty.

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.

> Contrast that, say, with npm -g. Most npm -g installs will fail without su, unless you are willing to spend a half hour reconfiguring where dependencies install--pretty fucked in my opinion, as you could potentially install something really nasty.

It's actually not that bad. You can tell npm where to install "global" packages in the .npmrc file:

  prefix = /home/foouser/npmlocal
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.

I personally don't see this useful at all for Linux... however I see this replacing ports on most BSD based systems. Its definitely more modern and easier to maintain. I use homebrew for my Mac's but for all my linux systems I use apt/yum depending on the system. I see no reason to use anything else on them.
More power to them, but I'm not sure why they're doing this. Pretty much every package manager included in current distributions is more useful than Homebrew. Homebrew only exists to patch a package manager into a system that isn't built with one.
I don't particularly like homebrew compared to the Linux distro package managers, but I have found it convenient for messing around on my Macbook due to the large existing library.

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/

Exactly! For anything were I have to deploy, I currently use FPM which you mentioned together with freight (https://github.com/rcrowley/freight) to generate a debian apt repository. Just serve the resulting folder with nginx/apache/... and you're good to go. It also signs the packages.
The problem with apt-get for my use case is that most packages are outdated. If I need to install the latest version of a package I have to Google for instructions which is quite annoying. e.g. these are the steps to install Node.js:

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