The coreutils Rust rewrite story is pretty funny.
-
@Doomed_Daniel@mastodon.gamedev.place @ireneista@irenes.space @lcamtuf@infosec.exchange @puppygirlhornypost2@transfem.social I’m just saying that slim POSIX implementations that prioritize small size aren’t the best references for a clean-room GNU coreutil rewrite. FreeBSD utils and GNU documentation would be better.
Given the different language, I’m not sure that lightly referencing the GNU source code would even pose a legal risk.
@Seirdy@pleroma.envs.net @lcamtuf@infosec.exchange @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space Also, BSD-Clause and MIT are compatible licenses. IANAL though, so I'm hesitant to discuss how this would actually impact "porting" BSD-Clause code from C to an MIT Licensed Rust codebase
-
@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. -
@lcamtuf@infosec.exchange @Seirdy@pleroma.envs.net @Doomed_Daniel@mastodon.gamedev.place @ireneista@adhd.irenes.space i find it annoying because on GNU coreutil systems i am so used to being able to just append whatever flag i forgot to put in the front and then it's like
nah@puppygirlhornypost2 @ireneista People talking about UX are often talking about GUIs but aside from GNU making clean copyleft license versions of the (at the time) proprietary Unix utils, GNU also spent a lot of effort in UX like long options and fewer arbitrary restrictions (which made sense on a PDP but not on the larger systems of the 90's and later) which is how they got to be so popular, before Linux was even created. It's too bad that some of the other systems keep looking back farther for inspiration rather than looking around and forward for what the UX of a Unix should be.
-
@puppygirlhornypost2 @ireneista People talking about UX are often talking about GUIs but aside from GNU making clean copyleft license versions of the (at the time) proprietary Unix utils, GNU also spent a lot of effort in UX like long options and fewer arbitrary restrictions (which made sense on a PDP but not on the larger systems of the 90's and later) which is how they got to be so popular, before Linux was even created. It's too bad that some of the other systems keep looking back farther for inspiration rather than looking around and forward for what the UX of a Unix should be.
@raven667 @puppygirlhornypost2 they did, yeah, you're right. they deserve credit for that work.
they did so in a time when UX wasn't yet a science (or rather, design was a science but had not been made rigorous in the domain of computing), so perhaps it's understandable that they still have a ton of UX problems... but you're right. still way better than earlier attempts.
-
@lcamtuf
I learned C++ after Modula-2 and before C.
I learned programming earlier.Learning a programming language isn't learning programming (extracting requirements, specification, design, coding, test etc).
I looked at Rust. C++ certainly has got too complicated since 1987, but I wonder does Rust *only* help with memory safety?
Main memory safety in general relates to using pointers that are invalid, accessing arrays out of bounds and past the end of strings.
Partly bad libraries & design.@raymaccarthy @lcamtuf Rust seems to in-practice accomplish very little Ada doesn't do better. -
@ChuckMcManis @lcamtuf now why the hell, after all these years, have I not heard of Chesterton’s Fence? Is this what I missed by not learning my trade at a uni? Kinda rhetorical, but I _still_ feel I must’ve missed something other than the debt…
Anyway, thank you. It’s going to provide a nice two-worder when reviewing prs by newbies - and a lot of oldbies and, lest l forget, their sloppy chums.
@Kynx @ChuckMcManis @lcamtuf I don't get the big deal about Chesterton's Fence and think it's probably safe to remove it from our lexicon tbh
-
@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.
