Homebrew 1.0.0 - <AUTHOR> http://brew.sh/2016/09/02/homebrew-1.0.0/ <comment><USER2> I've worked with mike to maintain formula for years and he is always pleasant and on top of things in what is a very hectic job.

Homebrew is such a good package manager (and not for the reasons any package manager is classically considered good). It's great because the community is so vibrant, the user experience is so well thought out, and the formula dsl makes so much logical sense. It's actually both a GitHub and Ruby showcase.

Thanks homebrew team! Here to many more years of accessible packages on the Mac.

<comment><USER3> > not for the reasons any package manager is classically considered good

You can say that again. Homebrew's dependency management is a fucking joke, to the point that it might as well not exist.

<comment><USER4> That's the reason I stopped using Homebrew and plenty of other comments have said the same thing. Maybe it's changed recently, but last time I used it (about a year ago), dependencies were not cleanly resolved in every case.

<comment><USER5> What better alternative exists?

<comment><USER3> Depends what sort of packages you want.

I used to use it for things like local installs of server-side stuff (e.g. language runtime, database server, cache server, etc) but I've moved to using vagrant (and in turn Debian, so Apt) for those things.

For dev tools such as Mercurial, Git, Autotools, etc there are first/third party .pkg installers available.

</comment></comment></comment></comment></comment><comment><USER6> As a user, Homebrew is a great experience.

As a package maintainer, though, one thing surprised me: you can't make your package depend on a specific version -- even a major version -- of a library.

So if MyApp uses YourLib 1.0, everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors. I have no choice but to drop whatever I'm doing and make MyApp compatible with YourLib 2.0, which may even be impossible.

It's just odd because otherwise Homebrew is so well designed. It seems like a weird omission.

Edit: Some packages get around this by packaging major versions separately (qt, qt5) but most don't.

<comment><USER7> "everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors."

Sorry, this is just not true, we hold merging YourLib 2.0 into core until all dependents are upgraded or boneyarded. Maybe you're speaking from your outdated experience with brew years ago.

Also, we do have plans to support multiple versions of libraries, see [https://github.com/Homebrew/brew/issues/620](https://github.com/Homebrew/brew/issues/620) "Handle Versions Better" (although I'm not necessarily a fan of this personally). We also have an email@example.com formula in core already in case you want a sneak peek of the future.

<comment><USER7> To be clear: I'm only talking about core here. If you try to compile external software against brewed libraries, of course you may run into problems, but we do have the homebrew/versions tap, and you can always host your own taps for outdated libraries.

<comment><USER6> Thanks for responding. Yeah, my package isn't in core, although it seems I would just have a different problem if it were (upgrade to YourLib 2.0 or get boneyarded)

I get that it's all a tradeoff, and it must to help keep complexity down if brew is latest-everything.

New versions stuff looks good. I'll look into the versions tap too.

<comment><USER7> > I would just have a different problem if it were (upgrade to YourLib 2.0 or > get boneyarded)

In core this is true. In your own tap you can vendor your dependencies however you want.

</comment></comment></comment></comment></comment><comment><USER8> Throwback to that one time Google wouldn't hire @mxcl. ;) [https://twitter.com/mxcl/status/608682016205344768](https://twitter.com/mxcl/status/608682016205344768)

Well done Mike and contributors! It's a great piece of work.

<comment><USER9> It's hard for me to understand the issue with this. Google didn't hire the guy who wrote software that had a big impact on the community. Does it mean Google misses good engineers because of their less-than-ideal interview process, or simply Google hires only people who are a good fit for their organisation?

Writing the overly bitter tweet surely won't help with improving hiring points. Seems highly unprofessional and childish.

<comment><USER10> Well, he's at Apple now in charge of the Swift Package Manager, so I think he did okay.

<comment><USER11> He left.

<comment><USER12> Yeah I'm curious why he left. From what I could tell it sounded like changes in Swift took an act of congress basically. Which is fine, and how it should be, given how important it is to get it right. I wonder where he went.

<comment><USER13> My understanding is he just doesn't really know how to work in a big company.

<comment><USER14> Meh. I know "how to work in a big company" and choose not to. Talented people will always do whatever they want.

<comment><USER13> You choose not to, but you could if you wanted to, right? He apparently wanted to, otherwise he wouldn't have gone to Apple in the first place, but he just doesn't know how to work in a corporate environment. In fact, he says as much in this tweet: [https://twitter.com/mxcl/status/773574683518119936](https://twitter.com/mxcl/status/773574683518119936)

<comment><USER15> You seem to be looking at this through a somewhat unusual prism.

You and I both "know how" to eat discarded food out of a trash dumpster.

But absent some truly compelling reason, we wouldn't _choose_ to do so, right?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Among all the software I use, Homebrew must be the one giving me the least trouble. I have 100 installed packages and I don't remember the last time anything didn't work. Plus, for anything I care about, updates seem to always take less than a day, usually it's almost instantaneous.

In comparison with MacPorts before, it's like night and day. npm/pip/mix/bundler all seem to periodically conspire to waste a few hours of my time (even though I can do that quite well on my own).

NPM being the worst of the bunch. By a lot. About this much:

`tree node_modules`

<comment><USER17> So npm is bad in your opinion, because it correctly handles different dependencies on packages with varying versions, screwing up? Or is the problem the vast js ecosystem?

I don't think that "tree X" can be a good argument against using any kind of package manager.

<comment><USER18> It's just popular to hate JavaScript and npm right now.

It's not perfect, but it's not bad either.

<comment><USER17> This whole "JS and it's ecosystem is the worst"-meme is just awful. Same goes for the PHP counterpart. I think it's fine to search for better solutions for our backends, but there is no denying that 1) our browsers rely on JS and will do so for the close future, and 2) that there is an ecosystem for every programming language that can use it efficiently and proficiently.

</comment></comment></comment></comment><comment><USER19> "brew update

Error: /usr/local is not writable. You should change the ownership and permissions of /usr/local back to your user account: sudo chown -R $(whoami) /usr/local

.

.

.

==> Migrating HOMEBREW_REPOSITORY (please wait)...

==> Migrated HOMEBREW_REPOSITORY to /usr/local/Homebrew!

Homebrew no longer needs to have ownership of /usr/local. If you wish you can return /usr/local to its default ownership with: sudo chown root:wheel /usr/local"

You got to love the user experience of this! Thanks Homebrew team. <3

<comment><USER7> I see no problem in this. We need writing permissions to /usr/local to finish our migration (as we always did). Once you finish the migration we (hopefully) never write directly to /usr/local again.

<comment><USER7> Sorry, I probably failed to notice the "Thanks Homebrew team. <3" part first time round.

</comment></comment></comment><comment><USER20> Just wanted to highlight that as of this release, all the core code for Homebrew-Cask (the sister project for GUI apps) has been (re)integrated into the Brew codebase. This should allow for tighter integration between the two and a renewed focus on making installing GUI apps as painless as possible!

From a user/developer perspective, we've created a command line utility (`cask-repair`) to make version bumps as painless as possible. Would love to see more people using it [0], and we welcome suggestions and PRs (we have a few long-standing issues that have gone unaddressed, and fresh eyes are always good!)

[0] [https://github.com/caskroom/homebrew- cask/blob/master/CONTRI...](https://github.com/caskroom/homebrew- cask/blob/master/CONTRIBUTING.md)

<comment><USER21> Looking forward to checking this out. One issue I have run into with homebrew is that due to varying packaging choices as a project grows, I've seen stuff move back and forth from brew core to cask to neither, and the old ones stick around at the outdated version so you have to be careful when you tell people to install the thing (seen this happen with terraform for example, which a month ago when I last checked existed as a year-old version in a cask, a few months old version in core, and the current version wasn't available in either).

It might be cool to also allow some kind of process for marking packages as deprecated and showing a warning or confirmation prompt if you try to install it, for the cases when maintainers start packaging in some different way that can't be supported by homebrew.

<comment><USER20> We do have a `deprecated` caveat, but we rely on users to bring up that fact, as there's no way the maintainers can keep track of the status of every Cask.

There's also a fairly large push and discussion about removing duplication between Homebrew core and Homebrew Cask, so you should see things improve. There should also be Formula -> renamed Cask migration at some point, the issue has been raised in brew-evolution. (We have basic Cask <-> Formula support already).

Re: terraform specifically, looks like it's now in core, and `brew cask terraform` will know to do `brew install terraform` automatically.

</comment></comment></comment><comment><USER22> Be aware of "update bug"

If Homebrew was updated on Aug 10-11th 2016 and brew update always says "Already up-to-date". you need to run:

``` cd "$(brew --repo)" && git fetch && git reset --hard origin/master && brew update ```

I had to.

<comment><USER23> It took me way too long of daily `brew update`s to notice something was wrong.

<comment><USER24> it's funny, but other than a few basic tools, most of what I get from homebrew is versionables (nvm, pyenv, etc) of other programming utilities, in that, I don't run brew update very often, usually only before installing something new via homebrew.

</comment></comment></comment><comment><USER25> Brew is awesome. Note though that it gathers anonymous aggregate user behaviour analytics and reports to Google Analytics, see [https://git.io/brew- analytics](https://git.io/brew-analytics) .

You can opt out with

        brew analytics off

<comment><USER26> That's obviously fine for you to do but it's worth noting that we remove software that no-one uses where "no-one" is defined by "no-one using analytics". That's actually our main use-case for analytics.

<comment><USER27> > we remove software

Why? Personally, the only reason I would remove software from a repository is if it didn't work, impacted performance, or cost me an unreasonable amount of money/time. There's a really long tail for software packages.

<comment><USER26> In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.

<comment> a-no-n How did the "royal we" arrive at this "reasoning?"

If popularity were a valid signal of importance, people should only express their eternal love for PHP and Javascript, and ignore computer science, functional programming languages, computer engineering and little-known-but- really-fucking-important packages.

Call me ageist, but code churn and labeling projects "dead" adds nothing in the context of portable code which has matured to the point stability; there's zero functional value added in refactored code being "new." Ongoing support, adding features and keeping pace with platform compatibility are separate issues from judging code to be "inferior" despite working because it's "old." What may seem "dead" to people whom don't know about particular packages but may well just be stable and resting very quietly because it just works.

<comment><USER26> If projects are portable and continue to work without patching indefinitely: we don't consider them dead. What we're unwilling to do is to apply patch after patch to unmaintained and undeveloped projects to keep them working on macOS; at that point we're forking the project and lack either the desire nor people power to do so.

</comment></comment></comment></comment></comment></comment><comment><USER28> Homebrew is a huge help that perfectly fills the niche it's intended for. Thanks for all people involved, you're time savers, which is pretty much the most sought after quality of a software project.

<comment><USER29> Except for loading the Ruby VM. Takes way too long.

<comment><USER26> Which is why for certain things like `brew --prefix` we now do it purely in Bash rather than using Ruby ;)

<comment><USER30> Why would bash be faster ? Would not you essentially call the same C lib stuff anyway ?

<comment><USER31> It would at least save the process-start overhead, plus loading the ruby vm and modules/gems.

<comment><USER26> Exactly. For a simple string comparison Bash is far faster (although Homebrew doesn't use require any gems, just FYI).

<comment><USER31> Good to know, so did the speedup come mostly from not spinning-up the Ruby VM?

<comment><USER26> Yep!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> If Mike is still here in the comments, can you talk a little bit about versioning support? Is this something that's on the roadmap at all, or something that Homebrew has a strong opinion about?

In general, it's a very useful (and pleasant to use!) tool - except for when trying to manage different versions of the same dependency on the same system. Since this is such a big deviation from most package managers, and feels intentional, I'd like to understand why, and whether there is a "homebrew way" of approaching multi-version management.

Thanks again for all of your hard work!

<comment><USER26> We're working on it: [https://github.com/Homebrew/brew/issues/620](https://github.com/Homebrew/brew/issues/620)

</comment></comment><comment><USER33> I have a stupid question. Is there a dogmatic way of listing installed things and sharing that with other brew?

For example, I now list with brew list into a file and edit the file so that whole list is a big brew install. That way if I reinstall OS or go to another I can have same things.

<comment><USER34> Not sure if that's what you wanna do but you could do :

"ls /usr/local/Cellar/ | cat >> myInstall.txt"

<comment><USER33> I just do this for now:

 _cat <(echo brew install) <(brew list) | sed ':a;N;$!ba;s/\n/ /g' > brew_install.txt_

It lists directly from brew, prepends brew install and then replaces all newlines with a space and outputs to brew_install.txt

<comment><USER35> I use brew leaves instead of brew list for this sort of thing; as I usually don't care about the constituent transitive dependencies, only the final results.

<comment><USER33> I wasn't even aware of existence of that!

<comment><USER35> Yeah, I don't know if it's mentioned in the docs. I had written my own version before I found it.

</comment></comment></comment></comment></comment></comment><comment><USER36> Thanks to Mike and everyone else that has contributed to Homebrew. I couldn't imagine how difficult it would be managing command line programs on a Mac without it.

<comment><USER37> I'm wondering if Macs would be as successful with developers without homebrew.

<comment><USER38> Mac OS X came out in 2001, and there was a lot of immediate adoption by people using emacs and bash: It became the largest consumer distro of a Unix-based system overnight. (look for all the old articles about how to upgrade from tcsh to bash).

Homebrew was successful because there were developers who wanted it. Is the Mac more successful as a developer platform because of it? Possibly.

<comment><USER37> It's fun to read all of this. I re-read John Siracusa reviews and some old blogs and yes, until Snow Leopard OSX was THE cool hackers' OS. And when Apple didn't invest in power users anymore, individuals took over.

</comment></comment></comment></comment><comment><USER39> Thank you Homebrew!

As corny as this may sound. I rely on Homebrew to get my unix experience on OS X and not have to compile everything myself. Saves me time and is one less wrench in my development process.

</comment><comment><USER40> As a developer, I'm intimidated - Homebrew sets an extremely high standard for software 1.0 release quality.

<comment><USER41> Remember how long Gmail was "beta"?

<comment><USER24> The funny thing is how quirky the gmail settings look compared to the rest of gmail these days... it works, but it just doesn't quite fit. Though on the flip side, I don't like how much they changed contacts, and that I can't initiate SMS messages from contacts web ui anymore.

</comment></comment></comment><comment><USER42> /usr/local was bad but /usr/local/Homebrew is worse.

The best would have been /opt/brew (short, no uppercase letter)

<comment><USER43> Why is /usr/local/Homebrew bad?

<comment><USER42> Because the UNIX hierarchy is standardized. System admins only expect bin, lib, etc, share, etc. to be in /usr/local. Imagine deleting /usr/local with the intention of only deleting local packages and accidentally breaking a Homebrew install.

Not to mention it's an uppercase H which breaks UNIX file name convention.

</comment></comment></comment><comment><USER44> Homebrew is quite an achievement, it grew in complexity over the years, yet remained reliable and kept a user-friendly interface.

It's also very simple to create packages, it took me less 30 min to learn how to create a package and to deploy it. In comparison last time I checked, creating deb packages is absurdly complex, and I usually just give up and provide a Bash file instead.

<comment><USER45> I find your statement laughable. Brew and Debian's package manager aren't even comparable.

<comment><USER44> apt-get has a wider scope but, in some cases, what it is needed for is to deploy a simple application, and there's no simple way to do that with Debian packages.

</comment></comment></comment><comment><USER46> I like brew, but it's complete ignorance of OSX deployment target version (macosx-version-min) means it's useless for building software intended to run on machines other than the developer's. Most commercial software in other words.

I realise that's outside of it's intended feature set, and it's fine for getting dependencies for other people's github projects or whatever. But what I'd really like is the ability to get dependencies that I can feed into my CI system to build software I intend to give to end users.

</comment><comment><USER47> Thank you guys for making my life as a software dev and end user infinitely easier.

\- brew install postgresql

\- brew install mpv

The list goes on and on and on. You rock!

<comment><USER48> Postgres.app[1] would make your life even easier. :)

[1]: [http://postgresapp.com/](http://postgresapp.com/)

<comment><USER47> I switched to use the homebrew version because I couldn't get the pg tools and such to work from the command line. Nobody got time for that. :P

<comment><USER49> After doing both homebrew and Postgresapp for a while, I've switched to using Docker to run it. It's really nice because then on a per-app basis I can have separate versions easily and all checked into version control.

</comment></comment></comment></comment><comment><USER50> From the announcement: _Use new Ruby Macho library for reading and writing library macOS Mach O file locations._

Why does Homebrew need to parse Mach-O files? Is this for fixing up shared library paths inside executables?

<comment><USER51> Author of ruby-macho (the library being used) here:

Yes, exactly. During bottle installations, we need to be able to relocate dylib references and install names so that they're relative to the Homebrew prefix.

</comment></comment><comment><USER52> I've had few (minor) issues with Homebrew, so I've been wondering about pkgsrc. Has anyone tried using pkgsrc, as a replacement for Homebrew?

<comment><USER53> I found pkgsrc to to be pretty great, but some of the packages are organized in odd ways and badly named. For example TexLive isn't called texlive. Same with xorg-server. I also couldn't figure out how to install Mac specific variants of things like Emacs. So I'm not giving up MacPorts anytime soon.

</comment></comment><comment><USER54> Homebrew is really great, and I recently discovered cask (I know, lame, but I'm a MacOS noob :) ) and it's so nice. No more downloading freaking dmg, mounting, dragging, clicking a bunch of popups, no more visiting the app store.

How is this thing not integrated in MacOS yet?

<comment><USER55> > no more visiting the app store

You answered your own question.

<comment><USER54> True for Cask, but unless I'm mistaken, cask is a plugin for Homebrew. It is not part of the vanilla install.

<comment><USER56> That has changed - it's now part of the main project.

<comment><USER54> Interesting, my bad then :)

</comment></comment></comment></comment></comment><comment><USER57> Ugh, ugh, ugh. I just tried Homebrew for the third time the other day and it made a complete mess of my /usr/local/bin and also screwed up my install of rvm ... never again will I give it a chance. Sorry, but IMO Homebrew is crufty, opinionated software with poor separation of concerns. Macports is the (objectively?) better choice for my needs.

<comment><USER58> > it made a complete mess of my /usr/local/bin

In that case you might be glad to hear that in v1.0.0:

> Homebrew's default repository installation location changed to > /usr/local/Homebrew to keep your /usr/local cleaner

Personally, I really like Homebrew and have never had problems (c.f. MacPorts which gave me big problems a few years ago), but I don't use /usr/local for much else, so that's probably why.

<comment><USER57> Heh, fair enough and thank you, good to know :) Maybe in another year or two my frustration will have abated somewhat. Don't get me wrong, I think it's great that the devs recognized using /usr/local/bin was a bad decision (even if they were kind of forced to because of Apple's SIP).

However -- I just remember, when Homebrew was getting started, all the supercilious (dare I say arrogant?) advice in the docs ... oh, just install to /usr/local, "seriously", etc. (Looking for a reference in archive.org right now ...) Even their whole "Macports driving you to drink?" thing rubbed me the wrong way -- maybe I'm humour-deficient, but I think to criticize another project when your alternative isn't clearly better is just bad taste.

That being said, I am genuinely curious: is there any one awesome thing is that Homebrew does that Macports can't do? Or better, what kind of problems arise from using Macports? I recognize that packaging in Ruby is probably more convenient than in TCL, but other than that? It seems to me that Homebrew is just getting closer to what Macports did (correctly) in the first place. The only way Macports has ever inconvenienced me is requiring a fresh install from time to time when Apple updates their OS, which (for my use case) is minor.

</comment></comment></comment><comment><USER59> Homebrew used to be my go-to tool for installing packages...

But now, with the new Docker for macOS, I never need home-brew anymore. It is especially helpful when you need to run 2 different versions of an app (like elastic search) for different projects.

I can't see myself returning to Homebrew now. That is just not the way to do things anymore.

<comment><USER60> Apples and oranges. I brew install git, Emacs, jq, and other dev tools. Packaging stuff in Docker is fine, but first you have to create or fetch something to package.

</comment></comment><comment> crooked-v As a side note, Ansible users might be interested in the roles I've been putting together for a bunch of the apps I regularly use [1].

You can kinda use homebrew-bundle in place of some of this stuff, but even then there's random installs that need extra configuration or general mucking about with that homebrew-bundle doesn't give a good way to encapsulate (for example, see the duckdns-updater repo and the template it uses [2]).

[1]: [http://galaxy.ansible.com/icopp/](http://galaxy.ansible.com/icopp/) [2]: [https://github.com/icopp/ansible-duckdns- updater](https://github.com/icopp/ansible-duckdns-updater)

</comment><comment><USER61> There has been a lot of talk in HN comments recently about Homebrew installing to `/usr/local`. With macOS Sierra, the user can no longer write to this folder without specifically owning it. Is there a security risk here and if so, whats the best workaround?

<comment><USER62> Newer versions install in `/usr/local/Homebrew`, older versions "migrate" there:

[http://apple.stackexchange.com/questions/253404/how-does- hom...](http://apple.stackexchange.com/questions/253404/how-does-homebrew-no- longer-need-ownership-of-usr-local)

<comment><USER63> I have a hard time understanding the "migration", even after reading all the related issues. Homebrew still writes into /usr/local/bin and /usr/local/Cellar, nothing different from the past. What exactly changes?

<comment><USER7> Writing to /usr/local/bin is not the same as writing to /usr/local. We don't drop a README.md in /usr/local anymore, for instance, and you can change the ownership of /usr/local back to root:wheel after the migration.

</comment></comment></comment></comment><comment><USER64> I enjoyed working and using Homebrew. My first contribution was to bring python 3.5.1 to brew. Loved the processes they have in place for anyone to make a change and have it available for distribution for the whole world using brew on OSX.

Great job for the brew maintainers and contributers. You guys make everyone's job a lot easy!

</comment><comment><USER65> brew update

brew --version

<comment><USER66> Kersten is a nice name.

<comment><USER65> Thanks. icantdrive55 is equally romantic ;)

</comment></comment></comment><comment><USER67> I'm excited about Homebrew potentially coming to Linux. When I first started using OS X more regularly, I was surprised by how better an experience OS X + Homebrew is compared to Ubuntu/Debian repositories + PPAs/third-party repositories.

<comment><USER68> I don't use Linux myself, but am curious as to why this has been so heavily downvoted.

<comment><USER69> I personally don't use Mac OS(X), but what I understand is that Homebrew is a project designed to give the functionality of a Linux command-line package manager to OSX.

For most (all? Slackware...) Linux distributions, there is ONE package manager: for Debian/Ubuntu it's APT, for Arch it's Pacman, for RedHat & friends it's RPM, etc. There is exactly one, because all the files which aren't user data or configuration are owned by some package or other. It's all well and good when there's a clear need for this on OSX, and so Homebrew must keep up to date with the official software management and keep itself contained, not breaking anything. Having a second package manager on Linux, which doesn't treat Linux as the main target platform, seems both pointless and asking for trouble.

Alternatively, you could be harsh and figure that the downvoters were saying, "No, you don't prefer Homebrew. You prefer your distribution's package manager, and thou shalt use it correctly."

<comment><USER70> My issue with those APT on Debian is that I almost always have to add another PPA to download a version of something that I actually want to use. That reduces the utility of APT in my view. Having a crowdsourced list of Homebrew packages to install would be fabulous.

<comment><USER24> Not only that, but a lot of those PPAs become stale, or get replaced by others, and it's only when you upgrade the dist, that you get failures and discover this... It's pretty annoying. It would be nice to have a meta package manager for "current" PPAs for given projects that wraps apt with brew-like ability.

<comment><USER71> Additionally, creating and maintaining a PPA involves one of the following:

(a) Use the upload form for Launchpad.net [0]

(b) Host your own deb server [1]

Unless you use Bazaar for a VCS, the only time you login to Launchpad is to upload a new release. With Homebrew it's built into git with adding a new tag. A _LOT_ lower barrier to entry here.

[0]: [https://help.launchpad.net/Projects/FileDownloads#Publishing...](https://help.launchpad.net/Projects/FileDownloads#Publishing_files)

[1]: [https://www.unixmen.com/setup-local-apt-repository-using- ins...](https://www.unixmen.com/setup-local-apt-repository-using-installation- media-in-debian-8/)

</comment></comment></comment></comment></comment></comment><comment><USER72> I can see a point in the future where everything is installed via a homebrew- like process.

Forget CPAN, CRAN, ports, pypi, go-get, rpm, apt, cabal, crate, opam, ...

Just get it from github or similar with homebrew.

<comment><USER31> Doubtful, homebrew doesn't do any kind of dependency management, so it would be a strict downgrade from pip, gem, cabal, etc

Edit: See comment from rogual elsewhere in this thread - [https://news.ycombinator.com/item?id=12547076](https://news.ycombinator.com/item?id=12547076)

<comment><USER26> That's an exaggeration. We definitely do dependency management, we just don't allow formulae in core to pin against arbitrary versions of software because it often means security updates are never tracked. We are going to loosen this slightly but not dramatically: [https://github.com/Homebrew/brew/issues/620](https://github.com/Homebrew/brew/issues/620)

<comment><USER31> Thanks for the clarification. However, if Foo depends on Bar, will homebrew track the dependency so that I can't upgrade Bar to a version incompatible with the existing installation of Foo? I recall running into that issue a while back, and it gave the impression of version tracking being an install- time-only deal.

<comment><USER26> In homebrew/core and within taps we ensure those cases are handled by `revision`s and CI checks. Across taps this is harder and we're working on it.

</comment></comment></comment></comment></comment><comment><USER73> Yesterday I was downloading a cask and homebrew told me to update because homebrew no longer needs to own /usr/local.

I think that was a perfect way to be introduced to this release :)

</comment><comment><USER74> Homebrew has been my "go to" package manager for years! Well done!!

</comment><comment><USER75> Should I go for a clean install, considering the structural changes?

</comment><comment><USER75> Should I go for a fresh install, considering structural changes?

</comment><comment><USER76> Good.

<comment><USER77> Has opt-out Google Analytics had any help for your project so far?

[https://news.ycombinator.com/item?id=11566720](https://news.ycombinator.com/item?id=11566720)

</comment></comment><comment><USER78> I had uninstalled homebrew this week because it stopped functioning. Out of nowhere, I started getting a ruby error related to a particular package and every CLI call would fail because of it. As someone who works with Go, it's sad to see an error bubbling up and not being gracefully handled.

<comment><USER70> I had errors with Homebrew and Go this week. In both cases, it was an issue with Websense (also known as Forcepoint). Might your issue be related to that?

<comment><USER78> Brew claimed it couldn't find the downcase for another package, not Go.

<comment><USER7> There were bugs in the past few days, but all known ones have been squashed as far as I know, so all you need to do now is

      brew update

_at least twice_.</comment></comment></comment></comment>


Graal and Truffle (2016) - <AUTHOR> https://blog.plan99.net/graal-truffle-134d8f28fb69 <comment><USER2> Fairly old article. A _lot_ has happened since then with these technologies.

<comment><USER3> Could you give more detail. A follow up article. Is GraalVM build ontop of this?

<comment><USER4> Endless resources here [https://github.com/neomatrix369/awesome- graal](https://github.com/neomatrix369/awesome-graal) and here [https://www.graalvm.org/community/publications/](https://www.graalvm.org/community/publications/).</comment></comment></comment>


Show HN: Keywordgenerator.io – A tool to generate thousands of longtail keywords - <AUTHOR> https://keywordgenerator.io/ <comment><USER2> What's your source for these?

<comment><AUTHOR> what do you mean by source?

<comment><USER3> I believe the comment was asking for how you are generating the keywords.

<comment><AUTHOR> Ah I see - the tool just creates permutations of keywords entered, foe example, if you enter 10 keywords in each column, it generates you 10,000 long tail keyword combinations of the words you enter. (10 * 10 * 10 * 10)

It's ideal for when you want a huge list of all your services, sectors and areas covered etc in every combination.</comment></comment></comment></comment>


The Failure of Lisp? A Reply To Brandon Werner - <AUTHOR> http://danweinreb.org/blog/the-failure-of-lisp-a-reply-to-brandon-werner <comment><USER2> Lisp (any lisp, be it lisp-1 or lisp-2) are currently fighting a fight on multiple fronts. From one side, each iteration of Python or Ruby gains new ground as they incorporate more and more lisp-concepts, while being "Visually friendly" (ie, with common syntax). They also have the ability to lure many more users from, say Java or C#.

On the other side, you have any language with type theory governing the language design: haskell, ML, etc. These have long since gobbled up most people interested in type theory and even these are loosing out to the new batch of languages with richer type zoos.

Lisp is not a failure and it has had more influence than people think. However, I think Lisp has played its major part like IBM has played theirs.

<comment><USER3> While I hear many people complaining about the "awkward" and "hard-to-read" syntax, it's rare to hear someone compliment the syntax of lisp. I am a big fan of the Lisp syntax because it's so simple and consistent - probably a relic of its roots in lambda calculus. Not having to worry about operator precedence is a huge bonus in itself - I don't know why on one hand people cling to PEMDAS, logic, assignment, etc having a complicated hierarchy of precedence and on the other reject lisp because it's too "foreign".

<comment><USER4> I agree. I wish ML used s-expressions.

Also, you might like this presentation, "The Swine Before Perl" by Shriram Krishnamurthi (of PLT). It's a great thing to show people who wonder how you could think Lisp has a _good_ syntax: [http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe...](http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePerl/)

(Also: SK's book is great.)

<comment><USER5> ML and it's successors do not want for s-exprs.

They force an inappropriate fundamental data type on everything, and are only of benefit if you want to fiddle with the insides of extant functions.

Use composition like a real FPer. Learn that there's so much more to data than lists + atoms.

<comment><USER4> > They force an inappropriate fundamental data type on everything, and are > only of benefit if you want to fiddle with the insides of extant functions.

Please explain.

(And I know composition, etc. I also use Haskell and Forth.)

<comment><USER2> I think what is meant is that the list is the primary data structure for everything in lisps. Fortunately, it is not the only data structure in lisps. I dislike constructs where eg. a graph edge is built as:

'(GRAPH-EDGE <source-vertex> <target-vertex>)

whereas in ML you would write

type edge = { source: Vertex.t; target: Vertex.t }

which is not a list, but an entirely different representation. In Common Lisp the representation could of course be a CLOS object or a DEFSTRUCT (I think, my CL-fu is definitely not that good).

As for the composition, lisps are lacking (nice) currying which is one of the basic building blocks when constructing combinator-libraries.

<comment><USER6> It's true that earlier Lisp dialects had trouble. But in Common Lisp, you can do currying just fine. At work (ITA Software), it's part of our standard utility library.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Such a respectful reply. To judge by his writing, Weinreb is a genuinely nice man. I'm glad that he has taken on a (semi-) public role as Lisp advocate.

I'm a recent (last 3 years) adopter of Common Lisp who works in it every day. To me Lisp is hardly a failure, it's a secret weapon. For example, a couple of weeks ago I had occasion to take a complex chunk of CL code and make it compile into Javascript as well (I need it to run both on the server and in the browser, under different circumstances). The point isn't that I _needed_ , say, Lisp macros to do this. The point is that I was able to do it pretty _easily_. As a working programmer, I'm surprised by how often something that feels like it'll be scary and hard turns out to be pretty easy in CL. In fact I often spend more time worrying about it than I do coding it (which makes me wonder how long it will take before certain habits that come from experience in less productive environments die off).

This isn't the sort of thing you can really analyze on the level of language features. I find that a lot of the discourse around language comparison is the activity of researchers and hobbyists (for want of a better term) who aren't immediately concerned with building major systems. They like to explore many different things and the programming tasks they take on tend to be conducive to that - coding exercises and such. That's great, but not the same perspective as when you throw yourself into making one big system over months or years. To the first sort of person, the various Lisps and startup annoyances and incompatibilities constitute a huge barrier, enough to say "why bother" and move on. To me they were an investment that paid off relatively quickly and has since produced big gains. (I mean technically. We'll see if they cross over economically.)

Lisp isn't going to have a major resurgence on language grounds alone. It's too old for that, and too suboptimal for blog posts. What would, though, make a big difference is seeing more successful products made with it. That may sound odd as there have been few so far, but that's where I think the untapped potential of Lisp is. And if that ever happens, an ecosystem might develop that has fewer of the dysfunctional aspects of the past. Successful companies that use Lisp would fund open source development, and so on.

<comment><USER6> Thank you for the kind words!

I don't think that Brandon Werner said that Lisp was a failure as a language. As I read it, he's saying that Lisp has failed to capture a lot of new users, get very popular, and so on.

I agree with you that a lot of the really big advantages of Lisp show up better in large systems than in small coding exercises.

There have actually been lots of successful products made with Lisp. People just don't say so, sometimes because Lisp is unpopular and sometimes because it's just not important. InspireData is a great product, but there's no need for anyone to know what language it's in: in fact, it's in the LispWorks implementation of Common Lisp.

For links to success stories, see my survey paper at <http://common- lisp.net/~dlw/LispSurvey.html> and see the "Success Stories" section.

</comment></comment><comment><USER8> Lisp is the second oldest high level language, having barely been pipped by FORTRAN... and it's still around, and under active development. Long way from a failure.

Equally, with that kind of a trajectory and history, you'd also have to predict Lisp isn't going anywhere soon.

If anything, the rising interest and competition in functional languages is pushing Lisp back into the spotlight.

</comment><comment><USER9> I don't know CL, but from the subset of scheme that i know, i cant imagine how can this language fail. It just feels too good and the code is so beautiful. I could say for certain that scheme has made me into a better programmer.

<comment><USER4> Common Lisp and (especially!) Scheme are really elegant languages, sure, but there's really something to be said for being able to install the one clear Python implementation* and getting a huge standard library with lots of documentation and a large community, upfront, versus trying to figure out whether you should set up SBCL or CLISP or PLT or Chicken or ..., then finding there are several libraries for what you're trying to do, but you're not sure they're compatible with the compiler/interpreter you're using, etc. And then, what editor do you use? ("What's this SLIME thing about?") And this, that, and the other thing. That is a _lot_ to figure out, all at once and upfront, before you can try it out. Making it really hard for curious people to play around with Lisp means that few people will see its potential.

All of the above could just as well apply to Ruby or even Haskell. I think Python, in particular, has been really carefully designed to give a good first impression, though. I don't know if that was deliberate or not, but it's brilliant. (I know some people balk at the indentation-based syntax, but I bet many people coming from e.g. a Perl or C++ background think, "Whoa, this looks really clean." "Executable pseudocode.") Lisp doesn't really seem to focus on making a good first impression. (On the other hand, OCaml just says, "Hello!" and immediately backhands you. It makes up for it once you understand the type system, but I'm not at all surprised the OCaml community is small.)

Stuff like Lisp in a Box helps a lot, but it wouldn't hurt to have a link to it in 300-pixel-tall burning letters at the top of lisp.org, you know? You can't even go directly to a download page for any implementation from lisp.org. (When you click the download link at the top of Haskell.org, it takes you right to GHC's download page.)

I've also frequently heard the Lisp community can be rude or off-putting, but I haven't experienced this personally. I could see them being a bit gruff and frustrated about answering a lot of the same questions over and over again, though, and seeing languages like Python and Ruby getting so much more attention than Lisp can be heartbreaking.

So, basically: Marketing.

* I know about Stackless, etc., but which does _python.org_ point you to? QED.

<comment><USER6> Yes, lisp.org needs to be (and will be) vastly improved. We definitely need the equivalent of a CPAN for Lisp, and several of us are working on producing such a thing. You're quite about marketing!

As for multiple implementations: CPython, Jython, IronPython, Stackless Python, PyPy. What editor do you use? Gnu Emacs with Slime; or, some of the commercial Lisp implementations come with IDE's; and there's work being done ("curl") to make Eclipse work well with Common Lisp. Java has several IDE's, such as IntelliJ and Eclipse. For Python, what I'm told by the Python experts I know is that they just don't use any IDE.

But much of what you're saying above is very much to the point. The comments on my blog posting go into these issues more.

<comment><USER4> > We definitely need the equivalent of a CPAN for Lisp

Agreed! I like the Eggs repository for Chicken (<http://chicken.wiki.br/Eggs%20Unlimited%203>), but individual Scheme implementations just aren't compatible enough for such things to really benefit them _all_ \-- I'm pretty sure the lack of a module system in the core for R5RS is to blame. There's one in R6RS, but I hope it's not too little, too late.

</comment></comment></comment></comment><comment><USER10> Some may consider Lisp a failure of a language, but I sure am glad my startup is written in Lisp! The issue of syntax baffles me, because in recently learning Javascript, the essential area of bugs for me were almost all syntax related. I never have to worry about syntax in lisp as its either ( or ). There are no ; or } or { or , etc to worry about what goes where when.

The logical structure reveals itself so clearly in the form of indentation so that the parenthesis become transparent for me. Having emacs slime automate the indenting is of course essential in enabling a clear focus on the function of the code instead of spending time thinking about the syntax.

</comment><comment><USER11> Lisp's biggest problem is the simple fact that most other languages already ship with most nonwindows boxes. _Successful_Lisp_ is a good book (amongst others), but what do you type the code into?

Until today, I hadn't heard of SBCL. I've been fiddling in e-lisp, which is a tragedy of its own sorts. The only mention of SBCL in "google:lisp linux" is an ad. I don't think I'm the only one still afraid of a $5k entrance fee for lisp.

<comment><USER6> Soon, lisp.org will be redone to make it easy to find good free Lisp implementations. Meanwhile, check out my survey paper at <http://common- lisp.net/~dlw/LispSurvey.html>.

</comment></comment><comment><USER12> _"the community is judgmental and unfriendly to newcomers and thorny and un- inspiring."_

Brandon's reply _agrees with this criticism_ , because "I have heard this same criticism from other people than you, and at this point I assume it must really be true."

The comments here focus on lisp. Lisp isn't the problem.

</comment><comment><USER13> In my college days I was very interested in AI and learned Prolog and Lisp.</comment>


Trustwave issued a subordinate root certificate to a company - <AUTHOR> https://bugzilla.mozilla.org/show_bug.cgi?id=724929

<comment><USER2> The lynch mob is in full effect at Mozilla. Tie em up, hang em high, put em out of business!

So a company publicly announces they are revoking a subordinate certificate, the only one they ever issued, as a proactive step to prevent abuse. And the reaction is to destroy them. Seems unfair. Why encourage companies to keep this a secret?</comment>


The Infamous SCSH Scheme Shell "Acknowledgements" (1994) - <AUTHOR> http://www.scsh.net/docu/html/man.html#node_index_start <comment><USER2> He also once wrote:

"Enough of this last-minute, stay-of-execution, midnight-phone-call-from-the- governor stuff. Throw the switch and let's fry this thing."

[https://srfi.schemers.org/srfi-1/mail- archive/msg00077.html](https://srfi.schemers.org/srfi-1/mail- archive/msg00077.html)

Also: "First, do you understand the difference between a dissertation and a thesis? A thesis is an idea. A dissertation is a document that supports your thesis. After you write your dissertation explaining why your thesis is a good one, you have to stand up in front of a crowd and defend it -- the thesis defence. It is best if you can capture your thesis in a single sentence. If you can do this, make it sentence #1 of your dissertation, and repeat this sentence, word for word, wherever you need to drive home the point of your dissertation. This is a tremendous aid in focussing your work. A side benefit is that it provides an unassailable defense to an entire class of attacks on your work. For example, should someone attack your work by pointing out that it does not scale, you simply reply,

 _You may be correct, but right or wrong, your point is irrelevant. My thesis is that "crossbreeding gerbils with hamsters provides an order of magnitude speedup over standard treadmill technology." I clearly demonstrate factors of 12-17 in my dissertation; I make no claims beyond an order of magnitude._

This is one of the benefits of focus."

[http://www.ccs.neu.edu/home/shivers/diss- advice.html](http://www.ccs.neu.edu/home/shivers/diss-advice.html)

<comment><USER3> This is another paragraph that works for me:

The point is: what are you trying to show? The point is: what is your point? If you can get that straight in your head, and put it up front at the beginning of your document, you will be able to proceed in a straight line. You will know what things are essential, and what things are distractions or detours. You will know when to stop writing: when you have demonstrated your thesis. If your thesis committee makes unreasonable demands of you, you will be able to tell them: "(a) My thesis, as stated, is a solid advancement of the field, and (b) I have supported my thesis. This is all I need to do to graduate; your requests are above and beyond this threshold. Cancel them and give me my degree."

</comment></comment><comment><USER4> "Losing $35" by the same author:[http://www.ccs.neu.edu/home/shivers/rants/msoft.html](http://www.ccs.neu.edu/home/shivers/rants/msoft.html)

<comment><USER5> A classic.

<comment><USER4> Autoweapons too: [http://www.ccs.neu.edu/~shivers/autoweapons.html](http://www.ccs.neu.edu/~shivers/autoweapons.html).

"He just couldn't get it through his head that I didn't want to hear about Interlisp, and I damn sure didn't want to hear about 9-fucking-millimeter automatics; we were a Zetalisp/.223 project. I finally gave up on him; that was the first time I'd ever personally encountered the east coast/west coast split in Lisp style and weapons choice."

<comment><USER6> It reads exactly like an Onion article!

 _I am very fond of Berkeley. I think that while LA represents the dark, twisted climb-the-water-tower-and-start-shooting-until-the-Marines-settle-it side of California weirdness, Berkeley represents the very best of the pure, innocent-killer side of it all._

</comment></comment></comment></comment><comment><USER7> > A 10 oz. Jack 'n Zac helps me get through the meetings without one of my > students winding up with his severed head in a bowling-ball bag.

This is very colorful. He should have written thriller novels. Shame he wasted his life doing "something with computers".

</comment><comment><USER8> The reference to "Tops-20 JSYS manuals" is analogous to "Linux syscall wiki". "JSYS" is the opcode for "Jump into the operating SYStem" on Digital Equipment's 36-bit mainframes.

<comment><USER9> Can you get hardcover Print-outs of the Linux man pages, syscalls or other sections? Huge printed manual sections on shelves appears to be a thing of the past...

<comment><USER10> I haven't seen anyone selling them commercially. But if you could find high- quality lever-arch binders and the right kind of blank paper you could presumably make your own Linux version of the Big Grey Wall [http://www.jargon.net/jargonfile/b/BigGrayWall.html](http://www.jargon.net/jargonfile/b/BigGrayWall.html) . I assume that the core APIs change slowly enough nowadays that printing new pages often enough to keep the wall up to date would not be infeasible. One possible problem: IDK if all the snags involved in converting man page troff into other formats are fully ironed out, even now. [http://man7.org/linux/man- pages/man1/gropdf.1.html](http://man7.org/linux/man-pages/man1/gropdf.1.html) Probably the bigger reason not to is that the arrival of cheap tablets and laptops, multi-monitor and/or ultrawide-monitor desktop setups and AR/VR is eroding the remaining usefulness of such hardcopy docs. It still might be a marginally-useful fashion statement for a whole office of programmers who build directly on the Linux APIs fairly regularly.

Probably the nearest thing that's available off the shelf (no pun intended) is a hardcover copy of Kerrisk [http://man7.org/tlpi/](http://man7.org/tlpi/) , which actually happens to be on a slightly-higher-than-usual discount this very weekend: [https://nostarch.com/tlpi](https://nostarch.com/tlpi) .

<comment><USER11> I have used eprinting services to bind APIs as a book before. It's nice - definitely worth the money if you plan on using something a lot.

<comment><USER10> Interesting. Which services did you use, and were you happy with the service and prices? Did you find anyone who will print pages punched for ring-binding?

<comment><USER11> I used lulu - and I just printed the html documentation (it was for Allegro 5) as a novel-size book. The price was fine. Other than that, it wasn't significantly more difficult than ordering any other book - so I have no real feeling for the service. They have a sort of web design app which was predictably terrible, but it didn't really bother me because I didn't want anything on the cover.

</comment></comment></comment></comment></comment></comment><comment><USER12> Ah the '90s, when talking about how much you hate the world and would like to do violence to it was cool, instead of a way to get banned from social media.

<comment><USER13> It got you banned from publishers except when you had a ton of reputation already, so no much changed really...

</comment></comment><comment><USER14> C.f. [https://news.ycombinator.com/item?id=2382531](https://news.ycombinator.com/item?id=2382531)

<comment><USER15> Originally posted by pg in 2007: [https://news.ycombinator.com/item?id=76462](https://news.ycombinator.com/item?id=76462)

</comment></comment><comment><USER16> What's the story behind this?

<comment><USER17> I had Olin as a professor while he was still at Georgia Tech.

Below is roughly as I recall from him telling the story. Olin has a colorful sense of humor (see his usenet posts).

The anti-acknowledgements page was originally intended for his doctoral thesis. It was going to contain everyone who discouraged or otherwise hindered his efforts to degree (e.g. parents, girlfriend). His advisor talked him out of it.

Later when he was at the one of MIT's lab he puts in the SCSH manual. The manual gets printed and distributed. He doesn't hear anything. Later he gets called into the head of the lab's office. Olin comes in and sits down. The director takes out the manual and opens it to the acknowledgements section. The first question is "Who has been stealing your work?", the second one is "do you need to go into rehab?". Olin tells him it's a joke. It ended up being a career limiting move for him.

<comment><USER18> Yeah, go figure. I'm glad it seems he was able to roll with it and go on being his awesome self, but there's a solid cautionary tale here: assume someone with power over you is going to find and take offense to your snark and it will hinder your forward momentum.

... that's the phrasing for sociopaths. For everyone else, you can summarize it as "Don't be an asshole."

<comment><USER19> I have made some similar career limiting moves in the past, and I regret none of them. The single thing I am most grateful for is being privileged to be in a situation where I don't have to dial down the snark to survive. I've known people for whom it would have been a "roof over your head" limiting move, and that sucks.

I do try to keep the snark to a minimum on hn though, because I firmly believe that I should only be an asshole to someone if I'm also granting them the opportunity to punch me in the face.

My apologies for the few times I've not done so.

</comment></comment></comment></comment><comment><USER15> As long as we're linking to other pieces he wrote, "The History of T" is fascinating. (Mostly not funny.)

[http://www.paulgraham.com/thist.html](http://www.paulgraham.com/thist.html)

<comment><USER17> He also wrote a chapter in the unix haters handbook.

</comment></comment><comment><USER20> More by Olin Shivers, and others:

[https://www.ccs.neu.edu/home/shivers/autoweapons.html](https://www.ccs.neu.edu/home/shivers/autoweapons.html)

</comment><comment><USER21> Is this the same Olin Shivers as [0]?

[0] [https://www.findagrave.com/memorial/95333577/olin- shivers](https://www.findagrave.com/memorial/95333577/olin-shivers)

<comment><USER17> No - I believe he's at Northeastern University. It's humor - don't take it as anything but that.</comment></comment>


Is it Time for You to Earn or to Learn? - <AUTHOR> http://www.bothsidesofthetable.com/2009/11/04/is-it-time-for-you-to-earn-or-to-learn/ <comment><USER2> Excellent article, shame it's not getting more upvotes.

<comment><USER3> I went and read it because you're one of my favorite posters/commenters, and really enjoyed it and learned - so thank you.

The title _is_ underwhelming though. The piece is a lot better than the title - author does realistic math on the range stock options are likely to be worth, then discusses whether it makes sense to jump into a risky venture with a chance of a big win, and talks about what to look for in more stable learning gigs if you're not going for a big win. Then he tells some stories, and he also mentions some nice specific points to think about ("accelerated vesting on change of control" - that one seems very important to me after reading this).

So yeah, very good piece, underwhelming title, but it's definitely worth a read.

</comment></comment><comment><AUTHOR> There is so much career crap that comes through the internet, and this is the most practical piece I've read in a long time. So many decisions can be concluded by simply asking the question of the post title.

The best one to make, I assume, is if you can both earn and learn.

</comment><comment><USER4> Earning can give you a different perspective that improves your knowledge on what to learn.

</comment><comment><USER5> > If you really want to earn you need to be in the top 3-4 in the company. > Best to be a founder.

The most important line of the article. If you're not on the conference calls and meetings that involve money, you're a sucker. They are hiding things from you.

Work a 9-5 and "learn" on your own time - or better yet, learn as part of the job where you're paid what you're actually worth. Many developers need to learn how to grow a spine and not work to make other (startup) people rich.

Likewise, if you work a 9-5 and don't have time to "learn", you're a sucker. What the _HELL_ (!!!) are you doing working your ass off for a megacorp? This is something of a false dichotomy.

<comment><USER6> > If you're not on the conference calls and meetings that involve money, > you're a sucker.

The article's point is that if you want to make enough money to retire, you're not going to do that with << 1% equity vesting over four years. That does not mean you're a "sucker"; you just need to be taking a job like that for the right reasons.

> learn as part of the job where you're paid what you're actually worth

For many of the jobs in question, we're talking about significantly more than $100,000 annual salary, plus stock options and benefits. For most people, that's not exactly being screwed.</comment></comment>


The browsers are probably running the TLS show now - <AUTHOR> https://utcc.utoronto.ca/~cks/space/blog/web/BrowsersRunningTLSNow <comment><USER2> Rather than browsers arbitrarily only trusting certain lengths of certs, of much greater concern to me is the number of root CAs trusted by every major browser, some of which are companies under the control of authoritarian states (Turkey, China).

Go take a look at how many CAs your browser trusts, and tell me with a straight face that you absolutely trust every one of those CAs to always do the right thing.

Certificate issuance transparency helps, but doesn't get rid of the fundamental issue.

<comment><USER3> On the one hand we argue the Internet should be global and not get Balkanized and on the other hand we arbitrarily select certain countries to place lesser or higher trust in. Someone in China could legitimately have a similar low level of trust for US root certs and he/she would not be far wrong given that NSLs can gag companies into complying with arbitrary dictums that no one ever knows about.

<comment><USER4> The original hacker dream of the internet was that it would break down borders and open up the free flow of information. Now that non-hacker types (politicians and bureaucrats, mainly) have had access for a few decades, they've realized how powerful a tool it is for empowering their authoritarian impulses.

Call me cynical but I think it's only a matter of time before the internet becomes totally Balkanized. Heck, it's almost there right now.

<comment><USER5> we have ports for everything else, internet ports will come. it'll suck for me.

</comment></comment></comment></comment><comment><USER6> Thank Christ. The browsers have been far, far better stewards of the Web PKI than the CA/B Forum (at large) has been, and, in the main, the Web PKI exists to support browser security. That the major browser vendors are getting more muscular about their demands is a major shift: antitrust was a real concern that prevented a lot of important Web PKI stuff from happening sooner. But with Google and Mozilla breaking the largest CAs over documented misissuance, it's possible that concern has finally gone by the wayside.

</comment><comment><USER7> I feel like this is a fairly narrow view of the situation. In theory the CA "System" ought to be much bigger than just web traffic since a globally distributed hierarchical database of certs is neat and could be used for all sorts of stuff.

The fact that browsers have so much say in how the CAs operate that database makes me think that the public CA system is actually a wildly successful failure. If the public CA system has no other use than to allow someone to securely connect to one of a handful of web browsers then why all the fanfare over just having letting the companies stewarding the browsers run the show entirely?

<comment><USER6> People say this a lot. But where are the examples of all the "stuff" that would benefit by being linked into a single global PKI? Many of the most important public key crypto tools people actually use --- Signal, SSH and SSH CAs, U2F and WebAuthn, OAuth2 --- have little or no PKI at all.

<comment><USER8> > But where are the examples of all the "stuff" that would benefit by being > linked into a single global PKI?

Estonia's national system and its e-services are a local example of a single central PKI. Provided services and systems seem to be far ahead of basically all other countries.

Identity theft, identification, authentication, signing etc. have been solved for nearly two decades now and I have to say the way the rest of the world does stuff looks stone-age to me.

For example I __loathe __how I 've been asked to do identity verification by foreign companies "send us a picture of your ID", WTF. Sentences like "Use SMS 2FA to protect your account", "e-mail us the bill" and "come to our office to sign {x}" make me shudder, it's absolutely dogs __*.

<comment><USER9> The anti-PKI crowd are getting waayyyyy ahead of themselves. Pretty much any large deployment of public-key cryptographic needs some sort of PKI. Any framework where there's a third-party authority that signs keys requires some sort of PKI, directly, indirectly, or both. And there's almost always such a third-party because otherwise public-key cryptography is barely just a step ahead of shared secrets. This is especially true when you have distinct vendors, but I can guarantee you that even Signal has an internal PKI framework, independent of the Android PKI framework that it also implicitly relies upon.

Someone else thread mentioned S/MIME. S/MIME might be a failure, but S/MIME is a thin wrapper around CMS (Content Messaging Syntax), which is widely deployed standard for signing, authenticating, and encrypting content. It's based on the same ASN.1 standards as PKIX. And like PKIX, the root authorities are whatever you want them to be; the standards just provide the syntax and semantics for building the PKI and providing interoperable messaging.

Correct me if I'm wrong, but AFAIU CMS is the basis for various European digital identity systems. See, e.g., [https://en.wikipedia.org/wiki/CAdES_(computing)](https://en.wikipedia.org/wiki/CAdES_\(computing\))

<comment><USER6> You tried the same rhetorical sleight of hand in a different thread a week ago; what you're doing is claiming that any use of asymmetric cryptography is by definition a form of PKI, when what we're talking about --- top-down tree- structured global PKI --- is clearly different from what they're doing.

Your point about S/MIME and CMS kind of makes my overall point for me. Sure. A global PKI is super useful for making things like CMS happen.

<comment><USER9> _You 're_ talking about _global_ PKI. But the "public" in PKI doesn't imply global any more than the public in public-key cryptography does.

What PKI does usually imply is some sort of top-down tree of trust and mechanisms and policy for managing and verifying that tree. But the roots of that tree of trust don't have to be global, and with the exception of Web PKI aren't.

You're creating the straw man. You keep saying that new protocols don't need PKI. Well, if we accept your criteria for what PKI means, and considering that the only example that meets your criteria, past, present, or future, is Web PKI, then what exactly is the point of your argument?

If you have a beef against PKIX, CMS, X.509, ASN.1 etc--i.e. the _mechanisms_ \--then just say so. There's a ton of reasonable criticism to be made there. But those things are not equivalent to "PKI". There are plenty of PKI systems out there that make use of alternative mechanisms, though mostly proprietary and hidden as interoperability usually demands making use of pre-existing standards. But, to reiterate, using those standards to build a PKI system absolutely does not require relying on the same global roots of trusts. Nothing in those standards even identifies such a root or the shape of the tree at all.

<comment><USER6> No. _We 're_ talking talking about global PKI. See: rest of thread. You're the one who's departed from the topic.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Why is this an improvement? Has there been a rash of stolen certificates or domain name ownership changes? Is having a third party with a cert for a domain you're using for 12 months acceptable in a way that 2 years isn't?

It would be nicer if certs could be issued with long lives but required a stapled revalidation with a short time span (daily? weekly?), which would be automatically issued at any time requested unless the certificate was revoked.

<comment><USER11> How does that help vs simply having short lived certificates?

<comment><USER10> (re-)Validation costs. In theory, if it was just a "not revoked" signature, anyone could obtain it. No access to thorny private keys needed, etc.

</comment></comment></comment><comment><USER12> This is an unexpected (from someone outside the cert industry) development. I know for sure it will have some impact on servers I manage, since we typically purchase 2 year certs, and issue 5 year certs internally.

It's also been shown recently that not all companies are great at managing their certs, with notable shutdowns associated with expired certificates. Increasing the frequency of updating certs should be a good thing, but in practice I'm afraid that it will remain a manual project for some time to come.

<comment><USER8> I don't think it's unexpected. Browsers are _the_ lifeblood of CAs.

Unless CAs insert themselves more into the process of code signing, S/MIME, GPG or something like that. They will remain under the heavy influence of browsers.

<comment><USER12> The move to 1 year is what was unexpected to me. Browsers taking over the rules around CAs, I agree that it's a natural expansion.

<comment><USER8> Browsers did the same thing with Certificate Transparency earlier, unnoticed to many.

<comment><USER13> And this is like that in an important way, for now.

Chrome and Safari both have browsers which implement a check such that you need to present enough "qualified" SCTs or the certificate is treated as invalid.

The easiest way to pass that check (for certificates you're going to sell or give to webmasters with no clue) is to log a pre-certificate with Google, and with at least one (preferably two) other logs that Apple and Google agree are trustworthy - then bake the SCTs you get back from those logs into the X.509 certificate you're issuing.

But these are not Trust Store policy requirements. If you in fact choose to issue (for a number of reasons some CAs do) without logging that's still permitted, the certificates just won't be trusted in Chrome or Safari. You obviously won't get far selling certificates that don't work out of the box in Chrome or Safari to the average punter, but not every customer is the average punter.

Apple's _declared_ intention is that Safari will not trust long-lived certificates. But as far as I've seen it is _not_ specified that they would consider a CA which chooses to issue such certificates to violate Apple trust store policy and pursue any sanction or demand revocation. The certificate just doesn't work in Safari.

Now, today Mozilla's Firefox is in a different situation from Safari and Chrome as I mentioned elsewhere. Firefox doesn't do a lot of technical enforcement. Mozilla works hard (and in public where we can all see) on policy decisions, but most of them are not enforced in its flagship browser product. Mozilla champions CT logging for example, but a brand new certificate presented with no SCTs works fine in Firefox even though it'd be rejected by Safari and Chrome. Today Firefox doesn't require 825 day lifetime limits, even though those are the limits set in policy, and so following Apple's suggestion wouldn't actually be easy for them, there isn't a line of code (as there is in Chrome for example) that multiples 825 * 86400 = maximum lifetime in seconds, which can be adjusted to say 398 or some other number of days instead of 825.

</comment></comment></comment></comment></comment><comment><USER14> And the browsers, in turn, are controlled by a few big tech companies. Is it a good idea to give those companies control over the trust architecture of the internet? What happens if you get on tech's persona non grata list? Do you not get to use the PKI?

<comment><USER13> You'd need to ask Microsoft about that, theirs is (as far as I know) the only Trust Store which demands they get unilateral override for revocation decisions.

That is, if Mozilla, or Apple, or Google reach out to Let's Encrypt and say "killtrump.example is not acceptable, revoke their certificate" Let's Encrypt says "No" and nothing happens. But if Microsoft does so, Let's Encrypt can say "Please reconsider this seems like a bad idea" and then Microsoft can say "We've thought about it, revoke" and the choice is only whether Let's Encrypt wants to remain trusted in Microsoft's products.

Nobody else has a rule like that, and it isn't a new rule, it's a published part of Microsoft's policy. Microsoft says they use it only to protect Microsoft's customers from phishing and similar attacks. Perhaps that's even true.

</comment></comment><comment><USER15> It is difficult to find a group of companies less trusted to do the right thing than the major browsers (Apple, Google, Microsoft). However, the CAs qualifies, ironically perhaps, as less trusted.

</comment><comment><USER16> At no point have the browsers ever _not_ been running the whole TLS show. The CAB forum is a useful construct, but its usefulness has a specific place.

Imagine a weird little town with 6 people who buy all the groceries and a 60 grocery stores. The stores get together periodically and meet with the 6 shoppers to talk about what the stores should stock. Maybe they even vote.

That be a useful set of meetings.

But ultimately those 6 customers are going to buy whatever the hell they want to buy, regardless of how the votes went.

</comment><comment><USER17> Does certificate length really matter? It seems like other factors related to certificates are much more important than the ability for a cert to be stolen, reused, and not revoked.

<comment><USER18> Cert revocation for the web is broken, which is why there's been so much emphasis on lifetime. Revocation checks are a privacy leak and reliability degradation and DoS vector, unless you use something like OCSP stapling, which fairly few sites do.

<comment><USER19> Mozilla is starting to do CRLite, which should be an improvement here:

[https://blog.mozilla.org/security/2020/01/09/crlite- part-1-a...](https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all- web-pki-revocations-compressed/)</comment></comment></comment>


Facebook will 'completely deprioritize publishers' - <AUTHOR> https://digiday.com/media/facebook-encouraged-us-not-pivot-video-confessions-audience-development-head/?utm_campaign=digidaydis&utm_source=twitter&utm_medium=social <comment><AUTHOR> Warning 1: Anonymous interview

Warning 2: I'm not entirely happy with the title but decided to take a subset of the real article title rather than attempt to editorialise. If dang or his team can think of a better one, I'd encourage them to edit it.</comment>