Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notes by djb on using Fil-C

cr.yp.to

Post reply on HN
Print view View original

61–70 of 263 posts

Re: Notes by djb on using Fil-C

#61

Post by jabwd »

Slothrop99 wrote: post #4
mesrik wrote: post #3

Earlier quoted context omitted.

>Great to see some 3letter guy into this AFAIK, djb isn't for many "some 3letter guy" for over about thirty years but perhaps it's just age related issue with those less been around. https://en.wikipedia.org/wiki/Daniel_J._Bernstein

Just to be clear, I mean to venerate Bernstein for earning his 3letters, not to trivialize him.

Despite the cool shit the guy has done, keep in mind that "venerate" is not the word to use here. djb is very much not a shorthand used in any positive messaging pretty much ever by any cryptographer. He did it to himself, sadly.

Re: Notes by djb on using Fil-C

#62

Post by sibellavia »

dontlaugh wrote: post #28
jeffrallen wrote: post #8

Wish we were talking about making Fil-C required for apt, not Rust...

Fil-C is slow. There is no C or C++ memory safe compiler with acceptable performance for kernels, rendering, games, etc. For that you need Rust. The future includes Fil-C for legacy code that isn’t performance sensitive and Rust for new code that is.

How slow? In some contexts, the trade-off might be acceptable. From what I've seen in pizlonator's tweets, in some cases the difference in speed didn't seem drastic to me.

Re: Notes by djb on using Fil-C

#63

Post by conradev »

mbrock wrote: post #46
simonask wrote: post #44

Earlier quoted context omitted.

If that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally…

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?

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

Re: Notes by djb on using Fil-C

#64

Post by quotemstr »

mbrock wrote: post #35
commandersaki wrote: post #23

Earlier quoted context omitted.

I guess to get on board with this, it is my understanding you have to accept the premise of a Garbage Collector in the runtime?

Note that it is a garbage collector designed and implemented by one of the most experienced GC experts on earth. He previously designed and implemented WebKit's state of the art concurrent GC, for example. So—yes, but don't dismiss it too quickly.

It's amazing how much technical discourse revolves around impressions.

"Oh, it has a GC! GC bad!"

"No, this GC by smart guy, so good!"

"No, GC always bad!"

People aren't engaging with the technical substance. GC based systems and can be plenty good and fast. How do people think JavaScript works? And Go? It's like people just absorbed from the discursive background radiation the idea GC is slow without understanding why that might be or whether it's even true. Of course it's not.

Re: Notes by djb on using Fil-C

#65

Post by quotemstr »

I can't wait for all the delicious four-way flamewars. Choose your fighter!

1) Rewrite X in Rust

2) Recompile X using Fil-C

3) Recompile X for WASM

4) Safety is for babies

There are a lot of half baked Rust rewrites whose existence was justified on safety grounds and whose rationale is threatened now that HN has heard of Fil-C

Re: Notes by djb on using Fil-C

#66

Post by mbrock »

kragen wrote: post #58
mbrock wrote: post #36

Earlier quoted context omitted.

Look at how fanatic the compatibility actually is. Building Postgres or MySQL is conceivable but probably will require some changes. (SQLite compiles and runs with zero changes right now.)

Thanks for checking! I was wondering.

If you run Nix (whether on NixOS or elsewhere) you can do `cachix use filc` and `nix run github:mbrock/filnix#sqlite` and it should drop you into a Fil-C SQLite after downloading the runtime dependencies from my binary cache (no warranty)!

Re: Notes by djb on using Fil-C

#67

Post by kragen »

mbrock wrote: post #66
kragen wrote: post #58

Earlier quoted context omitted.

Thanks for checking! I was wondering.

If you run Nix (whether on NixOS or elsewhere) you can do `cachix use filc` and `nix run github:mbrock/filnix#sqlite` and it should drop you into a Fil-C SQLite after downloading the runtime dependencies from my binary cache (no warranty)!

Thanks!

Re: Notes by djb on using Fil-C

#68

Post by dontlaugh »

procaryote wrote: post #43
dontlaugh wrote: post #34

Earlier quoted context omitted.

Enough of it is performance sensitive that Fil-C is not an option. Fil-C is useful for the long tail of C/C++ that no one will bother to rewrite and is still usable if slow.

How is apt performance sensitive?

It parses formats and does TLS, I’m assuming it’d be quite bad. I don’t think you can mix and match.

Re: Notes by djb on using Fil-C

#69

Post by simonask »

tkz1312 wrote: post #52
simonask wrote: post #44

Earlier quoted context omitted.

If that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally…

I do not think this is niche in the slightest. I would very happily take a 2-4x slowdown for almost all of the web facing C software I run if I get guaranteed memory safety. I will be using at the very least fil-c openssh (and likely much more) on every machine I run.

Sure, that makes sense. The point I’m making is just that from an engineering perspective, that also implies that there is no longer any reason for that software you’re running to be written in C at all.

Re: Notes by djb on using Fil-C

#70

Post by mbrock »

_flux wrote: post #56
GTP wrote: post #49

Earlier quoted context omitted.

I would say that Rust would be a better choice rarher than patching memory safety on top of C. But I think the reason for this is that most, if not all, cryptographic reference implementations are in C. So they want to use existing reference implementations without having to port them to Rust. IMO cryptographers should start using Rust for their reference implementations, but I also get that they'd rather spend their…

I'm not a practioner of cryptography, but I would be wary about timing attacks that might become possible if such a dynamic runtime is introduced. At least relevant pieces of code would need to be re-evaluated in the Fil-C environment. But maybe you could use C as the "glue language" and then the build better performing libraries in Rust for C to use. Like in Python!

Good call! Fil-C does in fact have a way to let you build and run OpenSSL with its constant time crypto. I don't know how this works exactly but I guess it's relatively easy to guarantee it's safe.
Post reply on HN