Goals and Guidelines

In General

  • Be a valuable resource for all things related to building GNU/Linux systems from source
  • Target the more technically adept Linux user. Not all is described in excruciating detail for newbies. Folks interested in this project will typically:
  1. Have been running Linux boxes for 3 or more years
  2. Have already done LFS
  3. Be control freaks that simply must do it themselves
  • Newbies are directed to the LFS project
  • Education is not a primary goal (although huge opportunities for learning exist due to the nature of the work)
  • Cater for non-standard procedures like cross compiling and building uClibc based systems and any other "off the wall" scenarios that crop up. Basically anything related to toolchain technology
  • Maintain a strong focus on Correctness, Testing, Automation (i.e. scripting) and Package Management
  • Provide a "reference" build. This means folks can take the Reference Build and customize it to their heart's content. There are no huge flamefests about what packages go in or out as it's just for reference
  • Folks are encouraged to share their work/build scripts/whatever they feel like contributing

The Reference Build

  • Build a reasonably up-to-date and usable base GNU/Linux system from source
  • The term "usable" implies Package Management. Therefore the build recipe strives to accommodate general Package Management principles
  • The build method used to bootstrap the Reference Build must be robust and work from a virgin default "dev" installation of every major Linux distro released within the last 5 years. Installing upgraded tools on the host defeats the purpose and therefore does not qualify
  • It must also work the other way around i.e. be buildable from the latest cutting edge distros
  • The base system must be able to build a wide range of commonly used open source software
  • The base system must be self-hosting i.e. be able to rebuild itself reproducibly with verification provided by a binary comparison technique known as Iterative Comparison Analysis (ICA).
  • Use pristine upstream sources with as few patches as possible and as minimal build commands as possible (within reason)
  • Monitor the mainstream distros and attempt to follow if necessary. Do not adopt new technologies into the Reference Build before they are ready. But there is nothing stopping folks from playing around and discussing whatever they want

Administrivia

  • The primary means of communication is via subscription-only mailing lists. Off-list development is discouraged
  • The project is run as a benevolent dictatorship by the Project Leader who reserves the right to make judgment calls on anything he sees fit to judge on, including evicting trolls, trouble makers and individuals guilty of anti-social behavior
Comments