
Homebrew 1.4.0 - mikemcquaid
https://brew.sh/2017/12/11/homebrew-1.4.0/
======
drinchev
The Patreon page says they receive $177 per month. That's too low for a
project with such a high popularity and usage.

I read somewhere ( and I bet ) it's used by Google / Facebook / Apple
employees.

~~~
ufmace
Reminds me of one of patio11's posts somewhere. I don't remember which one,
but the gist is that big companies basically _can 't_ donate to tipjars,
patreons, etc. But if you make it a product with an enterprise option for
support or something, they'll gladly pay tens of thousands a month.

~~~
atonse
Yes, exactly!

I face this with my government clients. They spend very little time thinking
of the actual amount (even if it's $30k), and more time about "how are we
going to purchase this??"

Tip Jars aren't an effective way to get money for this stuff, at least if you
want money from companies. It's good for "aw this library helped me, let me
throw in $5" from individuals.

~~~
cyberpunk0
Tip jars and pay what you can are effective. Bs corporate red tape is the
problem

~~~
mschuster91
The red tape is needed for legal reasons. As a company you can't just throw
around money via Paypal, gofundme or whatever, the risk is too high that it
will end up being a tax/audit problem.

Give a company a proper bill with VAT, and they'll stuff you with money.

~~~
danellis
Companies make charitable donations. I wonder if there's a charity that
accepts donations for specific projects. If not, is there a good reason why?

~~~
nindalf
Companies make charitable donations to entities registered with the tax
authorities as charities. When a donation is scrutinised during an audit its
clear what its for, based on the receiving entity. A random payment to a
person looks like a bribe or some suspicious activity when its not in direct
exchange for goods or services. This will require an explanation to the person
conducting the audit at the very least.

------
eridius
> _Homebrew requires the CLT on all but the latest version of macOS (to avoid
> copious workarounds in formulae)_

Why? What are these workarounds? The linked PR didn't explain, and as someone
who's still got one machine on 10.12 I'd really rather not have to keep CLT
installed as well.

Edit: Wow, the maintainer on that PR is a real jerk. He refused to answer a
legitimate question (and locked the PR at the same time) because he thought
the original (since edited) complaint of "The error message for this patch is
terrible" was "rude".

MikeMcQuaid, if you ever read this, this sort of behavior on your part is a
great argument for ditching HomeBrew.

~~~
felixgallo
Good luck writing your own version and supporting it. Be sure to post your
progress.

~~~
gutnor
Ah, the passive-aggressive old school OSS defence.

That's not an argument, that's basic herd mentality and can literally apply to
any kind of critic legitimate or otherwise. Even Linus does not get a pass
nowadays and there is really no reason on HN where we can be so critical of
even the most minor design mistake.

~~~
kelnos
I think the parent's dismissal is unfortunate in its nonchalance, but
ultimately is correct.

Look, open source maintainers don't owe anyone anything. It behooves them to
behave in a positive manner in order to encourage people to contribute, and,
well, just because being nice tends to give you a good reputation. But that
doesn't mean they're not still people. Sometimes they'll be curt or terse
after someone asks a question about a decision that has already been beaten to
death because they're just tired of talking about it. Maybe they just had an
argument with a friend or family member and aren't in the best frame of mind.
Maybe they're just having a bad day.

And that's ok. That's just human nature. As long as the majority of
interactions with users is positive, everything's going to be fine. A few
people might get their feelings stepped on here and there, and that's truly
unfortunate, but I'd also hope that those people give the maintainers the
benefit of the doubt and recognize that one bad interaction should hopefully
not sour all the positive value they've gotten out of the maintainer's work.

Sure, if there's a huge pattern of abuse, that's a problem. But I submit that
a one-off issue submitter is not qualified to assess if there's a pattern or
not, especially right after they've just been rebuffed and still feel bad
about it.

------
tzs
Edit: Wow...within 20 seconds of me posting this, an update to "Command Line
Tools" version 9.2 showed up in the App Store app. So, if you have this
problem, check updates again.

Anyone else getting a warning about command line tools?

    
    
      $ brew doctor
    

tells me:

    
    
      Warning: A newer Command Line Tools release is available.
      Update them from Software Update in the App Store.
    

Looking around, I see that there are two sets of the command line tools
installed. There is a set in

    
    
      /Library/Devloper/CommandLineTools/usr/bin
    

and a set in

    
    
      /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
    

The latter is what /usr/bin/clang invokes. The /Library/Developer set is
older. The file date on clang is 2017-10-20 on that one, and 2017-11-17 on the
one under XCode.app.

Homebrew checks the command line tools version by running "clang --version".
It uses this one:

    
    
      /Library/Devloper/CommandLineTools/usr/bin/clang
    

It has the /Library/Developer/CommandLineTools prefix hard coded.

The version I have there is 900.0.38. The version under Xcode.app is
900.0.39.2 (which is the version Homebrew wants).

Looking back at my Time Machine backups, I see that
/Library/Developer/CommandLineTools/usr did not even have a bin directory
until 2017-11-23 (it just had usr/share/man). The bin directory there, and its
contents, were apparently created when I installed "Command Line Tools (macOS
High Sierra Version 10.13) for Xcode" version 9.1 from the App Store on
2017-11-22. That had clang version 900.0.38. That is also the version that was
under Xcode.app at the time.

It looks like on 2017-12-06 there was an Xcode update (version 9.2) that
updated the command line tools under Xcode.app bringing the clang version to
900.0.39.2 (which is the one Homebrew wants).

I haven't seen any updates for the "Command Line Tools" package, so what is
the correct way to get the 900.0.39.2 tools into
/Library/Developer/CommandLineTools/usr/bin, where Homebrew expect to find
them? Is Apple just being slow to get the update out?

~~~
0x0
I got the same warning, opened Appstore.app and found a pending update for the
Command Line Tools that wasn't there earlier today.

------
iRobbery
Oh nice, just upgraded everything yesterday.

Side note: I find it a pity brew upgrade webcalls google analytics.

~~~
mmastrac
You can disable it if you aren't comfortable with it (they document this
clearly multiple places).

    
    
           analytics (on|off)
                  Turn on/off Homebrew's analytics.

~~~
daveFNbuck
I've been using brew for years and wasn't aware that it was using google
analytics at all. It may be clearly documented, but they're not doing much to
ensure users know about it.

~~~
sigzero
If it is clearly documented that should be it. Maybe a blurb on the main page
about it would be nice but not necessary.

~~~
ysavir
Any opt-out features should be disclosed to the user on install. That seems
fairly straight forward to me.

~~~
mynameisvlad
Which, as someone pointed out in a separate comment thread here, Homebrew is
already doing. I'm not sure what else you want from them, they seem to be
following best practices here.

~~~
falcolas
Existing installs were not prompted. You had to catch it in the patch notes,
IIRC.

~~~
mikemcquaid
Not prompted but were notified.

~~~
bobwaycott
The notification when it first came out wasn’t really noticeable for a tool
that frequently has a lot of output an average user running `brew upgrade`
would be used to ignoring. Prompting would have been the better choice. I
didn’t notice until the change hit HN and created a bit of a shit storm.

PS: Despite my feelings of disagreement on how brew handled this, I still
appreciate your work.

~~~
mikemcquaid
Homebrew literally never prompts for anything so a prompt would likely break
many scripts.

------
danra
_The first-time installation on Mac OS X 10.5 has been improved_

This is just pleasant to see. Some people like/are stuck using older OSes.

Which Apple itself conveniently ignores (inconveniently for its developers),
e.g., Xcode hacks and looking for 3rd party copies of old SDKs to be able to
keep compiling for older OSes. :(

~~~
orbitur
While it's definitely bad that Apple stopped supporting PowerPC Macs just 3
years after they sold the last machines, expecting any support at all 10 years
later is ridiculous.

What ties people to PowerPC these days? Surely the speed and power consumption
of the latest Intel machines is 100x better?

~~~
danra
10.6 is still used by a lot of people on Intel processors, and compiling for
it on a modern platform involves the hacks I mentioned.

~~~
kelnos
Any ideas why, though? I can understand not wanting to be on the latest-shiny
until the inevitable initial bugs are fixed... but does Apple even provide
security updates for 10.6?

------
TY
To the conversation of making it easier for enterprises to support open source
projects.

Would it make sense to create a legal entity whose only goal would be to
"sell" enterprise subscriptions to open source products and then channel all
the funds to those projects, after taking a reasonable cut for administrative
expenses - such as invoicing, collection, production of physical media when
required and etc?

That would make support of open source projects fit much easier into standard
enterprise procurement process.

Each project would define different levels of subscription with different
price tags. Token licenses would be generated and physical media created and
mailed out.

Pretty sure something like this was already discussed on HN?

------
bluedino
Does anyone use MacPorts/Fink anymore? What are the use cases for them?

~~~
zakk
MacPorts user here. Uses case are the same, but:

\- MacPorts does not track you by default with Google analytics.

\- MacPorts lives by default in a self-contained directory tree.

\- MacPorts tends to be more stable than Homebrew, but that’s just my personal
experience.

\- I didn’t like the slogans Homebrew used for years, implying MacPorts wasn’t
good quality.

~~~
zbentley
Does MacPorts have anything like Homebrew Cask? I know it's technically a
plugin/addon, but it owes its existence to the Homebrew tooling and ecosystem
it's on top of.

The ability to very easily install full GUI apps, or closed-source ones, is
absolutely indispensable for automatically configuring Macs in many large
environments, especially those (like a former one of mine) that heavily used
Puppet for provisioning.

If MacPorts is lacking in that "umbrella package manager" functionality, I'd
be stuck using both it and cask if I switched (and, given my positive
experiences with Homebrew core and cask, I have no plans to).

~~~
zakk
The MacPorts system is flexible enough that you can use it to install any kind
of software.

Honestly I don't know if that's popular, when using Homebrew and MacPorts I
was always installing open source stuff...

------
2bitencryption
does homebrew still* use Github as the store for all packages?

Just curious, that always seemed like a strange scenario.

* or am I wrong that it ever did?

~~~
jameskilton
"Packages" in homebrew are nothing more than Ruby install files called
Formulas[1]. So using Github works really well for their use case and I don't
think there is any thought of changing it. Updating homebrew, new formulas,
etc, is nothing more than a `git pull`.

[1] [https://github.com/Homebrew/homebrew-
core/tree/master/Formul...](https://github.com/Homebrew/homebrew-
core/tree/master/Formula)

~~~
FooBarWidget
Not quite. They also supply precompiled binaries nowadays, one version of each
supported macOS version. They have a CI infrastructure that continuously
builds precompiled binaries for all formulas, for all supported macOS
versions.

~~~
jameskilton
Right, those binaries are hosted in Bintray
([http://homebrew.bintray.com/](http://homebrew.bintray.com/))

~~~
diggan
Is there any facilities for mirroring this or this "belongs" to bintray?
Torrents, magnet links, rsync server or something like that.

You would think `wget` for building your own mirror would work fine but no,
[http://homebrew.bintray.com/bottles/](http://homebrew.bintray.com/bottles/)
returns "Forbidden", probably because the directory listing is too large.

------
dunein
Awesome! At some point I would like to get into Homebrew development (I'm
already familiar with Ruby).

~~~
mikemcquaid
We'd love that! Here's a good starting point and feel free to contact me
directly if you'd like other pointers.

------
jlillyreed
Just curious, where can I find their reasoning for removing apache & php from
brew? Is it because they come pre-installed on macs?

~~~
chipotle_coyote
They're removing those _taps,_ but that's because they're migrating the
formulas to homebrew core. Do a "brew update" and "brew search apache" and you
can see they're all there, but now as just, e,g, "apache-httpd" rather than
"homebrew/apache/apache-httpd". I assume the same is going to happen with PHP.

------
snitzr
How does one upgrade?

~~~
AlexeyBrin

        brew update
        brew upgrade

------
philip1209
The maintainer's tweet about interviewing at Google is one of my favorites:

[https://mobile.twitter.com/mxcl/status/608682016205344768?la...](https://mobile.twitter.com/mxcl/status/608682016205344768?lang=en)

~~~
ubernostrum
One of my less-favorite things is how many people always pop up to defend the
Google approach and argue that if he couldn't pass such an interview he must
by definition not be qualified.

~~~
bunderbunder
I can count the number of times I've needed to implement any binary tree
algorithms on one hand. And they've all been either homework when I was in
undergrad, or job interviews.

That said, I'm pretty sure that interview questions like these are not about
whether or not someone is qualified to do the job they're actually doing, and
100% about companies trying to come up with a standardized, one size fits all
tech interview that can be used for every position. Since the intersection of
necessary skills for all kinds of developer jobs is something close to
{"understands values vs. references", "knows at least 1 programming
language"}, though, the result of any such endeavor is going to involve a lot
of noise.

It works for Google because they're such an attractive employer that they're
dealing with essentially zero risk that they accidentally filter out all their
qualified applicants with stuff like this. It probably even helps company
morale by fostering a perception among Google employees that they are an elect
few.

~~~
feelix
>works for Google because they're such an attractive employer that they're
dealing with essentially zero risk that they accidentally filter out all their
qualified applicants with stuff like this

You know the founder of homebrew was filtered out by exactly this, right?

~~~
bunderbunder
Yeah, that's the context of this thread.

I said that there's minimal risk that they filter out _all_ qualified
applicants, not that they won't filter out any of them.

------
huwinfa
Excellent

