8 ms·

How realistic is it for the Trifecta Tech implementation to start displacing the "official" implementation used by linux distros, which hasn't seen an upstream

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

masfuerte 1y ago
They do provide a compatible C ABI. Someone "just" needs to do the work to make it happen.
rlpb 1y ago
> You just need to provide a C ABI compatible with the original one. How does this interact with dynamic linking? Doesn't the current Rust toolchain mandate static linking?
- sedatk 1y ago
  No. https://doc.rust-lang.org/reference/linkage.html#r-link.dylib https://doc.rust-lang.org/reference/linkage.html#r-link.dyli...
- arcticbull 1y ago
  Rust lets you generate dynamic C-linkage libraries. Use crate-type=["cdylib"]
- nicoburns 1y ago
  Dynamic linking works fine if you target the C ABI.
- timeon 1y ago
  You can use dynamic linking in Rust with C ABI. Which means going through `unsafe` keyword - also known as 'trust me bro'. Static linking directly to Rust source means it is checked by compiler so there is no need for unsafe.
- bluGill 1y ago
  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.
  - deleted 1y ago
    [deleted]
  - mjevans 1y ago
    It might help to think of it as two IPC 'servers' written in rust that happen to have the C ABI interfaces as their communication protocol.
  - filmor 1y ago
    Rust can absolutely link to Rust libraries dynamically. There is no stable ABI, so it has to be the same compiler version, but it will still be dynamically linked.
- conradev 1y ago
  Rust importing Rust must be statically linked, yes. You can statically link Rust into a dynamic library that other libraries link to, though!
- alxhill 1y ago
  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.
  - eru 1y ago
    Static linking also produces smaller binaries and lets you do link-time-optimisation.
    - emidln 1y ago
      Static linking doesn't produce smaller binaries. You are literally adding the symbols from a library into your executable rather than simply mentioning them and letting the dynamic linker figure out how to map those symbols at runtime. The sum size of a dynamic binary plus the dynamic libraries may be larger than one static linked binary, but whether that holds for more static binaries (2, 3, or 100s) depends on the surface area your application uses of those libraries. It's relatively common to see certain large libraries only dynamically linked, with the build going to great lengths to build certain libraries as shared objects with the executables linking them using a location-relative RPATH (using the $ORIGIN feature) to avoid the extra binary size bloat over large sets of binaries.
      - IshKebab 1y ago
        Static linking does produce smaller binaries when you bundle dependencies. You're conflating two things - static vs dynamic linking, and bundled vs shared dependencies. They are often conflated because you can't have shared dependencies with static linking, and bundling dynamically linked libraries is uncommon in FOSS Linux software. It's very common on Windows or with commercial software on Linux though.
        guappa 1y ago
        You know how the page cache works? Static linking makes it not work. So 3000 processes won't share the same pages for the libc but will have to load it 3000 times.
wmf 1y ago
Ubuntu is using Rust sudo so it's definitely possible.
- egorfine 1y ago
  It's not. At least not yet. It's planned for 25.10, but thankfully sudo will be packaged and available for a few versions after that as promised [1]. [1] https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-in-ubuntu-25-10/60583 https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-i...
tiffanyh 1y ago
I think that is the goal of uutils. https://uutils.github.io/ https://uutils.github.io/
- cocoa19 1y ago
  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).
  - egorfine 1y ago
    I absolutely hate it when people call their tools a "replacement" for something that is part of core standards, something, that did just fine for decades. ripgrep is an excellent tool. But it's not a grep replacement. And should not ever be.
    - mprovost 1y ago
      The GNU utils were a replacement for the BSD utils which were a replacement for the original AT&T utils. Every replacement added new functionality and improvements, and every time someone complained that they didn't stick closer to the thing they replaced. Looking specifically at grep, there used to be new versions like egrep and fgrep that added functionalities beyond standard grep's, but those were eventually pulled into "standard" grep (GNU or BSD). If we stuck with standards we'd all still be using the Bourne shell. The GNU utilities have been around long enough that they feel like the standard now, but I'm glad that we're coming into a new phase of innovation in command-line utilities. And this didn't start with Rust - the new generation of search utilities started with ack (Perl) and then ag (C).
      - egorfine 1y ago
        > which were a replacement for the You have a point here. I have to agree. "X but rewritten in Z" is a terrible marketing, though. Makes me instantly want to hate the tool and its authors. (Love rust. Hate the vibe).
deknos 1y ago
i wait until they come to the hard stuff like awk, sed and grep.
- GuB-42 1y ago
  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'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't look hard to implement and because they are not used as much, optimizing these is less of a priority. I don'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.
  - scns 1y ago
    There is sd, not a drop in replacement though. https://github.com/chmln/sd https://github.com/chmln/sd
- egorfine 1y ago
  What would be the point?
kpcyrd 1y ago
I briefly looked a this and there's already cargo-c configuration, which is good, but it's currently namespaced differently, so it won't get automatically detected by C programs as `libbz2`: https://github.com/trifectatechfoundation/libbzip2-rs/blob/8214be22d32e91d31a122409eba5f3c67dc80659/libbz2-rs-sys-cdylib/Cargo.toml#L30-L39 https://github.com/trifectatechfoundation/libbzip2-rs/blob/8... I'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'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: https://github.com/kpcyrd/platypos https://github.com/kpcyrd/platypos
Pesthuf 1y ago
If it hasn't seen an upstream release since 2019, doesn't that mean the implementation is just... finished? Maybe there's no more bugs to fix and features to add. And in that case, I don't see what's wrong with it.
- LinusU 1y ago
  Isn't 10-15% faster compression, and 5-10% faster decompression, a very nice "feature"? > [...] doesn't that mean the implementation is just... finished? I don't think that it _necessarily_ means that, e.g. all projects that haven't had a release since 2019 aren't finished? Probably most of them are simply abandoned? On the other hand, a finished implementation is certainly a _possible_ explanation for why there have been no releases. In this specific case, there are a handful of open bugs on their issue tracker. So that would indicate that the project isn't finished. ref: https://sourceware.org/bugzilla/buglist.cgi?product=bzip2 https://sourceware.org/bugzilla/buglist.cgi?product=bzip2
  - restalis 1y ago
    "Isn't 10-15% faster compression, and 5-10% faster decompression, a very nice «feature»?" Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays. Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me. ¹ ...and not only. I've already described in other comments some of the issues I see with it as a software development tool, here https://news.ycombinator.com/item?id=31565024 https://news.ycombinator.com/item?id=31565024 here https://news.ycombinator.com/item?id=33390634 https://news.ycombinator.com/item?id=33390634 and here https://news.ycombinator.com/item?id=42241516 https://news.ycombinator.com/item?id=42241516
    - LinusU 1y ago
      > Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays. Makes sense, and I'd probably make the same call if I was a maintainer and someone submitted a patch which increased performance at the cost of maintainability... > Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me. Here I have to personally disagree. I think that Rust is easier than both C and C++. Especially when coming into an already existing project. The chance of me contributing to a Rust project is higher than to a C project, because I feel more comfortable in knowing that my code is "correct". It's also easier to match the "style" since most Rust projects follow the same structures and patterns, whereas in C it can vary wildly. E.g. I contributed my first feature to Valkey (Redis fork, C codebase) recently, and figuring out how the tests worked took me quite some time. In fact, in the end I couldn't figure out how to run a specific test so I just ran all tests and grepped the output for my test name. But the tests take tens of minutes to run so this was sub-optimal. On the other hand, 99% of all Rust projects use `cargo test`, and to run a single test I can just click the play button in my editor (Zed) that shows up next to the test (or `cargo test "testname"`). (with this said, I think that Valkey is a really well structured code base! Great work on their part) Anyhow, this is just to illustrate my experience. I'm sure that for someone more used to C or C++ they would be more productive in that. And I could go on for ages on all the features that make me miss Rust every day at work when I have to work in other languages, especially algebraic data types!

masfuerte 1y ago

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

rlpb 1y ago

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

sedatk 1y ago
No. https://doc.rust-lang.org/reference/linkage.html#r-link.dylib https://doc.rust-lang.org/reference/linkage.html#r-link.dyli...
arcticbull 1y ago
Rust lets you generate dynamic C-linkage libraries. Use crate-type=["cdylib"]
nicoburns 1y ago
Dynamic linking works fine if you target the C ABI.
timeon 1y ago
You can use dynamic linking in Rust with C ABI. Which means going through `unsafe` keyword - also known as 'trust me bro'. Static linking directly to Rust source means it is checked by compiler so there is no need for unsafe.
bluGill 1y ago
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.
- deleted 1y ago
  [deleted]
- mjevans 1y ago
  It might help to think of it as two IPC 'servers' written in rust that happen to have the C ABI interfaces as their communication protocol.
- filmor 1y ago
  Rust can absolutely link to Rust libraries dynamically. There is no stable ABI, so it has to be the same compiler version, but it will still be dynamically linked.
conradev 1y ago
Rust importing Rust must be statically linked, yes. You can statically link Rust into a dynamic library that other libraries link to, though!
alxhill 1y ago
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.
- eru 1y ago
  Static linking also produces smaller binaries and lets you do link-time-optimisation.
  - emidln 1y ago
    Static linking doesn't produce smaller binaries. You are literally adding the symbols from a library into your executable rather than simply mentioning them and letting the dynamic linker figure out how to map those symbols at runtime. The sum size of a dynamic binary plus the dynamic libraries may be larger than one static linked binary, but whether that holds for more static binaries (2, 3, or 100s) depends on the surface area your application uses of those libraries. It's relatively common to see certain large libraries only dynamically linked, with the build going to great lengths to build certain libraries as shared objects with the executables linking them using a location-relative RPATH (using the $ORIGIN feature) to avoid the extra binary size bloat over large sets of binaries.
    - IshKebab 1y ago
      Static linking does produce smaller binaries when you bundle dependencies. You're conflating two things - static vs dynamic linking, and bundled vs shared dependencies. They are often conflated because you can't have shared dependencies with static linking, and bundling dynamically linked libraries is uncommon in FOSS Linux software. It's very common on Windows or with commercial software on Linux though.
      - guappa 1y ago
        You know how the page cache works? Static linking makes it not work. So 3000 processes won't share the same pages for the libc but will have to load it 3000 times.

wmf 1y ago

Ubuntu is using Rust sudo so it's definitely possible.

egorfine 1y ago
It's not. At least not yet. It's planned for 25.10, but thankfully sudo will be packaged and available for a few versions after that as promised [1]. [1] https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-in-ubuntu-25-10/60583 https://discourse.ubuntu.com/t/adopting-sudo-rs-by-default-i...

tiffanyh 1y ago

I think that is the goal of uutils. https://uutils.github.io/ https://uutils.github.io/

cocoa19 1y ago
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).
- egorfine 1y ago
  I absolutely hate it when people call their tools a "replacement" for something that is part of core standards, something, that did just fine for decades. ripgrep is an excellent tool. But it's not a grep replacement. And should not ever be.
  - mprovost 1y ago
    The GNU utils were a replacement for the BSD utils which were a replacement for the original AT&T utils. Every replacement added new functionality and improvements, and every time someone complained that they didn't stick closer to the thing they replaced. Looking specifically at grep, there used to be new versions like egrep and fgrep that added functionalities beyond standard grep's, but those were eventually pulled into "standard" grep (GNU or BSD). If we stuck with standards we'd all still be using the Bourne shell. The GNU utilities have been around long enough that they feel like the standard now, but I'm glad that we're coming into a new phase of innovation in command-line utilities. And this didn't start with Rust - the new generation of search utilities started with ack (Perl) and then ag (C).
    - egorfine 1y ago
      > which were a replacement for the You have a point here. I have to agree. "X but rewritten in Z" is a terrible marketing, though. Makes me instantly want to hate the tool and its authors. (Love rust. Hate the vibe).

deknos 1y ago

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

GuB-42 1y ago
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'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't look hard to implement and because they are not used as much, optimizing these is less of a priority. I don'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.
- scns 1y ago
  There is sd, not a drop in replacement though. https://github.com/chmln/sd https://github.com/chmln/sd
egorfine 1y ago
What would be the point?

kpcyrd 1y ago

I briefly looked a this and there's already cargo-c configuration, which is good, but it's currently namespaced differently, so it won't get automatically detected by C programs as `libbz2`: https://github.com/trifectatechfoundation/libbzip2-rs/blob/8214be22d32e91d31a122409eba5f3c67dc80659/libbz2-rs-sys-cdylib/Cargo.toml#L30-L39 https://github.com/trifectatechfoundation/libbzip2-rs/blob/8... I'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'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: https://github.com/kpcyrd/platypos https://github.com/kpcyrd/platypos

Pesthuf 1y ago

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

LinusU 1y ago
Isn't 10-15% faster compression, and 5-10% faster decompression, a very nice "feature"? > [...] doesn't that mean the implementation is just... finished? I don't think that it _necessarily_ means that, e.g. all projects that haven't had a release since 2019 aren't finished? Probably most of them are simply abandoned? On the other hand, a finished implementation is certainly a _possible_ explanation for why there have been no releases. In this specific case, there are a handful of open bugs on their issue tracker. So that would indicate that the project isn't finished. ref: https://sourceware.org/bugzilla/buglist.cgi?product=bzip2 https://sourceware.org/bugzilla/buglist.cgi?product=bzip2
- restalis 1y ago
  "Isn't 10-15% faster compression, and 5-10% faster decompression, a very nice «feature»?" Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays. Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me. ¹ ...and not only. I've already described in other comments some of the issues I see with it as a software development tool, here https://news.ycombinator.com/item?id=31565024 https://news.ycombinator.com/item?id=31565024 here https://news.ycombinator.com/item?id=33390634 https://news.ycombinator.com/item?id=33390634 and here https://news.ycombinator.com/item?id=42241516 https://news.ycombinator.com/item?id=42241516
  - LinusU 1y ago
    > Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays. Makes sense, and I'd probably make the same call if I was a maintainer and someone submitted a patch which increased performance at the cost of maintainability... > Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me. Here I have to personally disagree. I think that Rust is easier than both C and C++. Especially when coming into an already existing project. The chance of me contributing to a Rust project is higher than to a C project, because I feel more comfortable in knowing that my code is "correct". It's also easier to match the "style" since most Rust projects follow the same structures and patterns, whereas in C it can vary wildly. E.g. I contributed my first feature to Valkey (Redis fork, C codebase) recently, and figuring out how the tests worked took me quite some time. In fact, in the end I couldn't figure out how to run a specific test so I just ran all tests and grepped the output for my test name. But the tests take tens of minutes to run so this was sub-optimal. On the other hand, 99% of all Rust projects use `cargo test`, and to run a single test I can just click the play button in my editor (Zed) that shows up next to the test (or `cargo test "testname"`). (with this said, I think that Valkey is a really well structured code base! Great work on their part) Anyhow, this is just to illustrate my experience. I'm sure that for someone more used to C or C++ they would be more productive in that. And I could go on for ages on all the features that make me miss Rust every day at work when I have to work in other languages, especially algebraic data types!