
Linuxbrew – A fork of Homebrew for Linux - gil_klein
http://brew.sh/linuxbrew/
======
davexunit
This is totally silly. Homebrew isn't a very good package manager. When I used
it at a previous job (the only time I've used OS X), it was quite unreliable.
It would try to build most things from source (which sometimes failed), but
then download pre-built binaries for others. IIRC, installing the MySQL
package just downloaded a binary from Oracle, it wasn't even a binary pre-
built and verified with Homebrew! I have zero confidence in Homebrew to
provide any security.

Now, I see that people are saying that it fills a niche of having the latest
and greatest builds of things. Other GNU/Linux distros already have similar
things. Arch Linux's core repo is quite fresh and there's also the AUR for
bleeding edge stuff. Debian testing isn't as fresh, but it has most new
software fairly quickly. I don't know much about Gentoo, but it's overlay
system gives users easy access to custom repos with bleeding edge software.
Hell, even Ubuntu seems to have PPA for everything if the software in the
release isn't new enough. Then there's some less known options like Nix and
GNU Guix that provide very up-to-date packages and have far more features than
Homebrew.

In short, we need better system package managers for our distros, not
additional package managers to slap on top of the distro we use.

~~~
lectrick
The whole point of Homebrew is:

1) To install things in _userland_

2) To make maintenance easier.

Is there a Linux package manager that puts everything in userland in a place
like /usr/local? If not, then it installs things _into the operating system_ ,
essentially. And that is bad design, pure and simple. You're basically
mutating your OS, with nondeterministic results- such as I often run into when
I hit "update everything" and my Linux distro then refuses to boot.

~~~
stephenr
The whole point of Homebrew is to be a package manager for OS X, and it's only
popular because its the best of several shit options.

That it installs things as a non-admin user is not specific or inherent to its
goal.

~~~
tlrobinson
It's one of the key differences between Homebrew and existing OS X package
managers (Macports, Fink) and they talk about it quite a lot on the homepage
and installation instructions. IMHO one of the reasons it's more popular.

 _" The standard script installs Homebrew to /usr/local so that you don’t need
sudo when you brew install"_

[https://github.com/Homebrew/homebrew/blob/master/share/doc/h...](https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Installation.md#installation)

 _" Homebrew installs packages to their own directory and then symlinks their
files into /usr/local."_

 _" Homebrew won’t install files outside its prefix, and you can place a
Homebrew installation wherever you like."_

[http://brew.sh/](http://brew.sh/)

------
jamescun
Homebrew was created to add the package manager experience of Linux to Mac OS
X, so what gap does this fill?

Mac users already experience issues relating to having multiple non-default
package managers (i.e. Homebrew and MacPorts) - what conflicts will having a
default and non-default package manager arise?

The problem it is trying to solve would be better approached hosting Debian,
RHEL etc repositories which mirror each other in their structure.

~~~
AlexMax
> The problem it is trying to solve would be better approached hosting Debian,
> RHEL etc repositories which mirror each other in their structure.

I disagree, and I think Linuxbrew fills a different niche.

When you install something from your distro's package manager, you are
actually installing another program that happens to come with the operating
system. This has two implications:

\- It's usually fixed at a particular version for that distro release.

\- It's installed into the root filesystem or /usr.

When you compile something from source or download a pre-compiled .tar.gz, on
the other hand, it's not something that came with the operating system, it's a
third-party package installed by the administrator, and the rules are a bit
different:

\- You usually grab the latest version or a very specific version from the
vendor's website.

\- The correct place to put it is usually in /usr/local.

This is where the FreeBSD ports tree puts programs, and this is also where
Homebrew puts programs in the OSX version at least. Assuming that Linuxbrew
does the same thing, I believe Linuxbrew aims to be the ports tree equivalent
for Linux.

~~~
nailer
Building from source and installing packages aren't mutually exclusive.
Particularly because of the buildroot stuff for GNU autoconf apps, you can
just grab '/' in the build root and get everything installed by the build,
then update the %files from that (removing common dirs, so your package
doesn't own /usr just because it made buildroot/usr).

OTOH if someone said RPM spec format was archaic I'd certainly agree.

------
SwellJoe
Homebrew is not only a weak package manager, it is a dangerous package
manager. No one makes it clear anywhere in the docs or on the site that it
should never be used on a server or world-facing service...and people are
using it for that.

Because it is installed in userland (its most advertised feature), it runs
everything as the same user (probably an admin level user with sudo
privileges). This throws away 40 years of basic UNIX security wisdom. All so
you can install it without sudo.

I recently set out to make our software (and all of its dependencies)
installable on Mac OS X. I tried Homebrew first, because it seems so popular
and well-liked. But, it's just awful. Coming from a couple of decades using
Linux package managers, it's like stepping into the stone age, and it's absurd
to bring something that is vastly inferior to the existing options on Linux
over. I even blogged about it, for a variety of reasons (mostly to warn people
off of the thing): [http://inthebox.webmin.com/homebrew-package-installation-
for...](http://inthebox.webmin.com/homebrew-package-installation-for-servers)

Frankly, this is like porting the DOS command line to Linux (which has
probably happened at some point, but hopefully as a joke or to solve a
specific problem).

So, if you're going to use this, know that it is for _home_ use. If you are
putting this on a server for installing services (as I found many people on
the web doing with the Mac version) you are doing it _so_ wrong.

~~~
davexunit
>it is a dangerous package manager

To go along with this theme, I must ask: Does homebrew do any isolation when
building from source? Chroots, separate process namespaces, etc.

>All so you can install it without sudo.

This is actually a really great feature. I work on a package manager called
Guix, which also allows for unprivileged package management. It's one of my
favorite features. You and I could have user accounts on the same machine and
use different versions of the same application without conflict.

Of course, I don't know what the security story is for Homebrew, but it
doesn't look to be better than average. We take security very seriously with
Guix, to the point that we are seeking things like bit-for-bit reproducible
builds.

~~~
SwellJoe
"Does homebrew do any isolation when building from source? Chroots, separate
process namespaces, etc."

No. This is why they install as the user. "For security", you see.

I agree that non-root installs are a useful feature for some scenarios. But,
the problem with that for servers is you _need_ to be able to start all of
your services as _different_ users. That's really not optional. How you get
there doesn't really matter, to me, but dpkg and RPM have long had it solved.

I've looked at Guix and Nix, and find them neat. I'm kind of a package
management nerd (and I judge all operating systems by their package management
story...Windows and Mac OS X are unacceptable, most modern Linuxes are pretty
pretty good, FreeBSD is getting better). I'm not sure I'm willing to make all
of the tradeoffs and move onto such a foreign system layout, but it's on my
radar.

~~~
Ded7xSEoPKYNsDd
> But, the problem with that for servers is you need to be able to start all
> of your services as different users. That's really not optional.

Anything with an attack surface also must not be able to replace its own
binaries/code. Otherwise a one-time exploit is instantly updated to a
permanent infection.

------
zz1
Honest question.

Homebrew is the missing package manager for OS X. Linux has package managers,
so why a fork? Packages just available through homebrew?

~~~
untitaker_
I personally have always hoped for a unified package manager across distros.

~~~
justincormack
Not very likely that they adopt one, but pkgsrc works across OSX, Linux, the
BSDs, Solaris and more.

------
phillips1012
Why exactly is this needed?

Conflicting with the system's package manager is obviously the most
problematic issue with porting homebrew to linux, and I can imagine there's
many more caveats that would render such a thing pretty useless.

~~~
lectrick
1) it puts software into /usr/local, in userland, which is safer from both an
OS stability and security perspective, since 99% of installable software
doesn't deserve to run as root anyway. And then it modifies the PATH so that
the OS first looks there, making it supersede any OS-installed packages.

2) it uses git

3) it has a really nice Ruby DSL (probably lost on you)

4) as I've mentioned elsewhere here, I've OFTEN hung my Linux distros on the
next boot by doing a simple "apt-get update". This has NEVER happened in years
of using Homebrew.

5) If you Linux folks had any sense of design (software or otherwise) to begin
with, your OS wouldn't be primarily relegated to the backend, so the fact that
you're one of dozens of people repeating the same "we don't need another
package manager" doesn't surprise me in the least, because you guys wouldn't
recognize a better design if it pulled up to you in a bus like this:
[https://www.youtube.com/watch?v=sLB-
uMPj27s](https://www.youtube.com/watch?v=sLB-uMPj27s)

~~~
soneil
Point 1 I keep seeing repeated, but it's entirely false. Installing packages
as the user does not increase security in the least. If anything, it weakens
the traditional unix security model because now the running user owns the
binaries, running processes can modify them.

"run as root" is nothing to do with this. Who installs the package and who
runs it are entirely disconnected. If I install a package as root, and run it
with my user, it's running as my user, not root.

All it actually illustrates is that the package manager is _not_ trusted. You
don't give homebrew root so that it can't damage the OS by accident. The end
result is a binaries that are at risk from errant processes, but it seems this
is preferable to trusting homebrew.

~~~
davexunit
>If anything, it weakens the traditional unix security model because now the
running user owns the binaries, running processes can modify them.

This is a great issue to point out. This is why package managers like Nix and
Guix (and maybe others I do not know about) use an immutable store for package
builds. Unprivileged users may still install and use the software in the
store, but the Unix security model prevents them or a malicious process
running under their user account from corrupting what has been built.

------
jff
The long nightmare is over, Linux finally has a package manager!

------
aikinai
Finally! It looks like a lot of commenters here are confused, but there are a
lot of situations where the default package Linux package managers don't cut
it.

After getting used to the (update) speed, flexibility, and reliability of
Homebrew, it's shocking and frustrating to go back to Linux, where package
managers were born, and have to settle for a less robust ecosystem.

~~~
cheald
Honest question, in what way is brew faster, more flexible, or more reliable
than apt-get or yum? I've had far more problems with it than I have its Linux
brethren.

~~~
lectrick
I have never hung my OS X boot simply by updating Homebrew packages.

I have _frequently_ hung up my Linux distro boot simply by apt-get updating.
To the point that I now run all my Linux OS'es in a VM and take a snapshot
prior to updating. Coming from a Mac background, this possibility is not only
_ridiculous_ , it's _fucking unacceptable._ And it happens BECAUSE apt-get and
yum _mutate the OS install_ instead of installing into userland the way
Homebrew does.

Game, set, match.

~~~
stephenr
if something is stopping your OS from booting, it is _part_ of the OS, and
thus must be installed as part of the OS, and _not_ as a user land tool.

~~~
dragonwriter
Sure, but having a separate package manager (or, at least, a distinct package
management "realm") for pure userland things that _cannot_ break the OS
install so that you know when you install from it you _will not_ break the
install, even with dependencies that may get pulled in, is good for piece of
mind.

It might be better to have a single package manager which supported bother
user and OS packages, and clearly distinguished between them, but in the
absence of that it is good to have a way to install what you intend to be
_user_ packages with an assurance that they _won 't_ be installing OS-level
things that might break the OS install.

Even aside from this guarantee, its good to be able to install things for _a_
user, but to have other users on the same machine whose environments are
unaffected by the install.

~~~
cozzyd
As I mentioned in a different comment, I don't think there's anything about
yum/rpm that precludes doing this. Provided someone took the time to create a
repository of relocatable rpm's, you could create a "yumbrew" script that does
something like

yum-downloader --deps --destdir=~/.myrpms foo-1.3.3.7; rpm -U
--prefix=~/.yumbrew/ \--dbpath=~/.yumbrewdb ~/.myrpms/*

or whatever version of that would actually work. This has the added advantage
that you don't have to compile the packages (although if you wanted to, you
could make the script do that too..)

~~~
stephenr
Dpkg already has a "\--root" option to use a different path for both
installing packages and storing the dpkg info.

I think the biggest issue would be having it recognise packages already
installed in the system when it's using a different info directory - it's
possible a lot of packages would get re-installed "locally".

Other than that, I believe your concept should work on Debian.

------
davexunit
I've commented on this thread too much as is, but:

    
    
        ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/linuxbrew/go/install)"
    

Can we stop telling users to do stuff like this? Please?

------
motoboi
Best feature of homebrew for me is the possibility to package a software with
a pull request.

On the other hand, Homebrew packaging _maintenance_ is done by homebrew
maintainers.

Sooner or later, when they achieve the thousands-of-packages mark, they'll
need packaging guidelines, and then packaging rules, and then a packaging team
(maybe with their own email domain [@debian ;)].

When (if) this happen to linuxbrew, you'll have another linux distribution.

------
drivingmenuts
I'm actually surprised this wasn't done sooner.

~~~
totalrobe
why?

~~~
drivingmenuts
When it came out for OS X, I thought it would be terribly useful on Linux as
well and wouldn't be all that difficult to port.

However, I lacked the time to do it and I don't use Linux as my primary OS.

------
gtirloni
Am I correct in using the term "bike-shedding" to describe our obsession with
package managers, programming languages and web frameworks? It seems every new
release changes things just a little bit, usually to make things more
comfortable but without much efficiency gains. And we discuss it over and
over. Have we run out of hard problems?

------
marrone12
I love the irony of having apt-get and yum install instructions for a package
manager.

------
JacobEdelman
Standardizing a package manager across platforms is nice and making homebrew
for linux does this without just creating another package manager to support
packages.

~~~
amyjess
PackageKit was supposed to do this...

~~~
davexunit
PackageKit doesn't support, and doesn't intend to support, unprivileged
package management features, unfortunately.

------
adamwong246
but _why?_

------
opless
Finally :D

