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

41–50 of 263 posts

Re: Notes by djb on using Fil-C

#41

Post by arthur2e5 »

oddmiral wrote: post #26
jeffrallen wrote: post #8

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

I wish, we will have something like Fil-C as an option for unsafe Rust.

Fil-C works because you recompile the whole C userspace. Unsafe Rust doesn't do that... and for many practical purposes you probably want to touch the non-safe-version of the C userspace.

Still, it's all LLVM, so perhaps unsafe Rust for Fil-space can be a thing, a useful one for catching (what would be) UBs even [Fil-C defines everything, so no UBs, but I'm assuming you want to eventually run it outside of Fil-space].

Now I actually wonder if Fil-C has an escape hatch somewhere for syscalls that it does not understand etc. Well it doesn't do inline assembly, so I shouldn't expect much... I wonder how far one needs to extend the asm clobber syntax for it to remotely come close to working.

Re: Notes by djb on using Fil-C

#42

Post by uecker »

IshKebab wrote: post #39
uecker wrote: post #37

Earlier quoted context omitted.

That you should be very careful about what you install. Cut&pasting some line from a website is the exact opposite of it. This is mostly about psychology and not technology. But there are also other issues with this, e.g. many independent failure points at different levels, no transparency, no audit chain, etc. The counter model we tried to teach people in the past is that people select a linux distribution, independ…

None of that has anything to do with curl|bash. Be careful who you trust when installing software is a fine thing to teach. But that doesn't mean the only people you can trust are Linux distro packagers.

I think it has a lot to do with "curl|bash". Cut&paste a curl|bash command-line disables all inherent mechanisms and stumbling blocks that would ensure properly ensuring trust. It was basically invented to make it easy to install software by circumventing all protection a Linux distribution would traditionally provide. It also eliminates all possibility for independent verification about what was installed or done on the machine.

Re: Notes by djb on using Fil-C

#43

Post by procaryote »

dontlaugh wrote: post #34
mbrock wrote: post #32

Earlier quoted context omitted.

What does that have to do with apt?

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?

Re: Notes by djb on using Fil-C

#44

Post by simonask »

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.

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 needs to be at least 2-4x the actual working set of your program for GCs to be efficient. That's fine for a lot of use cases, especially when RAM isn't scarce.

Most people who use C or C++ or Rust have already made this calculation and deemed the cost to be something they don't want to take on.

That's not to say Fil-C isn't impressive, but it fills a very particular niche. In short, if you're bothering with a GC anyway, why wouldn't you also choose a better language than C or C++?

Re: Notes by djb on using Fil-C

#45

Post by simonask »

oddmiral wrote: post #26
jeffrallen wrote: post #8

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

I wish, we will have something like Fil-C as an option for unsafe Rust.

Unsafe Rust actually has a great runtime analyzer: Miri. It's very easy to just run `cargo +nightly miri test` in your project to get some confidence in the more questionable choices along the way.

Re: Notes by djb on using Fil-C

#46

Post by mbrock »

simonask wrote: post #44
mbrock wrote: post #35

Earlier quoted context omitted.

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.

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?

Re: Notes by djb on using Fil-C

#47

Post by HL33tibCe7 »

simonask wrote: post #44
mbrock wrote: post #35

Earlier quoted context omitted.

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.

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…

The value prop here is for existing projects in C or C++, as is made abundantly clear in the linked article

Re: Notes by djb on using Fil-C

#48

Post by IshKebab »

uecker wrote: post #42
IshKebab wrote: post #39

Earlier quoted context omitted.

None of that has anything to do with curl|bash. Be careful who you trust when installing software is a fine thing to teach. But that doesn't mean the only people you can trust are Linux distro packagers.

I think it has a lot to do with "curl|bash". Cut&paste a curl|bash command-line disables all inherent mechanisms and stumbling blocks that would ensure properly ensuring trust. It was basically invented to make it easy to install software by circumventing all protection a Linux distribution would traditionally provide. It also eliminates all possibility for independent verification about what was installed or done on…

Downloading and installing a `.deb` or `.rpm` is going to be no more secure. They can run arbitrary scripts too.

Re: Notes by djb on using Fil-C

#49

Post by GTP »

simonask wrote: post #44
mbrock wrote: post #35

Earlier quoted context omitted.

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.

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 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 time working on their next paper rather than learning a new language.

Re: Notes by djb on using Fil-C

#50

Post by i80and »

simonask wrote: post #44
mbrock wrote: post #35

Earlier quoted context omitted.

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.

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…

The user of the code may plausibly want to make a different tradeoff than the author, without wanting to rewrite the project from scratch.
Post reply on HN