Quite possibly they would have been better off staying purely postgres but with sharing. But impossible to know.

6 days actually seems like a long time for this situation!

But in practice C, Rust and Fortran are not really distinguishable on their own in larger projects. In larger projects things like data structures and libraries are going to dominate over slightly different compiler optimizations. This is usually Rust's `std` vs `libc` type stuff or whatever foundational libraries you pull in.

For most practical Rust, C, C++, Fortran and Zig have about the same performance. Then there is a notable jump to things like Go, C# and Java.

At this level of abstraction you'll probably see on average an effect based on how easy it is to access/use better data structures and algorithms.

Both the ease of access to those (whether the language supports generics, how easy it is to use libraries/dependencies), and whether the population of algorithms and data structures available are up to date, or decades old, would have an impact.

A "SIM" should just be a keypair. The subscriber use it to access the network.

So it’s more like: which network to connect to, keys, fallback network selection logic and tunnel logic to get authorisation on a non-home network

IIUC if the keypair was a certificate with a few other fields foreign networks could give you some basic communication with your provider and decided if you should be allowed to use this network and if/how to tunnel you back to the home network.

But the main point is that it should just be data that the user can port around to different devices as they see fit and that they can trust not to do malicious things.

It’s effectively multi-hop peer discovery and I don’t think you can encode the general case logic for it as just config.

Edit: as a (rather niche) example, FirstNet sims run a different applet to AT&T sims despite nominal running on the same network because they have special logic to use more networks if they are in an emergency area.

The apps are still on the VM.

It's not. For semantic purposes <my-element> is the same as <div class=my-element>. So on the surface they are equivalent.

But if you are in the habit of using custom elements then you will likely continue to use them even when a more useful element is available so <my-aside> rather than <aside class=my-aside> so in practice it is probably worse even if theoretically identical.

Basically divs with classes provide no semantic information but create a good pattern for using semantic elements when they fit. Using custom elements provides no semantic information and makes using semantic elements look different and unusual.

This article is written for web developers. I’m not sure who you think you are addressing with this comment.

In any case - the argument is a weak one. To the extent people make the mistake you allege they can make it with classed div and span tags as well and I’ve seen this in practice.

You could say the same about divs. I’ve seen pages where everything is a div. No paragraphs, no headings, no tables, no lists, just divs.

My point is that if you are using <div class=my-element> you don't have to change your .my-element CSS selector or JS selection code to improve your code to <p class=my-element>. If you are using <my-element> it is much more work to change your selectors and now you have two ways of doing things depending on if you are using a native semantic element or a div (either a tag selector or class selector). You have made your styling code depend on your element choice which makes it harder to change.

But semantic purposes are not all possible purposes.

So it was used primarily like a desktop, and as my only system having power was useful. But the fact that I could put it in my backpack and transport it was super valuable.

Now I do have a more portable laptop and a full desktop setup. But at the time that wasn't the best option.

I work at Obscura VPN and faced with boringtun bugs a few years ago we evaluated a few of the forks and switched our client to be based on top of NepTUN (https://github.com/NordSecurity/NepTUN).

I am curious why Mullvad started their own fork rather than building on top of one of the existing ones. It would be nice if there could be reconsolidation somewhere.

I'm not sure that is necessary a bad reason. You need to factor in a lot of concerns to determine what "too expensive" means.

But if you are going to spend billions of dollars to develop a drug that only treats about 2 people a year it is likely too expensive even if it is 100% effective. That money would be better spent on treatments that have wider applicability.

Of course this is not simple to measure. Costs aren't known upfront and the research may end up proving invaluable to more widely applicable treatments.

So it is a judgment call and not necessarily a bad reason.

In other cases it's a bad reason for failure: it's also incredibly expensive to prove your drug works even if it does work for a lot of people.

That's bad! It'd be better if it were cheaper.

Actually counterintuitively, due to a weird drug approval and payor reimbursement policy arbitrage, pharma companies are highly incentivized to produce drugs for tiny populations.

One of my hobby horses is railing against this specific dynamic.

IIRC AV1 decoding hardware started shipping within a year of the bitstream being finalized. (Encoding took quite a bit longer but that is pretty reasonable)

Yeah, that's... sparse uptake. A few smart TV SOCs have it, but aside from Intel it seems that none of the major computer or mobile vendors are bothering. AV2 next it is then!