How to maintain code for a century: Just add Rust
- Reference: 1721723410
- News link: https://www.theregister.co.uk/2024/07/23/opinion_column/
- Source link:
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.
[1]
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.
[2]
[3]
As this must-watch [4]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.
[5]
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.
[6]Hey Microsoft – what ever happened to 'Developers, developers, developers'?
[7]Fragile Agile development model is a symptom, not a source, of project failure
[8]Open source versus Microsoft: The new rebellion begins
[9]How to deorbit the Chromebook... and repurpose it for innovators
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.
[10]
There's a core utility for you. ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zp9-Oow0RaGTn28MMdIZ8gAAAEw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zp9-Oow0RaGTn28MMdIZ8gAAAEw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zp9-Oow0RaGTn28MMdIZ8gAAAEw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://hackaday.com/2024/07/17/floss-weekly-episode-792-rust-coreutils/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zp9-Oow0RaGTn28MMdIZ8gAAAEw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2024/07/15/opinion_development_ms/
[7] https://www.theregister.com/2024/06/10/agile_opinion_column/
[8] https://www.theregister.com/2024/04/15/opinion_microsoft_sovereignty/
[9] https://www.theregister.com/2023/12/11/opinion_column/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zp9-Oow0RaGTn28MMdIZ8gAAAEw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
I think Zig is better than Rust and long term will have more legs.
but no FOSS package ever dies
Oh yes they do - and have.
Nowadays, the bulk of FOSS is shoved into GitHub and will be available - for as long as GirHub bothers to run its servers[1].
Back in the day, Tarballs and Arc files were downloaded direct from the author's site and then you were expected to mirror it if it was important to you.
Then the Web was "discovered" by more and more people and for some reason the mirroring stopped and changed to just dropping in a link to "the" download location - and of course, we then learnt that URLs have a half-life.
As public version control servers came online - and people started to trust them - we saw materials on something safer than a personal site, or the pages of a company that vanished overnight (sometimes the entire company vanished, sometimes just the project)[2].
If you are lucky, the Internet Archive grabbed a copy and you can try one of the dead URLs there; patience can be required[4].
If you are really lucky, somebody has put a copy into GitHub[5] - although you can open yourself up to flames because your copy "doesn't compile for me"[6]
And what about the FOSS that is practically single-sourced by being published in that JavaScript compost heap? Was LeftPad() also available from GitLab? Some of it is handled properly (p5.js oooh, squiggly and probably safe from vanishing).
Of course, any FOSS that does fall through the cracks "is not important" - after all, all the Linux distros keep their own copies of source packages, "so we are not actually reliant on GitHub at all, Corner you fool."
Not important. Well, you never know. Literally, you never know, it has gone now.[7]
[1] Then we'll have to go back and pull the older version from SourceForge.
[2] As [1]a few others did I like the old "Elegant" library & util from Philips Labs - good luck finding that, on the Philips site - or doing a web search for it available elsewhere[3]
[3] stop giving your projects names that are normal words!
[4] not being able to find something is, in all practical terms, the same as the thing no longer existing at all. Take note when organising your backup copies...
[5] really must put my compiling copy of Elegant up on GitHub
[6] so maybe I won't put Elegant up, as I only have Makefiles for My Own Build System and am fed up telling people how to write build scripts for their favoured build tools. Seriously.
[7] "Important" is a relative term[8]. Maybe it is really important to *you* to generate an awful lot of Elegantly laid out syntax diagrams in the next day or you can't pay for Tiny Tim's new clutches, he is growing so fast nowadays, at least the one leg is.
[8] see so very many commentards "well, my PC is ok so this is a non-issue" and the response to same
[9] Footnotes FTW. Be more Pterry!
[1] https://compilers.iecc.com/comparch/article/98-07-235
"One person's itch to learn and code found its salve in a project that few thought needed to be done."
On the basis that if it ain't broke, don't fix it, many will think it a project that ought not to be done. Once somebody decides to take that back off something there's always the temptation to fiddle with this or that.
As to whether, in a few decades time, coreutils will need to be available in Rust or Go or some future contender to replace C, none of us know.