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)

A video on vulnerabilities in Asus routers was released yesterday: https://youtube.com/watch?v=kYnwCx2SNYY

But if you are talking TVs specifically, I expect they will get back to that too.

> lean-zip beats every single compression level miniz_oxide

Miniz_oxide is an intentionally simple implementation. It would be more fair to compare it to the newer zlib-rs[1], which even beats zlib-ng (fastest implementation in C)[2].

[1]: https://lib.rs/crates/zlib-rs

[2]: https://trifectatech.org/blog/zlib-rs-is-faster-than-c/

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.

You can easily get memory safety issues with any concurrency though. Since this is a property of the the raw underlying hardware model of concurrency you can't work around it. See https://www.ralfj.de/blog/2025/07/24/memory-safety.html for an example of this is Go.

As soon as you have something larger than the hardware atomic size (or unaligned in memory) you risk torn reads/writes. So a pointer + a size for example on some architectures (some hardware like x86 has a double word atomic support, but on embedded you usually only get up to word size atomics).

All this means that you can't (in a systems level language) feasibly make everything atomic and ensure no UB.

All that said, do I wish Rust did more for other concurrency bugs? Yes, sure. Though there is some hope: I have seen Rust crates to enforce lock ordering at compile time (I think that originally came out of the Fuchsia OS kernel development). There is also scoped threads, rayon, actor frameworks etc. All different approaches to strucured concurrency, with the goal of reducing bugs. Different frameworks seem to suit different problems though. For what I do I rarely need mutexes, instead either rayon or message passing work well.

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.

Concurrency issues (such as torn writes) can easily cause out of bounds and similar UB on other threads, so focusing on races is not arbitrary if you want to be a systems level language.

Sure, you could pay the overhead of a managed language and have the runtime handle synchronization behind your back, but that isn't the path Rust went down.

As someone who worked professionally with both C++ and Rust, I mostly agree with this, but I would say that writing the concurrent code in C++ is also hard.

The only way I found that works reliably is stick to a small well defined set of mostly safe primitives. E.g. at work we use message passing / event bus architecture everywhere, which works great for a robotics / industrial context. But even then, if you somehow mess up and have a variable accessed from event handlers in two different threads, it is tough to spot other than if you get lucky and observe it with a build using TSAN.

With rust that class of mistakes is just entirely eliminated, which makes it easier to to concentrate on the hard things that actually matter (like the domain specific logic).

Worth adding to this: there may also be code needed in the rust part (not just the llvm part) to enable support for a target triplet. There certainly will be for the OS and libc part of the triplet: what specific syscalls exist and should be used to implement the standard library on a particular flavour of BSD etc.

But even for the architecture part there can be differences. For example, my understanding is that a lot of the calling convention details need to be handled by the frontend in LLVM, leading rustc to duplicate logic from clang here. Things like varargs FFI with C code can be particularly gnarly.

LLVM is the default yes, there is also an experimental cranelift backend, which is all Rust. Not sure if it is good enough to build the compiler itself using it.

(There is also a GCC backend called codegen_gcc that is pretty far along. And a separate reimplementation of both the frontend and backend using gcc and C++, called gccrs, which is not nearly as far along.)

You could use https://github.com/thepowersgang/mrustc to get relatively modern Rust compiler (1.90 currently apparently, but every now and then that is updated). Then build newer rustc from there to reach the current 1.99.

But I don't get why some people are obsessed with bootstrapping. Yes it is good to be able to do it, but it isn't something you need to do regularly.

Especially since rust had a much better cross compilation story than C or C++ (not as good as go or zig though), so you don't need to bootstrap on a new architecture, just cross compile to it. Furthermore, new architectures for hosting a compiler (as opposed to just a target, like microcontrollers) is a rare event. Just something that happens every few years.

Ah, that is interesting. I found it a bit too confusing puzzle-wise. But I only played it years later, so I don't have the nostalgia. Which suggests that nostalgia probably is a big part of why I still enjoy Myst.

That is a big maybe though. It is very experimental (didn't even have non-placeholder syntax last I looked), and as far as I know nobody has yet even discussed it for floats.

Not yet that I know of, though perhaps LLVM might be able to infer simple cases (when loading from a known constant for example).

Pattern types could potentially maybe in the future allow for the compiler to know more details though. They are a nightly feature, and afaik only for enums, integers and pointers so far. The idea would be that you can define a custom type such as "an integer between 7 and 45" and everything else become niches for niche optimisation (e.g. for `Option<MyFunkyInt>` some of those impossible values would be used to represent the None case of the wrapping Option).

But I could envisage a future in which you could say "f64 without NaN" which would both make those available for niches and potentially tell LLVM about this. However, we are very far from any of that currently. And it might not be what you want, since you would need to add checks when you perform operations to ensure the value doesn't suddenly become a NaN. Which is way more complicated than ensuring integers don't become, say, zero. It will likely be much harder to optimise away the checks.

Last I checked (a few years ago admittedly) Gnome Tweaks only configured the fontconfig setting, not the ini setting to make GTK4 programs care.

Also Gnome Tweaks is an add-on, not part of the default install on any Linux distro I have tried. In KDE Plasma this is in the standard settings.

And if you use any desktop environment other than GNOME, their preferences certainly won't set the GTK4 hidden ini setting. Rather they expect programs to follow best interoperability practises, such as respecting the fontconfig settings. Most people won't limit themselves to only first-party apps from their DE of choice, so interoperability is king.

Those tank controls are not great, and going to 3D made the graphics noticeably worse. It would have been a better game had it stayed 2D but with the same story. A lot of early 3D has aged poorly.

Yes the first 3 games are really good. But I also have a soft spot for Myst. Maybe it is nostalgia, but I really enjoyed replaying it from the original CD of the Mac release a few years ago (using my original iBook, which is slightly later vintage than the game of course).

Last I checked I couldn't set full hinting. And for GTK4 programs I even had to set a hidden variable in a ini file[1] to make it respect my fontconfig setting for hinting.

Apparently it is supposed to be on for low DPI screens. I would count mine as low DPI (even my laptop is only around 150 DPI) but I still need to set that manually.

So no, GTK didn't keep the font rendering settings I care about, and is actively hostile in trying to ignore them even.

[1]: https://wiki.archlinux.org/title/GTK#Text_in_GTK_4_applicati...

There may be differences between C and C++ here (and I worked with C++ more recently than C), but: if that enum doesn't specify an underlying type it would be UB to have a value that isn't in the "member list" of the enum. In that case it should be possible to determine if all cases are covered.

If an underlying type is specified, then it should error since it is legal to have those values (unless the whole range of the underlying type is covered by the cases.

Again, that is what would be sensible from a C++ perspective, I don't know if C differs here.

EDIT: Also, and now I'm talking with my Rust user hat on: it is better to not have pointless UB. Yes some is needed to practically allow for optimisation. But C and C++ had a lot of UB that doesn't really help with making your code faster, such as this.

Gnome 2 was really good for it's time. Gnome 3 is a dumbed down disaster, removing settings I care about (such as font antialiasing settings, which I need to change to not get literal headaches, subpixel AA is awful as is anything blurry).

And that is just the tip of the iceberg when it comes to Gnome. I went to Xfce, MATE and then Cinnamon for some years, but I'm now back on KDE and it been good for several years (I left KDE when KDE 4 came out and went to Gnome 2).

But each to their own, use what makes you happy. But Gnome has a history of messing with your desktop, KDE less so in recent years.

That or you hit some UB elsewhere that caused the compiler to assume things that you didn't follow.

Trying UBSAN and ASAN might have been worth it. I don't think comparing debug and release builds would have helped: could be buggy optimisations or UB in your code regardless of what the outcome of that test was.