in other news: software has bugs
this post was submitted on 12 Nov 2025
441 points (95.5% liked)
linuxmemes
28364 readers
1235 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
- Don't come looking for advice, this is not the right community.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
Not my software.
No tests, no users, no bugs.
see Ivan? Dead code cannot have bugs
The other day o spent a bunch of time carefully dissecting and then rewriting some code from the guy before me.
Turns out that code was never used, he just didnβt remove it or comment it out.
That was a good use of a couple hours.
load more comments
(3 replies)
helloworld("print")
Ah, we have a senior developer here!
load more comments
(3 replies)
Mozilla, where Rust was originally conceived, have already talked about this risk factor ages ago when they were still working on Servo. Reimplementing battle-tested software in a different language can result in logic bugs being introduced, which no programming language can really prevent. Many times they will actually reintroduce bugs that have already been historically fixed in the original implementation. This doesn't invalidate the benefits of moving to a very memory safe language, it just needs to be taken into consideration when determining whether it's worth the risk or the effort.
Honestly I have no idea whether sudo-rs is a good idea or not, but I have my doubts that any of the other people (especially the very vocal kind) chiming in on this do. Any time Rust is involved in the Linux community, a lot of vocal critics with very little knowledge of the language or programming in general seem to appear.
This is why its generally better to only write new code in more memory safe langs instead of rewriting everything
The counterpoint is that, especially with FOSS that does not receive much (if any) corporate backing, developer retention and interest is an important factor.
If I'm donating some of my free time to a FOSS project I'd rather not slug through awful build systems, arcane mailing lists, and memory unsafe languages which may or may not use halfway decent - often homebrew - manual memory management patterns. If the project is written in Rust, it's a pretty clear indicator that the code will be easily readable, compilable, and safer to modify.
load more comments
(6 replies)
load more comments
(1 replies)
Any time Rust is involved in the Linux community, a lot of vocal critics with very little knowledge of the language or programming in general seem to appear
I swear to god sometime last week in a conversation about Rust here, there was one commenter whose entire point was "OK admittedly i don't code and don't know much about programming but i got this feeling that memory safety isn't all what' it's cracked up to be". A confederacy of dunces indeed...
It's a generally applicable lesson in why it's NOT a good idea to change things for the sake of it though (chesterton's fence, but where most of the actual bits of fence are invisible).
load more comments
(8 replies)
The real problem is not Rust, or that somebody decided to rewrite sudo in Rust. These are both good things.
The actual real problem is that Ubuntu adopts these in their mainline distribution when the release version is 0.something. I mean sure, this will get the worst bugs noticed and fixed sooner but come on. Have a little empathy for your dumb users. They didn't choose to be that way.
I would argue a rewrite of sudo in rust is not necessarily a good thing.
Sure, if you are starting from scratch, Rust is likely to mitigate mistakes that C would make into vulnerabilities.
When you rewrite anything, there's just a lot of various sorts of risks. For sudo and coreutils, I'm skeptical that there are sufficient unknown, unaddressed problems in the C codebases of such long lived, extremely scrutinized projects to be worth the risks of a rewrite.
A rust rewrite may be indicated for projects that are less well scrutinized due to no one bothering or not being that old anyway. Just the coreutils and sudo are in my mind the prime examples of bad ideas of rewrite just for the sake of rust rewrite.
I think the people doing the rewrites genuinely believe it will be an improvement, and they could be correct. I get the instinct to "don't fix what ain't broken", but that is what staging is for. There is no need to make sacred cows, and this seems like a perfect opportunity to improve security and integration testing as well.
Canonical wouldnβt have anything to do if they didnβt push software prematurely without testing it properly or making sure anyone actually wants it. See also:
- Mir
- Snap
- Core utils in Rust
- Netplan
- Their shitty installer
- CloudInit
Sometimes, their stuff end up getting popular and sometimes even usable. Most of the time thoughβ¦
Thereβs still nothing wrong with reimplementations. Itβs like saying donβt build houses because youβll have to make repairs.
I don't know.
Where can I download a house?
You wouldn't...
load more comments
(3 replies)
PSA: If you think that people use Rust because it lets you write without bugs do yourself a favor and don't comment on anything Rust related. You will avoid sounding stupid.
I think the criticism is more about deciding to try to re-implement a long standing facility in rust that has, by all accounts, been 'finished' for a long time.
About the only argument for those sorts of projects is the resistance to the sorts of bugs that can become security vulnerabilities, and this example highlights that rewrites in general (rust or otherwise) carry a risk of introducing all new security issues on their own, and that should be weighed against the presumed risks of not bothering to rewrite in the first place.
New projects, heavy feature development, ok, fine, Rust to make that easier. Trying to start over to get to the same place you already are, needs a bit more careful consideration, especially if the codebase in question has been scrutinized to death, even after an earlier reputation of worrisome CVEs that had since all been addressed.
load more comments
(3 replies)
load more comments
(3 replies)
Canonical should really wake up and stop thinking that rewriting in rust is a magical way to remove bugs.
Sure the rust rewrite will surely be easier to maintain and less error prone (Assuming the code is idiomatic), but you can't rewrite software maturity.
They should put it behind a checkbox instead of shoving it down anyone's throat. They are literally testing in prod
We have yet to see if they'll stick to the Rust implementations for 26.04. If you're running non-LTS Ubuntu in prod, that's not on Canonical...
If we expect software like sudo to stick around for decades to come, a transition phase like this might very well be worth the investment.
IMO if you're running Ubuntu at all in prod you already fucked up.
Real professionals use LFS, obvs
load more comments
(2 replies)
load more comments
(1 replies)
But that is literally what the 25.10 is for, to test in prod. So that those bugs are fixed in the upcoming LTS
load more comments
(3 replies)
load more comments
(1 replies)
Can anyone explain why do we need this rewrite? What I'm hearing is just that the language is memory safe and, honestly, it sounds like a weak argument. Unless the program is actively evolving or requires regular updates and it can be seen that a rewrite could genuinely improve thingsβ¦
All I've seen in these media posts were just vague "what if" arguments. If that's it, a rewrite seems pretty dumb.
Image working in an old building, there is no coffee machine, there is no warm water and if you want to do something new, chances of you getting in trouble because you forgot to mess with CMake or free memory, are high. But the building works since it has been tested for 30 years.
Rust is a new building that you can move over to, there is a coffee machine that is a bit complicated at first but once you understand it it is that bad, there is warm water and you don't have to mess with CMake or allocate/free memory for everything. But the building is new, there will be issues here and there and sometimes the promised warm water wont work since someone fucked it up, but in general it is just sooooo much more comfy to work in.
Rust is not about making Programming languages fast or memory safe. If you truly want to do that, I recommend doing crack and writing in assembly. It is about making programming easier without sacrificing speed.
load more comments
(5 replies)
Sudo is being actively developed and has several fairly recent CVEs, some of which are memory issues (at least recent compared to how old sudo is). Apart from being memory safe rust is also better at error handling than C.
IMO best would be to reduce attack surface by using a memory safe language and also reducing complex features like OpenBSD's doas does.
https://www.cvedetails.com/vulnerability-list/vendor_id-15714/Sudo-Project.html?page=1&order=3
load more comments
(4 replies)
load more comments
(3 replies)
I am one of the people that believe in the technical superiority of rust.
What differentiates me though, is that I also believe in the superiority of C, the superiority of Java, of Javascript, ALL WITHIN THEIR RELATIVE DOMAINS HAVE STRENGTHS AND WEAKNESSES.
I like my crypto libraries in C. I like my desktop applications in rust and I like my web pages with simple, hand-written javascript. Or none is fine too.
I think it's an acceptable choice to use rust for core utilities, though not necessarily exclusively, but I think we're a far way off, where we should widely adopt it. It's not very mature yet.
I don't think I've seen more vocal sponsors of any language except Rust. With the high barrier to entry and relatively greater developer effort, I am curious to see what place it occupies in over the long term.
load more comments
(1 replies)
Sometimes an old legacy project have things that are dated but also years and years of bug fixes, improvements many not really documented. Starting a new project to replace it, will have regressions itβs impossible to not
What? New software doesn't have the same level of battle testing that 30 year old software, with billions of deployments had? What does that matter? It's memory safe, guys! That means it can't have any bugs!
You exude vibes of someone who would've opposed the move from assembly to C ..
Developers are well aware of the risks of re-writting, and I have seen no one say Rust is bug or cve free on compile time. But you do have higher guarantees that a certain class of vulnerabilities do not exist or it is easier to narrow down where they might be. Stop spreading FUD
And before you try: nop I'm not a Rust developer
But, maybe, just maybe, replacing one of the most important coreutils with an immature Rust product isn't a good idea
Can someone explain to me why Rust enthusiasts are so evangelical about it? I get that it's memory safe, OK - super great. But rewriting a stable, small-but-important legacy tool doesn't seem like a good place to prove its worth. Surely there are a million better places? And yet when I heard about this, it totally seemed to track. I've never touched Rust but I already find its proponents to be strangely focused on it. I never felt such religious zeal with regard to a programming language.
load more comments
(2 replies)
load more comments
(1 replies)
If you had an ancient utility in assembly that did exactly what you wanted and no particular issues, then it would have been a dubious decision to rewrite in C.
Of course, the relative likelyhood of assembly code actually continuing to function across the evolution of processor instruction sets is lower than C, so the scenario is a bit trickier to show in that example.
However, there are two much more striking examples: COBOL continues to be used in a lot of applications. Because the COBOL implementations work and while it would be insane to choose COBOL for them now if they were to start today, it's also insane to rewrite them and incur the risks when they work fine and will continue working.
Similarly, in scientific computing there's still a good share of Fortran code. Again, an insane choice for a new project, but if the implementation is good, it's a stupid idea to rewrite.
There's not a lot of reason to criticisize the technical merits of Rust here, nor even to criticize people for choosing Rust as the path forward on their project. However the culture of 'every thing must be rewritten in Rust' is something worthy of criticism.
load more comments
(1 replies)
And it was a memory bug even. Just not a very common one.
"It's just programming errors, nothing to do with Rust", aka the language that they've been acting like will solve all programming errors
load more comments
(1 replies)
view more: next βΊ