Getting ahead of the curve regarding potential future legislations/regulations around unsafe languages, which may introduce contract conditions, liabilities…etc (See 2:30-4:30 of this talk for an overview).

If they listened to the calls describing this move as premature, and it arguably was, they could have gotten strapped for time later.

An implementation in a good safe fast modern language that developers actually enjoy has other tangible benefits of course. But if people want the “corpo reason”, the above should provide an answer.

Vibe-coded trash + outdated models.

Wouldn’t have expected anything better from a trash website.

You missed a 4 year anniversary.

It’s officially centrally hosting the non-pre-moderated non-official user contributed build-scripts, where “user” means literally anyone.

I’m not sure what argument you’re trying to “win”, and to what end. Or why do you think anyone would care about the manufactured confusion you’re trying to concoct.

All community projects are open contribution. Most non-community ones too. You know, almost the whole point of open-source!

But that’s not the same as “user repo”, which is a wild west concept on purpose.

Unless every single dependency is version locked

Which is the case with Cargo.lock. You can even lock the toolchain itself with rust-toolchain.toml. There a reason why uv developers knew what good practices to implement in their quest to fix python tooling 😉.

one update or maintainer change can silently compromise the whole chain.

That’s another failed analogy. There is no orphaning and total randos taking over in crates.io (same for npm/pypi I would assume). The owner himself must hand over or give permissions to a specific person/account. That’s another implicit chain of trust that doesn’t exist in AUR.

Nothing is fail-proof of course, as the xz incident showed.

I don’t follow npm incidents closely, but the cases I saw involved the legit owners/maintainers themselves, who were either compromised, or genuinely doing the compromising themselves 🤣.

Arch is a single rolling release

This is largely irrelevant to the discussion.

hit Rust and PyPi in a similar way.

It won’t be similar for the all the reasons stated.

And a strict “version locking” ethos can lead to security problems down the line, too.

That’s where language implementation compat guarantees, audit tooling (cargo audit et al) and good tooling in general, together with a good semver story in the ecosystem itself, ALL come together to make this largely not a problem.

This works well enough in the crates.io ecosystem.

From what I hear, npm has the audit tooling part covered. But it’s failure in all the other aspects that’s making the situation unattainable.

As with pypi, there is the pain point of python minor release updates breaking shit all the time. But beyond that, I don’t know enough to give an informed take (other than that uv is a blessing for those who don’t want to get their hands really dirty in that ecosystem).

And again, these details and differences are very relevant.

It’s easy to sneak some malware downloader into a long Rust dependency chain, even if it’s technically all open code.

As of now, the number of successful supply chain attacks (where a chain of real dependants exists) in the crates.io system is ZERO.

still weaker than Debian

There is a lot of myths that surround what distros actually do, can do, and have the resources to do. We had this discussion in one of the two threads I linked.

That’s a failed analogy. The AUR is an end-user build-script repo, not a source/binary/source+binary repo for both devs and sometimes users.

If you e.g. install a CLI tool via cargo, there is at least an implicit tree of trust, with each dependant in a dependency tree doing at least some minimal vetting of dependencies. And the source is all there anyway (barring exceptions like build.rs pulling code, or the indirection of proc macros).

The same applies to npm and pypi, although there is no distinction between “code” and “binary”, given the scripting nature of the languages. But some pypi packages do actually distribute binaries (e.g. C/C++ compiled libraries). Don’t know about npm.

But, if I’m not mistaken, the py/js tooling wasn’t always there for stuff like full pinning of dep versions like cargo, and that’s a very important technical detail.

With the AUR, there is no trust tree. And often no fixed code (or binaries) to look at (e.g. *-git packages). So the feasibility of doing any sort of global in-tree checking/vetting is not there. On the other hand, source repos are responsible for removing, or at least flagging, malware or otherwise harmful packages once that becomes known.

Incidentally, I commented on both AUR security and cargo trust here and here. So, I will stop blabbing.

OH NO, they must be devastated!

P.S. Since it wasn’t mentioned already, look up cgroups.

Back when I had a humble laptop (pre-Rust), using nice and co. didn’t help much. Custom schedulers come with their own stability and worst-case-scenario baggage. cgroups should give you supported and well-tested tunable kernel-level resource usage control.

This hasn’t been my experience when no swapping is involved (not a concern for me anymore with 32GiB physical RAM with 28GiB zram).

And I’ve been Rusting since v1.0, and Linuxing for even longer.

And my setup is boring (and stable), using Arch’s LTS kernel which is built with CONFIG_HZ=300. Long gone are the days of running linux-ck.

Although I do use craneleft backend now day to day, so compiles don’t take too long anyway.