VorpalWay
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.)
But if you are talking TVs specifically, I expect they will get back to that too.
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/
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.)
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.
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.
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.
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.
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.
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).
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.
(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.)
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.
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.
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.
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...
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.
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.
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.