41–50 of 219 posts
Earlier quoted context omitted.
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 never know what to make of "people still use ______?!" comments
The Patreon page says they receive $177 per month. That's too low for a project with such a high popularity and usage. I read somewhere ( and I bet ) it's used by Google / Facebook / Apple employees.
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/
Earlier quoted context omitted.
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.
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 crack…
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...
Earlier quoted context omitted.
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.
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.
Working software should be prioritised over rote memorisation of data structure theory.
The Patreon page says they receive $177 per month. That's too low for a project with such a high popularity and usage. I read somewhere ( and I bet ) it's used by Google / Facebook / Apple employees.
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…
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.
Just curious, where can I find their reasoning for removing apache & php from brew? Is it because they come pre-installed on macs?
Earlier quoted context omitted.
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.
The Patreon page says they receive $177 per month. That's too low for a project with such a high popularity and usage. I read somewhere ( and I bet ) it's used by Google / Facebook / Apple employees.
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…
Just curious, where can I find their reasoning for removing apache & php from brew? Is it because they come pre-installed on macs?
For example, apache has been moved to homebrew-core. You can see that in the archived repository: https://github.com/Homebrew/homebrew-apache