[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. I'm not a maintainer of coreutils and can't speak for the folks who are, really. Although I am a maintainer of findutils, I'm not the only one, and so what I'm writing here is just a personal opinion, not the response from the "findutils maintainer team" at all. I haven't looked at this for a long time, but when I did look at the coreutils implementation, I was left with the impression that the team's engineering trade-offs favoured using standard Rust library interfaces over native operating system (i.e. FFI) interfaces. 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. 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, - Where the current directory is above the root directory "/" - Where the current directory contains an infinite loop of hard links - Where the file system being searched is an active target of symlink race attacks - Where the current user lacks the search permission for the current directory (but does not lack read permission) - Where the current user lacks the read permission for the current directory (but does not lack search permission) - Where entries in /etc/fstab exist for which a stat or statvfs call will hang forever 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. 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. [*] probably my most memorable mistake was in making `find . -name foo -maxdepth 2` generate a warning message. A mistake even though the stdout output is identical. 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. James.
