On Wed, May 15, 2024 at 6:53 PM James Youngman <ja...@youngman.org> wrote: > > [I changed the subject line because this is quite a tangent from the original > thread] > > On Wed, May 15, 2024 at 7:50 PM Nikolaos Chatzikonstantinou > <nchatz...@gmail.com> wrote: >> >> >> How about GNU does a call to arms for an alternative Rust >> implementation of its coreutils? There's still hungry Rust devs out >> there willing to write a lot of code to prove themselves. > > > A Rust-based coreutils implementation would do nothing for find, since it's > not part of coreutils. In this email I'm mainly going to discuss findutils.
Ah yeah, my bad. Find or coreutils, the point is to invite more Rust into GNU. > For security above all reasons, findutils has preferred native interfaces and > gnulib's implementations/wrappers. The advantage of using gnulib for things > like fts is that findutils is not the only consumer, and we're very likely to > notice issues with it even in weird corner cases. I find it a bit hard to > imagine a Rust-based implementation correctly implementing GNU find's > "-regex" without using gnulib as the regex implementation, for example. There's no issue in using gnulib from my point of view. > Find in particular needs to be able to work correctly in odd situations where > even library implementers would often just shrug and say those cases are not > in-scope. For example, [ ...snip examples ] I'll show you one example where my patch was ignored <https://savannah.gnu.org/bugs/?62622>. It's a bug and it's not looked into because the maintainers don't have the time for it. Why? because the code base is very messy. Find definitely has odd situations that are being ignored. > If a Rust-based-find team was serious about making a 100% drop-in backward > compatible find implementation that would prioritise working securely and > correctly on the GNU system over other considerations, then there's a > discussion worth having. Obviously security would be prioritized and then backward compatibility. Instead of having a discussion, I'd suggest a call to arms, e.g. an open invitation for people to submit their work or to organize their collaboration. > Flipping back to coreutils for a moment, the Rust-coreutils folks are aiming > for feature compatibility, but that's not the same thing as being a > completely faithful drop-in replacement. Maintainers of GNU core tools (not > just coreutils, other things too) are very, very careful about breaking their > callers[*]. There are cases with find, for example, where the > deprecation-to-removal timeline is 5 years+ (example: -perm +...). I'm > struggling to imagine that the Rust coreutils folks will really buy into this > kind of approach. They're using Clap as the command-line parser for example. > Now, actually I like Clap and there are projects where I've used it. But > it's a stretch to imagine that it's going to parse arguments in precisely the > same way as getopt_long() in all cases. So I find it hard to imagine that > the two suites will ever be close enough in behaviour for either team to > consider them aligned. Though of course I can imagine some (obviously not > all: nothing is ever "all") distributions electing to switch even without > this kind of drop-in-replacement compatibility. Rust coreutils is MIT-licensed so it shouldn't be a project for GNU. > Please don't get the idea though that I'm against Rust. I think that, yes, > new tools should often be written in it. But that's a very different > question from replacing an existing tool, because compatibility is a hard > problem. I do not suggest that we replace find, I'm suggesting that we develop another find in Rust for the GNU project and give users the freedom to choose; as well as divert more resources toward the Rust version. Regards, Nikolaos Chatzikonstantinou
