Fabio Valentini

Rustacean 🦀 with a Computer Science degree 🎓

I write Rust and Python, and maintain lots of RPM packages for Fedora Linux. Fedora Engineering Steering Committee (FESCo) and Packaging Committee (FPC) member. AI Luddite.

Fluent in English and German. He/Him. 🏳️‍🌈🇦🇹🇪🇺

Website: https://decathorpe.dev
Codeberg: https://codeberg.org/decathorpe
GitHub: https://github.com/decathorpe
Instagram: https://instagram.com/decathorpe

Public Key

npub154ch8wd5pln4drhvxjgjht4mjjnjcrg8ejgz7dsl36r8656mg6jstj494f

NIP-05 Address

[email protected]

Profile Code

nprofile1qqs22utnhx6qle6k3mkrfyft46aeffevp5rueyp0xc0capna2dd5dfgprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmntqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hs0fzq9w

Publishing to

relay.momostr.pink

relay.damus.io

offchain.pub

Author Public Key

npub154ch8wd5pln4drhvxjgjht4mjjnjcrg8ejgz7dsl36r8656mg6jstj494f

Show more details

Last Notes

2025-12-27 16:10:39 GMT

- reply

that would be https://git.deuxfleurs.fr/Deuxfleurs/garage ?
doesn't look too horrible, I can take a stab at it tomorrow.

2025-12-27 15:57:38 GMT

- reply

static linking is fine and there's no way around it with languages like Rust and Go. what you're thinking of is bundling all your dependencies, and even that is allowed if necessary and if you do it correctly.
the problem isn't getting packages with vendored deps working (that's quite easy), the problem is all the auditing and integration work that you'd need to do for separately packages libraries anyway.

2025-12-11 23:05:42 GMT

- reply

no, I install the full driver version (from a source that does not have to care about software patents) 🤷🏻‍♂️

2025-12-11 22:54:14 GMT

- reply

personally, I have not seen any impact on the distribution itself, so I don't see a reason to move away from it (yet).
not sure what codec drama you're talking about?

2025-12-11 21:22:55 GMT

- reply

speaking as a long term Fedora contributor and FESCo member, I can only agree with 🤮
the way "AI" stuff is getting shoehorned into everything is starting to make me really quite angry

2025-12-07 10:38:26 GMT

- reply

in my mind the notion that you need to "earn" things like being able to eat and have shelter is just inherently anti-human - and also the start of a slippery slope from just being a "liberal" into actual right-wing extremism
the cognitive leaps between ideas like "work requirement" to "you just don't deserve the same rights" to "slavery actually not that bad" to "I heart camps and deportations" aren't *that* big and it's wild seeing "liberals" on live TV leapfrogging them with glee

2025-04-30 09:01:20 GMT

- reply

do you really need to deal with dynamically typed values at runtime? :(

2025-04-29 10:38:29 GMT

- reply

I found dealing with JSON very very nice in Rust, so I wonder what you're doing 😅 are you not using serde+derive/serde_json?

2025-02-01 18:27:50 GMT

- reply

well ... what *is* the error? 😅

2025-02-01 18:01:01 GMT

- reply

I'd check if the .desktop file does something weird

2024-12-03 17:11:18 GMT

dxr 0.7.0 is out! 🎉
it's a framework for writing #XMLRPC clients and servers in #Rust, with a modern, ergonomic, and type-safe API - for those of us who still need to Interface with "legacy" systems but don't want to be stuck using "legacy" programming languages too :emoji_wink:
release notes: https://github.com/ironthree/dxr/releases/tag/0.7.0

2024-10-02 23:16:58 GMT

- reply

ohhhh .... I didn't know that it was *that* easy to do this, and that the interface was so simple. 🙏🏼

2024-09-11 22:01:04 GMT

- reply

(and I have the suspicion that your one look into Rust stack, which admittedly was a single-function library, wasn't helpful with getting an actual good overview of what the Rust stack in Fedora looks like, and you probably shouldn't base your opinions on that one first look alone)

2024-09-11 21:58:40 GMT

- reply

I don't think it will get *that* bad.
and I have at least *some* data to back that up. the number of Rust packages in Fedora had remained stable for years (at ~2200), and has just grown to ~3200 over the past year or two - but with *a lot* more Rust-written applications being available now.
and a good part of that growth is not actually more crates, but alternative versions of existing ones (I plan to spend more time on getting rid of those again in the future)

2024-09-11 11:31:56 GMT

- reply

well ... yes, but also no.
the Rust standard library used to be bigger before 1.0.0 was released. but they ripped everything out for which they didn't want to commit to stability guarantees
but after 1.0, std has been getting *bigger* again with every release. just because no HTTP stack is included doesn't mean the standard library is "useless"

2024-09-07 05:59:05 GMT

- reply

I see you've been looking at what I've been doing yesterday? 😅
And I agree that more basic functionality should be part of the standard library ... is_executable could just as well be a method on std::fs::Path.

2024-08-23 20:30:40 GMT

- reply

I'm curious - have all previous contributors signed off on the license change? or is it going to be "GPL 3.0 for new contributions but old code remains MIT licensed"? (the linked commit makes it look like MIT is just gone though)

2024-06-13 22:15:26 GMT

- reply

It usually doesn't (the "major" version getting big, that is).
The thing that *does* matter is the frequency of breaking changes - and if a project releases breaking changes every 2 months (be it pre-1.0 or post-1.0), that's not a good sign in my experience ...
So when I see a library that's only 2 years old and already at version 12.0.0, I'm just a little suspicious.

2024-06-13 15:14:29 GMT

- reply

I'm starting to think were talking about different things here.
Or maybe I just don't understand the "sentimentality" associated with pre-1.0 vs. post-1.0 releases.

2024-06-13 14:36:51 GMT

- reply

Do you know that the guarantees provided by semver as implemented in cargo are stronger than those by "plain" semver?
For example, 0.2.x and 0.2.y (where y > x) are supposed to be API compatible, even though they're pre-1.0. This guarantee is not present in plain semver.
The only "burden" usually associated with 1.0 is that projects want to settle on a stable API *before* tagging 1.0 to avoid s ballooning number of post-1.0 major releases.

2024-06-13 08:10:15 GMT

- reply

I hope so ...
at least for some of the projects on the 0ver list, they are relatively new and stay on 0.x intentionally to mark that their API or CLI is not stable yet (like ruff)
releasing a 1.0.0 has a pretty high bar attached to it, especially in the Rust ecosystem. it might be *too* high, but I don't think it's a negative per se that some projects want to hone in on a stable API *before* they release 1.0 ...