Yeah, looks pretty straightforward to me, but I used to write C++ for a living. I mean, there are complicated cases in C++ starting with C++11, this one is not really one of them. Just init the fields to false. Most of these cases is just C++ trying to bring in new features without breaking legacy code, it has become pretty difficult to keep up with it all.
Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
If that's their plan, I predict another situation exactly like this one where Google decides that removing support is the best move forward. Careful, BMP, Chrome is out to get you!
This actually seems to use the encoder/decoder from the Rust image crate (1), which would bring the opportunity for more memory safe formats once BMP would be accepted.
> Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.
At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.
Well, the first public implementation dates to 2020. And, the Cpp choice is obvious, simpler integration with the majority of existing image processing libs, tools and utilities. Not to mention GUI toolkits.
Nonetheless, we should really bear in mind how entrenched Cpp is. If you normalize CVEs by language popularity Java looks downright dangerous!
No new code goes in that violates the rule, and ideally no code at all goes in that is both unsafe and parses untrusted data (regardless of sandboxing) and old code doing both gets replaced.
A giant pile of C++ can be used for rendering, not parsing untrusted data. A giant pile of C++ can sit behind a validator: a memory-safe JSON validator can vet a stream, before an C++ library deserializes it. Etc.
Mozilla's position for some time now has been, "we aren't opposed to shipping JXL support, but we'd want to ship a decent implementation in a memory safe language, not the reference C++ implementation". That position hasn't been met with very much criticism.
Google's position, on the other hand, has been a flat-out "no, we will not ship JXL". That's what has been met with criticism. Not an imagined reluctance to shipping a C++ JXL implementation.
It's Google, it's one of the biggest tech companies in the world making boatloads of money, in part off their browser. They're currently best known as one of the companies trying to create AI God. They really can't write an... image format parser?
I actually wanted to try webtop for a long time, and did it only recently. I could not figure out these selkies for the life of me. It wanted a bunch of ports, was complaining about something all the time (don't remember, it's been a month). Might be a skill issue, but I've been using docker for the past 10 years.
Moreover they want root access to the host system, which kind of defies one of the reasons to use containers. Is there a video that explains the benefits in a good way? I mean, if it's for gaming only, I can understand the use-case, but say you just want to run something like Gnu Radio in a container, why would I need 60 fps and root permissions for that.
Sentry consumes around 200W on Intel Atom and camera based detection enabled. I'd say it's a total overkill. It even heats up the display pretty good when it's relatively chilly outside.
> A plugged well is injected with high pressure concrete to/past the impermeable rock layers, past the multiple steel/concrete well casings that travels through aquifers.
Now imagine having hundreds of old oil wells around, some of them are rusted out and can totally transfer fluids up from down under to the water table level.
They probably need to inspect every well and make sure it's properly plugged with concrete, not just a cap on top.
> They probably need to inspect every well and make sure it's properly plugged with concrete, not just a cap on top.
This is the real take-away here. Not some narrative that fracking is definitely bad (it might be, might not be), but that The TXRRC needs to be more on top of continuing to monitor and/or plug wells before these things happen.
^ 100% the point! Thank you! ffs fracking has nothing to do with it!
Plugged wells are safe for eternity. In fact, nature does this (look up Devils Tower monument) on it's own.
Capped wells are kept around... because they might come in handy for salt water injection. They need to be permanently killed at the end of their lives with high pressure concrete.
It's just dumb this practice is even allowed to take fluids from one formation and put them in another. But hey, as long as "BAN FRACKING" is the headline both the oil burning companies and the regulators will succeed in doing nothing to prevent environmental damage.
Great work!
Why does autopilot stop around 12 min mark?
UPD: I see that it cannot load an mp3 file, net cache operation not supported. I reloaded / cleaned my cache, maybe you regenerated the sounds and I just had stale cache.
Personally, I've seen JPEG XL source code and I'd rather not have it in my production, unless it's rewritten or at least security audited / Google fuzz-tested. It's a bit of a mess (the last time I checked was 6 months ago)
