I’ve read through the LFS: Linux From Scratch and the add-on BLFS and ALFS books that pile on popular advanced concepts, although there’s no hope to cover everything. It is for this reason that new Linux distributions are created all the time. Here, I elaborate my thoughts to help motivate myself for building my own LFS-based Linux distribution for mainly my own education.

I want to marry my love of emulation with my love of Linux to create a Linux distribution that targets running within a virtual machine. Many distributions do this well enough already, but I would like to make my own. Here are the changes I want to make to define my new distribution:

• Target virtual hardware exclusively.
  
  I don’t think a one-man distro project can ever be the best solution for bare-metal use in the real world. Cubby will specifically forgo hardware support, targeting only VirtIO devices and a few select physical devices only inasmuch as these devices are used in popular virtual machine hosts as a fallback option for our kernel to reach the “outside world.”
  
  This choice will save hundreds of megabytes of storage for drivers that are simply unnecessary, reduce build times, and help ensure that Cubby really feels like it fits in a cubby.
  
  Naturally, this implies no power management and no CPU frequency support, removing the relevant kernel code.
  
• Target the simplest CPU for an architecture.
  
  Cubby intends to run inside an emulator, so it should try to make the job of the emulator as easy as possible. Cubby aims to be architecture-independent while keeping the code to be emulated common and basic. This avoids small performance costs like when an emulator uses intrinsics or helper functions to implement more complex or uncommon instructions.
  
• Self-hosting.
  
  Cubby will be most easily propagated by copying VM images or virtual disk drive files. Cubby doesn’t need to be capable of building itself from scratch. However, being a self-hosting distro is like a weight upon a bridge, setting a minimum standard of technical capability.
  
• System compiler: clang.
  
  It is the opinion of the author that clang is technically superior to GCC and is both faster (in compilation) and offers more features. Linux now supports clang builds.
  
• System libc: musl
  
  This is simpler and smaller than glibc, and it ups the challenge and interest in building a custom compiler and toolchain for the system while still insisting that it should be able to build the Linux kernel.
  
• No initramfs.
  
  To facilitate a fast initialization, and given the advance knowledge of the emulated environment, an initramfs should not be needed.
  

This is already more than enough challenge before I start thinking about maybe having a graphics system, so let’s keep it simple and work from here.