Was there something wrong with the old coreutils that needed improvement?
https://buildings.honeywell.com/au/en/products/by-category/b...
The reasoning was that the users didn’t own the device. While I personally believe this is not consistent with recent interpretations of the license by the courts, I think they concluded that it was worth the risk of a customer suing to get the source code, as the company could then pull the hardware and leave that customer high and dry. It is unlikely any of their users a would risk that outcome.
Edited to add: it would be cool if, instead of the top-most wealth-concentrators F[500:], there was an index of the top-most wealth-spreaders F[:500]. What would that look like? A list of cooperatives?
Assuming this theory is true then, what other GPLv3-licensed "core" software in the distro could be next on their list?
https://packages.ubuntu.com/plucky/rust-coreutils
The dependencies of rust-coreutils list libgcc-s1, which is GPL version 3.
However, it would be a fairly straightforward project to replace the unwinder used directly by Rust binaries with the one from libunwind. Given that this hasn't happened, I'd be surprised if Canonical is actually investing into a migration. Of course there are much bigger tasks for avoiding GPLv3 software, such as porting the distribution (including LLVM itself and its users) from libstdc++ (GCC's C++ standard library that requires GCC to build, but provides support for Clang as well) to libc++ (LLVM's C++ standard library).
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...
Perhaps it is also so they can be used in closed source systems (I have uutils installed on my Windows system which works nicely).
This would let them sell to companies who want to only permit signed firmware images to run on their devices, which isn't allowed under GPLv3.
I don't think there’s any serious evidence of it being true though. All we can see right now is that there are a surprising number of MIT-licensed packages replacing GPL-licensed packages. It could be a coincidence.
We sigh in relief every time we see a software that we rely upon changes/adds non-viral license such as MIT, Apache, MPL, BSD, and so on.
This is gonna cause a lot of disappointment down the road.
In the end, a lot of people are willing to write open source just for the sake of having it as it scratches their own need and isn't otherwise monetizable or they just think it should exist. I would never even consider touching a GPLv3 licensed UI library component, for example.
It's not always the most appropriate license and if a developer wants to use a permissive license, they are allowed to. This isn't an authoritarian, communist dictatorship, at least it isn't where I live and to my dying breath won't be.
Choosing licenses due to peer pressure is completely stupid though. If you're not sure, you can just not pick a license at all. Copyright 2025 all rights reserved. If you must pick a license just because, then the reasonable choice is the strongest copyleft license available, simply because it maximizes leverage. The less you give away, the more conditions, the more leverage. It's that simple.
That people are actually feeling "pressure" to pick permissive licenses leads me to conclude this is a psyop. It's a wealth transfer, from well meaning developers straight into the pockets of corporations. It's being actively normalized so that people choose it "by default" without thinking. Yeah, just give it all away! Who cares, right?
I urge people to think about what they are doing.
So the ONLY reasonable choice for me is to release my code with a non-viral license. A copyleft license is TOTALLY UNREASONABLE for me because it limits the reach of my software.
(My license of choice is MPL-2.0)
The problem is that people choose permissive licenses to be "nice" when the truth is they have tons of unwritten rules and hidden assumptions. Magical thinking like "if I publish this open source software then it will come back to me in some way, maybe a job, maybe a sponsorship." No such deal exists. Then they wake up one day with corporations making billions off of their software while they're not making even one cent, and they suddenly have a very public meltdown where they bitterly regret their decisions. I've seen it happen, even with copyleft licenses.
If I'm writing something I intend or might intend to monetize later or otherwise don't want to have privatized, I'll probably reach for GPLv3, AGPL or a different license. The less "whole" a thing is, the more likely I'm going to use a more permissive license than not. Libraries or snippets of code are almost always going to be permissive at least from me. This includes relatively simple CLI utils.
Brave of them to ship a Rust port of sudo as well.
- GNU coreutils (GPLv3)
- uutils coreutils (MIT)
- busybox (GPLv2)
In sort command
Is this the best they could come up with?
But the worst you can do is crash 'sort' with that. Note that uutils also has crashes. Here is one due to unbounded recursion:
$ ./target/release/coreutils mkdir -p `python3 -c 'print("./" + "a/" * 32768)'`
Segmentation fault (core dumped)
This has nothing to do with memory ownership, so borrow checker is irrelevant. Ubuntu just shipped before that argument's handling was implemented.
https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
> Performance is a frequently cited rationale for “Rewrite it in Rust” projects. While performance is high on my list of priorities, it’s not the primary driver behind this change. These utilities are at the heart of the distribution - and it’s the enhanced resilience and safety that is more easily achieved with Rust ports that are most attractive to me.
As an obvious example, I sometimes download files from the Internet, then run coreutils sha256sum or the like on those files to verify that they're trustworthy. That means they're untrusted at the time where I use them as input to sha256sum.
If there's an RCE in sha256sum (unlikely, but this is a thought experiment to demonstrate an attack vector), then that untrusted file can just exploit that RCE directly.
If there's a bug in sha256sum which allows a malicious file to manipulate the result, then a malicious file could potentially make itself look like a trusted file and therefore get past a security barrier.
Maybe there's no bug in sha256sum, but I need to base64 decode the file before running sha256sum on it, using the base64 tool from coreutils.
If you use your imagination, I'm sure you yourself can think up plenty more use cases where you might run a program from GNU coreutils against untrusted user input. If it helps, here's a Wikipedia article which lists all commands from GNU coreutils: https://en.wikipedia.org/wiki/GNU_Core_Utilities#Commands
EDIT: To be clear, this comment is only intended to explain what the attack surface is, not to weigh in on whether rewriting the tools in Rust improves security. One could argue that it's more likely that the freshly rewritten sha256sum from uutils has a bug than that GNU sha256sum has a bug. The statement "tools from coreutils are sometimes used to operate on untrusted input and therefore have an attack surface worth exploring" is not the same as the statement "rewriting coreutils in Rust improves security". Personally, I'm excited for the uutils stuff, but not primarily because I believe it alone will directly result in significant security improvements in Ubuntu 25.10.
Rust is not a silver bullet.
Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old.
See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.
The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected.
Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.
Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams.
> Those commands were never standardized
"Those commands" were present in v7 unix in 1979!
The only place that that doesn't support 'grep -E' and 'grep -F' nowadays is Solaris 10. But if you are still using that you will certainly run into many other missing options.
[1] https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.ht... [2] https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.ht...
The deprecation argument is at least... arguable. It was indeed retired from POSIX. But needless deprecation is itself a smell in a situation where you can't audit all the code that uses it. Don't do that. It breaks stuff. It broke the updates in the linked article too. If you have an API, leave it there absent extremely strong arguments for its removal.
Why?
It's surely not. The question wasn't how to rewrite the shell environment to be more "endorseable", though.
The point is that we have a half century (!) long history of writing code to this admittedly fragile environment, with no way to audit usage or even find all the existing code (literally many of the authors are retired or dead).
So... it's just not a good place to play games with "Look Ma, I rewrote /usr/bin/date and it's safe now!" Mess with your own new environments, not the ones that run the rest of the world please.
Sounds like a plan. Let me know when you're done, and then we can remove fgrep.
EDIT: Just to be clear, I'm otherwise perfectly happy that these experiments are being done, and we should all be better off for it and learn something as a result. Obviously somebody has assessed that this tradeoff has at least a decent probability of being a net positive here in some timeframe, and if others are unhappy about it then I suppose they're welcome to install another implementation of coreutils, or use a different distro, or write their own, or whatever.
F.ex. `sudo-rs` does not support most of what the normal `sudo` does... and it turned out that most people did not need most of `sudo` in the first place.
Less code leads to less bugs.
Hence "doas".
OpenBSD has a lot of new stuff throughout the codebase.
No need for adding a bloated dependency (e.g. Rust) just because you want to re-implement "yes" in a "memory-safe language" when you probably have no reasons to.
$ /usr/bin/time date
Fri Oct 24 10:20:17 AM CDT 2025
0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 2264maxresident)k
0inputs+0outputs (0major+93minor)pagefaults 0swaps
What? How??
- Tagged unions so you can easily and correctly return "I have one of these things".
- Generics so you can reuse datastructures other people wrote easily and correctly. And a modern toolchain with a package manager that makes it easy to correctly do this.
- Compile time reference counting so you don't have to worry about freeing things/unlocking mutex's/... (sometimes also called RAII + a borrow checker).
- Type inference
- Things that are changed are generally syntactically tagged as mutable which makes it a lot easier to quickly read code
- Iterators...
And so on and so forth. Rust is in large part "take all the good ideas that came before it and put it in a low level language". In the last 50 years there's been a lot of good ideas, and C doesn't really incorporate any of them.
Meanwhile my description doesn't fully capture how it guarantees unique access for writing, while yours does.
You're confusing the borrow checker with RAII.
Dropping the last reference to an object does nothing (and even the exclusive &mut is not an "owning" reference). Dropping the object itself is what automatically frees it. See also Box::leak.
With only RAII you don't get the last reference part.
Yes, there are exceptions, it's a roughly correct analogy not a precise description.
I didn't invent this way of referring to it, though I don't recall who I stole it from. It's not entirely accurate, but it's a close enough description to capture how rust's mostly automatic memory management works from a distance.
If you want a more literal interpretation of compile time reference counting see also: https://docs.rs/static-rc/0.7.0/static_rc/
It’s just not a good mental model.
For example, with reference counting you can convert a shared reference to a unique reference when you can verify that the count is exactly 1. But converting a `&T` to a `&mut T` is always instantaneous UB, no exceptions. It doesn’t matter if it’s actually the only reference.
Borrows are also orthogonal to dropping/destructors. Borrows can extend the lifetime of a value for convenience reasons, but it is not a general rule that values are dropped when the last reference is gone.
Borrow checking is necessary for dropping and destructors in the sense that without borrows we could drop an owned value while we still have references to it and get a use after free. RAII in rust only works safely because we have the borrow checker reference counting for us to tell us when its again safe to mutate (including drop) owned values.
Yes, rust doesn't support going from an &T to an &mut T, but it does support going from an <currently immutable reference to T> to a <mutable reference to T> in the shape of going from an &mut T which is currently immutably borrowed to an &mut T which is not borrowed. It can do this because it keeps track of how many shared references there are derived from the mutable reference.
You're right that it's possible to leak the owning reference so that the object isn't freed when the last reference is gone - but it's possible to leak a reference in runtime reference runtime reference counted language too.
But yes, it's not a perfect analogy, merely a good one. It's most likely that the implementation doesn't just keep a count of references for instance, but a set of them to enable better diagnostics and more efficient computation.
I work this way and that's why I consider Rust to be a major impediment to my productivity. Same goes for Python with its significant whitespace which prevents freely moving code around and swapping code blocks, etc.
I guess there are people who plan everything in their mind and the coding part is just typing out their ideas (instead of developing their ideas during code editing).
But it's also because of all the things I'm forced to fix while implementing or refactoring, that I would've been convinced were correct. And I was proven wrong by the compiler, so, many, times, that I've lost all confidence in my own ability to do it correctly without this kind of help. It helped me out of my naivety that "C is simple".
I don't think there are, I think Gall's law that all complex systems evolve from simpler systems applies.
I play with code when I program with Rust. It just looks slightly different. I deliberately trigger errors and then read the error message. I copy code into scratch files. I'm not very clever; I can't plan out a nontrivial program without feedback from experiments.
I've written probably tens of thousands of lines each in languages like C, C++, Python, Java and a few others. None other has been as misery-free. I admit I haven't written Haskell, but it still doesn't very approachable to me.
I can flash a microcontroller with new firmware and it won't magically start spewing out garbage on random occasions because the compiler omitted a nullptr check or that there's an off-by-one error in some odd place. None. Of. That. Shit.
I'm a bit surprised that you are surprised by this. I sometimes think Rust emphasizes memory safety too much - like some people hear it and just think Rust is C but with memory safety. Maybe that's why you're surprised?
Memory safety is a huge deal - not just for security but also because memory errors are the worst kind of bug to debug. If I never have to a memory safety bug that corrupts some data but only in release mode... Those bugs take an enormous amount of time to deal with.
But Rust is really a great modern language that takes all the best ideas from ML and C, and adds memory safety.
(Actually multithreading bugs might be slightly worse but Rust can help there too!)
But the fact that program X was written in Rust is, on the other hand, newsworthy? And there is nothing odd in the fact that the first property of the software that is advertised is the fact that it was made in Rust.
Yeah, nothing odd there.
That's not why it is newsworthy though.
"A project reimplementing core OS programs for the sake of reimplementing in the favourite language breaks stable OS", is what makes it newsworthy.
however once software that has been only rewritten for the sake of being written in Rust starts affecting large distributions like Ubuntu, that's a different issue...
however one could argue that Ubuntu picking up the brand new Rust based coreutils instead of the old one is a 2nd order effect of "let's rewrite everything in Rust, whether it makes sense of not"
There's no "however" here. Rewriting anything in Rust has no effect on anybody by itself.
This isn't something that affected Ubuntu. It's something Ubuntu wanted to test in day to day usage.
Which part of that is stupid? License is chosen because Rust is more static linkage friendly. Which leaves exercise part or high compatibility.
You might as well say Linux is a stupid rewrite that will never achieve anything circa 1998.
> nice
> we’re releasing coreutils rewritten in a memory safe language for free
> how dare you!
They've added internal features though, like better hardware support in copying and moving files.
But systemd projects and Rust rewrites have this one thing in common: them being pure virtue signaling they absolutely have to be noticed. And what's a better way to get noticed if not going for something important and core?
To me, Rust rewrites look like "just stop oil" road blocks - the more people suffer, the better.
PS: Disclaimer: I love Rust. I hate fanboys.
Then blame Canonical? Quit it with the Rust hate.
The thought of rewriting anything as intricate, foundational, and battle-tested as GNU coreutils from scratch scares me. Maybe I'd try it with a mature automatic C-to-Rust translator, but I would still expect years of incompatibilities and reintroduced bugs.
See also the "cascade of attention-deficit teenagers" development model.
It is extremely bad that it's not a relatively straightforward process for any random programmer to rewrite coreutils from scratch as a several week project. That means that the correct behavior of coreutils is not specified well enough and and it's not easy enough to understand it by reading the source code.
For a business it's often fine to stop at a local maximum, they can keep using old versions of coreutils however long they want, and they can still make lots of money there! However we are not talking about a business but a fundamental open source building block that will be around for a very long time. In this setting continuous long term improvement is much more valuable than short term stability. Obviously you don't want to knowingly break stability either, and in this regard I do think Ubuntu's timeline for actually replacing the default coreutils implementation is too ambitious, but that's beside the point—the rewrite itself is valuable regardless of what Ubuntu is doing!