I don’t have an opinion about this topic which actually affects Ubuntus upcoming release.
Unless the Arch team would join that adoption of sudo-rs. But I don’t think that would be the case for the foreseeable future.
It seems to be already available on Extra repo, but I think Arch won’t be jumping into wagon just yet replacing sudo with it. Of course Arch is make-yourself -distro, so if one wants to use it it’s alternative.
That’s pretty much my view on it, as well.
oh wow, this blew up. 
Anyway, someone correctly pointed out the rust vs no-rust debate, that gets inherited by the sudo vs sudo-rs debate. The non-professional linux user would probably never notice the difference, but for everyone else having clarity - I believe - is of the utmost importance.
I brought the subject to the forum attention to seek clarity, my goal wasn’t to start a fire.
Unless one has extensive experience with Rust (which I do not), I don’t believe anything more substantial is being conveyed but rust politics. I would invite someone who DOES have Rust programming experience to the floor to enlighten us plebs.
So you just do “run0 pacman -Syu” instead of “sudo pacman -Syu” ?
Yeah, I think so.
Here’s the manpage
I just use an alias from sudo to run0.
Do you need to configure systemd-homed first or can you just use run0 as a drop in replacement for sudo?
I remember getting very confused with some literature insisting that it wasn’t a drop in replacement for sudo and was designed as an improved alternative for systemd-run.
It isn’t drop-in replacement for sudo because it doesn’t use all the same options and config.
But if you are manually running commands using run0 instead of sudo it should run fine.
There is a shim in AUR to let you fully replace sudo but I haven’t tried that.
yep, this was also one of the points
Whether it’s written in C, or written in Rust, it can be written well, or it can be written poorly. A language isn’t going to make a bad programmer good.
Rust offers memory safety, great. Does that make it more secure? Here’s the biggest difference I can see:
- An experienced developer with C can create a program that does not exhibit memory leaks.
- A less experienced developer with Rust can create a program that does not exhibit memory leaks.
The interest in Rust has been trending for a while. New developers are interested in it, and learning it. The features it offers perhaps don’t in and of themselves make software better, but perhaps it lowers the bar to things like memory safety.
With the advent of LLM’s and with their prevalence among developers, with less attention paid to actually creating and understanding code, language features like memory safety offer a guard-rail, much like bumper bowling.
I can see why Rust is popular. I can see why those new to development are interested in it. I can also see why C developers and existing communities see no reason to abandon tried and tested solutions.
I’ve been a C programmer (side line, not purely a programmer) and perhaps not a very good one, but the language as I recall it, lends itself to all sorts of inexplicable behavior with pointers and memory allocation errors.
Yes, you can program in C, but it has absolutely NO guardrails or didn’t back in the day (I haven’t written C in probably close to twenty years now) and all sorts of shenanigans ensued (purposeful and accidental).
I program in C++ (purely for fun) and it’s been getting more and more memory safety features since c++11. C++26 introduces even more such as protection from dangling pointers and buffer overflows etc. The only real difference between these features and rusts are that in C++, they’re opt in.
My intention is not inflame a flame war to start one. So please bear with me.
From what I gather RUST is memory safe programming. That makes it slow, comparable to an equivalent code in C/C++. But it does away completely memory unsafe errors and conditions. That is a big chunk of vulnerabilities that our existing system and application software have. That itself makes Rust worthy of a second look.
On the other hand C/C++ has extensions, like SAFE C/C++ and others, which come close to eliminating buffer overflows, pointers/memory misdirection, etc but they are an afterthought. They are not baked into the language as in the case of RUST. With the attacks on systems going to increase only it is attractive to simply remove a massively big chunk of vulnerabilities in a single go.
Again not intending this to become a flame war between RUST and C/C++. But future does appear to be RUST.
Programming languages come and go in popularity. There is no perfect programming language and there will always be something newer coming along that people will be claiming is the “future”. Rust isn’t the future at this point. It is already widely used in the present.
Rust has an upside in that it is memory safe but it also has a security downside in that it is vulnerable to supply chain attacks via cargo. Which of those risks is higher is the topic of much debate.
A memory safe supply chain attack. There is no memory leak when your data leak. 