DietPi-Software | Rust

[MichaIng]

Continuation of: #4987 (comment)

Rust is used more and more by software projects, as it provides secure, stable, fast and lightweight standalone binaries. The DietPi-Dashboard backend is written in Rust as well, and it works brilliant 👍. Other projects like cURL or the Python cryptography module started to write parts of their code in Rust, where memory safety or other security aspects benefit from it.

The problem is that we generally aim to install software system-wide, and rustup is natively designed as a single user instance only. So if dietpi-software did install it, e.g. also as dependency to compile other software, it will be usable by the root user only in an interactive session (environment variables required etc). For an SBC with potentially limited resources and usually used by a single person only, having a root rustup + toolchain for a single software install only and a second one for the login user is not great. It is possible but a bit hacky to install it in a way that all users can use it while only having their own additional crates/projects installed into their individual home directory: rust-lang/rustup#2383

Instead of rustup, we could install cargo form the Debian repository, but it is naturally outdated, and stable Rust releases are supported by the Rust team for 6 weeks only: https://packages.debian.org/bullseye/cargo

So I'm not sure how to do it best. Personally I'd prefer the hacky way, but I cannot rule out that users may run into issues with it, and getting help from the Rust team for such an uncommon setup may be denied. There was some discussion about implementing safe concurrent usage, but the last activity on that was months before that clear statement above that it is not a supported setup: rust-lang/rustup#988

[Joulinar]

@MichaIng
Uhh looks like people working on rust have some internal challenges rust-lang/team#671

[MichaIng]

Sounds like some member(s) of the core team lifted of the ground too far instead of acting as a equal (when it's about communication and code of conduct) community member(s) 😞. But I should be careful to evaluate from here 😅.

[alexiri]

A slightly-older version of Rust is better than no version of Rust. Why not start with the one in the Debian repository and then make it more complicated if needed? I could give this a shot, if you want.

[MichaIng]

On the other hand, what benefit does it have if dietpi-software does nothing more than a simple apt install?

[alexiri]

I'd say the same benefit as the install of git, ffmpeg, unrar, gimp, vim, etc. etc. :)

I'm using DietPi more-or-less as a configuration management system for some Raspberry Pis. For me, it's useful to be able to declare the list of software I want installed, as that makes it easier to recreate a configuration. In more practical terms, I may be proposing other software soon that needs to be compiled with cargo, so being able to declare Rust as a dependency would be useful there as well.

[MichaIng]

We're actually thinking of removing some of the tools which we install via APT only and are no dependencies, making users more aware of APT and the huge Debian software repository in general 😉. However, for dependencies it is indeed a good thing to have them as software option.

What I'm not sure about is how fast upstream software starts to drop support for old Rust versions, or how fast older crate versions may be pulled, which are then probably not maintained anymore etc. The Rust developers themselves strongly recommend and promote rustup over any other distribution, and it is hence used in most cases, other than e.g. gcc and Python, which most users install from their Linux distro repository. With Python at least we already have issues that software cannot be installed anymore on old Debian version we still support, at least in the phase where er support the oldoldstable, or oldstable close to a new Debian release (where it hence gets 4 years old). I can imagine that this is a larger problem with Rust, when using a 4 years old version. But I don't know, to be true.

[alexiri]

I'm afraid I don't have much of an insight on that point. I've only ever built one bit of Rust software, and in this case I got lucky because the minimum version is the same as the one available in the Debian repositories. Given that the developer bumped the minimum version less than a month after that version was released, the long-term stability is not looking good. Still, sample of one, so 🤷

[MichaIng]

Then I bet oldstable Debian's Rust would be too old already, which kinda proves my worries. It doesn't make sense to implement Rust as a dedicated software option, shift over the single compiling Rust software option we currently have that requires Rust (vaultwarden, where we use a temporary rustup install currently) to use it as dependency and break it that way for older Debian versions. Especially when apt install cargo is all that is required to achieve the same Rust instance, when really required.

I think, until we want to implement some software where for some reason a persistent Rust setup makes sense (like for internal or faster updates or so), we shouldn't implement a Rust software option which is discouraged by the Rust developers themselves but leave it up to the users to choose between the two very simple to install options, apt install cargo or the preferred official, recent and per-user variant: https://rustup.rs/

[jahway603]

Since Matrix Synapse now requires rustc to compile/build, will this be explored as a new application offering thru dietpi-software again?

[MichaIng]

aarch64 wheels will be available with next Synapase release and we are working on ARMv6/7 wheels via piwheels as well.

[blogabe]

Hi. I'm wondering if there is an update on including Rust as a development software option? Is there any guidance on installation? I'm considering the Dioxus framework.

[MichaIng]

An installation for the current user is extremely simple 🙂: https://rustup.rs/

[blogabe]

Perfect. Thank you.