Working towards a source-based bootstrapping path to a GNU+Linux system
Published in 2021, this chronicle by @podiki details the mechanics of building a profitable, self-funded business without venture backing.
Core Principles for Independent Builders:
Charging customers from day one acts as the ultimate filter for building software that solves genuine, high-urgency problems.
Keeping fixed overhead low and leveraging lean infrastructure allows founders to stay alive until market tailwinds kick in.
Small, repetitive improvements in customer retention and conversion rates yield massive returns over multi-year horizons.
Community Debate Themes:
The community focused on B2B customer acquisition channels, cold email vs SEO distribution, and balancing full-time employment with side-project development.
CATEGORY Bootstrapping & MRR →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE 97 points
TOTAL DISCUSSIONS 19 comments
Bootstrapping GNU userland is a major pain point, and it's great to see GNU Guix taking it so seriously. There's even a section of their manual dedicated to it [1].
This is important, even if you don't intend to run GNU Guix itself. I care about building GNU userland for embedded targets, and even with a build system like Yocto, which builds specific versions of the entire host userland, you can get errors due to eg. an older gnu m4 not being buildable with a modern glibc. Thus, you end up essentially requiring developers to build inside a container.
This is paving the way for having everything required to build a piece of software just checked into the git repository. If you want to change it, you just commit it like everything else.
[1] https://guix.gnu.org/manual/en/guix.html#Bootstrapping ↗
Bootstrapping gcc and libc was one of the time honoured traditions I went through as a teenager with a Linux box. Learning how to set up gcc as a cross compiler to produce ELF binaries on an a.out system (or generating m68k binaries on my 486) was quite helpful later in my career when working on embedded systems. Granted, a lot of this was necessary as SLS and Slackware didn't exactly have very capable packaging systems at the time.
As well as the diagram on that page, there is a nice document in one of the repos listing the bootstrapping steps in order, from "stage0" to "gcc 4.7.4" and beyond:
https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst ↗
I find this fascinating and am a big supporter of FSF and GNU.
All that said, I am not an expert so would like to learn more. Can somebody let me know why one cannot just take the assembly version of an existing compiler and carefully review its code to be happy with it and then build everything from that verified compiler? Why does it need so many steps?
Super interesting, but I wonder if there is a historical accurate account of bootstrapping that is well documented. This jumps into ELF pretty quickly but there were older formats like a.out and OMAGIC? before ELF. Is there good documentation on the bootstrapping of x86 BSD or Minix since they are even older than Linux.