Comment by inigyou
3 days ago
I don't think you need to be an absolutist or only use memory safe languages but it's very obvious that we need to do a whole lot better than we actually do. Rewriting in Rust or any other language is one way to do that, but not a perfect one. I'll accept C++ when most C++ software has 1 in 50 chance of an RCE and not just a 1 in 50 chance of a known RCE. I think we can get there but we are not currently there.
Coreutils has a good track record. Ffmpeg doesn't. They should have rewritten ffmpeg in Rust, not coreutils.
There are other approaches though like formal verification.
ffmpeg is actually asm and for a good reason - it has to go fucking fast or else media playback will take too much resources
There are projects such as Halide[1] that actually allow you to achieve performance without needing to resort to asm.
[1] https://halide-lang.org/
Great then let's prove that ASM is correct.
the reference C code is just as bad.
Which is actually possible, unfortunately the industry never cared that much about strong typed assembly.
See Verve OS from Microsoft Research, TAL and the origins of the Dafny language.
1 reply →
If you go by this metric (has a RCE and not known to have RCE), I'm pretty sure the actual statistics are more like 1 in 2, at least. And probably more than one RCE.
>They should have rewritten ffmpeg in Rust, not coreutils.
Wait for an AI company to promote their new model by porting the entire ffmpeg to Rust (half ironically).
Didn’t the primary maintainer already signal burnout or frustration or something like that? If an AI company actually did port ffmpeg *successfully* (not like claude CC), the dude might get the release he might have been yearning for