5 ms·

I don't understand the need to hammer in the point that Fil-C is only valuable for this tiny, teeny, irrelevant microscopic niche, while not even talking about

by mbrock 11mo ago

I don't understand the need to hammer in the point that Fil-C is only valuable for this tiny, teeny, irrelevant microscopic niche, while not even talking about what the niche is? To be clear, the niche is rebuilding your entire GNU/Linux userland with full memory safety and completely acceptable performance, tomorrow, without rewriting anything, right? Is this such a silly little idiosyncratic hobby?

conradev 11mo ago
I am a member of this niche – thank you for the flake!! https://discourse.nixos.org/t/radically-improving-nix-nixos-security-with-fil-c/71476 https://discourse.nixos.org/t/radically-improving-nix-nixos-...
simonask 11mo ago
So I don’t want to come off as dismissive of the effort - it’s certainly impressive! The reason I’m not super excited is based on the widely publicized findings from Google and Microsoft (IIRC) about memory safety issues in their code: The vast majority is in new code. As such, the returns on running the entire userspace with Fil-C may be quite diminished from the get-go. Those who need to guard against UB bugs in seriously battle-hardened C software in production are definitely a small niche. But that doesn’t mean it isn’t also very useful as a tool during development.
- mbrock 11mo ago
  Hmm, so if they're writing new memory unsafe code in C/C++, presumably to remain within their already established and entrenched C/C++ ecosystems, why isn't Fil-C interesting as a way to thwart memory safety issues in that new code?
  - simonask 11mo ago
    Because every problem detected by Fil-C is already a serious problem in the existing code. As a mitigation strategy, that becomes less interesting as the quality of that code increases, but you still pay the full cost regardless of whether there are actually any bugs. That can certainly be valuable to you, but as a developer, the more interesting proposition is about how not to ship bugs in the first place.
    - vacuity 11mo ago
      As others have said, programs that have already been written are plainly not in the business of "not...[shipping] bugs in the first place". New code is new code; old code is old code.
- jitl 11mo ago
  It seems like there are constant updates for 20 year old packages on my Ubuntu systems. Ubuntu 20.04 Focal Fossa (first released April 2020) glibc had an update on 2025-05-28. Current stable updated glibc 2025-09-22. To say nothing about the rest of the packages in that operating system.
  - jitl 11mo ago
    Oh, look at the time, a few more CVEs in C code, posted 3 hours ago to Hacker News: "X.Org Security Advisory: multiple security issues X.Org X server and Xwayland" https://news.ycombinator.com/item?id=45790015 https://news.ycombinator.com/item?id=45790015 https://lists.x.org/archives/xorg-announce/2025-October/003635.html https://lists.x.org/archives/xorg-announce/2025-October/0036... To torture the analogy: perhaps the "returns" are diminishing, but their absolute value is still a few million bucks, I'm happy to take those returns.
- brucehoult 11mo ago
  > The reason I’m not super excited is based on the widely publicized findings from Google and Microsoft (IIRC) about memory safety issues in their code: The vast majority is in new code This makes perfect sense to me. Which is why I don't at all understand the current fetish with rewriting things that have been working well for decades in Rust. Such as coreutils. Or apt. It feels like an almost deliberate crippling of progress by diverting top talent into useless avenues, much like string theory in physics, or SLS/Artemis.
  - tempaccount420 11mo ago
    > It feels like an almost deliberate crippling of progress by diverting top talent into useless avenues, much like string theory in physics, or SLS/Artemis. You don't have to be a "top talent" to rewrite old unix utilities. The hard part is writing it safely, which in Rust can be done without "top talent."
    - brucehoult 11mo ago
      And then you end up with code 17 times slower than the C code it is replacing. When it didn't need replacing in the first place.
vorador 11mo ago
There's a contingent of rust fans that show up on every story about C – their premise is that C code is unsafe and most safety-critical C code should be rewritten in rust. Fil-C is new and is a viable competitor to rust, that's why you're hearing all asides about tiny niches, unacceptable performance degradation, etc.
- testdelacc1 11mo ago
  There’s no Rust fans here, only GC skeptics. GC skeptics existed long before anyone dreamed of Rust and will survive Rust as well. It’s a pretty reasonable objection too (though I personally don’t agree). C has always been chosen when performance is paramount. For people who prioritise performance it must feel a bit weird to leave performance on the table in this way. And Jesus Christ, give it a rest with this “Rust fans must be thinking” stuff. It sounds deranged.
  - vorador 11mo ago
    No, back in the day C was used for everything. Vim was not written in C because it needed to wring every last bit of performance out of text editing. Rewriting everything in rust "for memory-safety" is a false tradeoff given the millions of lines of C code out there and the fact that rewrites always introduce new bugs.
    - testdelacc1 11mo ago
      Please, I’m begging you, stop talking about Rust. You’re shoehorning Rust into a discussion where it hasn’t been mentioned, just to hate on some imaginary people you think are pushing Rust here. No one is talking about that. You sound deranged and obsessed. The vast majority of the conversation here is about GC and the performance implications of that. Please stick to the rest of the thread.
      - vorador 11mo ago
        [flagged]

by mbrock 11mo ago

conradev 11mo ago

I am a member of this niche – thank you for the flake!! https://discourse.nixos.org/t/radically-improving-nix-nixos-security-with-fil-c/71476 https://discourse.nixos.org/t/radically-improving-nix-nixos-...

simonask 11mo ago

So I don’t want to come off as dismissive of the effort - it’s certainly impressive! The reason I’m not super excited is based on the widely publicized findings from Google and Microsoft (IIRC) about memory safety issues in their code: The vast majority is in new code. As such, the returns on running the entire userspace with Fil-C may be quite diminished from the get-go. Those who need to guard against UB bugs in seriously battle-hardened C software in production are definitely a small niche. But that doesn’t mean it isn’t also very useful as a tool during development.

mbrock 11mo ago
Hmm, so if they're writing new memory unsafe code in C/C++, presumably to remain within their already established and entrenched C/C++ ecosystems, why isn't Fil-C interesting as a way to thwart memory safety issues in that new code?
- simonask 11mo ago
  Because every problem detected by Fil-C is already a serious problem in the existing code. As a mitigation strategy, that becomes less interesting as the quality of that code increases, but you still pay the full cost regardless of whether there are actually any bugs. That can certainly be valuable to you, but as a developer, the more interesting proposition is about how not to ship bugs in the first place.
  - vacuity 11mo ago
    As others have said, programs that have already been written are plainly not in the business of "not...[shipping] bugs in the first place". New code is new code; old code is old code.
jitl 11mo ago
It seems like there are constant updates for 20 year old packages on my Ubuntu systems. Ubuntu 20.04 Focal Fossa (first released April 2020) glibc had an update on 2025-05-28. Current stable updated glibc 2025-09-22. To say nothing about the rest of the packages in that operating system.
- jitl 11mo ago
  Oh, look at the time, a few more CVEs in C code, posted 3 hours ago to Hacker News: "X.Org Security Advisory: multiple security issues X.Org X server and Xwayland" https://news.ycombinator.com/item?id=45790015 https://news.ycombinator.com/item?id=45790015 https://lists.x.org/archives/xorg-announce/2025-October/003635.html https://lists.x.org/archives/xorg-announce/2025-October/0036... To torture the analogy: perhaps the "returns" are diminishing, but their absolute value is still a few million bucks, I'm happy to take those returns.
brucehoult 11mo ago
> The reason I’m not super excited is based on the widely publicized findings from Google and Microsoft (IIRC) about memory safety issues in their code: The vast majority is in new code This makes perfect sense to me. Which is why I don't at all understand the current fetish with rewriting things that have been working well for decades in Rust. Such as coreutils. Or apt. It feels like an almost deliberate crippling of progress by diverting top talent into useless avenues, much like string theory in physics, or SLS/Artemis.
- tempaccount420 11mo ago
  > It feels like an almost deliberate crippling of progress by diverting top talent into useless avenues, much like string theory in physics, or SLS/Artemis. You don't have to be a "top talent" to rewrite old unix utilities. The hard part is writing it safely, which in Rust can be done without "top talent."
  - brucehoult 11mo ago
    And then you end up with code 17 times slower than the C code it is replacing. When it didn't need replacing in the first place.

vorador 11mo ago

There's a contingent of rust fans that show up on every story about C – their premise is that C code is unsafe and most safety-critical C code should be rewritten in rust. Fil-C is new and is a viable competitor to rust, that's why you're hearing all asides about tiny niches, unacceptable performance degradation, etc.

testdelacc1 11mo ago
There’s no Rust fans here, only GC skeptics. GC skeptics existed long before anyone dreamed of Rust and will survive Rust as well. It’s a pretty reasonable objection too (though I personally don’t agree). C has always been chosen when performance is paramount. For people who prioritise performance it must feel a bit weird to leave performance on the table in this way. And Jesus Christ, give it a rest with this “Rust fans must be thinking” stuff. It sounds deranged.
- vorador 11mo ago
  No, back in the day C was used for everything. Vim was not written in C because it needed to wring every last bit of performance out of text editing. Rewriting everything in rust "for memory-safety" is a false tradeoff given the millions of lines of C code out there and the fact that rewrites always introduce new bugs.
  - testdelacc1 11mo ago
    Please, I’m begging you, stop talking about Rust. You’re shoehorning Rust into a discussion where it hasn’t been mentioned, just to hate on some imaginary people you think are pushing Rust here. No one is talking about that. You sound deranged and obsessed. The vast majority of the conversation here is about GC and the performance implications of that. Please stick to the rest of the thread.
    - vorador 11mo ago
      [flagged]