Tootfinder

New #RustLang projects are popping up all over the place. Many of them quickly reach feature parity with their non-Rust predecessors, then beat them both in functionality and performance. Seeing all this, it's hard not to think of Rust as a language that makes rapid development and deployment possible, and that outperforms other programming languages.
While I won't argue that Rust has its advantages, that's not the real reason here. In my opinion, it's all about its popularity. All the cool kids use Rust nowadays, and cool kids are precisely the kind of people who have time and energy to develop stuff rapidly. Add to that corporations investing in the next boom, and delivering a full-time paid workforce and funding, the culture of code reuse (i.e. sharing lots of crates), and last but not least, the benefit of starting from scratch.
Old folk like us, who barely manage enough energy to keep things alive, can't compete with that. However, we have one advantage. We don't care about being cool anymore. We aren't going to pack our bags and run after the next shiny thing, whenever the next best thing since sliced bread gets invented.
#Gentoo #OpenSource

Anyone have any experience with the static site generator Cobalt?
It's built in #RustLang and uses Liquid templating. Basically has the same site structure as #Jekyll.
Seems like I could port my Jekyll stuff fairly easily.

I just had a "the tooling is now too good for me" moment with #RustLang: browsing a small crate, I jumped from definition to definition, found the code to be too low-level to grasp immediately, looked online for references, just to find the code in a different crate. Now who copied from whom? Nobody did: `gd` just sent me to my local cache of some dependency crate :-D
Thanks

#RustLang / Cargo support in #Gentoo has received a lot of optimizations over time.
Does that sound like a good thing? I'm afraid it isn't: it's just saying how *bad* the ecosystem is, that we have to keep adding hacks to make it even remotely usable.
For a start, we immediately gave up on packaging the dependencies separately. After all, we're talking about a humongous effort, creating thousands of Gentoo packages whose only purpose would be delivering sources that would be only linked statically into executables. Lot of effort, lot of space waste, no gain. Instead, every Rust package carries a huge list of crates it needs, and a humongous Manifest listing yet another set of copies of checksums for these crates.
We are strongly relying on mirroring crates on Gentoo mirror infrastructure. Why? Because crates.io is uselessly slow. On top of that, Portage normally does fetching in series, so grabbing hundreds of crates takes half an eternity. In fact, I've even made #PyCargoEbuild use aria2 to fetch new crates from crates.io in parallel to work around this.
I have recently added a hack to unpack crates in parallel, because even unpacking all of them is awfully slow. Ironically, the crates that seem to take most of the time to unpack are these responsible for Windows support.
PyCargoEbuild also has a function to repack all dependent crates into a single tarball that we redistribute. Why? Because some packages have so many dependencies that listing them all makes ebuilds and their Manifests humongous. For every package like that, *all* Gentoo users suffer a significant growth in repository size, even if they are never going to use the package in question. So instead of listing and fetching crates, we fetch a ready-made crate tarball. Which is also much smaller than all crates combined, and therefore faster to fetch and unpack (though I haven't compared this to parallel unpacking).
Oh, perhaps I should have mentioned first that Cargo is one of the few ecosystems that simply cannot be packaged without creating dedicated tools to prepare and update the ebuilds.
But yeah, Rust is awesome.

As we all know, one of the primary purposes for #RustLang rewrites is improving security. And there is no better way to make your code secure than by not including it at all.
#Python #Gentoo

I like to minimize the size of binaries I build. Unremovable debugging strings annoyed me, so I've added an option to completely neuter `Debug::fmt` in #Rustlang
https://github.com/rust-lang/rust/pull

debug-fmt-detail option by kornelski · Pull Request #123940 · rust-lang/rust
I'd like to propose a new option that makes #[derive(Debug)] generate no-op implementations that don't print anything, and makes {:?} in format strings a no-op. There are a couple of motivations fo...

As we all know, one of the primary purposes for #RustLang rewrites is improving security. And there is no better way to make your code secure than by not including it at all.
#Python #Gentoo

I am super proud and excited to present my new website and blog! Check out "bits and beebs", where I'll publish articles about my developer and tinkerer endeavours. The first article is about diff-testing with #foundry and #RustLang

bits and beebs
Yet another personal blog about programming and technology, by Valentin Bersier

This is pretty cool. I'm calling #rustlang from #dotnet. That said, there's a lot to think about when it comes to this interop-style code, especially the memory handoff.

for #java what is the best framework to build native compiled cli applications?
micronaut, quarkus, other?
I don't have time to learn #golang or #rustlang but do want this to have a small footpr…

Meetup in London! I'll be talking about #RustLang's paradox of promising safety while allowing unsafe code.
https://innovateinteractcf.splashthat.com/

#rustlang macros are the single most unreadable syntax since Perl.

Getting out of a sidetrack activity: cbor-edn 0.0.3 published. It is both a command line tool and a #RustLang library, and interacts with #CBOR diagnostic notation from plain conversion up to processing of the upcoming application literals:
$ cargo install cbor-edn
$ echo '{4: 1234567890}'…

cbor-edn
cbor-edn

I'm happy to announce I will be speaking at #RustFestZurich this year. My talk is about Linon, a graphical #RustLang application I began writing during my MSc studies at @…

Interactive Exploration of Nonlinear Ray Casting with Rust and wgpu
Speaker: Niklas Korz Description Light is commonly assumed to travel linearly from source to destination. There are however cases where the path of light can be bent or distorted. In the case of black holes for example, the light is attracted by a very strong gravitational center. Heated air can change the direction of light through the varying refraction caused by the temperature transition from heat source to environment. Creating an interactive environment for exploration of such phenomena m…

#RustLang idzie super!
Pewnie słyszałoście, że #uv jest przyszłością instalowania paczek Pythona. Niestety, pośrednio zależny jest od crate "ring". Ring używa sporo nieprzenośnego C/asemblera, więc działa tylko na kilku architekturach (znacznie wężej niż sam Rust, a na Rusta narzekałem…).
No…

This is pretty cool. I'm calling #rustlang from #dotnet. That said, there's a lot to think about when it comes to this interop-style code, especially the memory handoff.

Blog post on writing #Valkey modules with #rustlang
https://valkey.io/blog/modules/2024/05

i can write #rustlang code on #haikuos but i miss rustup and rust analyzer

#UV is truly the future of #Python packaging.
Except that its test suite relies on specific version of random packages happening to be the newest in #PyPI (and some other random third-party package index) at any given time. Which means that the test suite already fails *a few hours* after a release.
Oh, and upstream does drive-by updates to these broken assumptions while making other changes.
So… how are we supposed to mark any version stable in #Gentoo if we can't even hope for any single version to pass tests for a few days?
Also, that test is actually meaningless now, due to test assumptions no longer matching.
#RustLang

Oh right, I wrote a new #rustlang blog post about testing.
Rust Unit and Integration Testing in #RustRover

#UV is truly the future of #Python packaging.
Except that its test suite relies on specific version of random packages happening to be the newest in #PyPI (and some other random third-party package index) at any given time. Which means that the test suite already fails *a few hours* after a release.
Oh, and upstream does drive-by updates to these broken assumptions while making other changes.
So… how are we supposed to mark any version stable in #Gentoo if we can't even hope for any single version to pass tests for a few days?
Also, that test is actually meaningless now, due to test assumptions no longer matching.
#RustLang

What’s neat about #JetBrains #Fleet is the polyglot nature of it. I'm writing a #rustlang library that I later consume in a

When someone reports a crash bug and the release fixing it only mentions "improving performance".
Well, I guess unaligned writes may degrade performance. Having #RustLang extension crash #Python ain't important after all.
#Gentoo

After waiting four years, I'd have loved to meet the #embedded #RustLang community at @… – sadly, made impossibly by circumstances beyond my control. Gladly, …

These is one of these days when it occurs to you: "hey, packages using #Python and #RustLang, may have *both* Python and Cargo-level tests." And then you spend a lot of time going over all Rust-enabled dev-python/* packages and adding `cargo_src_test` where appropriate.
As it turns out, many of them did. Most of these don't actually link to libpython, so I suppose it's fine to test them once. Pydantic-core does, so I test per-impl (but also can't test on PyPy). Cryptography has Rust-level tests that don't even build (they fail at linking).
#Gentoo

Weekend Reads
* FCC open internet order analysis #FCC #DNS #ICANN #RustLang #DDoS

Followup on `tokio-tar`. As expected, nothing happened so far.
Apparently there is also a `tokio-tar-up2date` crate which is exactly the same thing as `tokio-tar` right now. Probably it was created as a temporary hack while `tokio-tar` was unresponsive.
Then, there is a `krata-tokio-tar` crate that's more recent. However, this one really seems like fork of a fork that was created for the same of some specific project and still without any hope of long-term maintenance. I've refiled my pull request there as well.
I've also filed a bug for #UV, since using dead dependencies is not a good practice.
#RustLang #Gentoo
https://crates.io/search?q=tokio-tar
https://github.com/edera-dev/tokio-tar/pull/1
https://github.com/astral-sh/uv/issues/3423

My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
H/T @… @… @… @… @…

My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
H/T @… @… @… @… @…

You know what's great about #Python stable ABI? That you can take a binary package of, say, cryptography, and it will work on CPython 3.13, even though it's been built with older CPython version.
You know what's not so great about #PyO3? That you won't be able to build this package using Python 3.13 because it's going to reject it as "too new". Even if the package in question is only using the stable ABI compatible with CPython 3.9. Sigh.
So, of course, everything on #Gentoo will be blocked, until individual packages update their dependencies to use PyO3 new enough to support 3.13.
#RustLang

Am I missing something or is it basically impossible to have `cargo update` actually select dependencies that are acceptable for the specific minimal `rust-version`? Like, even if you install old #RustLang version, `cargo update` from this version will update `Cargo.lock` to dependencies that require a newer Rust version and render the package non-buildable?
So yeah, I suppose you either end up requiring newer Rust (but you don't really know which version, since you don't know what's the highest minimal requirement in your dependencies), or you update `Cargo.lock` by hand. Such a great tooling!
#Gentoo

Please don't use #Mercurial. It's not well-maintained software.
People like to point out that Mercurial works great for a few BigTech corporations. That's great for them. The side effect is that the development is focused on these corporations, and if you find a bug that doesn't affect them, you better be ready to provide a fix yourself.
#Python 3. The first release with Python 3 was made *two months* before Python 2 went EOL.
#RustLang. Funny thing is, Mercurial with Rust extensions enabled still doesn't work on Python 3.12. Apparently, they've chosen to use some NIH Python/Rust bridge rather than PyO3.
#Gentoo

#RustLang is doing great!
You've probably heard that #uv is the future of #Python packaging. Unfortunately, it indirectly depends on "ring" crate. Ring uses a lot of non-portable C/Assembly, effectively meaning that uv only runs on a handful of architectures (much fewer than Rust itself, and I've been complaining about Rust…).
Well, there are some good news. Rustls 0.23 no longer uses ring by default, so there's hope. But to realize that hope, first all dependency graph must switch to the new Rustls version, people need to make releases, update their locks…
Yes, it's a great design!
#Gentoo

Time for your daily dose of #RustLang complaints. Yep, the ecosystem is doing great.
#UV depends on tokio-tar library. Tokio-tar is broken on #PowerPC, doesn't have a bug tracker (!) and seems to be quite dead, with a bunch of PRs ignored since 2022 (last activity mid-2023). Nevertheless, I've filed a PR to fix PowerPC, with little hope that it'll be merged, released and that we could get UV working on PowerPC.
On top of that, it seems that tokio-tar was forked in early 2021 from async-tar. It doesn't seem to have synced the few commits from 2021, and async-tar is dead since late 2021. But at least it has a bug tracker to keep track of how dead it is.
Rewriting stuff in Rust is great. Maintaining it afterwards for the sake of reverse dependencies isn't.
#Gentoo #Python

It's been a while since I've complained about #RustLang itself, so…
Cargo insists on interacting with #git repositories. At the same time, cargo insists on vendoring an old version of #LibGit2 (1.6.2 FWICS). So, if your system is using a new git version (2.44.0), you won't be able to `cargo build`:
```
error: failed to determine package fingerprint for build script for uv v0.1.38 (/tmp/uv/crates/uv)
Caused by:
failed to determine the most recently modified file in /tmp/uv/crates/uv
Caused by:
failed to determine list of files in /tmp/uv/crates/uv
Caused by:
failed to open git index at /tmp/uv/.git/
Caused by:
invalid data in index - calculated checksum does not match expected; class=Index (10)
```
You have to clone everything with `-c index.skipHash=false` to work around this.
But yeah, I'm sure there's a great benefit to using an outdated vendored C library that NIHs git.
#Gentoo #NIH

I suppose everyone and their grandmother is now using the xz/sshd exploit to further their own agenda, so I am going to take this opportunity to further mine as well.
1. #Autotools are a bad build system. If configure scripts are completely unreadable, there should be no surprise that people won't notice obfuscated malicious code in there, provided that everything else is obfuscated by design.
2. Static linking and vendoring is bad. Do you know why the prompt #security response was possible? Because we just had to revert to older liblzma. We didn't have to check, patch and re-release hundreds of projects. It wouldn't be this easy with #RustLang and cargo.
3. You can blame #OpenSource for being underfunded and open to abuse in core system packages. However, no IT project can be resilient to a sufficiently powerful bad actor, and that it happened to xz is just an incident. Corporate projects aren't resilient to it, neither is proprietary, closed-source software.
So, embrace #Meson, embrace dynamic linking, embrace distribution packaging and donate to open source developers.
#Gentoo