Hacker Newsnew | comments | show | ask | jobs | submit | shurcooL's comments login

I just did this (from [1]):

    sudo chown -R $(whoami):admin /usr/local
And not `sudo chown $(whoami):admin /usr/local`. Are both really necessary?

[1]: https://news.ycombinator.com/item?id=10307800

The -R was a bit overkill - what's inside /usr/local should already have had the correct owner - the problem is the owner of /usr/local itself.

The upgrade changes the permissions of all files within /usr/local to root:wheel.

Didn't for me, only /usr/local itself.

I'd say the "-R" might actually be harmful; for example the mysql GPL distribution binaries from dev.mysql.com installs in /usr/local/mysql and you definitively don't want to mess with the database file permissions there.

It might not be "best practice" to let non-homebrew stuff put things in /usr/local, but it happens.

No, only command with `-R` is necessary.

It is indeed a typo, sorry about that!

I've fixed it [1] after confirming [2] (yet again just now; I've ran those numbers many many times so I'm very confident it's not a one time fluke).

Thanks for catching it. You're also welcome to try to confirm the results yourself, they should be reproducible!

[1] https://github.com/gopherjs/gopherjs.github.io/commit/acea7a...

[2] https://gist.github.com/shurcooL/02183a57c51b28eaadf4

Hah, I should've checked (10 hours earlier) if someone would post it here.

I'm glad I'm not the only one who feels this way.

I feel like I gain more than I lose by simply excluding regexps from my toolbelt. (It's a personal choice, I'm not saying it'd be the same for others, since their values may differ from mine.)

Just to clarify, none of the support/money will go to websites that simply don't have ads, right?

If you don't like GOPATH workspace and use a separate GOPATH for each project, you should just use gb [1] which was designed and built with that use case as a goal.

Build tool and language are somewhat separate concepts.

[1] https://getgb.io


gb is promising, but doesn't feel like the complete solution quite yet.

The author only hesitantly added support for managing dependencies, which is done through a separate "plugin", gb-vendor. It maintains an internal manifest file which only the gb-vendor tool is supposed to manage. It's not like NPM or Ruby's Bundler where you the manifest file (package.json, Gemfile) is what you edit to produce the vendor tree. Support for branches and tags seems to missing, as does any notion of versioning, so of course semver is not on the table.

I understand the Unix philosophy of keeping dependency management and building separate tools, but I suspect that what most Go developers want is a fully integrated solution. I know I do.


The new layout looks great!

But there's an immediately obvious bug, the middle pane keeps resizing to become wider every time you switch between repos.

Also, one large repo I had simply shows 0 commits. It worked just fine before. And another even larger repo works fine.


An update, I tried to remove the problematic git repo and re-added it, and now history shows up okay.


> - Do I have uncommitted changes on any of my repos?

I wanted to know that too, so I made https://github.com/shurcooL/gostatus for my Go repos.


Agree with the first 3 paragraphs so much, well put.


I agree that open salaries are really really nice.

I am only aware of Balanced Payments that used to have it, but unfortunately they've recently shut down.

Chad Whitacre of Gratipay may know if any other companies do this by now.



Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact