repsilat

X doesn't support animated webp, slightly annoying.

Yes, the grandparent scored an own goal with their aside

>> The "free market" (which has been demonstrated to not be free at all)

The Berlin rental market suffers under strong government intervention, and would benefit from being much freer.

Yeah. It's worth looking at your own code and infrastructure as well. In my previous job there were dozens of opportunities to realise big savings by swapping out gzip for other compression schemes -- usually zstd, occasionally lz4 or bz2 or brotli. Huge assets took less hard drive space, took less time to download, and took less time to decompress. The differences were not small, and resulted in appreciable improvements both in infra cost and dev productivity.

Maybe that's the right approach, hard to say. No great harm making this kind of improvement if it isn't the globally best architectural direction.

> you have two options

There are many other ways to allocate capacity. For example, you could give preferential access to customers who sign long-term purchase commitments, or some other favourable terms. These other methods might correlate well with value to the seller and might be easier for buyers to pay.

Other methods could be "allocate to customers that you want to maintain a good relationship with." I suspect HBM is not allocated either with pure auctions or by lottery.

Faster is better than slower.

Postgres is amazing. When I use Sqlite I miss many of its upsides--better data migrations and better concurrency being two. But queries are not free, and sometimes are slower than I'd like even with the right indexes. And for OLAP-like queries like the one in TFA you might say "well, just don't use postgres for that," but wouldn't it be better if you could? If you could use one database instead of two, or use your favourite database in more places instead of reaching for a different tool?

> every few millennia

We'll feel awful silly having made any leap seconds if the robots kill us all in the next decade.

More seriously -- all of today's computers and probably all of today's software (not to mention many scientific and governmental institutions) will be gone in 500 years. Does it make sense to plan too far ahead?

I had an issue in a CI pipeline once where clocks on two different machines drifted out of sync, and it looked like an HTTP request went back in time (it had some validity from now until now plus some delta, and the second machine thought it arrived "before now"), validation failed, pipeline failed.

An unusual case, fragile design, but indicative of potential issues with more interesting timekeeping choices.

One way of thinking about ignoring leap seconds is that it's like letting the effective prime meridian drift east/west. And a "leap hour" is kind of like a timezone change. In fact, you could just not have a centralized/coordinated leap hour, and let individual jurisdictions change their own timezones as they wanted, if they wanted noon to be closer to the daily solar peak.

Occasionally in pure python "asymptotically reasonable, simple implementation, terrible memory locality" is the right pick for a data structure. You want to avoid an extra linear term, you don't care too much about the constant factor, and the cache doesn't really matter because the language is so slow that it's not really noticeable.

Not too common, but it happens.

I guess to expand on my earlier post, it's generally a good thing that these kinds of absurd allegations are counterproductive and generally not convincing, because if they were more readily believable they would be quite irresponsible. Real violence has occurred because of beliefs (and posts) like this.

This hyperbole does more to turn people away from Bluesky and other sites more than X to be honest. There are clearly lots of politically moderate, wholesome "politically inert," and international X users. The people who are vocal about having left seem more extreme and less tolerant to me.

Perhaps for related reasons, I've also recently heard Elon Musk being described as a "literal Nazi" a lot, and I'm sure that kind of wild rhetoric has a similar backfire effect with anyone who has any familiarity with him.

Yeah I guess a c++ programmer might say `std::array::operator[]` is a function (or method, whatever), just like `std::array::size` is. And that identifying the array with just one of those functions (or even the collection of all methods offered) is to miss the point -- not just contiguous indices, but contiguous storage. A red-black tree with added constraints is not an array.

TFA does allude to this. An "array indexing function" that just met the API could be implemented as an if-else chain, and would not be satisfactory.

I wonder if "the right solution" is a programming language that is fast, concise, trivially easy to run, and outputs some efficient binary format like protobuf.

Programming languages have comments and control flow, multiple popular implementations, and can have nice literals. Lack of Turing completeness is actually not a terribly useful feature if you trust the input (and you should probably just use protobufs or similar for untrusted inputs in that case.)

"Easier" is probably the right one-word generalization, but worth noting that there are quite different challenges. Stopping distance is substantially greater, so "dead halt" isn't as much of a panacea as it is in dense city environments. And you need to have good perception of things further away, especially in front of you, which affects the sensors you use.