add website and GitHub Pages deployment

This commit is contained in:
Astral
2026-09-01 11:23:34 +02:00
parent cb1da62339
commit da28f784a8
48 changed files with 3392 additions and 0 deletions
View File
+75
View File
@@ -0,0 +1,75 @@
<div class="wrap">
<div>
<h4>Keru OS</h4>
<ul>
<li><a href="./index.html">Home</a></li>
<li><a href="./about.html">About</a></li>
<li><a href="./philosophy.html">Philosophy</a></li>
<li><a href="./ethos.html">Ethos</a></li>
<li><a href="./stability.html">Stability</a></li>
</ul>
</div>
<div>
<h4>Install</h4>
<ul>
<li><a href="./install.html">Install Keru</a></li>
<li><a href="./installer-walkthrough.html">Installer walkthrough</a></li>
<li><a href="./installation-requirements.html">Requirements</a></li>
<li><a href="./network-setup.html">Network setup</a></li>
</ul>
</div>
<div>
<h4>Swappables</h4>
<ul>
<li><a href="./swappables.html">All choices</a></li>
<li><a href="./inits.html">Init systems</a></li>
<li><a href="./libcs.html">C libraries</a></li>
<li><a href="./filesystems.html">Filesystems</a></li>
<li><a href="./kernels.html">Kernels</a></li>
<li><a href="./privilege-elevation.html">Privilege elevation</a></li>
</ul>
</div>
<div>
<h4>Kama</h4>
<ul>
<li><a href="./kama.html">Package manager</a></li>
<li><a href="./kama-usage.html">Usage</a></li>
<li><a href="./kama-recipes.html">Recipes</a></li>
<li><a href="./kama-repos.html">Repos</a></li>
</ul>
</div>
<div>
<h4>Docs</h4>
<ul>
<li><a href="./docs.html">Docs home</a></li>
<li><a href="./make-conf.html">make.conf</a></li>
<li><a href="./recipe-format.html">Recipe format</a></li>
<li><a href="./build-pipeline.html">Build pipeline</a></li>
<li><a href="./live-init.html">Live init</a></li>
</ul>
</div>
<div>
<h4>Community</h4>
<ul>
<li><a href="./community.html">Community</a></li>
<li><a href="./contribute.html">Contribute</a></li>
<li><a href="./faq.html">FAQ</a></li>
<li><a href="./contact.html">Contact</a></li>
<li><a href="./links.html">Links</a></li>
<li><a href="./news.html">News</a></li>
</ul>
</div>
<div>
<h4>Legal</h4>
<ul>
<li><a href="./license.html">License</a></li>
<li><a href="./privacy.html">Privacy</a></li>
<li><a href="./credits.html">Credits</a></li>
<li><a href="./sitemap.html">Sitemap</a></li>
</ul>
</div>
</div>
<p class="foot">
ける・けいとうてき — craft your system.<br>
Keru OS is licensed under <span class="marks">AGPL-3.0</span>. No opinion, no telemetry, no bloat.
</p>
+10
View File
@@ -0,0 +1,10 @@
<a class="brand" href="./index.html"><span class="kanji">ける</span> Keru OS</a>
<a class="navlink" href="./index.html">Home</a>
<a class="navlink" href="./philosophy.html">Philosophy</a>
<a class="navlink" href="./swappables.html">Swappables</a>
<a class="navlink" href="./kama.html">Kama</a>
<a class="navlink" href="./install.html">Install</a>
<a class="navlink" href="./docs.html">Docs</a>
<a class="navlink" href="./news.html">News</a>
<a class="navlink" href="./community.html">Community</a>
<a class="menu-toggle" href="./sitemap.html">☰</a>
+57
View File
@@ -0,0 +1,57 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>About — Keru OS</title>
<meta name="description" content="Keru OS is an independent, source-only Linux distribution. This repo is the operating system itself — installer, profile system, and build pipeline.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / about</p>
<h1>About Keru OS</h1>
<p>An independent, source-only Linux distribution built around one idea: you don't install a system, you craft one.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>What Keru is</h3>
<p>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.</p>
<p>The name comes from <strong>ける・けいとうてき</strong> (keru keitō-teki), roughly "craft your system." It's the whole point stated as a phrase.</p>
<h3>The three repositories</h3>
<p>Keru is deliberately split into three pieces so each stays small and legible:</p>
<table>
<tr><th>Repo</th><th>What it holds</th></tr>
<tr><td>KeruOS</td><td>This repo — the installer, profile system, build pipeline, and website.</td></tr>
<tr><td>kama</td><td>The package manager. A ~225-line shell script. The "kiln" that fires recipes.</td></tr>
<tr><td>kama-packages</td><td>The recipe repository — plain shell scripts that describe how to build each package.</td></tr>
</table>
<h3>Where it sits</h3>
<p>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.</p>
<h3>Status</h3>
<p>Keru is in active development. The first installable release, <strong>0.1</strong>, will ship as a bootable ISO. Until then, the repositories document the design, philosophy, and the build pipeline it's all wired through.</p>
<div class="callout">
<strong>Anti-opinionated by design.</strong> Read the full reasoning in the <a href="philosophy.html">philosophy</a>.
</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+66
View File
@@ -0,0 +1,66 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Anti-opinionated — Keru OS</title>
<meta name="description" content="What it really means for a distribution to be anti-opinionated, what it costs, and what it grants.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="philosophy.html">philosophy</a> / anti-opinionated</p>
<h1>Anti-opinionated</h1>
<p>The core stance, and what it actually grants and costs you.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>Reading the room</h3>
<p>Every Linux distribution is an answer to the same question: <em>who decides what your system is?</em> 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.</p>
<p>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.</p>
<h3>The anti-opinionated answer</h3>
<p>Keru answers differently: <strong>the distribution holds no position.</strong> Not a middle position — <em>no</em> position. It doesn't ship a "best" init or a "recommended" filesystem, because that recommendation is the very thing Keru exists to remove.</p>
<p>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.</p>
<h3>What it grants</h3>
<ul class="features">
<li><strong>No inherited stack.</strong> You never fight a default you never agreed to. What's on the disk is what you chose, full stop.</li>
<li><strong>Every system is the same system.</strong> "Your" configuration isn't a deviation from Keru's ideal — it <em>is</em> Keru. There's no blessed path and no lesser path.</li>
<li><strong>The distro never defends a mistake.</strong> An opinionated distro inherits the burden of defending its picks forever. Keru inherits nothing to defend.</li>
<li><strong>Legibility.</strong> Because there's no position to paper over, every choice is visible in <code>make.conf</code> — readable, editable, rebuildable.</li>
</ul>
<h3>What it costs</h3>
<ul class="features">
<li><strong>No hand-holding.</strong> There's no "the way you install Keru is the way you install Keru" comfort. You carry the decisions.</li>
<li><strong>You must form an opinion.</strong> The installer's only requirement is that you have one. For people who specifically want that, it's freedom; it's not for everyone.</li>
<li><strong>More surface to keep stable.</strong> Supporting many inits, libcs, and filesystems means more combinations to honor — which is why the <a href="stability.html">stability promise is scoped honestly</a>.</li>
</ul>
<h3>Not GNU/Hurd, not a meta-OS</h3>
<p>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 <em>userspace and configuration</em> — init, libc, filesystem, kernel (within Linux), tooling. It's the meta-distribution stance: choice and composition over a fixed opinionated stack.</p>
<h3>In one line</h3>
<blockquote>An opinionated distro tells you what to use. Keru tells you that you have to choose — and then builds exactly what you pick.</blockquote>
<p><a href="philosophy.html">← Back to the philosophy</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+433
View File
@@ -0,0 +1,433 @@
/* Keru OS website — dark, modern, animated.
Reference: Gentoo's confident tech look, modernized. */
@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700;800&family=JetBrains+Mono:wght@400;500;700&display=swap');
:root {
--bg: #0a0e14; /* near-black blue */
--bg-2: #0f1520; /* raised surface */
--bg-3: #161e2e; /* cards */
--border: #22304a;
--text: #d7e0ee;
--text-dim: #8b9bb4;
--text-bright: #ffffff;
--accent: #8b5cf6; /* keru violet */
--accent-2: #22d3ee; /* cyan secondary */
--accent-3: #34d399; /* green success */
--warn: #f59e0b; /* amber */
--danger: #ef4444;
--code-bg: #0d1220;
--mono: 'JetBrains Mono', ui-monospace, monospace;
--sans: 'Inter', system-ui, -apple-system, sans-serif;
--grad: linear-gradient(135deg, var(--accent), var(--accent-2));
--shadow: 0 8px 30px rgba(0,0,0,.4);
--radius: 12px;
--nav-h: 64px;
}
* { margin: 0; padding: 0; box-sizing: border-box; }
html { scroll-behavior: smooth; }
body {
background: var(--bg);
color: var(--text);
font-family: var(--sans);
line-height: 1.65;
-webkit-font-smoothing: antialiased;
overflow-x: hidden;
}
/* subtle animated grid backdrop */
body::before {
content: "";
position: fixed;
inset: 0;
z-index: -1;
background:
radial-gradient(circle at 20% -10%, rgba(139,92,246,.12), transparent 45%),
radial-gradient(circle at 90% 10%, rgba(34,211,238,.08), transparent 40%),
repeating-linear-gradient(0deg, transparent 0 39px, rgba(255,255,255,.02) 39px 40px);
pointer-events: none;
}
a { color: var(--accent-2); text-decoration: none; }
a:hover { text-decoration: underline; }
::selection { background: var(--accent); color: #fff; }
/* ---------- top nav ---------- */
nav.top {
position: sticky;
top: 0;
z-index: 100;
height: var(--nav-h);
background: rgba(10,14,20,.82);
backdrop-filter: blur(12px);
border-bottom: 1px solid var(--border);
display: flex;
align-items: center;
padding: 0 28px;
gap: 8px;
}
.brand {
font-family: var(--mono);
font-weight: 700;
color: var(--text-bright);
font-size: 1.05rem;
letter-spacing: .02em;
margin-right: auto;
display: flex;
align-items: center;
gap: 8px;
}
.brand .kanji { color: var(--accent); }
.brand:hover { text-decoration: none; }
nav.top a.navlink {
color: var(--text-dim);
font-size: .92rem;
font-weight: 500;
padding: 6px 10px;
border-radius: 6px;
transition: color .15s, background .15s;
}
nav.top a.navlink:hover { color: var(--text-bright); background: var(--bg-3); text-decoration: none; }
.menu-toggle { display: none; }
/* ---------- hero ---------- */
.hero {
padding: 96px 28px 64px;
text-align: center;
animation: fadeUp .7s ease both;
}
.kicker {
display: inline-flex;
align-items: center;
gap: 8px;
font-family: var(--mono);
color: var(--accent-2);
border: 1px solid var(--border);
background: var(--bg-2);
padding: 4px 12px;
border-radius: 999px;
font-size: .8rem;
letter-spacing: .08em;
text-transform: uppercase;
}
.kicker .dot {
width: 7px; height: 7px; border-radius: 50%;
background: var(--accent-3);
animation: pulse 2s infinite;
}
.hero h1 {
font-size: clamp(2.6rem, 6vw, 4.6rem);
font-weight: 800;
line-height: 1.05;
color: var(--text-bright);
margin: 22px auto 18px;
max-width: 900px;
letter-spacing: -.02em;
}
.hero h1 .grad {
background: var(--grad);
-webkit-background-clip: text;
background-clip: text;
color: transparent;
}
.hero p.sub {
max-width: 640px;
margin: 0 auto 30px;
color: var(--text-dim);
font-size: 1.12rem;
}
.cta-row { display: flex; gap: 14px; justify-content: center; flex-wrap: wrap; }
.btn {
display: inline-flex;
align-items: center;
gap: 8px;
font-family: var(--mono);
font-weight: 500;
padding: 12px 22px;
border-radius: 10px;
font-size: .95rem;
transition: transform .15s, box-shadow .15s, background .15s;
}
.btn:hover { text-decoration: none; transform: translateY(-2px); }
.btn-primary { background: var(--grad); color: #0a0e14; box-shadow: 0 4px 20px rgba(139,92,246,.4); }
.btn-primary:hover { box-shadow: 0 8px 28px rgba(139,92,246,.55); }
.btn-ghost { background: var(--bg-3); color: var(--text); border: 1px solid var(--border); }
.btn-ghost:hover { background: var(--bg-2); }
/* ---------- sections ---------- */
section { padding: 56px 28px; }
.wrap { max-width: 1080px; margin: 0 auto; }
.section-title {
font-family: var(--mono);
text-transform: uppercase;
letter-spacing: .12em;
font-size: .82rem;
color: var(--accent-2);
margin-bottom: 10px;
}
h2.head { font-size: clamp(1.6rem, 3.5vw, 2.4rem); color: var(--text-bright); font-weight: 700; margin-bottom: 14px; letter-spacing: -.01em; }
.lead { color: var(--text-dim); font-size: 1.05rem; max-width: 720px; margin-bottom: 30px; }
.grid { display: grid; gap: 22px; }
.grid-2 { grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); }
.grid-3 { grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); }
.grid-4 { grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); }
.card {
background: var(--bg-3);
border: 1px solid var(--border);
border-radius: var(--radius);
padding: 22px;
transition: transform .2s, border-color .2s, box-shadow .2s;
animation: fadeUp .6s ease both;
}
.card:hover { transform: translateY(-4px); border-color: var(--accent); box-shadow: var(--shadow); }
.card.h { font-family: var(--mono); font-size: 1.05rem; color: var(--text-bright); margin-bottom: 8px; }
.card p { color: var(--text-dim); font-size: .95rem; }
.card .num {
font-family: var(--mono);
font-size: .75rem;
color: var(--accent-2);
border: 1px solid var(--border);
padding: 2px 8px;
border-radius: 6px;
display: inline-block;
margin-bottom: 10px;
}
/* ---------- terminal/snippet ---------- */
.terminal {
background: #05080d;
border: 1px solid var(--border);
border-radius: var(--radius);
overflow: hidden;
box-shadow: var(--shadow);
text-align: left;
margin: 0 auto;
max-width: 640px;
}
.terminal .tbar {
background: var(--bg-2);
padding: 10px 14px;
display: flex;
gap: 6px;
align-items: center;
border-bottom: 1px solid var(--border);
}
.terminal .tbar span.dot { width: 11px; height: 11px; border-radius: 50%; display: inline-block; }
.terminal .tbar .r { background: var(--danger); }
.terminal .tbar .y { background: var(--warn); }
.terminal .tbar .g { background: var(--accent-3); }
.terminal .tbar .t { margin-left: 8px; font-family: var(--mono); font-size: .75rem; color: var(--text-dim); }
.terminal pre {
padding: 18px;
overflow-x: auto;
font-family: var(--mono);
font-size: .85rem;
line-height: 1.7;
color: var(--text);
}
.terminal .c { color: var(--accent-2); }
.terminal .k { color: var(--accent-3); }
.terminal .p { color: var(--text-dim); }
/* ---------- code blocks ---------- */
pre, code, kbd {
font-family: var(--mono);
}
.code-block {
background: var(--code-bg);
border: 1px solid var(--border);
border-radius: 10px;
padding: 18px;
overflow-x: auto;
margin: 18px 0;
font-size: .85rem;
line-height: 1.7;
color: var(--text);
}
code:not(.code-block) {
background: var(--bg-3);
border: 1px solid var(--border);
border-radius: 5px;
padding: 2px 6px;
font-size: .85em;
color: var(--accent-2);
}
kbd {
background: var(--bg-3);
border: 1px solid var(--border);
border-bottom-width: 2px;
border-radius: 5px;
padding: 1px 6px;
font-size: .8em;
}
/* ---------- lists / prose ---------- */
.prose { max-width: 760px; margin: 0 auto; }
.prose h3 {
color: var(--text-bright);
font-size: 1.25rem;
margin: 34px 0 10px;
font-weight: 700;
}
.prose h4 { color: var(--accent-2); margin: 22px 0 8px; font-size: 1.05rem; }
.prose p { margin: 12px 0; color: var(--text); }
.prose ul, .prose ol { margin: 12px 0 12px 24px; }
.prose li { margin: 6px 0; color: var(--text); }
.prose li::marker { color: var(--accent); }
.prose blockquote {
border-left: 3px solid var(--accent);
background: var(--bg-2);
padding: 14px 18px;
border-radius: 0 8px 8px 0;
margin: 18px 0;
color: var(--text-dim);
}
.prose blockquote strong { color: var(--text-bright); }
.prose hr { border: none; border-top: 1px solid var(--border); margin: 30px 0; }
table { border-collapse: collapse; width: 100%; margin: 18px 0; font-size: .92rem; }
th, td { border: 1px solid var(--border); padding: 9px 12px; text-align: left; }
th { background: var(--bg-2); color: var(--text-bright); font-family: var(--mono); font-size: .82rem; }
tr:nth-child(even) td { background: rgba(255,255,255,.015); }
/* tag chips */
.tag {
display: inline-block;
font-family: var(--mono);
font-size: .72rem;
letter-spacing: .05em;
text-transform: uppercase;
padding: 2px 9px;
border-radius: 999px;
border: 1px solid var(--border);
color: var(--accent-2);
margin: 2px 4px 2px 0;
}
.tag.warn { color: var(--warn); border-color: rgba(245,158,11,.4); }
.tag.danger { color: var(--danger); border-color: rgba(239,68,68,.4); }
.tag.ok { color: var(--accent-3); border-color: rgba(52,211,153,.4); }
/* pill callout */
.callout {
border: 1px solid var(--border);
border-left: 3px solid var(--accent);
background: var(--bg-2);
border-radius: 8px;
padding: 14px 18px;
margin: 18px 0;
}
.callout.warn { border-left-color: var(--warn); }
.callout.danger { border-left-color: var(--danger); }
.callout.ok { border-left-color: var(--accent-3); }
/* ---------- comparison tables / feature list ---------- */
.features { list-style: none; margin: 0; }
.features li { padding: 10px 0; border-bottom: 1px solid var(--border); display: flex; gap: 12px; }
.features li::before { content: "◆"; color: var(--accent); }
/* ---------- news ---------- */
.post-list { max-width: 820px; margin: 0 auto; }
.post-item {
display: block;
background: var(--bg-3);
border: 1px solid var(--border);
border-radius: var(--radius);
padding: 20px 24px;
margin-bottom: 16px;
transition: transform .15s, border-color .15s;
}
.post-item:hover { transform: translateX(4px); border-color: var(--accent); text-decoration: none; }
.post-item h3 { color: var(--text-bright); font-size: 1.2rem; margin-bottom: 6px; }
.post-item .meta { font-family: var(--mono); font-size: .78rem; color: var(--text-dim); margin-bottom: 6px; }
.post-item p { color: var(--text-dim); font-size: .95rem; }
/* ---------- footer ---------- */
footer {
border-top: 1px solid var(--border);
background: var(--bg-2);
padding: 40px 28px 32px;
margin-top: 40px;
}
footer .wrap { display: flex; gap: 40px; flex-wrap: wrap; justify-content: space-between; }
footer h4 { color: var(--text-bright); font-family: var(--mono); font-size: .85rem; text-transform: uppercase; letter-spacing: .1em; margin-bottom: 12px; }
footer ul { list-style: none; }
footer li { margin: 6px 0; }
footer a { color: var(--text-dim); }
footer a:hover { color: var(--text-bright); text-decoration: none; }
footer .foot {
margin-top: 30px;
padding-top: 20px;
border-top: 1px solid var(--border);
font-family: var(--mono);
font-size: .78rem;
color: var(--text-dim);
text-align: center;
}
footer .marks { font-family: var(--mono); color: var(--accent-2); }
/* ---------- animation utilities ---------- */
@keyframes fadeUp {
from { opacity: 0; transform: translateY(18px); }
to { opacity: 1; transform: translateY(0); }
}
@keyframes pulse {
0%, 100% { opacity: 1; }
50% { opacity: .35; }
}
.reveal { animation: fadeUp .7s ease both; }
.d1 { animation-delay: .1s; }
.d2 { animation-delay: .2s; }
.d3 { animation-delay: .3s; }
.d4 { animation-delay: .4s; }
/* scrolling feature ticker on landing */
.ticker {
overflow: hidden;
border-top: 1px solid var(--border);
border-bottom: 1px solid var(--border);
padding: 14px 0;
background: var(--bg-2);
white-space: nowrap;
}
.ticker-inner {
display: inline-block;
animation: ticker 30s linear infinite;
font-family: var(--mono);
color: var(--text-dim);
}
.ticker-inner span { margin: 0 28px; }
.ticker-inner b { color: var(--accent-2); }
@keyframes ticker { from { transform: translateX(0); } to { transform: translateX(-50%); } }
/* stat blocks */
.stats { display: flex; gap: 28px; flex-wrap: wrap; justify-content: center; margin: 24px 0; }
.stat { text-align: center; }
.stat .big { font-family: var(--mono); font-size: 2.4rem; font-weight: 700; color: var(--text-bright); background: var(--grad); -webkit-background-clip: text; background-clip: text; color: transparent; }
.stat .lbl { color: var(--text-dim); font-size: .85rem; }
/* page header (non-hero pages) */
.pagehead { padding: 72px 28px 32px; text-align: center; }
.pagehead h1 { color: var(--text-bright); font-size: clamp(2rem, 5vw, 3.2rem); font-weight: 800; letter-spacing: -.02em; }
.pagehead p { color: var(--text-dim); max-width: 640px; margin: 14px auto 0; }
/* breadcrumb */
.crumbs { font-family: var(--mono); font-size: .78rem; color: var(--text-dim); max-width: 760px; margin: 20px auto 0; }
.crumbs a { color: var(--accent-2); }
/* responsive */
@media (max-width: 720px) {
nav.top { padding: 0 14px; }
nav.top a.navlink { display: none; }
.menu-toggle { display: inline-flex; }
.hero { padding: 64px 18px 40px; }
section { padding: 40px 18px; }
footer .wrap { gap: 24px; }
}
+41
View File
@@ -0,0 +1,41 @@
/* Keru website — inject shared nav + footer partials.
Usage:
<nav data-nav></nav>
<footer data-footer></footer>
<script src="assets/js/include.js" data-base="."></script>
data-base is the path prefix from this page to the web root.
All links inside the injected partials are resolved against that base. */
(function () {
var base = '.';
var scripts = document.querySelectorAll('script[src*="include.js"]');
for (var i = 0; i < scripts.length; i++) {
if (scripts[i].dataset.base) base = scripts[i].dataset.base;
}
var nav = document.querySelector('[data-nav]');
var footer = document.querySelector('[data-footer]');
function fill(el, url) {
if (!el) return;
fetch(base + '/' + url)
.then(function (r) { return r.text(); })
.then(function (t) {
// resolve links/asset refs in the partial against base
var div = document.createElement('div');
div.innerHTML = t;
['a', 'link', 'script', 'img'].forEach(function (sel) {
var nodes = div.querySelectorAll(sel + '[href], ' + sel + '[src]');
for (var j = 0; j < nodes.length; j++) {
var n = nodes[j];
var attr = n.hasAttribute('href') ? 'href' : 'src';
var val = n.getAttribute(attr);
if (val && val.indexOf('./') === 0) {
n.setAttribute(attr, base + '/' + val.replace(/^\.\//, ''));
}
}
});
el.innerHTML = div.innerHTML;
})
.catch(function () { /* offline / file:// — nav/footer stay empty */ });
}
fill(nav, '_includes/nav.html');
fill(footer, '_includes/footer.html');
})();
+78
View File
@@ -0,0 +1,78 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Build pipeline — Keru OS</title>
<meta name="description" content="How build-root.sh and mkfs-root.sh turn a make.conf into a bootable rootfs, driven by Kama.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / build pipeline</p>
<h1>Build pipeline</h1>
<p>From make.conf to a bootable filesystem.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>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.</p>
<h3>The stages</h3>
<h4>Stage 0 — bootstrap the toolchain</h4>
<p><code>build-root.sh</code> boots a toolchain from nothing: <code>binutils</code>, <code>gcc</code>, your chosen <code>libc</code>, then the <code>toolchain</code> package. This is the "fully from scratch" step — the stage that separates a source distro from one that seeds binaries.</p>
<h4>Stage 1 — base system</h4>
<p>The <code>BASE_PACKAGES</code> set from your profile is built and installed into <code>$ROOT</code>. Every package compiles against the stage-0 toolchain.</p>
<h4>Stage 2 — the swappables</h4>
<p>Exactly what you chose: the kernel (<code>$KERNEL</code>), the init system (<code>$INIT</code>), your privilege-elevation tool (<code>$SUDO</code>), and your network tools (<code>$NET</code>). Nothing preselected — the picks in your make.conf are the picks that get built.</p>
<h4>Stage 3 — finalize the root</h4>
<p><code>mkfs-root.sh</code> formats and assembles the target as your chosen filesystem, producing the rootfs that will boot.</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">$ sh scripts/build-root.sh</span></div>
<pre><span class="c">[ keru ]</span> building Keru rootfs into /tmp/keru/root
<span class="c">[ keru ]</span> profile: init=runit libc=glibc fs=ext4 kernel=linux sudo=doas
<span class="c">[ keru ]</span> stage 0: bootstrap toolchain (gcc binutils glibc)
<span class="c">[ keru ]</span> stage 1: base system
<span class="c">[ keru ]</span> stage 2: kernel + init + sudo + net
<span class="c">[ keru ]</span> stage 3: finalize ext4 root
<span class="k">[ keru ] rootfs ready: /tmp/keru/root</span></pre>
</div>
<h3>The scripts</h3>
<table>
<tr><th>Script</th><th>Job</th></tr>
<tr><td><code>scripts/common.sh</code></td><td>Shared helpers; knows the sibling-repo layout (<code>KAMA_DIR</code>, <code>PKGS_DIR</code>).</td></tr>
<tr><td><code>scripts/build-root.sh</code></td><td>The orchestrator — runs the four stages above.</td></tr>
<tr><td><code>scripts/mkfs-root.sh</code></td><td>Formats the target root as the chosen filesystem.</td></tr>
</table>
<h3>Convenience entrypoints</h3>
<div class="code-block">make rootfs # sh scripts/build-root.sh
make install # sh installer/install.sh
make live-init # syntax-check live/init
make recipe-check # sh -n every recipe in kama-packages</div>
<div class="callout">The pipeline is the honest core of "from scratch": no binary base image, no opaque build tool — a shell script reading a profile and driving a shell package manager.</div>
<p><a href="mkfs-root.html">mkfs-root reference</a> · <a href="kama-repos.html">How the repos fit</a> · <a href="docs.html">← Docs</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+50
View File
@@ -0,0 +1,50 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Community — Keru OS</title>
<meta name="description" content="Join the Keru OS community: contribute, report bugs, discuss choices, and shape the distribution.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / community</p>
<h1>Community</h1>
<p>A small distribution with a clear idea, shaped by people who care about choice.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-3">
<a class="card" href="contribute.html"><span class="num">1</span><span class="h">Contribute</span><p>Write recipes, fix the installer, improve docs, or help shape the road to 0.1.</p></a>
<a class="card" href="faq.html"><span class="num">2</span><span class="h">FAQ</span><p>Straight answers to the questions everyone asks.</p></a>
<a class="card" href="contact.html"><span class="num">3</span><span class="h">Contact</span><p>GitHub issues, mailing list, and how to reach the project.</p></a>
<a class="card" href="links.html"><span class="num">4</span><span class="h">Links</span><p>The three repos, this site's source, and related reading.</p></a>
</div>
<div class="prose" style="margin-top:40px">
<h3>What the community is for</h3>
<p>Keru holds one opinion — that you should form yours. That extends to the community: the interesting conversations here are about <em>which</em> init/libc/fs combos should be proven next, <em>which</em> recipes matter, and <em>how</em> the distro stays honest at its edges.</p>
<h3>The stance carries over</h3>
<ul class="features">
<li><strong>No gatekeeping about your stack.</strong> Whatever init you run, you're a Keru user doing it right.</li>
<li><strong>Bugs are bugs.</strong> Report a broken combination and it gets curated out of the "offered" set or proven and kept — not argued about for a release.</li>
<li><strong>Small is fine.</strong> This isn't a race for the biggest community; it's a race for the most coherent one.</li>
</ul>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+69
View File
@@ -0,0 +1,69 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Contact — Keru OS</title>
<meta name="description" content="How to reach the Keru OS project: issues, mailing list, and community channels.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="community.html">community</a> / contact</p>
<h1>Contact</h1>
<p>Use issues for bugs and ideas; the list for discussion.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-2">
<div class="card">
<span class="num">preferred</span>
<span class="h">GitHub issues</span>
<p>Bugs, recipe ideas, installer feedback, combination reports. The most actionable way to reach us.</p>
<p><a href="https://github.com/AstralZX/KeruOS/issues">AstralZX/KeruOS issues</a></p>
</div>
<div class="card">
<span class="num">discussion</span>
<span class="h">Mailing list</span>
<p>Longer conversations about philosophy, design decisions, and direction. Subscribe or join the thread.</p>
<p><a href="mailto:[email protected]">[email protected]</a> (placeholder)</p>
</div>
<div class="card">
<span class="num">channel</span>
<span class="h">Matrix</span>
<p>A real-time room for early adopters and contributors.</p>
<p><a href="https://matrix.to/#/#keru:matrix.org">#keru:matrix.org</a> (placeholder)</p>
</div>
<div class="card">
<span class="num">code</span>
<span class="h">The repos</span>
<p>Everything is public. Clone it, read it, break it, report it.</p>
<p><a href="links.html">All links →</a></p>
</div>
</div>
<div class="prose" style="margin-top:40px">
<h3>Bug reports that help</h3>
<ul class="features">
<li><strong>Reproduce.</strong> The combo, the <code>make.conf</code> (if any), the failure output.</li>
<li><strong>Scope.</strong> Was it fetch, build, install, or boot? That points straight at the stage.</li>
<li><strong>Label.</strong> A broken combination gets curated out of "offered" or fixed — say which you'd rather.</li>
</ul>
<div class="callout">Small project, responsive maintainers. If you file something, expect a real answer.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+65
View File
@@ -0,0 +1,65 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Contribute — Keru OS</title>
<meta name="description" content="How to contribute to Keru OS: recipes, the installer, the package manager, docs, and the website.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="community.html">community</a> / contribute</p>
<h1>Contribute</h1>
<p>There's no gatekeeping. There's work to do.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>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.</p>
<h3>Where things live</h3>
<table>
<tr><th>Repo</th><th>You'd contribute</th></tr>
<tr><td>KeruOS</td><td>Installer, profile, scripts, live init, docs, and this website.</td></tr>
<tr><td>kama</td><td>The package manager itself — and, ideally, not much. It's meant to stay small.</td></tr>
<tr><td>kama-packages</td><td>Recipes — the highest-leverage place. Busybox, runit, and a template exist.</td></tr>
</table>
<h3>Ways to help</h3>
<ul class="features">
<li><strong>Write recipes.</strong> A <code>&lt;pkg&gt;.sh</code> in <code>kama-packages</code> is a package. Start from <code>TEMPLATE.sh</code>. <a href="recipe-format.html">The format is small.</a></li>
<li><strong>Test the toolchain bootstrap.</strong> The stage-0 build (gcc/glibc from nothing) is the riskiest seam; hands on real machines are gold.</li>
<li><strong>Sharpen the installer.</strong> Menu UX, network handling, stability checks — all open.</li>
<li><strong>Fix bugs.</strong> The road to 0.1 is literally a list of bugs between here and a booting ISO.</li>
<li><strong>Docs & site.</strong> This website lives in <code>web/</code> in the KeruOS repo — plain HTML, no framework. Improving it is plain work on plain files.</li>
</ul>
<h3>Ground rules</h3>
<ul class="features">
<li><strong>Match the ethos.</strong> Source-only, no opinion, small pieces. A PR that adds a dependency resolver to kama contradicts the project's spine.</li>
<li><strong>Stay legible.</strong> If shell can do it plainly, don't introduce machinery.</li>
<li><strong>Honesty at the edges.</strong> Unproven combinations go in with a warning, or not at all — never silently.</li>
<li><strong>AGPL-3.0.</strong> All three repos are AGPL-3.0; contributions fall under it.</li>
</ul>
<h3>Where to start</h3>
<p>Issues, recipe ideas, and bug reports live on the <a href="links.html">three repositories</a>, and discussion on the <a href="contact.html">contact channels</a>. If you're looking for a first move: pick a recipe, read <code>TEMPLATE.sh</code>, and send it.</p>
<div class="callout">A small distribution values every PR — there's no pile to get lost in. What you send is likely to matter.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+56
View File
@@ -0,0 +1,56 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Credits — Keru OS</title>
<meta name="description" content="Credits and acknowledgment for Keru OS.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / credits</p>
<h1>Credits</h1>
<p>The people, projects, and tools Keru stands on.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>Who</h3>
<p>Keru is the work of <strong>Astral</strong> (<a href="https://github.com/AstralZX">@AstralZX</a>), 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).</p>
<h3>The tradition Keru sits in</h3>
<ul class="features">
<li><strong>Gentoo</strong> — source-based purity and the profile concept that Keru carries forward.</li>
<li><strong>Nix</strong> — declarative, reproducible composition of a system from pieces.</li>
<li><strong>Bedrock Linux</strong> — the "meta-distribution" idea: a distro about choice and composition.</li>
<li><strong>OpenBSD & doas</strong> — the minimalism that Keru's default privilege tool comes from.</li>
<li><strong>The skarnet suite (s6)</strong> — clean service supervision, an option among equals here.</li>
</ul>
<h3>The free software underneath</h3>
<p>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 <code>kama-packages</code>. Credit belongs to all of them, and their licenses — not Keru's — govern those components. Keru's AGPL covers Keru's own code (<a href="license.html">see the license page</a>).</p>
<h3>This website</h3>
<ul class="features">
<li><strong>Fonts:</strong> Inter and JetBrains Mono.</li>
<li><strong>Built:</strong> hand-written HTML/CSS/JS, no framework — consistent with the project's spine.</li>
</ul>
<div class="callout">If you contributed and you're not listed, that's a bug — <a href="contact.html">say so</a> and it'll be fixed.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+42
View File
@@ -0,0 +1,42 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Docs — Keru OS</title>
<meta name="description" content="Keru documentation: make.conf, profile, recipe format, build pipeline, live init, and contributor references.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / docs</p>
<h1>Docs</h1>
<p>The reference. Everything you might open a file to check.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-2">
<a class="card" href="make-conf.html"><span class="num">reference</span><span class="h">make.conf</span><p>The profile file your selections produce, and every variable it knows.</p></a>
<a class="card" href="profile.html"><span class="num">reference</span><span class="h">Profile system</span><p>How profile/make.conf templates the build and the swappables.</p></a>
<a class="card" href="recipe-format.html"><span class="num">spec</span><span class="h">Recipe format</span><p>The formal spec for kama package recipes — fields, hooks, tiers.</p></a>
<a class="card" href="build-pipeline.html"><span class="num">reference</span><span class="h">Build pipeline</span><p>scripts/build-root.sh and mkfs-root.sh — how a make.conf becomes a rootfs.</p></a>
<a class="card" href="live-init.html"><span class="num">reference</span><span class="h">Live init</span><p>live/init — how booting the ISO auto-starts the installer.</p></a>
<a class="card" href="swappables.html"><span class="num">guide</span><span class="h">Swappables guide</span><p>Every component you can choose at install, with the full option list.</p></a>
<a class="card" href="install.html"><span class="num">guide</span><span class="h">Install guide</span><p>The end-to-end installation flow, from BIOS to boot.</p></a>
<a class="card" href="contribute.html"><span class="num">guide</span><span class="h">Contribute</span><p>How to get involved across the three repos and this site.</p></a>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Ethos — Keru OS</title>
<meta name="description" content="The ける ethos: keru keitō-teki — a system assembled the way you want it. The name, the mark, and what Keru stands for.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / ethos</p>
<h1>Ethos</h1>
<p>What the mark stands for.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>ける · keru keitō-teki</h3>
<p>Keru is written <strong>ける</strong> in Japanese, and the project's full phrase is <strong>ける・けいとうてき</strong> (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.</p>
<p>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.</p>
<h3>The kiln and the craft</h3>
<p>The package manager is called <strong>Kama</strong> (窯, "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.</p>
<h3>Principles guiding the work</h3>
<ul class="features">
<li><strong>Source-only.</strong> You run what you built. Every package is compiled from original source.</li>
<li><strong>Legibility.</strong> Every decision is a script or a line in <code>make.conf</code> you can see and change.</li>
<li><strong>Simplicity as stability.</strong> Fewer moving parts means fewer things to break — keeping the manager in shell is the point, not a compromise.</li>
<li><strong>Honesty at the edges.</strong> Unproven combinations get a warning, not a wall. You are never lied to about risk.</li>
<li><strong>No junk.</strong> No telemetry, no preinstalled opinions masked as defaults, no background assumptions.</li>
</ul>
<h3>What Keru is not</h3>
<ul class="features">
<li>Not a meta-OS that runs arbitrary kernels — it's a Linux distribution that composes the bits <em>above</em> the kernel however you like.</li>
<li>Not an opinionless void — it holds one strong opinion: that you should form yours.</li>
<li>Not a challenge to pick the "right" stack — there is no right stack, there's only your stack.</li>
</ul>
<blockquote>企業はあなたの選択の上に成り立つ — the distro stands on your choices.</blockquote>
<p><a href="about.html">Read about Keru</a> · <a href="philosophy.html">Read the philosophy</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+68
View File
@@ -0,0 +1,68 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>FAQ — Keru OS</title>
<meta name="description" content="Frequently asked questions about Keru OS: what it is, how it differs from Gentoo/Bedrock, what it means for you.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="community.html">community</a> / faq</p>
<h1>FAQ</h1>
<p>Straight answers.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>What is a "meta-distribution"?</h3>
<p>In the GNU/Linux world it names the Gentoo/Nix/Bedrock family: distributions organized around <em>choice and composition of components</em> rather than a fixed opinionated stack. Keru is the anti-opinionated member — its meta is choosing <em>not to choose for you</em>. <a href="anti-opinionated.html">Details.</a></p>
<h3>Is Keru a "meta-OS" that runs any kernel?</h3>
<p>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.</p>
<h3>How is this different from Gentoo?</h3>
<p>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.</p>
<h3>How is this different from Bedrock?</h3>
<p>Bedrock stitches multiple <em>distributions</em> together (apt + pacman + xbps side by side). Keru doesn't compose distros — it composes <em>components</em>, one init/libc/fs/kernel/tool at a time, built from source.</p>
<h3>Why is network required to install?</h3>
<p>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. <a href="installation-requirements.html">More.</a></p>
<h3>Will my system be stable?</h3>
<p>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. <a href="stability.html">The full stance.</a></p>
<h3>Is this a joke or a real project?</h3>
<p>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.</p>
<h3>What's with the Japanese?</h3>
<p><strong>ける</strong> (Keru) and <strong>ける・けいとうてき</strong> (keru keitō-teki) — "craft your system." Kama (窯) means "kiln." The naming is deliberate atmosphere, not branding gimmick. <a href="ethos.html">More.</a></p>
<h3>Why is the package manager in shell?</h3>
<p>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.</p>
<h3>When can I install it?</h3>
<p>The first release, 0.1, ships as a bootable ISO. <a href="news/roadmap-0.1.html">Follow the road to 0.1</a>.</p>
<h3>Where do I ask something this page doesn't cover?</h3>
<p><a href="contact.html">Contact channels</a> — issues first, then the mailing list.</p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Filesystems — Keru OS</title>
<meta name="description" content="Choose your root filesystem with Keru: ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, or swap.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / filesystems</p>
<h1>Filesystems</h1>
<p>The shape of your disk.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>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.</p>
</div>
<table>
<tr><th>Filesystem</th><th>Character</th></tr>
<tr><td><strong>ext4</strong></td><td>The default. Proven, journaled, everywhere-supported, boring in the best way.</td></tr>
<tr><td><strong>ext2 / ext3</strong></td><td>Classic lineage — ext2 is unjournaled simplicity, ext3 added the journal.</td></tr>
<tr><td><strong>btrfs</strong></td><td>Snapshots, subvolumes, checksums, and a rich feature set out of the box.</td></tr>
<tr><td><strong>xfs</strong></td><td>Scale-friendly, robust, excellent for large files and heavy workloads.</td></tr>
<tr><td><strong>zfs</strong></td><td>Snapshots, RAID-Z, checksums, volume management. Serious features, more moving parts.</td></tr>
<tr><td><strong>f2fs</strong></td><td>Flash-friendly filesystem, designed for SSDs and flash storage performance.</td></tr>
<tr><td><strong>jfs</strong></td><td>IBM's journaled filesystem — lean, historically aimed at servers.</td></tr>
<tr><td><strong>reiserfs</strong></td><td>Once a pioneer; now effectively unmaintained. Offered, but flagged.</td></tr>
<tr><td><strong>swap</strong></td><td>As a separate swap area, part of the root setup.</td></tr>
</table>
<div class="prose">
<h3>Honest flags</h3>
<p>Two filesystem options carry warnings in the installer:</p>
<ul class="features">
<li><strong>zfs</strong> as root needs a kernel module + ZFS userspace, and isn't yet proven end-to-end in the 0.1 pipeline. Warned, not blocked.</li>
<li><strong>reiserfs</strong> is unmaintained with no stable future. Offered because the choice is yours; flagged because honesty is cheaper than regret.</li>
</ul>
<div class="callout">The filesystem tooling (mkfs, fs tools) is built alongside the kernel and init in stage 2 — your choice dictating exactly what gets compiled in.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+123
View File
@@ -0,0 +1,123 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Keru OS — craft your system</title>
<meta name="description" content="Keru is an independent, source-only Linux distribution where you choose your init, libc, filesystem, kernel, and tools at install time. Nothing is forced. Everything is swappable.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="hero">
<span class="kicker"><span class="dot"></span> independent · source-only · linux</span>
<h1>You don't install a system.<br>You <span class="grad">craft</span> one.</h1>
<p class="sub">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.</p>
<div class="cta-row">
<a class="btn btn-primary" href="install.html">↓ Download 0.1</a>
<a class="btn btn-ghost" href="philosophy.html">Read the philosophy</a>
<a class="btn btn-ghost" href="swappables.html">See what's swappable</a>
</div>
</header>
<div class="ticker">
<div class="ticker-inner">
<span><b>runit</b> · <b>s6</b> · <b>openrc</b> · <b>systemd</b> · <b>busybox-init</b> · <b>sysvinit</b> · <b>dinit</b> · <b>shepherd</b></span>
<span><b>glibc</b> · <b>musl</b> · <b>uclibc-ng</b></span>
<span><b>ext4</b> · <b>btrfs</b> · <b>xfs</b> · <b>zfs</b> · <b>f2fs</b> · <b>jfs</b> · <b>reiserfs</b></span>
<span><b>linux</b> · <b>linux-lts</b> · <b>linux-hardened</b> · <b>linux-cachyos</b> · <b>linux-zen</b></span>
<span><b>doas</b> · <b>sudo</b> · <b>opendoas</b> · <b>su</b></span>
<span>ける・けいとうてき — craft your system</span>
</div>
</div>
<section>
<div class="wrap">
<p class="section-title">the differentiator</p>
<h2 class="head">Everything is swappable. Nothing is forced.</h2>
<p class="lead">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.</p>
<div class="grid grid-4">
<a class="card" href="inits.html"><span class="num">01</span><span class="h">Init system</span><p>runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd — your call.</p></a>
<a class="card" href="libcs.html"><span class="num">02</span><span class="h">C library</span><p>glibc, musl, uclibc-ng. The foundation under everything is up to you.</p></a>
<a class="card" href="filesystems.html"><span class="num">03</span><span class="h">Filesystem</span><p>ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap. Pick your root.</p></a>
<a class="card" href="kernels.html"><span class="num">04</span><span class="h">Kernel</span><p>linux, linux-lts, hardened, cachyos, zen. The spine of your machine.</p></a>
<a class="card" href="privilege-elevation.html"><span class="num">05</span><span class="h">Privilege elevation</span><p>doas, sudo, opendoas, or plain su — decide how you elevate.</p></a>
<a class="card" href="network-tools.html"><span class="num">06</span><span class="h">Network tools</span><p>networkmanager, connman, systemd-networkd, or nmtui on its own.</p></a>
<a class="card" href="make-conf.html"><span class="num">07</span><span class="h">Everything else</span><p>kernel parameters, locale, clock, keymap — all configurable in make.conf.</p></a>
<a class="card" href="stability.html"><span class="num">08</span><span class="h">Stability</span><p>Stable on what we offer. Past that, we warn and step aside — never block.</p></a>
</div>
</div>
</section>
<section style="background:var(--bg-2);border-top:1px solid var(--border);border-bottom:1px solid var(--border)">
<div class="wrap">
<p class="section-title" style="text-align:center">live demo</p>
<h2 class="head" style="text-align:center">Boot. Choose. Built from source.</h2>
<p class="lead" style="text-align:center">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.</p>
<div class="terminal reveal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre><span class="c">[ keru ]</span> <span class="k">Keru OS — craft your system</span>
Select the components, press enter for defaults.
== Init system == [runit]
== C library == [glibc]
== Filesystem == [ext4]
== Kernel == [linux]
== Privilege elevation == [doas]
== Network tools == [nmtui]
Selecting: <span class="c">btrfs</span> ← you choose, Keru builds it
<span class="p">...fetching source...</span>
<span class="p">...compiling from scratch (gcc → glibc → the system)...</span>
<span class="k">[ keru ] rootfs ready: /tmp/keru/root</span>
<span class="c">[ keru ] you crafted a btrfs, doas, runit system. it boots.</span></pre>
</div>
</div>
</section>
<section>
<div class="wrap">
<p class="section-title">why keru</p>
<h2 class="head">Purist. Honest. Light.</h2>
<div class="stats">
<div class="stat"><div class="big">~225</div><div class="lbl">lines, kama package manager</div></div>
<div class="stat"><div class="big">0</div><div class="lbl">binary packages</div></div>
<div class="stat"><div class="big">1,000+</div><div class="lbl">possible system combos</div></div>
<div class="stat"><div class="big">0</div><div class="lbl">opinions forced on you</div></div>
</div>
<div class="grid grid-3" style="margin-top:34px">
<div class="card"><span class="h">Source-only</span><p>Everything — toolchain included — compiled from original source. No binary packages, no opaque machinery.</p></div>
<div class="card"><span class="h">Kama, the kiln</span><p>The whole package manager is a ~225-line shell script. Legible. You can read every decision it makes.</p></div>
<div class="card"><span class="h">Anti-opinionated</span><p>Keru's only opinion is that you must form one. After that, it shuts up and builds exactly what you chose.</p></div>
<div class="card"><span class="h">From scratch</span><p>The ISO carries only the installer. Your system is fetched and built on the fly during install.</p></div>
<div class="card"><span class="h">Warn, don't block</span><p>Stability is guaranteed on what's offered. Push past the proven edge and Keru warns you, then gets out of your way.</p></div>
<div class="card"><span class="h">All yours</span><p>No telemetry, no unwanted services, no background assumptions. The disk reflects exactly what you chose.</p></div>
</div>
</div>
</section>
<section style="text-align:center;background:var(--bg-2);border-top:1px solid var(--border)">
<div class="wrap">
<h2 class="head">Ready when it's ready.</h2>
<p class="lead" style="margin:0 auto 24px">Keru 0.1 will ship as a bootable ISO. No source builds, no manual tooling — boot, choose, then watch it craft your system.</p>
<div class="cta-row">
<a class="btn btn-primary" href="news.html">Follow progress</a>
<a class="btn btn-ghost" href="contribute.html">Contribute</a>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript>
<div style="text-align:center;padding:16px">
See the <a href="sitemap.html">sitemap</a> for all pages.
</div>
</noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+55
View File
@@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Init systems — Keru OS</title>
<meta name="description" content="The init system is yours to choose with Keru: runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / inits</p>
<h1>Init systems</h1>
<p>Who brings your machine up. Your call.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>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: <strong>pick one yourself.</strong></p>
</div>
<div class="grid grid-3" style="margin-top:30px">
<div class="card"><span class="h">runit</span><p>Small, fast, BSD-style. Default in Keru — fast boot, simple service supervision, based on the runit process supervisor.</p></div>
<div class="card"><span class="h">s6</span><p>The skarnet suite's init and service manager. Dependency-free, designed-for-service supervision, very small.</p></div>
<div class="card"><span class="h">openrc</span><p>The classic Gentoo-style init. Compatible with sysvinit-style init.d, predictable "exclusive" service tree.</p></div>
<div class="card"><span class="h">systemd</span><p>The dominant init — service manager, logind, udev, resolved, timedate, all in one. If you want it, it's a choice, not an assumption.</p></div>
<div class="card"><span class="h">busybox-init</span><p>The bare init from busybox. Minimalist, tiny static binaries, closest to "nothing but a process supervisor."</p></div>
<div class="card"><span class="h">sysvinit</span><p>The classic System V init. Simple runlevels, init.d scripts, historically the baseline Linux init.</p></div>
<div class="card"><span class="h">dinit</span><p>A modern, fast, dependency-oriented init and service manager. Parallel boot, small footprint.</p></div>
<div class="card"><span class="h">shepherd</span><p>GNU's service manager (init). Guile-based, declarative services, part of the GNU project.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>Notes on pairing</h3>
<p>Some combinations are easier than others. The stability check in the installer flags pairs that aren't yet proven (for example, <code>musl + systemd</code>), but never blocks them — <a href="stability.html">the warn-not-block stance</a>.</p>
<div class="callout">The init you pick is baked in at first boot. It's a choice you make once, deliberately, at install — not inherited from a default you never saw.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+75
View File
@@ -0,0 +1,75 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Install — Keru OS</title>
<meta name="description" content="How to install Keru: boot the ISO, the installer starts itself, choose your components, and Keru builds your system from source.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / install</p>
<h1>Install Keru</h1>
<p>Boot the ISO. The installer starts itself. You choose. It builds.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>The whole flow</h3>
<p>Keru ships as a live ISO that carries <strong>only the installer</strong>. 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.</p>
<div class="callout"><strong>Network required.</strong> A working connection is a hard requirement for installing Keru. The installer checks it, and if you're not connected it offers to run <code>nmtui</code> for you.</div>
<h3>Step by step</h3>
<ol>
<li><strong>Boot the ISO.</strong> The live init (<code>live/init</code>) mounts the essentials and launches the installer automatically. No shell prompt, no manual boot gymnastics — it just starts.</li>
<li><strong>Connect if asked.</strong> If there's no network yet, you'll be prompted. Say yes and <code>nmtui</code> opens; connect, then continue. The installer re-checks until you're online.</li>
<li><strong>Choose your system.</strong> The installer walks through each swappable: init system, C library, filesystem, kernel, privilege elevation, network tools. Defaults are one enter-key away.</li>
<li><strong>Resolve the stability check.</strong> Unproven combinations get a warning, never a block. If it's risky, you're told — then you decide.</li>
<li><strong>Build.</strong> Confirm, and Keru fetches and compiles your exact system from source into a rootfs, then writes it to disk.</li>
<li><strong>Boot what you chose.</strong> Fixed at first boot. The system that lands is precisely the one you designed.</li>
</ol>
<h3>What the installer asks you</h3>
<table>
<tr><th>Component</th><th>Options</th></tr>
<tr><td>Init system</td><td>runit · s6 · openrc · systemd · busybox-init · sysvinit · dinit · shepherd</td></tr>
<tr><td>C library</td><td>glibc · musl · uclibc-ng</td></tr>
<tr><td>Filesystem</td><td>ext4 · ext2 · ext3 · btrfs · xfs · zfs · f2fs · jfs · reiserfs</td></tr>
<tr><td>Kernel</td><td>linux · linux-lts · linux-hardened · linux-cachyos · linux-zen</td></tr>
<tr><td>Privilege elevation</td><td>doas · sudo · opendoas · su</td></tr>
<tr><td>Network tools</td><td>nmtui · networkmanager · connman · systemd-networkd</td></tr>
</table>
<h3>What it writes</h3>
<p>Your choices are assembled into a <code>make.conf</code>, then handed to the build pipeline: <code>scripts/build-root.sh</code> drives Kama through toolchain bootstrap, base system, kernel, init, and tooling. The result — a rootfs matching your profile — is finalized with <code>mkfs-root.sh</code> and written to the target filesystem.</p>
<div class="code-block"># Generated by keru-install — hand-tune then rebuild if you like.
INIT=runit
LIBC=glibc
TARGET_FS=ext4
KERNEL=linux
SUDO=doas
NET=nmtui
LICENSE_ACCEPT=(*)</div>
<div class="callout ok"><strong>From scratch, every time.</strong> There's no binary base to seed. The toolchain is bootstrapped — gcc, binutils, your libc — then the rest on top. This is the "fully from scratch" path, kept honest.</div>
<p><a href="installer-walkthrough.html">Walk through the installer in detail</a> · <a href="installation-requirements.html">See the requirements</a> · <a href="network-setup.html">Network setup details</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Installation requirements — Keru OS</title>
<meta name="description" content="What you need to install Keru: a network connection, a machine to run it on, and a willingness to make choices.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="install.html">install</a> / requirements</p>
<h1>Installation requirements</h1>
<p>Honest about what installing Keru demands.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>Hard requirements</h3>
<table>
<tr><th>Requirement</th><th>Why</th></tr>
<tr><td><strong>Working network</strong></td><td>The ISO carries only the installer. Everything else — toolchain, kernel, init, libc, tools — is fetched and compiled during install. No network, no install.</td></tr>
<tr><td><strong>A machine that runs Linux</strong></td><td>Keru is a Linux distribution. The installer boots on x86 (and other archs as they're proven).</td></tr>
<tr><td><strong>A target disk/filesystem</strong></td><td>The system is written to the filesystem you choose during install.</td></tr>
<tr><td><strong>Some patience</strong></td><td>Everything is built from source on your machine. A from-scratch toolchain + system takes time. The compiler, not the package manager, is the bottleneck.</td></tr>
<tr><td><strong>A willingness to choose</strong></td><td>Keru's only ask is that you form an opinion about init, libc, filesystem, kernel, and tooling. Defaults exist; the decisions are still yours.</td></tr>
</table>
<h3>Not requirements</h3>
<ul class="features">
<li><strong>No pre-existing Linux.</strong> You don't need an OS to install from — the ISO + installer handles everything.</li>
<li><strong>No manual source builds.</strong> The installer drives the whole from-scratch build for you.</li>
<li><strong>No binary packages.</strong> Nothing precompiled to download. You build what you run.</li>
<li><strong>No telemetry or accounts.</strong> Nothing phone-home, nothing to sign up for to install.</li>
</ul>
<h3>The network, concretely</h3>
<p>At the first installable release (0.1), the network path is straightforward: wired Ethernet via DHCP, or wireless via <code>nmtui</code>, both handled from inside the installer. <a href="network-setup.html">See the network setup flow.</a></p>
<h3>What "from the network" means</h3>
<p>The installer reaches source tarballs (via a mirror such as <code>mirror.keru.org</code>, with upstream as fallback), pulls recipes from the <a href="kama-repos.html">recipe repository</a>, and builds. The heavy lifting is the compiler on your CPU — which is exactly the point of a source-only, from-scratch distribution.</p>
<div class="callout">If you want fast and prebaked, a binary distro is right there. If you want <em>your</em> machine — built from source to your exact selection — Keru is the one.</div>
<p><a href="install.html">← Back to install overview</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+113
View File
@@ -0,0 +1,113 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Installer walkthrough — Keru OS</title>
<meta name="description" content="A detailed walkthrough of the Keru installer: every menu, every choice, the network gate, the stability check, and the build.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="install.html">install</a> / walkthrough</p>
<h1>Installer walkthrough</h1>
<p>Every screen, in order, with the logic behind it.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>0 — Boot</h3>
<p>The live init starts <code>installer/install.sh</code> 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.</p>
<h3>1 — Network gate</h3>
<p>Because the ISO carries only the installer, connectivity is checked first. The probe hits a few hosts (<code>1.1.1.1</code>, <code>github.com</code>, <code>mirror.keru.org</code>) with ping; if ping isn't there, it falls back to a TCP connect via <code>nc</code>.</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ keru ] network: connected <span class="c">← online, straight to choices</span>
<span class="p">or, if offline:</span>
[ keru ] warning: network: not connected
Connect to the network now (runs nmtui)? [Y/n] <span class="k">y</span>
<span class="p">(nmtui opens; you connect; press ok)</span>
[ keru ] network: connected</pre>
</div>
<p>If you press <kbd>n</kbd> at the prompt, the installer exits with <code>a network connection is required to install Keru</code>. If you run <code>nmtui</code> and don't actually connect, the loop simply asks again — it never fakes success.</p>
<h3>2 — Choose your system</h3>
<p>Each swappable is presented as a numbered menu. Pressing enter keeps the default; typing a number picks the option.</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ 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]: </pre>
</div>
<p>The same pattern repeats for C library, filesystem, kernel, privilege elevation, and network tools.</p>
<h3>3 — Stability check</h3>
<p>After the last pick, known-risky combinations are flagged. This is a warning, never a block — the philosophy of <a href="stability.html">stable-on-what's-offered, never-lock-you-out</a>.</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ 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.</pre>
</div>
<h3>4 — make.conf</h3>
<p>Your selections are written to a profile and shown back to you before anything builds:</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ 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] <span class="k">y</span></pre>
</div>
<h3>5 — Build</h3>
<p>Confirming hands the profile to the build pipeline, which runs in three stages:</p>
<ol>
<li><strong>Stage 0 — bootstrap.</strong> <code>binutils</code>, <code>gcc</code>, your chosen <code>libc</code>, then the <code>toolchain</code> package. This is the from-scratch toolchain.</li>
<li><strong>Stage 1 — base system.</strong> The <code>BASE_PACKAGES</code> set from your <code>make.conf</code>.</li>
<li><strong>Stage 2 — the swappables.</strong> Kernel, init, sudo-alternative, and network tools — exactly the ones you picked.</li>
<li><strong>Stage 3 — finalize.</strong> <code>mkfs-root.sh</code> writes the chosen filesystem to the target root.</li>
</ol>
<div class="callout ok"><strong>Result:</strong> a rootfs at <code>/tmp/keru/root</code> matching your profile, ready to boot. Fixed at first boot — the system you designed.</div>
<p><a href="install.html">← Back to install overview</a> · <a href="build-pipeline.html">The build pipeline in full</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+80
View File
@@ -0,0 +1,80 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama recipes — Keru OS</title>
<meta name="description" content="How kama recipes work: plain shell scripts that define name, version, url, deps, and the build/install steps.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="kama.html">kama</a> / recipes</p>
<h1>Kama recipes</h1>
<p>The package manager runs recipes. Here's what a recipe is.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>A Kama recipe is a <strong>plain shell script</strong>. It declares metadata and defines build steps. There is no DSL to learn beyond shell itself — which is the point. The recipe repository (<a href="kama-repos.html">kama-packages</a>) contains one file per package, and each one is readable top to bottom.</p>
<h3>Anatomy of a recipe</h3>
<div class="code-block">name=busybox
version=1.36.1
url="https://busybox.net/downloads/busybox-${version}.tar.bz2"
deps=( make )
build() {
cp ../config .config # basic setup from kama
make -j"$(nproc)"
}
install() {
make install CONFIG_PREFIX="$DESTDIR"
}</div>
<p>The key fields:</p>
<table>
<tr><th>Field</th><th>Meaning</th></tr>
<tr><td><code>name</code></td><td>Package name; used for the stage and cache paths.</td></tr>
<tr><td><code>version</code></td><td>The release version, typically embedded in the <code>url</code>.</td></tr>
<tr><td><code>url</code></td><td>Upstream source tarball (mirror-then-upstream on fetch).</td></tr>
<tr><td><code>deps</code></td><td>Array of build-time dependencies, built then purged.</td></tr>
<tr><td><code>build()</code></td><td>Runs in the extracted source dir — configure & compile.</td></tr>
<tr><td><code>install()</code></td><td>Installs into the package's stage dir (<code>DESTDIR</code>).</td></tr>
</table>
<h3>Two tiers</h3>
<p>Recipes can stay deliberately simple or take full control:</p>
<ul class="features">
<li><strong>Easy tier</strong> — the <code>build()</code> / <code>install()</code> sugar above. Great for "configure, make, make install" packages.</li>
<li><strong>Advanced tier</strong> — <code>pkg_build()</code>, <code>pkg_install()</code>, custom <code>pkg_fetch()</code>, and a <code>pkg_post()</code> hook. For packages that need a hand.</li>
</ul>
<p>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.</p>
<h3>The staging model</h3>
<p>Building installs into a per-package stage dir, not the live root. That's how kama can assemble a complete system in <code>$ROOT</code> — the installer's whole trick — without ever touching the tree being built. The install step copies the staged dir into <code>$ROOT</code>.</p>
<h3>How it's found</h3>
<p>Kama locates a recipe by trying <code>PKGDIR/&lt;pkg&gt;/PKGBUILD</code>, then <code>PKGDIR/&lt;pkg&gt;.sh</code>, then <code>PKGDIR/&lt;pkg&gt;/*.sh</code>. Naming a recipe file <code>&lt;pkg&gt;.sh</code> is the common case.</p>
<div class="callout">A recipe is a contract you can read. No opaque package format, no hidden build logic — if you can read shell, you can audit every package in the repository.</div>
<p><a href="recipe-format.html">The formal recipe format spec</a> · <a href="kama.html">← Kama overview</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+62
View File
@@ -0,0 +1,62 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama repos — Keru OS</title>
<meta name="description" content="The kama repo split: the package manager (kama) and the recipe repository (kama-packages).">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="kama.html">kama</a> / repos</p>
<h1>The repo split</h1>
<p>Three small pieces, each with one job.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru splits its world into three repositories so each stays small and legible. The package side of that is:</p>
<table>
<tr><th>Repo</th><th>Holds</th><th>Keeps</th></tr>
<tr><td><strong>kama</strong></td><td>The manager — the <code>kama</code> entry point and <code>lib/kama.sh</code> core.</td><td>The code.</td></tr>
<tr><td><strong>kama-packages</strong></td><td>The recipe repository — one <code>.sh</code> per package.</td><td>The knowledge.</td></tr>
<tr><td><strong>KeruOS</strong></td><td>The OS: installer, profile, build pipeline, live init, website.</td><td>The orchestration.</td></tr>
</table>
<h3>Why separate</h3>
<ul class="features">
<li><strong>Independent cadence.</strong> The manager changes rarely; recipes change constantly. Mixing them couples an ossified core to churn.</li>
<li><strong>Clear ownership.</strong> "Which file builds busybox?" — the recipe repo. "How does kama decide to stage?" — the manager repo. No guessing where things live.</li>
<li><strong>Small repos, legible diffs.</strong> A PR adding a package touches exactly one file in one repo.</li>
<li><strong>Cross-repo defaults.</strong> Keru's scripts expect the three repos as siblings (<code>kama</code> next to <code>kama-packages</code> next to <code>KeruOS</code>), and every path is overridable via <code>KAMA_DIR</code> / <code>PKGS_DIR</code>.</li>
</ul>
<h3>How they fit together</h3>
<div class="code-block"># KeruOS build-root.sh drives kama against kama-packages
KAMA="$KAMA_DIR/kama" # the manager
PKGDIR="$PKGS_DIR" "$KAMA" make "$pkg" # a recipe, executed
# into $ROOT — a completed system, built from source.</div>
<p>The installer is the conductor: it writes your <code>make.conf</code>, then calls the build pipeline, which runs kama over recipes to produce exactly the system you chose.</p>
<div class="callout">This is Keru's answer to packaging sprawl: three tiny repos, each human-sized, instead of one monolith that swallowed everything.</div>
<p><a href="kama.html">← Kama overview</a> · <a href="build-pipeline.html">The build pipeline</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+79
View File
@@ -0,0 +1,79 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama usage — Keru OS</title>
<meta name="description" content="The kama commands: fetch, build, install, make, purge, info — and how the dependency flow works.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="kama.html">kama</a> / usage</p>
<h1>Kama usage</h1>
<p>The whole command surface, in one place.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Kama's commands are few on purpose. Here's the complete set:</p>
<table>
<tr><th>Command</th><th>What it does</th></tr>
<tr><td><code>kama fetch &lt;pkg&gt;</code></td><td>Download and extract source for a package into the cache.</td></tr>
<tr><td><code>kama build &lt;pkg&gt;</code></td><td>Stage-build one package (configure/make) into its stage dir.</td></tr>
<tr><td><code>kama install &lt;pkg&gt;</code></td><td>Build + install a package into <code>$ROOT</code> (staging-aware).</td></tr>
<tr><td><code>kama make &lt;pkg&gt;</code></td><td>High-level: fetch deps, build, install, then purge temp deps.</td></tr>
<tr><td><code>kama purge [pkg ...]</code></td><td>Remove temp build-time deps after a successful install.</td></tr>
<tr><td><code>kama info &lt;pkg&gt;</code></td><td>Show a recipe's metadata (name, version, url, deps).</td></tr>
<tr><td><code>kama help</code></td><td>Print the command reference.</td></tr>
</table>
<h3>Making a package, end to end</h3>
<p><code>kama make</code> is the command that ties it together. For a package with dependencies it walks through:</p>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">$ kama make firefox</span></div>
<pre><span class="c">[ kama ]</span> building temp deps for firefox: <span class="k">rust gtk3</span>
<span class="p"> ... fetch, build, install each temp dep ...</span>
<span class="c">[ kama ]</span> building firefox
<span class="p"> ... stage build + install into $ROOT ...</span>
<span class="c">[ kama ]</span> purging temp deps for firefox: <span class="k">rust gtk3</span></pre>
</div>
<h3>Environment & config</h3>
<p>Kama reads a few things to know where to work:</p>
<table>
<tr><th>Variable</th><th>Default</th></tr>
<tr><td><code>PKGDIR</code></td><td>The recipe repo (kama-packages, sibling by default).</td></tr>
<tr><td><code>MAKE_CONF</code></td><td><code>/etc/kama/make.conf</code> — profile settings, if present.</td></tr>
<tr><td><code>ROOT</code></td><td><code>/tmp/keru/root</code> — where installed files go.</td></tr>
<tr><td><code>CACHEDIR</code></td><td><code>/var/cache/kama</code> — source, download, and stage dirs.</td></tr>
<tr><td><code>PURGE_TEMP_DEPS</code></td><td><code>1</code> — whether temp deps are purged after building.</td></tr>
</table>
<h3>Fetch details</h3>
<ul class="features">
<li><strong>Mirror first.</strong> Downloads try <code>SOURCE_MIRROR</code> before upstream, so the org mirror (e.g. mirror.keru.org) can carry the load.</li>
<li><strong>Cached.</strong> Already-downloaded source is reused; already-extracted source isn't re-extracted.</li>
<li><strong>Auto-extract.</strong> Tar (gz/xz/bz2/plain) and zip are handled automatically by extension.</li>
</ul>
<div class="callout">Kama's surface stays tiny because the complexity lives in recipes, not the manager. Read <a href="kama-recipes.html">how recipes work</a> next.</div>
<p><a href="kama.html">← Kama overview</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+59
View File
@@ -0,0 +1,59 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kama — Keru OS package manager</title>
<meta name="description" content="Kama (窯, kiln) is Keru's package manager: a ~225-line shell script that builds every package from source by executing recipes.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / kama</p>
<h1>Kama — the kiln</h1>
<p>Keru's package manager, deliberately small.</p>
<span class="tag">窯</span>
</header>
<section>
<div class="wrap">
<div class="prose">
<p><strong>Kama</strong> (窯, "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 <a href="kama-recipes.html">recipe</a>. It holds no opinions — matching the distro that ships it. It reads a <code>make.conf</code>, runs recipe commands, and gets out of the way.</p>
</div>
<div class="grid grid-3" style="margin-top:30px">
<div class="card"><span class="num">no db</span><span class="h">No package database</span><p>Kama doesn't track installed files in a manifest db. It stages, installs, and moves on.</p></div>
<div class="card"><span class="num">no resolver</span><span class="h">No dependency resolver</span><p>Dependencies come from the recipe's <code>deps[]</code> array — explicit, not discovered.</p></div>
<div class="card"><span class="num">shell</span><span class="h">Pure shell</span><p>The whole manager is a script. Legible end to end; every decision is something you can read.</p></div>
<div class="card"><span class="num">stage</span><span class="h">Staging installs</span><p>Builds into a per-package stage dir, then copies into <code>$ROOT</code> — never smears the live tree.</p></div>
<div class="card"><span class="num">tmp deps</span><span class="h">Ephemeral build deps</span><p>Build-time-only dependencies are fetched, built, installed, and purged after use — they never accumulate.</p></div>
<div class="card"><span class="num">$ROOT</span><span class="h">Builds anywhere</span><p>Targets <code>$ROOT</code>, so it can assemble a full system in a staging root — exactly what the installer needs.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>The philosophy in the manager</h3>
<p>Kama embodies Keru's central bet: <em>package managers became more complex than the packages they manage.</em> 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.</p>
<blockquote>"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."</blockquote>
<h3>Where it lives</h3>
<p>Kama lives in its own repo, <a href="kama-repos.html">alongside the recipe repository</a> — two small pieces that Keru's installer drives together.</p>
<div class="callout">Kama is the thing that makes "from scratch" real. It's the kiln that fires your system from the ingredients you pick.</div>
<p><a href="kama-usage.html">How to use Kama</a> · <a href="kama-recipes.html">How recipes work</a> · <a href="kama-repos.html">The repo split</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+55
View File
@@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Kernels — Keru OS</title>
<meta name="description" content="Choose your kernel with Keru: linux, linux-lts, linux-hardened, linux-cachyos, linux-zen.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / kernels</p>
<h1>Kernels</h1>
<p>The spine of your machine.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>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.</p>
</div>
<div class="grid grid-3" style="margin-top:30px">
<div class="card"><span class="h">linux</span><p>The default. Stock mainline — the broad, well-trodden baseline that matches the ecosystem.</p></div>
<div class="card"><span class="h">linux-lts</span><p>The long-term-supported line. Slower-moving, security-patched, built for stability and long installs.</p></div>
<div class="card"><span class="h">linux-hardened</span><p>Hardening patches on top of the kernel — hardened allocator, stronger exploit mitigations.</p></div>
<div class="card"><span class="h">linux-cachyos</span><p>A performance-tuned kernel with scheduler and allocator tweaks; built for responsiveness.</p></div>
<div class="card"><span class="h">linux-zen</span><p>Community kernel focused on desktop and multimedia performance — faster, more adventurous.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>A choice, within a family</h3>
<p>To be clear about the scope: the freedom here is <em>within</em> 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. <a href="anti-opinionated.html">More on what Keru's freedom does and doesn't cover.</a></p>
<h3>Baked in, not bolted on</h3>
<p>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.</p>
<div class="callout">linux-lts for "set it and forget it," linux for the mainstream, hardened/zen/cachyos for the tradeoffs you actually want. Your call.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+53
View File
@@ -0,0 +1,53 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>C libraries — Keru OS</title>
<meta name="description" content="Choose your C library with Keru: glibc, musl, or uclibc-ng. The foundation under your whole system.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / libcs</p>
<h1>C libraries</h1>
<p>The foundation under everything that runs.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Every C program on your system links against a C library. It's the floor under userspace: <code>malloc</code>, <code>printf</code>, thread primitives, the syscall wrappers, all of it. Keru lets you choose which floor the rest of your system stands on.</p>
</div>
<div class="grid grid-3" style="margin-top:30px">
<div class="card"><span class="h">glibc</span><p>The default, and the most compatible. Maximal feature set, broadest software support, the ecosystem baseline.</p></div>
<div class="card"><span class="h">musl</span><p>Small, fast, clean implementation. MIT-licensed, statically-friendly, famous for strict correctness and small binaries.</p></div>
<div class="card"><span class="h">uclibc-ng</span><p>The maintained fork of uClibc — designed for embedded and minimal systems, tiny footprint, configurable.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>Why this is a choice</h3>
<p>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.</p>
<h3>Stability notes</h3>
<p>musl and uclibc-ng are early-0.1 territory. The installer's stability check currently flags <code>uclibc-ng</code> combinations as not-yet-proven, and <code>musl + systemd</code> as a known-hard pairing. Warnings — never blocks. <a href="stability.html">The stance.</a></p>
<div class="callout">glibc is the default for a reason: it's the widest path. But "the path everyone takes" is an argument, not a law — and in Keru, you make the call.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+51
View File
@@ -0,0 +1,51 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>License — Keru OS</title>
<meta name="description" content="Keru OS, kama, and kama-packages are licensed under AGPL-3.0.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / license</p>
<h1>License</h1>
<p>AGPL-3.0, across all three repositories.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru OS, <a href="kama.html">kama</a>, and <a href="kama-repos.html">kama-packages</a> are licensed under the <strong>GNU Affero General Public License v3.0</strong> (AGPL-3.0). The full license text ships as <code>LICENSE</code> in each repository.</p>
<h3>What that means, briefly</h3>
<ul class="features">
<li><strong>Freedom to use.</strong> Build, install, and run Keru on anything you like.</li>
<li><strong>Freedom to study and modify.</strong> Source is available everywhere; it always has been — that's Keru's whole point.</li>
<li><strong>Freedom to share.</strong> Redistribute copies (modified or not) under the same license.</li>
<li><strong>Network use counts.</strong> If you modify Keru's software and offer it to users over a network, the AGPL requires you to offer the modified source — the "Affero" addition.</li>
</ul>
<h3>Derivative distributions welcome</h3>
<p>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.</p>
<h3>About this website</h3>
<p>This site lives in <code>web/</code> in the KeruOS repository, and is covered by the same AGPL-3.0. The design, copy, and markup are free to reuse under it.</p>
<div class="callout">License texts live in each repo root. The canonical document is the file, not this page.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+62
View File
@@ -0,0 +1,62 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Links — Keru OS</title>
<meta name="description" content="Every repository and related resource for Keru OS.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="community.html">community</a> / links</p>
<h1>Links</h1>
<p>Everything, in one place.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-2">
<a class="card" href="https://github.com/AstralZX/KeruOS">
<span class="num">repo</span><span class="h">KeruOS</span>
<p>The operating system — installer, profile, build pipeline, live init, and this website.</p>
</a>
<a class="card" href="https://github.com/AstralZX/kama">
<span class="num">repo</span><span class="h">kama</span>
<p>The package manager — a ~225-line shell script. The kiln.</p>
</a>
<a class="card" href="https://github.com/AstralZX/kama-packages">
<span class="num">repo</span><span class="h">kama-packages</span>
<p>The recipe repository — one shell file per package.</p>
</a>
<a class="card" href="https://github.com/AstralZX">
<span class="num">org</span><span class="h">AstralZX</span>
<p>The GitHub account behind the project, and whatever else ships under it.</p>
</a>
</div>
<div class="prose" style="margin-top:40px">
<h3>Related reading</h3>
<ul class="features">
<li><a href="philosophy.html">The philosophy</a> — the full argument for Keru's stance.</li>
<li><a href="anti-opinionated.html">Anti-opinionated</a> — what the stance grants, what it costs, and its limits (it's not a meta-OS).</li>
<li><a href="stability.html">Stability, honestly scoped</a> — the warn-not-block promise.</li>
<li><a href="news.html">News</a> — announcements and the road to 0.1.</li>
</ul>
<div class="callout">All code is AGPL-3.0. This site's source lives in <code>web/</code> inside the KeruOS repo — clone, read, improve.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+65
View File
@@ -0,0 +1,65 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Live init — Keru OS docs</title>
<meta name="description" content="The live/init reference: how booting the Keru ISO auto-starts the installer.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / live init</p>
<h1>Live init</h1>
<p>Boot the ISO, and the installer starts itself.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p><code>live/init</code> 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."</p>
<h3>What it does, in order</h3>
<ol>
<li><strong>Sets up the console.</strong> Redirects to <code>$CONSOLE</code> (<code>/dev/tty1</code> by default) so installer messages land where you can see them.</li>
<li><strong>Mounts virtual filesystems.</strong> <code>/proc</code>, <code>/sys</code>, <code>/dev</code> (devtmpfs, with tmpfs fallback), <code>/dev/pts</code>, <code>/dev/shm</code> — the essentials the installer needs.</li>
<li><strong>Locates the installer root.</strong> Uses the kernel's <code>root=</code> if given, or looks for a <code>KERU*</code>-labeled device to find the read-only squashfs payload; otherwise assumes the installer is on the current root.</li>
<li><strong>Execs the installer.</strong> <code>exec sh installer/install.sh</code> — the TUI starts immediately.</li>
<li><strong>Emergency shell fallback.</strong> If the installer exited or isn't found, you get an interactive rescue shell instead of a hang.</li>
</ol>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">live/init</span></div>
<pre>[ keru ] booting installer...
<span class="c">[ keru ] Keru OS — craft your system</span>
== Init system == [runit]
== C library == [glibc]
== Filesystem == [ext4]
<span class="p"># and you're choosing — the installer opened itself.</span></pre>
</div>
<h3>Design notes</h3>
<ul class="features">
<li><strong>Ultra-minimal.</strong> The live env is busybox + the installer. No init system in the live env — this script <em>is</em> the init.</li>
<li><strong>Never strand you.</strong> The emergency shell is deliberate: "installer not found or exited" should never be a dead end.</li>
<li><strong>Console-aware.</strong> It listens to the <code>console=</code> kernel param so serial consoles work too.</li>
</ul>
<div class="callout">This is the "boot → choose → it builds" promise made real: the ISO carries the installer, and live/init hands it straight to you.</div>
<p><a href="installer-walkthrough.html">What happens after it starts</a> · <a href="docs.html">← Docs</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+97
View File
@@ -0,0 +1,97 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>make.conf reference — Keru OS</title>
<meta name="description" content="The make.conf reference: the single source of truth for a Keru build, written by the installer and read by Kama.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / make.conf</p>
<h1>make.conf</h1>
<p>The single source of truth for a build.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p><code>make.conf</code> 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.</p>
<h3>Profile — the swappables</h3>
<div class="code-block"># Which init system gets installed
INIT=runit
# Which libc the toolchain and packages build against
LIBC=glibc
# Which filesystem the target root is formatted as
TARGET_FS=ext4
# Which kernel you want built
KERNEL=linux
# Which privilege-elevation tool gets installed
SUDO=doas
# Base package set pulled into every install
BASE_PACKAGES=(base toolchain openssh)
# Locale / clock / keymap applied to the target
LOCALE=en_US.UTF-8
TIMEZONE=UTC
KEYMAP=us</div>
<h3>Build environment</h3>
<div class="code-block"># Compiler / linker flags passed to every recipe build
CFLAGS="-O2 -march=x86-64"
CXXFLAGS="$CFLAGS"
LDFLAGS="-s"
# Parallelism
JOBS=$(nproc)
MAKEFLAGS="-j$JOBS"
# Mirrors for source tarballs
SOURCE_MIRROR="https://mirror.keru.org/sources"
# Where the new target root lives on the build host
ROOT=/tmp/keru/root
# Persistent source + build cache (survives across installs)
CACHEDIR=/var/cache/kama</div>
<h3>Kama behaviour</h3>
<div class="code-block"># Remove temp build-time deps after use (AUR-style). Set to 0 to keep them.
PURGE_TEMP_DEPS=1
# Stop on first recipe failure
FAIL_FAST=1</div>
<h3>Why it's "the source of truth"</h3>
<ul class="features">
<li><strong>The installer writes it</strong> from your choices — every menu pick lands as a line here.</li>
<li><strong>Kama reads it</strong> to know flags, mirrors, cache, and where to install into.</li>
<li><strong>It's human-editable.</strong> The TUI is a convenience, not a gate. Edit, rebuild, repeat.</li>
<li><strong>It's reproducible.</strong> The same make.conf should build the same system.</li>
</ul>
<div class="callout">The canonical template lives in <code>profile/make.conf</code> at the repo root — the copy above mirrors it, but the repository file is the source of truth.</div>
<p><a href="profile.html">The profile system</a> · <a href="docs.html">← Docs</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+49
View File
@@ -0,0 +1,49 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>mkfs-root — Keru OS docs</title>
<meta name="description" content="The mkfs-root.sh reference: formatting and assembling the target root as your chosen filesystem.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / build-pipeline / mkfs-root</p>
<h1>mkfs-root.sh</h1>
<p>Finalizing the root as the filesystem you chose.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p><code>scripts/mkfs-root.sh</code> is the final stage of the build pipeline. Given your chosen <code>TARGET_FS</code>, it formats and assembles <code>$ROOT</code> so the disk reflects exactly the filesystem you selected at install.</p>
<h3>What it does</h3>
<ul class="features">
<li><strong>Formats.</strong> Creates the filesystem image with the matching mkfs tool (ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap, or the ext2/ext3 lineage).</li>
<li><strong>Populates.</strong> Copies the built rootfs into the formatted volume.</li>
<li><strong>Wiring.</strong> Ensures fstab and boot records match your selections.</li>
</ul>
<h3>Honest flags</h3>
<p>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.</p>
<div class="callout">The result of <code>stage 3</code> is a rootfs that will boot — with the exact filesystem, kernel, init, and tools you picked. That's the whole pipeline in one line.</div>
<p><a href="build-pipeline.html">← Build pipeline</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+65
View File
@@ -0,0 +1,65 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Network setup — Keru OS</title>
<meta name="description" content="How the Keru installer handles networking: the connectivity gate, nmtui, and the re-check loop.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="install.html">install</a> / network setup</p>
<h1>Network setup</h1>
<p>Connectivity is a hard requirement. The installer makes connecting easy.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>Why networking is mandatory</h3>
<p>The ISO carries <em>only</em> 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.</p>
<h3>The flow, exactly</h3>
<ol>
<li><strong>Probe.</strong> The installer checks connectivity against several hosts (<code>1.1.1.1</code>, <code>github.com</code>, <code>mirror.keru.org</code>) using <code>ping</code>, falling back to a TCP connect via <code>nc</code> if needed.</li>
<li><strong>If connected:</strong> a simple <code>[ keru ] network: connected</code> and it moves straight to crafting your system.</li>
<li><strong>If not connected:</strong> you're told, and asked — <code>Connect to the network now (runs nmtui)? [Y/n]</code>.</li>
<li><strong>Say yes:</strong> <code>nmtui</code> opens. Connect to your network, press okay.</li>
<li><strong>Saying no:</strong> the installer exits with <code>a network connection is required to install Keru</code>.</li>
<li><strong>Re-check.</strong> After <code>nmtui</code> closes, connectivity is probed again. If you're online, you continue. If not, it asks again — it never fakes success.</li>
</ol>
<div class="terminal">
<div class="tbar"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="t">keru@live:~$</span></div>
<pre>[ keru ] warning: network: not connected
Connect to the network now (runs nmtui)? [Y/n] <span class="k">y</span>
<span class="p">(nmtui opens — pick your network, connect, press ok)</span>
[ keru ] network: connected</pre>
</div>
<h3>Details that matter</h3>
<ul class="features">
<li><strong>Wired is the path of least resistance.</strong> A physical Ethernet connection with DHCP typically just works — the probe succeeds and you skip straight to choosing.</li>
<li><strong>Wireless goes through nmtui.</strong> The NetworkManager TUI handles Wi-Fi selection, WPA credentials, and the rest. The installer doesn't guess; it hands you the tool.</li>
<li><strong>Loop, don't lie.</strong> If you run <code>nmtui</code> but never connect, the installer loops back to the prompt rather than proceeding on a "trust me, it worked" basis.</li>
</ul>
<div class="callout"><strong>What if nmtui isn't available?</strong> The live ISO ships with it, so this is an edge case — but if it's missing, the installer tells you plainly and lets you bring the network up yourself before continuing.</div>
<p><a href="installer-walkthrough.html">Walkthrough</a> · <a href="installation-requirements.html">Requirements</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+54
View File
@@ -0,0 +1,54 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Network tools — Keru OS</title>
<meta name="description" content="Choose your network management with Keru: networkmanager, connman, systemd-networkd, or nmtui alone.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / network tools</p>
<h1>Network tools</h1>
<p>How your network gets managed. Your call.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>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."</p>
</div>
<div class="grid grid-4" style="margin-top:30px">
<div class="card"><span class="h">nmtui</span><p>The default. Just NetworkManager's terminal user interface — connect wires and Wi-Fi without a full manager on your system.</p></div>
<div class="card"><span class="h">networkmanager</span><p>The full NetworkManager — daemon, D-Bus API, <code>nmcli</code>, handles wired, wireless, VPN, and more.</p></div>
<div class="card"><span class="h">connman</span><p>Intel's connection manager — light, D-Bus bus–independent, designed for embedded and minimal systems.</p></div>
<div class="card"><span class="h">systemd-networkd</span><p>systemd's network configuration daemon — declarative unit-based config, pairs with systemd/udev.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>Notes on the default</h3>
<p>The default is <code>nmtui</code> — the interface, not the daemon — which is the lean choice: you get the easy <code>nmtui</code> workflow during install without committing yourself to running NetworkManager's daemon afterward. If you want the full manager, it's one selection away.</p>
<h3>Coherence</h3>
<p>If you chose <code>systemd</code> as your init, <code>systemd-networkd</code> pairs naturally. If you're on runit or s6, a standalone manager (or just <code>nmtui</code>) fits the picture. The installer offers the pieces; you assemble them.</p>
<div class="callout">During install, network setup uses <code>nmtui</code> itself (the installer runs it when you need to connect) — independent of what you pick as your system's eventual network tool. <a href="network-setup.html">The install-time network flow.</a></div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+52
View File
@@ -0,0 +1,52 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>News — Keru OS</title>
<meta name="description" content="News from the Keru project: announcements, design notes, and the road to 0.1.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / news</p>
<h1>News</h1>
<p>Progress, decisions, and the road to 0.1.</p>
</header>
<section>
<div class="post-list">
<a class="post-item" href="news/announcing-keru.html">
<h3>Introducing Keru OS</h3>
<div class="meta">2026-09-01 · announcement</div>
<p>An anti-opinionated, source-only Linux distribution where everything is swappable at install time.</p>
</a>
<a class="post-item" href="news/philosophy-is-architecture.html">
<h3>The philosophy is the architecture</h3>
<div class="meta">2026-09-01 · design</div>
<p>Why the "you choose everything" claim is structurally real, not a slogan.</p>
</a>
<a class="post-item" href="news/roadmap-0.1.html">
<h3>The road to 0.1</h3>
<div class="meta">2026-09-01 · roadmap</div>
<p>What has to exist before the first installable ISO ships — honest about the work.</p>
</a>
<a class="post-item" href="news/design-decisions.html">
<h3>Design decisions, so far</h3>
<div class="meta">2026-09-01 · design</div>
<p>The choices recorded so Keru didn't drift: shell manager, warn-not-block, sibling repos, installer-only ISO.</p>
</a>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+55
View File
@@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Introducing Keru OS — Keru OS news</title>
<meta name="description" content="Announcing Keru OS: an independent, source-only, anti-opinionated Linux distribution.">
<link rel="stylesheet" href="../assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="../index.html">home</a> / <a href="../news.html">news</a> / announcing keru</p>
<h1>Introducing Keru OS</h1>
<p class="meta" style="font-family:var(--mono);color:var(--text-dim);font-size:.85rem">2026-09-01 · announcement</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru (ける) is a Linux distribution built on a deliberately unusual premise: <strong>the distro holds no opinion about your system.</strong> Not a light opinion, not a sensible default disguised as neutrality — no position at all.</p>
<p>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: <strong>you decide, at install time, and the distro builds exactly that.</strong></p>
<h3>What that means concretely</h3>
<ul class="features">
<li><strong>Init is a choice.</strong> runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd — side by side, weightless.</li>
<li><strong>Your C library is a choice.</strong> glibc, musl, uclibc-ng.</li>
<li><strong>Your filesystem is a choice.</strong> ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs.</li>
<li><strong>Your kernel is a choice.</strong> linux, linux-lts, hardened, cachyos, zen.</li>
<li><strong>Even sudo is a choice.</strong> doas, sudo, opendoas, or su.</li>
</ul>
<p>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.</p>
<h3>Why</h3>
<p>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 <em>theirs</em>. Keru's only opinion is that you have to form one. After that, it builds exactly what you chose.</p>
<p>Read the <a href="../philosophy.html">full philosophy</a>, or follow <a href="../news.html">progress here</a>.</p>
<div class="callout">Everything is at an early stage. The first installable release, 0.1, will ship as a bootable ISO. Until then: the design is public, the repos are live, and the road is documented.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="../sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="../assets/js/include.js" data-base=".."></script>
</body>
</html>
+58
View File
@@ -0,0 +1,58 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Design decisions, so far — Keru OS news</title>
<meta name="description" content="The recorded decisions that stop Keru from drifting: shell manager, warn-not-block stability, sibling repos, installer-only ISO.">
<link rel="stylesheet" href="../assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="../index.html">home</a> / <a href="../news.html">news</a> / design decisions</p>
<h1>Design decisions, so far</h1>
<p class="meta" style="font-family:var(--mono);color:var(--text-dim);font-size:.85rem">2026-09-01 · design</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>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.</p>
<h3>1. The package manager is a shell script</h3>
<p>Kama (~225 lines, pure shell) reads <code>make.conf</code> 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.</p>
<h3>2. Stability is warn-not-block</h3>
<p>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.</p>
<h3>3. Three sibling repos</h3>
<p>KeruOS, kama, kama-packages — separate, sibling by default, each human-sized. Rationale: independent cadence, legible diffs, clear ownership. Paths are overridable via <code>KAMA_DIR</code>/<code>PKGS_DIR</code>.</p>
<h3>4. The ISO carries only the installer</h3>
<p>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.</p>
<h3>5. All ephemeral build deps (AUR-style)</h3>
<p>Build-time dependencies are compiled, installed, and purged after use (<code>PURGE_TEMP_DEPS=1</code>). Rationale: they never accumulate, so the final system reflects exactly what it needs to run — not what it needed to be built.</p>
<h3>6. The installer auto-starts on boot</h3>
<p>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.</p>
<h3>7. The website lives in the OS repo</h3>
<p>For now, the site ships inside KeruOS under <code>web/</code> — 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.</p>
<div class="callout">None of these are dogma — they're recorded because they're decisions, and decisions are meant to be repeatable or revisitble. This page is where revisiting starts.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="../sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="../assets/js/include.js" data-base=".."></script>
</body>
</html>
+53
View File
@@ -0,0 +1,53 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>The philosophy is the architecture — Keru OS news</title>
<meta name="description" content="Why Keru's 'you choose everything' claim is structural, not a slogan.">
<link rel="stylesheet" href="../assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="../index.html">home</a> / <a href="../news.html">news</a> / philosophy is the architecture</p>
<h1>The philosophy is the architecture</h1>
<p class="meta" style="font-family:var(--mono);color:var(--text-dim);font-size:.85rem">2026-09-01 · design</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>"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.</p>
<h3>The claim</h3>
<p>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:</p>
<ul class="features">
<li><strong>The installer encodes the choices.</strong> <code>install.sh</code> presents switches and writes them into <code>make.conf</code>. Init, libc, fs, kernel, sudo, net — each a line.</li>
<li><strong>The profile is the only interface.</strong> <code>make.conf</code> is what the build reads. There's no hidden stack to override your choices; the choices <em>are</em> the input.</li>
<li><strong>Kama executes, doesn't decide.</strong> The package manager runs recipes. It has no opinion because it has no place for one.</li>
<li><strong>The build is a pipeline of your selections.</strong> Stage 2 builds exactly <code>$KERNEL</code>, <code>$INIT</code>, <code>$SUDO</code>, <code>$NET</code>. Nothing else is possible.</li>
</ul>
<h3>Why that matters</h3>
<p>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.</p>
<h3>The boundary is honest too</h3>
<p>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 — <a href="../stability.html">the warn-not-block stance</a>. 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.</p>
<p>Read more in <a href="../philosophy.html">the philosophy</a>.</p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="../sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="../assets/js/include.js" data-base=".."></script>
</body>
</html>
+55
View File
@@ -0,0 +1,55 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>The road to 0.1 — Keru OS news</title>
<meta name="description" content="What has to exist before the first installable ISO ships.">
<link rel="stylesheet" href="../assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="../index.html">home</a> / <a href="../news.html">news</a> / road to 0.1</p>
<h1>The road to 0.1</h1>
<p class="meta" style="font-family:var(--mono);color:var(--text-dim);font-size:.85rem">2026-09-01 · roadmap</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>The first installable release, <strong>0.1</strong>, 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.</p>
<h3>The pipeline must actually build</h3>
<ul class="features">
<li><strong>Toolchain bootstrap on real hardware.</strong> binutils → gcc → libc → toolchain, from literal nothing. This is the hard step; source distros live or die here.</li>
<li><strong>A working base set.</strong> <code>base</code>, <code>toolchain</code>, <code>openssh</code>, and the tooling each swappable needs, all building against the chosen libc.</li>
<li><strong>Every offered combo, proven.</strong> The stability promise is "stable on what we offer" — so the offering must be curated to what's tested.</li>
</ul>
<h3>The ISO must boot and install</h3>
<ul class="features">
<li><strong>live/init works.</strong> The ISO boots, mounts virtual filesystems, and hands you the installer with no prompt in the way.</li>
<li><strong>Network gate works.</strong> Connectivity check, <code>nmtui</code> handoff, re-check loop — the hard requirement handled gracefully.</li>
<li><strong>The installer writes a correct profile.</strong> Menus → make.conf → build, with the stability checks warning (never blocking) along the way.</li>
<li><strong>The installed system boots.</strong> First boot runs the init you chose, on the filesystem you chose, with the kernel you chose. Fixed at first boot.</li>
</ul>
<h3>Honesty about the present</h3>
<p>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.</p>
<div class="callout">When 0.1 lands, it will be linked here and on the <a href="../install.html">install page</a>. Until then, progress shows up in the <a href="../news.html">news</a>.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="../sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="../assets/js/include.js" data-base=".."></script>
</body>
</html>
+77
View File
@@ -0,0 +1,77 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Philosophy — Keru OS</title>
<meta name="description" content="Keru's philosophy: the OS is a choice, not a conclusion. Anti-opinionated, source-only, warn-not-block stability.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / philosophy</p>
<h1>Keru's Philosophy</h1>
<p>The governing principle, in plain terms.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<blockquote><strong>The OS is a choice, not a conclusion.</strong></blockquote>
<p>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 <em>variable you resolve at install time</em>, not a fixed value baked into the distribution. Every init, every libc, every filesystem, every kernel, every privilege-elevation tool — all selectable, none forced.</p>
<hr>
<h3>Anti-opinionated, not opinionated</h3>
<p>Keru is not opinionated. It is <strong>anti-opinionated</strong>. 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 <strong>no opinion</strong> about which init, libc, filesystem, or daemon you should run, because that decision belongs to you, not to the distribution.</p>
<p>The distro's only opinion is that you have to form one. After that, it shuts up and builds exactly what you chose.</p>
<h3>Only what you asked for</h3>
<p>The install medium carries <strong>nothing but the installer</strong>. 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.</p>
<h3>Control without complexity</h3>
<p>This is the deliberate bet, and the thing that separates Keru from a Gentoo skin. The package manager, <strong>Kama</strong>, is a shell script. It reads a <code>make.conf</code> and runs recipe commands. No dependency solver. No package database. No compiled manager machinery.</p>
<blockquote>"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."</blockquote>
<p>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.</p>
<blockquote>"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."</blockquote>
<h3>Squared with reality</h3>
<p>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.</p>
<blockquote>"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."</blockquote>
<h3>Stability, honestly scoped</h3>
<p>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. <a href="stability.html">Read the stability stance in full.</a></p>
<h3>The through-line</h3>
<p>Keru's lineage ran from TOML packages to a 50-line build DSL, then to plain shell. And from <em>opinionated dogma</em> — "you get s6 and XFS whether you like it or not" — to <em>anti-opinionated anything-goes</em>. Keru keeps the from-scratch purity while rejecting the fixed dogmas outright.</p>
<blockquote>"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."</blockquote>
<p>The philosophy in one line:</p>
<blockquote><strong>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.</strong></blockquote>
<p>And in two words: <strong>anti-opinionated by design.</strong></p>
<hr>
<p><a href="anti-opinionated.html">Deeper: what anti-opinionated actually costs and grants</a> · <a href="ethos.html">The ける ethos</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+53
View File
@@ -0,0 +1,53 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Privacy — Keru OS</title>
<meta name="description" content="Keru OS's privacy stance: no telemetry, no tracking, no accounts.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / privacy</p>
<h1>Privacy</h1>
<p>Short version: there's nothing to invade.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>The OS</h3>
<ul class="features">
<li><strong>No telemetry.</strong> Keru does not phone home — not during install, not at boot, not ever.</li>
<li><strong>No accounts.</strong> There is nothing to sign up for to install or use Keru.</li>
<li><strong>No tracking.</strong> No analytics SDKs, no crash reporters, no "improve your experience" data collection.</li>
<li><strong>Nothing you didn't ask for.</strong> The only network activity comes from what you explicitly install, at install time, from the sources that package's recipe names.</li>
</ul>
<h3>This website</h3>
<ul class="features">
<li><strong>No cookies.</strong> No session tracking, no analytics scripts, no third-party trackers.</li>
<li><strong>Static files only.</strong> Plain HTML/CSS/JS. The only external requests are the web fonts (from Google Fonts). If that matters to you, the site still works without them — it falls back to system fonts.</li>
<li><strong>No accounts for content.</strong> Reading the site requires nothing.</li>
</ul>
<h3>About the download</h3>
<p>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.</p>
<div class="callout">If that changes, this page changes first — and it will be public. Keru won't decide that telemetry is "fine actually" in a changelog.</div>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+53
View File
@@ -0,0 +1,53 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Privilege elevation — Keru OS</title>
<meta name="description" content="How you gain root with Keru: doas, sudo, opendoas, or su. You decide.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="swappables.html">swappables</a> / privilege elevation</p>
<h1>Privilege elevation</h1>
<p>How you become root. Your choice.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Even "sudo" isn't sacred in Keru. How you elevate privileges is a swappable — the question of which <code>su</code>-style tool runs your privileged commands is settled by you, at install, alongside everything else.</p>
</div>
<div class="grid grid-4" style="margin-top:30px">
<div class="card"><span class="h">doas</span><p>The default. OpenBSD's elegant, minimal replacement for sudo — small config, fewer lines, no surprise policies.</p></div>
<div class="card"><span class="h">sudo</span><p>The familiar heavyweight. Fine-grained policies (<code>sudoers</code>), broad ecosystem familiarity.</p></div>
<div class="card"><span class="h">opendoas</span><p>A portable, independently-maintained doas implementation for Linux — the doas philosophy with a maintained port.</p></div>
<div class="card"><span class="h">su</span><p>The classic. No added abstraction — switch user and run what you need, as basic as it gets.</p></div>
</div>
<div class="prose" style="margin-top:34px">
<h3>Why this is on the list</h3>
<p>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, <code>doas</code>. If you need <code>sudoers</code> granularity, <code>sudo</code>. If you want zero abstraction, <code>su</code>.</p>
<p>Whichever you choose gets built in stage 2 as part of your profile, alongside your kernel and init. Nothing preinstalled, nothing assumed.</p>
<div class="callout">Small opinion, stated plainly: <code>doas</code> is the default because two lines of config beats two hundred. But it's a default, not a dogma — swap it freely.</div>
<p><a href="swappables.html">← All swappables</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+61
View File
@@ -0,0 +1,61 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Profile system — Keru OS</title>
<meta name="description" content="How Keru's profile system works: the installer writes a profile, Kama reads it, and the whole build is driven by it.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / profile</p>
<h1>Profile system</h1>
<p>The contract between "what you chose" and "what gets built."</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru's profile system is the hand-off between your decisions and the build. It's a small, open design:</p>
<h3>The flow</h3>
<ol>
<li><strong>You choose.</strong> The installer (<code>installer/install.sh</code>) walks each swappable and records your picks.</li>
<li><strong>It writes a profile.</strong> Your choices become <code>make.conf</code> — plain, readable, human-editable.</li>
<li><strong>The pipeline reads it.</strong> <code>scripts/build-root.sh</code> sources the profile and drives Kama with those exact settings.</li>
<li><strong>The system appears.</strong> Kama boots the toolchain, builds the base, brings your chosen kernel/init/sudo/net, and finalizes the filesystem your profile named.</li>
</ol>
<h3>What the profile owns</h3>
<table>
<tr><th>Layer</th><th>What it holds</th></tr>
<tr><td>Swappables</td><td><code>INIT</code>, <code>LIBC</code>, <code>TARGET_FS</code>, <code>KERNEL</code>, <code>SUDO</code>, <code>NET</code>.</td></tr>
<tr><td>Base set</td><td><code>BASE_PACKAGES</code> — what every system gets (<code>base toolchain openssh</code>).</td></tr>
<tr><td>System config</td><td><code>LOCALE</code>, <code>TIMEZONE</code>, <code>KEYMAP</code>.</td></tr>
<tr><td>Build env</td><td><code>CFLAGS</code>, <code>CXXFLAGS</code>, <code>LDFLAGS</code>, <code>JOBS</code>, <code>MAKEFLAGS</code>.</td></tr>
<tr><td>Mirrors & cache</td><td><code>SOURCE_MIRROR</code>, <code>ROOT</code>, <code>CACHEDIR</code>.</td></tr>
<tr><td>Kama behavior</td><td><code>PURGE_TEMP_DEPS</code>, <code>FAIL_FAST</code>.</td></tr>
</table>
<h3>Hand-tuning is a feature</h3>
<p>The installer is convenient, not precious. The profile it writes is just a text file — change <code>INIT=s6</code>, tweak <code>CFLAGS</code>, add a package to <code>BASE_PACKAGES</code>, and rebuild. The "craft your system" ethos extends past install into the profile itself.</p>
<div class="callout">The profile makes Keru reproducible and legible in one stroke: the same <code>make.conf</code> is the full description of the system. Read, edit, rebuild.</div>
<p><a href="make-conf.html">make.conf reference</a> · <a href="build-pipeline.html">Build pipeline</a> · <a href="docs.html">← Docs</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+115
View File
@@ -0,0 +1,115 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Recipe format — Keru OS</title>
<meta name="description" content="The formal spec for kama recipes: easy tier, advanced tier, fields, hooks, and packaging control.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / <a href="docs.html">docs</a> / recipe format</p>
<h1>Recipe format</h1>
<p>The spec for kama packages.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>A recipe is a <strong>plain POSIX shell script</strong> describing how to compile and install one piece of software. The syntax splits into two tiers:</p>
<ul class="features">
<li><strong>Easy</strong> — declare a few variables, fill in <code>build</code> and <code>install</code>, done. Covers ~90% of packages (autotools/cmake/meson).</li>
<li><strong>Advanced</strong> — full control when you need it: custom fetch/extract, staging layout, packaging hooks, multi-arch, verification. Everything the easy tier does is sugar over this.</li>
</ul>
<p>In both tiers, Kama <em>sources</em> the recipe and runs the functions you define.</p>
<hr>
<h3>Easy tier — most packages only need this</h3>
<div class="code-block">name=busybox
version=1.36.1
url=https://busybox.net/downloads/busybox-1.36.1.tar.bz2
deps=() # build-time deps, purged after (AUR-style)
build() { # configure + compile
make defconfig
make
}
install() { # install into $pkgdir (staging), not $ROOT
make install CONFIG_PREFIX="$pkgdir"
}</div>
<p>That's it. Kama supplies the conventional <code>pkg_fetch</code> (download + extract — auto-detects <code>.tar.xz/.gz/.bz2/.zip</code>, strips the top directory) and <code>pkg_clean</code>.</p>
<hr>
<h3>Advanced tier — override any step</h3>
<div class="code-block">name=busybox
version=1.36.1
url=https://busybox.net/downloads/busybox-1.36.1.tar.bz2
deps=(gcc musl-headers) # temp build deps (AUR-style)
runtime_deps=(musl) # stays installed
license=(GPL-2.0)
provides=(sh) # capability this package provides
conflicts=(dash) # mutual exclusion
arch=(x86_64) # if non-empty, restrict to archs
noextract=() # URLs to download but NOT auto-extract
# override auto extract (e.g. patching before configure)
pkg_fetch() {
default_fetch # run the easy-tier default
cd "$src"
patch -p1 &lt; ../my.patch
}
build() { ./configure --prefix=/usr "$@" &amp;&amp; make; }
install() { make install DESTDIR="$pkgdir"; }</div>
<h3>Fields</h3>
<table>
<tr><th>Field</th><th>Purpose</th></tr>
<tr><td><code>name</code></td><td>Package name. Required.</td></tr>
<tr><td><code>version</code></td><td>Release version. Required for fetch.</td></tr>
<tr><td><code>url</code></td><td>Upstream source (or list).</td></tr>
<tr><td><code>deps</code></td><td>Build-time dependencies — compiled, installed, then purged (AUR-style).</td></tr>
<tr><td><code>runtime_deps</code></td><td>Dependencies that stay installed.</td></tr>
<tr><td><code>license</code></td><td>SPDX license identifiers.</td></tr>
<tr><td><code>provides</code></td><td>Capabilities this package provides (virtuals).</td></tr>
<tr><td><code>conflicts</code></td><td>Mutual exclusions.</td></tr>
<tr><td><code>arch</code></td><td>Architecture allow-list; empty means any.</td></tr>
<tr><td><code>noextract</code></td><td>URLs downloaded but not auto-extracted.</td></tr>
</table>
<h3>Hooks and functions</h3>
<table>
<tr><th>Function</th><th>Role</th></tr>
<tr><td><code>build()</code></td><td>Configure + compile, run in the extracted source dir.</td></tr>
<tr><td><code>install()</code></td><td>Install into the staging dir (<code>$pkgdir</code>/<code>DESTDIR</code>), not the live root.</td></tr>
<tr><td><code>pkg_fetch()</code></td><td>Override download/extract (can call <code>default_fetch</code>).</td></tr>
<tr><td><code>pkg_clean()</code></td><td>Override source cleanup.</td></tr>
<tr><td><code>pkg_post()</code></td><td>Post-install hook, called after staging.</td></tr>
<tr><td><code>pkg_split()</code></td><td>Optional splitting of staged output into subpackages.</td></tr>
</table>
<div class="callout">The full spec lives in the repo at <code>docs/recipe-format.md</code>. The web version mirrors it; the canonical source is the repository.</div>
<p><a href="kama-recipes.html">The recipe concept</a> · <a href="kama.html">← Kama</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+112
View File
@@ -0,0 +1,112 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Sitemap — Keru OS</title>
<meta name="description" content="The complete sitemap for the Keru OS website.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / sitemap</p>
<h1>Sitemap</h1>
<p>Every page on this site.</p>
</header>
<section>
<div class="wrap">
<div class="grid grid-2">
<div>
<span class="tag">landing</span>
<ul class="features">
<li><a href="index.html">Home</a></li>
</ul>
<span class="tag">about</span>
<ul class="features">
<li><a href="about.html">About Keru OS</a></li>
<li><a href="philosophy.html">Philosophy</a></li>
<li><a href="anti-opinionated.html">Anti-opinionated</a></li>
<li><a href="stability.html">Stability</a></li>
<li><a href="ethos.html">Ethos</a></li>
</ul>
<span class="tag">install</span>
<ul class="features">
<li><a href="install.html">Install</a></li>
<li><a href="installer-walkthrough.html">Installer walkthrough</a></li>
<li><a href="installation-requirements.html">Requirements</a></li>
<li><a href="network-setup.html">Network setup</a></li>
</ul>
</div>
<div>
<span class="tag">swappables</span>
<ul class="features">
<li><a href="swappables.html">All swappables</a></li>
<li><a href="inits.html">Init systems</a></li>
<li><a href="libcs.html">C libraries</a></li>
<li><a href="filesystems.html">Filesystems</a></li>
<li><a href="kernels.html">Kernels</a></li>
<li><a href="privilege-elevation.html">Privilege elevation</a></li>
<li><a href="network-tools.html">Network tools</a></li>
</ul>
<span class="tag">kama</span>
<ul class="features">
<li><a href="kama.html">Kama overview</a></li>
<li><a href="kama-usage.html">Kama usage</a></li>
<li><a href="kama-recipes.html">Kama recipes</a></li>
<li><a href="kama-repos.html">Kama repos</a></li>
</ul>
<span class="tag">docs</span>
<ul class="features">
<li><a href="docs.html">Docs</a></li>
<li><a href="make-conf.html">make.conf</a></li>
<li><a href="profile.html">Profile system</a></li>
<li><a href="recipe-format.html">Recipe format</a></li>
<li><a href="build-pipeline.html">Build pipeline</a></li>
<li><a href="mkfs-root.html">mkfs-root</a></li>
<li><a href="live-init.html">Live init</a></li>
</ul>
</div>
<div>
<span class="tag">news</span>
<ul class="features">
<li><a href="news.html">News</a></li>
<li><a href="news/announcing-keru.html">Introducing Keru OS</a></li>
<li><a href="news/philosophy-is-architecture.html">The philosophy is the architecture</a></li>
<li><a href="news/roadmap-0.1.html">The road to 0.1</a></li>
<li><a href="news/design-decisions.html">Design decisions, so far</a></li>
</ul>
<span class="tag">community</span>
<ul class="features">
<li><a href="community.html">Community</a></li>
<li><a href="contribute.html">Contribute</a></li>
<li><a href="faq.html">FAQ</a></li>
<li><a href="contact.html">Contact</a></li>
<li><a href="links.html">Links</a></li>
</ul>
<span class="tag">legal</span>
<ul class="features">
<li><a href="license.html">License</a></li>
<li><a href="privacy.html">Privacy</a></li>
<li><a href="credits.html">Credits</a></li>
</ul>
</div>
</div>
<div class="prose" style="margin-top:40px">
<p>Total: 32 pages, all served from <code>web/</code> in the KeruOS repo — plain static HTML, no framework, dark, with a shared nav/footer injected at runtime.</p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">This is the sitemap. If nav/footer didn't load, it's because JS is off — links above still work.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+75
View File
@@ -0,0 +1,75 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Stability — Keru OS</title>
<meta name="description" content="Keru's stability promise: the system won't break for any choice Keru offers you. Past that, it warns and steps aside — you're never blocked.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / stability</p>
<h1>Stability</h1>
<p>Guaranteed on what's offered. Never enforced on you.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<h3>The promise, scoped</h3>
<p>Keru's definition of stable is direct: <strong>the system won't break.</strong> But that promise is only honest if it's scoped. Keru guarantees it <strong>on the combinations it offers you.</strong></p>
<p>That's what it means for the installer to offer a choice in the first place: each option in <code>install.sh</code> is one Keru has proven builds and boots. The offered set is curated <em>so that</em> 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.</p>
<h3>But you're never locked out</h3>
<p>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 <strong>not</strong> stop you. It <strong>warns you</strong> the combination is unstable and lets you proceed.</p>
<blockquote>"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."</blockquote>
<p>The full definition, in one line:</p>
<blockquote><strong>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.</strong></blockquote>
<h3>How the warning shows up</h3>
<p>The installer runs a stability check after your selections. Known-risky combinations are flagged before anything is written:</p>
<div class="code-block"><span class="tag warn">WARNING</span>
uclibc-ng + runit: not yet proven to build and boot together
musl + systemd: not yet proven to build and boot together
this combination is unstable. Keru won't stop you — build at your own risk.</div>
<p>Some of the pairs Keru currently warns about:</p>
<table>
<tr><th>Combination</th><th>Why it's flagged</th></tr>
<tr><td>uclibc-ng + anything</td><td>Pre-0.1, not yet proven to build and boot end to end.</td></tr>
<tr><td>musl + systemd</td><td>Systemd and musl are a known-hard pairing.</td></tr>
<tr><td>zfs as root fs</td><td>Needs kernel module + ZFS userspace; not yet proven.</td></tr>
<tr><td>reiserfs</td><td>Unmaintained; no stable future.</td></tr>
</table>
<h3>What stability means for choices that work</h3>
<ul class="features">
<li><strong>Reproducible.</strong> The same <code>make.conf</code> builds the same system.</li>
<li><strong>Predictable.</strong> What you chose is what boots. No surprises smuggled in by defaults.</li>
<li><strong>Kama never lies.</strong> The package manager's job is to do exactly what a recipe says — reliably, silently, and correctly.</li>
</ul>
<h3>The honest trade-off</h3>
<p>"Extremely stable" and "everything is swappable" pull in opposite directions. Most famously-stable distros (Debian) gain stability by <em>shrinking</em> choice. Keru's stability therefore isn't "fewest things possible" — it's <strong>"whatever you chose, it builds and boots predictably, and Keru never hides a risk from you."</strong></p>
<p><a href="philosophy.html">← Back to the philosophy</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>
+54
View File
@@ -0,0 +1,54 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Swappables — Keru OS</title>
<meta name="description" content="The Keru differentiator: every major component — init, libc, filesystem, kernel, privilege elevation, networking — is chosen by you at install time.">
<link rel="stylesheet" href="assets/css/style.css">
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>ける</text></svg>">
</head>
<body>
<nav class="top" data-nav></nav>
<header class="pagehead">
<p class="crumbs"><a href="index.html">home</a> / swappables</p>
<h1>The Swappables</h1>
<p>Every foundational component, yours to choose at install time.</p>
</header>
<section>
<div class="wrap">
<div class="prose">
<p>Keru's differentiator is one sentence: <strong>nothing is fixed, nothing you didn't ask for is forced on you.</strong> The installer presents each foundational component as a flat, open choice, and the system that boots is assembled from exactly the ones you picked.</p>
<p>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 <em>your</em> decision, made once, at install.</p>
</div>
<div class="grid grid-2" style="margin-top:34px">
<a class="card" href="inits.html"><span class="num">init</span><span class="h">Init system</span><p>Who brings your system up at boot. runit, s6, openrc, systemd, busybox-init, sysvinit, dinit, shepherd.</p></a>
<a class="card" href="libcs.html"><span class="num">libc</span><span class="h">C library</span><p>The foundation under everything that runs. glibc, musl, uclibc-ng.</p></a>
<a class="card" href="filesystems.html"><span class="num">fs</span><span class="h">Filesystem</span><p>The shape of your disk. ext4, btrfs, xfs, zfs, f2fs, jfs, reiserfs, swap.</p></a>
<a class="card" href="kernels.html"><span class="num">kernel</span><span class="h">Kernel</span><p>The spine of the machine. linux, linux-lts, linux-hardened, linux-cachyos, linux-zen.</p></a>
<a class="card" href="privilege-elevation.html"><span class="num">priv</span><span class="h">Privilege elevation</span><p>How you elevate. doas, sudo, opendoas, su.</p></a>
<a class="card" href="network-tools.html"><span class="num">net</span><span class="h">Network tools</span><p>How the network is managed. networkmanager, connman, systemd-networkd, nmtui alone.</p></a>
</div>
<div class="prose" style="margin-top:40px">
<h3>Beyond the big six</h3>
<p>Kernel parameters, locale, clock, and keymap are all configurable too — surfaced through <code>make.conf</code>, the profile that your choices produce. The swappables aren't a fixed list; they're a stance. <a href="make-conf.html">Read the make.conf reference.</a></p>
<h3>Stability is scoped to these</h3>
<p>Because choice multiplies the surface, Keru is stable on the combinations it offers, and warns (never blocks) beyond that. <a href="stability.html">How that works.</a></p>
</div>
</div>
</section>
<footer data-footer></footer>
<noscript><div style="text-align:center;padding:16px">See the <a href="sitemap.html">sitemap</a> for all pages.</div></noscript>
<script src="assets/js/include.js" data-base="."></script>
</body>
</html>