The coreutils Rust rewrite story is pretty funny.
-
@ChuckMcManis I actually find questioning the why behind something to be important. In your experience at Google, did the devs rewriting things have _access_ to the documentation as to why something was done? Was it like disbelief of the stated facts or were there holes in the notetaking about the reasoning?
Two problems: that kind of documentation often does not exist, and if it does, that kind of documentation often gets ignored. "Too theoretical, not practical, etc. etc., but more often if they were self aware and being honest, it's more like 'I don't understand'"
I mean, I agree, this kind of documentation can be invaluable, if employers are willing to let (and encourage) engineers to write *and* read it. (What did you do today? Read a bunch of documentation that you barely understand? Do better tomorrow!)
Concurrency poses a real challenge, as most programmers don't even begin to comprehend the issues in play. I know I was taking graduate classes before that light bulb really turned on.
-
@q @ireneista @erincandescent @pinskia @lcamtuf we know *for sure* that browsers get involved in "emoji presentation" because we reported a bug in that area
Firefox also has a hack workaround to ignore "Segoe UI Emoji" for country flags, specifically to fix Mastodon (and some other sites of this nature which use a "OS font stack" philosophy)
@pinskia @lcamtuf @erincandescent @ireneista @r I also had to implement this for the renderer, it wasn’t too difficult. and yes, there was emoji specific code
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf I guess they all needed to be written within the same code so that rust could fail...
Truly comical...
-
@pinskia @lcamtuf @erincandescent @ireneista @r I also had to implement this for the renderer, it wasn’t too difficult. and yes, there was emoji specific code
@q @pinskia @lcamtuf @erincandescent @r sigh fontconfig, of course, says that if the user has a preference as to the rendering of emoji they should express that preference in XML
which is an interesting extreme of the individualism as a replacement for communal responsibility thing
-
@r @q @erincandescent @pinskia @lcamtuf the way that corporations would describe this need is that browsers implement their own thing because otherwise there's no way to achieve consistent behavior across OSes
our view is that this attitude, if taken seriously, will always lead to a monolith
and also it is equivalent in practical terms to not wanting to engage with OSes
@ireneista @q @erincandescent @pinskia @lcamtuf hrm, we've seen the "engage with OSes" perspective quite a bit recently, but we're personally much closer to the attitude of "OSes have dragged their feet so much that everyone making applications decided they're just not going to play that game anymore (and hence finding better and better ways to bypass the OS)"
-
@ireneista @q @erincandescent @pinskia @lcamtuf hrm, we've seen the "engage with OSes" perspective quite a bit recently, but we're personally much closer to the attitude of "OSes have dragged their feet so much that everyone making applications decided they're just not going to play that game anymore (and hence finding better and better ways to bypass the OS)"
@r @q @erincandescent @pinskia @lcamtuf here's the thing
the web platform is trying to be an OS, in every way except the kernel
or if you want more precise language, most platforms of that breadth are OSes and the web platform is the one that isn't
-
@r @q @erincandescent @pinskia @lcamtuf here's the thing
the web platform is trying to be an OS, in every way except the kernel
or if you want more precise language, most platforms of that breadth are OSes and the web platform is the one that isn't
@r @q @erincandescent @pinskia @lcamtuf the web platform's governing bodies, and the ungoverned steering that browser vendors do without engaging with the official processes, are also perfectly capable of making bad decisions, becoming frozen in time, etc
it's in a slightly more community-focused place than most OSes right now, but that doesn't make it immune to those social problems
-
@ireneista @q @erincandescent @pinskia @lcamtuf hrm, we've seen the "engage with OSes" perspective quite a bit recently, but we're personally much closer to the attitude of "OSes have dragged their feet so much that everyone making applications decided they're just not going to play that game anymore (and hence finding better and better ways to bypass the OS)"
@r @ireneista @q @pinskia @lcamtuf i think the unix desktop (collectively) has certainly dragged its feet on a lot of things just through lack of a forcing function. the only common way of doing X is often the way it was done in 1996. if you need things you couldn’t do in 1996, well…
-
@r @q @erincandescent @pinskia @lcamtuf the web platform's governing bodies, and the ungoverned steering that browser vendors do without engaging with the official processes, are also perfectly capable of making bad decisions, becoming frozen in time, etc
it's in a slightly more community-focused place than most OSes right now, but that doesn't make it immune to those social problems
@r @q @erincandescent @pinskia @lcamtuf one way or another
a platform that is worth our time personally is one that is community-driven
we have high standards for that. we do not accept governance processes that are merely for show, without true accountability. we do not accept processes that prioritize the interests of capital and states above the interests of people.
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf well at least it's larger and slower
-
@r @ireneista @q @pinskia @lcamtuf i think the unix desktop (collectively) has certainly dragged its feet on a lot of things just through lack of a forcing function. the only common way of doing X is often the way it was done in 1996. if you need things you couldn’t do in 1996, well…
@erincandescent @q @r @pinskia @lcamtuf yes, certainly. it's a different pathological niche than the web platform, but no less pathological.
-
@lcamtuf I legitimately wonder what it is about Rust that inspires people to start questionable porting projects in the first place. Like, who asked for coreutils in Rust?
@BalooUriza People who hate the GPL and wanted to get rid of it, from what I heard.
-
One thing that the Rust rewrite of coreutils tried to do was to prove that it was making steady progress by the number of test cases originating from GNU coreutils that it could pass.
I very much suspect that there's a whole host of race condition tests that made it into the test corpus late in the game.
Test-driven rewrite has its limits.
Note the uptick in failures at the very right edge of the graph, they are currently under 90% tests successful.
-
@ireneista @lcamtuf I think in this case it would've been possible to properly rewrite hem one by one, but the metric appears to be more a quantity-over-quality "lets get this out of the door quickly", i.e. the incentives weren't placed right.
@fogti @ireneista @lcamtuf but why do it at all? I'm usually among the first to advocate beating with blunt objects as punishment for using C in any serious context, but these are some of the most extensively stress-tested pieces of software known to mankind and, as the OT states, not to be expected to be plagued by hideous hidden memory bugs anyway.
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf
$ mkfafo --version -
@fogti @ireneista @lcamtuf but why do it at all? I'm usually among the first to advocate beating with blunt objects as punishment for using C in any serious context, but these are some of the most extensively stress-tested pieces of software known to mankind and, as the OT states, not to be expected to be plagued by hideous hidden memory bugs anyway.
-
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf "The original code accounted for decades of hard-learned lessons in that space."
Yeah, that was in a textbook - sorry, forget which one - I read decades ago. Not news.
(The general message as described in that sentence, not this specific case.)
-
The coreutils Rust rewrite story is pretty funny.
Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
https://seclists.org/oss-sec/2026/q2/332
PS. I'm not dunking on Rust. It's just that... starting over from scratch has its hidden costs.
@lcamtuf The Tiobe index still gives Rust very low percentages: it will take some years to rise as Java did before, or to go where Python is now. Someone ignites faster, some slower, but in the end they all live in the hope to burn C. Which doesn't take fire, and looks at all these fireballs passing.
Or maybe not, and suddenly C will disappear. I bet my five cents it won't happen in my lifetime. In any case, I voluntary plan to be cremated
And to not be listed on Tiobe index! 
