5 ms·

Carefully but Purposefully Oxidising Ubuntu

84 points by wicket 2y ago

superkuh 2y ago
Porting of stable tools to an unstable (rapidly changing) language which can only successfully compile projects if the distro toolchain is rolling (or constantly updated outside of repos every few months, ala curl|sh, rustup, etc). Ubuntu is not a rolling distro. This is a bad match.
- jerf 2y ago
  It seems like the first step should be packaging this up as a metapackage or something for interested parties and having at least a full unstable release cycle where that's optional and tested before replacing such utilities for what is oestensibly an end-user distribution for less-technical people who will not be able to fix things going wrong deep in the heart of shell scripts. I'm all for Rusting more-or-less all the things, but Rust isn't actually magic or anything. Things aren't automatically better just because Rust. And as someone who keeps at least modest track of CVEs and such, these utilities aren't exactly throwing CVEs out left right front and center. I don't like the amount of C in the world but being run billions of times a day in every conceivable environment is itself a really, really good test. We well know from history, still not always perfect, but honestly these aren't the things that need a priority Rusting; it's the code that doesn't fit that description that really needs it.
  - ericjmorey 2y ago
    something like this?: https://github.com/jnsgruk/oxidizr https://github.com/jnsgruk/oxidizr
    - superkuh 2y ago
      I appreciate your comment and the humor in the situation since the original topic does everything the post you're glibly replying to requests. And so you just had to re-link it. But it's still rolling-only code. And having to change it for every ubuntu release (even if per-release everything is targeted to the static version of rustc in Ubuntu) is silly since cargo editions won't save you. And since anyone actually compiling rust programs will have had to update their rustc constantly they'll have to do some containerization or something to compile the $version-written tool for $ubuntu-release-number.
  - HumanOstrich 2y ago
    That's a lot of text to say "rewrite everything else in Rust, just not this".
    - jerf 2y ago
      No, it's a lot of text to say "before replacing so many fundamental packages in an end-user distro at least beta test it". By all means, rewrite it in Rust, but don't go slamming it in to Ubuntu. Debian unstable. Gentoo. Something other than what I put on my boomer-generation, stereotypical "knows nothing about computers" father-in-law's laptop so I don't have to support him every week.
      - HumanOstrich 2y ago
        > By all means, rewrite it in Rust No
      - sophacles 2y ago
        Good thing the actual article is introducing a tool that makes it easy for people to switch between the rust core-utils and the gnu ones. Almost as if it enables a wide-spread, opt-in beta...
- stonemetal12 2y ago
  Rust editions should take care of that. They currently claim they will support previous editions forever. Which is obviously silly, but hopefully ends up at least as good as GCC is at supporting old code.
  - steveklabnik 2y ago
    It may sound obviously silly, but if you know how the edition system works, it’s not. Most things land in all editions, the only things that are edition specific are the “breaking” changes, and those have such limited scope that it’s not difficult to support all of them.
    - estebank 2y ago
      Iirc when I checked there were about ~25 if checks per edition on the compiler. I feel like we can go for a while at that rate without it being a big maintenance burden.
      - steveklabnik 2y ago
        Nice, yeah that's not too bad at all.
- bitwize 2y ago
  But the Rust toolchain adopted for a given Ubuntu version can compile the Rust core utilities for that version. I don't see what the stability problem is here. Furthermore, doing this in Ubuntu will nudge other distros to do the same, furthering the long-term goal of the Rust project: to rid the world of C, C++, and all their scourges.
  - TingPing 2y ago
    Rust projects do not care about the limits of a distro, they just say use rustup, so future fixes will be left out of Ubuntu sometimes.
    - SAI_Peregrinus 2y ago
      That's hardly unique to Rust projects. Quite a few projects in other languages (e.g. Python) don't care about distro limitations & fixes get left out of Ubuntu. Even C has that issue. "Stable" distros only get the updates the maintainers can backport.
      - TingPing 2y ago
        Sure but the “stable tools” are currently C and those projects probably build on a decade old distro. Replacing them with faster moving projects will hit issues.
- tialaramex 2y ago
  This project actually says "The current Minimum Supported Rust Version (MSRV) is 1.82.0" Rust 1.82 was released in October last year. It looks like this gets bumped periodically, but it isn't pulled to latest and presumably a bugfix release, if they were doing those, wouldn't change MSRV so that seems basically fine?
Y_Y 2y ago
How about Ubuntu just sticks to their area of competency repainting Debian. Remember when the switched they shell to dash? Not to mention, Upstart, Mir, Unity, Snap.
- actionfromafar 2y ago
  They should have kept at Upstart, but instead we got punished for our sins.
- klysm 2y ago
  Investor money throws out attempts like tentacles that get slapped away by the community. It will continue to happen
  - actionfromafar 2y ago
    Didn’t slap systemd hard enough.
    - thyristan 2y ago
      Upstart was like slapping with a broken hand. Hurts the slapper much more than the slapee.
  - AdmiralAsshat 2y ago
    What "investors" are pushing rust? What is the end goal?
    - knowitnone 2y ago
      topic was about ubuntu
- ahepp 2y ago
  I thought dash was an upstream Debian thing? But I agree in principle
  - 2y ago
glitchc 2y ago
Are there any security vulnerabilities in ls, chgrp, chown etc. that requires this change? Or this just more Rust evangelism?
- steveklabnik 2y ago
  https://news.ycombinator.com/item?id=43344829 https://news.ycombinator.com/item?id=43344829
- stonemetal12 2y ago
  There have been CVEs in core utils. I am not aware of any that Rust would prevent.
- thyristan 2y ago
  I'd say misplaced evangelism. ls, chgrp, chown, etc are applications that the current user will use to interactively work with them. Or maybe use in a shell script. They are not to be exposed to malicious inputs, so any bugs are usually not security problems, because you can't really do anything that the user couldn't do anyways. There is no security boundary, so nothing to secure there. However, if you e.g. write your webserver as a shell script or using shell commands you are doing it wrong and you deserve the evil things an attacker does to you. Also, very often, the insecurity is codified in the relevant standards such as POSIX, so you cannot really fix anything without breaking everything. E.g. newlines and various kinds of whitespace characters in filenames are a huge pain to handle safely in shell commands and especially shell scripts, if possible at all. Because shells do split things at any whitespace (unless quoted properly, which is hard to impossible to do) and shell commands usually separate their stdin/stdout at newlines (unless you know about -print0 and everything in your pipe does as well...). None of this is fixed by rust, everything could be fixed by throwing away existing standards first, but then the language doesn't matter.
  - yjftsjthsd-h 2y ago
    > ls, chgrp, chown, etc are applications that the current user will use to interactively work with them. Or maybe use in a shell script. They are not to be exposed to malicious inputs, so any bugs are usually not security problems, because you can't really do anything that the user couldn't do anyways. There is no security boundary, so nothing to secure there. I dunno, I'd expect that you could ls -l untrusted.exe mv untrusted.exe untrusted.exe.donotrun chmod 600 untrusted.exe.donotrun sha256sum untrusted.exe.donotrun without anything bad happening. That said, I'd like some evidence that GNU's coreutils aren't already safe; I suspect that their limited scope means there's minimal exposure even when operating on untrusted inputs (note that in my example there, only hashing the file actually involves its contents).
larsnystrom 2y ago
> 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. Is performance a frequent rationale for rewriting C applications in Rust?
- klysm 2y ago
  No I don’t believe so
- vacuity 2y ago
  No. It's normally memory safety and/or ease of tooling/coding/whatever.
- dralley 2y ago
  No - unless the rationale was taking better advantage of multithreading, which Rust does make easier. But that's at least partially a maintainability argument, not just a performance one. Rust can make achieving higher levels of performance easier and less risky than doing so in C or C++ would have, but you do still have to work for it a little, it's not going to be magically faster.
  - eej71 2y ago
    I think that's only generally true for the period of time where the new tool has yet to achieve full functional parity with what it replaced. As that functionality gap is closed, the performance increase usually declines too.
    - burntsushi 2y ago
      One counter example: $ curl -LO 'https://burntsushi.net/stuff/subtitles2016-sample.en.gz' $ gzip -d subtitles2016-sample.en.gz $ time rg -c 'Sherlock Holmes' subtitles2016-sample.en 629 real 0.099 user 0.063 sys 0.035 maxmem 923 MB faults 0 $ time LC_ALL=C grep -c 'Sherlock Holmes' subtitles2016-sample.en 629 real 0.368 user 0.285 sys 0.082 maxmem 25 MB faults 0 $ time rg -c '^\w{42}$' subtitles2016-sample.en 1 real 1.195 user 1.162 sys 0.031 maxmem 928 MB faults 0 $ time LC_ALL=en_US.UTF-8 grep -c -E '^\w{42}$' subtitles2016-sample.en 1 real 21.261 user 21.151 sys 0.088 maxmem 25 MB faults 0 (Yes, ripgrep is matching a Unicode-aware `\w` above, which is why I turned on GNU grep's locale feature. To make it apples-to-apples.) Now to be fair, you did say "usually." But actually, sometimes, even when functional parity[1] has been achieved (and then some), perf can still be wildly improved. [1]: ripgrep is not compatible with GNU grep, but there shouldn't be much you can do with grep that you can't do with ripgrep. The main thing would be stuff related to the marriage of locales and regexes, e.g., ripgrep can't do `echo 'pokémon' | LC_ALL=en_US.UTF-8 grep 'pok[[=e=]]mon'`. Conversely, there's oodles that ripgrep can do that GNU grep can't. For example, transparently searching UTF-16. POSIX forbids such wildly popular use cases (e.g., on Windows).
amiga386 2y ago
Snaps were the first shot across the bow. This is another. Switch to Debian before this happens.
- juujian 2y ago
  Switched to Debian, not looking back. Everything just works, almost like Ubuntu had promised it would.
- deleted 2y ago
  [deleted]
- anilakar 2y ago
  Ads in the system logs were the last straw for me.
  - mystified5016 2y ago
    Yup, I jumped ship after that one. Previously all of my servers ran Ubuntu, now it's straight Debian or Arch in some situations. Canonical is just so gross at every level. I saw a job posting in my area recently and it was the slimiest corpo-speak job post I've seen in.. well, a couple of weeks at least.
  - everybodyknows 2y ago
    Ah, you mean for their "security upgrades" to LTS versions -- presented by 'apt upgrade' since at least 20.04?
    - knowitnone 2y ago
      because that's a great place to put it...in the logs...when we are troubleshooting an issue \s
    - anilakar 2y ago
      Logging in triggers motd-news.service that prints whatever ad they're currently running into the journal.
Kwpolska 2y ago
On the one hand, having less RMS and GNU software in the world is better. On the other hand, I'd prefer for basic system tools to be provided by an established and well-funded project, and not just switch to something written in Rust because Rust is the hype these days.
- yjftsjthsd-h 2y ago
  > On the one hand, having less RMS and GNU software in the world is better. Why?
  - Kwpolska 2y ago
    For RMS specifically: https://stallman-report.org/ https://stallman-report.org/ The GNU project has an extremely utopian and unrealistic vision of open-source.
    - sham1 2y ago
      Since we're talking about the "utopian and unrealistic vision" of the GNU project, I'd just like to pedantically note that the GNU project has no vision for "open source" but Free software. Indeed, the Chief GNUisance himself is very adamant about that[0]. Of course, the GNU project is a lot bigger than just RMS, and we shouldn't condemn the project and its struggle against non-free software just because RMS is problematic. [0]: <https://www.gnu.org/philosophy/open-source-misses-the-point.html https://www.gnu.org/philosophy/open-source-misses-the-point....>
    - amiga386 2y ago
      For the rebuttal to the Stallman Report: https://stallmansupport.org/ https://stallmansupport.org/ For the details on the author of the Stallman Report -- Drew Devault -- who tried to pretend he didn't write it, see https://dmpwn.info/ https://dmpwn.info/ Also, please consider not using the term "open-source". It's a term designed to pander to businessmen, who are afraid of the Free Software movement's goals, and to muddy the waters as to what rights you should have with such software.
_ink_ 2y ago
Please fix fractional scaling first. The performance is still bad.
- SAI_Peregrinus 2y ago
  Have you tried Plasma on Wayland? I've found it has very good fractional scaling support, better than Gnome or Windows. I don't own a Mac so can't compare to MacOS, and haven't used X in years, but fractional scaling with Plasma has been problem-free for me. No weird window resizing like Windows does, no blurry text, just everything on different resolution monitors staying the same visual size.
  - _ink_ 2y ago
    I haven't. Thanks for the suggestion, I might give it a go. I returned to Linux this year, after 10 or so years of Windows. My hope was in 2025 we have reached a state where you can install a distro and be done with it. Seems like endless hours of tweaking are still required :(
  - superkuh 2y ago
    Your scaling with the Plasma compositor implementing the Wayland protocol will depend heavily on the graphical toolkit the specific application is using. Gtk vs Qt vs Flutter, etc. Each of these has to implement custom backends for the waylands and that work is far from done re: fractional scaling. And each wayland compositor is quite a bit different too since the core wayland protocol is so slim and each has to implement core features their own way. Whereas there's just one thing to target with X11. Far more consistent, less buggy overall. At least up to now. But with megacorps like IBM/Red Hat having their employees abandon X11 entirely for Gtk5, etc, it's gonna be rough going everywhere.
pizlonator 2y ago
I think that all of those tools can be recompiled with Fil-C today and you get memory safety while retaining the original functionality.
- badmintonbaseba 2y ago
  What about performance?
  - pizlonator 2y ago
    For these tools, you won’t notice.
    - badmintonbaseba 2y ago
      What modifications are needed to run through Fil-C, if any? It looks like you forked some of the software to run through Fil-C. Are you subsetting the language, or do those libraries/applications run into some "benign" UB under normal operation that is caught by Fil-C?
      - pizlonator 2y ago
        > What modifications are needed to run through Fil-C, if any? Most likely none. The most likely bugs you'll encounter are due to Fil-C using musl, not glibc (that always leads to some incompatibilities for GNU code). > Are you subsetting the language No. > or do those libraries/applications run into some "benign" UB under normal operation that is caught by Fil-C? Sometimes, but rarely.
        badmintonbaseba 2y ago
        Super interesting. Tempting to hook it up with conan to build our dependencies and set it up with our unit tests at least. If incompatibilities are mostly due to the libc then I don't think any of our C++ dependencies would care.
  - 2y ago
Marlinski 2y ago
[flagged]
- ape4 2y ago
  Good idea, we should rewrite systemd in rust ;/
- knowitnone 2y ago
  Don't like it, don't use it - same with systemd. I'm not sure what the complaint is. When Go is used to rewrite something, nobody complains. Also, you should find out what a cult is and do some research on past cults before you start accusing a project of being a cult.
  - amiga386 2y ago
    We're commenting on an Ubuntu discussion where an Ubuntu developer is proposing to make this mandatory for Ubuntu. Even when the alternatives system is suggested, that's quickly dismissed, because the real aim is to boot out coreutils permanently and make written-in-Rust the default. I don't mind people writing things in their favourite languages; I do mind them trying to compel me to adopt them through distro shenanigans. Even though Debian adopted systemd, it didn't do it without a _lot_ of discussion and voting.
    - steveklabnik 2y ago
      > Even when the alternatives system is suggested, that's quickly dismissed, because the real aim is to boot out coreutils permanently and make written-in-Rust the default. They have good technical reasons why they aren't using alternatives at this stage, and it's also suggested that if this gets closer to being real, the alternative system will be used.
      - yjftsjthsd-h 2y ago
        What are those technical reasons? The only answer I see in the linked thread is https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995/8 https://discourse.ubuntu.com/t/carefully-but-purposefully-ox... which points out that it requires cooperation from the existing package (fair), but also notes that "Diversions would work"... before moving on and not even hinting at why, then, diversions were not used and a new tool was thrown in the mix.
lproven 2y ago
I am curious -- I asked on Discourse as well... How this will work on CPU architectures other than x86 and Arm? Ubuntu also supports ppc64le and IBM s390. Is LLVM usefully able to built binaries from Rust code for those architectures now?
- sophacles 2y ago
  Well the oxidizr tool discussed in the article is for making the choice of the rust tools or the classic C ones simple. Presumably for architectures not supported by rust you'd do something like "oxidizr use gnu-tools".
- steveklabnik 2y ago
  powerpc64le-unknown-linux-gnu is supported, s390x-unknown-linux-gnu isn't s390 but I think Ubuntu supports s390x, so I believe that is the case as well.
- WhyNotHugo 2y ago
  Alpine supports x86, x86_64, armhf, armv7, aarch64, ppc64le, s390x, riscv64 and loongarch64. Rust and a great deal of Rust-based packages build for all these architectures. I'm sure there are a few more supported architectures.
blankx32 2y ago
We can’t leave things alone
xiphias2 2y ago
While changing the core packages as a rewrite looks easy (,,just reimplement ls''), compatibility/stability may mean reproducing all the tiny but not safety critical bugs as well. There's enough data from the Android ecosystem that it's much better to focus oxidisation on new software instead of old.
- steveklabnik 2y ago
  They're using the upstream test suite to track this: https://github.com/uutils/coreutils-tracking https://github.com/uutils/coreutils-tracking
burntsushi 2y ago
I mentioned this on reddit, but AFAIK, the uutils project doesn't yet support locales: https://github.com/uutils/coreutils/issues/3997 https://github.com/uutils/coreutils/issues/3997 I'm not any more a fan of POSIX locales than the next person[1], but AIUI, that seems a likely requirement for uutils to be used in a distro like Ubuntu. I'd be curious how they plan to address this. At least from my perspective, unless uutils has already been designed to account for locales from the start (I don't know if it has), it seems likely that a significant investment of time will be required to add support for it. [1]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
Spivak 2y ago
Why oxidizer over the existing Debian alternatives system? It's designed for this exact use case and already works with many existing packages. The author's response in the comments was a basically a non-answer which doesn't exactly inspire confidence. > Long-term, my concern would be that this may somewhat muddy the picture for which packages need substantive fixes. If it is extremely easy to just revert, what is the benefit to switching? ??? Is this not the ideal situation? It provides low friction both for moving to the new cool thing and moving back to the existing tools when you have software that hard depends on GNU coreutils. You want the changeover to be high risk because it's hard to undo? I guess that's one way to force yourself to commit but the real users on the ground won't be happy when going to the LTS is substantially more work. This would be 3 different symlink managers in Ubuntu all used for different sets of software. The alternatives system at least has the benefit of integrating tightly with apt.
- deleted 2y ago
  [deleted]
vimarsh6739 2y ago
To me, this feels less about Rust and more about moving away from copyleft.
- MiiMe19 2y ago
  This is the truth of it. They want to take everything proprietary to make more money off of it.

84 points by wicket 2y ago

Porting of stable tools to an unstable (rapidly changing) language which can only successfully compile projects if the distro toolchain is rolling (or constantly updated outside of repos every few months, ala curl|sh, rustup, etc). Ubuntu is not a rolling distro. This is a bad match.

jerf 2y ago
It seems like the first step should be packaging this up as a metapackage or something for interested parties and having at least a full unstable release cycle where that's optional and tested before replacing such utilities for what is oestensibly an end-user distribution for less-technical people who will not be able to fix things going wrong deep in the heart of shell scripts. I'm all for Rusting more-or-less all the things, but Rust isn't actually magic or anything. Things aren't automatically better just because Rust. And as someone who keeps at least modest track of CVEs and such, these utilities aren't exactly throwing CVEs out left right front and center. I don't like the amount of C in the world but being run billions of times a day in every conceivable environment is itself a really, really good test. We well know from history, still not always perfect, but honestly these aren't the things that need a priority Rusting; it's the code that doesn't fit that description that really needs it.
- ericjmorey 2y ago
  something like this?: https://github.com/jnsgruk/oxidizr https://github.com/jnsgruk/oxidizr
  - superkuh 2y ago
    I appreciate your comment and the humor in the situation since the original topic does everything the post you're glibly replying to requests. And so you just had to re-link it. But it's still rolling-only code. And having to change it for every ubuntu release (even if per-release everything is targeted to the static version of rustc in Ubuntu) is silly since cargo editions won't save you. And since anyone actually compiling rust programs will have had to update their rustc constantly they'll have to do some containerization or something to compile the $version-written tool for $ubuntu-release-number.
- HumanOstrich 2y ago
  That's a lot of text to say "rewrite everything else in Rust, just not this".
  - jerf 2y ago
    No, it's a lot of text to say "before replacing so many fundamental packages in an end-user distro at least beta test it". By all means, rewrite it in Rust, but don't go slamming it in to Ubuntu. Debian unstable. Gentoo. Something other than what I put on my boomer-generation, stereotypical "knows nothing about computers" father-in-law's laptop so I don't have to support him every week.
    - HumanOstrich 2y ago
      > By all means, rewrite it in Rust No
    - sophacles 2y ago
      Good thing the actual article is introducing a tool that makes it easy for people to switch between the rust core-utils and the gnu ones. Almost as if it enables a wide-spread, opt-in beta...
stonemetal12 2y ago
Rust editions should take care of that. They currently claim they will support previous editions forever. Which is obviously silly, but hopefully ends up at least as good as GCC is at supporting old code.
- steveklabnik 2y ago
  It may sound obviously silly, but if you know how the edition system works, it’s not. Most things land in all editions, the only things that are edition specific are the “breaking” changes, and those have such limited scope that it’s not difficult to support all of them.
  - estebank 2y ago
    Iirc when I checked there were about ~25 if checks per edition on the compiler. I feel like we can go for a while at that rate without it being a big maintenance burden.
    - steveklabnik 2y ago
      Nice, yeah that's not too bad at all.
bitwize 2y ago
But the Rust toolchain adopted for a given Ubuntu version can compile the Rust core utilities for that version. I don't see what the stability problem is here. Furthermore, doing this in Ubuntu will nudge other distros to do the same, furthering the long-term goal of the Rust project: to rid the world of C, C++, and all their scourges.
- TingPing 2y ago
  Rust projects do not care about the limits of a distro, they just say use rustup, so future fixes will be left out of Ubuntu sometimes.
  - SAI_Peregrinus 2y ago
    That's hardly unique to Rust projects. Quite a few projects in other languages (e.g. Python) don't care about distro limitations & fixes get left out of Ubuntu. Even C has that issue. "Stable" distros only get the updates the maintainers can backport.
    - TingPing 2y ago
      Sure but the “stable tools” are currently C and those projects probably build on a decade old distro. Replacing them with faster moving projects will hit issues.
tialaramex 2y ago
This project actually says "The current Minimum Supported Rust Version (MSRV) is 1.82.0" Rust 1.82 was released in October last year. It looks like this gets bumped periodically, but it isn't pulled to latest and presumably a bugfix release, if they were doing those, wouldn't change MSRV so that seems basically fine?

Y_Y 2y ago

How about Ubuntu just sticks to their area of competency repainting Debian. Remember when the switched they shell to dash? Not to mention, Upstart, Mir, Unity, Snap.

actionfromafar 2y ago
They should have kept at Upstart, but instead we got punished for our sins.
klysm 2y ago
Investor money throws out attempts like tentacles that get slapped away by the community. It will continue to happen
- actionfromafar 2y ago
  Didn’t slap systemd hard enough.
  - thyristan 2y ago
    Upstart was like slapping with a broken hand. Hurts the slapper much more than the slapee.
- AdmiralAsshat 2y ago
  What "investors" are pushing rust? What is the end goal?
  - knowitnone 2y ago
    topic was about ubuntu
ahepp 2y ago
I thought dash was an upstream Debian thing? But I agree in principle
- 2y ago

glitchc 2y ago

Are there any security vulnerabilities in ls, chgrp, chown etc. that requires this change? Or this just more Rust evangelism?

steveklabnik 2y ago
https://news.ycombinator.com/item?id=43344829 https://news.ycombinator.com/item?id=43344829
stonemetal12 2y ago
There have been CVEs in core utils. I am not aware of any that Rust would prevent.
thyristan 2y ago
I'd say misplaced evangelism. ls, chgrp, chown, etc are applications that the current user will use to interactively work with them. Or maybe use in a shell script. They are not to be exposed to malicious inputs, so any bugs are usually not security problems, because you can't really do anything that the user couldn't do anyways. There is no security boundary, so nothing to secure there. However, if you e.g. write your webserver as a shell script or using shell commands you are doing it wrong and you deserve the evil things an attacker does to you. Also, very often, the insecurity is codified in the relevant standards such as POSIX, so you cannot really fix anything without breaking everything. E.g. newlines and various kinds of whitespace characters in filenames are a huge pain to handle safely in shell commands and especially shell scripts, if possible at all. Because shells do split things at any whitespace (unless quoted properly, which is hard to impossible to do) and shell commands usually separate their stdin/stdout at newlines (unless you know about -print0 and everything in your pipe does as well...). None of this is fixed by rust, everything could be fixed by throwing away existing standards first, but then the language doesn't matter.
- yjftsjthsd-h 2y ago
  > ls, chgrp, chown, etc are applications that the current user will use to interactively work with them. Or maybe use in a shell script. They are not to be exposed to malicious inputs, so any bugs are usually not security problems, because you can't really do anything that the user couldn't do anyways. There is no security boundary, so nothing to secure there. I dunno, I'd expect that you could ls -l untrusted.exe mv untrusted.exe untrusted.exe.donotrun chmod 600 untrusted.exe.donotrun sha256sum untrusted.exe.donotrun without anything bad happening. That said, I'd like some evidence that GNU's coreutils aren't already safe; I suspect that their limited scope means there's minimal exposure even when operating on untrusted inputs (note that in my example there, only hashing the file actually involves its contents).

larsnystrom 2y ago

> 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. Is performance a frequent rationale for rewriting C applications in Rust?

klysm 2y ago
No I don’t believe so
vacuity 2y ago
No. It's normally memory safety and/or ease of tooling/coding/whatever.
dralley 2y ago
No - unless the rationale was taking better advantage of multithreading, which Rust does make easier. But that's at least partially a maintainability argument, not just a performance one. Rust can make achieving higher levels of performance easier and less risky than doing so in C or C++ would have, but you do still have to work for it a little, it's not going to be magically faster.
- eej71 2y ago
  I think that's only generally true for the period of time where the new tool has yet to achieve full functional parity with what it replaced. As that functionality gap is closed, the performance increase usually declines too.
  - burntsushi 2y ago
    One counter example: $ curl -LO 'https://burntsushi.net/stuff/subtitles2016-sample.en.gz' $ gzip -d subtitles2016-sample.en.gz $ time rg -c 'Sherlock Holmes' subtitles2016-sample.en 629 real 0.099 user 0.063 sys 0.035 maxmem 923 MB faults 0 $ time LC_ALL=C grep -c 'Sherlock Holmes' subtitles2016-sample.en 629 real 0.368 user 0.285 sys 0.082 maxmem 25 MB faults 0 $ time rg -c '^\w{42}$' subtitles2016-sample.en 1 real 1.195 user 1.162 sys 0.031 maxmem 928 MB faults 0 $ time LC_ALL=en_US.UTF-8 grep -c -E '^\w{42}$' subtitles2016-sample.en 1 real 21.261 user 21.151 sys 0.088 maxmem 25 MB faults 0 (Yes, ripgrep is matching a Unicode-aware `\w` above, which is why I turned on GNU grep's locale feature. To make it apples-to-apples.) Now to be fair, you did say "usually." But actually, sometimes, even when functional parity[1] has been achieved (and then some), perf can still be wildly improved. [1]: ripgrep is not compatible with GNU grep, but there shouldn't be much you can do with grep that you can't do with ripgrep. The main thing would be stuff related to the marriage of locales and regexes, e.g., ripgrep can't do `echo 'pokémon' | LC_ALL=en_US.UTF-8 grep 'pok[[=e=]]mon'`. Conversely, there's oodles that ripgrep can do that GNU grep can't. For example, transparently searching UTF-16. POSIX forbids such wildly popular use cases (e.g., on Windows).

amiga386 2y ago

Snaps were the first shot across the bow. This is another. Switch to Debian before this happens.

juujian 2y ago
Switched to Debian, not looking back. Everything just works, almost like Ubuntu had promised it would.
deleted 2y ago
[deleted]
anilakar 2y ago
Ads in the system logs were the last straw for me.
- mystified5016 2y ago
  Yup, I jumped ship after that one. Previously all of my servers ran Ubuntu, now it's straight Debian or Arch in some situations. Canonical is just so gross at every level. I saw a job posting in my area recently and it was the slimiest corpo-speak job post I've seen in.. well, a couple of weeks at least.
- everybodyknows 2y ago
  Ah, you mean for their "security upgrades" to LTS versions -- presented by 'apt upgrade' since at least 20.04?
  - knowitnone 2y ago
    because that's a great place to put it...in the logs...when we are troubleshooting an issue \s
  - anilakar 2y ago
    Logging in triggers motd-news.service that prints whatever ad they're currently running into the journal.

Kwpolska 2y ago

On the one hand, having less RMS and GNU software in the world is better. On the other hand, I'd prefer for basic system tools to be provided by an established and well-funded project, and not just switch to something written in Rust because Rust is the hype these days.

yjftsjthsd-h 2y ago
> On the one hand, having less RMS and GNU software in the world is better. Why?
- Kwpolska 2y ago
  For RMS specifically: https://stallman-report.org/ https://stallman-report.org/ The GNU project has an extremely utopian and unrealistic vision of open-source.
  - sham1 2y ago
    Since we're talking about the "utopian and unrealistic vision" of the GNU project, I'd just like to pedantically note that the GNU project has no vision for "open source" but Free software. Indeed, the Chief GNUisance himself is very adamant about that[0]. Of course, the GNU project is a lot bigger than just RMS, and we shouldn't condemn the project and its struggle against non-free software just because RMS is problematic. [0]: <https://www.gnu.org/philosophy/open-source-misses-the-point.html https://www.gnu.org/philosophy/open-source-misses-the-point....>
  - amiga386 2y ago
    For the rebuttal to the Stallman Report: https://stallmansupport.org/ https://stallmansupport.org/ For the details on the author of the Stallman Report -- Drew Devault -- who tried to pretend he didn't write it, see https://dmpwn.info/ https://dmpwn.info/ Also, please consider not using the term "open-source". It's a term designed to pander to businessmen, who are afraid of the Free Software movement's goals, and to muddy the waters as to what rights you should have with such software.

_ink_ 2y ago

Please fix fractional scaling first. The performance is still bad.

SAI_Peregrinus 2y ago
Have you tried Plasma on Wayland? I've found it has very good fractional scaling support, better than Gnome or Windows. I don't own a Mac so can't compare to MacOS, and haven't used X in years, but fractional scaling with Plasma has been problem-free for me. No weird window resizing like Windows does, no blurry text, just everything on different resolution monitors staying the same visual size.
- _ink_ 2y ago
  I haven't. Thanks for the suggestion, I might give it a go. I returned to Linux this year, after 10 or so years of Windows. My hope was in 2025 we have reached a state where you can install a distro and be done with it. Seems like endless hours of tweaking are still required :(
- superkuh 2y ago
  Your scaling with the Plasma compositor implementing the Wayland protocol will depend heavily on the graphical toolkit the specific application is using. Gtk vs Qt vs Flutter, etc. Each of these has to implement custom backends for the waylands and that work is far from done re: fractional scaling. And each wayland compositor is quite a bit different too since the core wayland protocol is so slim and each has to implement core features their own way. Whereas there's just one thing to target with X11. Far more consistent, less buggy overall. At least up to now. But with megacorps like IBM/Red Hat having their employees abandon X11 entirely for Gtk5, etc, it's gonna be rough going everywhere.

pizlonator 2y ago

I think that all of those tools can be recompiled with Fil-C today and you get memory safety while retaining the original functionality.

badmintonbaseba 2y ago
What about performance?
- pizlonator 2y ago
  For these tools, you won’t notice.
  - badmintonbaseba 2y ago
    What modifications are needed to run through Fil-C, if any? It looks like you forked some of the software to run through Fil-C. Are you subsetting the language, or do those libraries/applications run into some "benign" UB under normal operation that is caught by Fil-C?
    - pizlonator 2y ago
      > What modifications are needed to run through Fil-C, if any? Most likely none. The most likely bugs you'll encounter are due to Fil-C using musl, not glibc (that always leads to some incompatibilities for GNU code). > Are you subsetting the language No. > or do those libraries/applications run into some "benign" UB under normal operation that is caught by Fil-C? Sometimes, but rarely.
      - badmintonbaseba 2y ago
        Super interesting. Tempting to hook it up with conan to build our dependencies and set it up with our unit tests at least. If incompatibilities are mostly due to the libc then I don't think any of our C++ dependencies would care.
- 2y ago

Marlinski 2y ago

[flagged]

ape4 2y ago
Good idea, we should rewrite systemd in rust ;/
knowitnone 2y ago
Don't like it, don't use it - same with systemd. I'm not sure what the complaint is. When Go is used to rewrite something, nobody complains. Also, you should find out what a cult is and do some research on past cults before you start accusing a project of being a cult.
- amiga386 2y ago
  We're commenting on an Ubuntu discussion where an Ubuntu developer is proposing to make this mandatory for Ubuntu. Even when the alternatives system is suggested, that's quickly dismissed, because the real aim is to boot out coreutils permanently and make written-in-Rust the default. I don't mind people writing things in their favourite languages; I do mind them trying to compel me to adopt them through distro shenanigans. Even though Debian adopted systemd, it didn't do it without a _lot_ of discussion and voting.
  - steveklabnik 2y ago
    > Even when the alternatives system is suggested, that's quickly dismissed, because the real aim is to boot out coreutils permanently and make written-in-Rust the default. They have good technical reasons why they aren't using alternatives at this stage, and it's also suggested that if this gets closer to being real, the alternative system will be used.
    - yjftsjthsd-h 2y ago
      What are those technical reasons? The only answer I see in the linked thread is https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995/8 https://discourse.ubuntu.com/t/carefully-but-purposefully-ox... which points out that it requires cooperation from the existing package (fair), but also notes that "Diversions would work"... before moving on and not even hinting at why, then, diversions were not used and a new tool was thrown in the mix.

lproven 2y ago

I am curious -- I asked on Discourse as well... How this will work on CPU architectures other than x86 and Arm? Ubuntu also supports ppc64le and IBM s390. Is LLVM usefully able to built binaries from Rust code for those architectures now?

sophacles 2y ago
Well the oxidizr tool discussed in the article is for making the choice of the rust tools or the classic C ones simple. Presumably for architectures not supported by rust you'd do something like "oxidizr use gnu-tools".
steveklabnik 2y ago
powerpc64le-unknown-linux-gnu is supported, s390x-unknown-linux-gnu isn't s390 but I think Ubuntu supports s390x, so I believe that is the case as well.
WhyNotHugo 2y ago
Alpine supports x86, x86_64, armhf, armv7, aarch64, ppc64le, s390x, riscv64 and loongarch64. Rust and a great deal of Rust-based packages build for all these architectures. I'm sure there are a few more supported architectures.

blankx32 2y ago

We can’t leave things alone

xiphias2 2y ago

While changing the core packages as a rewrite looks easy (,,just reimplement ls''), compatibility/stability may mean reproducing all the tiny but not safety critical bugs as well. There's enough data from the Android ecosystem that it's much better to focus oxidisation on new software instead of old.

steveklabnik 2y ago
They're using the upstream test suite to track this: https://github.com/uutils/coreutils-tracking https://github.com/uutils/coreutils-tracking

burntsushi 2y ago

I mentioned this on reddit, but AFAIK, the uutils project doesn't yet support locales: https://github.com/uutils/coreutils/issues/3997 https://github.com/uutils/coreutils/issues/3997 I'm not any more a fan of POSIX locales than the next person[1], but AIUI, that seems a likely requirement for uutils to be used in a distro like Ubuntu. I'd be curious how they plan to address this. At least from my perspective, unless uutils has already been designed to account for locales from the start (I don't know if it has), it seems likely that a significant investment of time will be required to add support for it. [1]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

Spivak 2y ago

Why oxidizer over the existing Debian alternatives system? It's designed for this exact use case and already works with many existing packages. The author's response in the comments was a basically a non-answer which doesn't exactly inspire confidence. > Long-term, my concern would be that this may somewhat muddy the picture for which packages need substantive fixes. If it is extremely easy to just revert, what is the benefit to switching? ??? Is this not the ideal situation? It provides low friction both for moving to the new cool thing and moving back to the existing tools when you have software that hard depends on GNU coreutils. You want the changeover to be high risk because it's hard to undo? I guess that's one way to force yourself to commit but the real users on the ground won't be happy when going to the LTS is substantially more work. This would be 3 different symlink managers in Ubuntu all used for different sets of software. The alternatives system at least has the benefit of integrating tightly with apt.

deleted 2y ago
[deleted]

vimarsh6739 2y ago

To me, this feels less about Rust and more about moving away from copyleft.

MiiMe19 2y ago
This is the truth of it. They want to take everything proprietary to make more money off of it.