Yeah and then we could have called it xhtml5. Too bad that does not exist. Oh wait https://html.spec.whatwg.org/multipage/xhtml.html

> But the anti-XML sentiment was explicit and spiteful.

No, xhtml was just a bad idea creating tons of problems and solving none.

Seems like he’s giving a ballpark of 150 here.

We in fact have high confidence that it’s not true. Google started leap smearing back in 2008 because so much broke on leap seconds.

Honestly I’d think a negative leap second would have way higher chances of just working than positive: a positive leap second causes a UTC minute to have a 61st second, and a unix timestamp to repeat. That is a highly rare condition and plays complete havoc on software which does not specifically support these.

A negative leap just means jumping a second, this is already relatively routine due to scheduling and suspends, your program can do one thing and then 20 minutes occur before the next, because right then the user closed their laptop lid.

… good? I want my applications to be consistent with the platform they run on, not with their own stupidity on other platforms.

That they’ve failed miserably has been one of the few good news since.

Not that that would make any difference, theorem provers can also have bugs. Famously this summer someone “disproved” the collatz conjecture by exploiting a soundness bug in Lean.

The problem is that commuting is not the only thing people do, and not everyone has the space or finances to have multiple cars.

Short term rentals are an option sometimes but I can understand how having a car and renting one feels like a waste of money, and is hardly an amazing experience both intrinsically and in terms of freedom and spontaneity (I live without a personal car and rent one once in a while as needed).

Well to the extent that git is able to find a suitable delta, which is the difficult part.

You can configure loose object and pack compression separately (core.compression and pack.compression) so loose object compression could be switched to an other algorithm as it's completely local[1] (likely a low-compression zstd), but pack files are part of the network exchange, so things are a bit more complicated there. Also an annoyance there is that git uses raw zlib there is no identifying header or anything.

There are old threads on the mailing list, as well as a gitlab issue.

Although you can also tune compression per pack when you create them explicitly, on $DAYJOB's repository in order to speed up gc some I have .keep packs which segregate images uncompressed in their own packs, because there's little point wasting cycles on zlib-compressing jpegs and pngs.

[1]: unless you're using the "dumb http" protocol, or performing (n)fs-mediated clones

Because currently abi3t is only relevant for 3.15, its value is future-proofing artefacts for 3.16 and beyond, you need two free threaded wheels at least (3.14t and abi3t).

    if v.is_none() {
        return 0;
    }
    v.unwrap()

That is the main reason inlining is so fundamental to modern optimizing compilers, it’s nice that it removes funcall overhead, but it’s more relevant that it unlocks a whole slew of further optimization opportunities (including even more inlining).