AnduinOS builds an Ubuntu ISO with make and one arguments file

A distribution built by shell scripts

The repository's primary language is Shell, and that is the whole architecture in one fact. AnduinOS is not assembled with a distribution build framework; it is assembled by scripts that run an existing system and produce an image.

The build interface is deliberately tiny:

make

And the parameters live in one file, `./src/args.sh`, which you edit to change what gets built. The output is an ISO in `./src/dist`, and the README's instruction for testing it is to mount that ISO to a virtual machine and start it.

There is a bootstrap assumption worth stating plainly: the README suggests using AnduinOS to build AnduinOS. So building the distribution from scratch requires either an AnduinOS installation or a machine already capable of producing Ubuntu ISOs. That is not a criticism, it is how the project has chosen to sequence things, but it does mean the first build is not self-hosting from a fresh Ubuntu install.

The repository layout supports the picture. There is a `makefile` at the root in lowercase, `build_all.sh` and `clean_all.sh` for the full build and its inverse, a `config/` directory, and a large `src/` tree. One path in the README's markup hints at the structure beneath: `src/mods/30-gnome-extension-arcmenu-patch`, which suggests numbered modification stages, and the numbering is what `args.sh` presumably selects between.

Which repository is the current one

The default branch is `1.4`, not master or main. That is unusual enough to check before you clone anything, because a checkout of the default branch gets you the 1.4 line.

There is a second repository for the next version. The README directs anyone looking for the source of AnduinOS 2 to the AnduinOS 2 repository under the `aiursoftweb` organisation, and the primary language there is not stated here but the split itself is what matters: this repository is the 1.x line, and new development has moved.

The release history reinforces that reading. Three tags appear within the same minute on 2026-01-04: 1.4.2, 1.3.9 and 1.1.12. Publishing three release numbers simultaneously looks less like three separate releases and more like a maintenance pass that pushed version bumps across several supported series at once, which is a reasonable thing for a distribution that keeps older branches alive for people who installed them.

The last push was on 2026-09-28 and the repository is not archived, so the 1.4 line still receives work roughly nine months after that tag batch.

Why a prebuilt distribution at all

The project's stated purpose is a custom Ubuntu-based Linux distribution offering a familiar and easy-to-use experience for anyone moving to Linux. The positioning is about the first-run experience rather than about packaging innovation.

That framing explains the choices visible in the repository. There is no attempt to be a general-purpose build system, no supported list of targets, and no declarative configuration. There is one product, tuned by one set of scripts, and a designer deciding what a new user should get.

The trade-off is direct. If you want Ubuntu with a particular desktop layout, window manager and application set already arranged, this saves an afternoon to a day of configuration. If you want to know exactly what is in the image, why each package is there, and how to change it reproducibly, that is precisely what this repository does not give you, because the configuration is a set of shell decisions rather than a manifest you read.

The path `30-gnome-extension-arcmenu-patch` in the README's markup is a good example of the difference. It implies a script that patches a GNOME extension, which is exactly the sort of last-mile adjustment a distribution makes and a user cannot easily reproduce on their own machine.

Funding, governance and where questions go

AnduinOS is funded by user donations, and the README says the project is grateful for support, with a PayPal link for that purpose. For a hobby-adjacent distribution maintained in shell scripts, donation-funded is the honest description of the model, and it tells you something about bus factor that no badge would.

The licence is the GNU General Public License, with a LICENSE file at the root. The README also states that the open-source software included in AnduinOS is distributed in the hope that it will be useful but without any warranty, and points to an `OSS.md` file listing the open-source software included. That list is the thing to read before redistributing an image you built, since AnduinOS is a collection of other people's packages and the terms travel with it.

Support is split between two channels. Community discussion goes through GitHub Discussions and a Revolt community, while bug reports and feature requests go to the GitHub Issues page. Documentation is at docs.anduinos.com, and the project site is anduinos.com.

There is also an `upgrade_14_to_20.sh` script at the root, which is a detail worth noticing. An upgrade path from one base release to another implies that an installed system is expected to be carried forward rather than reinstalled, and a shell script is what performs it. The name suggests the jump from Ubuntu 20.04 to a later base, though the README does not describe its behaviour in detail.

CI on GitLab, code on GitHub

There is a `.gitlab-ci.yml` at the root, and the badges in the README point at `gitlab.aiursoft.com` for the project, the licence file and a commit activity counter. The code, the discussions and the issues live on GitHub.

That split is unusual enough to mention because it affects where you report what. An issue tracker on one forge and the build pipeline on another means a broken build may not surface in the place a contributor is watching.

The build itself is driven by `make`, so the CI most likely runs the same entry point you would run locally. That is the right design for a distribution whose stated build interface is one command, and it means a failing CI is telling you that `make` fails on that runner.

The remaining directories complete the picture: `config/` for build configuration distinct from `src/args.sh`, `src/` for the bulk of the work, `build_all.sh` and `clean_all.sh` for the full cycle, and `.gitignore` for generated artefacts such as whatever lands in `src/dist`.

Everything about this project is aimed at one image for one audience. That is a legitimate thing to want and a poor foundation for anything you intend to reshape later.

Editorial conclusion

Adopt AnduinOS if you want a preconfigured Ubuntu-derived system with a particular desktop configuration and can accept that you are running someone else's choices rather than assembling your own. Do not adopt it as a base for a distribution you intend to maintain yourself, since the build is a shell script suite tuned by one person. Verify first which branch you are on, since the default is 1.4 and AnduinOS 2 lives in the aiursoftweb/anduinos-2 repository, and confirm that a system capable of building Ubuntu ISOs is available before you start.

Frequently asked questions

Official sources

1. Anduin2017/AnduinOS on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases