This is really interesting. I'll probably reference this blog post for a very long time.

I wish it would be easy to filter for pure crates, as well as no-std crates on crates.io. I know there is no-std tag but I'm not sure how reliable this is.

no-std is orthogonal to use of C. There are crates where it means replacing libstd with stdlib :)

I wish there was a good alternative to gstreamer for building a "zero copy" computational graph and media pipeline. Even though the bindings are very good, it's far from ideal.

PipeWire? Also not Rust.

My main motivation for having a Rust alternative is to allow stronger typing of the edges of the graph. Going through gstreamer typically means dealing with byte slices and string-typing the input and outputs of each node...

Interesting. There are so many Rust game engines. Does none of them handle text rendering properly? (I haven't studied this aspect of Bevy, while I really should have since English isn't even my mother tongue...)

https://github.com/bevyengine/bevy/issues/7616 might interest you. Bevy plans to migrate to cosmic-text (mentioned in the article) because of their current implementation's (ab_glyph maybe?) issues.

Good list. Wrapping C is especially annoying when cross-compiling. You always run into issues.

Very hardware focused. I would say the biggest one is OpenSSL. My heart always drops when something depends on that. Guaranteed pain.

Not sure about TCL. TCL is a terrible language. Surely it would be better to simply move to a sane modern one? There are a few decent embedded languages written in Rust, e.g. Rhai or Starlark.

PAM? Really?

I think a better goal would be to create an entirely new design, with a decent scripting language for expressing which authentication/authorization queries to do and when to succeed (which PAM config files, ahem, are not), and get distros to use it. And maybe allow loading legacy PAM modules as an optional feature.

(Aside from all the obvious suckage, I have my personal pet peeve: it’s been how many years, and we still can’t grant ambient capabilities using PAM?)

There is already BSD Auth, which has the advantage that it allows for sandboxing, while PAM doesn’t due to its use of shared libraries (instead of separate processes), which the author of TFA claims is not problematic. Yes, it is.

I agree with you - the linux ecosystem is very impressive, up until the user-space (with many exceptions of course). I usually never recommend starting from scratch, and we should definitely strive for proper backwards compatibility, but I don’t feel much would be lost by leaving behind the whole, unsecure C programs of contemporary linux distros.

Like, why does it still have to be C, didn’t we learn a bit from all those vulnerabilities?!

The problem with PAM isn’t (IMO) that it’s written in C. The problems are that the entire design is horrible, the configuration abilities are horrible, the maintenance seems pretty bad (not much changes these days), and the ability to actually interact with PAM during authentication is quite weak.

The latter is a functionality weakness (e.g. doing anything useful using PAM when accessing a system over SSH or HTTPS or really anything else is a mess and not terribly useful, but it also makes the fact that PAM is written in C be less of a problem: there is so little untrusted input available to PAM that it’s not a very easy target.

What PAM needs is a redesign. A different language would just be icing on the cake.

I bet you could map a Linux user space authorization environment to an authzed schema and define permissions that way.

https://authzed.com/docs

Authentication should just be another service you talk to over UNIX domain sockets. The dynamic library design is a huge problem, and changing the configuration language won't fix that.

GUI libraries?

Every time I attempt to look at Rust and it's still so early days there isn't even a way to create a simple desktop UI with it without depending on some completely random library some likely 13 year old made that I instantly give up on Rust and don't think about it again for another year.

RustDesk uses Tauri, Iced is replacing GTK+ in System76's COSMIC DE, and in my experience, egui is a very comfortable ImGui replacement.

I've definitely had "damn, I wish I could do xyz" moments with all three of those, but "early days" is a bit of a stretch.

What's wrong with a random 13 year old making a library? It's not worth using unless some corporation is funding a team of developers to work full time on it? Come on.

Somebody has to make all this stuff. Be somebody. If it doesn't do what you want, fork it and make it do it. If it's unmaintained, fork it and take it over.

> What's wrong with a random 13 year old making a library?

If companies start using the code, isn't it child labor?

That’s a super uncharitable take on Rust GUIs and honestly implies you never looked deeper.

Slint alone is more than capable and backed by an actual company of ex QT engineers. ;P

My project https://github.com/evmar/retrowin32 includes a (Windows-agnostic) pure Rust instruction level emulator for x86, and if anyone is interested on hacking on one I'd love the help!

Personally I want a pure rust (minimal unsafes) PDF rendering/parsing library and viewer, same for EPUB (basically minimal browser engine), a video player (with ffmpeg equivalent), an image viewer with the accompanying image format libraries. Also preferably that it wouldn't be too integrated into the "ecosystem" which usually results in something hellish(JSish) like 300 microdependnecies authored by 200 people for something basic, and would be more self-contained.

Pure rust should mean "only uses rustc" not "only uses cargo" imo. Cargo is great, but it is not the language itself or the only build system for rust in the world.

Cargo is great compared to other language build systems, but people tend to forgot that there are even better solutions like bazel and buck2.

You're not going to win this battle. The best you can do is to accept it as the canonical Rust project layout, and reimplement Cargo's build steps in the build system of your choice.