olliej

The Supreme Court ruled already that there does not need to be a victim, or even any real people at all in its justification to permit refusal of service to lgbt people.

So I’m unsure why even if there were no victims that would be relevant.

To me the problem here is they might identify someone with a problem, but then send them to jail with essentially the same label as an actual pedofile or rapist, and prisons in the US exist as a source of slave labor and future criminals rather than any kind of rehab. So person goes in who is already clearly fucked up (not necessarily this case, assume some case where it’s clearly be demonstrated guilt or whatever) and then comes out with a pile of trauma and no employment prospects and it seems like a sure fire way to create an actual dangerous pedo/abuser.

I think a better equivalence would be the treatment of alcohol - alcoholics don’t go to jail immediately, not even when driving, it requires them failing to get the alcoholism treated, or actually harming people for them to end up in jail.

I mean there have already been people reported to police or having all accounts cancelled for the kind of images most families have of their children growing up.

This entirely ignores what happens when you have states classifying telling a child “it’s ok to be gay/trans” as child abuse, or even just being gay/trans as a sex crime - which plenty of states in the US have said that they want to do.

Typically the same states and people that actively support child abuse by banning actual sex ed, and normalizing child molestation.

Um, literally days after one drone flying idiot took out an actual fire fighting plane?

"Cool"

Are we going to require drone pilots to have insurance that covers all potential damage caused by their actions? if not this seems like another case of letting shitty people be shitty without consequences.

Again, DEI does not mean "hire less qualified people from group X", it mean "don't bias your hiring of less or equally competent candidates in favor of men". It is not "sexist/racist in the other direction" - though I'm sure some people can make it such - however, let's be clear here, if it _were_ racist/sexist in the other direction, and you want it to be removed, you're saying "both paths are sexist/racist and I just prefer the old sexist/racist path that gave an advantage to people who are straight, cis, white, and/or men". It's really not the most compelling argument to say "I just wish we got to benefit from the biases we used to have".

The problem is lots of people are use to a default world in which being a man, or being white, etc means that if all other things are equal they will be selected. They see anything other than choose the "equally performing" white dude by default as reverse racism.

Couple this with the well documented history of women and minorities being judged more critically for the same work, and you get the "non-racist" world where worse performing candidates are hired because they're "equal" and a better culture fit.

You can see the same thing retroactively: a woman or minority figure who subsequently performs below the level expected is blamed on "DEI", yet no one questions the hiring of a sub-performing non-minority. Weird right? lackluster minority employees only ever get their jobs because of DEI, lackluster non-minorities are just a thing that happens some times.

You're right, it would be great to not consider gender, race, etc - and certainly when I've interviewed people it has never figured into the process, but companies need to have some kind of mechanism to compensate for all the employees that do (you can happily find countless examples on HN of people openly admitting they consider women inferior devs, they dismiss certain races and castes, lgbt candidates, or people with the wrong religion. DEI programs exist so that those bigots can't pollute the entire recruitment process. Those are the bigots who complain most, yet seem completely unaware that they are the entire reason DEI programs are necessary. The moment you say "I don't think group X can do the job as group Y", you've immediately said there needs to be an external mechanism to mitigate the advantage you are giving to group Y.

That's what DEI is: a hamfisted, but sadly necessary, unless you have a better idea, mechanism to stop people from biasing the recruitment process.

Seriously.

If you think DEI is bad, I want you to think about every "bad" coworker you've had and see if there's any bias in what you blame for them being hired. If you look at the news today, everytime anything goes wrong, and there is a minority involved anywhere, even if they were objectively not at fault, the bigot circle jerk does nothing but blame DEI.

Lots of people want to go back to the "good old days", because they were immensely privileged in those days, you could get and stay married easier - because women could not have bank accounts, and were functionally owned by their family or husband. Remember a women could not divorce her husband for beating her, nor for raping her, because by definition spousal rape was impossible. So yeah, I understand why lots of men want to go back in time, life was objectively easier for them. Those men just don't give a shit about it being harder for literally every one else, which is why I don't give a shit about their opinion.

If you think DEI is the reason you can't get a job, maybe the problem is just that you're broadcasting "I'm a bigot" and no one wants to work with someone who is saying "I have no respect for my coworkers unless they're the same race, gender, religion, etc as me and will not treat them as people". Or of course, maybe it's just dunning-kreuger: you're too low skill to understand you're lower skill than the people being selected over you.

"Bay Area progressive politics" - you mean "don't bias your hiring in favor of male employees"? or do you mean "don't bias your hiring in favor of straight people?"

Maybe we should just go back to the days where we should just not hire black Americans or women into tech? Maybe go back to a time where only a few tech companies actually did that, and those that did then had to literally create there own banks, because even when a tech company did employ someone, and paid them the same amount as a white man, the banks would not let those employees get mortgages? Maybe go back to firing people because they're gay or trans?

Would that make you feel better?

Why is this flagged?

So it’s wage theft then? Gotta love the “disruptive” tech industry. Such innovation.

The privacy problems were catastrophic - the Google CDN fed directly into Google’s pervasive tracking infrastructure.

Most other CDNs similarly support tracking services.

As the article says the actual cost of partitioning is negligible, the cost of not partitioning is that nothing can prevent cross site tracking and invasion of privacy.

VPNs and extensions don’t work because the browser is ensuring your identity is constant. That’s why the large ad networks funded free/cheap CDNs.

Flying drones during wildfires is a violation of federal law for this exact reason, every one of these absolute cunts should be charged, they're posting the videos so can be traced.

These fuckers should have all their assets seized, and they should be left in prison until everyone else has recovered.

Filing a take down requires a sworn statement of good faith belief the claim is false, so this would appear to be perjury.

But … he didn’t found any of those companies?

doesn't include search?

I think my favorite introduction to just how insane the pipelines, predictors, and other insanity in "modern" (more than a decade ago now) was trying to improve `Math.sqrt()` performance in JSC. This was during the first generation of JIT JS engines (e.g. no one was inlining functions yet), and I was replacing the host implementation of Math.sqrt with a pure assembly version - essentially calling a host function was significantly more expensive another JS function - e.g. JIT JS function -> JIT JS function was significantly faster than JIT JS function -> host code (e.g. C/C++). As part of doing that I was going step by step through each instruction making sure it was the minimum overhead as each step, think something like (very approximate - again more than a decade ago):

  v0:
    1. if (input not a number)
       fallback to C++; else
    2. return tagged 0; // Just making sure the numeric check was optimal

  v1:
    1. As above
    2. If integer
       convert to float
    3. return tagged 0

  v2:
    1-2. as above
    3. If negative
       return tagged nan
    4. Return tagged 0

  v3:
    1-3. as above
    4. use the sqrt instruction
    5. return tagged 0

  v4.
    1-4. as above
    5. move <4> back to an integer register
    6. return tagged 0

  v5.
    1-5. as above
    6. tag the result of sqrt
    7. return tagged 0

  v6.
    1-6. as above
    7. Actually return/store the result of <6>

Alas I cannot recall whether at this point return values were going into the heap allocated VM call stack, or whether the return was via rax, but that's not the bit that was eye opening to me.

I had a benchmark that was something like

    for (var i = 0; i < large number; i++)
       Math.sqrt(i)

Noting that while I was working on this there was no meaningful control flow analysis, inlining, etc so this was an "effective" benchmark for perf work at the time - it would not be so today.

The performance remained "really good" (read fake) until the `v6` version that actually store/returned the result of the work. It was incredibly eye opening to see just how much code could be "executed" before the CPU actually ended up doing any work, and significantly impacted my approach to dealing with codegen in future.

My perspective at the time was "I know there's a significant marshaling cost to calling host code, and I know the hardware sqrt is _very_ fast", so it seemed that it was possible that a 5-10x perf improvement seemed "plausible" to me at the time (because marshaling was legitimately very expensive) - and I can't recall where in the 5-10x range the perf improvement was - but then once the final store/return was done it dropped in perf to only 2x faster. Which was still a big win, but also seeing just how much work the CPU could just avoid doing while trying to build out the code was a significant learning experience.

So there are multiple factors here - I used to work on browsers so have some experience here :D

First off, there are legitimate security concerns with the kind of functionality required for effective ad blocking given the immense work the ad industry (i.e google) have put into preventing purely static filters is also very powerful for exploitation. Those powers can (and have been) abused: the recent news about "Honey" replacing affiliate links so that they are getting paid for ads on peoples page, but also there have been numerous examples over the last year of extensions being sold and then having the extensions getting malware, crypto miners, etc.

Second, there are real performance problems - the non-JS filter rules are vastly more efficient, for memory usage, cpu usage, and load time (I recall people doing benchmarks a while ago, showing ad blocker extensions that actually slowed down page loads).

So those are the engineering arguments for not supporting this model of extension.

However, the engineers on the chrome team are not stupid, or malicious, and understand that the trade offs are something users want. But those engineers work for Google, and google is an advertising company.

So it does not matter what those engineers want, or think is better, if the company management says "you cannot block our revenue model" they do not have a choice. Well, they could quit, but that's basically it.