3 ms·

Porting of stable tools to an unstable (rapidly changing) language which can only successfully compile projects if the distro toolchain is rolling (or constantl

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?

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?