A PR fixing the issue has already been submitted (which surfaced another issue, but it doesn’t concern stable).

People likening this to the issue behind cve-rs (which is blocked on a major rework) are clueless, which happens to be par for the course regarding anything Rust. So no surprises there.

But I don’t understand why everyone else has an outdated version number.

Who are you talking about? If it’s AUR uploaders, the version you see is the version in the last uploaded PKGBUILD. AUR itself doesn’t build anything. And PKGBUILD uploaders don’t need to keep uploading to bump the version because it auto-updates when a user builds it. They only need to upload to fix builds if they get broken, or update meta info, …etc.

git (vcs in general) packages always update unless you pass --holdver with makepkg.

And just to be clear, that relates to git sources not the package name. The -git naming is just a convention that has no bearing on functionality.

Maybe its just a placeholder

Mostly yes. You can just put “0” or “1” initially. Build once, and it will be populated anyway.

The +nightly syntax is a rustup proxy feature, so a distro-packaged cargo won’t even parse it. Nightly is a different compiler every day.

export RUSTC_BOOTSTRAP=1 and you wouldn’t need rustup or nightly. It will work with your stable distro package.

clap = “4” and anyhow = “1” are ranges, and there’s no Cargo.lock.

you can do clap = "=4.x.x", ditto for all deps, direct and indirect.

Nightly is a different compiler every day.

Nothing about that script is fixed except its text.

Is nix finished free-standing software?

but maybe “safe enough”.

It won’t be. Bjarne doesn’t want any real workable safety to be added. And that’s for the best because it’s a shit language. And falling out of favor, especially for new projects, is the best outcome.

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.

I think the other user meant that ls output is not supposed to be treated as parsable, because the tool doesn’t offer any guarantees in that regards.

Shells have built-in support for globbing files anyway. xargs is also not needed. If someone is allergic to using a shell for loop, find always had -exec with ; instead + which wouldn’t trip on too many arguments.

Try out CrispASR.

They didn’t use that technique. Some vibers do ask Codex to review Claude and vice versa. But since this is Anthropic-owned, they did use “parallel agents”, but they were all Claude.

You could have searched for some benchmarks yourself, instead of thinking you’re winning an argument in such a stupid manner.

Note that Jarred himself (bun creator) wouldn’t push against this either. Instead, he will sell you the aggregate performance talking point (as another user did), which is why I made my deliberately facetious comment about webshittery.

can execute TypeScript directly.

Did the word “directly” get the same fate the word “literally” got? As in, it completely lost its real meaning?

Bundling a compiler/transpiler and directing inotify at a source directory (for glorious hot-reloading) doesn’t a language “runtime” make. Otherwise, I can create “runtimes” for any language in three lines of code right now.

unless you’re saying that Bun is slower.

Are you saying JavaScriptCore is faster than V8? Or is the majority of time in webshittery operations not spent on actually running code, and that’s how bun “wins” ?

I’m going to call cargo a Rust runtime from now on, considering cargo-script exists.

First of all. Strictly speaking, there is no such a thing as a TS runtime. TS compiles to JS.

Second of all, bun binds against JavaScriptCore, which is the JS engine used in Safari. Node binds against V8, which is the engine used by Blink (Chromium et al). Both are implemented in C++. And the latter is considered the fastest engine.

Ironically, both engines are mentioned by name in the very bun blog post being discussed, which points to a problem that is almost bigger than mere tech literacy from the pseudo-intellectual OP.

You can interface with a C++ JS engine without unsafe (which is equivalent to just using C btw), if you just really put a real effort into it.

😇

I do love me some internet gantry commentary. Especially when it’s super confident and acting knowledgable, with multiple layers of genius on display.

You clearly don’t even know what unsafe in rust means. And it’s not something you can avoid when FFI is involved, slopping involved or otherwise.

Bun is a TypeScript runtime, like a faster NodeJS.

I guess the target audience is non-coding AI skeptics looking for pseudo-intellectual takes, which appears to be a growing market. Because getting the very first technical detail, and a very basic one at that, this wrong is not a good look.

There is a huge difference between vetting packages once every 6 years,

And here the myth shows its head. No one is actually “vetting” 10s of thousand of packages, to a meaningful degree.

And all distros have rolling channels and testing channels, so the every X years part is mythical itself.

In the case of Debian, when is the mythical vetting taking place exactly? Whenever a Debian unstable/sid package gets updated? That’s a rolling repo.
Or is it when world is frozen, and the unvetted packages which lived happily in “unstable” and “testing” will now magically get vetted on their way to “stable”, in a few months (not six years as you imagined).

You clearly lack basic knowledge about what actually goes on in a distro release cycle.

This is because rust and crates makes it impossible to do any form of dynamic linking. Which is why some people have gripes with rust and avoid it.

You missed the point. crates.io is a source registry. Debian ships binary packages (yes, including rust ones).

Where do you think Debian gets source packages for C or C++ from? Did you think they get them in the (physical) mailbox? 🎅

As for dynamic linking, the “security” argument for it has been discussed and debunked. You can search the web for discussions regarding that. Most arguments for .so has been debunked, in fact.

But for C, Java, and other languages, it is possible for distros to ship and manage libraries, which has the benefit that the various libraries can have their security issues fixed automatically.

Nothing is “automatic” when it comes to distro maintenance. Much more so when an upstream doesn’t give a f*** about helping you patch your X years old version. If Red Hat, Canonical, …etc wasn’t actively paying developers to do maintenance, Debian wouldn’t exist as it is. But even then, that only covers a very small fraction of core packages.

The model of vendoring dependencies, breaks this. With Cargo (or uv or etc), the programs move very fast, and updates break things. In order to prevent their program from breaking, developers pin packages. And then, they don’t update them.

Pinning and vendoring are orthogonal.

The original talking points were about source supply chains. But people like you seem to confuse concerns across multiple chains from the individual upstream dev to the binary distro repo mirror.

Pinning is actually the only way to actually (almost*) guarantee that built code would work correctly. What distros sell you is “should work” and “API looks compatible” and “this patch hopefully doesn’t break the interface”.

And more ironically, why distros do is global pinning, so the problem is apparently not pinning itself, but upstreams choosing the pinning themselves, right? right?

“But they don’t fully pin… security updates smth smth”

Good. Let’s continue…

Here is cargo-audit ran against radicle-tui

Good.

The next best thing to pinning is semver-compatible updates.

Now you have an example where you will see that to “fix all CVEs”, you need to run the total of TWO whopping commands.

You ran the first command already. The second is cargo update (or cargo update <only_audit_mentioned_packages> if you want to be more precise.

cargo update only does semver-compatible updates, as released, authorized, and supported by the upstreams, whose knowledge of the code and its interfaces infinitely trumps your random distro maintainer doing raw patching. This is how a coherent competent ecosystem operates.

Some of what the distros do is actually not far away from this. If you looked close enough, you will find that it’s not rare for a stated “frozen” version to be a complete lie, with distro patches effectively updating the distro source package to a later patch, or sometimes even minor version, without changing the version number.

But of course, they wouldn’t tell you about any of that, because the myths must live on 😉.

I can be confident that if I make a program tied to libraries or programs that the distro provides, this stuff will automatically be patched and handled for me.

While not completely misplaced, your confidence is inspiring 🙂.

Weird how this random thread came back to life, just to rehash some talking points.

See my comments here and here.

In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

If you followed the link, you would have seen that nothing actually fishy was found, unlike the implication.

Cargo and crates are basically just as bad as npm, just less popular, which is why they haven’t been hit yet… And it’s currently very difficult to build rust programs without cargo.

The number of actual supply chain attacks actually effecting anybody in the crates.io ecosystem is ZERO. In npm, it’s a weekly occurrence.

less popular

Rust cleared the critical mass and critical relevance milestone years ago. Most people can run desktops without npm or local js code. This is increasingly unfeasible for rust components. And yet, nothing happened. And that’s not a coincidence (read linked threads). That doesn’t mean nothing will ever happen. Nothing is fully fail-safe. But the talking points themselves are completely false.

Also, I would like to see you explain how cargo itself is a problem. It’s a build tool that is not tied to crates.io. You can use different registries, repos, and even full vendoring with it (which you can switch to with one command, and it will just work). But I can’t wait to hear your explanation 🙂. Examples of tools that do it better, with an explanation why would also be appreciated 🙂.

Stable linux distributions have extremely strong supply chain security in comparison to language specific package managers.

This myth is discussed extensively in the linked threads at the start of this comment, especially the second one.

Debian, for example, was not affected by the xz utils backdoor, due to it’s policy of only doing cherry picked security patches, and ignoring feature or bugfixes for the most part.

Also covered in the linked threads. But let’s address specifics.

• Debian unstable/sid (the rolling branch) was affected. Debian is not special.
• Debian stable was unaffected because it runs multi-year old packages. This specific attack was discovered early, so they were spared. Other upstream-controlled attacks could target projected-to-be-stable upstream versions, and remove the compromised part later, reversing that effect (depending on who would discover the malicious code, and what are they testing looking at).
• The stable distro model is broken. Distro developers are not better than upstreams at judging upstream code. Many non-security tagged bugs can become security ones. And out-of-date(ness) itself can have adverse affects in other ways. This was always been known/realized by people who know the reality of the situation. But nowadays, “AI” security scanners had a complete mockery of the stable distro model “security” claims.
• Debian’s willy-nilly “security” patching in particular, lead to multiple scandals in the past. This is not all theoretical. One day half the internet had to re-issue SSL certs/keys because of the mythical Debian super security. And on that subject, do you know what distro wasn’t affected by the specific xz attack, despite actually shipping the compromised xz version? It’s Arch. Why? Because they didn’t patch systemd with xz support thinking they can outsmart an upstream.
• Distros pull from upstreams anyway (code has to exist somewhere), crates.io included. So they inherently can’t have better supply chain security than upstreams at the code level, unless you’re also a believer in the popular myth "they review and vet everything ". Some distros may have good/better build security practices. But that’s about it.

I would prefer Java if you cared strongly about supply chain security

What makes you think JAVA or its ecosystem(s) are unique or immune from any of this?

Another hit-and-run Rust thread!

I advise against any more activity here, until, or rather, unless OP appears again.

It’s on the title, you don’t even need to read the excerpt👆.

But more seriously, the excerpt is from the release/tag notes, but what’s quoted above is from the README.

While eventually implementing incremental linking was the inspiration, as already pointed out. It’s actually already faster than mold (see benchmarks).