about

what keltOS is

a source-based GNU/Linux distribution: you don’t install binaries, you build them from source on the machine that will run them. the system is described by recipes — one per package, declaring where the source comes from, what it depends on, and how to build it.

it targets arm64 and x86_64, on a modern toolchain, and it is written from scratch in Go.

what it isn’t

it isn’t a fork. keltOS contains no code from any prior distribution, ships no inherited package tree, and is not an attempt to revive anything.

why “spiritual successor”

because the idea came from somewhere, and pretending otherwise would be dishonest.

Hadron GNU/Linux was a source-based distribution in the Gentoo lineage, built in Turkey between 2011 and 2014. its last commit landed in January 2014.

Hadron’s distinguishing decision was that build recipes should be Python-syntax modules rather than bash ebuilds. a package definition was a handful of declarations and, where the build needed help, a few small functions. compare that to the shell-script-with-conventions approach every other source distribution takes, and the difference in how much you have to hold in your head is not small.

that decision aged remarkably well. the implementation around it did not: a package manager in Python 2, a sandbox that depended on a component no longer downloadable from anywhere, and an architecture story that assumed x86_64 and nothing else.

keltOS takes the idea and leaves the rest. same conviction — that a package definition should be something you can read in one sitting — implemented on a stack that will still build in ten years.

melo

the package manager, currently being written. a single static Go binary, and the design decision most of the rest depends on.

recipes will be executed on Starlark, Google’s Python-subset dialect — the Bazel configuration language, with a mature Go implementation. it gives recipes real control flow (def, for, if, comprehensions, string formatting) without being a general-purpose language that can reach into the filesystem or the network behind your back. a recipe gets exactly the build DSL melo hands it, and nothing else.

here is roughly the shape a package should take. this is a design sketch, not a specification — the format is not settled and nothing executes it yet:

name    = "zlib"
version = "1.3.1"
summary = "Compression library implementing the deflate method"
source  = "https://zlib.net/$name-$version.tar.gz"
arch    = ["arm64", "amd64"]

depends = ["sys-libs/glibc"]

def configure():
    run("./configure", "--prefix=/usr", "--libdir=/usr/lib")

def install():
    make("install", destdir = True)
    docs("README", "ChangeLog", "doc/algorithm.txt")

what writing it in Go is meant to buy


no interpreter in the base system	the package manager is a static binary with no runtime dependencies. nothing has to be installed on the target so that the package manager can run — which removes an entire category of bootstrap circularity.
cross-compilation is free	`GOOS=linux GOARCH=arm64 go build` produces melo for the target from any host. no seed interpreter, no chicken-and-egg.
a sandbox that can actually be built	Linux namespaces and Landlock, called directly from Go. no C extension to maintain, no architecture-specific ptrace register offsets — which is precisely what confined the previous generation of these tools to x86.
parallel builds	the dependency graph is resolved before anything is fetched, so independent packages build concurrently. on a machine with cores to spare this is the difference between an afternoon and an evening.
two architectures, honestly	nothing in melo is written against a specific instruction set, so arm64 isn’t a port bolted on later. it is one of two first-class targets.

status

the beginning. not “early access” — the beginning.

nothing is written yet. there is no melo binary, no recipe format you could write against, no package tree, no toolchain, no sandbox, and nothing you could boot. the repositories exist and are empty.

what does exist is a design and a reason to trust it: this approach was tried once, by people who got the central idea right and were let down by the tools available to them in 2011. the failure modes are documented rather than hypothetical — a package manager written in a language that had to ship inside the system it managed, a sandbox depending on a component that has since vanished from the internet, an architecture assumption that made the whole thing unbuildable on the machines people now own. every one of those is addressed by the choice of Go, and none of them is addressed by wishful thinking.

that is worth exactly as much as a design is worth, which is to say: something, but not much until there is code.

the roadmap on the front page is the honest order of operations. this page will say so here first when any of it lands.

the names

neither one means what it looks like. both are Turkish, and both are nicknames.

keltOS has nothing to do with the Celts. it’s coming from keltoş; kel means bald, and the -toş ending is the one that turns a word affectionate rather than rude — the difference between “baldy” and “baldy” from someone who loves you. keltoş is what I have always called the friend who wrote Hadron, who is, as it happens, bald.

melo is the same joke aimed back at me. people like to clip a name short and put an -o on the end to make it fond or a little ridiculous in Turkish. for example: Merve becomes Mero. he calls me melodi — which means “melody” in English and which is not my name either — and melodi clips down to melo.

so the distribution carries his name and the package manager carries mine.

only the capitalisation was deliberate. keltoş already ends in the sound English writes as OS, and keltOS is one — so it is set the way macOS is, and the pun pays for itself.

credit

Hadron was written by the hadronproject developers in Turkey between 2011 and 2014. keltOS uses none of their code, but the idea at its center is theirs, and it is a good one.

not forked from Hadron — descended from it, with love and hair.