It is so confusing to me. Yolo-C, Yolo Land, Fil-C...
For example
> Fil-C supports both musl and glibc. Because of the coupling between the loader, libc, and runtime, Fil-C always uses the same libc in Yolo Land as in User Land. So, when running with musl, we use two versions of musl (one compiled with Yolo-C and another compiled with Fil-C).
> And when running with glibc, we use two versions of glibc (one compiled with Yolo-C and another compiled with Fil-C). The rest of this page documents how the runtime looks with musl. If you build with glibc, you'll see minor differences.
Why do you need a libc compiled with both Yolo-C and Fil-C, and what are the differences? What exactly is Yolo-C?
This project says "The kernel is compiled with Yolo-C."... so is that a good thing? And why not Fil-C?
I see Yolo being mentioned a lot everywhere. What exactly is that, how does it relate to Fil-C, and what are the differences? There is such a thing as Yolo toolchain (and Yolo Land (userland)), too!
I believe in u/pizlonator's parlance Yolo-C is any C compiler that isn't Fil-C.
Some parts of Pizlix are built with Yolo-C, including the kernel. My guess is that Fil-C is not yet able to build a Linux kernel and have it run well, or maybe it's only a bootstrapping issue (as u/pizlonator notes in another sub-thread).
Fil-C _itself_ needs two C libraries: one for Fil-C's run-time, and one for the program you've compiled with Fil-C. The C library for the program built with Fil-C has to be built with Fil-C, while the one for Fil-C's run-time can't itself be compiled with Fil-C and must be built with Yolo-C.
Lastly, YOLO is an acronym meaning "you only live once". It's something one says right before doing something dangerous, such as bungee jumping. The joke here is that any C compiler that is not the Fil-C C compiler is dangerous, thus "YOLO!".
I think the way to do that is via something like l4linux, so that the ultra low level bits of the Fil-C runtime aren't relying - circularly - upon kernel functionality compiled with Fil-C that rely on that runtime.
The only thing standing in the way of it working on real HW is just making sure the kernel is configured properly for it. Like right now the kernel config file is the result of enabling those things that work on the virtual devices that HyperV and VMware provide.
The right answer is modular kernel and something like initramfs and modprobe or whatnot. That kind of work has nothing to do with Fil-C; it’s just distro engineering
I don't expect for a moment that Fil-C might supplant normal C under normal circumstances. Calling normal C "yolo-C" is dishearteningly pompous. Just because you've invented a C environment with a different tradeoff, people not interested in it are not automatically irresponsible (which is what you are suggesting with "yolo", of course).
Back in the Usenet days we used to call C development, cowboy programming, while they called safer languages like Ada, Modula-2 and Object Pascal, straightjacket programming.
metadope|2 months ago
kbr2000|2 months ago
> You must have a filesystem, located on the /dev/sda4 device, mounted at /mnt/lfs.
The /dev/sda4 device represents the fourth (primary) partition on the /dev/sda block device, which represents the first SCSI disk.
pizlonator|2 months ago
ndesaulniers|2 months ago
Fil, you can compile the Linux kernel will clang+lld. `make LLVM=1` https://docs.kernel.org/kbuild/llvm.html
pizlonator|2 months ago
So if I used clang, then I'd have three compilers (yolo-clang, gcc, fil-clang) instead of two (gcc, fil-clang).
johnisgood|2 months ago
For example
> Fil-C supports both musl and glibc. Because of the coupling between the loader, libc, and runtime, Fil-C always uses the same libc in Yolo Land as in User Land. So, when running with musl, we use two versions of musl (one compiled with Yolo-C and another compiled with Fil-C).
> And when running with glibc, we use two versions of glibc (one compiled with Yolo-C and another compiled with Fil-C). The rest of this page documents how the runtime looks with musl. If you build with glibc, you'll see minor differences.
Why do you need a libc compiled with both Yolo-C and Fil-C, and what are the differences? What exactly is Yolo-C?
This project says "The kernel is compiled with Yolo-C."... so is that a good thing? And why not Fil-C?
I see Yolo being mentioned a lot everywhere. What exactly is that, how does it relate to Fil-C, and what are the differences? There is such a thing as Yolo toolchain (and Yolo Land (userland)), too!
cryptonector|2 months ago
Some parts of Pizlix are built with Yolo-C, including the kernel. My guess is that Fil-C is not yet able to build a Linux kernel and have it run well, or maybe it's only a bootstrapping issue (as u/pizlonator notes in another sub-thread).
Fil-C _itself_ needs two C libraries: one for Fil-C's run-time, and one for the program you've compiled with Fil-C. The C library for the program built with Fil-C has to be built with Fil-C, while the one for Fil-C's run-time can't itself be compiled with Fil-C and must be built with Yolo-C.
Lastly, YOLO is an acronym meaning "you only live once". It's something one says right before doing something dangerous, such as bungee jumping. The joke here is that any C compiler that is not the Fil-C C compiler is dangerous, thus "YOLO!".
johnisgood|2 months ago
It would be nice to have this cleared up somewhere (accessible).
... or maybe I should just ask an LLM at this point.
---
So I did. If anyone is interested in the answer (provided by an LLM), then see: https://chatgpt.com/share/6943df8f-2cbc-8011-9e65-afbcaf1987...
jabedude|2 months ago
pizlonator|2 months ago
hulitu|2 months ago
Any idea if it runs on real hardware ?
pizlonator|2 months ago
The only thing standing in the way of it working on real HW is just making sure the kernel is configured properly for it. Like right now the kernel config file is the result of enabling those things that work on the virtual devices that HyperV and VMware provide.
The right answer is modular kernel and something like initramfs and modprobe or whatnot. That kind of work has nothing to do with Fil-C; it’s just distro engineering
CerryuDu|2 months ago
At least in this article:
https://fil-c.org/runtime
the term "classic C" is still used.
I don't expect for a moment that Fil-C might supplant normal C under normal circumstances. Calling normal C "yolo-C" is dishearteningly pompous. Just because you've invented a C environment with a different tradeoff, people not interested in it are not automatically irresponsible (which is what you are suggesting with "yolo", of course).
pjmlp|2 months ago
I am perfectly fine with Yolo-C nickname.
reactordev|2 months ago