The coreutils Rust rewrite story is pretty funny.
-
@xerz @star @hypha @lcamtuf Switching to dependencies with a single non-replaceable toolchain is also irresponsible.
Core utilities should not rely on something that can believably be slopped into oblivion with no viable replacement (C compilers are a dime a dozen and comparatively much easier to implement, with many functional replacements readily available).
Proper specification of all the core toolchains should be a bare minimum.@lispi314 @hypha @star @lcamtuf in fairness GNU has a viable alternative,
gccrsis aiming for Rust 1.49 and is getting quite close https://rust-gcc.github.io/2026/04/13/2026-03-monthly-report.html.....not sure what compiler version
uutilsrequires tho -
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 We clearly need a type system capable of expressing TOCTOU-safety.
-
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.
-
@lispi314 @hypha @star @lcamtuf in fairness GNU has a viable alternative,
gccrsis aiming for Rust 1.49 and is getting quite close https://rust-gcc.github.io/2026/04/13/2026-03-monthly-report.html.....not sure what compiler version
uutilsrequires tho@xerz@soc.masfloss.net @hypha@cafe.mycelium.locahlo.st @star@fed.amazonawaws.com @lcamtuf@infosec.exchange Last I had heard from gccrust is that it couldn’t even be used for bootstrap compiling yet, without enforcing any of the semantics a Rust compiler is expected to.
It’s unclear whether it also now does that as of this progress report or not. If it does then that would be progress indeed.
-
@r @ireneista @pinskia @lcamtuf any widget toolkit they have is heavily entangled with the HTML renderer, and the advanced typography is stuff like HarfBuzz
-
"Netscape went bankrupt trying to re-write their software from scratch"
It is also why Microsoft Edge went from something written from scratch to be a fork of chromium. The story is the same and even more it is about the similar product. Plus it is a recent example of the whole starting from scratch issues.
@pinskia@hachyderm.io @ireneista@adhd.irenes.space @lcamtuf@infosec.exchange They also just didn’t really have a reason to care about writing their own browser much either. I think their main revenue streams had diverged from that already.
-
@raymaccarthy @lcamtuf Rust seems to in-practice accomplish very little Ada doesn't do better.
@lispi314 @lcamtuf
C++ programmers are not going to use Ada or Modula-3.
Ada or any version of Modula / Oberon would be totally anathema to C programmers.Rust is better than C and maybe has some advantages over C++, and that's the market it's aimed at. The selling point is that it's C like, with classes, types and "Memory Safe". And turning off the Memory safe.
-
@darkuncle @ChuckMcManis @lcamtuf Sure, but perhaps don't do your learning in production?
@sten @darkuncle @ChuckMcManis @lcamtuf Got to get the company investing in the continuous training of their workers somehow, right? -
@r @ireneista @pinskia @lcamtuf any widget toolkit they have is heavily entangled with the HTML renderer, and the advanced typography is stuff like HarfBuzz
@r @ireneista @erincandescent @pinskia @lcamtuf HarfBuzz is perfectly usable on its own. It only took me a week of hair pulling to get it into an Metal renderer for Eurovision; even had proper RTL/LTR mixing and Emoji support
-
@r @ireneista @erincandescent @pinskia @lcamtuf HarfBuzz is perfectly usable on its own. It only took me a week of hair pulling to get it into an Metal renderer for Eurovision; even had proper RTL/LTR mixing and Emoji support
@q @ireneista @erincandescent @pinskia @lcamtuf we were under the impression that browsers had additional "miscellaneous bullshit" such as font fallback selection and "OS-specific quirks" (we're not sure what if anything that actually refers to)
-
@q @ireneista @erincandescent @pinskia @lcamtuf we were under the impression that browsers had additional "miscellaneous bullshit" such as font fallback selection and "OS-specific quirks" (we're not sure what if anything that actually refers to)
@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)
-
@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)
@r @q @erincandescent @pinskia @lcamtuf yes browsers implement their own font fallback logic which is a duplicate of what OS core libraries and fontconfig do, just slightly different. they implement their own so as to not have to engage with OSes.
-
@r @q @erincandescent @pinskia @lcamtuf yes browsers implement their own font fallback logic which is a duplicate of what OS core libraries and fontconfig do, just slightly different. they implement their own so as to not have to engage with OSes.
@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
-
@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
