If it hasn&#x27;t seen an upstream release since 2019, doesn&#x27;t that mean the implementation is just... finished?
Maybe there&#x27;s no more bugs to fix and features to add. And in that case, I don&#x27;t see what&#x27;s wrong with it.

It&#x27;s not. At least not yet. It&#x27;s planned for 25.10, but thankfully sudo will be packaged and available for a few versions after that as promised [1].[1] <a href="https:&#x2F;&#x2F;discourse.ubuntu.com&#x2F;t&#x2F;adopting-sudo-rs-by-default-in-ubuntu-25-10&#x2F;60583" rel="nofollow">https:&#x2F;&#x2F;discourse.ubuntu.com&#x2F;t&#x2F;adopting-sudo-rs-by-default-i...</a>

Ubuntu is using Rust sudo so it&#x27;s definitely possible.

They do provide a compatible C ABI. Someone &quot;just&quot; needs to do the work to make it happen.

1) This is a cool project and I wish them success. It would be really cool if these became the default utilities some day soon.2) I think the MIT license was a mistake. These are often cloning GNU utilities, so referencing GNU source in its original language and then re-implementing it in Rust would be the obvious thing to do. But porting GPL-licensed code to an MIT licensed project is not allowed. Instead, the utilities must be re-implemented from scratch, which seems like a waste of effort. I would be interested in doing the work of porting GNU source to Rust, but I&#x27;m not interested in re-writing them all from scratch, so I haven&#x27;t contributed to this project.

I hope some are improved too.The performance boost in tools like ripgrep and tokei is insane compared to the tools they replace (grep and cloc respectively).

I think that is the goal of uutils.<a href="https:&#x2F;&#x2F;uutils.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;uutils.github.io&#x2F;</a>

I briefly looked a this and there&#x27;s already cargo-c configuration, which is good, but it&#x27;s currently namespaced differently, so it won&#x27;t get automatically detected by C programs as `libbz2`:<a href="https:&#x2F;&#x2F;github.com&#x2F;trifectatechfoundation&#x2F;libbzip2-rs&#x2F;blob&#x2F;8214be22d32e91d31a122409eba5f3c67dc80659&#x2F;libbz2-rs-sys-cdylib&#x2F;Cargo.toml#L30-L39">https:&#x2F;&#x2F;github.com&#x2F;trifectatechfoundation&#x2F;libbzip2-rs&#x2F;blob&#x2F;8...</a>I&#x27;m not familiar enough with the symbols of bzip2 to say anything about ABI compatibility.I have a toy project to explore things like that, but it&#x27;s difficult to set aside the amount of time needed to maintain an implementation of the GNU operating system. I would welcome pull requests though:<a href="https:&#x2F;&#x2F;github.com&#x2F;kpcyrd&#x2F;platypos">https:&#x2F;&#x2F;github.com&#x2F;kpcyrd&#x2F;platypos</a>

The commenters below are confusing two things - Rust binaries can be dynamically linked, but because Rust doesn’t have a stable ABI you can’t do this across compiler versions the way you would with C. So in practice, everything is statically linked.

Rust cannot dynamic link to rust. It can dynamic link to C and be dynamicly linked by C - if you combine the two you can cheat but it is still C that you are dealing with not rust even if rust is on both sides.

No. <a href="https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;reference&#x2F;linkage.html#r-link.dylib" rel="nofollow">https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;reference&#x2F;linkage.html#r-link.dyli...</a>

Rust lets you generate dynamic C-linkage libraries.Use crate-type=[&quot;cdylib&quot;]

Dynamic linking works fine if you target the C ABI.

Rust importing Rust must be statically linked, yes. You can statically link Rust into a dynamic library that other libraries link to, though!

You can use dynamic linking in Rust with C ABI. Which means going through `unsafe` keyword - also known as &#x27;trust me bro&#x27;. Static linking directly to Rust source means it is checked by compiler so there is no need for unsafe.

&gt; You just need to provide a C ABI compatible with the original one.How does this interact with dynamic linking? Doesn&#x27;t the current Rust toolchain mandate static linking?

ripgrep is one of the best grep replacement you can find, maybe even the best, and also one of the most famous Rust projects.I don&#x27;t know of a sed equivalent, but I guess that would be easy to implement as Rust has good regex support (see ripgrep), and 90%+ of sed usage is search-and-replace. The other commands don&#x27;t look hard to implement and because they are not used as much, optimizing these is less of a priority.I don&#x27;t know about awk, it is a full programming language, but I guess it is far from an impossible task to implement.Now the real hard part is making a true, bug-for-bug compatible replacement of the GNU version of these tools, but while good to have, it is not strictly necessary. For example, Busybox is very popular, maybe even more so than GNU in terms of number of devices, and it has its own (likely simplified) version of grep, sed and awk.

i wait until they come to the hard stuff like awk, sed and grep.

How realistic is it for the Trifecta Tech implementation to start displacing the &quot;official&quot; implementation used by linux distros, which hasn&#x27;t seen an upstream release since 2019?Fedora recently swapped the original Adler zlib implementation with zlib-ng, so that sort of thing isn&#x27;t impossible. You just need to provide a C ABI compatible with the original one.

Common Crawl delivers the data as bz2. Indeed I store intermediate data in zstd with ZFS.

That assumes you&#x27;re processing the data more than once.

What&#x27;s the reason for using bz2 here? Wouldn&#x27;t it be faster to do a one off conversion to zstd? It beats bzip2 in every metric at higher compression levels as far as I know.

bzip2 (particularly parallel implementations thereof) are already relatively competitive for compression. The decompression time is where it lags behind because lz77 based algorithms can be incredibly fast at decompression.

Yeah came here to say a 14% speed up in compression is pretty good!

I use this crate to process 100s of TB of Common Crawl data, I appreciate the speedups.

FTA:&gt; Why bother working on this algorithm from the 90s that sees very little use today?What&#x27;s in use nowadays ? zstd ?ahh saw this: <a href="https:&#x2F;&#x2F;quixdb.github.io&#x2F;squash-benchmark&#x2F;" rel="nofollow">https:&#x2F;&#x2F;quixdb.github.io&#x2F;squash-benchmark&#x2F;</a>

There&#x27;s certainly a contrast between the &quot;Oops a huge file causes a runtime failure&quot; reported for that crate and a bunch of &quot;Oops we have bounds misses&quot; in C. I wonder how hard anybody worked on trying to exploit the bounds misses to get code execution. It may or may not be impossible to achieve that escalation.

&gt; The bzip2 crate before 0.4.4They&#x27;re releasing 0.6.0 today :&gt;

But it does apply to the bzip2 crate, which is the topic of discussion. Its new pure-rust implementation is libbz2-rs-sys, not bzip2-rs. The last sentence is irrelevant.

This article is about the bzip2 crate, not the bzip2-rs crate, despite the repo for the former having the name of the latter.

Anyone know if this will by default resolve the 11 outstanding CVEs?Ironically there is one CVE reported in the bzip2 crate[1] <a href="https:&#x2F;&#x2F;app.opencve.io&#x2F;cve&#x2F;?product=bzip2&amp;vendor=bzip2_project" rel="nofollow">https:&#x2F;&#x2F;app.opencve.io&#x2F;cve&#x2F;?product=bzip2&amp;vendor=bzip2_proje...</a>

This makes a lot of sense to me, though I don’t know the official answer so I’m just sort of guessing along too.Linked from the article is another on how they used c2rust to do the initial translation.<a href="https:&#x2F;&#x2F;trifectatech.org&#x2F;blog&#x2F;translating-bzip2-with-c2rust&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trifectatech.org&#x2F;blog&#x2F;translating-bzip2-with-c2rust&#x2F;</a>For our purposes, it points out places where the code isn’t very optimal because the C code has no guarantees on the ranges of variables, etc.It also points out a lot of people just use ‘int’ even when the number will never be very big.But with the proper type the Rust compiler can decide to do something else if it will perform better.So I suspect your idea that it allows unlocking better optimizations though more knowledge is probably the right answer.

Ergonomics of using the right data structures and algorithms can also play a big role. In C, everything beyond a basic array is too much hassle.

Just speculating: Rust can hand over more hints to the code generator. Eg you don&#x27;t have to worry about aliasing as much as with C pointers. See <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Aliasing_(computing)#Conflicts_with_optimization" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Aliasing_(computing)#Conflicts...</a>

Popcount, clz, and ctz are provided as nonstandard functions in GCC (and clang might also support them in GNU mode, but I don&#x27;t know for sure). PDEP and PEXT do not seem to be, but I think they should be (and PEXT is something that INTERCAL already had, anyways) (although PDEP and PEXP can be used with -mbmi2 on x86, but are not available for general use). The MOR and MXOR of MMIX are also something that I would want to be available as built-in functions.

C is honestly a pretty bad language for writing modern high performance code. Between C99 and C21, there was a ~20 year gap where the language just didn&#x27;t add features needed to idiomatically target lots of the new instructions added (without inline asm). Just getting good abstract machine instructions for clz&#x2F;popcnt&#x2F;clmul&#x2F;pdep etc helps a lot for writing this kind of code.

any rewrite, in X, Y, Z language gives you the opportunity to speed things up, there is nothing inherent to rust

i&#x27;d be curious if they&#x27;re using the same llvm codegen (with the same optimization) backend for the c and rust versions. if so, where the speedups are coming from?(ie, is it some kind of rust auto-simd thing, did they use the opportunity to hand optimize other parts or is it making use of newer optimized libraries, or... other)

Thank you, precisely what I had in mind! Somehow I missed this project. As well as Holo[1] (routing)[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;holo-routing&#x2F;holo">https:&#x2F;&#x2F;github.com&#x2F;holo-routing&#x2F;holo</a>

Check out<a href="https:&#x2F;&#x2F;nlnet.nl&#x2F;project&#x2F;current.html" rel="nofollow">https:&#x2F;&#x2F;nlnet.nl&#x2F;project&#x2F;current.html</a>
<a href="https:&#x2F;&#x2F;www.sovereign.tech&#x2F;programs&#x2F;fund" rel="nofollow">https:&#x2F;&#x2F;www.sovereign.tech&#x2F;programs&#x2F;fund</a>There&#x27;s been good support over the last couple of years to fund rewriting critical internet &amp; OS tools into safer languages like Rust.Eg BGP in Rust <a href="https:&#x2F;&#x2F;www.nlnetlabs.nl&#x2F;projects&#x2F;routing&#x2F;rotonda&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.nlnetlabs.nl&#x2F;projects&#x2F;routing&#x2F;rotonda&#x2F;</a>

Is that domain actually about memory safety or about Rust?

<a href="https:&#x2F;&#x2F;www.memorysafety.org&#x2F;initiative&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.memorysafety.org&#x2F;initiative&#x2F;</a> this page mentions TLS and DNS which goes some way towards your suggestion.

Nothing against Ada, it&#x27;s a good language. The only problem would be finding contributors in that case.

One guy did Ironsides DNS in SPARK Ada which has stronger proofs.

I hope they or Prossimo will also look and reimplement in the similar fashion the core Internet protocols - BGP, OSPF and RIP, other routing implementations, DNS servers, and so on.

About not having perf on macOS: you can get quite far with dtrace for profiling. That’s what the original flame graph script in Perl mentions using and what the flame graph Rust reimplementation also uses. It does not have some metrics like cache misses or micro instructions retired but still it can be very useful.

Does anyone know if it supports parallel decompression, lbzip2-style? (or just iterators doing pre-scanning for the block magic that allow doing parallel decompression on top).Edit : it probably doesn&#x27;t.

Thanks for showing us you have no understanding of python&#x27;s situation.

Lbzip2 had much faster decompressing speed, using all available CPU cores.It&#x27;s 2025, and most programs like Python are stuck at one CPU core.

rust aside, I really enjoy seeing all these different implementation benchmarks, very satisfying to read

Serious answer: For some, they do change semi-often and don&#x27;t feel compelled to declare stability. In other cases, it&#x27;s a stable + widely used 0.x package, and bumping it to 1.0 usually implies _some_ kind of breaking change. (I don&#x27;t know if that _should_ be the case, but I know that if I see a dependency has bumped from 0.x to 1.0 I&#x27;m going to be cautious and wait to update it until I have more time).In general: People usually aren&#x27;t too concerned about it.

This list&#x27;s Zig as an entry, despite the Zig project having very clear plans[0] for a 1.0 release. That&#x27;s not 0ver, it&#x27;s just the beta stage of semver.[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;ziglang&#x2F;zig&#x2F;milestone&#x2F;2">https:&#x2F;&#x2F;github.com&#x2F;ziglang&#x2F;zig&#x2F;milestone&#x2F;2</a>

<a href="https:&#x2F;&#x2F;0ver.org&#x2F;#notable-zerover-projects" rel="nofollow">https:&#x2F;&#x2F;0ver.org&#x2F;#notable-zerover-projects</a>

I like Rust and have an ambition to learn it as well (I&#x27;ve had a few false starts...). One of my issues that I have is that every (slight exaggeration) library that I seem to come across is still at version 0.x.y. Take this library as an example. 0.1.0 was released in 2014 and it still hasn&#x27;t had a 1.0.0 release, is there an aversion to get to 1.0.0 in the rust community?

&gt; After the uutils debacleWhich debacle?

Sure there is: someone provided you bzip2 files. Or required you give them files in that format.Then you don’t have a choice.And if you have to use it, 14% is a really nice speed up.

You should of course verify these results in your scenario. However, I somewhat doubt that the person exists who cares greatly about performance, and is still willing to consider bzip2. There isn&#x27;t a point anywhere in the design space where bzip2 beats zstd. You can get smaller outputs from zstd in 1&#x2F;20th the time for many common inputs, or you can spend the same amount of time and get a significantly smaller output, and zstd decompression is again 20-50x faster depending. So the speed of your bzip2 implementation hardly seems worth arguing over.

They indeed used c2rust for the initial transpile according to <a href="https:&#x2F;&#x2F;trifectatech.org&#x2F;blog&#x2F;translating-bzip2-with-c2rust&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trifectatech.org&#x2F;blog&#x2F;translating-bzip2-with-c2rust&#x2F;</a>

If you&#x27;re going to use tools to transpile, don&#x27;t use something that hallucinates. You want it to be precise.<a href="https:&#x2F;&#x2F;github.com&#x2F;immunant&#x2F;c2rust">https:&#x2F;&#x2F;github.com&#x2F;immunant&#x2F;c2rust</a> reportedly works pretty well. Blog post from a few years ago of them transpiling quake3 to rust: <a href="https:&#x2F;&#x2F;immunant.com&#x2F;blog&#x2F;2020&#x2F;01&#x2F;quake3&#x2F;" rel="nofollow">https:&#x2F;&#x2F;immunant.com&#x2F;blog&#x2F;2020&#x2F;01&#x2F;quake3&#x2F;</a>. The rust produced ain&#x27;t pretty, but you can then start cleaning it up and making it more &quot;rusty&quot;

Without commenting on whether an LLM is the right approach, I don&#x27;t think this task is particularly hard to audit. There is almost assuredly a huge test suite for bzip2 archives; fuzzing file formats is very easy; and you can restrict &#x2F; audit the use of unsafe by the translator.

Task that requires precision and potentially hard to audit? Exactly where I&#x27;d use an LLM &#x2F;s

Do they use any llm to transpile the C to Rust ?

&gt; Counting CPU cycles as if it&#x27;s an accomplishment seems irrelevant in a world where 50% of modern CPU resources are allocated toward UI eye candy.That&#x27;s the kind of attitude that leads to 50% of modern CPU resources being allocated toward UI eye candy.

They kicked off the article saying that no one uses bzip2 anymore. A million cycles saved for something no one uses (according to them) is still 0% battery life saved.If modern CPUs are so power efficient and have so many spare cycles to allocate to e.g. eye candy no one asked for, then no one is counting and the comparison is irrelevant.

Every cycle saved is longer battery life. Someone paid the one time cost of porting it, and now we can enjoy better performance forever.

I personally find a lot more relevant the part about &quot;Enabling cross-compilation
&quot;, which in my opinion is important and a win.The same about exported symbols and being able to compile to wasm easily.

You know it is just Wirth&#x27;s law in action: &quot;Software gets slower faster than hardware gets faster.&quot; [^1]In fact Jevons Paradox: When technological progress increases the efficiency with which a resource is used, but the rate of consumption of that resource rises due to increasing demand - essentially, efficiency improvements can lead to increased consumption rather than the intended conservation. [^2][^3][^1]: <a href="https:&#x2F;&#x2F;www.comp.nus.edu.sg&#x2F;~damithch&#x2F;quotes&#x2F;quote27.htm" rel="nofollow">https:&#x2F;&#x2F;www.comp.nus.edu.sg&#x2F;~damithch&#x2F;quotes&#x2F;quote27.htm</a>[^2]: <a href="https:&#x2F;&#x2F;www.greenchoices.org&#x2F;news&#x2F;blog-posts&#x2F;the-jevons-paradox-when-efficiency-leads-to-increased-consumption" rel="nofollow">https:&#x2F;&#x2F;www.greenchoices.org&#x2F;news&#x2F;blog-posts&#x2F;the-jevons-para...</a>[^3]: <a href="https:&#x2F;&#x2F;quickonomics.com&#x2F;terms&#x2F;jevons-paradox&#x2F;" rel="nofollow">https:&#x2F;&#x2F;quickonomics.com&#x2F;terms&#x2F;jevons-paradox&#x2F;</a>

&gt; Counting CPU cycles as if it&#x27;s an accomplishment seems irrelevant in a world where 50% of modern CPU resources are allocated toward UI eye candy.Attitude which leads to electron apps replacing native ones, and I hate it.
I am not buying better cpus and more ram just to have it wasted like this

Buffer overflows are more a library problem, not a language problem, though for newer ecosystems like Rust the distinction is kind of lost on people. But point being, if you rewrote bzip2 using an equivalent to std::Vec, you&#x27;d end up in the same place. Unfortunately, the norm among C developers, especially in the past, was to open code most buffer manipulation, so you wind up with 1000 manually written overflow checks, some of which are wrong or outright missing, as opposed to a single check in a shared implementation. Indeed, even that Rust code had an off-by-one (in &quot;safe&quot; code), it just wasn&#x27;t considered a security issue because it would result in data corruption, not an overflow.What Rust-the-language does offer is temporal safety (i.e. the borrow checker), and there&#x27;s no easy way to get that in C.

It seems to me like binary file format parsing (and construction) is probably a good place for using languages that aren&#x27;t as prone to buffer-overflows and the like. Especially if it&#x27;s for a common format and the code might be used in all sorts of security-contexts.

Pretty incredible for such a short argument to be so inconsistent with itself. Complaining about counting CPU cycles and actually measuring performance because... modern software development is bad and doesn&#x27;t care about performance?

Those cycles translate directly to $ saved in a few places. Mostly in places far away from having any UI at all.

I fully agree with you on the first statement and I am at loss of words at the second...

you&#x27;re just an end user, you don&#x27;t have to maintain the suite.In OSS every hour of volunteer time is precious Manna from heaven, flavored with unicorn tears. So any way to remove Toil and introduce automation is gold.Rust&#x27;s strict compiler and an appropriate test suite guarantees a level of correctness far beyond C. There&#x27;s less onus on the reviewer to ensure everything still works as expected when reviewing a pull request.It&#x27;s a win-win situation.

It&#x27;s like &quot;adapting&quot; Akallabêth so you can tell your own empowering story for modern audiences.

&gt; lot of this &quot;rewrite X in Rust&quot; stuff feels likeIndeed. You know the react-angular-vue nevermind is churn? It appears that the trend of people pushing stuff because it benefit their careers is coming to the low level world.I for one still find it mistifying that Linus torvals let this people into the kernel. Linus, who famous banned c++ from the kernel not because of c++ in itself, but to ban c++ programmer culture.

Except Wayland was developed by the same people who worked for years on X. And they don&#x27;t dislike X because of C. And they didn&#x27;t write Wayland in Rust.

So you say younger programmer have not the required coding kung fu to cope with c code? I hope you are wrong. The perspective to have rust like things on everydays devices realy frightens me. C is like a Lingua franca for computers. Nearly any hardware near person can READ it. I am one of this Boomers and i am not able to propper READ rust code, because the syntax is so academic. The fact that more and more code is written in rust, lessens the amount of people that can read programs

It&#x27;s a lot like X11 vs. Wayland. The current graphics developers, who trend younger, don&#x27;t want to maintain the boomer-written C code in the X server. Too risky and time-consuming. So one of the goals of Wayland is to completely abolish X so it can be replaced with something more long-term maintainable. Turns out, current systems-level developers don&#x27;t want to maintain boomer-written GNU code or any C code at all, really, for similar reasons. C is inherently problematic because even seasoned developers have trouble avoiding its footguns. So an unstated, but important, goal of Rust is to abolish all critical C code and replace it with Rust code. Ubuntu is on board with this.

Do you have any reason to think their numbers are wrong, or is your argument &quot;someone else once lied, maybe they are too&quot;?

Rust devs continuing to use misleading benchmarks? I, for one, am absolutely shocked. Flabbergasted, even.

&gt; Counting CPU cyclesAnd that&#x27;s assuming they aren&#x27;t lying about the counting: <a href="https:&#x2F;&#x2F;desuarchive.org&#x2F;g&#x2F;thread&#x2F;104831348&#x2F;#q104831479" rel="nofollow">https:&#x2F;&#x2F;desuarchive.org&#x2F;g&#x2F;thread&#x2F;104831348&#x2F;#q104831479</a>

A lot of this &quot;rewrite X in Rust&quot; stuff feels like burning your own house down so you can rebuild and paint it a different color.Counting CPU cycles as if it&#x27;s an accomplishment seems irrelevant in a world where 50% of modern CPU resources are allocated toward UI eye candy.

Bzip2 crate switches from C to 100% Rust