UB didn’t matter.

There is no such a thing.

If you really must pretend this matters performance wise, look up MaybeUninit. It still requires unsafe{}, but it’s a lot less trouble.

What made you reach out to a static mut in the first place?

sudo is NOT a part of coreutils. Anyone with basic *nix knowledge would have known this.

sudo-rs, as expected, is also NOT a part of uutils. And the projects happen to be very different in many aspects. uutils started from scratch as a hobby side-project, and it was developed from the start in idiomatic Rust. It can’t directly take anything from the GNU implementation anyway, as explained in their README. sudo-rs however is a funded effort to translate some C projects into Rust with as little unsafe{} as possible. Some of the code was directly translated from the original implementation. And if you look at the code in general, you will see that it’s rather low-level and looks more like C than Rust in many parts. Some of this is arguably necessary given the nature of sudo functionality, but not all of it.

Both projects do share the fact that they probably didn’t push for distros, Ubuntu or anyone else, to switch to either of them by default already, and both were probably surprised it happened this soon.

And yes, this exposure, negative as it may seem for now, is an unavoidable “teething” period, and it’s going to be of great benefit to both projects on the long run. Hopefully, Ubuntu users living on the edge wouldn’t face too much trouble meanwhile.

(I don’t use Ubuntu, but have been using sudo-rs by default for months.)

I have been using it by default with cargo since just before 0.4, I think, and had zero problems.

The situation may have been different If I tried to use it with some non-Rust projects that need special support for some feature(s).

Like you, I’m not well versed in the web**** world (self-censored), but from my observations, Leptos appears to be the most popular (community) web rust/wasm framework currently. Why? I wouldn’t know.

You see, rust platform support can’t be bad when even meme platforms can get to tier 1.

I get it – abstractions are cool. They’re supposed to hide complexity so we can focus on cooler stuff. And Rust loves that idea. Traits, generics, lifetimes – layer upon layer of “don’t worry about it honey.”

That’s such a fundamental misunderstanding of something so basic, that I almost had to stop reading.

A word of appreciation.

Typst developers are among the best Rust citizens around. Not only do they have a cool project, but they also contribute a lot to the Rust ecosystem at large.

The push-based ActivityPub (apub) federation itself is bad design anyway. Something pull-based with aggregation and well-defined synchronisation would have been much better.

There are ideas beyond that. For example, complete separation between content and moderation. But that would diverge from the decentralized family of protocols apub belongs to, and may not attract a lot of users and traffic. And those who care and don’t mind smaller networks prefer fully distributed solutions anyway.

rationale behind the design principle is the only organizing entity here it seems.

It is worth pointing out however (for “non-techies”) that Rust projects have been written by people who love Rust and use it as their main language, love it but can’t use it a lot in their employment, like it or are lukewarm about it and used it once or write in it on occasion, don’t like it but wanted to experiment with it, hate it but learned it because it could be beneficial to them in some way, hate it but had to use it (usually as a part of their employment).

The success of the language means that not everyone who uses it necessarily even likes it. So not even a “belief” in the design principle can be assumed by all involved.

Good comment.

the framing of it being a “unified, central community” is entirely yours

The explicitness in that part of my comment was deliberate to fully dispel the “really pulled together and made sure” part from the well-meaning OP.

The Rust community really pulled together and made sure that there are Rust alternatives to as many tools out there as possible.

Deliberately or not, with good appreciative intentions or not, I’m afraid you’re perpetuating a myth here (a conspiracy theory even, in some “mentally challenged” circles).

Most tools are independently created by individuals, or very small independent teams of contributors. And being an “alternative written in rust” is rarely a goal in and of itself (or shouldn’t be anyway).

The notion of a unified central “<lang> community” that is responsible for creating 100s of tools is both silly and fictitious.

Talking about Rust itself as a good language with good tooling that allows individuals to create good tools, and contribute to a thriving library ecosystem, is okay. Not everything has to be a “community” or a “community effort” or framed that way, however.

zswap is not better than modern zram in any way. And you can set up the latter with writeback anyway.

But that’s not OP’s problem since “swap gets hardly touched” in OP’s case.

The point is compression.

% swapon
NAME           TYPE      SIZE USED  PRIO
/dev/nvme0n1p2 partition   8G   0B     5
/dev/sda2      partition  32G   0B    -2
/dev/zram1     partition 3.5G 1.8G 32767
/dev/zram2     partition 3.5G 1.8G 32767
/dev/zram3     partition 3.5G 1.8G 32767
/dev/zram4     partition 3.5G 1.8G 32767
/dev/zram5     partition 3.5G 1.8G 32767
/dev/zram6     partition 3.5G 1.8G 32767
/dev/zram7     partition 3.5G 1.8G 32767
/dev/zram8     partition 3.5G 1.8G 32767

% zramctl
NAME       ALGORITHM DISKSIZE   DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram8 zstd          3.5G 293.4M 189.2M 192.5M         [SWAP]
/dev/zram7 zstd          3.5G 282.1M 187.5M   192M         [SWAP]
/dev/zram6 zstd          3.5G 284.6M 189.4M 192.9M         [SWAP]
/dev/zram5 zstd          3.5G 297.8M 197.3M 200.1M         [SWAP]
/dev/zram4 zstd          3.5G 304.9M 202.9M 206.7M         [SWAP]
/dev/zram3 zstd          3.5G 300.7M 201.9M 204.6M         [SWAP]
/dev/zram2 zstd          3.5G 311.3M 207.2M 210.6M         [SWAP]
/dev/zram1 zstd          3.5G 307.9M 210.5M 213.3M         [SWAP]
/dev/zram0 zstd          <not used for swap>

• Use zram devices equal to the number of threads in your system.
• Use zstd compression.
• Mount zram devices as swap with high priority.
• Mount disk swap partition(s) with low priority.
• Increase swapiness:

     sysctl vm.swappiness=<larger number than default>
  

• Use zramctlto see detailed info about your zram disks.
• Check with iotop to see if something unexpected is using a lot of IO traffic.

lightweight

😑
/me looks inside
/me finds >20 sub-crates and all kinds of dependencies including a web server
/me starting to think i’m the weird one for saving my passwords in a text file and almost getting annoyed about having to use cotp

Brother, some of us already moved from lld to mold to wild already. The project could have waited a little bit, then went with the implemented-in-rust option directly.

Thank you for the update.

Thank you (+ contributors) for doing this work and keeping us posted.

Last time I took a look, I think LTO was broken. Is that still the case?