3 ms·

They're not going to mention a single-person experimental project that has 900 stars on GitHub. This is meant to be a practical strategy that can be implemente

by pornel 1y ago

They're not going to mention a single-person experimental project that has 900 stars on GitHub. This is meant to be a practical strategy that can be implemented nation-wide, without turning into another https://xkcd.com/2347 https://xkcd.com/2347

pizlonator 1y ago
> They're not going to mention a single-person experimental project that has 900 stars on GitHub. Seems like a bad way to pick technology. They do mention things like TRACTOR. Fil-C is far ahead of any project under the TRACTOR umbrella. > This is meant to be a practical strategy that can be implemented nation-wide, without turning into another https://xkcd.com/2347 https://xkcd.com/2347 The solution to that is funding the thing that is essential, rather than complaining that an essential thing is unfunded. DOD could do that
- safercplusplus 1y ago
  Preach it brother! :) Hmm, I take it that the situation is that there are a number of vendors/providers/distros/repos who could be distributing your memory-safe builds, but are currently still distributing unsafe builds? I wonder if an organization like the Tor project [1] would be more motivated to "officially" distribute a Fil-C build, being that security is the whole point of their product. (I'm talking just their "onion router" [2], not (necessarily) the whole browser.) I could imagine that once some organizations start officially shipping Fil-C builds, adoption might accelerate. Also, have you talked to the Ladybird browser people? They seemed to be taking an interested in Fil-C. [1] https://www.torproject.org/ https://www.torproject.org/ [2] https://gitlab.torproject.org/tpo/core/tor https://gitlab.torproject.org/tpo/core/tor
  - pornel 1y ago
    Tor wants to move to Rust, and they aren't happy with their C codebase. They want to expand use of multi-threading, and C has been too fragile for that. https://blog.torproject.org/announcing-arti/ https://blog.torproject.org/announcing-arti/
    - safercplusplus 1y ago
      Makes sense. But maybe the fact that that post is 4 years old serves to bolster the argument for Fil-C's value proposition. However much people may want to move away from their C code bases, the resources it takes to do so in a timely manner are often not so readily available.
- pornel 1y ago
  > Seems like a bad way to pick technology. This is a very sensible way to pick a technology for a government. Having a cool proof of concept, with a bus factor of 1, and having a solution that countless government agencies can depend on for multi-million-dollar decades-long software projects are very different things. They can't just depend out of the blue on you personally maintaining "Fil's Unbelievable Garbage Collector" for the lifetime of the government's projects. Maybe you believe they could, but it takes way more legwork to give such assurance to a government. They list TRACTOR under projects they've already funded (and crucially, not among solutions they recommend yet). Apply for funding for Fil-C, and if it gets accepted, it'll probably get listed there too. The TRACTOR approach also has higher tolerance to being an experimental project, because it's one-time conversion of C to Rust. It only needs to work once, not continuously for decades. The Rust-lang org is set up to offer serious long-term support, and is way past having a critical dependency on a single developer.
  - pizlonator 1y ago
    > This is a very sensible way to pick a technology for a government. No, it's not, for the simple reason that the government has more than adequate resources to recreate a Fil-C-like with a team, or even just add people power to Fil-C. The fact that it only took one dude working in his spare time 1.5 years to make C memory safe suggests that the whole narrative of the OP is wrong. The problem isn't that people aren't using memory safe languages. The problem is that nobody is funding just making C memory safe.
    - pornel 1y ago
      You've made a language that is at least 20-50% slower than C and has a garbage collector. That's not what people use C for. You're presenting it as a memory-safe C, but you've got a more fine-grained ASAN. That's useful, but it's not blowing away the whole narrative. For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks. For new development, where a slower GC language is suitable, there are plenty of languages to choose from that are more convenient and less crash-prone. There's already CHERI that takes a similar approach to pointer tagging, but they're doing it in hardware, because they know that software emulation makes the solution unappealing.

by pornel 1y ago

pizlonator 1y ago

> They're not going to mention a single-person experimental project that has 900 stars on GitHub. Seems like a bad way to pick technology. They do mention things like TRACTOR. Fil-C is far ahead of any project under the TRACTOR umbrella. > This is meant to be a practical strategy that can be implemented nation-wide, without turning into another https://xkcd.com/2347 https://xkcd.com/2347 The solution to that is funding the thing that is essential, rather than complaining that an essential thing is unfunded. DOD could do that

safercplusplus 1y ago
Preach it brother! :) Hmm, I take it that the situation is that there are a number of vendors/providers/distros/repos who could be distributing your memory-safe builds, but are currently still distributing unsafe builds? I wonder if an organization like the Tor project [1] would be more motivated to "officially" distribute a Fil-C build, being that security is the whole point of their product. (I'm talking just their "onion router" [2], not (necessarily) the whole browser.) I could imagine that once some organizations start officially shipping Fil-C builds, adoption might accelerate. Also, have you talked to the Ladybird browser people? They seemed to be taking an interested in Fil-C. [1] https://www.torproject.org/ https://www.torproject.org/ [2] https://gitlab.torproject.org/tpo/core/tor https://gitlab.torproject.org/tpo/core/tor
- pornel 1y ago
  Tor wants to move to Rust, and they aren't happy with their C codebase. They want to expand use of multi-threading, and C has been too fragile for that. https://blog.torproject.org/announcing-arti/ https://blog.torproject.org/announcing-arti/
  - safercplusplus 1y ago
    Makes sense. But maybe the fact that that post is 4 years old serves to bolster the argument for Fil-C's value proposition. However much people may want to move away from their C code bases, the resources it takes to do so in a timely manner are often not so readily available.
pornel 1y ago
> Seems like a bad way to pick technology. This is a very sensible way to pick a technology for a government. Having a cool proof of concept, with a bus factor of 1, and having a solution that countless government agencies can depend on for multi-million-dollar decades-long software projects are very different things. They can't just depend out of the blue on you personally maintaining "Fil's Unbelievable Garbage Collector" for the lifetime of the government's projects. Maybe you believe they could, but it takes way more legwork to give such assurance to a government. They list TRACTOR under projects they've already funded (and crucially, not among solutions they recommend yet). Apply for funding for Fil-C, and if it gets accepted, it'll probably get listed there too. The TRACTOR approach also has higher tolerance to being an experimental project, because it's one-time conversion of C to Rust. It only needs to work once, not continuously for decades. The Rust-lang org is set up to offer serious long-term support, and is way past having a critical dependency on a single developer.
- pizlonator 1y ago
  > This is a very sensible way to pick a technology for a government. No, it's not, for the simple reason that the government has more than adequate resources to recreate a Fil-C-like with a team, or even just add people power to Fil-C. The fact that it only took one dude working in his spare time 1.5 years to make C memory safe suggests that the whole narrative of the OP is wrong. The problem isn't that people aren't using memory safe languages. The problem is that nobody is funding just making C memory safe.
  - pornel 1y ago
    You've made a language that is at least 20-50% slower than C and has a garbage collector. That's not what people use C for. You're presenting it as a memory-safe C, but you've got a more fine-grained ASAN. That's useful, but it's not blowing away the whole narrative. For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks. For new development, where a slower GC language is suitable, there are plenty of languages to choose from that are more convenient and less crash-prone. There's already CHERI that takes a similar approach to pointer tagging, but they're doing it in hardware, because they know that software emulation makes the solution unappealing.