I don't care about service at a gas station - I want to fill my tank, pay, and get out. It's different when I take it to the mechanic - it's a rather old car, and I appreciate them talking intelligently about what the options are and what repairs they would suggest.

In addition, "non-native" English speakers in India (and Nigeria?) typically study English from the first grade, and in many cases attended elementary schools where English was the language of instruction.

I think the differences between US English and both Indian and Nigerian English have more to do with divergent evolution of the educational systems. British English has a lot of differences, too, but we don't notice it as much unless we run across things like "whilst", probably because there's more media crossover. (if you find yourself reading Thomas the Tank Engine to kids it jumps out at you, though - the entire vocabulary for railroads evolved during a period when US and British English were diverging)

In section 2, 34% of cases are found to have "substantive" disagreements differing by 2 or more buckets - True + Misleading, Mostly True + False, or True + False.

This is probably a better measure than the headline one. It's still a concerning fraction, although some fraction is no doubt due to forcing "I don't know" cases to return an answer anyway.

It's quite interesting - this isn't ethernet as we know it. Instead of each NIC using its own free-running clock, all the physical layers are sync'ed to each other at layer 1. (note that gigabit ethernet, which is what it uses, sends data at all times - when idle it sends the idle symbol)

It's a gambler's ruin problem. Future profits are worth zero if you go out of business first.

"The reason why RAM has become four times more expensive is that a huge amount of RAM that has not yet been produced was purchased with non-existent money to be installed in GPUs that also have not yet been produced, in order to place them in data centers that have not yet been built, powered by infrastructure that may never appear, to satisfy demand that does not actually exist and to obtain profit that is mathematically impossible."

Almost certainly crap.

As the author states, it's a simple fork-on-request server, which was state-of-the-art in about 1996. But that's not the point.

https://www.usenix.org/legacy/event/hotos11/tech/final_files...

It has a very good approximation for seek time based on the track radius delta, with experimental validation on a modern drive.

My only experience with Veracrypt is via a law firm I was consulting with, who used it to protect some files they were sharing with me. Law firm and their end client are both big, prestigious companies.

IIRC these came out in the early-mid 90s; a bike messenger trick at the time was to fasten the horn to your handlebars with velcro, so you could take it off and hold it near a car window when triggering it.

You dismissed the standard lock-guarded data structure as a "bogus comparison", despite it being the way every programmer is taught to write multi-threaded code.

Now the more you write, the more you seem to make the case that (a) normal programmers shouldn't be writing code like this, and (b) there are significant speedups possible if someone who knows what they're doing *does* write a highly tuned lock-free library.

It's precisely the way we teach people how to build thread-safe systems. And we teach them to do it that way because we've learned from experience that letting them code up their own custom synchronization primitives leads to immense woe and suffering.

(and it's not slow because of the C++ mutex implementation, either - I tested a C/pthreads version, and it was the same speed as the C++ version)

The whole point of lock-free data structures and algorithms is that sometimes you can do better by using these atomic operations inside your own code, rather than using a one-size-fits-all mutex based on those same atomic operations.

(Note that I say "sometimes". Too many people believe that lock-free structures are always faster; as always, your mileage may vary. In this case it's a huge win, to the point where I would bet it almost always moves the bottleneck to the code actually using the ring buffer.)

Most scientific research represents about the same amount of improvement over the state of the art as the shitty web app or whatever that you're working on right now. It's not zero, but very few are going to be groundbreaking. And since the rules are that we all have to publish papers[*], the scientific literature (at least in my field, CS) looks less like a carefully curated library of works by geniuses, and more like an Amazon or Etsy marketplace of ideas, where most are crappy.

[* just like software engineers have to write code, even if the product ends up being shitty or ultimately gets canceled]

Neither of us are going to be changing how the system works, so my advice is to deal with it.

I'll add that the reaction of most of academia will be "It's in a management journal - of course it's nonsense."

But what about availability? If you ask most of our users whether they’d prefer 4 9s of availability or 10% more money to spend on CPUs, they choose the CPUs. We asked them.

There are a lot of availability-insensitive workloads in the commercial world, as well, like AI training. What matters in those cases is how much computing you get done by the end of the month, and for a fixed budget a UPS reduces this number.