Also, I think that people's efforts should in general be spent on rallying behind dracut and making it work faster, thereby benefiting all Linux distributions that use dracut (increasingly more)."
As described on the website unixsheikh.com recently posted to HN^1 and making the front page^2, I think this illustrates one difference between "Linux" and BSD. Much of what unixsheikh describes has been said before however I think it still remains true today. I am currently using Linux and open to being persuaded otherwise. I want to learn "the Linux way" if there is such a thing.
That said, I always found booting to ramdisk, "root on mfs", "mfsroot", or whatever people might call it, very straightforward on BSD. They maintained and provided all the necessary tools, some of them have no Linux equivalent. Things stayed more or less the same so once the process was learnt, there seemed little chance of the goalposts moving. One did not need to be a contributor to understand these processes. Sometimes I get the feeling I am just not smart enough for Linux, and it seems like these processes are constantly subject to change. (I hope to find the truth is otherwise.)
As a BSD end user, I found it relatively easy to compile a custom kernel and a custom, statically-linked, multi-call binary as a userland, like busybox but using utilities "as is" not pared down with features missing, to be inserted into the kernel. I could boot from USB stick^3 to ramdisk root, pull out the USB stick, e.g., if I needed the USB port, then chroot into any userland. This was extremely flexible and allowed for easy experimentation. Sometimes I might have that userland prepared on internal media, the USB stick, or some other external media, or I might create it dynamically by downloading and extracting binary sets. This "targetroot"^4 userland might be mounted, usually r/o, on HDD or it might just be mfs/tmpfs.
Apparently, the author was inspired to make his own distribution because he found the package installation process too slow for large packages, e.g. qemu.^5 He tried using SquashFS images to speed up the process. I did the same thing in 2012 using cloop2 compressed filesystem images for large packages, e.g. ghostscript, on NetBSD. I would keep them on the USB stick and just mount them over an executable directory as necessary. I was not using these large programs too frequently and I was running entirely from tmpfs, no HDD, so I did not want them occupying space and depleting RAM.
1. https://news.ycombinator.com/from?site=unixsheikh.com
2. https://news.ycombinator.com/front?day=2020-01-20
3. Thanks to the excellent BSD bootloaders I could manually choose the kernel during boot. I would have several kernels on the USB stick. Of course the kernel did not have to reside on the USB stick, I could load it from any connected media. At one point I was able to boot NetBSD kernels using the FreeBSD bootloader.
4. TBH, I still do not know the true story behind targetroot. Things in BSD always have a history behind them. Surely there is a story behind the "targetroot" directory.
5 https://michael.stapelberg.ch/posts/2019-08-17-linux-package...
"How can minitrd be 20 times faster than dracut?
dracut is mainly written in shell, with a C helper program. It drives the generation process by spawning lots of external dependencies (e.g. ldd or the dracut-install helper program). I assume that the combination of using an interpreted language (shell) that spawns lots of processes and precludes a concurrent architecture is to blame for the poor performance."
Interesting that dracut uses bash, not dash for its scripts. Would dash be any faster. Are bash features a necessity for the simple tasks dracut performs.
Also, could dracut use readelf instead of the bash shell script ldd. According to Wikipedia, the Linux man page for ldd asserts it is a security risk.
Does default Ubuntu include a manpage for ldd. Mine is missing.