https://validate.pics

Also related: I'm using LLM assistance to write it, but I also have a test suite that proves it's working (I call it the "shotgun" suite: given a good image file, it first flips a random bit ("sniper"), then a random byte ("boltgun") and then a random 4096 byte segment which is the typical sector size ("shotgun"); each time it tries to validate the file by decoding it fully, and records what percentage of time it is detected at each scope, and it collects statistics about this over hundreds of times.)

The point of it is to detect things like corrupt data and bitrot... across 240+ different filetypes so far... since no other tool really exists yet in this space to do that.

Note that some formats, notably Apple's HEIC, are so data-dense that corruption only results in undetectable image corruption (well, a human would notice it, but an algorithm cannot!) So I have ANOTHER app coming to help with that which does detection AND repair (to a point). ;)

The CLI will be free and open-source, but I'm also writing a for-sale-in-future private-source GUI for it.

Deploying and watching CI and looping until it passes.

I never thought I'd actually see an anti-joy argument being used in all seriousness, but welcome to 2026!

https://news.ycombinator.com/item?id=48413983

Thoughts on that, then?

What about using a sewing machine instead of hand-sewing?

Washing machines instead of hand-washing? (Some people still swear by air-drying instead of using a dryer, but there aren't that many "hand-washing is just better" holdouts, even if it might be true!)

Note that in all of these cases, you ALWAYS grin when you first use the more automated thing after having done the manual thing, and you ALWAYS lose something by going the faster/less-laborious route. If people are simply hyperfocusing on what is lost when you lean on LLM for coding, then they're simply going to miss the train (yet another invention that superseded walking and horseback-riding, with its own set of tradeoffs!)

We all know a walk is good on its own terms even if a car is faster, but if your goal is to get from point A to B in less than a certain amount of time, sometimes only a car will do. Hand-washing probably is less wear-and-tear on the clothes and lets you focus on dirty spots. Air-drying leads to fresher-smelling clothes that don't shrink. And hand-coding leads to a more curated solution than an LLM ever could... All of these at a comparatively extreme extra time or labor cost.

well, at least you're being honest about your non-empirical biases...

Note that it doesn't matter if the compiler is correct about its claims; if the language doesn't actively discourage patterns that produce this outcome at scale, then the language does not scale, end of story.

The trend is basically either linear or exponential: as more LOC of Rust are added, the greater the percent of total time you spend fighting the compiler to get a successful build, especially in a team context (which is exactly what gets you to >1M LOC). Solo devs can contain the whole design in their minds and may not run into this issue as much; the problem specifically occurs on teams where the mental model MUST be fractured by necessity, and this results in "distributed knowledge of magic" that ends up constantly breaking.

Perhaps this explains WHY there aren't that many Rust projects done by more than 1 developer that approach that many LOC.

what the heck has convinced you that logic is somehow flawed in a new low-level language? LOLLL

The nice thing is that all these languages feature easy C interop so you can use a C FFI as the interface between them if you want to experiment with, for example, writing a module in Nim

Zig is a return to “no magical effects,” except with reasonable safety

Cool, let me know when you have a rational counterargument then, some of us have gotten fed up with Rust (especially at scale) and are very much enjoying Zig (which has no magic, which turns out to be a huge advantage at scale)

One verifies the binary data of over 200+ common filetypes, to the extent possible.

Another protects data archives/data collections with some parity, in order to survive a degree of bitrot, for those files that you don't necessarily have on a NAS.

The third is a new kind of archiver that specializes in compressing files that are already internally compressed as part of their spec.

Trivia: Did you know that the now-most-common image format in the world, Apple's HEIC/HEIF, has absolutely NO internal integrity protection, and that you can't depend on a failed decode to detect errors since all binary values are allowed in the stream format?

https://mecha.llc/software/

Aaaaand now I can't remember the name of it