upvote
coreutils was a category error: they took a set of tools which were not very exposed to memory safety errors and rewrote them in a language which does nothing to prevent the kind of logic errors coreutils has suffered from (mostly races around file operations). It’s like complaining that an airbag didn’t save you after driving into a lake.

In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with those complex decoders operating on data which is often untrusted. I wouldn’t suggest a project of that scale lightly but it’s at least a near-perfect fit on the problem domain.

reply
I would say it’s the opposite. coreutils is core utils, you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. They are also relatively simple.

With ffmpeg, anyone who knows anything about secure application development in the past 20 years knows that it is a huge security tarpit and throwing it untrusted inputs in trusted environment is asking to be owned. You thoroughly sandbox that shit. That’s true for all untrusted media conversion, but absolutely with ffmpeg.

reply
> you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments.

True.

That doesn't make them "very exposed to memory safety errors".

reply
The coreutils rewrite was shit because of the license change. Most of the other founding ideas were also bad as you say, but the license change was absolutely a much worse signal. Just a bunch of people rolling over and showing big corps their belly. And for what? So they can be more exploited by people that treat them like cattle.
reply
Rust does not do "nothing" to prevent logic errors. On the contrary, its strong type system makes them much less likely than in C.

Also security isn't the only reason to prefer Rust to C.

But I do agree ffmpeg would see a much bigger benefit from being written in Rust.

reply
In case with coreutils, as I remember, there were mostly race conditions. Not memory safety issues. Maybe we just need better I/O libraries.
reply
Or use a buffer abstraction in C. This is not exactly rocket science. The "this is impossible to prevent in C" nonsense does far more harm than good.
reply
Errors are easily found and corrected for a modest one-person project in C.

But we’re combining probability of error creation (which is effectively constant) and the limits of human cognition.

Some things are impossible at one scale, become possible at another, and become inevitable at yet another.

reply
To be fair, C is a pain to use, so it is better to improve Rust. It is annoying when for example, you have to free several allocated structures when there is an error in the middle of a functon.
reply
I personally like to use C and find Rust annoyingly complex. I think it may be an alternative to C++, but C++ is also too complex for my taste. I do not find it annoying to free several allocated structures when there is an error, but one could also automate this with a often used extension.

There is also the question whether trading memory safety against supply chain risks is really worth it.

reply