@vicgrinberg@mastodon.social Thank you for your presentation tonight at #cbaseberlin . I left feeling I have understood black holes, and knowing that I did not.
Remote
Tobias Hunger
@hunger@floss.social
mastodon 4.7.3Works on making package management easy with https://pixi.sh and lives in Berlin/Germany.
153 Followers
327 Following
20 Posts
Joined April 28, 2025
github:
pronouns:
HE/HIM
@orhun@fosstodon.org recently posted about all the tools he every showed off in the last few years, listing the top 99 here: https://blog.orhun.dev/800-rust-projects/
I took the liberty to adding all of the projects that have binary releases up on github into my conda package channel over at https://prefix.dev/github-releases so any conda user can grab them easily.
Unfortunately only 31 of those 99 have binary releases up on github.
I am trying to make it simpler for projects to publish binaries and conda packages.
Just published a blog post about a tool that imports github releases into the conda packaging eco-system.
A packaging eco-system is only good when it has all the stuff you need. Having a simple way to add binary releases made by projects on github is a win I think:-)
https://prefix.dev/blog/octoconda-repackage-github-binary-releases
It was a fun experience playing with github API, prefix.dev APIs and the many ways projects package binaries in their CI scripts.
Replying to
@lcamtuf@infosec.exchange To no surprise to anyone on earth did it not stop all possible bugs from creeping in.
But the good thing is that rust delivered what it promised: There is nothing related to memory management on the list.
Here is a look at what is in there and what is not: https://corrode.dev/blog/bugs-rust-wont-catch/
Replying to
@vicgrinberg Ich bin ein hoch privilegierter Mann und dann auch noch gross und schwer: War eine Lernerfahrung für mich. Ist mir noch nie passiert.
Ich mansplaine selber zu oft und versuche mein Hirn durch konsequentes gendern um zu programmieren, damit ich das lasse. Das war grad Antrieb, das noch konsequneter zu tun.
That crate blew my mind when I first saw it 🤯
Replying to
@jyn I am aware that most of the code produced by you people is open source. That's why I am asking: I would not have bothered elsewhere.
I hope you can find someone to sponsor this, if would be so neat.
Replying to
@jyn a very interesting read, thanks for writing it up!
Will I eventually be able to use a compiler driver like this one to make sure my uncertified (and probably uncertifiable) rust code can't panic?
Or will this stay in the certified world as a differentiator?
Replying to
Replying to
@uecker@mastodon.social @lcamtuf@infosec.exchange Who am I to judge whether or not other people's projects make sense or not?
I do find it a bit daring to adopt it this early in a distribution, but who am I to tell canonical what they should or should not do?
And who knows whether or not there are memory issues in gnu coreutils? These buggers are surprisingly good at hiding.
With a bit of luck rust will get a couple of warnings about TOCTOU issues in their linter now or a better crate for file handling.
Replying to
@uecker@mastodon.social @lcamtuf@infosec.exchange oh, I judge whether projects are fit for my use cases all the time. That is very different from judging projects.
It annoys me when I read "project X or Y is a waste of time". It obviously is not to the people that run it, its their time and they are free to do with it whatever they want.
Replying to
@uecker@mastodon.social @lcamtuf@infosec.exchange *shrug* If someone wants to rewrite something, she will do it eventually. I have seen worse excuses to rewrite stuff than to have a memory safe version of it.
Yes, you can write a memory safe programs in both C and C++, but you can't know whether you failed to do so -- till someone exploits your bug a couple years later. You will never know whether you succeeded. I find that very frustrating working with either of those languages.
Replying to
@uecker@mastodon.social @lcamtuf@infosec.exchange Plus you make it sound as if C or C++ was better than rust at handling TOCTOU and similar stuff. I'd say C is a bit behind the other two in that area.
C coreutils have only one technical argument in their favor: They are battle tested. Let's watch ubuntu go into battle with the rust coreutils and then the rust one is, too :-)
But yes, I would not use rust coreutils in production just yet myself. But I definitly will in a couple years time (if they still are a thing by then).
Replying to
@uecker@mastodon.social Canonical is a bit early, but they want as much time to test before the next LTS.
My experience replacing C and C++ tools with rust equivalents has been very positive so far (after an initial stabilization phase of course). Nothing crashes anymore. I will never go back to C-based shells.
The problem is that there is little overlap between people interested in rewriting a tool in Rust and people wanting to maintain C or C++ code. You won't convince the former to help with the latter.
Replying to
@uecker@mastodon.social Pretty normal stuff... shells and console tools:-) Yeap, many C++ tools are pretty OK. Still use lots of those, mostly on the GUI side.
Yeap. Cloudflare killed the internet using a rust program. So did log4j and heartbleed before it. At least the cloudflare bug did not leak information to attackes, it was "just" a denial of service.
Yes, Debian is pretty braindead wrt. rust.
Replying to
@uecker@mastodon.social It is always stupid errors -- in all languages.
unsafe is indeed the Achilles heel of rust. Good that you rarely need it! The one core dump I saw in a rust program was in the single unsafe line in the code -- the obvious place to look. Easiest core dump to fix in 30 years of programming.