Many people suggested that I do that. I believe it's the standard way to embed files into executables. Open the executable and read backwards from the end until the zip archive metadata is found.
My goal was to do it in such a way that the Linux kernel memory mapped the embedded file section before the process had even started running. I explicitly wanted to avoid doing things like opening /proc/self/exe and reading its contents into memory. My interpreter is freestanding and has zero dependencies. This solution fits the minimalist spirit of the thing.
Long story short: Linux passes a pointer to the ELF program header table to the process via the auxiliary vector which means the program segments are already reachable from inside the program, and I took advantage of that by adding custom load segments and making the interpreter search for them at runtime.
This little mechanism allows embedding arbitrary data, including zip files. I made a little lisp S-expression file format which the interpreter simply parses but it could have been anything. Zip archivers should be able to edit the data in place, it should work fine provided the segments are updated with the new size of the zip archive.
The practical application of this is to enable the creation of a freestanding, self-executing application by making a copy of an existing interpreter and adding the desired code and data to it, even though the interpreter has already been compiled and linked:
The interpreter introspects, discovers there's an embedded segment inside itself and evaluates it. Unfortunately I had to write a tool to append those segments. Never figured out how to do it with linker script.
My understanding is that they had massive QC issues. I ordered one on a lark and actually liked it, ended up getting a few times. But from what I've seen online that was not a universal experience.
Or just use https://limine-bootloader.org/, which greatly simplifies everything. No messing around in real mode (even when doing SMP), automatically loads your kernel using a higher-half mapping, and also works on aarch64 and riscv64.
To be fair, writing a bootloader is an interesting and educational project in its own right. But yes, for most people interested in osdev they should just use an existing bootloader. It gets you to the part that interests most people (writing the kernel) faster, and without having to worry if you are going to run into gnarly bugs because the bootloader is buggy and you never realized.
I'm not convinced that matters much in 2024, especially when this article singles out safety critical systems. Such systems are likely to be fairly expensive to being with, so the marginal cost of adding a display would be minuscule compared to testing and regulatory costs (not to mention the increase in fault tolerance versus a failed segment causing an incorrect reading).
A cracked LCD screen also makes the display unreadable. There are all sorts of ways for anything to fail, so calling out one failure method of one thing while ignoring similar failures for the device being compared comes across as very short sighted
The thing I hate about low cost LCD displays is that terrible motion blur when you have changing or scrolling text. It just screams cheap in my mind. 7 segment never had that problem.
Yes but a cracked LCD is much more obvious than a single LED segment burning out. Also usually physical damage is required to crack an LCD, where as LEDs can burn out (albeit rarely)
