Ask HN: Homebrew for Linux?
13 comments
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'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).
I disagree with the first sentence:
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.
> The linux package managers are significantly better than homebrew/macports
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.
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.
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.
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.
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.
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.
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.
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.
Homebrew for Mac doesn't, so it would be odd for this one to.
> I'm limited by my phone atm, but does this thing have a GUI?
apt has synaptic
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.
This is exactly the same question I had.
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.
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:
> 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.
It's actually not that bad. You can tell npm where to install "global" packages in the .npmrc file:
prefix = /home/foouser/npmlocal
> 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.
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.
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 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/
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.
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.
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.
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...
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...
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.
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.
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)
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.