Axe OS

Axe OS is a from-source operating system, driven by Linux From Scratch and others like it.

Instead of creating a full-fledged desktop system, it is more about simplicity and a lightweight module-based approach. It is intended for use with my C/C++.

With the Docker runtime, any additional dependencies or utilities required in the future can be built, ran or downloaded inside Docker containers. This way, the host system is left clean; no need to install any dependencies.

Advice

Here is a corrected version of your text. I have fixed the grammar, spelling, and flow while keeping your specific advice and technical perspective intact. My advice: Learn the Bash programming language. It is underrated, but it saves time and helps you avoid many of the pitfalls I fell into. The number of times I accidentally deleted my main OS or lost projects—and the amount of time I wasted because of it—is something you definitely want to avoid.

I’ve even bricked a disk before. You might wonder how you can brick a disk: unsynced changes, multiple simultaneous writes, or overwriting—I’m not entirely sure of the exact cause, but my disk just stopped working. It wasn't even a hard drive; it was an SSD. So yeah, many things can go wrong.

Depending on your needs, you might not need to build most of the tools I use. For example, BusyBox already includes awk, sed, patch, coreutils, findutils, diffutils, grep, tar, gzip, xz, bzip2, and more. The reason I build these tools separately on my side is for Docker. Docker requires specific compression and networking tools, so since I was going to build those anyway, I decided to build the others as well.

When following LFS, you may notice they include a large number of packages. For some Python-related packages, you can just build Python with pip and then install the rest using pip. You don’t have to download and build every single one from source. The same applies to Meson and Ninja; you don't necessarily have to download the source code for them. This approach can really speed things up for you.

The next choice you’ll face is the graphical stack: Xorg or Wayland. I avoid Xorg because of the massive number of packages I would have to build. It’s not that I can’t build them, but there are just too many to maintain. Xorg is slowly being phased out—not overnight, but it is happening. Another issue is connecting applications inside Docker to your host system; with Xorg, you have to expose more than is ideal.

For the compositor, it is best to look for something written in C or C++ that uses dependencies you already provide or has very few (1–2) extra dependencies. While there are some good compositors out there, some are written in Rust and others in Zig. I’m not interested in building the Zig or Rust compilers right now, as that would require building LLVM, which is another beast entirely.

If you are going to use a GPU for OpenGL or Vulkan, you will eventually need to build LLVM because Mesa requires it. However, I’ll be using software rendering for now. I will figure out the GPU side of things later because I don't plan on using Mesa; I intend to download the AMD, Intel, or NVIDIA drivers directly. I will work on that a bit later on.

Project Structure

The project is structured to keep configurations, utilities, and package builds clearly separated and easy to maintain.

configs/
	global.env
	global.chroot.env
	utilities.bash

build/
	{package}/
		package.env
		build.bash
	...

Configuration

• configs/global.env

  • Environment variables specific to the bootstrap and toolchain build environment stage.

• configs/global.chroot.env

  • Environment variables specific to the setup and final build environment stage.

• configs/utilities.bash

  • Common helper functions used by build scripts.

Build System

Each package lives in its own directory under build/ and defines:

• package.env — package-specific configuration and versioning

• build.bash — the build logic for that package, include logic for all build stage support by package

Build Stages

Packages are built in four distinct stages, following a progressive bootstrapping model:

1. Bootstrap

Minimal components required to bring up a usable base toolchain:

• binutils

• GCC

• Linux headers

• glibc

• libstdc++

2. Toolchain

Core Unix tools and a more complete compiler toolchain:

• m4, ncurses

• coreutils, diffutils, file, findutils

• gawk, grep, gzip, make, patch, sed, tar, xz

• binutils, gcc

3. Setup

Tools required for building more complex software:

• bison

• Perl

• Python

• texinfo

• util-linux

4. Final

Rebuilds most of the previous components in their final form and installs higher-level software, including:

• Docker and graphics stack support

• Development tools such as git

• Networking and utility dependencies (e.g curl)

• Additional packages required by the target C/C++ and Go codebases

Sources, Sysroot, and Mounts

All package source archives are downloaded into a shared sources/ directory.

The build uses multiple sysroots depending on the stage:

• sysroot/cross
  Used during the bootstrap and toolchain stages to build an isolated cross-compilation environment.

• sysroot/
  Represents the final target system and is used during the setup and final stages.

During the setup and final stages, the following directories are mounted into the chroot environment to make them accessible during the build:

• sources/
• build/

This approach keeps source archives and build scripts outside the target filesystem while still allowing full visibility inside the chroot when needed.

Contributing

Contributions are welcome.

This project is experimental and intentionally minimal, so clarity and simplicity are preferred over feature expansion. If you plan to contribute:

• Keep changes focused and well-scoped
• Follow the existing project structure and build stages
• Avoid introducing unnecessary dependencies
• Document any non-obvious behavior or design decisions

Before submitting large or architectural changes, consider opening an issue to discuss the approach first.

By contributing to this project, you agree that your contributions will be licensed under the MIT License.

License

Axe OS is licensed under the MIT License.

This license applies only to the Axe OS build scripts, configuration files, and documentation contained in this repository. It does not override or alter the licenses of third-party software built by the system (such as the Linux kernel, GCC, glibc, or other packages), which remain under their respective upstream licenses.