4 ms·

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

phicoh 1y ago
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).
- thomasmg 1y ago
  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 space that doesn't have these disadvantages. But in my view, Rust also has issues, specially the borrow checker, and code verbosity. Maybe in the future there will be a language that resolves these issues as well (as a hobby, I'm trying to build such a language). But right now, Rust seems to be the best choice for the kernel (for code that needs to be fast and secure).
  - kees99 1y ago
    > 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/bash
    - nialse 1y ago
      How does that compare with rust? You don't happen to have an example of a binary underway moving to rust in Ubuntu-land as well? Curious to see as I honestly don't know whether rust is nimble like C or not.
      - vacuity 1y ago
        I don't have numbers, but Rust is also terrible for binary size. Large Rust binaries can be improved with various efforts, but it's not friendly by default. Rust focuses on runtime performance, high-level programming, and compile-time guarantees, but compile times and binary sizes are the drawback. Notably, Rust prefers static linking.
      - kees99 1y ago
        My impression is - rust fares a bit better on RAM footprint, and about as badly on disk binary size. It's darn hard to compare apples-to-apples, though - given it's a different language, so everything is a rewrite. One example: Ubuntu 25.10's rust "coreutils" multicall binary: 10828088 bytes on disk, 7396 KB in RAM while doing "sleep". Alpine 3.22's GNU "coreutils" multicall binary: 1057280 bytes on disk, 2320 KB in RAM while doing "sleep".
oddmiral 1y ago
I wish, we will have something like Fil-C as an option for unsafe Rust.
- arthur2e5 1y ago
  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.
  - jitl 1y ago
    at the bottom of the turtle stack, there's a yolo-c libc that does some syscall stuff: > libyoloc.so. This is a mostly unmodified [musl/glibc] libc, compiled with Yolo-C. The only changes are to expose some libc internal functionality that is useful for implementing libpizlo.so. Note that libpizlo.so only relies on this library for system calls and a few low level functions. In the future, it's possible that the Fil-C runtime would not have a libc in Yolo Land, but instead libpizlo.so would make syscalls directly. but mostly you are using a fil-c compiled libc: > libc.so. This is a modified musl libc compiled with Fil-C. Most of the modifications are about replacing inline assembly for system calls with calls to libpizlo.so's syscall API. That links here: https://github.com/pizlonator/fil-c/blob/deluge/filc/include/pizlonated_syscalls.h https://github.com/pizlonator/fil-c/blob/deluge/filc/include... Quotes from: https://fil-c.org/runtime https://fil-c.org/runtime
- simonask 1y ago
  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.
dontlaugh 1y ago
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.
- mbrock 1y ago
  What does that have to do with apt?
  - dontlaugh 1y ago
    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.
    - procaryote 1y ago
      How is apt performance sensitive?
      - kragen 1y ago
        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.
      - dontlaugh 1y ago
        It parses formats and does TLS, I’m assuming it’d be quite bad. I don’t think you can mix and match.
        jitl 1y ago
        stuff that talks to "the internet" and runs as "root" seems like a good thing to build with filc.
lucyjojo 1y ago
doesnt it only work on x86_64?

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

thomasmg 1y ago
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 space that doesn't have these disadvantages. But in my view, Rust also has issues, specially the borrow checker, and code verbosity. Maybe in the future there will be a language that resolves these issues as well (as a hobby, I'm trying to build such a language). But right now, Rust seems to be the best choice for the kernel (for code that needs to be fast and secure).
- kees99 1y ago
  > 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/bash
  - nialse 1y ago
    How does that compare with rust? You don't happen to have an example of a binary underway moving to rust in Ubuntu-land as well? Curious to see as I honestly don't know whether rust is nimble like C or not.
    - vacuity 1y ago
      I don't have numbers, but Rust is also terrible for binary size. Large Rust binaries can be improved with various efforts, but it's not friendly by default. Rust focuses on runtime performance, high-level programming, and compile-time guarantees, but compile times and binary sizes are the drawback. Notably, Rust prefers static linking.
    - kees99 1y ago
      My impression is - rust fares a bit better on RAM footprint, and about as badly on disk binary size. It's darn hard to compare apples-to-apples, though - given it's a different language, so everything is a rewrite. One example: Ubuntu 25.10's rust "coreutils" multicall binary: 10828088 bytes on disk, 7396 KB in RAM while doing "sleep". Alpine 3.22's GNU "coreutils" multicall binary: 1057280 bytes on disk, 2320 KB in RAM while doing "sleep".

oddmiral 1y ago

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

arthur2e5 1y ago
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.
- jitl 1y ago
  at the bottom of the turtle stack, there's a yolo-c libc that does some syscall stuff: > libyoloc.so. This is a mostly unmodified [musl/glibc] libc, compiled with Yolo-C. The only changes are to expose some libc internal functionality that is useful for implementing libpizlo.so. Note that libpizlo.so only relies on this library for system calls and a few low level functions. In the future, it's possible that the Fil-C runtime would not have a libc in Yolo Land, but instead libpizlo.so would make syscalls directly. but mostly you are using a fil-c compiled libc: > libc.so. This is a modified musl libc compiled with Fil-C. Most of the modifications are about replacing inline assembly for system calls with calls to libpizlo.so's syscall API. That links here: https://github.com/pizlonator/fil-c/blob/deluge/filc/include/pizlonated_syscalls.h https://github.com/pizlonator/fil-c/blob/deluge/filc/include... Quotes from: https://fil-c.org/runtime https://fil-c.org/runtime
simonask 1y ago
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.

dontlaugh 1y ago

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.

mbrock 1y ago
What does that have to do with apt?
- dontlaugh 1y ago
  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.
  - procaryote 1y ago
    How is apt performance sensitive?
    - kragen 1y ago
      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.
    - dontlaugh 1y ago
      It parses formats and does TLS, I’m assuming it’d be quite bad. I don’t think you can mix and match.
      - jitl 1y ago
        stuff that talks to "the internet" and runs as "root" seems like a good thing to build with filc.

lucyjojo 1y ago

doesnt it only work on x86_64?