chimeracoder

> SRE was always a lame job description and so was the entire "DevOps" movement we had to suffer through during ZIRP. Real ones are oncall for the systems they build.

You're conflating a whole lot of different models here. In fact, "developers should be on call for the systems they build" is a principle that most schools of DevOps thought emphatically subscribe to.

If that's what you think the "spirit and reasonable implications" are, then you didn't understand what I said.

> Are you serious? Just the hardware build Google did for Youtube alone. They 1000x (not %, times) their backbone bandwidth and they're still increasing it. Youtube used to have 2 small datacenters where they were acquired. Now it's 20% or so of half of the total Google DCs.

> That's nothing?

Either you replied to the wrong comment or you didn't read the comment you're replying to.

> Yes certainly if you discount the 20 years of development, the creator tools, the advertiser tools, monetizing creators, live streaming, completely rewriting the whole thing, etc. Google didn't develop YouTube much.

I never made that claim.

When YouTube was acquired by Google, it was already pretty similar in shape as a product to what it is now. The biggest differences are scale, the addition of advertising, and ancillary integration with other Google services. The first is a function of growth, the second is exactly what Google would be expected to do to monetize the service, and the third is another logical implication of "acquisition". (You could quibble and say they added vertical shorts and live video, but I don't think those are even fundamentally different from a product perspective from what YouTube was already doing in 2006, just fast-forwarded to adapt to the consumer technology we have today).

That's very different from Android, which was an unreleased prototype that had zero users and was dramatically different even from what ended up shipping as the first product, let alone what it is today. Android at acquisition would be unrecognizable from what the majority of people worldwide are typing on this very minute.

Have you looked at storage prices recently?

> Why haven’t they fixed Amazon Linux then? Same as none of their AMIs for bottlerocket have emSign revocations.

Last I checked, Amazon has also not patched their Lightsail blueprints for WordPress, or even communicated about the vulnerability with those customers at all, which is arguably way worse, because

(a) by design, all-in-one blueprints aren't really intended to use system PHP or have system PHP updated in a meaningful way; and

(b) hosting static sites such as WordPress is 90% of the selling point of Lightsail as a product

And Lenovo was done after Superfish

No, those provided glitzy branding for the bug but the actual pages were pretty compact and information-centric.

His argument is that DNSSEC is fundamentally broken, and you can't fix it via incremental improvements.

He is not arguing that DNS security cannot or should not be improved; in fact, he explicitly states the exact opposite.

> Clickwrap licenses are generally held to be enforceable

Sort of. Depends on the jurisdiction, and it's not always the case. That's why this is likely to be one of the core topics litigated in this case.

Nobody on HN is going to know the answer here at this point.

> Violating a contract is illegal.

If you have entered into the contract and are even party to it in the first place, which is not clear in this case and is likely going to be one of the questions litigated here.

> Force hospitals to expose API's with transparent pricing.

Unless you're uninsured (which is a whole separate clusterfuck), the hospitals aren't the ones who decide how much you pay for any service - the insurance companies are. The sticker price that hospitals charge is almost meaningless and is intentionally high because it's used as the starting point for negotiations, which always bring the price down (never up). There isn't any expectation that any insurer is actually going to pay the billed amount as-is.

> But this went out of the window when some genius decided that usernames were too complicated, so Passkeys had to be discoverable, which means they have to be fully stored token-side. Which of course has the nice side benefit of essentially killing hardware tokens and forcing people into using their Android/iOS/Windows device for it.

This part of your comment is incorrect. Discoverable Webauthn absolutely can be used with hardware tokens like Yubikeys.

> See, that’s just flat-out lying. What’s this mythical circumstance where playing audio A at the same volume as audio B on one device will magically make A louder than Bon another?

Regarding your second point: as any audio engineer or electronic musician knows, the same exact audio absolutely will sound very different on different speakers, depending on how well they replicate various sounds, what level of gain is being applied, and the volume (which is different from gain, although people confuse the two).

That's even before you get into the fact that many modern devices, like smartphones, will apply their own compression or sound processing before playing the sound, sometimes to compensate for those deficiencies and make them less noticeable, and sometimes to "enhance" the sound.

Loudness/volume (technically different things but let's conflate them here) are also unintuitive because human ears don't have a flat frequency response curve, and some things will be perceived as louder despite being the same volume, or vice versa.

Advertisers actually can (and do) take advantage of this, by using sound engineering to make things feel louder while staying within the desired volume, by targeting the way humans perceive the sound.

This isn't a defense of the advertising/streaming companies here, because it is a solvable problem. But it is true that this is a problem that they need to solve.