Homebrew 1.4.0(brew.sh)
brew.sh
Homebrew 1.4.0
https://brew.sh/2017/12/11/homebrew-1.4.0/
218 comments
If you look into the OS version analytics, there are 397 events registered from "macOS (10.14)".
That's the next version of macOS :)
https://brew.sh/analytics/os-version/
https://brew.sh/analytics/os-version/
Perhaps someone deliberately messing with their version string, e.g. testing the software to make sure it handles "unknown" or "future" release cases properly?
nice catch!
My immediate thought is that this is spoofed. I doubt anyone at Apple would be silly enough to allow software on an unannounced OS to freely send out analytic data. I expect they'd have some sort of filtering applied either right on their dev/test machines (something like Little Snitch, though surely built in-house) or at the network level.
> I doubt anyone at Apple would be silly enough to allow software on an unannounced OS to freely send out analytic data
...and you'd be wrong. It is very common for Apple to test its new browser versions on the public internet and for those version numbers to show up in the logs of popular Apple web sites. It's one of the ways that Think Secret could confirm that a new version was on the way.
...and you'd be wrong. It is very common for Apple to test its new browser versions on the public internet and for those version numbers to show up in the logs of popular Apple web sites. It's one of the ways that Think Secret could confirm that a new version was on the way.
Besides, what does a version number reveal? “Oh, Apple is working on a new OS version!” You don’t say??
Certainly not much if anything at all, but it's mildly interesting to note that it identifies as 10.14 and not, say, 11.0.
Anyways there is surely something strange brewing for the next macOS, as Apple has repeatedly noted that "macOS High Sierra will be the last macOS release to support 32-bit apps without compromise", without specifying what kind of "compromise" might come up (see https://developer.apple.com/news/?id=06282017a )
Anyways there is surely something strange brewing for the next macOS, as Apple has repeatedly noted that "macOS High Sierra will be the last macOS release to support 32-bit apps without compromise", without specifying what kind of "compromise" might come up (see https://developer.apple.com/news/?id=06282017a )
I think you might be reading that wrong - should be "Without compromise, macOS will discontinue support for 32-bit apps". The only compromise should be not upgrading to 10.14 and staying on 10.13.
Maybe. It's an odd phrasing. Why not just say "will not run"? How do you run 32bit apps "WITH compromise"? In a VM window?
Think Secret? Wow, that takes me back.
I also doubt they’d ever release a security vulnerability where a user can enter a blank password to gain root access to macOS.
:-P
:-P
Why would they not allow internal software send out analytics data? At this point it is common knowledge that Apple is working on a new version of OS X that will come out next year.
It's incredibly weird since Apple employees are heavily discouraged from running Homebrew.
Why are they discouraged to run Homebrew?
You’ve never worked at a big company like Apple or Facebook have you ?
Welcome to open source software. The site I run has 70,000+ monthly unique visitors; It's used by all of the top tech companies, and brings in about $45 a month in ad revenue. I'm not complaining because the only financial costs are my domain hosting. I chalk up my personal time to an educational investment.
I'm sure Homebrew has a significantly higher value, but you've got to weigh the tradeoffs. If Homebrew cost $9.99 a year for access to updates I would pay it, but I know a lot of people would complain.
I'm sure Homebrew has a significantly higher value, but you've got to weigh the tradeoffs. If Homebrew cost $9.99 a year for access to updates I would pay it, but I know a lot of people would complain.
It's really sad. I always thought there are lots of companies, acting like WhatsApp ( $1,000,000 donation to FreeBSD [1] ) and return back value to open source, the same way they got value out of it.
I'm really surprised that instead of "lots" I have to write "some".
I also think that it's a much bigger win, financially and for P.R., to donate some of the profits, instead of paying the taxes in selected tax-paradise countries.
1: https://forums.freebsd.org/threads/49056/
I'm really surprised that instead of "lots" I have to write "some".
I also think that it's a much bigger win, financially and for P.R., to donate some of the profits, instead of paying the taxes in selected tax-paradise countries.
1: https://forums.freebsd.org/threads/49056/
Not at all, from my consulting experience many companies, specially the ones whose main business is not software related, hardly give anything back.
FOSS is seen by upper management as a way to avoid paying for software, instead of pirating it, and contributing code back is frowned upon.
FOSS is seen by upper management as a way to avoid paying for software, instead of pirating it, and contributing code back is frowned upon.
[deleted]
A lot of big companies, even in 2017, don't have a very good in-house process for buying software that isn't available on CDROM from a preferred distributor (CDW, etc...)
One place I worked, it was easier to order a new work van for the department than a $30 program because the program could only be downloaded, and not bought in a box.
One place I worked, it was easier to order a new work van for the department than a $30 program because the program could only be downloaded, and not bought in a box.
The reason is kickbacks. The CxO level gets either direct kickbacks (or, in holding company layouts, the mothership company) or by invitations to golf weekends.
So they try to keep people from buying from non-approved (i.e. no kickback agreement) vendors as much as possible, no matter if the company loses on the long term (worker happiness, productivity). Also, keeping records, both financial and stuff like license expiration is easier with one to a dozen suppliers than hundreds. The major enterprise vendors (eg MS, Adobe and Acronis) actually have dedicated enterprise license management solutions, which a tiny shop usually does not.
So they try to keep people from buying from non-approved (i.e. no kickback agreement) vendors as much as possible, no matter if the company loses on the long term (worker happiness, productivity). Also, keeping records, both financial and stuff like license expiration is easier with one to a dozen suppliers than hundreds. The major enterprise vendors (eg MS, Adobe and Acronis) actually have dedicated enterprise license management solutions, which a tiny shop usually does not.
So, how about repackage the app on cds?
I totally agree with you but at the same time - we can't tell people something is free and then get upset when they treat it as such.
We don't; unfortunately English is silly and uses the same word for "no-cost" as for "open".
While we implicitly give away the software for no cost, we don't really try to brand it as such (though for some, lack of cost is certainly a big plus).
It's a shame "open source" got co-opted by the OSI and the Free Software purists are left to continue to use "free". I doubt something like "libre" would catch on; some people use it, but it doesn't seem to be used widely enough.
While we implicitly give away the software for no cost, we don't really try to brand it as such (though for some, lack of cost is certainly a big plus).
It's a shame "open source" got co-opted by the OSI and the Free Software purists are left to continue to use "free". I doubt something like "libre" would catch on; some people use it, but it doesn't seem to be used widely enough.
We shouldn't tell them it is free, but rather that they can have higher confidence in it as they can examine or change it.
Which then gets us to the topic of GPL vs MIT & friends.... :-)
How do you know that these other companies aren’t contributing in other ways (code, testing, bug reports, etc.)?
If only the supermarket lady could take some pull requests as payment.
Because he’s a maintainer and sees it daily, as I do. The best that most companies “contribute” are poor bug reports served with entitled attitude and expectation that you’ll fix the issue they’re having. PRs? Nah, not even if you ask for them. There are exceptions but they are very rare.
[deleted]
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.
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.
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.
Tip jars and pay what you can are effective. Bs corporate red tape is the problem
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.
Give a company a proper bill with VAT, and they'll stuff you with money.
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?
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.
BS corporate red tape is a reality, though. So why not offer workarounds that help them give you money?
As mentioned above, offer consulting services and accept corporate purchase orders. Be able to give and receive PO numbers. This is the language the bean counters speak, and sprinkles magic pixie dust on your invoices, ensuring you get paid.
One really big downside to offering this yourself or providing it as a service: contracts. You can try avoid paying a lawyer and use a standard contract. The engineering manager would be cool with that since he just wants to support a project but all bets are off when it hits legal. A big enough company and you can get into a seemingly endless revision back-and-forth that can last weeks. No big deal for them and other big companies they work with since they have salaried lawyers on staff but the cost is something to consider for everyone else.
Hiring a lawyer is important if you are going to be contracting with a large enough company though. The money you save and the time you spend as a result of having a competent lawyer draft, negotiate, and proof your contracts pays for itself in the long run when, inevitably, something goes wrong on a project.
What makes it BS? Can you come up with a better way to manage giving access to a bank account with hundreds of millions of dollars to a thousand people?
If they don’t accomplish the goal (and they don’t), you can hardly call them “effective”.
Are they? Usually unless you're known, they bring in next to nothing.
Same thing. I could get a sign-off to order a licence worth $500 or a 20$/month subscription if it's needed, but a donation of 5$ would be absolutely impossible; not just hard, but legally unacceptable use of funds.
in germany you can just use an receipt for stuff under a certain amount. no need for a special invoice, etc. the receipt only needs the total amount, the date, effort or product name, vat percentage.
well of course for a donation you need a document that you actually correctly donated, etc..
This is the almighty power manifest of the purchase order in corporate finance.
Only true in a fairly narrow sense. At my company we use a ton of open source software. We have support contracts for a few of the big-ticket/core pieces, but I doubt anyone would even think to bother to pay for support for the vast majority of OSS we use.
The other option is being a 501c3/6 foundation whose purpose is to support the particular software project, and then companies will donate to said foundation.
Until reading this comment, I didn't know they had a patreon page. As far as I can tell, it's not linked from the front page of brew.sh. It is linked down at the bottom of the README on github though.
Anyway, that number would probably be higher if it were advertised more.
Anyway, that number would probably be higher if it were advertised more.
Not at all saying that this is happening here,
but this made me wonder: would there be fake Patreons accounts? How much verification is done?
but this made me wonder: would there be fake Patreons accounts? How much verification is done?
Patreon doesnt seem to do much checking of anything. There are patreon users getting money by copying the content of other patreon users and aggrigating it. So far patreon has done nothing. There are also patreon accounts just posting links to torrents and no movement from Patreon
Patreon attempts to charge new subscribers as soon as they sign up to give to a page, so if a charge bounces back the numbers dont go up. Existing members are removed as soon as their card declines the transaction.
I'm sorry if i wasn't clear. I meant from the creator's side. How do I know this account is actually from Homebrew.
Wasn't aware either. +1 supporter.
If there were Enterprise Homebrew that did nothing different but sent me an invoice every month, I could effortlessly expense it for $100s/month.
There's a Windows equivalent of Homebrew called Chocolatey and they actually have enterpise features available as a buy-up.
https://chocolatey.org/pricing
https://chocolatey.org/pricing
Also, interestingly, there are large companies that we know use our software heavily internally who flat out lie about using Homebrew in any form when we've asked for help with resources. It's a sad state of affairs that smaller companies and individuals are far more generous when it comes to supporting us.
If the Big Corps aren't going to play your game Please Donate!, you'll need to play theirs Invoice Required!. While there is a small amount of monthly overhead for generating invoices, landing just 1 paid subscription could make the effort worthwhile.
"Self-hosted homebrew" would probably be the magic word that unlocks the enterprise dollars.
Perhaps the people using it and the people responding to your requests are unaware of each other?
I think this is what you mean: https://news.ycombinator.com/item?id=9695102
Basically anyone who does any kind of work with code on a Mac is pretty likely to be using Homebrew for something or another.
Or MacPorts.
> I read somewhere ( and I bet ) it's used by Google / Facebook / Apple employees.
In fairness, it's used by virtually everyone who has to do anything of significance in software development on a Mac.
In fairness, it's used by virtually everyone who has to do anything of significance in software development on a Mac.
https://www.patreon.com/homebrew
It's $312 a month now, but that's still super now. We should at least get them to where they can afford a few beers with the monthly groceries.
It's $312 a month now, but that's still super now. We should at least get them to where they can afford a few beers with the monthly groceries.
[deleted]
Thank you for bringing this to my attention. I’m now a proud patron adding $1/mo. The number went up to $325 per month and I hope it keeps going up!
Thanks for this comment. I just added my little bit of support, as did a a couple dozen others.
Thanks for reminding us all of this. I just supported them.
Up to $304 already, good job guys!
Now 178.
The maintainer works for GitHub, I’m sure he is doing alright.
I'm the lead (but not only) maintainer and: yeh, I do alright. I've never made or taken a dime from Homebrew directly (indirectly includes it helping me get my last two jobs). There's a bunch of annoying stuff like AWS and Heroku that we can't really afford to use right now (I refuse to pay for Homebrew stuff from my own pocket) and it would be great to have more CI machines. These are the sort of things a Patreon pays for.
> 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.
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.
> 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".
The commenting user in this case immediately opened another issue where they were rude to another maintainer too, had to be warned about their behaviour and (unlike most people who are warned) did not apologise. This issue was not locked.
My work on Homebrew over the last 9 years has been almost entirely in my free time. That's time I'm not spending with my wife, friends, dog or (now) new baby. As my Twitter and GitHub bios point out: "I block rude people". I'm not interested in giving my free time to people who cannot be polite.
The GitHub UI indicates whether someone is a first-time contributor, contributor or maintainer. You get cut proportionally more slack for having a bad day and being rude if you've contributed to Homebrew already. I try to be over-the-top positive for new contributors and I will immediately and genuinely gratefully accept apologies that are given.
> MikeMcQuaid, if you ever read this, this sort of behavior on your part is a great argument for ditching HomeBrew.
If you'd like to ditch Homebrew: please go ahead. There's things that MacPorts do better than we do and the MacPorts maintainers I know are good people. If you use Homebrew: you are the one who benefits, we do not. I want to build something that's useful but primarily maintaining Homebrew needs to be an enjoyable experience for me and others for it to be a sustainable project.
The commenting user in this case immediately opened another issue where they were rude to another maintainer too, had to be warned about their behaviour and (unlike most people who are warned) did not apologise. This issue was not locked.
My work on Homebrew over the last 9 years has been almost entirely in my free time. That's time I'm not spending with my wife, friends, dog or (now) new baby. As my Twitter and GitHub bios point out: "I block rude people". I'm not interested in giving my free time to people who cannot be polite.
The GitHub UI indicates whether someone is a first-time contributor, contributor or maintainer. You get cut proportionally more slack for having a bad day and being rude if you've contributed to Homebrew already. I try to be over-the-top positive for new contributors and I will immediately and genuinely gratefully accept apologies that are given.
> MikeMcQuaid, if you ever read this, this sort of behavior on your part is a great argument for ditching HomeBrew.
If you'd like to ditch Homebrew: please go ahead. There's things that MacPorts do better than we do and the MacPorts maintainers I know are good people. If you use Homebrew: you are the one who benefits, we do not. I want to build something that's useful but primarily maintaining Homebrew needs to be an enjoyable experience for me and others for it to be a sustainable project.
I just read zenspider's other issue. It's not rude. You and the other maintainer are.
If I was on the fence before, I'm not now. Time to ditch Homebrew and stop recommending it to friends. You are poor stewards of the project and of your community.
If I was on the fence before, I'm not now. Time to ditch Homebrew and stop recommending it to friends. You are poor stewards of the project and of your community.
I'm the guy who originally made Homebrew independent of the CLT (GSoC 2015).
macOS is a constantly moving target, and it's hard enough to get consistent behavior across multiple versions with the CLT installed. It's a losing battle that I've been fighting for the last 3 years, and it's one with diminishing returns (only a minority of Homebrew users don't want/need the CLT for other purposes anyways).
Edit: As for PR, we get a lot of issues and PRs that amount to handling a 1% case at the cost of the 99% case. When we get those, we have to consider both to time cost to ourselves and the future maintenance cost. We could probably be a little less brusque about it, but the reality is that we don't have the kind of labor or resources necessary to support maintenance-heavy features like CLT-free installs on older macOS versions.
macOS is a constantly moving target, and it's hard enough to get consistent behavior across multiple versions with the CLT installed. It's a losing battle that I've been fighting for the last 3 years, and it's one with diminishing returns (only a minority of Homebrew users don't want/need the CLT for other purposes anyways).
Edit: As for PR, we get a lot of issues and PRs that amount to handling a 1% case at the cost of the 99% case. When we get those, we have to consider both to time cost to ourselves and the future maintenance cost. We could probably be a little less brusque about it, but the reality is that we don't have the kind of labor or resources necessary to support maintenance-heavy features like CLT-free installs on older macOS versions.
Why is it necessary for people to be polite in the face of rudeness? Especially when the person expected to be polite is volunteering their time for you?
To enlighten the polite people who have not insulted Homebrew maintainers: the issue with requiring the CLT on everything but the latest version of macOS is because of the horrible workarounds. Grep the Homebrew taps for "Xcode-only", "CLT.installed?", or "clock_gettime" for an idea of the amount of hacks required. I don't know precisely why this occurs but it's related to Apple only shipping the latest SDK in Xcode rather than one that matches the version of macOS that Xcode is running on.
To enlighten the polite people who have not insulted Homebrew maintainers: the issue with requiring the CLT on everything but the latest version of macOS is because of the horrible workarounds. Grep the Homebrew taps for "Xcode-only", "CLT.installed?", or "clock_gettime" for an idea of the amount of hacks required. I don't know precisely why this occurs but it's related to Apple only shipping the latest SDK in Xcode rather than one that matches the version of macOS that Xcode is running on.
Possible slightly off-topic, but I discovered a screw up where due to a typo they had reverted back to an ancient version. My wording was deemed rude and I was shut out and not even given a chance to apologize or explain. That pretty much guaranteed my future non-contribution to the project.
EDIT: reworded
EDIT: reworded
Saying "the error message is terrible" isn't particularly rude to begin with. And if you're having a one-on-one conversation with someone, saying "I think you're rude so I'm not going to answer your question" is one thing, but in a public forum, saying "You raise a valid question but I don't like how you phrased something so I'm going to explicitly refuse to answer the question, then lock the PR so nobody else can ask the question either, and screw anybody who actually wants to know the answer" is unacceptable. It's really user-hostile and makes me not want to use anything that maintainer is responsible for.
It's not much of an argument to say "well, it's not really that rude". Is it generous and gracious to communicate with people despite their rudeness? Sure. But should it an obligation, particularly for an open-source maintainer? Absolutely not.
Nor do I buy the "public forum" argument. You direct your writing to the audience you have (i.e., the person that asked you a question rudely), not an imagined audience that might be reading. "Lock the PR so nobody else can ask the question either, and screw anybody who actually wants to know the answer" is projecting; there's nothing about locking an issue that shuts down all conversations, just the one in the issue that is being discussed (that again, to emphasize, is a rude conversation anyway).
Nor do I buy the "public forum" argument. You direct your writing to the audience you have (i.e., the person that asked you a question rudely), not an imagined audience that might be reading. "Lock the PR so nobody else can ask the question either, and screw anybody who actually wants to know the answer" is projecting; there's nothing about locking an issue that shuts down all conversations, just the one in the issue that is being discussed (that again, to emphasize, is a rude conversation anyway).
Saying the error message was terrible is barely rude at all. The only real problem with it is it's non-specific. And the poster edited their message to change the wording immediately anyway, the maintainer was only annoyed because GitHub emailed him the original contents of the comment.
So the maintainer took an extremely minor just-barely-qualifies-as-a slight and decided to react about as bad as you possibly can. It's awful.
And I'm not projecting either. zenspider had a legitimate complaint and a real question, both of which I care about. The complaint still hasn't been addressed, and the only way I was able to get an answer to the question was to ask here on HN. But that answer isn't visible to anyone else who looks at that PR (i.e. anyone who sees the changelog entry and wants to know why the CLT are now required), which I guarantee you is a nonzero number of people.
So the maintainer took an extremely minor just-barely-qualifies-as-a slight and decided to react about as bad as you possibly can. It's awful.
And I'm not projecting either. zenspider had a legitimate complaint and a real question, both of which I care about. The complaint still hasn't been addressed, and the only way I was able to get an answer to the question was to ask here on HN. But that answer isn't visible to anyone else who looks at that PR (i.e. anyone who sees the changelog entry and wants to know why the CLT are now required), which I guarantee you is a nonzero number of people.
In my experience, low tolerance for negativity is a form of burn out dealing with people.
Even the thimble of energy required to ignore a comment is yet another thimble of energy taken from the pool when all you're doing is helping somebody.
The hard line approach might seem silly in isolation, but I don't think it's unreasonable. The slow creep of community negativity has burned me out on one of my own projects, a forum I run.
One perk of zero tolerance is that it spares you energy for more important decisions. People are quick to point out that it comes at the expense of alienating some folks, but nobody ever seems to care about discouraging the people actually doing the work.
Even the thimble of energy required to ignore a comment is yet another thimble of energy taken from the pool when all you're doing is helping somebody.
The hard line approach might seem silly in isolation, but I don't think it's unreasonable. The slow creep of community negativity has burned me out on one of my own projects, a forum I run.
One perk of zero tolerance is that it spares you energy for more important decisions. People are quick to point out that it comes at the expense of alienating some folks, but nobody ever seems to care about discouraging the people actually doing the work.
Homebrew is an awesome, super useful piece of software that people put in tonnes of effort to maintain, for free. Your complaint was indeed worded rudely. Also, re: the “why” behind this commit, “to avoid copious workarounds in formulae” is already a pretty good description, I can see why he didn’t feel the need to elaborate.
Remember that maintainers of projects like Homebrew have to deal with an endless stream of complaints and feature requests, and don’t get paid to do so. If this commit is a big deal for you, just make the effort to bring it up in a nice, thoughtful way. Or, don’t use the software if you don’t like it/the maintainers.
Remember that maintainers of projects like Homebrew have to deal with an endless stream of complaints and feature requests, and don’t get paid to do so. If this commit is a big deal for you, just make the effort to bring it up in a nice, thoughtful way. Or, don’t use the software if you don’t like it/the maintainers.
It wasn't my complaint.
And no, that's not a good description, because it gives me literally zero information to go on in order to find out what the workarounds were, how many formula actually needed them, and what the problems were that necessitated this.
> Remember that maintainers of projects like Homebrew have to deal with an endless stream of complaints and feature requests
Yeah, that's what happens with popular open source projects. Good projects are able to handle this in a way that doesn't alienate the community or future contributors. The fact that MikeMcQuaid is doing this for free does not remove the obligations he has to the community.
And no, that's not a good description, because it gives me literally zero information to go on in order to find out what the workarounds were, how many formula actually needed them, and what the problems were that necessitated this.
> Remember that maintainers of projects like Homebrew have to deal with an endless stream of complaints and feature requests
Yeah, that's what happens with popular open source projects. Good projects are able to handle this in a way that doesn't alienate the community or future contributors. The fact that MikeMcQuaid is doing this for free does not remove the obligations he has to the community.
> And no, that's not a good description, because it gives me literally zero information to go on in order to find out what the workarounds were, how many formula actually needed them, and what the problems were that necessitated this.
Why do you feel that you're entitled to this information? And/or that providing this information is a good use of the maintainer's unpaid volunteer time (and that it's immediately obvious to the maintainer that it would be)?
> Good projects are able to handle this in a way that doesn't alienate the community or future contributors.
Homebrew is one such project. Empirically, they have an active community and sufficient contributions to keep the project robust and growing. That doesn't mean that they're going to be perfectly nice and polite to everyone, bending over backward to every user's whim. Sometimes someone is going to feel off-put as you have. But, clearly, most of the time people have positive experiences, so I'm sure they're satisfied with their performance.
> ... doing this for free does not remove the obligations he has to the community.
The only obligations I expect from an OSS maintainer is that they won't be negligent or malicious -- that is, they will work hard to avoid catastrophic bugs that destroy data or open security holes. Even given that, I accept that those sorts of things may happen due to innocent mistakes. Beyond that, I pay nothing, so I expect nothing.
This sort of thing reminds me of really the only negative I've experienced as an open source maintainer: users with feelings of entitlement.
Why do you feel that you're entitled to this information? And/or that providing this information is a good use of the maintainer's unpaid volunteer time (and that it's immediately obvious to the maintainer that it would be)?
> Good projects are able to handle this in a way that doesn't alienate the community or future contributors.
Homebrew is one such project. Empirically, they have an active community and sufficient contributions to keep the project robust and growing. That doesn't mean that they're going to be perfectly nice and polite to everyone, bending over backward to every user's whim. Sometimes someone is going to feel off-put as you have. But, clearly, most of the time people have positive experiences, so I'm sure they're satisfied with their performance.
> ... doing this for free does not remove the obligations he has to the community.
The only obligations I expect from an OSS maintainer is that they won't be negligent or malicious -- that is, they will work hard to avoid catastrophic bugs that destroy data or open security holes. Even given that, I accept that those sorts of things may happen due to innocent mistakes. Beyond that, I pay nothing, so I expect nothing.
This sort of thing reminds me of really the only negative I've experienced as an open source maintainer: users with feelings of entitlement.
If you don’t want to engage with the community, then don’t. But if you do it behooves you to behave in a manner that respects your users and the community. Doing otherwise is how you lose that community. It’s not “entitlement” to expect the Homebrew maintainers to be good stewards of the project and the community.
Sure it is. It's entitlement to expect literally anything for free. You and I, personally, have not done anything to deserve Homebrew, and yet we have it (well, ok, you do; I haven't run macOS in a few years, so I haven't had need of it). It's a net good, and we, personally, did not have to do anything for it to come into being. I'm not saying you should revere and prostrate yourselves before the people who gave it to you, but you should also not expect any more from them.
You should also give them the benefit of the doubt and cut them a bit of slack when they don't behave exactly as you'd think that you would. (I say "think" because it's all well and good to take the moral high ground in theory, but unless you're actually in that person's shoes, it's hard to speak in absolutes.) I've said this elsewhere, but: perhaps you hit the edges of a long drawn-out discussion that took place out of your sight, a discussion that was tiring and draining, and he just didn't feel like rehashing for you. Or maybe he simply just got out of an argument with a friend or family member, or just had a bad day.
That may not excuse his behavior in polite society, but it makes it understandable. You had a one-off bad interaction with someone. Boo hoo. It happens. Give people the benefit of the doubt, and, unless you have very strong evidence to the contrary, assume your experience was an unfortunate outlier. Homebrew is obviously a successful, robust project, with lots of contributors, so maybe, just maybe, your negative experience isn't typical, and perhaps most people who he interacts with actually come away with a positive impression. We can't all always have our best faces on, 100% of the time. Generalizing your single interaction as the norm is arrogant, ignorant, and selfish. Apply the principle of charity, and move on. If a person/community is truly toxic, then that needs to be addressed, but you seem to be assuming that your single bad experience is the norm, without taking the time to actually do any research... and feel the need to repeatedly trash-talk here for some reason.
If you met this guy in person and said "hey, I had a bad experience interacting with you online", and he didn't talk it out and apologize, then that would speak poorly for his character. But you have one tiny insignificant data point to go on, and I think it's incredibly disheartening that you've chosen to take that as representative to such a vehement degree.
You should also give them the benefit of the doubt and cut them a bit of slack when they don't behave exactly as you'd think that you would. (I say "think" because it's all well and good to take the moral high ground in theory, but unless you're actually in that person's shoes, it's hard to speak in absolutes.) I've said this elsewhere, but: perhaps you hit the edges of a long drawn-out discussion that took place out of your sight, a discussion that was tiring and draining, and he just didn't feel like rehashing for you. Or maybe he simply just got out of an argument with a friend or family member, or just had a bad day.
That may not excuse his behavior in polite society, but it makes it understandable. You had a one-off bad interaction with someone. Boo hoo. It happens. Give people the benefit of the doubt, and, unless you have very strong evidence to the contrary, assume your experience was an unfortunate outlier. Homebrew is obviously a successful, robust project, with lots of contributors, so maybe, just maybe, your negative experience isn't typical, and perhaps most people who he interacts with actually come away with a positive impression. We can't all always have our best faces on, 100% of the time. Generalizing your single interaction as the norm is arrogant, ignorant, and selfish. Apply the principle of charity, and move on. If a person/community is truly toxic, then that needs to be addressed, but you seem to be assuming that your single bad experience is the norm, without taking the time to actually do any research... and feel the need to repeatedly trash-talk here for some reason.
If you met this guy in person and said "hey, I had a bad experience interacting with you online", and he didn't talk it out and apologize, then that would speak poorly for his character. But you have one tiny insignificant data point to go on, and I think it's incredibly disheartening that you've chosen to take that as representative to such a vehement degree.
> the obligations he has to the community.
There isn't an obligation though. You could fork or pick an alternative as much as a maintainer/owner can abandon a project. They aren't obligated to do anything for you and you aren't obligated to do anything for them.
If you don't like a project because of personalities involved, avoid them. I have personally done this without problem. It can be a pain but I have no actual pull in the matter.
There isn't an obligation though. You could fork or pick an alternative as much as a maintainer/owner can abandon a project. They aren't obligated to do anything for you and you aren't obligated to do anything for them.
If you don't like a project because of personalities involved, avoid them. I have personally done this without problem. It can be a pain but I have no actual pull in the matter.
I checked out some of the closed issues/PRs, and yeah, seems like Mike McQuaid can be a little brusque at times, but I didn't see anything that made me think he was a "real jerk".
I'll say again that it's worth remembering that the maintainers are putting in a tonne of work, dealing with huge volumes of issues and PRs, and doing it all for free, while also working full time jobs and having lives outside of programming. It's necessary for them to write short/quick replies, and if people are being rude (as the one guy was in the PR comments), it's pretty reasonable for the maintainers to be dismissive. Also, I disagree strongly with this sentence:
"The fact that MikeMcQuaid is doing this for free does not remove the obligations he has to the community."
None of the maintainers have obligations to the community.
I'll say again that it's worth remembering that the maintainers are putting in a tonne of work, dealing with huge volumes of issues and PRs, and doing it all for free, while also working full time jobs and having lives outside of programming. It's necessary for them to write short/quick replies, and if people are being rude (as the one guy was in the PR comments), it's pretty reasonable for the maintainers to be dismissive. Also, I disagree strongly with this sentence:
"The fact that MikeMcQuaid is doing this for free does not remove the obligations he has to the community."
None of the maintainers have obligations to the community.
Good luck writing your own version and supporting it. Be sure to post your progress.
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.
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.
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.
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.
Why would I write my own version? If I ditch Homebrew I'd just go back to MacPorts.
I wish I could click this upvote triangle a million times.
Or you could, like, do it.
Things are easier these days with great CI tools, cloud stuff like CDNs, cheap storage and bandwidth, and FOSS sponsors.
Scratching your own itch is something that can be worth being done at times. After all that's how Homebrew started, when people grew discontent of the complexity of MacPorts and Fink. There were dismissing words towards Homebrew back then too (like "wait till they have to do X").
Things are easier these days with great CI tools, cloud stuff like CDNs, cheap storage and bandwidth, and FOSS sponsors.
Scratching your own itch is something that can be worth being done at times. After all that's how Homebrew started, when people grew discontent of the complexity of MacPorts and Fink. There were dismissing words towards Homebrew back then too (like "wait till they have to do X").
I had the same experience with MikeMcQuaid. I asked a question, he got offended, and then he locked the issue. I stopped participating in the community after this.
And now MikeMcQuaid has actually banned me (presumably from the whole organization) over this.
Mike, I don't know what you think you're doing, but you threatened to ban zenspider simply because they asked to have their issue reopened, and you actually banned me because I pointed out that your behavior was unacceptable. I'd go so far as to say you're actually violating your own Code of Conduct, and if you had any sense whatsoever, you'd immediately stop interacting with the community and appoint someone else to handle all tickets from here on out.
Mike, I don't know what you think you're doing, but you threatened to ban zenspider simply because they asked to have their issue reopened, and you actually banned me because I pointed out that your behavior was unacceptable. I'd go so far as to say you're actually violating your own Code of Conduct, and if you had any sense whatsoever, you'd immediately stop interacting with the community and appoint someone else to handle all tickets from here on out.
[deleted]
Well it is rude so...
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?
Homebrew checks the command line tools version by running "clang --version". It uses this one:
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?
Anyone else getting a warning about command line tools?
$ brew doctor
Warning: A newer Command Line Tools release is available.
Update them from Software Update in the App Store.
/Library/Devloper/CommandLineTools/usr/bin
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Homebrew checks the command line tools version by running "clang --version". It uses this one:
/Library/Devloper/CommandLineTools/usr/bin/clang
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?
I got the same warning, opened Appstore.app and found a pending update for the Command Line Tools that wasn't there earlier today.
Oh nice, just upgraded everything yesterday.
Side note: I find it a pity brew upgrade webcalls google analytics.
Side note: I find it a pity brew upgrade webcalls google analytics.
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.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.
There was an announcement[0] a couple of years ago that certainly provoked a lot of debate on HN[1].
[0] https://github.com/Homebrew/brew/blob/master/docs/Analytics.... [1] https://news.ycombinator.com/item?id=11566720
[0] https://github.com/Homebrew/brew/blob/master/docs/Analytics.... [1] https://news.ycombinator.com/item?id=11566720
IIRC, it's mentioned when you install brew
I never noticed it. A lot of text scrolls across the screen during the installation.
what do you want them to do?
Ask for permission - opt-in not opt-out.
The current behaviour isn't sufficient for the new GDPR requirements coming in May. Contributors and any relevant companies (or their subsidiaries) in the EU could be liable.
The current behaviour isn't sufficient for the new GDPR requirements coming in May. Contributors and any relevant companies (or their subsidiaries) in the EU could be liable.
GDPR covers personal data, not anonymous unidentifiable stats.
You are incorrect - this is personal data and does fall under the extremely wide scope of GDPR, which is simply "processing".
Under the current data protection laws, as long as it isn't personally identifying, it would fall out of scope. Under GDPR, it is in-scope, and explicit opt-in consent is required for both collection and for the things you want to use the data for.
Requiring opt-in to use the software is also not permissible.
GDPR is a bit of a beast.
Under the current data protection laws, as long as it isn't personally identifying, it would fall out of scope. Under GDPR, it is in-scope, and explicit opt-in consent is required for both collection and for the things you want to use the data for.
Requiring opt-in to use the software is also not permissible.
GDPR is a bit of a beast.
At first install, prompt the user to opt-in? Occasionally re-prompt a user, say, once per year to choose to opt-out if they’re opted in, just to check they’re still cool with it and haven’t forgotten and/or changed their mind on how comfortable they are with the practice? People’s opinions on that sort of thing don’t always remain static.
Opt-in is a decent enough method. But "Occasionally re-prompt a user" is a horrible idea, in my opinion. From a user perspective, that's kind of like the software forgetting the options you set. The very first time that something re-prompted me about something I had already opted-in to or out of, I would feel intense rage that it's asking me something that it had already asked me.
You would feel intense rage? Jesus. That sounds like intense overkill. You might be quite unlike an average person if you specifically--and without fail--recall every choice you've made forever when you're in the process of setting up tools.
No, it's not at all like the software forgetting the options you've set. It's the software, in the interest of providing a user with the greatest possible control over their software, while having the average user's propensity to forget minor details in mind, offering the explicit option to re-evaluate a prior choice in the future without having to remember to do so, or manually recall the way to do it.
Moreover, when I threw out the off-the-cuff idea to occasionally re-prompt, I set that occasion as an annual one. You're making it sound in this overreaction as if I suggested it to occur every few days or weeks. Instead of instantly going to such unwarranted extremes as full-on-intense-rage-mode-11, thinking to yourself, "Oh my fucking god, what the fuck is wrong with this developer that s/he'd dare to ask me this question I answered 2 years ago again?!", you might pause just a moment to consider it to be a little like recalibrating a tool that's been in use for some time. Few people keep static positions on things. Such recalibration doesn't need to occur at every minor upgrade, but perhaps major upgrades might want to ask the user to review their settings/choices.
I've changed my position on things I've opted in/out of at various times. When it's privacy-related, I've increasingly developed a harder default stance over the last 15 years. I wouldn't mind if my tools asked me to annually review old choices I've long forgotten--much like I've heard Facebook offers people their little privacy checkups (ignoring for the moment the efficacy of such a checkup when everything you do is tracked). Many people other than me reacted to the way in which the analytics "feature" was included in homebrew with surprise, because many of us never noticed the notification, and a great many of us believe tracking is something that should always be opt-in, not opt-out. However, as of this writing, I can't recall exactly what my current homebrew setting for analytics is, and I can't recall how long it's been since I last checked it to ensure it is what I think it is.
But hey, that's just me, friend. I can't remember every choice I made last month, much less last year, two years ago, or any time before that. If you do, that's cool. If you were using a tool I created/maintained, and I wanted to cover all my bases, I'd simply give you a way to say, "Don't ever fucking ask me this question again or I'll rage tweet what a forgetful little shit you are." :)
No, it's not at all like the software forgetting the options you've set. It's the software, in the interest of providing a user with the greatest possible control over their software, while having the average user's propensity to forget minor details in mind, offering the explicit option to re-evaluate a prior choice in the future without having to remember to do so, or manually recall the way to do it.
Moreover, when I threw out the off-the-cuff idea to occasionally re-prompt, I set that occasion as an annual one. You're making it sound in this overreaction as if I suggested it to occur every few days or weeks. Instead of instantly going to such unwarranted extremes as full-on-intense-rage-mode-11, thinking to yourself, "Oh my fucking god, what the fuck is wrong with this developer that s/he'd dare to ask me this question I answered 2 years ago again?!", you might pause just a moment to consider it to be a little like recalibrating a tool that's been in use for some time. Few people keep static positions on things. Such recalibration doesn't need to occur at every minor upgrade, but perhaps major upgrades might want to ask the user to review their settings/choices.
I've changed my position on things I've opted in/out of at various times. When it's privacy-related, I've increasingly developed a harder default stance over the last 15 years. I wouldn't mind if my tools asked me to annually review old choices I've long forgotten--much like I've heard Facebook offers people their little privacy checkups (ignoring for the moment the efficacy of such a checkup when everything you do is tracked). Many people other than me reacted to the way in which the analytics "feature" was included in homebrew with surprise, because many of us never noticed the notification, and a great many of us believe tracking is something that should always be opt-in, not opt-out. However, as of this writing, I can't recall exactly what my current homebrew setting for analytics is, and I can't recall how long it's been since I last checked it to ensure it is what I think it is.
But hey, that's just me, friend. I can't remember every choice I made last month, much less last year, two years ago, or any time before that. If you do, that's cool. If you were using a tool I created/maintained, and I wanted to cover all my bases, I'd simply give you a way to say, "Don't ever fucking ask me this question again or I'll rage tweet what a forgetful little shit you are." :)
I stand by my intense rage that I would feel if some software I was using asked me a setting question that I had already set (for no reason other than the length of time since I last answered the question). Sorry, but I'm particular about my user experience. I'm not arguing anything for or against the privacy concerns, as I do not believe the fact that this is a privacy setting means it should be treated differently than other settings.
I guess I should have gone into specifics about why I don't like that idea... I can think of lots of things that let you set a setting and say "never ask me again", but those aren't quite the same. They're usually for things that get asked _every_ time you run those programs, so until you select "never ask me again" you're not actually setting the setting, you're just giving a temporary answer for that one use. Notice how this differs from what you've suggested (asking you based on an arbitrary time period). Your suggestion is a different paradigm than the already existing ones. I can see a case for having it ask you if you want to be tracked each time you run homebrew, or each time you upgrade homebrew, but doing so based on an arbitrary time-based interval (be it days, months, or years) seems odd and needlessly different than the existing accepted UI paradigms.
Oh, and I'm not sure Facebook's privacy check-ups is the best analogy. I always thought they did the check-ups when they've specifically changed something and need to give you the option to opt-out of the change, not as a friendly "do you still want your settings this way". Maybe I'm wrong about that, but that's what it always felt like to me when I was using facebook more, since I'd see a lot of articles/blog posts about new changes, and then the next time I logged in I'd get the privacy check-up.
I guess I should have gone into specifics about why I don't like that idea... I can think of lots of things that let you set a setting and say "never ask me again", but those aren't quite the same. They're usually for things that get asked _every_ time you run those programs, so until you select "never ask me again" you're not actually setting the setting, you're just giving a temporary answer for that one use. Notice how this differs from what you've suggested (asking you based on an arbitrary time period). Your suggestion is a different paradigm than the already existing ones. I can see a case for having it ask you if you want to be tracked each time you run homebrew, or each time you upgrade homebrew, but doing so based on an arbitrary time-based interval (be it days, months, or years) seems odd and needlessly different than the existing accepted UI paradigms.
Oh, and I'm not sure Facebook's privacy check-ups is the best analogy. I always thought they did the check-ups when they've specifically changed something and need to give you the option to opt-out of the change, not as a friendly "do you still want your settings this way". Maybe I'm wrong about that, but that's what it always felt like to me when I was using facebook more, since I'd see a lot of articles/blog posts about new changes, and then the next time I logged in I'd get the privacy check-up.
If you are a user who cares about such things, I think the onus lies on you.
If it is clearly documented that should be it. Maybe a blurb on the main page about it would be nice but not necessary.
Any opt-out features should be disclosed to the user on install. That seems fairly straight forward to me.
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.
Existing installs were not prompted. You had to catch it in the patch notes, IIRC.
Not prompted but were notified.
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.
PS: Despite my feelings of disagreement on how brew handled this, I still appreciate your work.
Homebrew literally never prompts for anything so a prompt would likely break many scripts.
You are right. If I put more thought into my comment I would have urged them to prompt the user. But I rushed, and the post was invalid and senseless.
I feel that if you're collecting data about me and sending it to a third party, there should at least be a clear notice during installation. It should really be opt-in, but at the very least it should be as obvious as they would make it if it were opt-in.
There is a clear notice during installation.
That would turn it off for package downloads, but not for the initial install, right?
Out of curiosity, would you be more comfortable if brew webcalled a different service? one not affiliated with Google?
Not sure about him, but I personally would, yes.
Well different, i would prefer it would make only calls to services that are required for what the application does, so sites' project i guess is okay, but certainly not third parties. And then certainly not any big data third parties. I'm quite sure, there are download stats for the brew application itself to monitor usage and so on.
Though i had the option to block it, using little snitch (great app, not affiliated). For web browsing i have it on never allow already, but not for all applications i use from terminal, so the little snitch, snitched about it.
Though i had the option to block it, using little snitch (great app, not affiliated). For web browsing i have it on never allow already, but not for all applications i use from terminal, so the little snitch, snitched about it.
We do not have the resources to be able to host something like this ourselves or we would have done so.
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. :(
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. :(
Fun fact: for maximum compatibility our vendored portable Ruby 2.3.3 was compiled on 10.5 (hence these fixes).
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?
What ties people to PowerPC these days? Surely the speed and power consumption of the latest Intel machines is 100x better?
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.
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?
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?
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?
Does anyone use MacPorts/Fink anymore? What are the use cases for them?
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.
- 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.
Also Macports works in a multi user environment without problems (as long as one either gives all users sudo access or sudo port access).
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).
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).
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...
Honestly I don't know if that's popular, when using Homebrew and MacPorts I was always installing open source stuff...
I use MacPorts pretty heavily and prefer it over homebrew. The use-case is the same as for homebrew
I meant, what do you prefer about one vs the other
I use both homebrew and macports. The main benefit with macports for me is the ability to work with different versions at the same time. You can have applications requiring gcc4.5, gcc4.9, and gcc6 installed. The package manager handles most weird special cases and combinations.
Last I used MacPorts I thought it was more separate from MacOS, installing its own components rather than using what comes with the operating system.
I preferred the MacPorts model, but when I used them both, there seemed to be a lot less support compared to Homebrew. When builds stop working, they seemed to be fixed in Homebrew before they were fixed in MacPorts, and Homebrew also seemed to have more current versions of most packages available.
I preferred the MacPorts model, but when I used them both, there seemed to be a lot less support compared to Homebrew. When builds stop working, they seemed to be fixed in Homebrew before they were fixed in MacPorts, and Homebrew also seemed to have more current versions of most packages available.
Homebrew also seems to use its own toolchain packages if they're installed. It just doesn't insist on it like MacPorts.
I switched to Brew because I got tired of recompiling from source for every update with MacPorts. As an end-user I don't see the benefit of repeating the same thing N times for N clients versus doing it once, centrally.
Every time "boost" updates, you're stuck recompiling half your ports for the next 20 minutes to use the new library. With Brew, you wait a minute for the new packages to download, and you're done.
Every time "boost" updates, you're stuck recompiling half your ports for the next 20 minutes to use the new library. With Brew, you wait a minute for the new packages to download, and you're done.
MacPorts has been providing binary packages since 2.0, which was released in 2011. Many pre-compiled binaries are even available for old macOS versions back to 10.6. There are only a few ports where the license does not allow binary distribution.
I don't know what to tell you, I like it better. Different flavours for different folks.
I never know what to make of "people still use ______?!" comments
I never know what to make of "people still use ______?!" comments
Is there no specific reason why you like it better? Usually you can explain why certain software is preferable to similar software. For example, I use IntelliJ over VS Code for writing Scala because I've had difficulties getting the Ensime extensions to work properly and IntelliJ usually just works. I use VS Code over PyCharm for writing Python code because it's lighter weight and offers 99% of the features that I need. We use Slack at work instead of IRC because there are a lot of non-technical people who need to communicate with the dev team and Slack offers an easy to use UI for organizations.
For myself, I like MacPorts better than Homebrew because in my experience it's subject to less breakage, less flaky interaction with tools like rvm or python, and has a better project philosophy overall. And I personally like that it's not in Ruby but I understand the opposing opinion too ;)
> I never know what to make of "people still use ______?!" comments
Usually people are assuming a network-effect that would make using not-Foo when Foo has "won" problematic. Like, imagine using MySpace as your social network today. It'd be a ghost town and nobody you knew would be on it.
In this case, I imagine people would expect that MacPorts either wouldn't have as wide a selection of packages, or wouldn't keep 100% of its packages constantly up-to-date, or some combination of the two.
Usually people are assuming a network-effect that would make using not-Foo when Foo has "won" problematic. Like, imagine using MySpace as your social network today. It'd be a ghost town and nobody you knew would be on it.
In this case, I imagine people would expect that MacPorts either wouldn't have as wide a selection of packages, or wouldn't keep 100% of its packages constantly up-to-date, or some combination of the two.
Our team uses MacPorts, at this point mostly out of habit and because no-one has taken the time to try out Homebrew and see how our pipeline would work on that.
Not that we have any problems with MacPorts really.
I too am curious about qualitative differences between the two.
Not that we have any problems with MacPorts really.
I too am curious about qualitative differences between the two.
I like MacPorts over Homebrew because MacPorts lives in its own directory. Homebrew can hose your system binaries and that was enough for me to never use it.
Homebrew, like, for example, CPAN, runs reasonably arbitrary code at package-install time. Much of it is sandboxed, or reviewed by the maintainers, but scripts/configure programs/etc. can spray files, or remove files, anywhere they want on your system. The same is true with ill-behaved "configure; make; make install" deployment systems.
This is contrasted with something like dnf/yum, which has registries of assets that are supposed to be installed. I'm not positive, but I suspect something like that would be a way higher maintenance burden for OSX (for maintainers of the package management system and packagers themselves, many of whom have shown little to no interest in packaging for OSX, hence Homebrew's patch system).
It also lives primarily in its own directory, unless you're installing casks (which usually "do exactly what the installer would do if I downloaded and installed it myself") or packages with special cases that manage external-to-homebrew things. For packagers, the API for "use Homebrew-managed/blessed directories for e.g. --prefix configure arguments" is pretty good, but people (and bad, old build scripts) can and do still mess around outside of where they're supposed to. "Hosing your system binaries" is a pretty darn rare occurrence unless you're explicitly configuring brew to put things where it wouldn't normally.
Edit: plurals are hard.
This is contrasted with something like dnf/yum, which has registries of assets that are supposed to be installed. I'm not positive, but I suspect something like that would be a way higher maintenance burden for OSX (for maintainers of the package management system and packagers themselves, many of whom have shown little to no interest in packaging for OSX, hence Homebrew's patch system).
It also lives primarily in its own directory, unless you're installing casks (which usually "do exactly what the installer would do if I downloaded and installed it myself") or packages with special cases that manage external-to-homebrew things. For packagers, the API for "use Homebrew-managed/blessed directories for e.g. --prefix configure arguments" is pretty good, but people (and bad, old build scripts) can and do still mess around outside of where they're supposed to. "Hosing your system binaries" is a pretty darn rare occurrence unless you're explicitly configuring brew to put things where it wouldn't normally.
Edit: plurals are hard.
I haven't looked into this too heavily, but my understanding is that Homebrew prefixes everything it installs. It does not touch any existing files, so uninstallation (even just to reinstall) is just deleting a directory.
MacPorts does not work the same way.
Edit: grammar.
MacPorts does not work the same way.
Edit: grammar.
macports user. works just fine, no reason to switch.
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?
Just curious, that always seemed like a strange scenario.
* or am I wrong that it ever did?
"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...
[1] https://github.com/Homebrew/homebrew-core/tree/master/Formul...
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.
Right, those binaries are hosted in Bintray (http://homebrew.bintray.com/)
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/ returns "Forbidden", probably because the directory listing is too large.
You would think `wget` for building your own mirror would work fine but no, http://homebrew.bintray.com/bottles/ returns "Forbidden", probably because the directory listing is too large.
There is an environment variable you can set to force building from source if you do not want to rely on bottled binaries.
They moved their heavy stuff to bintray, which is a better fit.
I don't know about homebrew, but Nix does (not binaries, though).
https://github.com/NixOS/nixpkgs
https://github.com/NixOS/nixpkgs
Both Cocoapods and Homebrew are pretty big on github.
The previous cocoapods article comments mention this.
https://news.ycombinator.com/item?id=11245652
Awesome! At some point I would like to get into Homebrew development (I'm already familiar with Ruby).
We'd love that! Here's a good starting point and feel free to contact me directly if you'd like other pointers.
Just curious, where can I find their reasoning for removing apache & php from brew? Is it because they come pre-installed on macs?
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.
I reckon they have not been removed from homebrew, just relocated.
For example, apache has been moved to homebrew-core. You can see that in the archived repository: https://github.com/Homebrew/homebrew-apache
For example, apache has been moved to homebrew-core. You can see that in the archived repository: https://github.com/Homebrew/homebrew-apache
[deleted]
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?la...
I love that one. I now regularly use "invert a binary tree" as a proxy joke for "let's grill you at a whiteboard with algorithmic puzzles that we never use in practice here but they make a great reason for us to belittle and laugh at you for not being desperate enough to drill these kind of questions for months before coming here"
This is the thing that always confuses me. Google is a company that we all associate with a fairly high quality of technical work, and yet they still appear to use as interview questions what we'd all consider to be really poor proxies for on-the-job performance. I can't seem to reconcile those two things.
That's easy enough: Google is sufficiently big and well known that even if they have an alarmingly high false negative rate, they will never run out applicants, and "weeding out" even a lot of high quality applicants doesn't substantially reduce the average competence of the remaining pool. And the company is big enough that it can absorb the occasional false positive as well, especially when it comes to people who know their algorithms but not, say, how to work on a team effectively.
I dunno--to me that rant hints at a potential inability to take rejection well. No matter what company you're talking about, getting hired has a luck-based component, so you shouldn't take rejection personally. I've probably been turned down for 99% of the jobs I've applied for in my career. If I opened Twitter to rage every time someone told me "no" I'd sound like a lunatic.
In my view, the correct response to being turned down at a company where I want to work is to simply try again later. No need to stress about it.
In my view, the correct response to being turned down at a company where I want to work is to simply try again later. No need to stress about it.
The problem with your view is that you're basically expecting everyone to be robots. I entirely can understand needing to vent like that after not getting a job for a very, very stupid reason.
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.
No, but just because he created homebrew doesn't mean he's qualified either. Homebrew is one of the least reliable pieces of software I've ever used. It's popularity puzzles me and I've stopped letting it get near any machine I use. It's baffling and annoying to me that people view it as some default packaging solution for Mac, especially when the platform already has pkgutil/pkgbuild. I really wish something like Rudix [0] had taken off instead of homebrew since it's far superior.
Popularity doesn't mean quality and the entitlement of that tweet would be a red flag to me as an interviewer.
[0] http://rudix.org/
Popularity doesn't mean quality and the entitlement of that tweet would be a red flag to me as an interviewer.
[0] http://rudix.org/
Popularity may not inherently imply quality, but enough popularity over time correlates with a gradual improvement in quality.
Homebrew has improved a ton over just a few short years. The Linux ecosystem did the same, as did many other projects that started out as a popular-but-less-featureful/reliable alternative.
If it's been awhile since you tried it, I'd check it out.
Homebrew has improved a ton over just a few short years. The Linux ecosystem did the same, as did many other projects that started out as a popular-but-less-featureful/reliable alternative.
If it's been awhile since you tried it, I'd check it out.
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.
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.
yes, the goal is standardization of interviews, not hiring the best candidate, but it's also about signalling the cleverness of the interviewer and the company. if you're actually clever, it will be evident during the interview without having to plan for it with a pre-determined interview puzzle.
but your "zero risk" assessment is a common but unproven justification of such hiring practices. with good management, you can easily bound the cost of a bad hire to a few (tens of) thousands of dollars. it's hard to estimate the benefit of a good hire since that's an alternate reality not taken, but it's probably many, many times higher than the cost of a bad hire:
opportunity cost of losing a good hire >>> realized cost of a bad hire
(the probability of a bad hire is higher than of missing out on a good hire however, so you'd need real numbers to estimate the relative costs)
but your "zero risk" assessment is a common but unproven justification of such hiring practices. with good management, you can easily bound the cost of a bad hire to a few (tens of) thousands of dollars. it's hard to estimate the benefit of a good hire since that's an alternate reality not taken, but it's probably many, many times higher than the cost of a bad hire:
opportunity cost of losing a good hire >>> realized cost of a bad hire
(the probability of a bad hire is higher than of missing out on a good hire however, so you'd need real numbers to estimate the relative costs)
Binary tree questions probably come up as often as they do, relative to how often binary trees are actually used, because so many interview questions can be solved trivially with hash tables.
Just because you don’t use binary trees doesn’t mean Google or Amazon don’t, though. Maybe not binary trees themselves, but b-trees and similar data structures are widely used in file systems, databases, and other large scale systems that these companies routinely work on.
Also, everyone knows that companies ask questions about data structures and algorithms. If you’re have the ability and inclination to prepare for these interviews, that says something about you as a candidate. If you don’t prepare at all and then go on the internet to whine about it when you don’t get an offer, that also reflects on you.
Just because you don’t use binary trees doesn’t mean Google or Amazon don’t, though. Maybe not binary trees themselves, but b-trees and similar data structures are widely used in file systems, databases, and other large scale systems that these companies routinely work on.
Also, everyone knows that companies ask questions about data structures and algorithms. If you’re have the ability and inclination to prepare for these interviews, that says something about you as a candidate. If you don’t prepare at all and then go on the internet to whine about it when you don’t get an offer, that also reflects on you.
> and 100% about companies trying to come up with a standardized, one size fits all tech interview that can be used for every position
Pretty much. We had a conversation at work about this recently, where folks were talking about how they were varying up the interview process depending on the applicant.
Some people pushed back saying we needed a one size fit all process to avoid things being unfair/biaised/etc.
When you push that to the extreme, the google process is what you get (and who gets hired is biased as hell anyway).
While it has its flaws, Ill always push hard for personalized interviews whenever possible. Look at someone's resume to see if its someone who would be useful to you, then test them on THAT to make sure they're not bullshitting on their resume.
Pretty much. We had a conversation at work about this recently, where folks were talking about how they were varying up the interview process depending on the applicant.
Some people pushed back saying we needed a one size fit all process to avoid things being unfair/biaised/etc.
When you push that to the extreme, the google process is what you get (and who gets hired is biased as hell anyway).
While it has its flaws, Ill always push hard for personalized interviews whenever possible. Look at someone's resume to see if its someone who would be useful to you, then test them on THAT to make sure they're not bullshitting on their resume.
Nope. It's just hazing. The geek version of fraternity pledge week.
The only standardization is the thud of hitting the floor due to all participants expending the least possible effort. Like a team building trust fall where everyone is too busy checking Messenger to be bothered to extend their arms.
The shared failure of institutionalized apathy.
The only standardization is the thud of hitting the floor due to all participants expending the least possible effort. Like a team building trust fall where everyone is too busy checking Messenger to be bothered to extend their arms.
The shared failure of institutionalized apathy.
I don't see the a contradiction between these two ideas. That last sentence, about this contributing to insiders' perception of being an elect few, describes the same kind of mentality that allows hazing to persist in organizations that do 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
You know the founder of homebrew was filtered out by exactly this, right?
You know the founder of homebrew was filtered out by exactly this, right?
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.
I said that there's minimal risk that they filter out all qualified applicants, not that they won't filter out any of them.
“Capable of writing software that solves a real world problem” isn’t necessarily Google’s bar. It’s entirely possible that the creator of Homebrew doesn’t have the level of skill that Google requires.
Possible points for the defense:
- He may be qualified to work at Google, but that's not apparent just because he created Homebrew, right?
- Google can afford to be picky enough to miss out on popular open-source project authors who _can't_ code on the whiteboard in favor of those who _can_ -- can we argue that they should reverse this, or just that in certain cases potentially-qualified people fall through the cracks?
- He may be qualified to work at Google, but that's not apparent just because he created Homebrew, right?
- Google can afford to be picky enough to miss out on popular open-source project authors who _can't_ code on the whiteboard in favor of those who _can_ -- can we argue that they should reverse this, or just that in certain cases potentially-qualified people fall through the cracks?
I get that the response to this will be "they make $INFINITY as-is", but yes, I'd be willing to argue that they should reverse that. My basic argument would look something like:
A) Writing algos on a whiteboard is not the be-all end-all of actual programming
B) The skill set of "can identify things that people want and need and actually implement them" is a useful one that the person who created one of the most widely used pieces of OSS out there has demonstrated they have.
C) There's no evidence that I know of that indicates that whiteboard algo writing correlates with the skill set identified in B, and a fair amount of anecdotal evidence that suggests they aren't correlated. (And there are a range of other skills that are useful for an engineer or someone leading teams of engineers that are similarly not correlated with whiteboard algo writing.)
D) Firms benefit from diversity. Gender-diverse and ethnically-diverse companies are more likely to out-perform less diverse companies.[1] I don't have specific evidence for it, but I suspect that a firm that has a hiring process that brings in people with multiple diverse skill sets will eventually perform better than a firm that only brings in employees with tightly focused, highly similar skill sets.
And to respond to the "well, FB/Amazon/Google make $INFINITY as-is, so nyah-nyah", I would say that those companies are in market-dominant positions now that may make their math on hiring a diverse array of skill sets different from a theoretical firm, but I also suspect that maintaining those dominant positions will be more difficult with an engineering corps that is solely selected on a narrow band of proficiencies.
So, I'm not necessarily saying that Google should change their policy (although I do feel comfortable saying that any company that isn't in that rarified air that decides to copy that policy is making a serious mistake), but I think there's a pretty solid case for why they should at least acknowledge that there are people for whom they should make exceptions and possibly completely reverse that policy and overhaul their hiring process to achieve a broader range of skills among their engineers.
[1]: https://www.mckinsey.com/business-functions/organization/our...
A) Writing algos on a whiteboard is not the be-all end-all of actual programming
B) The skill set of "can identify things that people want and need and actually implement them" is a useful one that the person who created one of the most widely used pieces of OSS out there has demonstrated they have.
C) There's no evidence that I know of that indicates that whiteboard algo writing correlates with the skill set identified in B, and a fair amount of anecdotal evidence that suggests they aren't correlated. (And there are a range of other skills that are useful for an engineer or someone leading teams of engineers that are similarly not correlated with whiteboard algo writing.)
D) Firms benefit from diversity. Gender-diverse and ethnically-diverse companies are more likely to out-perform less diverse companies.[1] I don't have specific evidence for it, but I suspect that a firm that has a hiring process that brings in people with multiple diverse skill sets will eventually perform better than a firm that only brings in employees with tightly focused, highly similar skill sets.
And to respond to the "well, FB/Amazon/Google make $INFINITY as-is, so nyah-nyah", I would say that those companies are in market-dominant positions now that may make their math on hiring a diverse array of skill sets different from a theoretical firm, but I also suspect that maintaining those dominant positions will be more difficult with an engineering corps that is solely selected on a narrow band of proficiencies.
So, I'm not necessarily saying that Google should change their policy (although I do feel comfortable saying that any company that isn't in that rarified air that decides to copy that policy is making a serious mistake), but I think there's a pretty solid case for why they should at least acknowledge that there are people for whom they should make exceptions and possibly completely reverse that policy and overhaul their hiring process to achieve a broader range of skills among their engineers.
[1]: https://www.mckinsey.com/business-functions/organization/our...
For a lot of the people Google needs to hire to write Google-scale code, maybe "can identify things that people want and need and actually implement them"" isn't a particularly useful skillset _to Google_, but the skill set of "ingrained knowledge of data structures useful to writing scalable, low-level code" is.
I do agree that the "make things people want" is a very useful/desirable skillset for a vast array of non-Google-scale companies, and I'd personally prefer to work for a company that values this.
But I'm willing to posit that at a certain software engineering scale, the problems and valued traits are very different, and may align more with "knows data structures" than "can make something people want".
I'm not saying Google should value one to the exclusion of the other. But perhaps if you have Google's talent pool, the base level is "ingrained data structure knowledge" (correlating to engineering skills they need), and they'll also get the "ingrained data structure knowledge AND ability to make something people want" applicants.
I'm not arguing that other companies should do this. Just exploring whether it makes more sense for Google than perhaps we would think.
I do agree that the "make things people want" is a very useful/desirable skillset for a vast array of non-Google-scale companies, and I'd personally prefer to work for a company that values this.
But I'm willing to posit that at a certain software engineering scale, the problems and valued traits are very different, and may align more with "knows data structures" than "can make something people want".
I'm not saying Google should value one to the exclusion of the other. But perhaps if you have Google's talent pool, the base level is "ingrained data structure knowledge" (correlating to engineering skills they need), and they'll also get the "ingrained data structure knowledge AND ability to make something people want" applicants.
I'm not arguing that other companies should do this. Just exploring whether it makes more sense for Google than perhaps we would think.
Sure, that's what I was trying to convey in the paragraph after D. That said, I think that even for a company Google's size, having those different skill sets will be useful as your business ages. Google will probably always need a number of people that have memorized every data structure known to humanity, but they would probably be better set up to avoid stagnation and continue in a position of market dominance into the future if they also have a set of people who can come up with new things and implement them.
But also maybe it's better that those people don't end up at Google et al. and that these gigantic companies stagnate and eventually die because their corporate bureaucracy/scar tissue prevents them from hiring the people who can prevent them from stagnating and dying? I dunno, haven't really fleshed this idea out too much.
But also maybe it's better that those people don't end up at Google et al. and that these gigantic companies stagnate and eventually die because their corporate bureaucracy/scar tissue prevents them from hiring the people who can prevent them from stagnating and dying? I dunno, haven't really fleshed this idea out too much.
> Google will probably always need a number of people that have memorized every data structure known to humanity, but they would probably be better set up to avoid stagnation and continue in a position of market dominance into the future if they also have a set of people who can come up with new things and implement them.
Yep, agreed! But since there's probably some overlap in that candidate skillset Venn diagram, maybe they're getting the people that can do both, and the data-structure skillset's the one that's possible to consistently interview for.
Yep, agreed! But since there's probably some overlap in that candidate skillset Venn diagram, maybe they're getting the people that can do both, and the data-structure skillset's the one that's possible to consistently interview for.
It’s not complete crap - the cost of a bad hire is a lot more than the cost of missing out on a good one.
Except that implies that someone who remembers how to invert a binary tree but doesn't have an open track record is a better hire than someone who couldn't remember but created, maintains and improves a popular open source project for YEARS.
Working software should be prioritised over rote memorisation of data structure theory.
Working software should be prioritised over rote memorisation of data structure theory.
It also implies that just because you can invert a binary tree on a whiteboard you’re actually good. That’s debatable but I guess it’s one of N filters.
When I interviewed at Google they asked a lot of (at the time) very specific questions about various languages but only 1 “solve this riddle” type question. It was a pretty good experience.
The best interview I ever did was with an investment bank where I was struggling to whiteboard some problem (after a string of really tough, challenging problems I did well at) and they let me use a terminal to actually code it up (which I managed to do very quickly). I got that offer. ;)
When I interviewed at Google they asked a lot of (at the time) very specific questions about various languages but only 1 “solve this riddle” type question. It was a pretty good experience.
The best interview I ever did was with an investment bank where I was struggling to whiteboard some problem (after a string of really tough, challenging problems I did well at) and they let me use a terminal to actually code it up (which I managed to do very quickly). I got that offer. ;)
[deleted]
Welcome to the free market, where private companies are free to hire or not hire at will based on criteria that works for them. Writing OSS doesn’t entitle you to any job.
Also “inverting” a binary tree is a trivial computation exercise. There’s a difference between engineering and scripting. Homebrew is very much a scripting problem.
Also “inverting” a binary tree is a trivial computation exercise. There’s a difference between engineering and scripting. Homebrew is very much a scripting problem.
"Welcome to the free market, where private companies are free to hire or not hire at will based on criteria that works for them. Writing OSS doesn’t entitle you to any job."
Nobody is saying anything other than that. They're pointing out how dumb the decision is.
"Also “inverting” a binary tree is a trivial computation exercise."
It really isn't, especially if you're not doing it on a regular basis. Which I'd contend 99% of people, including those at Google, are not doing.
"There’s a difference between engineering and scripting. Homebrew is very much a scripting problem."
Aside from, you know, the entire infrastructure around it. That is very much an engineering problem.
Nobody is saying anything other than that. They're pointing out how dumb the decision is.
"Also “inverting” a binary tree is a trivial computation exercise."
It really isn't, especially if you're not doing it on a regular basis. Which I'd contend 99% of people, including those at Google, are not doing.
"There’s a difference between engineering and scripting. Homebrew is very much a scripting problem."
Aside from, you know, the entire infrastructure around it. That is very much an engineering problem.
“Nobody is saying anything other than that. They're pointing out how dumb the decision is.”
I think filtering people based on ability to solve trivial binary tree manipulation problems is brilliant. Seems to objectively be working out great for google thus far.
I think filtering people based on ability to solve trivial binary tree manipulation problems is brilliant. Seems to objectively be working out great for google thus far.
Excellent
I read somewhere ( and I bet ) it's used by Google / Facebook / Apple employees.