Opinion One of the delicious promises of open source software is eternal life. In literature from Gilgamesh on, this has been a classic trap for the careless and greedy, but this is FOSS so it must be true. No package ever dies. Proprietary code goes unpublished: if its host company dies, it probably dies with it the moment the servers are wiped.

Open source's default mode is life. The code is published, cloned, archived by default. It may be abandoned to lie dormant, like a tardigrade sitting out a drought in suspended animation, but drop the water of attention on it and it's back in the game. At least, that's the theory. All current code relies on an ecosystem of languages, skills, tools and, above all, relevance. Y2K was made many times more difficult because of old COBOL and the like where most of that ecosystem was on the edge of extinction.

Which is why what's happening now to coreutils is so fascinating. These are the terminal commands in Unix, Linux and the like which give direct access to the operating system and its attached storage and IO. You'll know them best as ls, cp, grep and so on. There are 60 to 70 of them, most of which you'll never use. They are terse, they are arcane, and the most useful ones are 50 years old. Ever used octal? You will with chmod. They're also utterly essential for any OS level task.

This extreme antiquity is because they were started by Ken Thompson and Dennis Ritchie as they invented Unix and C and needed to put control knobs on that wonderful machinery. Half a century on, coreutils are still the primary toolkit for sysadmins and low-level wizards. Both they and the C language are still in rude health - so why reimplement the GNU coreutils in Rust? Because that's what's happening.

As this must-watch Hackaday interview with lead dev Sylvestre Ledru notes, it's not for the usual reasons people Rustify C code, security and reliability. There have been virtually no security issues with coreutils, and the bugs have been gone for decades. Ledru started the project for very personal reasons: as a director at Mozilla, he was surrounded by Rust creators in an entirely managerial job, and he wanted to learn Rust. Reinventing coreutils, for him, was primarily fun; he learned the thinking behind the beginning of modern computing. Plus, it seemed to be something worth doing.

Last year, the package started to get a reputation for robustness, and was finding its way into production in some significant places. It had attracted hundreds of contributors, it had some performance advantages, and it has a more permissive license - MIT in place of GPL. You can do that if you re-invent. There are a ton more interesting details in the interview about implementation and distribution - did we say it's a must-see? - but the most significant aspect of the project is the long term implication.

While C and its offspring remain popular, it is losing relevance. C was so apt for early modern computing, yet its intimate, flexible control over memory usage lacked safeguards because they took space and time when there was very little of both. The original Unix philosophy was to hand as much power as possible to the programmer consistent with portability. In today's landscape of intersecting complexity, inherently secure languages are mandated. The pool of C programmers will shrink over time, and at some point the language itself will become an antique.

Which is not the case for coreutils, any more than chisels and planes and pliers. Without motivated, skilful language experts, though, they will fossilize and become unable to adapt to new platforms or needs. They'll lose their appeal to the curious: these tools are self-contained and need few dependencies, so are excellent for learning. Not so if they're written on the logic equivalent of Latin.

The Rusty coreutils don't just come in an attractive form for the modern coder, they include other benefits that come with 50 years of experience. The code has been fuzzed to death, and there's a comprehensive test suite - excellent things to learn about and practice. Also, long-standing gripes have been fixed, such as cp growing a progress bar switch, and future plans for further additions. In short, coreutils is gently moving forward in all the right ways.

The real joy of this is that it's been so organic. One person's itch to learn and code found its salve in a project that few thought needed to be done. But in ten or 20 years' time, it will need to have been done. None of the reasons for this have any place in the proprietary, metrics-driven goal world of closed source.

The end result is that an essential and massively used set of tools from 50 years ago will be just as essential and just as used 50 years hence. To the many freedoms FOSS grants, we can add that of looking ahead as far as you can see and quietly start the business of evolution to fit.

There's a core utility for you. ®

https://www.theregister.com//2024/07/23/opinion_column/