I'm not arguing that there aren't problems here, just that I think people have different expectations that are a little extreme. The libc implementation is a core part of the operating system, if you want to target that OS you should target that libc. Some distros (alpine) prefer musl libc, most prefer glibc. And distros really are different operating systems.

Not really, though. glibc uses symbol versions that are forward but not backward compatible. If you got an error that said "this program was built for a newer version of " would you say the same thing?

Note this is the same (if not worse) on MacOS, and on windows you used to distribute the CRT with your application just to deal with the same problem.

Even when it comes to manufacturing the tooling/testing infrastructure, it's just a question of money aiui.

That article is two years out of date, and looking at nationwide electricity usage doesn't account for the local impacts of these data centers.

(* nb4 "it's summer": talking about price per kWhr)

But that discards my point, which is that you should probably have been prevented from pushing all those to github unless you were paying them for it, but you weren't because the executives running github can't admit that AI is bad for their platform.

People should really use the individual optimization flags they want (no signed zeros, no trapping math, associative math, reciprocal math) and not -ffast-math because the other optimizations it enables leads to surprising code (for example, isinf and isnan may become noops, which will break production code).

Basically never use an optimization flag that changes the semantics of your code without understanding exactly what that means. I have had to fix this in a number of codebases because someone thought that flag was as innocuous as -O3.

And if you have to enable flush to zero/denormals are zero it should be explicit in your code and scoped.

The relevant text doesn't call it an "algorithmic feed" for what it's worth. They define an "addictive" feed and it's essentially any kind of personalized recommendation.

> "Addictive feed" means a website, online service, online application, or mobile application, or a portion thereof, in which multiple pieces of media generated or shared by users of a website, online service, online application, or mobile application, either concurrently or sequentially, are recommended, selected, or prioritized for display to a user based, in whole or in part, on information associated with the user or the user's device, unless any of the following conditions are met.

Their customers are musicians. They want to hear what the strings sound like in a demo. What they did was not just dishonest, it's contrary to literally everything their customers do.

Whoever did it has no sense and shouldn't be working in that business. Full stop.

I say this as a D'Addario customer of 20+ years that will never buy their strings again.

I don't disagree that it's obvious they've got problems but I'm just saying it's obvious to me the part that falls over (the scheduling of jobs) and why that would impact self hosted runners, which do no scheduling but depend on it to function.

As for 'just a message queue with some database updates and sharding that's easy to reason about'... Here's a job scheduling problem as an example: imagine you schedule a job, and there's no runner available. How do you disambiguate between no runners available because you've reached capacity, runners not being available because they're on a real network with faulty connections, and runners not being available because of a faulty rollout of internal updates?

A simple message queue for job scheduling is fine if you own everything and can deal with the operational overhead of identifying those cases by hand, but Github can't do that.

If the scheduling was self hosted it would be inexcusable but you can always just connect whatever you want to webhooks.