zlib-rs => crate replacing non-rust zlib
firefox => where the replacement is happening
trifecta => the foundation sponsored to develop the replacements
Maybe I'm influenced by the fact that I pre-knew all of the above. But as I wrote, it's quite ironic choosing this perfect title in particular to complain about π.
On the topic of low(ish) level dependencies getting incrementally replaced with Rust rewrites, a Google employee did a presentation on the same topic recently.
People usually like at least some minimal context attached, in case they are not familiar with the topic at hand.
But as it happens, the title of this specific post is rather self-documenting. So I'm not sure what's "non-descriptive" about it.
Or perhaps we have automated complaining now, pushing against automated low quality (re-)posting. And we got caught in the middle as remnants of the genuine human interaction that used to take place online π.
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.
If it's Tex, it's not modern.
It's like:
"We have Swiss cheese with no holes."
Swiss cheese, or no holes? Pick one!
Another hit-and-run Rust thread!
I advise against any more activity here, until, or rather, unless OP appears again.
"-C", "link-arg=-lstdc++",
"-C", "link-arg=-lsupc++",
"-C", "link-arg=-lgcc_s"
Now, that's just funny. But hey, you're using -Os to keep that binary size low π
And what's with the global allocator being initialized in a module? (didn't/don't know if that even works)
If you want to do things really minimally, check out the rustix crate which wraps syscalls directly.
Otherwise, and if loading huge shared libraries is fine, then you might as well not go nostd at all, since you can just pass -C prefer-dynamic for that elusive magically-small std-using binary π
Get well brother.
As a son of a specialist physician, I know full well how hard it can be to connect the dots between random symptoms and a problem that's actually in the brain. It's not rare for such confirmed diagnoses to become case presentations (which is how I know π).
creen TUI workloads (vt100 0.16 leaks tens of GB under multi-hour
claude-style streams; this does not).
Interesting stress test you got there.
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).
The project description reminded me of a project I saw years ago. I looked it up, and I'm pretty sure it was oxen, which is surprisingly still going, although their hub looks half-dead.