It is guaranteed those who talk about this have ZERO clue about the licenses of the software they directly use, or have been always installed on their systems.

• SSH is bloat when you can have an efficient wireguard P2P connection.
• Does waypipe support input (keyboard+mouse)? because if it doesn’t, it’s kind of useless. you might as well just use ffmpeg with kmsgrab (provided that the pixel format the compositor uses is supported).

I have no intention of switching to wayland, but I did try wayvnc a couple of times. The first time it was very buggy. The second time it seemed to have improved. But I see now that it isn’t actively developed anymore!

Rust has features that are not directly related to memory safety, but introduce paradigmatic and ergonomic improvements that help writing correct logic more often. Features like sum types (powerful enums) and type classes (traits, how generics are implemented) quickly come to mind. Hygienic macros and procedural macros are also very powerful features.

Sometimes the two aspects (language feature and memory safety) come together. For example, the Send and Sync traits is the part of the type system that contributes to implementing thread safety.

So it’s not all just about (im)mutability, lifetimes, and the borrow checker, the directly relevant safety features.

Also, the tooling and the ecosystem are factors the value of which can not be understated.

Nice(!) to see so many people who don’t know anything about programming get successfully propagandized into going against something they know nothing about.

Below is a list of CVE’s published against original sudo, all within the last 5 years. You may not heard of them, because CVE’s against non-Rust projects are not news 🫣

sudo CVE’s from within the last 5 years

(severity scores are not available/assigned always)

CVE-2021-3156 (Severity: High)

Sudo before 1.9.5p2 contains an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root via “sudoedit -s” and a command-line argument that ends with a single backslash character.

CVE-2021-23239

The sudoedit personality of Sudo before 1.9.5 may allow a local unprivileged user to perform arbitrary directory-existence tests by winning a sudo_edit.c race condition in replacing a user-controlled directory by a symlink to an arbitrary path.

CVE-2021-23240

selinux_edit_copy_tfiles in sudoedit in Sudo before 1.9.5 allows a local unprivileged user to gain file ownership and escalate privileges by replacing a temporary file with a symlink to an arbitrary file target. This affects SELinux RBAC support in permissive mode. Machines without SELinux are not vulnerable.

CVE-2022-43995 (Severity: High)

Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd.c array-out-of-bounds error that can result in a heap-based buffer over-read.

CVE-2023-7090 (Severity: Medium)

A flaw was found in sudo in the handling of ipa_hostname, where ipa_hostname from /etc/sssd/sssd.conf was not propagated in sudo. Therefore, it leads to privilege mismanagement vulnerability in applications, where client hosts retain privileges even after retracting them.

CVE-2023-22809 (Severity: High)

In Sudo before 1.9.12p2, the sudoedit (aka -e) feature mishandles extra arguments passed in the user-provided environment variables (SUDO_EDITOR, VISUAL, and EDITOR), allowing a local attacker to append arbitrary entries to the list of files to process. This can lead to privilege escalation.

CVE-2023-27320 (Severity: High)

Sudo before 1.9.13p2 has a double free in the per-command chroot feature.

CVE-2023-28486

Sudo before 1.9.13 does not escape control characters in log messages.

CVE-2023-28487

Sudo before 1.9.13 does not escape control characters in sudoreplay output.

CVE-2023-42465

Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.

CVE-2025-32462 (Severity: Low)

Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.

CVE-2025-32463 (Severity: Critical)

Sudo before 1.9.17p1 allows local users to obtain root access because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option.

The special comment from @MTK@lemmy.world in this thread deserves some focus:

The Rust hype is funny because it is completely based on the fact that a leading cause of security vulnerabilities for all of these mature and secure projects is memory bugs, which is very true, but it completely fails to see that this is the leading cause because these are really mature projects that have highly skilled developers fixing so much shit.

So you get these new Rust projects that are sometimes made by people that don’t have the same experience as these C/C++ devs, and they are so confident in the memory safety that they forget about the much simpler security issues.

This has all the classics from the collectively manic discourse that has been spreading lately

mature projects

highly skilled developers

Rust projects that are sometimes made by people that don’t have the same experience as these C/C++ devs

C/C++ devs (deserves a separate entry)

they forget about the much simpler security issues.

The only classic missing is “battle tested” which is a crowd favorite these days.

But of course the internet gantry’s knowledge about CVE’s reported against non-Rust projects, is as good as their understanding of the Rust language itself.

Someone bothering to be minimally informed, even when lacking the technical knowledge to maximize their understanding of the information, would have known that the original “mature” sudo has CVE’s published against it all the time. A CRITICAL one was rather recent even. And as it just happens, the ones not (directly) related to memory safety did outnumber the ones that did recently (5 year span). Which ones had higher severity is left as homework for the internet gantry.

The discourse centered around memory safety is itself lacks the knowledge to realize that the overall value proposition of Rust is much bigger than this single aspect, although the breadth of sub-aspects that cover memory safety offered by Rust is itself also under-grasped.

The internet gantry’s susceptibility to propaganda and good old FUD done by ignorant and drama mongering “influencers” and “e-celebs” would have been almost concerning, that is if their transient feelings mattered in any way, in the grand scheme of things.

Needless to say, but this is comment is not meant to be disparaging towards Todd C. Miller or any other sudo developer/maintainer. He has a good relationship with sudo-rs developers anyway, not that the internet gantry would know.

I used to run their closed cli client years ago, but only when connecting to grab wireguard configs, then I closed it and connected with that config without it, which worked well*.

I also remember strace showing it reading a bunch of stuff including /etc/os-release. So they at least knew what distro you were using 😉

It was okay for me because I knew how to deal with it, although I’m with a provider that provides configs directly so you don’t need to use any service-specific clients.

Nord was never, or should have never been, a “privacy” choice, unless you are the kind of person that falls for paid reviewers and comparison sites, or marketing bullshit like all the X eyes talk.

*you can do that with any client that connects through wireguard since you can run wg showconf on the connected wireguard device. Although you would have to do some scripting yourself to replicate other steps like DNS and routing. I don’t think I was the only one doing this.

Good news. Thank you.

And it’s good to hear that it wasn’t something nefarious messing with the instance.

A long time ago, there was this misconception that “linux” was terminal-only. You know, like the interface sysadmins and Hollywood hackers use.

A small long-defunct non-tech forum I used to be a member of had a tech sub-forum, and in that sub-forum there was a new post one day introducing “linux” and covering some basics. It was full of DE screenshots (GNOME 2 and KDE 3) specifically to dispel the “terminal-only” misconception.

That was almost ~20 years ago. And the rest is history. I never liked Windows or M$ anyway for both technical and non-technical reasons. So it wasn’t that hard to convince me.

I almost exclusively use the terminal for everything except web browsing now, and don’t use a DE. So you could say that I myself ironically became a perpetuator of the misconception 😉

Or to avoid ad hominem accusations:
No code. Don’t Care.

And no benchmarks either. That intro about stack vs. heap also reads like someone who never went further than sophomore-level knowledge, or someone explaining things to kids.

Not my area of expertise, but egui may suit your use-case better than the usual candidates.

You’re confusing the Taliban with the “moderate patriots”* NATO tried to prop up for two decades, except those “moderates” didn’t stop at looking at pictures.

* That’s always a code for lowlife mercenaries if you haven’t caught on yet.

Oh look! An attempt at supporting an unhinged manic take with some condescension. A staple of fediverse discourse.

Do tell about the golden platinum era of Apache/CGI + Perl/PHP + MySQL + Flash (+ Java applets for the 15 minutes where they were a thing), because I totally wasn’t there.

incompetent
Dipshit
deranged

I would give you some advice, but it would probably be in vain.

“Every accusation is …” comes to mind.

If people wanted to run an app over the internet, they should’ve just run a fucking app written in something that’s actually appropriate for that purpose

Between all the weirdly charged language, this part was especially worthy of a laugh, since this line of argumentation has full symmetry with the one used by mobile carriers that refused to accept the smart phone (iPhone 1 era).

“If you want a camera, buy a camera. Why do you want it on your phone?!”

Maybe you should write a very “insightful” comment about the incompetent deranged Dipshits at Apple and AT&T too.

resvg/usvg is a good implementation if you’re looking for one.

As a Rust dev who has to target Windows, more support for Rust from MS is very relevant and important to me.

“Target Windows” presumably doesn’t involve writing drivers. How would WDK FFI wrappers help you exactly in that context, and what non-trivial support is MS actually providing?

Maybe you mistook this community for !opensource@programming.dev?

No, I didn’t. Any language community can easily become a corpo spam one if you don’t put some rules in place to filter direct and indirect ads.

Let’s analyze this “news” story as an example:

• Microsoft published trivial unsafe NDK FFI wrappers and tooling awhile ago (not new, not impressive, not news).
• Microsoft publishes an ad in their blog mentioning the published wrappers, and using a lot of marketing talk, with a random trivial LookasideList sample wrapper sandwiched in between. The real LookasideList implementation is of course neither available, nor is it implemented in Rust (If it was, you would be going through two layers of FFI to connect Rust to Rust, which would be even more stupid). Below that random sample code is this note:

Though we believe this wrapper to be sound for the purposes of the team that developed it, it requires further review and testing before we can publish it as the “official” wrapper for these APIs. Thus the above should be considered a possible look at what Rust abstractions for our kernel mode might look like, and not final code.

In the long term, as we make design decisions and finalize our wrappers, our intent is to publish these wrapper crates on crates.io as first-class members of the Rust ecosystem.

• Then independent “news” sites pick up on these low-in-technical-substance ads, and consume the well crafted marketing section titles like “The next steps: going from unsafe Rust to safe Rust”. So we end up with the title here “Microsoft is turning Rust into a first-class language for developing secure Windows drivers”. When in reality, almost literally nothing happened (yet). And even the premise and promise is all about making safer bindings to (presumably) non-Rust code we will never see.

For me, corpo ads with no “relevant” code is boring (or in this case, no new code at all, unless you count the sample list binding). And I can’t imagine I’m alone here.

For me, posting every single pull request from the Asterinas repo would be infinitely more interesting, and infinitely more relevant.

Adding rust FFI bindings to a part of a closed-source system doesn’t magically make anything “secure”.

And ads shouldn’t be allowed here, unless real fully functional code (not just bindings) is made available. Such ads should go to !technology@programming.dev or wherever.

urged lawmakers to act.

“We urge uniparty members to investigate themselves and find some wrongdoing.”

Only looked at the Cargo.toml files.

• (pet peeve) Considering there is (presumably) no compatibility concerns, why not use an efficient binary format instead of JSON?
• Not checking in Cargo.lock files, and using = dependency versions for Phoenix_Desktop, is a bit odd!

People stopped taking Brian seriously when he helped create Go. That was pre-Rust.

Even the “talking points” here seem to be re-used from “Go vs. X” ones. Also, his experience speaks of someone who only tried Rust pre-v1.0.

Anyone who actually knows Rust, anti- or pro-, knows that what he said (partially in jest) is factually wrong.

Feel free to prove otherwise, especially the part about the performance of Rust programs. Don’t be surprised if he simply didn’t pass --release to cargo build, a common pitfall for someone in the “hello world” stage of trying Rust.

And this is why appeal to authority was never more fallacious, considering we live in a world where Dunning-Kruger is a universal reality.

man 7 hier is much older than linux itself. The 1994 start date in the article is not doing the history of the tradition justice.

It would have been weirder if the creepy “init system” (with its 58 executables and counting, 52 + 6 arg0 links) dictating the future of that tradition didn’t raise some eye brows.

What’s wrong with it

• It’s a random crate no one uses.
• You’re not even really “using” it. You are just importing a re-export of reqwest, which is what I expected you to immediately notice after I brought it into attention. You can obviously just remove it and use reqwest directly.
• Still, trusting a re-export is not a trivial matter. The random author of the no-name crate could replace the original reqwest with something malicious, or bad in some other way, in a v0.1.1 release. That (theoretical) release will be picked up after a cargo update call, or when Cargo.lock is not checked, which is the case by default with libraries.