Hacker Newsnew | past | comments | ask | show | jobs | submit | Lukasa's commentslogin

Quoting directly from the text:

> It's the third time I'm using Apple hardware for Linux development

No mention of ARM64 there.


Oh, I misinterepreted. How do I delete my old posting...

Although Apple branded hardware is not apple developed hardware, so I read that in a different way. But now I realize that PowerPC was not an Apple Development, too, so he means Apple branding. So in my head, this is his first time of using Apple hardware (CPU, not keyboard, casing, etc.) for kernel compilation.

Thanks Apple for insisting that "this is the first Apple hardware" for clamshell laptops in your PR statements.


> Re configurable TLS: TLS 1.3 allows services to perfectly pin certs and reject your custom root CA. It breaks the flow you are talking about that has worked up to 1.2. The answer is to not build a myopic protocol/technology that only cares about 1 dimension of usage.

No it doesn't. I have no idea what technology you think this is (maybe HPKP?), but installing a local root CA absolutely continues to work in all browsers with TLS 1.3.


TLS proxies need to be able to inspect the server certificate response in order to dynamically generate an appropriate certificate. This flow doesn't work in TLS 1.3 since the certificate is encrypted to prevent MITM.


MITM for TLSv1.3 is possible. Plenty of solutions available for enterprises to do this. The MITM occurs still happens for TLSv1.3 on key exchange, allowing for the subsequent certificate to also be MITM and be replaced and encrypted. The only real affect TLSv1.3 has for MITM is that company policies for decryption can't match on the cert to determine if decrypt should occur, but they can still use the SNI which is plaintext


I thought combined with encrypted SNI this was no longer possible since the middleware doesn't have access to that information.


The same is true of Swift, and Swift can also call into C whenever it likes. The difference is that Swift can do the same for Objective-C at full fidelity, including support the full Objective-C feature set (ARC, arbitrary selectors, interfaces, properties, you name it).


You can definitely default on a negative rate mortgage, by not paying your monthly payment. You cannot pay nothing each month. Instead, the principal reduces each month by more than the amount you paid. You still have a term over which you have to pay the mortgage off. No-one is offering (or will offer) a negative interest rate _interest only_ mortgage.

Negative interest rates make sense if you consider them as a lender trading current cash-on-hand for future cash flow. That is, the bank has $200k today, but it would rather see that broken up into payments over 10 years, even if it has to pay you to do it.

When viewed through this lens, it becomes clear that the factor driving this is likely that the bank is being disincentivised from storing the cash directly.


`some Shape` is literally identical to `impl Shape`, including the semantics you discuss above. The compile-time return value of a function returning `some Shape` must be the same on all execution paths. It just avoids expressing to the caller what it is.

Incidentally, this in principle allows the optimiser to specialise the caller to the return type of this function, avoiding the existential altogether.


Have you considered OmniOutliner for this use case?


OmniOutliner is one of my favorite applications. I use it every day as a planner/outliner. OmniFocus grew out of OmniOutliner, and I used to be an OmniFocus user. But since I started using OmniOutliner I've completed the circle and use it for just about everything, including todolists.

Only big limitation is that it's Mac and iOS only. No web or Windows version (also, the Pro version is a bit expensive)


> He was very clear that he was talking about the group not any individuals.

Since when does that excuse anything? If he'd written "Jews are, in general, hateful monsters. Not the Jews who work here, they're great, but most of the rest" does that statement become acceptable?

More importantly, Mr Damore does not know all the women at Google personally. He cannot. So when he says "In general, women are less suited to/interested in programming careers", he cannot possibly implicitly mean "but clearly that does not apply to every woman currently employed at Google, who were all hired because they are the best in the world at their jobs". Damore asserts that Google practices discriminatory hiring practices. For this to be true, Google must have at least once hired a woman where a better male candidate was available, and more importantly must do so more often than they do the reverse.

If you are going to make general statements about a group of people, then you should not be surprised when individuals in that group assume you mean that statement to apply to them.


I say: black people are more suited to be NBA players. This is obvious looking at black players % in the league in comparison to the total population as well as the fact that black people are poorer on average and get less opportunities (or even chances for proper nutrition, let alone training).

Should white NBA players be offended by that statement? The answer is obvious: they shouldn't as that only means they were the ones on the tail of the genetic distribution and made it anyway or maybe even they overcome disadvantages to get there.

Now I say: women are in general less likely to be interested in tech and less likely to become good programmers because they are, on average, less competitive and less likely to devote themselves to solitude practice which is often necessary to become a very good coder.

Should women, who already made it to Google be offended? Of course they shouldn't for the same reasons as above. We can however do something with this information: we can try changing tech world to be more welcoming to women. This way we can avoid sexist hiring practices (gender quotas are clear discrimination) while still achieving more diverse environment.

Those are the points of the manifesto. Being offended by that is the problem of those taking offence as it doesn't speak well about their ability to reason about distributions of traits in a population.


> Should white NBA players be offended by that statement? The answer is obvious: they shouldn't as that only means they were the ones on the tail of the genetic distribution and made it anyway or maybe even they overcome disadvantages to get there.

I don't know: I'm not an NBA player and have no idea what the experience of becoming one is like. But there is a difference in kind here. He didn't say "Men are better suited to be Google employees", he said "Men are better suited to be programmers". The closer analogy here is to say that "Black people are better basketball players than white people", and here it might well be fair for white NBA players to be offended. There is a distinction between saying "More of X are good enough to pass this bar", and "X is better than Y". People who can pass the bar are unlikely to be offended for themselves (though they may be offended for others who don't attempt to cross that bar), but they may be offended for themselves if the suggestion is that they are worse than their colleagues.

But if you said, in addition, "The NBA currently employs discriminatory hiring practices that favour white athletes at the expense of black ones", then they should be offended. At that point you are saying "I believe that group X is better than group Y, and many of group Y are here despite there being better members of group X". That is offensive.

> We can however do something with this information: we can try changing tech world to be more welcoming to women.

I have a suggestion as to how to do that: stop saying that women are worse at coding. Just don't even bring it up. This goes doubly because there is no evidence for that at all.

You can make the tech world more welcoming to women by welcoming more women, and then give them the opportunity to succeed. Writing think pieces about how women are so ill-suited to coding doesn't just display a stunning lack of understanding about how the industry got started, it also makes it clear that right now you think women don't belong.

But if the view is that "software work as it is today is just not women's work, so we should make it more like women's work", then I'm sorry but you've already lost.


Have you read the memo? By saying "stop saying that women are worse at coding" you are putting words in his mouth, as the memo states a very, very different thing i.e. that women are less likely to choose coding for various reasons, including biological ones. There's a world of difference between these two arguments.

And there is solid evidence for that difference, and it should be brought up, and asking to stop the discussion is, frankly, ridiculous - we can all see that there is an important open problem with different viewpoints and thus it should be discussed, and expressing all kinds of possible viewpoints should be facilitated.


> Have you read the memo? By saying "stop saying that women are worse at coding" you are putting words in his mouth, as the memo states a very, very different thing i.e. that women are less likely to choose coding for various reasons, including biological ones. There's a world of difference between these two arguments.

I wasn't replying to the memo, I was replying to bluecalm, and bluecalm said this:

> Now I say: women are in general less likely to be interested in tech and less likely to become good programmers because they are, on average, less competitive and less likely to devote themselves to solitude practice which is often necessary to become a very good coder.

Note "less likely to become good programmers". I feel pretty comfortable with my response given that.

> and expressing all kinds of possible viewpoints should be facilitated.

I disagree. Many kinds of possible viewpoints construct hostile work environments, and should be forbidden. It is simply not necessary to allow a workplace to tolerate all views. We don't allow people to cover their cube in swastikas, walk around greeting all their colleagues with "heil hitler", and to push for the dismissal of all their Jewish colleagues in an attempt to reduce the influence of the hidden Jewish conspiracy running the world.

If Mr Google had wanted to write this on his personal blog I wouldn't have cared at all. But he didn't do that: he wrote it at work, in his professional capacity, and posted it for his co-workers to see. Guess what: speech at work is something that can get you fired. See Colin Kaepernick for evidence.


The funny thing is, you might be wrong about black guys and NBA suitability. The reason is, black people hit puberty earlier, and that might cause them to be selected for and receive extra attention and training because of a temporary athletic advantage, in much the same way that hockey players born in a certain part of the year (the oldest among their cohort) tend to be.


> he cannot possibly implicitly mean "but clearly that does not apply to every woman currently employed at Google, who were all hired because they are the best in the world at their jobs"

He clearly can, were it not for affirmative actions - if you assume perfect recruitment based on merit, you can expect everyone accepted to be suitable for the role. But in this case you'll also find, as the memo author explained quite sensibly, that the gender ratio might not be 1:1 due to distribution of interest in the population, which affects the distribution of the candidate pool.

I mean, come on, this is a pretty obvious point - and I'm starting to believe that it takes intent to misread it like you did.

> Damore asserts that Google practices discriminatory hiring practices.

Yes, that's the definition of affirmative action. It's literally discriminating in order to counter perceived discrimination in the opposite direction.


> I mean, come on, this is a pretty obvious point - and I'm starting to believe that it takes intent to misread it like you did.

I...don't think I did misread it? I said "he cannot mean this", and you appear to agree with me: due to the facts on the ground, he cannot have intended to mean that. Therefore, I have to assume he did not mean that.

So if he believes that Google employs discriminatory hiring practices, then he presumably believes that some of his colleagues are not the best possible choice for their role, and do not deserve to be there. That seems like a straightforward reading of his text. Am I wrong?


How do you make any business decisions when taking things this personally?


I think that the media and Google itself did a horrible disservice to the memo author in mis-representing his words, and I'm fairly certain they did so on purpose and will continue to do so. However, to be charitable to googlers offended by the memo:

If the author asserted in the memo that Google practices discriminatory hiring practices ("Hiring practices which can effectively lower the bar for “diversity” candidates by decreasing the false negative rate" is the only relevant language I encountered), wouldn't that imply that some members of Group X currently employed at Google are less qualified than the members of Group Y who were discriminated against? Otherwise it would seem we are discussing a situation where tiebreaks tend to be decided in favor of the current minority group, or recruitment efforts for underrepresented groups are more intensive. The "lower the bar" phrase would seem to imply that he believes there are different standards in effect for selecting current employees.

The memo author's point about differing interest distributions does not necessarily imply anything about ability differences in the current Google employee pool, but claiming discriminatory hiring practices might.


I can't speak to consultants, but as an experienced conference speaker I can tell you that it vastly improves my employability.

I cannot stress enough how much some modicum of "fame" in a community greases the wheels of employment. You don't need to be at the Guido van Rossum level of famous to get this benefit: just being known and respected by enough of the "right people" helps enormously.

Software engineers often underestimate how much of our industry is built on "who respects you". If respected people trust you to know what you're talking about and to do good work, it makes it much easier to find good jobs and get well paid.

(For those who hate public speaking, similar benefits accrue to those who write great blogs or notable, innovative OSS projects.)


> It's the same as if you blamed the TLS/SSL RFC for being responsible for the heartbleed bug in OpenSSL - It makes no sense.

It makes some sense.

Features are attack surface. Each extra feature or option your protocol enables is more code you need to manage. So careful decisions need to be made: just because you can easily specify a feature for many use-cases in your protocol doesn't mean you should, because once you spec it people might just use it.

For heartbleed, for example, why was the TLS Heartbeat extension ever specified for TLS over reliable protocols? It serves no purpose: TCP has TCP_KEEPALIVE if that's a thing you need. But it was specified, and because it was specified it was implemented, and then it became attack surface that needed to be protected. It wasn't. So I guarantee to you that if RFC 6520 had been more restricted in scope, the Heartbleed attack would not have happened (or would have been a much more minor story, I can't remember if Heartbleed affected only the TLS and not the DTLS implementation).


It's worth noting that the iOS and macOS keychains are very different. In fact, if you check the design docs you'll find they share only four functions between them. Essentially, as far as I could tell, the iOS keychain participates in the sandboxing of apps, while the macOS one does not.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: