+ ける・けいとうてき — craft your system.
+ Keru OS is licensed under AGPL-3.0. No opinion, no telemetry, no bloat.
+
home / about
+An independent, source-only Linux distribution built around one idea: you don't install a system, you craft one.
+Keru (ける) is a Linux distribution where virtually nothing is decided for you. Every foundational component — init system, C library, filesystem, kernel, privilege-elevation tool, network stack — is a variable you resolve at install time. What lands on your disk is precisely what you chose, compiled from original source.
+ +The name comes from ける・けいとうてき (keru keitō-teki), roughly "craft your system." It's the whole point stated as a phrase.
+ +Keru is deliberately split into three pieces so each stays small and legible:
+| Repo | What it holds |
|---|---|
| KeruOS | This repo — the installer, profile system, build pipeline, and website. |
| kama | The package manager. A ~225-line shell script. The "kiln" that fires recipes. |
| kama-packages | The recipe repository — plain shell scripts that describe how to build each package. |
Keru belongs to the line of source-and-choice distributions that includes Gentoo and Nix. Where Keru differs: it takes the "no opinion" stance further than any of them. Gentoo still picks most of your stack for you; Keru asks you to form the whole opinion up front, then builds exactly that.
+ +Keru is in active development. The first installable release, 0.1, will ship as a bootable ISO. Until then, the repositories document the design, philosophy, and the build pipeline it's all wired through.
+ +home / philosophy / anti-opinionated
+The core stance, and what it actually grants and costs you.
+Every Linux distribution is an answer to the same question: who decides what your system is? Most answers reduce to "the maintainers, wisely." Your distro picks systemd or OpenRC, glibc or musl, ext4 or btrfs, and you inherit that stack as the price of using it.
+ +That's genuinely fine for a lot of people. It's how you get a system that mostly works with default effort. But it means the shape of your machine is decided by someone else's tastes, release cadence, and risk appetite.
+ +Keru answers differently: the distribution holds no position. Not a middle position — no position. It doesn't ship a "best" init or a "recommended" filesystem, because that recommendation is the very thing Keru exists to remove.
+ +Every foundational component is presented as a flat, open choice in the installer. Runit or systemd? They're options, side by side, weightless. glibc or musl? Your call. btrfs or reiserfs or swap? All offered. Keru doesn't rank them, because ranking is an opinion, and opinions are exactly what it delegates to you.
+ +make.conf — readable, editable, rebuildable.To head off a common reading: anti-opinionated doesn't mean Keru is a "meta operating system" that runs arbitrary kernels. Keru is a Linux distribution. Its freedom lives in userspace and configuration — init, libc, filesystem, kernel (within Linux), tooling. It's the meta-distribution stance: choice and composition over a fixed opinionated stack.
+ +An opinionated distro tells you what to use. Keru tells you that you have to choose — and then builds exactly what you pick.+ + +
From make.conf to a bootable filesystem.
+The build pipeline is the machinery between your profile and a running system. It's intentionally thin — a few shell scripts that orchestrate Kama, not a build system monolith.
+ +build-root.sh boots a toolchain from nothing: binutils, gcc, your chosen libc, then the toolchain package. This is the "fully from scratch" step — the stage that separates a source distro from one that seeds binaries.
The BASE_PACKAGES set from your profile is built and installed into $ROOT. Every package compiles against the stage-0 toolchain.
Exactly what you chose: the kernel ($KERNEL), the init system ($INIT), your privilege-elevation tool ($SUDO), and your network tools ($NET). Nothing preselected — the picks in your make.conf are the picks that get built.
mkfs-root.sh formats and assembles the target as your chosen filesystem, producing the rootfs that will boot.
[ keru ] building Keru rootfs into /tmp/keru/root +[ keru ] profile: init=runit libc=glibc fs=ext4 kernel=linux sudo=doas +[ keru ] stage 0: bootstrap toolchain (gcc binutils glibc) +[ keru ] stage 1: base system +[ keru ] stage 2: kernel + init + sudo + net +[ keru ] stage 3: finalize ext4 root +[ keru ] rootfs ready: /tmp/keru/root+
| Script | Job |
|---|---|
scripts/common.sh | Shared helpers; knows the sibling-repo layout (KAMA_DIR, PKGS_DIR). |
scripts/build-root.sh | The orchestrator — runs the four stages above. |
scripts/mkfs-root.sh | Formats the target root as the chosen filesystem. |
home / community
+A small distribution with a clear idea, shaped by people who care about choice.
+Write recipes, fix the installer, improve docs, or help shape the road to 0.1.
+ 2FAQStraight answers to the questions everyone asks.
+ 3ContactGitHub issues, mailing list, and how to reach the project.
+ 4LinksThe three repos, this site's source, and related reading.
+Keru holds one opinion — that you should form yours. That extends to the community: the interesting conversations here are about which init/libc/fs combos should be proven next, which recipes matter, and how the distro stays honest at its edges.
+ +Use issues for bugs and ideas; the list for discussion.
+Bugs, recipe ideas, installer feedback, combination reports. The most actionable way to reach us.
+ +Longer conversations about philosophy, design decisions, and direction. Subscribe or join the thread.
+keru@keru.org (placeholder)
+A real-time room for early adopters and contributors.
+#keru:matrix.org (placeholder)
+make.conf (if any), the failure output.There's no gatekeeping. There's work to do.
+Keru is small and early, which means contributions are unusually consequential. A recipe you write may be the one a whole filesystem choice builds on. Here's how to get in.
+ +| Repo | You'd contribute |
|---|---|
| KeruOS | Installer, profile, scripts, live init, docs, and this website. |
| kama | The package manager itself — and, ideally, not much. It's meant to stay small. |
| kama-packages | Recipes — the highest-leverage place. Busybox, runit, and a template exist. |
<pkg>.sh in kama-packages is a package. Start from TEMPLATE.sh. The format is small.web/ in the KeruOS repo — plain HTML, no framework. Improving it is plain work on plain files.Issues, recipe ideas, and bug reports live on the three repositories, and discussion on the contact channels. If you're looking for a first move: pick a recipe, read TEMPLATE.sh, and send it.
home / credits
+The people, projects, and tools Keru stands on.
+Keru is the work of Astral (@AstralZX), who maintains all three repositories and this site. It grew out of earlier experiments (the lineage runs TOML packages → a 50-line build DSL → plain shell, and from opinionated dogmas to the anti-opinionated stance).
+ +A source-only distribution is downstream of everyone who makes the sources it builds: the Linux kernel, GCC/binutils, the libcs, busybox, the init systems, the filesystem tools, and every project with a recipe in kama-packages. Credit belongs to all of them, and their licenses — not Keru's — govern those components. Keru's AGPL covers Keru's own code (see the license page).
home / docs
+The reference. Everything you might open a file to check.
+The profile file your selections produce, and every variable it knows.
+ referenceProfile systemHow profile/make.conf templates the build and the swappables.
+ specRecipe formatThe formal spec for kama package recipes — fields, hooks, tiers.
+ referenceBuild pipelinescripts/build-root.sh and mkfs-root.sh — how a make.conf becomes a rootfs.
+ referenceLive initlive/init — how booting the ISO auto-starts the installer.
+ guideSwappables guideEvery component you can choose at install, with the full option list.
+ guideInstall guideThe end-to-end installation flow, from BIOS to boot.
+ guideContributeHow to get involved across the three repos and this site.
+home / ethos
+What the mark stands for.
+Keru is written ける in Japanese, and the project's full phrase is ける・けいとうてき (keru keitō-teki) — a system assembled the way you want it. The ethos is compact enough to sit behind a name: you don't receive a system, you craft it.
+ +It's deliberately not a pronouncement. It's a description of the relationship Keru wants with you: you choose, it builds, and it has no agenda beyond honoring that choice.
+ +The package manager is called Kama (窯, "kiln"). The metaphor is warm on purpose — not a cathedral of machinery, but a kiln: you stack your ingredients, fire it, and what comes out is shaped by your hand, not by the kiln's preferences. A kiln doesn't have opinions about the pot. It just fires.
+ +make.conf you can see and change.企業はあなたの選択の上に成り立つ — the distro stands on your choices.+ + +
Straight answers.
+In the GNU/Linux world it names the Gentoo/Nix/Bedrock family: distributions organized around choice and composition of components rather than a fixed opinionated stack. Keru is the anti-opinionated member — its meta is choosing not to choose for you. Details.
+ +No. Keru is a Linux distribution. Its freedom lives above the kernel — init, libc, filesystem, and Linux kernel variants. It won't boot a BSD or illumos kernel; that's not the claim and not on the roadmap.
+ +Gentoo is source-based and highly configurable, but it still picks most of your stack and calls it defaults. Keru extends the same impulse to its logical end: no default init, no default libc, no default filesystem. And its manager, Kama, is a ~225-line shell script — no resolver, no database.
+ +Bedrock stitches multiple distributions together (apt + pacman + xbps side by side). Keru doesn't compose distros — it composes components, one init/libc/fs/kernel/tool at a time, built from source.
+ +The ISO carries only the installer. Your entire system is fetched and compiled during install, so a connection is a hard gate. It's the price of "power to choose anything" — nothing is prebuilt. More.
+ +Stable on the combinations Keru offers you — that's the promise. If you pick something past the proven edge, the installer warns and lets you proceed. You're never blocked. The full stance.
+ +Real. The repos are live, AGPL-3.0, and the road to 0.1 is documented. It's at the "design is public, nothing has booted hardware yet" stage — which is exactly what 0.1 is for.
+ +ける (Keru) and ける・けいとうてき (keru keitō-teki) — "craft your system." Kama (窯) means "kiln." The naming is deliberate atmosphere, not branding gimmick. More.
+ +Because a package manager should be legible, and shell is the most legible thing that can run a build recipe. The real cost of your build is the compiler, not the manager — so the manager gets to be simple.
+ +The first release, 0.1, ships as a bootable ISO. Follow the road to 0.1.
+ +Contact channels — issues first, then the mailing list.
+ +home / swappables / filesystems
+The shape of your disk.
+The filesystem is how the kernel organizes data on disk — and it's a genuinely meaningdifferent choice: reliability vs features, volume management, snapshots, checksums, performance on specific workloads. Keru leaves it to you.
+| Filesystem | Character |
|---|---|
| ext4 | The default. Proven, journaled, everywhere-supported, boring in the best way. |
| ext2 / ext3 | Classic lineage — ext2 is unjournaled simplicity, ext3 added the journal. |
| btrfs | Snapshots, subvolumes, checksums, and a rich feature set out of the box. |
| xfs | Scale-friendly, robust, excellent for large files and heavy workloads. |
| zfs | Snapshots, RAID-Z, checksums, volume management. Serious features, more moving parts. |
| f2fs | Flash-friendly filesystem, designed for SSDs and flash storage performance. |
| jfs | IBM's journaled filesystem — lean, historically aimed at servers. |
| reiserfs | Once a pioneer; now effectively unmaintained. Offered, but flagged. |
| swap | As a separate swap area, part of the root setup. |
Two filesystem options carry warnings in the installer:
+Keru is an anti-opinionated Linux distribution. Choose your init, libc, filesystem, kernel, and tools at install time — and it builds exactly what you chose from source. Nothing forced, nothing you didn't ask for.
+ +the differentiator
+Most distros hand you someone else's decision. Keru refuses that — every foundational component is yours to pick, resolved at install time and locked in at first boot.
+runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd — your call.
+ 02C libraryglibc, musl, uclibc-ng. The foundation under everything is up to you.
+ 03Filesystemext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap. Pick your root.
+ 04Kernellinux, linux-lts, hardened, cachyos, zen. The spine of your machine.
+ 05Privilege elevationdoas, sudo, opendoas, or plain su — decide how you elevate.
+ 06Network toolsnetworkmanager, connman, systemd-networkd, or nmtui on its own.
+ 07Everything elsekernel parameters, locale, clock, keymap — all configurable in make.conf.
+ 08StabilityStable on what we offer. Past that, we warn and step aside — never block.
+live demo
+The ISO carries only the installer. Boot it, it starts the installer automatically, you make your picks — and it builds your entire system from source.
+[ keru ] Keru OS — craft your system +Select the components, press enter for defaults. + +== Init system == [runit] +== C library == [glibc] +== Filesystem == [ext4] +== Kernel == [linux] +== Privilege elevation == [doas] +== Network tools == [nmtui] + +Selecting: btrfs ← you choose, Keru builds it +...fetching source... +...compiling from scratch (gcc → glibc → the system)... +[ keru ] rootfs ready: /tmp/keru/root +[ keru ] you crafted a btrfs, doas, runit system. it boots.+
why keru
+Everything — toolchain included — compiled from original source. No binary packages, no opaque machinery.
The whole package manager is a ~225-line shell script. Legible. You can read every decision it makes.
Keru's only opinion is that you must form one. After that, it shuts up and builds exactly what you chose.
The ISO carries only the installer. Your system is fetched and built on the fly during install.
Stability is guaranteed on what's offered. Push past the proven edge and Keru warns you, then gets out of your way.
No telemetry, no unwanted services, no background assumptions. The disk reflects exactly what you chose.
Keru 0.1 will ship as a bootable ISO. No source builds, no manual tooling — boot, choose, then watch it craft your system.
+home / swappables / inits
+Who brings your machine up. Your call.
+The init system is the first thing that runs after the kernel — it boots the rest of your system and usually supervises services. It's also one of the most fought-over pieces of modern Linux. Keru's answer to the fight is simple: pick one yourself.
+Small, fast, BSD-style. Default in Keru — fast boot, simple service supervision, based on the runit process supervisor.
The skarnet suite's init and service manager. Dependency-free, designed-for-service supervision, very small.
The classic Gentoo-style init. Compatible with sysvinit-style init.d, predictable "exclusive" service tree.
The dominant init — service manager, logind, udev, resolved, timedate, all in one. If you want it, it's a choice, not an assumption.
The bare init from busybox. Minimalist, tiny static binaries, closest to "nothing but a process supervisor."
The classic System V init. Simple runlevels, init.d scripts, historically the baseline Linux init.
A modern, fast, dependency-oriented init and service manager. Parallel boot, small footprint.
GNU's service manager (init). Guile-based, declarative services, part of the GNU project.
Some combinations are easier than others. The stability check in the installer flags pairs that aren't yet proven (for example, musl + systemd), but never blocks them — the warn-not-block stance.
home / install
+Boot the ISO. The installer starts itself. You choose. It builds.
+Keru ships as a live ISO that carries only the installer. There is no prebuilt base image on the disk. The entire system — toolchain, kernel, init, libc, filesystem tooling — is fetched and compiled during installation, on the fly.
+ +nmtui for you.live/init) mounts the essentials and launches the installer automatically. No shell prompt, no manual boot gymnastics — it just starts.nmtui opens; connect, then continue. The installer re-checks until you're online.| Component | Options |
|---|---|
| Init system | runit · s6 · openrc · systemd · busybox-init · sysvinit · dinit · shepherd |
| C library | glibc · musl · uclibc-ng |
| Filesystem | ext4 · ext2 · ext3 · btrfs · xfs · zfs · f2fs · jfs · reiserfs |
| Kernel | linux · linux-lts · linux-hardened · linux-cachyos · linux-zen |
| Privilege elevation | doas · sudo · opendoas · su |
| Network tools | nmtui · networkmanager · connman · systemd-networkd |
Your choices are assembled into a make.conf, then handed to the build pipeline: scripts/build-root.sh drives Kama through toolchain bootstrap, base system, kernel, init, and tooling. The result — a rootfs matching your profile — is finalized with mkfs-root.sh and written to the target filesystem.
Walk through the installer in detail · See the requirements · Network setup details
+Honest about what installing Keru demands.
+| Requirement | Why |
|---|---|
| Working network | The ISO carries only the installer. Everything else — toolchain, kernel, init, libc, tools — is fetched and compiled during install. No network, no install. |
| A machine that runs Linux | Keru is a Linux distribution. The installer boots on x86 (and other archs as they're proven). |
| A target disk/filesystem | The system is written to the filesystem you choose during install. |
| Some patience | Everything is built from source on your machine. A from-scratch toolchain + system takes time. The compiler, not the package manager, is the bottleneck. |
| A willingness to choose | Keru's only ask is that you form an opinion about init, libc, filesystem, kernel, and tooling. Defaults exist; the decisions are still yours. |
At the first installable release (0.1), the network path is straightforward: wired Ethernet via DHCP, or wireless via nmtui, both handled from inside the installer. See the network setup flow.
The installer reaches source tarballs (via a mirror such as mirror.keru.org, with upstream as fallback), pulls recipes from the recipe repository, and builds. The heavy lifting is the compiler on your CPU — which is exactly the point of a source-only, from-scratch distribution.
Every screen, in order, with the logic behind it.
+The live init starts installer/install.sh automatically on the console. If the installer ever exits (say you decline to build), it drops you into an emergency shell rather than stranding you.
Because the ISO carries only the installer, connectivity is checked first. The probe hits a few hosts (1.1.1.1, github.com, mirror.keru.org) with ping; if ping isn't there, it falls back to a TCP connect via nc.
[ keru ] network: connected ← online, straight to choices +or, if offline: +[ keru ] warning: network: not connected +Connect to the network now (runs nmtui)? [Y/n] y +(nmtui opens; you connect; press ok) +[ keru ] network: connected+
If you press n at the prompt, the installer exits with a network connection is required to install Keru. If you run nmtui and don't actually connect, the loop simply asks again — it never fakes success.
Each swappable is presented as a numbered menu. Pressing enter keeps the default; typing a number picks the option.
+ +[ keru ] Keru OS — craft your system +== Init system == + 1) runit + 2) s6 + 3) openrc + 4) systemd + 5) busybox-init + 6) sysvinit + 7) dinit + 8) shepherd +Select [runit]:+
The same pattern repeats for C library, filesystem, kernel, privilege elevation, and network tools.
+ +After the last pick, known-risky combinations are flagged. This is a warning, never a block — the philosophy of stable-on-what's-offered, never-lock-you-out.
+ +[ keru ] warning: uclibc-ng + runit: not yet proven to build and boot together +[ keru ] warning: this combination is unstable. Keru won't stop you — build at your own risk.+
Your selections are written to a profile and shown back to you before anything builds:
+ +[ keru ] writing /tmp/keru/make.conf
+[ keru ] profile complete:
+# Generated by keru-install — hand-tune then rebuild if you like.
+INIT=runit
+LIBC=glibc
+TARGET_FS=btrfs
+KERNEL=linux
+SUDO=doas
+NET=nmtui
+LICENSE_ACCEPT=(*)
+
+Build now? [y/N] y
+ Confirming hands the profile to the build pipeline, which runs in three stages:
+binutils, gcc, your chosen libc, then the toolchain package. This is the from-scratch toolchain.BASE_PACKAGES set from your make.conf.mkfs-root.sh writes the chosen filesystem to the target root./tmp/keru/root matching your profile, ready to boot. Fixed at first boot — the system you designed.The package manager runs recipes. Here's what a recipe is.
+A Kama recipe is a plain shell script. It declares metadata and defines build steps. There is no DSL to learn beyond shell itself — which is the point. The recipe repository (kama-packages) contains one file per package, and each one is readable top to bottom.
+ +The key fields:
+| Field | Meaning |
|---|---|
name | Package name; used for the stage and cache paths. |
version | The release version, typically embedded in the url. |
url | Upstream source tarball (mirror-then-upstream on fetch). |
deps | Array of build-time dependencies, built then purged. |
build() | Runs in the extracted source dir — configure & compile. |
install() | Installs into the package's stage dir (DESTDIR). |
Recipes can stay deliberately simple or take full control:
+build() / install() sugar above. Great for "configure, make, make install" packages.pkg_build(), pkg_install(), custom pkg_fetch(), and a pkg_post() hook. For packages that need a hand.Kama maps the easy tier onto the advanced one when the advanced forms aren't defined, so simple recipes stay simple and complex ones stay powerful.
+ +Building installs into a per-package stage dir, not the live root. That's how kama can assemble a complete system in $ROOT — the installer's whole trick — without ever touching the tree being built. The install step copies the staged dir into $ROOT.
Kama locates a recipe by trying PKGDIR/<pkg>/PKGBUILD, then PKGDIR/<pkg>.sh, then PKGDIR/<pkg>/*.sh. Naming a recipe file <pkg>.sh is the common case.
Three small pieces, each with one job.
+Keru splits its world into three repositories so each stays small and legible. The package side of that is:
+ +| Repo | Holds | Keeps |
|---|---|---|
| kama | The manager — the kama entry point and lib/kama.sh core. | The code. |
| kama-packages | The recipe repository — one .sh per package. | The knowledge. |
| KeruOS | The OS: installer, profile, build pipeline, live init, website. | The orchestration. |
kama next to kama-packages next to KeruOS), and every path is overridable via KAMA_DIR / PKGS_DIR.The installer is the conductor: it writes your make.conf, then calls the build pipeline, which runs kama over recipes to produce exactly the system you chose.
The whole command surface, in one place.
+Kama's commands are few on purpose. Here's the complete set:
+ +| Command | What it does |
|---|---|
kama fetch <pkg> | Download and extract source for a package into the cache. |
kama build <pkg> | Stage-build one package (configure/make) into its stage dir. |
kama install <pkg> | Build + install a package into $ROOT (staging-aware). |
kama make <pkg> | High-level: fetch deps, build, install, then purge temp deps. |
kama purge [pkg ...] | Remove temp build-time deps after a successful install. |
kama info <pkg> | Show a recipe's metadata (name, version, url, deps). |
kama help | Print the command reference. |
kama make is the command that ties it together. For a package with dependencies it walks through:
[ kama ] building temp deps for firefox: rust gtk3 + ... fetch, build, install each temp dep ... +[ kama ] building firefox + ... stage build + install into $ROOT ... +[ kama ] purging temp deps for firefox: rust gtk3+
Kama reads a few things to know where to work:
+| Variable | Default |
|---|---|
PKGDIR | The recipe repo (kama-packages, sibling by default). |
MAKE_CONF | /etc/kama/make.conf — profile settings, if present. |
ROOT | /tmp/keru/root — where installed files go. |
CACHEDIR | /var/cache/kama — source, download, and stage dirs. |
PURGE_TEMP_DEPS | 1 — whether temp deps are purged after building. |
SOURCE_MIRROR before upstream, so the org mirror (e.g. mirror.keru.org) can carry the load.home / kama
+Keru's package manager, deliberately small.
+ 窯 +Kama (窯, "kiln") is Keru's package manager. It's a pure-shell script of roughly 225 lines that builds every package from source by running the commands in a recipe. It holds no opinions — matching the distro that ships it. It reads a make.conf, runs recipe commands, and gets out of the way.
Kama doesn't track installed files in a manifest db. It stages, installs, and moves on.
Dependencies come from the recipe's deps[] array — explicit, not discovered.
The whole manager is a script. Legible end to end; every decision is something you can read.
Builds into a per-package stage dir, then copies into $ROOT — never smears the live tree.
Build-time-only dependencies are fetched, built, installed, and purged after use — they never accumulate.
Targets $ROOT, so it can assemble a full system in a staging root — exactly what the installer needs.
Kama embodies Keru's central bet: package managers became more complex than the packages they manage. A resolver, a database, a binary format, a compiled daemon — none of that is needed to honestly manage a source-built system. What's needed is a script that faithfully runs what a recipe says, so the user can read any decision it makes.
+ +"A package manager doesn't need a resolver to be honest. It needs to be legible — you can read every decision it makes, because every decision is a script or a line in make.conf you can see and change."+ +
Kama lives in its own repo, alongside the recipe repository — two small pieces that Keru's installer drives together.
+ +home / swappables / kernels
+The spine of your machine.
+Keru is a Linux distribution — but "Linux" is a family, and the kernel is genuinely a choice: freshness vs stability, hardening vs performance, general-purpose vs tuned. Keru ships the choice, not the verdict.
+The default. Stock mainline — the broad, well-trodden baseline that matches the ecosystem.
The long-term-supported line. Slower-moving, security-patched, built for stability and long installs.
Hardening patches on top of the kernel — hardened allocator, stronger exploit mitigations.
A performance-tuned kernel with scheduler and allocator tweaks; built for responsiveness.
Community kernel focused on desktop and multimedia performance — faster, more adventurous.
To be clear about the scope: the freedom here is within Linux — which Linux kernel, not whether to leave the family. Keru composes everything above the kernel however you like; the kernel itself has a well-tested set of variants to pick from. More on what Keru's freedom does and doesn't cover.
+ +Stage 2 of the build compiles the exact kernel you chose and wires your init to boot it. The kernel, the init, and everything else is one coherent profile — nothing prebaked, nothing to fight.
+ +home / swappables / libcs
+The foundation under everything that runs.
+Every C program on your system links against a C library. It's the floor under userspace: malloc, printf, thread primitives, the syscall wrappers, all of it. Keru lets you choose which floor the rest of your system stands on.
The default, and the most compatible. Maximal feature set, broadest software support, the ecosystem baseline.
Small, fast, clean implementation. MIT-licensed, statically-friendly, famous for strict correctness and small binaries.
The maintained fork of uClibc — designed for embedded and minimal systems, tiny footprint, configurable.
Binary distributions can't really offer this — a prebuilt package set is glued to one libc. A source-only distribution can, because it compiles everything against whatever you picked. Keru carries that through: your chosen libc is bootstrapped first (in the toolchain stage), and every package is built against it.
+ +musl and uclibc-ng are early-0.1 territory. The installer's stability check currently flags uclibc-ng combinations as not-yet-proven, and musl + systemd as a known-hard pairing. Warnings — never blocks. The stance.
home / license
+AGPL-3.0, across all three repositories.
+Keru OS, kama, and kama-packages are licensed under the GNU Affero General Public License v3.0 (AGPL-3.0). The full license text ships as LICENSE in each repository.
Keru deliberately doesn't forbid forking or remixing. If another distribution wants to build on Keru — take the installer, the pipeline, the philosophy — it's welcome, under the AGPL. That's consistent with the ethos: the pieces are yours to assemble.
+ +This site lives in web/ in the KeruOS repository, and is covered by the same AGPL-3.0. The design, copy, and markup are free to reuse under it.
Everything, in one place.
+The operating system — installer, profile, build pipeline, live init, and this website.
+ + + repokama +The package manager — a ~225-line shell script. The kiln.
+ + + repokama-packages +The recipe repository — one shell file per package.
+ + + orgAstralZX +The GitHub account behind the project, and whatever else ships under it.
+ +web/ inside the KeruOS repo — clone, read, improve.Boot the ISO, and the installer starts itself.
+live/init is the init for the Keru live ISO. Its entire job is to get you into the installer as fast as possible — no shell prompt, no manual steps between boot and "craft your system."
$CONSOLE (/dev/tty1 by default) so installer messages land where you can see them./proc, /sys, /dev (devtmpfs, with tmpfs fallback), /dev/pts, /dev/shm — the essentials the installer needs.root= if given, or looks for a KERU*-labeled device to find the read-only squashfs payload; otherwise assumes the installer is on the current root.exec sh installer/install.sh — the TUI starts immediately.[ keru ] booting installer... +[ keru ] Keru OS — craft your system +== Init system == [runit] +== C library == [glibc] +== Filesystem == [ext4] +# and you're choosing — the installer opened itself.+
console= kernel param so serial consoles work too.The single source of truth for a build.
+make.conf is the file the installer writes and Kama reads. Every swappable choice in Keru lives here — it's the record of your crafted system, and hand-tuning it then rebuilding is fully supported.
profile/make.conf at the repo root — the copy above mirrors it, but the repository file is the source of truth.home / docs / build-pipeline / mkfs-root
+Finalizing the root as the filesystem you chose.
+scripts/mkfs-root.sh is the final stage of the build pipeline. Given your chosen TARGET_FS, it formats and assembles $ROOT so the disk reflects exactly the filesystem you selected at install.
The filesystem tooling is built in stage 2 from your choice — if you picked zfs, you get ZFS tools; if reiserfs, you get its (unmaintained) tooling, after a stability warning. Whatever you choose, the tooling and the format match.
+ +stage 3 is a rootfs that will boot — with the exact filesystem, kernel, init, and tools you picked. That's the whole pipeline in one line.home / install / network setup
+Connectivity is a hard requirement. The installer makes connecting easy.
+The ISO carries only the installer — there's no prebuilt base image on the disk. Your entire system (toolchain, kernel, init, libc, filesystem tooling, tools) is fetched from the network and compiled during installation. So the installer treats a connection as a hard gate: no network, no install. It won't pretend otherwise.
+ +1.1.1.1, github.com, mirror.keru.org) using ping, falling back to a TCP connect via nc if needed.[ keru ] network: connected and it moves straight to crafting your system.Connect to the network now (runs nmtui)? [Y/n].nmtui opens. Connect to your network, press okay.a network connection is required to install Keru.nmtui closes, connectivity is probed again. If you're online, you continue. If not, it asks again — it never fakes success.[ keru ] warning: network: not connected +Connect to the network now (runs nmtui)? [Y/n] y +(nmtui opens — pick your network, connect, press ok) +[ keru ] network: connected+
nmtui but never connect, the installer loops back to the prompt rather than proceeding on a "trust me, it worked" basis.home / swappables / network tools
+How your network gets managed. Your call.
+The network stack has as many opinions attached as the init system. Keru applies the same rule: pick the manager you want, and it's built into your system — nothing wireless-by-default imposed, no "just use the standard one."
+The default. Just NetworkManager's terminal user interface — connect wires and Wi-Fi without a full manager on your system.
The full NetworkManager — daemon, D-Bus API, nmcli, handles wired, wireless, VPN, and more.
Intel's connection manager — light, D-Bus bus–independent, designed for embedded and minimal systems.
systemd's network configuration daemon — declarative unit-based config, pairs with systemd/udev.
The default is nmtui — the interface, not the daemon — which is the lean choice: you get the easy nmtui workflow during install without committing yourself to running NetworkManager's daemon afterward. If you want the full manager, it's one selection away.
If you chose systemd as your init, systemd-networkd pairs naturally. If you're on runit or s6, a standalone manager (or just nmtui) fits the picture. The installer offers the pieces; you assemble them.
nmtui itself (the installer runs it when you need to connect) — independent of what you pick as your system's eventual network tool. The install-time network flow.home / news
+Progress, decisions, and the road to 0.1.
+An anti-opinionated, source-only Linux distribution where everything is swappable at install time.
+ + +Why the "you choose everything" claim is structurally real, not a slogan.
+ + +What has to exist before the first installable ISO ships — honest about the work.
+ + +The choices recorded so Keru didn't drift: shell manager, warn-not-block, sibling repos, installer-only ISO.
+ +Keru (ける) is a Linux distribution built on a deliberately unusual premise: the distro holds no opinion about your system. Not a light opinion, not a sensible default disguised as neutrality — no position at all.
+ +Most distributions are an answer to "who decides what your system is?" and the answer is usually "the maintainers, wisely." Keru's answer is different: you decide, at install time, and the distro builds exactly that.
+ +And it's source-only. The whole system — toolchain included — is compiled from original source by Kama, a package manager that's a ~225-line shell script. There are no binary packages, no opaque machinery, no background assumptions.
+ +Because "you get s6 and XFS whether you like it or not" is a fine stance for a distro that wants an opinion — but it's a burden for anyone who wants a system that is theirs. Keru's only opinion is that you have to form one. After that, it builds exactly what you chose.
+ +Read the full philosophy, or follow progress here.
+ +home / news / design decisions
+Keru is early enough that its choices are still choices, not habits — so we're recording the ones already made, and why. If a decision ever looks wrong, this is the record of what it was meant to do.
+ +Kama (~225 lines, pure shell) reads make.conf and runs recipe commands. No resolver, no database, no binary format. Rationale: legibility over machinery. The real cost of a build is the compiler, not the manager, so the manager should be boringly simple.
Keru guarantees stability on the combinations it offers, and warns (never stops) you past that. Rationale: stable-on-what's-offered keeps the promise honest, and never-lock-out keeps it faithful to the anti-opinionated ethos.
+ +KeruOS, kama, kama-packages — separate, sibling by default, each human-sized. Rationale: independent cadence, legible diffs, clear ownership. Paths are overridable via KAMA_DIR/PKGS_DIR.
No prebuilt base image on the disk. The entire system is fetched and compiled during install, with network as a hard gate. Rationale: this is what makes "everything is swappable" real rather than aspirational — power to choose comes from nothing being prebuilt.
+ +Build-time dependencies are compiled, installed, and purged after use (PURGE_TEMP_DEPS=1). Rationale: they never accumulate, so the final system reflects exactly what it needs to run — not what it needed to be built.
live/init execs install.sh directly; if it exits, an emergency shell catches you. Rationale: "boot → choose → build" should have zero friction, and a user should never be stranded.
+ +For now, the site ships inside KeruOS under web/ — plain static HTML, dark, no framework. Rationale: keep it close to the code it documents and framework-free to match the ethos; it can split out when it earns its own repo.
home / news / philosophy is the architecture
+"You choose everything" sounds like marketing. It's not — it's the shape of the code. Keru's philosophy and its architecture are the same thing, and that's the whole stability argument in miniature.
+ +Keru says every foundational component is a variable you resolve at install time. Here's how that's true at the structural level, not just in spirit:
+ +install.sh presents switches and writes them into make.conf. Init, libc, fs, kernel, sudo, net — each a line.make.conf is what the build reads. There's no hidden stack to override your choices; the choices are the input.$KERNEL, $INIT, $SUDO, $NET. Nothing else is possible.A distro is stable-for-its-idea when saying the thing and doing the thing are the same act. There's no gap for the machine to betray the pitch. If the pitch says "whatever you chose lands on the disk," the pipeline is materially incapable of doing anything else — because its only inputs are your choices.
+ +The same architecture makes the limits visible. Choice multiplies combinations, so stability is scoped to what's offered, and risky picks get warned, not blocked — the warn-not-block stance. That's another place the philosophy and the structure agree: the installer tells you the truth because the design has no way to hide it.
+ +Read more in the philosophy.
+The first installable release, 0.1, ships as a bootable ISO. No source builds for the user, no manual tooling — you boot it, the installer starts itself, you choose, and it builds. Here's the honest list of what has to be true before that ISO exists.
+ +base, toolchain, openssh, and the tooling each swappable needs, all building against the chosen libc.nmtui handoff, re-check loop — the hard requirement handled gracefully.Right now the design is public, the repos are live, and this site documents it all — but nothing has booted on hardware yet. The gap between "the architecture is sound" and "0.1 exists" is exactly the work in this roadmap. We're not pretending it's done; we're saying plainly what remains.
+ +home / philosophy
+The governing principle, in plain terms.
+The OS is a choice, not a conclusion.+ +
Most distros ship a decision someone else already made for you — a default init, a default libc, a default filesystem. You inherit it and live with it. Keru refuses that premise. Every foundational component is a variable you resolve at install time, not a fixed value baked into the distribution. Every init, every libc, every filesystem, every kernel, every privilege-elevation tool — all selectable, none forced.
+ +Keru is not opinionated. It is anti-opinionated. An opinionated distro picks a stack and defends it — "you get s6 and XFS whether you like it or not." Keru is the direct rejection of that. It holds no opinion about which init, libc, filesystem, or daemon you should run, because that decision belongs to you, not to the distribution.
+ +The distro's only opinion is that you have to form one. After that, it shuts up and builds exactly what you chose.
+ +The install medium carries nothing but the installer. There is no prebuilt base image, no hidden bloat, no background assumptions. You pick your system, Keru fetches it and compiles it from source, and the disk reflects exactly that and nothing more. What gets built is defined by what you chose — not by what maintainers decided you should have.
+ +This is the deliberate bet, and the thing that separates Keru from a Gentoo skin. The package manager, Kama, is a shell script. It reads a make.conf and runs recipe commands. No dependency solver. No package database. No compiled manager machinery.
"Sure, the package manager is in shell, and that compromises performance — but it's still faster than many package managers people actually use, and the real cost of a build is the compiler, not the meta-machinery around it."+ +
The dependency model is AUR-style ephemeral: build tools are fetched, compiled, and removed once they've served, so they never accumulate. The richness lives in the recipes and the profile, not in the machinery. Keru is the position that package managers became more complex than the packages they manage, and that the simple version is the right one.
+ +"A package manager doesn't need a resolver to be honest. It needs to be legible — you can read every decision it makes, because every decision is a script or a line in make.conf you can see and change."+ +
Building every init, every libc, every filesystem from source at install time requires a working network connection, and the installer is honest about that: connectivity is a hard gate, and network setup happens inside the installer. This is what makes "everything is swappable" real rather than aspirational. The power to choose anything comes from the fact that nothing is prebuilt — you fetch exactly the parts you picked.
+ +"You give up the convenience of a prebuilt system so the system you get is exactly the one you designed. Speed-to-install is traded for fit-to-request. If you want fast and prebaked, a binary distro is right there. If you want your machine, this is the one."+ +
Keru's promise is that the system won't break — on the combinations it offers you. That's a bounded promise, enforced by curation, and it never locks you out. You're warned, never blocked. Read the stability stance in full.
+ +Keru's lineage ran from TOML packages to a 50-line build DSL, then to plain shell. And from opinionated dogma — "you get s6 and XFS whether you like it or not" — to anti-opinionated anything-goes. Keru keeps the from-scratch purity while rejecting the fixed dogmas outright.
+ +"We don't tell you which init to worship or which filesystem to trust. We tell you that you have to choose — and then we build exactly that."+ +
The philosophy in one line:
+A system should be exactly what you chose it to be — selected at install, built from source, nothing forced and nothing you didn't ask for.+ +
And in two words: anti-opinionated by design.
+ +Deeper: what anti-opinionated actually costs and grants · The ける ethos
+home / privacy
+Short version: there's nothing to invade.
+When 0.1 ships as an ISO, downloading it is a plain file fetch from the public mirror. Nothing is recorded beyond what your server logs necessarily keep.
+ +home / swappables / privilege elevation
+How you become root. Your choice.
+Even "sudo" isn't sacred in Keru. How you elevate privileges is a swappable — the question of which su-style tool runs your privileged commands is settled by you, at install, alongside everything else.
The default. OpenBSD's elegant, minimal replacement for sudo — small config, fewer lines, no surprise policies.
The familiar heavyweight. Fine-grained policies (sudoers), broad ecosystem familiarity.
A portable, independently-maintained doas implementation for Linux — the doas philosophy with a maintained port.
The classic. No added abstraction — switch user and run what you need, as basic as it gets.
Privilege elevation touches everything an admin does, and it's usually a foregone conclusion: "you get sudo." Keru treats it as what it is — a tool with tradeoffs — and lets you pick the flavor. If you believe in two-line configs, doas. If you need sudoers granularity, sudo. If you want zero abstraction, su.
Whichever you choose gets built in stage 2 as part of your profile, alongside your kernel and init. Nothing preinstalled, nothing assumed.
+ +doas is the default because two lines of config beats two hundred. But it's a default, not a dogma — swap it freely.The contract between "what you chose" and "what gets built."
+Keru's profile system is the hand-off between your decisions and the build. It's a small, open design:
+ +installer/install.sh) walks each swappable and records your picks.make.conf — plain, readable, human-editable.scripts/build-root.sh sources the profile and drives Kama with those exact settings.| Layer | What it holds |
|---|---|
| Swappables | INIT, LIBC, TARGET_FS, KERNEL, SUDO, NET. |
| Base set | BASE_PACKAGES — what every system gets (base toolchain openssh). |
| System config | LOCALE, TIMEZONE, KEYMAP. |
| Build env | CFLAGS, CXXFLAGS, LDFLAGS, JOBS, MAKEFLAGS. |
| Mirrors & cache | SOURCE_MIRROR, ROOT, CACHEDIR. |
| Kama behavior | PURGE_TEMP_DEPS, FAIL_FAST. |
The installer is convenient, not precious. The profile it writes is just a text file — change INIT=s6, tweak CFLAGS, add a package to BASE_PACKAGES, and rebuild. The "craft your system" ethos extends past install into the profile itself.
make.conf is the full description of the system. Read, edit, rebuild.The spec for kama packages.
+A recipe is a plain POSIX shell script describing how to compile and install one piece of software. The syntax splits into two tiers:
+ +build and install, done. Covers ~90% of packages (autotools/cmake/meson).In both tiers, Kama sources the recipe and runs the functions you define.
+ +That's it. Kama supplies the conventional pkg_fetch (download + extract — auto-detects .tar.xz/.gz/.bz2/.zip, strips the top directory) and pkg_clean.
| Field | Purpose |
|---|---|
name | Package name. Required. |
version | Release version. Required for fetch. |
url | Upstream source (or list). |
deps | Build-time dependencies — compiled, installed, then purged (AUR-style). |
runtime_deps | Dependencies that stay installed. |
license | SPDX license identifiers. |
provides | Capabilities this package provides (virtuals). |
conflicts | Mutual exclusions. |
arch | Architecture allow-list; empty means any. |
noextract | URLs downloaded but not auto-extracted. |
| Function | Role |
|---|---|
build() | Configure + compile, run in the extracted source dir. |
install() | Install into the staging dir ($pkgdir/DESTDIR), not the live root. |
pkg_fetch() | Override download/extract (can call default_fetch). |
pkg_clean() | Override source cleanup. |
pkg_post() | Post-install hook, called after staging. |
pkg_split() | Optional splitting of staged output into subpackages. |
docs/recipe-format.md. The web version mirrors it; the canonical source is the repository.home / sitemap
+Every page on this site.
+Total: 32 pages, all served from web/ in the KeruOS repo — plain static HTML, no framework, dark, with a shared nav/footer injected at runtime.
home / stability
+Guaranteed on what's offered. Never enforced on you.
+Keru's definition of stable is direct: the system won't break. But that promise is only honest if it's scoped. Keru guarantees it on the combinations it offers you.
+ +That's what it means for the installer to offer a choice in the first place: each option in install.sh is one Keru has proven builds and boots. The offered set is curated so that it doesn't break. Choice multiplies the test surface — six inits, four libcs, seven filesystems, five kernels, and more produce well over a thousand possible systems. Guaranteeing every one of them is only honest if it's enforced by curation: Keru offers what works.
If you pick something that isn't yet proven — a libc and init never tested together, an unmaintained filesystem, an exotic kernel pair — Keru does not stop you. It warns you the combination is unstable and lets you proceed.
+ +"Stability is a guarantee about what we offer, not a jail around the edge of it. If you want to push into the unproven, we tell you the truth and get out of your way."+ +
The full definition, in one line:
+ +The system won't break for any choice Keru offers you; for anything beyond that, Keru warns and steps aside — you stay in control, never blocked.+ +
The installer runs a stability check after your selections. Known-risky combinations are flagged before anything is written:
+Some of the pairs Keru currently warns about:
+| Combination | Why it's flagged |
|---|---|
| uclibc-ng + anything | Pre-0.1, not yet proven to build and boot end to end. |
| musl + systemd | Systemd and musl are a known-hard pairing. |
| zfs as root fs | Needs kernel module + ZFS userspace; not yet proven. |
| reiserfs | Unmaintained; no stable future. |
make.conf builds the same system."Extremely stable" and "everything is swappable" pull in opposite directions. Most famously-stable distros (Debian) gain stability by shrinking choice. Keru's stability therefore isn't "fewest things possible" — it's "whatever you chose, it builds and boots predictably, and Keru never hides a risk from you."
+ + +home / swappables
+Every foundational component, yours to choose at install time.
+Keru's differentiator is one sentence: nothing is fixed, nothing you didn't ask for is forced on you. The installer presents each foundational component as a flat, open choice, and the system that boots is assembled from exactly the ones you picked.
+ +This is what distro arguments get settled with, resolved ahead of time by you instead of argued forever by maintainers. Runit vs systemd, glibc vs musl, ext4 vs btrfs, vanilla vs hardened kernel — all of it becomes your decision, made once, at install.
+Who brings your system up at boot. runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd.
+ libcC libraryThe foundation under everything that runs. glibc, musl, uclibc-ng.
+ fsFilesystemThe shape of your disk. ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap.
+ kernelKernelThe spine of the machine. linux, linux-lts, linux-hardened, linux-cachyos, linux-zen.
+ privPrivilege elevationHow you elevate. doas, sudo, opendoas, su.
+ netNetwork toolsHow the network is managed. networkmanager, connman, systemd-networkd, nmtui alone.
+Kernel parameters, locale, clock, and keymap are all configurable too — surfaced through make.conf, the profile that your choices produce. The swappables aren't a fixed list; they're a stance. Read the make.conf reference.
Because choice multiplies the surface, Keru is stable on the combinations it offers, and warns (never blocks) beyond that. How that works.
+