> The internet is still needed for delivering legal streams of matches. So there’s never going to be any pressure to turn off the entire internet.

Cloudflare serves a whole bunch of legal and genuinely important services, and yet there was enough pressure to block them off.

…and that was already enough to get Congress to review the situation. The first paragraph in the article we are discussing says:

> The complaints about the massive fall of web pages caused by LaLiga's fight against piracy reached Congress months ago. And the Chamber is now preparing to take measures.

But even ignoring the fact that TFA directly disproves your and the GP's argument, the point you're making that "x got approved so y also will" isn't how things work in the real world. People do have a pain threshold and just because CloudFlare was tolerated until now doesn't mean greater blockages would have been equally tolerated.

The Cloudflare block has been in effect since December 2024, so it's been in effect almost a year and a half, and Congress is at the "will act", not "has acted" stage.

And yes, of course you're right, that people have a pain threshold, but it's also true that people will normalise behaviour over time. I'm not saying further blockages will happen, just that I don't take it for granted that they won't.

Nobody was claiming that future blockages couldn’t happen.

The argument I was disagreeing with was the statement that “a total internet block is the logical conclusion”

Which it isn’t. But, and as I said in my comment you claimed to disagree with, that doesn’t mean things can’t still get worse.

Not that I need to tell you of all people, but I do find that Rust's editions system is one of the better ways to minimise this issue.

Indeed, editions are brilliant for making relatively large changes in a way that fully preserves backwards compatibility for codebases in the wild, but the existence of editions doesn't mean that Rust is exempt from sometimes desiring to make minor breaking changes in new versions for all editions. For that, it has the mechanism of future incompatibility lints, to give people ample advance warning: https://doc.rust-lang.org/rustc/lints/index.html#future-inco...

> you're much better off browsing r/fanfiction.

The punchline is buried a little bit too deep, but pretty sure they're just playing along.

I thought "when they made the decision to include human adult content in addition to fan-related content" in the first sentence was already pretty obvious

A less cynical explanation is that it helps decouple product failures from support failures. Last thing you want is for your customer support to break whenever your product breaks.

Good idea, too! Why do you see my explanation as cynical, though?

Your explanation is literally "blame somebody else, shift responsibility". It's a pretty straightforward case of assuming bad intentions.

Obviously, I don't know for a fact what Anthropic's motivations are, but I don't believe I'm being overly optimistic because I know for a fact that "use a third party as a way to de-risk" is a tried and true strategy. E.g. when I was at Facebook, all regular day-to-day comms were on Workplace, but they kept an IRC server hosted by some vendor or other, specifically to coordinate responses for serious SEVs that disrupted the normal channels.

Of course, an even simpler explanation is that they perceive building their own support harness as just low value work for engineers who could be working on their core product instead, and the cost of buying that service from somebody else is probably a drop in the ocean.

A cynic is what an optimist calls a realist.

The issue with C is that every single use of a pointer needs to come with safety invariants (at its most basic: when you a pass a pointer to my function, do I. take ownership of your pointer or not?). You cannot legitimately expect people to be that alert 100% of the time.

Inversely, you can write whole applications in rust without ever touching `unsafe` directly, so that keyword by itself signals the need for attention (both to the programmer and the reviewer or auditor). An unsafe block without a safety comment next to it is a very easy red flag to catch.

>when you a pass a pointer to my function, do I take ownership of your pointer or not?

It's honestly frustrating how prevalent this is in C, and the docs don't even tell you this, and if you guess it does take ownership and make a copy for it and you were wrong, now you just leaked memory, or if you guessed the other way now you have the potential to double-free it, use after free, or have it mutated behind your back.

You can't (in theory) get a warrant "just because", you need to state the grounds for the search in your application for a warrant.

If this was a "your company" problem, it would sort itself out soon enough. The real concern is that it might a "your industry" problem.

Had one of those happen in high school — science teacher talking about colour blindness and shows students the colour blindness tests, one student assumes he’s being trolled and that one of the test images was a solid colour.

It's specifically aimed at Framework, though, not PCs in general.

Framework is very much a premium brand (where the premium experience is centred on repairability/upgradeability), and don't have the economies of scale Apple do. It's natural that they'd end up being more expensive.

> not PCs in general

Yeah, I’m assuming just the one of the various tiers here that’s in the same bucket as MacBooks, and that we’re generally talking devices that are specialty-capable; such as media production or Linux development or gaming or what have you. If you lump the entire “portable screen bigger than nine? inches and with an in-box physical keyboard and pointer controller” market together, you’ll disregard ‘glorified word processors’ that cost a couple hundred bucks (before the RAM underproduction grift) in their own specialty niche. Framework isn’t competing there, right? (I could have missed something..)