11 ms·

Oxidizing Ubuntu: adopting Rust utilities by default

231 points by jwilk 2y ago

steveklabnik 2y ago
Previously: https://news.ycombinator.com/item?id=43360969 https://news.ycombinator.com/item?id=43360969 https://news.ycombinator.com/item?id=43353240 https://news.ycombinator.com/item?id=43353240
blueflow 2y ago
The uutils project has the right goals - 1:1 compatibility with GNU coreutils to the extent that any difference in functionality is a bug. The first comment on LWN is about a bug in the more(1) from uutils. I checked out that code, found some oddities (like doing stat() on a path to check if it exists, right before open()ing it) and went to check against how GNU coreutils does it. Turns out coreutils does not do it at all, because more(1) is from util-linux. ta-dam.
- cWave 2y ago
  the more you know
- samtheprogram 2y ago
  Not sure why you are downvoted but I’m curious why. I appreciated this tidbit, thanks.
- jgtrosh 2y ago
  And? How does that do it?
  - IshKebab 2y ago
    I checked. It fopen's the file and then fstat's it. So it isn't vulnerable to TOCTOU. However the TOCTOU is completely benign here. It's just an extra check before Rust opens the file so if you were to try to "exploit" it the only thing that would happen is you get a different error message.
    - oguz-ismail 2y ago
      > if you were to try to "exploit" it the only thing that would happen is you get a different error message Can't reproduce this. If I do sudo strace -e inject=stat:delay_exit=30s:when=2 ./coreutils more foo on one terminal and rm foo ln -s /etc/passwd foo on another, I can see the contents of /etc/passwd on the first one.
      - IshKebab 2y ago
        Uhm yeah well now try ln -s /etc/passwd foo sudo more foo OMG! The original version is "vulnerable" too! (I did not know about that strace feature though - that is very cool, thanks!)
        oguz-ismail 2y ago
        I thought I was gonna see an error because the stat'd file and the opened one didn't match. How disappointing
        IshKebab 2y ago
        No, it just means you're checking the wrong file so you might not get the nice error message from the initial check. It's still not going to do anything incorrect when it comes to actually open the file though. TOCTOU only matters when the check is actually checking something important. Here it isn't; it's just giving nicer error messages. If you bypass it you just lose those nice error messages. So it isn't a problem here.
- secondcoming 2y ago
  > > Klode said that it was a bad idea to allow users to select between Rust and non-Rust implementations on a per-command level, as it would make the resulting systems hard to support. Wouldn't this imply that these aren't actually 1:1 replacements?
  - zamadatix 2y ago
    It would imply not all of the replacements are complete and/or bug free yet, and the article gives examples of just that earlier in the text, but it would not imply the replacements lack the goal of being 1:1 replacements like GP said. This would seem to be one of the driving factors in the creation of oxidizr: to allow testing how ready the components are to be drop in replacements with easy recourse. You can read more about that in this section of the linked blog post by jnsgruk https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995#p-144776-introducing-oxidizr https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
  - blueflow 2y ago
    uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs. -- https://github.com/uutils/coreutils?tab=readme-ov-file#goals https://github.com/uutils/coreutils?tab=readme-ov-file#goals
- LeFantome 2y ago
  I think this is an excellent point that a lot of people are missing. There are a lot of GNU utils. For now, Ubuntu is only taking on the ones that are actually in coreutils. Those are the ones that uutils considers "production ready".
- 01HNNWZ0MV43FF 2y ago
  That's funny because just today I was reading the Rust docs for std::fs::File and saw a warning about that exact TOCTOU error, and had to fix my code to not hit it
  - Starlevel004 2y ago
    std::fs is generally not a good API with the complete lack of directory handles.
- codeguro 2y ago
  >The uutils project has the right goals Their goals are to _replace GPL's code_. It's a subtle attack on Free Software by providing corporations a workaround so they don't have to abide by the terms of the license. Nobody seriously doubts the efficiency or safety of the GNU Coreutils. They've been battle tested for over 30 years and whatever safety or optimization risks are left are negligible.
ZoomZoomZoom 2y ago
> This is not symbolic of any pointed move away from GNU components - it's literally just about replacing coreutils with a more modern equivalent. Sure, the license is different, and it's a consideration, but it's by no means a driver in the decision making. Sorry, don't believe this one bit. I'm very thankful for everything Canonical/Ubuntu did about 20 years ago, but no thanks. This comes from someone who loves Rust and what it made possible. However, freedoms are too important to not treat anything that looks like an attack on them as such.
- superb_dev 2y ago
  Which freedoms are being attacked?
  - endgame 2y ago
    Remember when Red Hat tried to lock away the source code to subscribers only? I think they would have preferred not to provide source at all, but the enormous base of GPL code entangled with everything make that impractical. I think we're really going to miss having the fundamental parts of the system available under strong copyleft, and it will be very hard to go back.
    - stouset 2y ago
      Everything in uutils is under the MIT license. The only thing you're missing is the "viral" nature of the GPL. Nobody in the BSD world seems to be particularly suffering under the thumb of unreleased forks of `chown` and `mkdir`.
      - desumeku 2y ago
        Yes, and if BSD was what everyone used for servers instead of Linux, then there would be nothing stopping Oracle from selling you Oracle BSD for a nice subscription price. Of course, they and red hat are already doing this in their own way that gets around the GPL, but a more permissive license would just allow them to do it even more.
stefan_ 2y ago
All you are doing is setting people up for more permanent bash-dash disasters. Isn't there something more useful you could be doing with your time? Say making drag&drop work in snaps (another unforced disaster)?
- OsrsNeedsf2P 2y ago
  The "security" in Wayland, Snaps and Flatpaks are starting to irk me. Macros aren't working, clipboard forgets my copy, drag n' drop is flimsy - AppImages like Cursor can't even open on vanilla Ubuntu anymore. These "features" no one asked for should be opt-in.
  - Etheryte 2y ago
    In a way they are opt-in, as in you opt in by using Ubuntu and opt out by using something else.
    - deleted 2y ago
      [deleted]
  - porridgeraisin 2y ago
    Yep, exactly. The whole thing is just theater. I hate it. I know I can just use X11 (and I do), but the already small appetite for developing for linux will be stretched even more thin in the coming years and we will probably only have Wayland apps. The bright side however, is that Wayland could make itself so utterly garbage that people just ignore making apps for it (I'm not counting apps targeting just kde/gnome, which anyway diverge far enough from wayland protocols to warrant being mentioned separately). So we would have X11/KDE/Gnome support for linux apps. That's probably the best case scenario.
  - surajrmal 2y ago
    Do you think app permissions in Android and iOS apps are not helpful? There isn't really a reason that the permission models make sense on mobile but not desktop. Desktop applications are inherently more trustworthy. The fact the security features gets in your way is more of a product finesse problem which generally plagues open source projects in general. The technology is not conceptually flawed.
hansvm 2y ago
> Of course they are considered problematic in Rust. > And leaks are hard to code by accident in Rust. > ... I enjoyed this gem and its descendants from the comments. What I see instead, commonly, even in big rust projects, is that it's easy to accidentally define something with a longer lifetime than you intend. Some of that happens accidentally (not recognizing the implications of an extra reference here and there when the language frees things based on static detections of being unused). Much more of it happens because the compiler fights against interesting data structures -- e.g., the pattern of allocating a vec as pseudo-RAM, using indices as pseudo-pointers, and never freeing anything till the container itself is unused. There's nothing wrong with those techniques per se, but the language tends to paint you into a bit of a corner if you're not very good and very careful, so leaks are a fact of life in basically every major Rust project I've seen not written by somebody like BurntSushi, even when that same sort of project would not have a leak in a GC language.
- MeetingsBrowser 2y ago
  > not recognizing the implications of an extra reference here and there when the language frees things based on static detections of being unused Maybe I’m misunderstanding, but isn’t the point of the borrow checker to throw errors if a reference “outlives” the memory it references? How can an extra reference extend the lifetime?
  - hansvm 2y ago
    Rust (most of the time, I'm not arguing about failure modes at all right now, let's pretend it's perfect) drops items when you're done with them. If you use the item longer, you have a longer implicit lifetime. The memory it references will also be claimed for longer (the reference does not outlive its corresponding memory). You only fix that by explicitly considering lifetimes as you write your code -- adding in concrete lifetimes and letting the compiler tell you when you make a mistake (very hard to do as a holistic strategy, so nobody does), or just "git gud" (some people do this, but it takes time, and it's not the norm; you can code at a very high level without developing that particular skill subset, with the nearly inevitable result of "leaky" rust code that's otherwise quite nice).
jvsgx 2y ago
I have a queston: Why do they need their utilities to be written in Rust? Most utilities do not have to face the network, and most don't need to have root privileges. Heck, most of them are one shot programs and don't even need to free memory by the programmer. They could exit and return all the memory space back to the OS.
- grandiego 2y ago
  > Most utilities do not have to face the network True, but code from those utilities may eventually be used in the network (for example, through copied functionality and shared libraries). Also, a creative pipeline may actually involve them (think of the Unix philosophy.) Eventually plain C has to die or be relegated to unavoidable places like in the assembly cases, even if Rust is not the best alternative after all.
  - zifpanachr23 2y ago
    This is based on a common fallacy that people believe about CVEs vs. what actually gets exploited. I would go back and read the papers that got you so aggressively on board the memory safety train one more time and see if you can't detect motivated reasoning.
    - treyd 2y ago
      What is the fallacy, specifically?
    - lolinder 2y ago
      If you have an argument to make, make it. This isn't a classroom and you're not an instructor, assigning homework to people who disagree with you isn't an effective argumentation technique.
- k_bx 2y ago
  Because things need to keep evolving, we see great new ideas coming from tools which add progress bar, make colorful output, have knowledge about .git structure etc. Current state of things is quite stalled, in my opinion.
zoogeny 2y ago
I hate to admit it, because I don't particularly like Rust, but I'm slowly coming around to the idea it should replace things. The major change is a recent comment I made where I was musing about a future where LLMs actually write most of the code. That isn't a foregone conclusion but the recent improvements in coding LLMs suggests it isn't as far off a future as I once considered. My thought was simple: if I am using a LLM to do the significant portion of generating code, how does that change what I think about the programming language I am using? Does the criteria I use to select the language change? Upon reflection, Rust is probably the best candidate. It has strictness in ways that other languages do not have. And if the LLM is paying most of the cost of keeping the types and lifetimes in order, what do I care if the syntax is ugly? As long as I can read the output of the LLM and verify it (code review it) then I actually want the strictness. I want the most statically analyzable code possible since I have low trust in the LLM. The fact that Rust is also, ahem, blazingly fast, is icing on the cake. As an aside to this aside, I was also thinking about modular kernels, like Minix. I wonder if there is a world where we take a userland like the one Ubuntu is trying and apply it to Minix. And then slowly replace the os modules with ones written in Rust. I think the modularity of something like Minix might be an advantage, but that might just be because I am completely naïve.
- Covenant0028 2y ago
  I've had similar thoughts as well. Rust or C would also be the ideal candidate from an energy consumption point of view, as they consume way less energy than Python, which is the language that LLMs most often default to in my experience. However it's unlikely LLMs will generate a lot of Rust code. All these LLMs are generating is the most likely next token, based on what they've been trained on. And in their training set, it's likely there is massively more Python and JS code out there than Rust, simply because those are way more popular languages. So with Rust, it's more likely to hallucinate and make mistakes than with Python where the path is much better trodden
  - jdright 2y ago
    In practice, it is not what happens. I've been doing AI assisted Rust for some time, and it is very convincing that this is the way. I expect 6mo to 1y to be basically fully automated. Rust has tons of code out there, and quality code. Different from js or Python that has an abundance of low quality to pure garbage code.
jauntywundrkind 2y ago
My long hope is that some day, someone starts to replace the perl-based Debian infrastructure with Rust (or really, anything). I did a decent bit of mod_perl, love & respect perl, but here in 2025, it's pretty terrifying to me that Debian's main dependency is a pretty sizable perl runtime. That there seems to be very little that will budge this. The whole ecosystem is built atop a language that very few people have interest in, that has much less interest & activity than other modern alternatives. It's fine if we start switching the user env over to more popular Rust based utilities. But what I really want is for the OS itself to modernize, to start getting away from it's ancient seemingly-unshakeable legacy. Nothing against Perl, but I'd love to see this family of OSes move beyond being Perl only.
- kiney 2y ago
  There are non-Perl-based replacements for basically all the system utilities written in Perl in Debian in other distributions, but as things are currently, the Debian versions written in Perl are still unmatched.
worik 2y ago
This is on brand for Canonical. Bleeding edge beta (alpha?) software put in the core of their system Reminds me of when they switched Gnome out for Ubuntu One, no way back if you did 'aptitude full-upgrade'. It was a buggy leaky pos Again, dear friends...
Animats 2y ago
Has someone built Busybox in Rust yet? That would be good for embedded.
- chiffaa 2y ago
  technically uutils/coreutils should suffice for this goal still as it can build into a single-binary tool a la busybox (iirc that's the default actually)
  - lifeinthevoid 2y ago
    Busybox has very basic implementations of the tools though, to keep the size in check.
redder23 2y ago
[dead]
black_13 2y ago
Using Rust is a political solution to deskill a generation of coders to replace higher-cost labor with lower The push for Rust isn't just a technical decision - it's a calculated economic strategy. By forcing rewrites of stable systems in a new language, companies effectively reset the clock on developer experience and expertise. When a C/C++ codebase with 30 years of institutional knowledge gets rewritten in Rust, senior developers with decades of experience suddenly compete on more equal footing with juniors who just graduated. Your 15 years of C++ optimization knowledge? Now worth less than a 22-year-old's six months of Rust bootcamp training. This isn't about memory safety - it's about labor costs. Companies call it "modernization" while quietly erasing the premium they'd otherwise pay for experience. The technical arguments serve as perfect cover for what's really happening: deliberately manufacturing a scenario where they can replace $250K senior engineers with $80K juniors. The pattern is familiar to anyone who's watched other industries. Create artificial obsolescence of existing skills, then exploit the resulting chaos to reset salary expectations and eliminate the leverage that comes with specialized knowledge. This is why language transitions always seem to coincide with hiring freezes and "restructuring." It's never been about technical superiority - it's about breaking labor's bargaining power.
- jeroenhd 2y ago
  That's an interesting conspiracy theory I haven't heard before. However, I doubt the investment into rewriting large projects makes any financial sense even if the goal is to kick out the experts. Rewrites take years, even if the junior does it for cheaper, and migrations are an existential business risk. If those 15 years of C++ optimization don't provide an advantage over what a 22 year old with half a year of bootcamp can provide for a quarter of the price, then maybe it really is time to stop doing things in C++. The unfortunate truth of programming as a profession is that you need to move with the times. If C++ is on its way out (which I highly doubt), it's time to learn Rust. Most Visual Basic programmers moved on, as did most Fortran programmers, and many C++ programmers when Java hit the scene. When you're making this about labour's bargaining power, you're assuming that young labour is a threat to experience labour. Perhaps that's the case to some extent, as the shortage of people with programming skills that has led to the ridiculously high wages for the software industry is slowly evaporating, but gatekeeping the industry isn't some kind of pro-labour move, it's just selfish.
userbinator 2y ago
Rust and "memory safety" is the current form of corporate authoritarianism. It's ironic that its most vocal advocates are also likely to be the ones complaining about the authoritarianism of the current administration.
- wisty 2y ago
  Memory safety isn't so corporate, AFAIK. I think it's just a current programmer fad, like pearl's dwim, python's "pythonic", JavaScript having 5 different libraries for every conceivable one-line function, Haskell's um ... I never got Haskell, etc. Every time a language starts taking off, people want to rewrite everything in their language. Rust just has the performance and a few advantages that make it arguably better than C for the things C does, which is a bit cool I guess.
  - userbinator 2y ago
    It is corporate, because they realised that things like jailbreaks and rooting could be stopped easily by increasing "security" this way.
nukem222 2y ago
GNU is free to adopt better tools than C/C++. I adore gnu but I refuse to support blatant and obstinant idiocy. Using the license to extort people into supporting C/C++ is just scummy behavior. What the fuck were you doing the last ten years that this wasn't a gnu project? Instead we got fucking systemd and a dozen more knockoffs of the shittiest os on earth
- DaSHacka 2y ago
  You have the right to not use GNU utilities or GNU/Linux either, you know. No one's forcing you.
tzwhaG 2y ago
It looks like a corporate project with all the required hype and lingo. Ubuntu was nice around version 10, it went downhill with spyware, snap, etc. "There are countless examples in the open source community of tools being re-engineered, and re-imagined using tools and practices that have only relatively recently become available." Recently? You can use Ada or OCaml, which is a better Rust. You can use C with formal proofs and not constantly rewrite everything. But that of course is the point. No rewrites, no easy money for the corporate OSS "developers".
- psd1 2y ago
  I love the ml language I'm learning and consider it better _than_ any other language I use, but I'm puzzled by "ada or ocaml, which is a better rust" Never written rust, only looked at snippets on blogs, but it visually looks so different to ml Am I being fooled by superficial syntactical differences? Could you explain?
johnisgood 2y ago
Amazing, another reason for avoiding Ubuntu. Many of these utilities have had logic errors in them, you can find them on GitHub issues. sudo, for example, allowed you to bypass through some way I cannot remember. And I bet you they are not a replacement for GNU utilities, i.e. have less features, and are possibly not optimized either, and perhaps they even have different (or less) flags/options. I have written a lot of Bash scripts, I wonder how well (if at all) would work on Ubuntu with the Rust utilities.
- Almondsetat 2y ago
  What an ignorant comment. The uutils README on GitHub explicitly states in the first section that every discrepancy wrt GNU utilities is considered a bug.
  - deleted 2y ago
    [deleted]
  - johnisgood 2y ago
    It is a comment coming from pragmatism, not ignorance. At any rate, feel free to look around here: https://github.com/uutils/coreutils/issues?q=is%3Aissue%20state%3Aopen%20state%3Aclosed https://github.com/uutils/coreutils/issues?q=is%3Aissue%20st... It is NOT a replacement of GNU coreutils AT ALL, as of yet. Granted under "Goals" it says "uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.", but please look around the opened (and closed) issues (since they should tell you about the major, yet simple logic bugs that has occurred). It is definitely not ready, and I am not sure when and if it will be ready. FWIW the README also says: "some options might be missing or different behavior might be experienced.". Future will tell, but right now, it is an extremely bad idea to replace GNU coreutils with Rust's uutils. Do you think otherwise? Elaborate as to why if so.
  - lolinder 2y ago
    Your first sentence is totally unnecessary and relies on an uncharitable reading of what they said. It's entirely possible that they knew that a goal of the project was to treat every discrepancy as a bug and were indicating that they were of the opinion that there were plenty of bugs left and no evidence that they would ever be all squashed. Also, while we're slinging the README around, here's the first paragraph: > uutils coreutils is a cross-platform reimplementation of the GNU coreutils in Rust. While all programs have been implemented, some options might be missing or different behavior might be experienced. The "ignorant comment" above was actually just pointing out the thing that the developers thought was second-most-important for people to know—right after the fact that it's a reimplementation.
alextingle 2y ago
This is the worst kind of busy-work. Rewriting something for the sake of it is terrible practice. There's a lot of refreshing energy amongst Rust coders eager to produce better, more modern command-line tools. That's amazing, and a real benefit to everyone. But rewriting simple, decades-old, perfectly functional tools, with the explicit goal of not improving them is just a self-absorbed hobby. And a dangerous one at that - any new code will contain bugs, and the best way to avoid that is not to write code if you don't have to.
- immibis 2y ago
  It's not for the sake of it - it's to have MIT-licensed (able to be propriotized) coreutils. GPL is a thorn in the side to anyone who wishes to EEE it.
  - IshKebab 2y ago
    That isn't the motivation. It's about "resilience, performance and maintainability". I doubt they'll get noticeably better performance (the main GNU tools are already very optimised). I'm not sure they really lack in resilience. And I don't think memory safety is a big factor here. Maintenance is definitely a big plus though. It will be much nicer to work on modern Rust code than ancient C.
    - immibis 2y ago
      To clarify, you think the obvious benefit that is something several organizations obviously want isn't the motivation, but improvements to 3 things that probably won't be improved are the real motivations?
    - psd1 2y ago
      How much maintenance do the tools need currently, and how does it compare to the effort? i am surprised by the implication
    - codeguro 2y ago
      If you look a bit deeper, this project actually cares deeply about its license, and is going out of its way to choose the license it is using, ignore complaints, and avoid ending up GPL. https://www.youtube.com/watch?v=5qTyyMyU2hQ https://www.youtube.com/watch?v=5qTyyMyU2hQ In an interview with FOSS Weekly, Sylvestre Ledru (the main developer, who curiously has a background working on Debian and Firefox, before ending up getting seduced by the clang/LLVM ecosystem), firmly states "it is not about security".
bravetraveler 2y ago
Canonical making light of licensing again, no surprise here. This has ulterior motive written all over it. Best outcome: nothing happens.

231 points by jwilk 2y ago

Previously: https://news.ycombinator.com/item?id=43360969 https://news.ycombinator.com/item?id=43360969 https://news.ycombinator.com/item?id=43353240 https://news.ycombinator.com/item?id=43353240

blueflow 2y ago

The uutils project has the right goals - 1:1 compatibility with GNU coreutils to the extent that any difference in functionality is a bug. The first comment on LWN is about a bug in the more(1) from uutils. I checked out that code, found some oddities (like doing stat() on a path to check if it exists, right before open()ing it) and went to check against how GNU coreutils does it. Turns out coreutils does not do it at all, because more(1) is from util-linux. ta-dam.

cWave 2y ago
the more you know
samtheprogram 2y ago
Not sure why you are downvoted but I’m curious why. I appreciated this tidbit, thanks.
jgtrosh 2y ago
And? How does that do it?
- IshKebab 2y ago
  I checked. It fopen's the file and then fstat's it. So it isn't vulnerable to TOCTOU. However the TOCTOU is completely benign here. It's just an extra check before Rust opens the file so if you were to try to "exploit" it the only thing that would happen is you get a different error message.
  - oguz-ismail 2y ago
    > if you were to try to "exploit" it the only thing that would happen is you get a different error message Can't reproduce this. If I do sudo strace -e inject=stat:delay_exit=30s:when=2 ./coreutils more foo on one terminal and rm foo ln -s /etc/passwd foo on another, I can see the contents of /etc/passwd on the first one.
    - IshKebab 2y ago
      Uhm yeah well now try ln -s /etc/passwd foo sudo more foo OMG! The original version is "vulnerable" too! (I did not know about that strace feature though - that is very cool, thanks!)
      - oguz-ismail 2y ago
        I thought I was gonna see an error because the stat'd file and the opened one didn't match. How disappointing
        IshKebab 2y ago
        No, it just means you're checking the wrong file so you might not get the nice error message from the initial check. It's still not going to do anything incorrect when it comes to actually open the file though. TOCTOU only matters when the check is actually checking something important. Here it isn't; it's just giving nicer error messages. If you bypass it you just lose those nice error messages. So it isn't a problem here.
secondcoming 2y ago
> > Klode said that it was a bad idea to allow users to select between Rust and non-Rust implementations on a per-command level, as it would make the resulting systems hard to support. Wouldn't this imply that these aren't actually 1:1 replacements?
- zamadatix 2y ago
  It would imply not all of the replacements are complete and/or bug free yet, and the article gives examples of just that earlier in the text, but it would not imply the replacements lack the goal of being 1:1 replacements like GP said. This would seem to be one of the driving factors in the creation of oxidizr: to allow testing how ready the components are to be drop in replacements with easy recourse. You can read more about that in this section of the linked blog post by jnsgruk https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995#p-144776-introducing-oxidizr https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
- blueflow 2y ago
  uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs. -- https://github.com/uutils/coreutils?tab=readme-ov-file#goals https://github.com/uutils/coreutils?tab=readme-ov-file#goals
LeFantome 2y ago
I think this is an excellent point that a lot of people are missing. There are a lot of GNU utils. For now, Ubuntu is only taking on the ones that are actually in coreutils. Those are the ones that uutils considers "production ready".
01HNNWZ0MV43FF 2y ago
That's funny because just today I was reading the Rust docs for std::fs::File and saw a warning about that exact TOCTOU error, and had to fix my code to not hit it
- Starlevel004 2y ago
  std::fs is generally not a good API with the complete lack of directory handles.
codeguro 2y ago
>The uutils project has the right goals Their goals are to _replace GPL's code_. It's a subtle attack on Free Software by providing corporations a workaround so they don't have to abide by the terms of the license. Nobody seriously doubts the efficiency or safety of the GNU Coreutils. They've been battle tested for over 30 years and whatever safety or optimization risks are left are negligible.

ZoomZoomZoom 2y ago

> This is not symbolic of any pointed move away from GNU components - it's literally just about replacing coreutils with a more modern equivalent. Sure, the license is different, and it's a consideration, but it's by no means a driver in the decision making. Sorry, don't believe this one bit. I'm very thankful for everything Canonical/Ubuntu did about 20 years ago, but no thanks. This comes from someone who loves Rust and what it made possible. However, freedoms are too important to not treat anything that looks like an attack on them as such.

superb_dev 2y ago
Which freedoms are being attacked?
- endgame 2y ago
  Remember when Red Hat tried to lock away the source code to subscribers only? I think they would have preferred not to provide source at all, but the enormous base of GPL code entangled with everything make that impractical. I think we're really going to miss having the fundamental parts of the system available under strong copyleft, and it will be very hard to go back.
  - stouset 2y ago
    Everything in uutils is under the MIT license. The only thing you're missing is the "viral" nature of the GPL. Nobody in the BSD world seems to be particularly suffering under the thumb of unreleased forks of `chown` and `mkdir`.
    - desumeku 2y ago
      Yes, and if BSD was what everyone used for servers instead of Linux, then there would be nothing stopping Oracle from selling you Oracle BSD for a nice subscription price. Of course, they and red hat are already doing this in their own way that gets around the GPL, but a more permissive license would just allow them to do it even more.

stefan_ 2y ago

All you are doing is setting people up for more permanent bash-dash disasters. Isn't there something more useful you could be doing with your time? Say making drag&drop work in snaps (another unforced disaster)?

OsrsNeedsf2P 2y ago
The "security" in Wayland, Snaps and Flatpaks are starting to irk me. Macros aren't working, clipboard forgets my copy, drag n' drop is flimsy - AppImages like Cursor can't even open on vanilla Ubuntu anymore. These "features" no one asked for should be opt-in.
- Etheryte 2y ago
  In a way they are opt-in, as in you opt in by using Ubuntu and opt out by using something else.
  - deleted 2y ago
    [deleted]
- porridgeraisin 2y ago
  Yep, exactly. The whole thing is just theater. I hate it. I know I can just use X11 (and I do), but the already small appetite for developing for linux will be stretched even more thin in the coming years and we will probably only have Wayland apps. The bright side however, is that Wayland could make itself so utterly garbage that people just ignore making apps for it (I'm not counting apps targeting just kde/gnome, which anyway diverge far enough from wayland protocols to warrant being mentioned separately). So we would have X11/KDE/Gnome support for linux apps. That's probably the best case scenario.
- surajrmal 2y ago
  Do you think app permissions in Android and iOS apps are not helpful? There isn't really a reason that the permission models make sense on mobile but not desktop. Desktop applications are inherently more trustworthy. The fact the security features gets in your way is more of a product finesse problem which generally plagues open source projects in general. The technology is not conceptually flawed.

hansvm 2y ago

> Of course they are considered problematic in Rust. > And leaks are hard to code by accident in Rust. > ... I enjoyed this gem and its descendants from the comments. What I see instead, commonly, even in big rust projects, is that it's easy to accidentally define something with a longer lifetime than you intend. Some of that happens accidentally (not recognizing the implications of an extra reference here and there when the language frees things based on static detections of being unused). Much more of it happens because the compiler fights against interesting data structures -- e.g., the pattern of allocating a vec as pseudo-RAM, using indices as pseudo-pointers, and never freeing anything till the container itself is unused. There's nothing wrong with those techniques per se, but the language tends to paint you into a bit of a corner if you're not very good and very careful, so leaks are a fact of life in basically every major Rust project I've seen not written by somebody like BurntSushi, even when that same sort of project would not have a leak in a GC language.

MeetingsBrowser 2y ago
> not recognizing the implications of an extra reference here and there when the language frees things based on static detections of being unused Maybe I’m misunderstanding, but isn’t the point of the borrow checker to throw errors if a reference “outlives” the memory it references? How can an extra reference extend the lifetime?
- hansvm 2y ago
  Rust (most of the time, I'm not arguing about failure modes at all right now, let's pretend it's perfect) drops items when you're done with them. If you use the item longer, you have a longer implicit lifetime. The memory it references will also be claimed for longer (the reference does not outlive its corresponding memory). You only fix that by explicitly considering lifetimes as you write your code -- adding in concrete lifetimes and letting the compiler tell you when you make a mistake (very hard to do as a holistic strategy, so nobody does), or just "git gud" (some people do this, but it takes time, and it's not the norm; you can code at a very high level without developing that particular skill subset, with the nearly inevitable result of "leaky" rust code that's otherwise quite nice).

jvsgx 2y ago

I have a queston: Why do they need their utilities to be written in Rust? Most utilities do not have to face the network, and most don't need to have root privileges. Heck, most of them are one shot programs and don't even need to free memory by the programmer. They could exit and return all the memory space back to the OS.

grandiego 2y ago
> Most utilities do not have to face the network True, but code from those utilities may eventually be used in the network (for example, through copied functionality and shared libraries). Also, a creative pipeline may actually involve them (think of the Unix philosophy.) Eventually plain C has to die or be relegated to unavoidable places like in the assembly cases, even if Rust is not the best alternative after all.
- zifpanachr23 2y ago
  This is based on a common fallacy that people believe about CVEs vs. what actually gets exploited. I would go back and read the papers that got you so aggressively on board the memory safety train one more time and see if you can't detect motivated reasoning.
  - treyd 2y ago
    What is the fallacy, specifically?
  - lolinder 2y ago
    If you have an argument to make, make it. This isn't a classroom and you're not an instructor, assigning homework to people who disagree with you isn't an effective argumentation technique.
k_bx 2y ago
Because things need to keep evolving, we see great new ideas coming from tools which add progress bar, make colorful output, have knowledge about .git structure etc. Current state of things is quite stalled, in my opinion.

zoogeny 2y ago

I hate to admit it, because I don't particularly like Rust, but I'm slowly coming around to the idea it should replace things. The major change is a recent comment I made where I was musing about a future where LLMs actually write most of the code. That isn't a foregone conclusion but the recent improvements in coding LLMs suggests it isn't as far off a future as I once considered. My thought was simple: if I am using a LLM to do the significant portion of generating code, how does that change what I think about the programming language I am using? Does the criteria I use to select the language change? Upon reflection, Rust is probably the best candidate. It has strictness in ways that other languages do not have. And if the LLM is paying most of the cost of keeping the types and lifetimes in order, what do I care if the syntax is ugly? As long as I can read the output of the LLM and verify it (code review it) then I actually want the strictness. I want the most statically analyzable code possible since I have low trust in the LLM. The fact that Rust is also, ahem, blazingly fast, is icing on the cake. As an aside to this aside, I was also thinking about modular kernels, like Minix. I wonder if there is a world where we take a userland like the one Ubuntu is trying and apply it to Minix. And then slowly replace the os modules with ones written in Rust. I think the modularity of something like Minix might be an advantage, but that might just be because I am completely naïve.

Covenant0028 2y ago
I've had similar thoughts as well. Rust or C would also be the ideal candidate from an energy consumption point of view, as they consume way less energy than Python, which is the language that LLMs most often default to in my experience. However it's unlikely LLMs will generate a lot of Rust code. All these LLMs are generating is the most likely next token, based on what they've been trained on. And in their training set, it's likely there is massively more Python and JS code out there than Rust, simply because those are way more popular languages. So with Rust, it's more likely to hallucinate and make mistakes than with Python where the path is much better trodden
- jdright 2y ago
  In practice, it is not what happens. I've been doing AI assisted Rust for some time, and it is very convincing that this is the way. I expect 6mo to 1y to be basically fully automated. Rust has tons of code out there, and quality code. Different from js or Python that has an abundance of low quality to pure garbage code.

jauntywundrkind 2y ago

My long hope is that some day, someone starts to replace the perl-based Debian infrastructure with Rust (or really, anything). I did a decent bit of mod_perl, love & respect perl, but here in 2025, it's pretty terrifying to me that Debian's main dependency is a pretty sizable perl runtime. That there seems to be very little that will budge this. The whole ecosystem is built atop a language that very few people have interest in, that has much less interest & activity than other modern alternatives. It's fine if we start switching the user env over to more popular Rust based utilities. But what I really want is for the OS itself to modernize, to start getting away from it's ancient seemingly-unshakeable legacy. Nothing against Perl, but I'd love to see this family of OSes move beyond being Perl only.

kiney 2y ago
There are non-Perl-based replacements for basically all the system utilities written in Perl in Debian in other distributions, but as things are currently, the Debian versions written in Perl are still unmatched.

worik 2y ago

This is on brand for Canonical. Bleeding edge beta (alpha?) software put in the core of their system Reminds me of when they switched Gnome out for Ubuntu One, no way back if you did 'aptitude full-upgrade'. It was a buggy leaky pos Again, dear friends...

Animats 2y ago

Has someone built Busybox in Rust yet? That would be good for embedded.

chiffaa 2y ago
technically uutils/coreutils should suffice for this goal still as it can build into a single-binary tool a la busybox (iirc that's the default actually)
- lifeinthevoid 2y ago
  Busybox has very basic implementations of the tools though, to keep the size in check.

redder23 2y ago

[dead]

black_13 2y ago

Using Rust is a political solution to deskill a generation of coders to replace higher-cost labor with lower The push for Rust isn't just a technical decision - it's a calculated economic strategy. By forcing rewrites of stable systems in a new language, companies effectively reset the clock on developer experience and expertise. When a C/C++ codebase with 30 years of institutional knowledge gets rewritten in Rust, senior developers with decades of experience suddenly compete on more equal footing with juniors who just graduated. Your 15 years of C++ optimization knowledge? Now worth less than a 22-year-old's six months of Rust bootcamp training. This isn't about memory safety - it's about labor costs. Companies call it "modernization" while quietly erasing the premium they'd otherwise pay for experience. The technical arguments serve as perfect cover for what's really happening: deliberately manufacturing a scenario where they can replace $250K senior engineers with $80K juniors. The pattern is familiar to anyone who's watched other industries. Create artificial obsolescence of existing skills, then exploit the resulting chaos to reset salary expectations and eliminate the leverage that comes with specialized knowledge. This is why language transitions always seem to coincide with hiring freezes and "restructuring." It's never been about technical superiority - it's about breaking labor's bargaining power.

jeroenhd 2y ago
That's an interesting conspiracy theory I haven't heard before. However, I doubt the investment into rewriting large projects makes any financial sense even if the goal is to kick out the experts. Rewrites take years, even if the junior does it for cheaper, and migrations are an existential business risk. If those 15 years of C++ optimization don't provide an advantage over what a 22 year old with half a year of bootcamp can provide for a quarter of the price, then maybe it really is time to stop doing things in C++. The unfortunate truth of programming as a profession is that you need to move with the times. If C++ is on its way out (which I highly doubt), it's time to learn Rust. Most Visual Basic programmers moved on, as did most Fortran programmers, and many C++ programmers when Java hit the scene. When you're making this about labour's bargaining power, you're assuming that young labour is a threat to experience labour. Perhaps that's the case to some extent, as the shortage of people with programming skills that has led to the ridiculously high wages for the software industry is slowly evaporating, but gatekeeping the industry isn't some kind of pro-labour move, it's just selfish.

userbinator 2y ago

Rust and "memory safety" is the current form of corporate authoritarianism. It's ironic that its most vocal advocates are also likely to be the ones complaining about the authoritarianism of the current administration.

wisty 2y ago
Memory safety isn't so corporate, AFAIK. I think it's just a current programmer fad, like pearl's dwim, python's "pythonic", JavaScript having 5 different libraries for every conceivable one-line function, Haskell's um ... I never got Haskell, etc. Every time a language starts taking off, people want to rewrite everything in their language. Rust just has the performance and a few advantages that make it arguably better than C for the things C does, which is a bit cool I guess.
- userbinator 2y ago
  It is corporate, because they realised that things like jailbreaks and rooting could be stopped easily by increasing "security" this way.

nukem222 2y ago

GNU is free to adopt better tools than C/C++. I adore gnu but I refuse to support blatant and obstinant idiocy. Using the license to extort people into supporting C/C++ is just scummy behavior. What the fuck were you doing the last ten years that this wasn't a gnu project? Instead we got fucking systemd and a dozen more knockoffs of the shittiest os on earth

DaSHacka 2y ago
You have the right to not use GNU utilities or GNU/Linux either, you know. No one's forcing you.

tzwhaG 2y ago

It looks like a corporate project with all the required hype and lingo. Ubuntu was nice around version 10, it went downhill with spyware, snap, etc. "There are countless examples in the open source community of tools being re-engineered, and re-imagined using tools and practices that have only relatively recently become available." Recently? You can use Ada or OCaml, which is a better Rust. You can use C with formal proofs and not constantly rewrite everything. But that of course is the point. No rewrites, no easy money for the corporate OSS "developers".

psd1 2y ago
I love the ml language I'm learning and consider it better _than_ any other language I use, but I'm puzzled by "ada or ocaml, which is a better rust" Never written rust, only looked at snippets on blogs, but it visually looks so different to ml Am I being fooled by superficial syntactical differences? Could you explain?

johnisgood 2y ago

Amazing, another reason for avoiding Ubuntu. Many of these utilities have had logic errors in them, you can find them on GitHub issues. sudo, for example, allowed you to bypass through some way I cannot remember. And I bet you they are not a replacement for GNU utilities, i.e. have less features, and are possibly not optimized either, and perhaps they even have different (or less) flags/options. I have written a lot of Bash scripts, I wonder how well (if at all) would work on Ubuntu with the Rust utilities.

Almondsetat 2y ago
What an ignorant comment. The uutils README on GitHub explicitly states in the first section that every discrepancy wrt GNU utilities is considered a bug.
- deleted 2y ago
  [deleted]
- johnisgood 2y ago
  It is a comment coming from pragmatism, not ignorance. At any rate, feel free to look around here: https://github.com/uutils/coreutils/issues?q=is%3Aissue%20state%3Aopen%20state%3Aclosed https://github.com/uutils/coreutils/issues?q=is%3Aissue%20st... It is NOT a replacement of GNU coreutils AT ALL, as of yet. Granted under "Goals" it says "uutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.", but please look around the opened (and closed) issues (since they should tell you about the major, yet simple logic bugs that has occurred). It is definitely not ready, and I am not sure when and if it will be ready. FWIW the README also says: "some options might be missing or different behavior might be experienced.". Future will tell, but right now, it is an extremely bad idea to replace GNU coreutils with Rust's uutils. Do you think otherwise? Elaborate as to why if so.
- lolinder 2y ago
  Your first sentence is totally unnecessary and relies on an uncharitable reading of what they said. It's entirely possible that they knew that a goal of the project was to treat every discrepancy as a bug and were indicating that they were of the opinion that there were plenty of bugs left and no evidence that they would ever be all squashed. Also, while we're slinging the README around, here's the first paragraph: > uutils coreutils is a cross-platform reimplementation of the GNU coreutils in Rust. While all programs have been implemented, some options might be missing or different behavior might be experienced. The "ignorant comment" above was actually just pointing out the thing that the developers thought was second-most-important for people to know—right after the fact that it's a reimplementation.

alextingle 2y ago

This is the worst kind of busy-work. Rewriting something for the sake of it is terrible practice. There's a lot of refreshing energy amongst Rust coders eager to produce better, more modern command-line tools. That's amazing, and a real benefit to everyone. But rewriting simple, decades-old, perfectly functional tools, with the explicit goal of not improving them is just a self-absorbed hobby. And a dangerous one at that - any new code will contain bugs, and the best way to avoid that is not to write code if you don't have to.

immibis 2y ago
It's not for the sake of it - it's to have MIT-licensed (able to be propriotized) coreutils. GPL is a thorn in the side to anyone who wishes to EEE it.
- IshKebab 2y ago
  That isn't the motivation. It's about "resilience, performance and maintainability". I doubt they'll get noticeably better performance (the main GNU tools are already very optimised). I'm not sure they really lack in resilience. And I don't think memory safety is a big factor here. Maintenance is definitely a big plus though. It will be much nicer to work on modern Rust code than ancient C.
  - immibis 2y ago
    To clarify, you think the obvious benefit that is something several organizations obviously want isn't the motivation, but improvements to 3 things that probably won't be improved are the real motivations?
  - psd1 2y ago
    How much maintenance do the tools need currently, and how does it compare to the effort? i am surprised by the implication
  - codeguro 2y ago
    If you look a bit deeper, this project actually cares deeply about its license, and is going out of its way to choose the license it is using, ignore complaints, and avoid ending up GPL. https://www.youtube.com/watch?v=5qTyyMyU2hQ https://www.youtube.com/watch?v=5qTyyMyU2hQ In an interview with FOSS Weekly, Sylvestre Ledru (the main developer, who curiously has a background working on Debian and Firefox, before ending up getting seduced by the clang/LLVM ecosystem), firmly states "it is not about security".

bravetraveler 2y ago

Canonical making light of licensing again, no surprise here. This has ulterior motive written all over it. Best outcome: nothing happens.