VorpalWay

Yeah, a funny thing with leaded solder being forbidden these days is that it isn't really about dangers when soldering with it, the issue is when it ends up in a garbage dump and leaches out.

The reason you still need fume extraction when soldering is the flux, those fumes are quite nasty to inhale. (How nasty varies based on the specific formulation, I recommend using proper ventilation for all of it though.)

(For those who don't know, the flux is there to prevent/clean oxidation and make the solder flow onto the metal pads and pins. Most solder wire contain a core of flux and you can also add additional flux if needed, usually liquid or a paste that melts into a liquid.)

Recent downloads per day show the opposite trend, with 2500k vs 1600k per day (with zlib-rs leading). The issue is zlib-rs is far younger so looking at total downloads is nonsense. And there is inertia to switch over as well.

Zlib-rs is several years newer, of course it has fewer downloads. Looking at recent downloads per day zlib-rs easily leads (2,500,000 vs 1,600,000)

The term you are looking for is viscosity. Water has higher viscosity than air. Honey and syrup even higher still. It basically describes how "thick" the medium is, or to be a bit more precise, how much it resists forces applied to it.

Honestly, why would we need anything except LE for TLS certs? Sure, they don't issue EV certs, but isn't that completely dead by now anyway?

You could argue single point of failure, which is fair, so then set up another LE clone which is run in a similar way in another (reasonable) country.

(And there is of course non TLS certs, such as code signing and S/MIME, if that is still a thing. I'm only arguing about the TLS case here.)

You could store the public key for each website in DNS. But now you moved the trust problem to DNSSEC. So far I haven't heard about issues like this for DNSSEC, but then again it is not a massive target currently.

It baffles me that software on Linux/Windows/MacOS doesn't just use the system certificate store, then it would just be a single place to update. Instead we need to be update pip, UV, node, etc separately.

I can see the case on phones: the OS may no longer be supported by the vendor, so browsers shipping their own set makes sense. And on embedded there isn't (and on IOT there might not be) an OS, but then you should probably just ship the the single CA that you use, not all of them.

Link is broken, gives some randomly generated text when using Brave on Android. Their AI bot detection is not very good.

> Has your “real” computer never had a bug or regresssion?

Sure, but the question is how limited you are in what you can do about it. iDevices are incredibly locked down. On my laptop I would just use the package manager to downgrade a package until it is fixed, or restore a backup. Or you could just fix the code yourself (or ask an AI for help to do so these days).

Even Windows has system restore to roll back to a previous OS version iirc (though it has been many years since I used windows last, going to all Linux has been so good). Not sure if that is possible on an iPad? I know Android doesn't really let you downgrade either the OS or an individual app, I would assume it is similar on iOS.

I believe they have used OSM for a long time yes (over a decade at least), not exactly a secret.

Is github built out of a house of cards? How does this stuff keep happening?

Rust is specifically designed to ensure that safe code can never trigger UB (barring compiler bugs, or bugs in unsafe code blocks). For that, protecting against races is necessary (at least when using LLVM as a backend, and when using the C++ memory model).

In practice rust also tries to guide you towards patterns that reduces the risk of other bugs. For example, using Result, Option (and enums in general) reduces the risk that you forget to handle error paths. It is also quite hard to get memory leaks unintentionally in Rust, since by default you work with various smart pointers.

In my experience typical multi-threaded C++ has a lot of threading bugs that tend to cause hard to reproduce bugs (I work in safety critical hard realtime robotics / machine control, where we have a lot of communicating threads). When I code Rust I can trust the language to prevent those classes of bugs, letting me focus on the actual hard domain specific problems, rather than language minutiae. Yes, TSAN helps in C++, but that is dynamic analysis so it has to actually catch the potential problem happening while running.

So I think that the multithreading approach in Rust is really good and what we want, not a hindrance. It is absolutely the right thing to do.

Now, the async story is another matter and I have conflicting opinions on how that is done in rust. I can't think of a significantly better design that would work on microcontrollers / no-std though. I'm not interested in anything that requires allocations or a runtime.