Carefully but Purposefully Oxidising Ubuntu

https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995

by wicket • 1 year ago

84 97 1 year ago

discourse.ubuntu.com

superkuh3• 1 year 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.

jerf2• 1 year 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.

HumanOstrich2• 1 year ago

That's a lot of text to say "rewrite everything else in Rust, just not this".

ericjmorey• 1 year ago

something like this?:

https://github.com/jnsgruk/oxidizr

stonemetal122• 1 year 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.

steveklabnik5• 1 year 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.

bitwize• 1 year 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.

TingPing2• 1 year 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.

tialaramex• 1 year 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• 1 year 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.

actionfromafar2• 1 year ago

They should have kept at Upstart, but instead we got punished for our sins.

klysm2• 1 year ago

Investor money throws out attempts like tentacles that get slapped away by the community. It will continue to happen

actionfromafar2• 1 year ago

Didn’t slap systemd hard enough.

AdmiralAsshat• 1 year ago

What "investors" are pushing rust? What is the end goal?

ahepp• 1 year ago

I thought dash was an upstream Debian thing?

But I agree in principle

yjftsjthsd-h3• 1 year ago

https://en.wikipedia.org/wiki/Almquist_shell#dash

Debian Almquist shell

So yes:)... Although apparently Ubuntu was first to adopt it as /bin/sh

simion314• 1 year ago

Remember when the switched the shell to dash? Not to mention, Upstart, Mir, Unity, Snap.

upstart was used by RedHat must have been good enough, before they NIH it Unity was actually better then GNOME at that time, but in the end RH NIH everything except Qt/KDE

lproven2• 1 year ago

Unity was actually better then GNOME at that time,

+1. Still is.

What Unity really demonstrated to me is that despite the constant "Vim gives me editing at the speed of light" mantra, most Linux users do not in fact know how to drive a Windows-like or Windows-compatible desktop GUI with the keyboard.

Knowing all the keyboard controls for one editor does not help someone with anything else. If anyone is a keen keyboard user and has the time and inclination to learn a single app's keyboard UI, then it's a good use of their time to learn the keyboard UI of the underlying OS.

There is a standard. It works on Windows and has done since I first met Windows in 1988 with Windows 2.01, and it still does. Decades ago most Linux WMs honoured it, and it still works today in Xfce, Metacity, much of LXDE and LXQt, and some of MATE. And in Unity.

Not just simple stuff like Alt+F4 closing a window, but richer stuff like Super+1--9 opens the nth app pinned to the taskbar or panel.

If you use the keyboard, Unity works great and the cosmetic resemblance to Mac OS X can be largely ignored.

If you don't... "OMG it's so different aaaaargh where am I noooooo I hate this!"

GNOME >3 threw keyboard UI in the bin along with 30Y of HCI R&D.

KDE... never bothered to learn to properly replicate Win98 so it invents its own. Or, more typically of KDE, half a dozen slightly different versions.

everybodyknows2• 1 year ago

... Bazaar.

glitchc• 1 year ago

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

stonemetal122• 1 year ago

There have been CVEs in core utils. I am not aware of any that Rust would prevent.

steveklabnik5• 1 year ago

https://news.ycombinator.com/item?id=43344829

thyristan3• 1 year 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-h3• 1 year 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).

ndiddy• 1 year ago

I think this interview with the uutils project lead https://www.youtube.com/watch?v=5qTyyMyU2hQ is fairly telling about the motivation behind the project. He mentions that he's not motivated by memory safety and that the GNU coreutils don't have security problems. The discussion gets interesting when the hosts start talking about software licensing. The GNU coreutils are of course GPL licensed, while uutils is MIT licensed. The lead says that he doesn't care about how the project is licensed, as long as it's OSI-approved, and that talking about software licenses is a waste of time. However, at one point (while the hosts are talking about reasons why a user might choose uutils instead of the GNU coreutils), one of the hosts refers to a discussion they'd had with the lead prior to the recorded interview about how car companies were using uutils for "compliance reasons", and asks if that's related to some sort of EU regulation about memory safety. The lead has to correct him, and says that the car companies weren't concerned about memory safety compliance, but GPL compliance. Combined with other statements he makes about purposely not looking at the original coreutils code to avoid any claims of the implementation being "tainted" by GPL code (seems like a lot of work for someone who doesn't care about software licensing), it seems like a major motivating factor behind the uutils project is to create a permissively licensed drop-in replacement to the GNU coreutils.

larsnystrom• 1 year 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?

klysm2• 1 year ago

No I don’t believe so

vacuity• 1 year ago

No. It's normally memory safety and/or ease of tooling/coding/whatever.

dralley• 1 year 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• 1 year 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.

baseballdork• 1 year ago

It's also easier to do things in parallel in rust that might otherwise not have been considered in a C version.

the__alchemist• 1 year ago

Is that because of the Rayon lib?

josefx• 1 year ago

It might be a rationale for a rewrite and rust is just the language the people doing the rewrite wanted to use.

Octoth0rpe• 1 year ago

I think it's often a rationale for choosing rust over other languages once you've decided to rewrite.

amiga3862• 1 year ago

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

juujian• 1 year ago

Switched to Debian, not looking back. Everything just works, almost like Ubuntu had promised it would.

anilakar2• 1 year ago

Ads in the system logs were the last straw for me.

mystified5016• 1 year 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.

everybodyknows2• 1 year ago

Ah, you mean for their "security upgrades" to LTS versions -- presented by 'apt upgrade' since at least 20.04?

Kwpolska3• 1 year 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-h3• 1 year ago

On the one hand, having less RMS and GNU software in the world is better.

Why?

Kwpolska3• 1 year ago

For RMS specifically: https://stallman-report.org/

The GNU project has an extremely utopian and unrealistic vision of open-source.

_ink_2• 1 year ago

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

SAI_Peregrinus2• 1 year 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_2• 1 year 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 :(

superkuh3• 1 year 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.

pizlonator6• 1 year 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.

badmintonbaseba3• 1 year ago

What about performance?

pizlonator6• 1 year ago

For these tools, you won’t notice.

ape4• 1 year ago

"Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. I'm actively working on performance optimizations for Fil-C, so that 4x number will go down."

source https://github.com/pizlonator/llvm-project-deluge/blob/delug...

lproven2• 1 year 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?

sophacles3• 1 year 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".

steveklabnik5• 1 year 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• 1 year 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• 1 year ago

We can’t leave things alone

burntsushi8• 1 year ago

I mentioned this on reddit, but AFAIK, the uutils project doesn't yet support locales: 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/1e70e82baa9193f6f02...

xiphias2• 1 year 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.

steveklabnik5• 1 year ago

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

Spivak• 1 year 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.

vimarsh6739• 1 year ago

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

MiiMe19• 1 year ago

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

Carefully but Purposefully Oxidising Ubuntu

Related Stories