Wish we were talking about making Fil-C required for apt, not Rust...
doesnt it only work on x86_64?
Notes by djb on using Fil-C
31–40 of 263 posts
Re: Notes by djb on using Fil-C
#32Wish 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.
What does that have to do with apt?
Re: Notes by djb on using Fil-C
#33Earlier quoted context omitted.
Those seems to be independent issues. Fil-C is about the best way to compile/run C code. Rust would be about what language to use for new code. Now that I have been programming in Rust for a couple of years, I don't want to go back to C (except for some hobby projects).
I agree. The main advantage of Fil-C is compatibility with C, in a secure way. The disadvantages are speed, and garbage collection. (Even thought, I read that garbage collection might not be needed in some cases; I would be very interested in knowing more details). For new code, I would not use Fil-C. For kernel and low-level tools, other languages seem better. Right now, Rust is the only popular language in this spa…
> disadvantages are speed, and garbage collection.
And size. About 10x increase both on disk and in memory
$ stat -c '%s %n' {/opt/fil,}/bin/bash
15299472 /opt/fil/bin/bash
1446024 /bin/bash
$ ps -eo rss,cmd | grep /bash
34772 /opt/fil/bin/bash
4256 /bin/bashRe: Notes by djb on using Fil-C
#34Earlier quoted context omitted.
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.
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.
Re: Notes by djb on using Fil-C
#35For those, like me, that didn’t know what Fil-C is: > Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics. Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (InvisiCaps). Every possibly-unsafe C and C++ operation is che…
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.
Re: Notes by djb on using Fil-C
#36Building 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.)
Re: Notes by djb on using Fil-C
#37Earlier quoted context omitted.
It is definitely not fine. The argument seems to be that since you need to trust somebody, curl | bash is fine because you just trust whoever controls the webserver. I think this is missing the point.
It's missing which point?
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, independently verify fingerprints of the installation media, and then only install packages from the curated a list of packages. A lot of effort went into making this safe and close the remaining issues.
Re: Notes by djb on using Fil-C
#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 restarts needed.
Yikes that’s a lot of memory! Filc is doing a lot of static analysis apparently.
Re: Notes by djb on using Fil-C
#39Earlier quoted context omitted.
It's missing which point?
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.
Re: Notes by djb on using Fil-C
#40Earlier quoted context omitted.
It is definitely not fine. The argument seems to be that since you need to trust somebody, curl | bash is fine because you just trust whoever controls the webserver. I think this is missing the point.
s/webserver/DNS/
HTTPS is there, so you go down to that level only if you want to distrust any element of the public key infrastructure. Which, to be fair, there are plenty of reasons if you are paranoid -- they do tell you who's doing what in a shady way as they revoke, so there's a huge list of transgressions.