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

51–60 of 263 posts

Re: Notes by djb on using Fil-C

#51

Post by uecker »

IshKebab wrote: post #48
uecker wrote: post #42

Earlier quoted context omitted.

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.

Downloading a deb via a package manager is more secure. Downloading a deb, comparing the hash (or at least noting down the hash) would also already be more secure.

But yes, that the run arbitrary scripts is also a known issue, but this is not the main point as most code you download will be run at some point (and ideally this needs sandboxing of applications to fix).

Re: Notes by djb on using Fil-C

#52

Post by tkz1312 »

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 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.

Re: Notes by djb on using Fil-C

#53

Post by mbrock »

le-mark wrote: post #38

> I had originally configured the server phoenix with only 12GB swap. I then had to restart ./build_all_fast_glibc.sh a few times because the Fil-C compilation ran out of memory. Switching to 36GB swap made everything work with no restarts; monitoring showed that almost 19GB swap (plus 12GB RAM) was used at one point. A larger server, 128 cores with 512GB RAM, took 8 minutes for Fil-C plus 6 minutes for musl, with no…

I think that's the build of LLVM+Clang itself.

Re: Notes by djb on using Fil-C

#54

Post by [deleted] »

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.

[deleted]

Re: Notes by djb on using Fil-C

#55

Post by [deleted] »

uecker wrote: post #51
IshKebab wrote: post #48

Earlier quoted context omitted.

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

Downloading a deb via a package manager is more secure. Downloading a deb, comparing the hash (or at least noting down the hash) would also already be more secure. But yes, that the run arbitrary scripts is also a known issue, but this is not the main point as most code you download will be run at some point (and ideally this needs sandboxing of applications to fix).

[deleted]

Re: Notes by djb on using Fil-C

#56

Post by _flux »

GTP wrote: post #49
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 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!

Re: Notes by djb on using Fil-C

#57

Post by kragen »

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 think Fil-C is for people who are using software that has already been written, not for people who are trying to pick what language to write new software in. A substantial amount of software has, after all, already been written.

Re: Notes by djb on using Fil-C

#58

Post by kragen »

mbrock wrote: post #36
nitinreddy88 wrote: post #21

Building tools is one thing, building a system like Postgres or Databases is going to be another thing. Anyone really tried building PG or MySQL or such a complex system which heavily relies on IO operations and multi threading capabilities

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.

Re: Notes by djb on using Fil-C

#59

Post by kragen »

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?

Apt has been painfully slow since I started using Debian last millennium, but I suspect it's not because it uses a lot of CPU, or it would be snappy by now.

Re: Notes by djb on using Fil-C

#60

Post by IshKebab »

uecker wrote: post #51
IshKebab wrote: post #48

Earlier quoted context omitted.

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

Downloading a deb via a package manager is more secure. Downloading a deb, comparing the hash (or at least noting down the hash) would also already be more secure. But yes, that the run arbitrary scripts is also a known issue, but this is not the main point as most code you download will be run at some point (and ideally this needs sandboxing of applications to fix).

> Downloading a deb via a package manager is more secure.

Not what I meant. Getting software into 5 different distros and waiting years for it to be available to users is not really viable for most software authors.

Post reply on HN