move website out to its own repo
This commit is contained in:
Astral
@@ -1,29 +0,0 @@
|
||||
name: Deploy website to GitHub Pages
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
pages: write
|
||||
id-token: write
|
||||
|
||||
concurrency:
|
||||
group: pages
|
||||
cancel-in-progress: true
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
environment:
|
||||
name: github-pages
|
||||
url: ${{ steps.deployment.outputs.page_url }}
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/upload-pages-artifact@v3
|
||||
with:
|
||||
path: web
|
||||
- uses: actions/deploy-pages@v4
|
||||
id: deployment
|
||||
@@ -1,82 +0,0 @@
|
||||
<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="./getting-started.html">Getting started</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="./recipe-authoring.html">Recipe authoring</a></li>
|
||||
<li><a href="./build-pipeline.html">Build pipeline</a></li>
|
||||
<li><a href="./toolchain.html">Toolchain bootstrap</a></li>
|
||||
<li><a href="./kama-config.html">Kama config</a></li>
|
||||
<li><a href="./mirror-cache.html">Mirrors & cache</a></li>
|
||||
<li><a href="./security.html">Security</a></li>
|
||||
<li><a href="./troubleshooting.html">Troubleshooting</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>
|
||||
@@ -1,10 +0,0 @@
|
||||
<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>
|
||||
@@ -1,57 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,66 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,511 +0,0 @@
|
||||
/* Keru OS website — Ryoku-style.
|
||||
Pure-black paper, warm bone ink, one vermillion accent.
|
||||
Radius 0. No shadow. Flat hairline surfaces. Monospace tech labels.
|
||||
Animations are loud enough to feel alive, flat enough to stay cool. */
|
||||
|
||||
@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 {
|
||||
--paper: #000000; /* pure black paper */
|
||||
--paper-2: #0d0d0d; /* raised surface */
|
||||
--paper-3: #131313; /* cards */
|
||||
--hair: #262626; /* hairline borders */
|
||||
--ink: #cdc4ba; /* warm bone ink — body */
|
||||
--ink-dim: #8b8275; /* subdued ink */
|
||||
--ink-faint: #5b5348; /* farthest faded */
|
||||
--bone: #f2ede4; /* bright ink, emphasis */
|
||||
--accent: #ff3b1f; /* vermillion — the single accent */
|
||||
--ok: #58e1c2;
|
||||
--warn: #f0a35e;
|
||||
--danger: #ff3b1f;
|
||||
--mono: 'JetBrains Mono', ui-monospace, monospace;
|
||||
--sans: 'Inter', system-ui, -apple-system, sans-serif;
|
||||
--radius: 0; /* sharp. always. */
|
||||
--nav-h: 60px;
|
||||
}
|
||||
|
||||
* { margin: 0; padding: 0; box-sizing: border-box; }
|
||||
::selection { background: var(--accent); color: #000; }
|
||||
html { scroll-behavior: smooth; }
|
||||
|
||||
body {
|
||||
background: var(--paper);
|
||||
color: var(--ink);
|
||||
font-family: var(--sans);
|
||||
line-height: 1.65;
|
||||
-webkit-font-smoothing: antialiased;
|
||||
overflow-x: hidden;
|
||||
}
|
||||
|
||||
/* faint scanline texture — a taste of grain, no image */
|
||||
body::before {
|
||||
content: "";
|
||||
position: fixed;
|
||||
inset: 0;
|
||||
z-index: -1;
|
||||
background:
|
||||
repeating-linear-gradient(180deg, transparent 0 3px, rgba(255,255,255,.008) 3px 4px);
|
||||
pointer-events: none;
|
||||
}
|
||||
|
||||
a { color: var(--ink); text-decoration: none; }
|
||||
a:hover { color: var(--bone); }
|
||||
|
||||
/* ---------- top nav ---------- */
|
||||
nav.top {
|
||||
position: sticky;
|
||||
top: 0;
|
||||
z-index: 100;
|
||||
height: var(--nav-h);
|
||||
background: rgba(0,0,0,.9);
|
||||
backdrop-filter: blur(8px);
|
||||
border-bottom: 1px solid var(--hair);
|
||||
display: flex;
|
||||
align-items: center;
|
||||
padding: 0 26px;
|
||||
gap: 4px;
|
||||
}
|
||||
.brand {
|
||||
font-family: var(--mono);
|
||||
font-weight: 700;
|
||||
color: var(--bone);
|
||||
font-size: 1rem;
|
||||
letter-spacing: .02em;
|
||||
margin-right: auto;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 9px;
|
||||
}
|
||||
.brand .kanji {
|
||||
color: var(--accent);
|
||||
font-size: 1.15rem;
|
||||
text-shadow: 0 0 14px rgba(255,59,31,.55);
|
||||
}
|
||||
.brand:hover { text-decoration: none; }
|
||||
|
||||
nav.top a.navlink {
|
||||
color: var(--ink-dim);
|
||||
font-family: var(--mono);
|
||||
text-transform: uppercase;
|
||||
font-size: .72rem;
|
||||
letter-spacing: .12em;
|
||||
padding: 6px 10px;
|
||||
border: 1px solid transparent;
|
||||
transition: color .15s, border-color .15s, background .15s;
|
||||
}
|
||||
nav.top a.navlink:hover {
|
||||
color: var(--bone);
|
||||
border-color: var(--hair);
|
||||
background: var(--paper-2);
|
||||
text-decoration: none;
|
||||
}
|
||||
.menu-toggle { display: none; }
|
||||
|
||||
/* ---------- hero ---------- */
|
||||
.hero { padding: 84px 26px 54px; text-align: center; }
|
||||
|
||||
.kicker {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
gap: 10px;
|
||||
font-family: var(--mono);
|
||||
color: var(--ink-dim);
|
||||
text-transform: uppercase;
|
||||
font-size: .72rem;
|
||||
letter-spacing: .22em;
|
||||
border: 1px solid var(--hair);
|
||||
background: var(--paper-2);
|
||||
padding: 5px 14px;
|
||||
}
|
||||
.kicker .dot {
|
||||
width: 7px; height: 7px; background: var(--accent);
|
||||
animation: pulse 1.6s infinite;
|
||||
}
|
||||
.kicker .dot.dim { background: var(--ink-faint); }
|
||||
|
||||
.hero .seal {
|
||||
font-size: 5rem;
|
||||
line-height: 1;
|
||||
color: var(--bone);
|
||||
user-select: none;
|
||||
display: block;
|
||||
margin: 18px auto 6px;
|
||||
animation: fadeUp .7s ease both;
|
||||
}
|
||||
.hero h1 {
|
||||
font-family: var(--mono);
|
||||
font-size: clamp(1.6rem, 4vw, 2.6rem);
|
||||
font-weight: 700;
|
||||
line-height: 1.1;
|
||||
color: var(--bone);
|
||||
letter-spacing: .02em;
|
||||
margin: 14px auto 16px;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
.hero h1 .grad { color: var(--accent); }
|
||||
.hero p.sub { color: var(--ink-dim); max-width: 620px; margin: 0 auto 30px; font-size: 1rem; }
|
||||
|
||||
.cta-row { display: flex; gap: 12px; justify-content: center; flex-wrap: wrap; }
|
||||
.btn {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
gap: 10px;
|
||||
font-family: var(--mono);
|
||||
text-transform: uppercase;
|
||||
letter-spacing: .1em;
|
||||
font-size: .78rem;
|
||||
font-weight: 700;
|
||||
padding: 12px 22px;
|
||||
border: 1px solid var(--ink-dim);
|
||||
color: var(--bone);
|
||||
transition: color .15s, background .15s, border-color .15s, transform .1s;
|
||||
}
|
||||
.btn:hover { text-decoration: none; }
|
||||
.btn-primary { background: var(--accent); border-color: var(--accent); color: #000; }
|
||||
.btn-primary:hover { background: #000; color: var(--accent); }
|
||||
.btn-ghost { background: transparent; color: var(--ink-dim); }
|
||||
.btn-ghost:hover { background: var(--paper-2); color: var(--bone); border-color: var(--accent); }
|
||||
|
||||
/* ---------- marquee ticker ---------- */
|
||||
.ticker {
|
||||
overflow: hidden;
|
||||
border-top: 1px solid var(--hair);
|
||||
border-bottom: 1px solid var(--hair);
|
||||
padding: 13px 0;
|
||||
background: var(--paper-2);
|
||||
white-space: nowrap;
|
||||
}
|
||||
.ticker-inner {
|
||||
display: inline-block;
|
||||
animation: ticker 32s linear infinite;
|
||||
font-family: var(--mono);
|
||||
font-size: .8rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: .1em;
|
||||
color: var(--ink-faint);
|
||||
}
|
||||
.ticker-inner span { margin: 0 26px; }
|
||||
.ticker-inner b { color: var(--bone); font-weight: 500; }
|
||||
.ticker-inner .a { color: var(--accent); }
|
||||
|
||||
/* ---------- sections ---------- */
|
||||
section { padding: 54px 26px; }
|
||||
.wrap { max-width: 1080px; margin: 0 auto; }
|
||||
|
||||
.section-title {
|
||||
font-family: var(--mono);
|
||||
text-transform: uppercase;
|
||||
letter-spacing: .2em;
|
||||
font-size: .7rem;
|
||||
color: var(--accent);
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
.section-title::before { content: "// "; opacity: .6; }
|
||||
h2.head {
|
||||
font-family: var(--mono);
|
||||
font-size: clamp(1.25rem, 3vw, 1.9rem);
|
||||
color: var(--bone);
|
||||
font-weight: 700;
|
||||
margin-bottom: 12px;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: .02em;
|
||||
}
|
||||
.lead { color: var(--ink-dim); font-size: 1rem; max-width: 720px; margin-bottom: 28px; }
|
||||
|
||||
.grid { display: grid; gap: 18px; }
|
||||
.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(--paper-2);
|
||||
border: 1px solid var(--hair);
|
||||
padding: 20px;
|
||||
position: relative;
|
||||
transition: border-color .15s, transform .1s, background .15s;
|
||||
}
|
||||
.card::before {
|
||||
content: "";
|
||||
position: absolute;
|
||||
left: 0; top: 0; bottom: 0;
|
||||
width: 2px;
|
||||
background: var(--accent);
|
||||
transform: scaleY(0);
|
||||
transform-origin: top;
|
||||
transition: transform .25s cubic-bezier(.2,.8,.2,1);
|
||||
}
|
||||
.card:hover { border-color: var(--accent); background: var(--paper-3); transform: translateY(-2px); }
|
||||
.card:hover::before { transform: scaleY(1); }
|
||||
.card.h {
|
||||
font-family: var(--mono);
|
||||
font-size: 1rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: .06em;
|
||||
color: var(--bone);
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.card p { color: var(--ink-dim); font-size: .92rem; }
|
||||
.card .num {
|
||||
font-family: var(--mono);
|
||||
font-size: .68rem;
|
||||
letter-spacing: .14em;
|
||||
text-transform: uppercase;
|
||||
color: var(--accent);
|
||||
border: 1px solid var(--hair);
|
||||
padding: 2px 8px;
|
||||
display: inline-block;
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
a.card { color: inherit; }
|
||||
a.card:hover { text-decoration: none; }
|
||||
|
||||
/* ---------- terminal / code ---------- */
|
||||
.terminal {
|
||||
background: #050505;
|
||||
border: 1px solid var(--hair);
|
||||
overflow: hidden;
|
||||
text-align: left;
|
||||
margin: 0 auto;
|
||||
max-width: 660px;
|
||||
}
|
||||
.terminal .tbar {
|
||||
background: var(--paper-2);
|
||||
padding: 9px 12px;
|
||||
display: flex;
|
||||
gap: 6px;
|
||||
align-items: center;
|
||||
border-bottom: 1px solid var(--hair);
|
||||
}
|
||||
.terminal .tbar span.dot { width: 9px; height: 9px; display: inline-block; }
|
||||
.terminal .tbar .r { background: var(--danger); }
|
||||
.terminal .tbar .y { background: var(--warn); }
|
||||
.terminal .tbar .g { background: var(--ok); }
|
||||
.terminal .tbar .t {
|
||||
margin-left: 10px;
|
||||
font-family: var(--mono);
|
||||
font-size: .72rem;
|
||||
color: var(--ink-faint);
|
||||
text-transform: uppercase;
|
||||
letter-spacing: .1em;
|
||||
}
|
||||
.terminal pre { padding: 18px; overflow-x: auto; font-family: var(--mono); font-size: .84rem; line-height: 1.75; color: var(--ink); }
|
||||
.terminal .c { color: var(--accent); }
|
||||
.terminal .k { color: var(--bone); }
|
||||
.terminal .p { color: var(--ink-faint); }
|
||||
|
||||
pre, code, kbd { font-family: var(--mono); }
|
||||
.code-block {
|
||||
background: #050505;
|
||||
border: 1px solid var(--hair);
|
||||
border-left: 3px solid var(--accent);
|
||||
padding: 18px;
|
||||
overflow-x: auto;
|
||||
margin: 18px 0;
|
||||
font-size: .84rem;
|
||||
line-height: 1.7;
|
||||
color: var(--ink);
|
||||
}
|
||||
code:not(.code-block) {
|
||||
background: var(--paper-2);
|
||||
border: 1px solid var(--hair);
|
||||
padding: 2px 6px;
|
||||
font-size: .85em;
|
||||
color: var(--accent);
|
||||
}
|
||||
kbd {
|
||||
background: var(--paper-2);
|
||||
border: 1px solid var(--hair);
|
||||
border-bottom-width: 2px;
|
||||
padding: 1px 6px;
|
||||
font-size: .8em;
|
||||
}
|
||||
|
||||
/* ---------- prose ---------- */
|
||||
.prose { max-width: 760px; margin: 0 auto; }
|
||||
.prose h3 {
|
||||
font-family: var(--mono);
|
||||
text-transform: uppercase;
|
||||
letter-spacing: .04em;
|
||||
color: var(--bone);
|
||||
font-size: 1.1rem;
|
||||
margin: 32px 0 10px;
|
||||
font-weight: 700;
|
||||
}
|
||||
.prose h3::before { content: "# "; color: var(--accent); }
|
||||
.prose h4 { color: var(--accent); margin: 22px 0 8px; font-size: .95rem; font-family: var(--mono); }
|
||||
.prose p { margin: 12px 0; color: var(--ink); }
|
||||
.prose ul, .prose ol { margin: 12px 0 12px 22px; }
|
||||
.prose li { margin: 6px 0; color: var(--ink); }
|
||||
.prose li::marker { color: var(--accent); }
|
||||
.prose blockquote {
|
||||
border-left: 3px solid var(--accent);
|
||||
background: var(--paper-2);
|
||||
padding: 14px 18px;
|
||||
margin: 18px 0;
|
||||
color: var(--ink-dim);
|
||||
}
|
||||
.prose blockquote strong { color: var(--bone); }
|
||||
.prose hr { border: none; border-top: 1px solid var(--hair); margin: 30px 0; }
|
||||
|
||||
table { border-collapse: collapse; width: 100%; margin: 18px 0; font-size: .92rem; }
|
||||
th, td { border: 1px solid var(--hair); padding: 9px 12px; text-align: left; }
|
||||
th { background: var(--paper-2); color: var(--bone); font-family: var(--mono); font-size: .78rem; text-transform: uppercase; letter-spacing: .05em; }
|
||||
tr:nth-child(even) td { background: rgba(255,255,255,.02); }
|
||||
|
||||
/* tags / callouts */
|
||||
.tag {
|
||||
display: inline-block;
|
||||
font-family: var(--mono);
|
||||
font-size: .66rem;
|
||||
letter-spacing: .12em;
|
||||
text-transform: uppercase;
|
||||
padding: 2px 9px;
|
||||
border: 1px solid var(--hair);
|
||||
color: var(--ink-dim);
|
||||
margin: 2px 4px 2px 0;
|
||||
}
|
||||
.tag.warn { color: var(--warn); border-color: var(--warn); }
|
||||
.tag.danger { color: var(--danger); border-color: var(--danger); }
|
||||
.tag.ok { color: var(--ok); border-color: var(--ok); }
|
||||
.tag.accent { color: var(--accent); border-color: var(--accent); }
|
||||
|
||||
.callout {
|
||||
border: 1px solid var(--hair);
|
||||
border-left: 3px solid var(--accent);
|
||||
background: var(--paper-2);
|
||||
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(--ok); }
|
||||
|
||||
.features { list-style: none; margin: 0; }
|
||||
.features li { padding: 9px 0; border-bottom: 1px solid var(--hair); display: flex; gap: 12px; color: var(--ink); }
|
||||
.features li::before { content: "▸"; color: var(--accent); }
|
||||
|
||||
/* ---------- news ---------- */
|
||||
.post-list { max-width: 820px; margin: 0 auto; }
|
||||
.post-item {
|
||||
display: block;
|
||||
background: var(--paper-2);
|
||||
border: 1px solid var(--hair);
|
||||
padding: 20px 22px;
|
||||
margin-bottom: 14px;
|
||||
transition: border-color .15s, transform .1s;
|
||||
}
|
||||
.post-item:hover { transform: translateX(4px); border-color: var(--accent); text-decoration: none; }
|
||||
.post-item h3 { color: var(--bone); font-family: var(--mono); font-size: 1.05rem; text-transform: uppercase; letter-spacing: .03em; margin-bottom: 6px; }
|
||||
.post-item .meta { font-family: var(--mono); font-size: .72rem; color: var(--ink-faint); text-transform: uppercase; letter-spacing: .1em; margin-bottom: 6px; }
|
||||
.post-item p { color: var(--ink-dim); font-size: .92rem; }
|
||||
|
||||
/* ---------- footer ---------- */
|
||||
footer { border-top: 1px solid var(--hair); background: var(--paper-2); padding: 38px 26px 30px; margin-top: 40px; }
|
||||
footer .wrap { display: flex; gap: 34px; flex-wrap: wrap; justify-content: space-between; }
|
||||
footer h4 { color: var(--bone); font-family: var(--mono); font-size: .72rem; text-transform: uppercase; letter-spacing: .16em; margin-bottom: 12px; }
|
||||
footer h4::before { content: "// "; color: var(--accent); }
|
||||
footer ul { list-style: none; }
|
||||
footer li { margin: 6px 0; }
|
||||
footer a { color: var(--ink-dim); }
|
||||
footer a:hover { color: var(--bone); text-decoration: none; }
|
||||
footer .foot {
|
||||
margin-top: 28px;
|
||||
padding-top: 18px;
|
||||
border-top: 1px solid var(--hair);
|
||||
font-family: var(--mono);
|
||||
font-size: .72rem;
|
||||
color: var(--ink-faint);
|
||||
text-align: center;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: .12em;
|
||||
}
|
||||
footer .marks { color: var(--accent); }
|
||||
|
||||
/* ---------- stats ---------- */
|
||||
.stats { display: flex; gap: 30px; flex-wrap: wrap; justify-content: center; margin: 22px 0; }
|
||||
.stat { text-align: center; border: 1px solid var(--hair); padding: 18px 26px; background: var(--paper-2); min-width: 150px; }
|
||||
.stat .big { font-family: var(--mono); font-size: 2.2rem; font-weight: 700; color: var(--bone); }
|
||||
.stat .lbl { color: var(--ink-faint); font-size: .72rem; text-transform: uppercase; letter-spacing: .12em; font-family: var(--mono); }
|
||||
|
||||
/* dossier block (Ryoku-style system sheet) */
|
||||
.dossier {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 1px;
|
||||
background: var(--hair);
|
||||
border: 1px solid var(--hair);
|
||||
margin: 26px auto;
|
||||
max-width: 680px;
|
||||
text-align: left;
|
||||
}
|
||||
.dossier .row {
|
||||
background: var(--paper-2);
|
||||
padding: 12px 18px;
|
||||
font-family: var(--mono);
|
||||
font-size: .78rem;
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
gap: 16px;
|
||||
}
|
||||
.dossier .row .lbl { color: var(--ink-faint); text-transform: uppercase; letter-spacing: .1em; }
|
||||
.dossier .row .val { color: var(--bone); text-align: right; }
|
||||
.dossier .row .val.a { color: var(--accent); }
|
||||
|
||||
/* ---------- animations ---------- */
|
||||
@keyframes fadeUp {
|
||||
from { opacity: 0; transform: translateY(14px); }
|
||||
to { opacity: 1; transform: translateY(0); }
|
||||
}
|
||||
@keyframes fadeLeft {
|
||||
from { opacity: 0; transform: translateX(-14px); }
|
||||
to { opacity: 1; transform: translateX(0); }
|
||||
}
|
||||
@keyframes pulse { 0%,100% { opacity: 1; } 50% { opacity: .25; } }
|
||||
@keyframes blink { 0%,49% { opacity: 1; } 50%,100% { opacity: 0; } }
|
||||
@keyframes ticker { from { transform: translateX(0); } to { transform: translateX(-50%); } }
|
||||
@keyframes sweep {
|
||||
0% { background-position: -200% 0; }
|
||||
100% { background-position: 200% 0; }
|
||||
}
|
||||
|
||||
.reveal { animation: fadeUp .6s ease both; }
|
||||
.d1 { animation-delay: .08s; }
|
||||
.d2 { animation-delay: .16s; }
|
||||
.d3 { animation-delay: .24s; }
|
||||
.d4 { animation-delay: .32s; }
|
||||
.d5 { animation-delay: .40s; }
|
||||
|
||||
/* blinking caret after brand */
|
||||
.caret { display: inline-block; width: 8px; height: 1em; background: var(--accent); margin-left: 2px; vertical-align: -0.15em; animation: blink 1.1s infinite; }
|
||||
|
||||
/* accent headline underline sweep on hover */
|
||||
.head { background: linear-gradient(90deg, var(--accent), var(--accent), var(--accent)) no-repeat;
|
||||
background-size: 0% 2px; background-position: 0 100%; transition: background-size .3s ease; }
|
||||
.head:hover { background-size: 100% 2px; }
|
||||
|
||||
/* text flicker on the kanji seal */
|
||||
.seal { animation: flicker 4s infinite; }
|
||||
@keyframes flicker {
|
||||
0%,100% { opacity: 1; }
|
||||
92% { opacity: 1; } 93% { opacity: .4; } 94% { opacity: 1; }
|
||||
}
|
||||
|
||||
/* ---------- pagehead ---------- */
|
||||
.pagehead { padding: 64px 26px 30px; text-align: center; }
|
||||
.pagehead h1 { font-family: var(--mono); text-transform: uppercase; letter-spacing: .02em; color: var(--bone); font-size: clamp(1.6rem, 4vw, 2.4rem); font-weight: 700; }
|
||||
.pagehead p { color: var(--ink-dim); max-width: 620px; margin: 12px auto 0; }
|
||||
.crumbs { font-family: var(--mono); font-size: .72rem; color: var(--ink-faint); text-transform: uppercase; letter-spacing: .12em; max-width: 760px; margin: 18px auto 0; }
|
||||
.crumbs a { color: var(--ink-dim); }
|
||||
.crumbs a:hover { color: var(--accent); }
|
||||
.crumbs span { color: var(--accent); }
|
||||
|
||||
/* responsive */
|
||||
@media (max-width: 720px) {
|
||||
nav.top { padding: 0 14px; }
|
||||
nav.top a.navlink { display: none; }
|
||||
.menu-toggle { display: inline-flex; }
|
||||
.hero { padding: 56px 18px 34px; }
|
||||
section { padding: 38px 18px; }
|
||||
footer .wrap { gap: 20px; }
|
||||
.dossier { grid-template-columns: 1fr; }
|
||||
}
|
||||
@@ -1,41 +0,0 @@
|
||||
/* 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');
|
||||
})();
|
||||
@@ -1,78 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,50 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,63 +0,0 @@
|
||||
<!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; email 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">direct</span>
|
||||
<span class="h">Email</span>
|
||||
<p>Longer conversations about philosophy, design decisions, and direction.</p>
|
||||
<p><a href="mailto:[email protected]">[email protected]</a></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>
|
||||
@@ -1,65 +0,0 @@
|
||||
<!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><pkg>.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>
|
||||
@@ -1,56 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,50 +0,0 @@
|
||||
<!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="getting-started.html"><span class="num">guide</span><span class="h">Getting started</span><p>From booting the ISO to a first-boot system — the whole arc in one read.</p></a>
|
||||
<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="recipe-authoring.html"><span class="num">howto</span><span class="h">Recipe authoring</span><p>Write your first kama recipe, with real examples from the repo.</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="toolchain.html"><span class="num">reference</span><span class="h">Toolchain bootstrap</span><p>binutils → gcc → libc → self-host: what "from scratch" means.</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="kama-config.html"><span class="num">reference</span><span class="h">Kama configuration</span><p>Every kama variable: PKGDIR, ROOT, CACHEDIR, MAKE_CONF, mirrors.</p></a>
|
||||
<a class="card" href="mirror-cache.html"><span class="num">reference</span><span class="h">Mirrors & cache</span><p>The download order and the dl/src/stage cache layout.</p></a>
|
||||
<a class="card" href="security.html"><span class="num">reference</span><span class="h">Security</span><p>Trust model of a source-only build, stated plainly.</p></a>
|
||||
<a class="card" href="troubleshooting.html"><span class="num">guide</span><span class="h">Troubleshooting</span><p>Diagnose by stage — boot, network, fetch, build, finalize.</p></a>
|
||||
<a class="card" href="release-process.html"><span class="num">reference</span><span class="h">Release process</span><p>What a release contains, and how versioning works.</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>
|
||||
@@ -1,61 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,68 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,61 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,77 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Getting started — Keru OS</title>
|
||||
<meta name="description" content="From booting the Keru ISO to a first-boot system: prerequisites, the install flow, network, and day one.">
|
||||
<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> / getting started</p>
|
||||
<h1>Getting started</h1>
|
||||
<p>Zero to a chosen, booting, source-built system.</p>
|
||||
</header>
|
||||
|
||||
<section>
|
||||
<div class="wrap">
|
||||
<div class="prose">
|
||||
<p>Keru 0.1 ships as an ISO. There is no source build to DIY, no binary download, no flashing a rootfs tarball. Boot the ISO, answer the installer, and Keru builds exactly what you chose while you watch.</p>
|
||||
|
||||
<h3>Before you begin</h3>
|
||||
<ul class="features">
|
||||
<li><strong>A working network.</strong> The build is fully online — every source tarball is downloaded fresh at install time.</li>
|
||||
<li><strong>A spare target disk.</strong> <code>mkfs-root.sh</code> formats whatever root device the installer points at. It will be written over.</li>
|
||||
<li><strong>Patience for the first build.</strong> Fetch + compile of the full toolchain and system takes a while on modest hardware.</li>
|
||||
<li><strong>Decisions.</strong> Prep your picks ahead — or just press enter; sane defaults are documented on every prompt.</li>
|
||||
</ul>
|
||||
|
||||
<h3>The flow</h3>
|
||||
<div class="code-block">1. Write the ISO to USB sudo dd if=keru-0.1.iso of=/dev/sdX bs=4M status=progress
|
||||
2. Boot the stick BIOS/UEFI → the live image starts by itself
|
||||
3. live/init mounts & runs the installer launches automatically on boot
|
||||
4. Connect to the network the installer runs nmtui for you when offline
|
||||
5. Make your picks init · libc · fs · kernel · sudo · net
|
||||
6. Keru builds the system fetch → stage 0 toolchain → base → swappables
|
||||
7. First boot your crafted system, exactly as chosen</div>
|
||||
|
||||
<h3>Your picks</h3>
|
||||
<table>
|
||||
<tr><th>Choice</th><th>Default</th><th>Why you might change it</th></tr>
|
||||
<tr><td>Init system</td><td><code>runit</code></td><td>systemd for optional use — but Keru never forces it.</td></tr>
|
||||
<tr><td>C library</td><td><code>glibc</code></td><td>musl for a smaller static-leaning system.</td></tr>
|
||||
<tr><td>Filesystem</td><td><code>ext4</code></td><td>btrfs snapshots, zfs features, xfs scaling.</td></tr>
|
||||
<tr><td>Kernel</td><td><code>linux</code></td><td>linux-lts for longevity, hardened for attacks.</td></tr>
|
||||
<tr><td>Privilege elevation</td><td><code>doas</code></td><td>sudo if you live in its muscle memory.</td></tr>
|
||||
<tr><td>Network tools</td><td><code>nmtui</code></td><td>networkmanager, connman, or systemd-networkd.</td></tr>
|
||||
</table>
|
||||
|
||||
<div class="callout">Every option here has a dedicated page. See <a href="swappables.html">the swappables guide</a> and its sub-pages before you install, so boot rehearsal is boring by design.</div>
|
||||
|
||||
<h3>Day one</h3>
|
||||
<p>Keru installs a bare, honest base — the packages you chose plus the few kama needs to run. From there you shape the rest:</p>
|
||||
<div class="code-block"># your system, your way
|
||||
kama make vim # build anything else from source
|
||||
kama info busybox # peek at a recipe's metadata
|
||||
doas kama install tmux</div>
|
||||
<p>Everything you don't install, you don't get. No services pretending to be useful, no telemetry phone-home.</p>
|
||||
|
||||
<div class="callout ok">Now read the <a href="installer-walkthrough.html">installer walkthrough</a> for the fine detail, or go straight to <a href="troubleshooting.html">troubleshooting</a> when something surprises you.</div>
|
||||
|
||||
<p><a href="install.html">← Install overview</a> · <a href="network-setup.html">Network setup</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>
|
||||
-135
@@ -1,135 +0,0 @@
|
||||
<!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 reveal"><span class="dot"></span> independent · source-only · linux</span>
|
||||
<span class="seal reveal d1">ける</span>
|
||||
<h1 class="reveal d1">You don't install a system.<br>You <span class="grad">craft</span> one.</h1>
|
||||
<p class="sub reveal d2">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 reveal d3">
|
||||
<a class="btn btn-primary" href="install.html">↓ Install 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="dossier reveal d4">
|
||||
<div class="row"><span class="lbl">Name</span><span class="val">Keru OS ける</span></div>
|
||||
<div class="row"><span class="lbl">Status</span><span class="val a">UNDER CONSTRUCTION</span></div>
|
||||
<div class="row"><span class="lbl">Distribution</span><span class="val">source-only linux</span></div>
|
||||
<div class="row"><span class="lbl">Package manager</span><span class="val">kama · ~225 lines</span></div>
|
||||
<div class="row"><span class="lbl">Defining trait</span><span class="val">anti-opinionated</span></div>
|
||||
<div class="row"><span class="lbl">Opinions forced</span><span class="val a">0</span></div>
|
||||
<div class="row"><span class="lbl">Base packages</span><span class="val">0 (everything is swappable)</span></div>
|
||||
<div class="row"><span class="lbl">Model</span><span class="val">boot ISO → choose → built from source</span></div>
|
||||
</div>
|
||||
|
||||
<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 class="a">ける・けいとうてき <b>— craft your system</b></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(--paper-2);border-top:1px solid var(--hair);border-bottom:1px solid var(--hair)">
|
||||
<div class="wrap">
|
||||
<p class="section-title" style="text-align:center">live boot</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, live.</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="background:var(--paper-2);border-top:1px solid var(--hair)">
|
||||
<div class="wrap" style="text-align:center">
|
||||
<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>
|
||||
@@ -1,55 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,75 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,61 +0,0 @@
|
||||
<!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 fetches source tarballs (straight from upstream, or via a mirror when <code>SOURCE_MIRROR</code> is set) and pulls package recipes from the GitHub-hosted <a href="kama-repos.html">recipe repository</a>. 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>
|
||||
@@ -1,113 +0,0 @@
|
||||
<!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>) 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>
|
||||
@@ -1,77 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Kama configuration — Keru OS</title>
|
||||
<meta name="description" content="The full kama configuration reference: PKGDIR, CACHEDIR, ROOT, MAKE_CONF, PURGE_TEMP_DEPS, SOURCE_MIRROR, and the cache layout.">
|
||||
<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> / kama configuration</p>
|
||||
<h1>Kama configuration</h1>
|
||||
<p>Every knob, every default, every path.</p>
|
||||
</header>
|
||||
|
||||
<section>
|
||||
<div class="wrap">
|
||||
<div class="prose">
|
||||
<p>Kama's configuration is environment variables. Nothing to edit inside the script, nothing hidden — set them in the environment (<code>export</code> in a profile, or inline on the command line) and it's done.</p>
|
||||
|
||||
<h3>Variables</h3>
|
||||
<table>
|
||||
<tr><th>Variable</th><th>Default</th><th>What it controls</th></tr>
|
||||
<tr><td><code>PKGDIR</code></td><td>the kama-packages repo, sibling of the kama script</td><td>Where recipes are found.</td></tr>
|
||||
<tr><td><code>ROOT</code></td><td><code>/tmp/keru/root</code></td><td>Where installed files land.</td></tr>
|
||||
<tr><td><code>CACHEDIR</code></td><td><code>/var/cache/kama</code></td><td>Base for the dirty working dirs.</td></tr>
|
||||
<tr><td><code>MAKE_CONF</code></td><td><code>/etc/kama/make.conf</code></td><td>Profile settings (JOBS, CFLAGS, etc.) if present.</td></tr>
|
||||
<tr><td><code>SOURCE_MIRROR</code></td><td>unset</td><td>Mirror tried before upstream (set to e.g. <code>mirror.example.org</code>).</td></tr>
|
||||
<tr><td><code>PURGE_TEMP_DEPS</code></td><td><code>1</code></td><td>Purge temp build deps after <code>kama make</code>.</td></tr>
|
||||
<tr><td><code>JOBS</code></td><td><code>nproc</code></td><td>Parallel build jobs; recipes call <code>make -j"$JOBS"</code>.</td></tr>
|
||||
</table>
|
||||
|
||||
<h3>Cache layout</h3>
|
||||
<div class="code-block">$CACHEDIR/
|
||||
├── dl/ downloaded archives
|
||||
├── src/ extracted source per package
|
||||
└── stage/ staged installs, committed to $ROOT on success</div>
|
||||
|
||||
<h3>Common setups</h3>
|
||||
<div class="code-block"># build into a scratch root
|
||||
ROOT=/mnt/keru-root kama make busybox
|
||||
|
||||
# migrate cache to a big disk
|
||||
export CACHEDIR=/mnt/cache/kama
|
||||
export SOURCE_MIRROR=https://mirror.example.org
|
||||
|
||||
# keep temp deps this run (default removes them)
|
||||
PURGE_TEMP_DEPS=0 kama make firefox</div>
|
||||
|
||||
<h3>make.conf integration</h3>
|
||||
<p>Inside an installed Keru system, the profile at <code>MAKE_CONF</code> feeds the same variables into kama and the build scripts. Your <a href="make-conf.html">make.conf reference</a> lists the full set.</p>
|
||||
|
||||
<ul class="features">
|
||||
<li>If <code>MAKE_CONF</code> exists it is sourced; missing is not an error.</li>
|
||||
<li>The installer writes <code>JOBS</code> and <code>CFLAGS</code> from build-host detection.</li>
|
||||
<li>Every variable has a sane default, so kama runs with zero config.</li>
|
||||
</ul>
|
||||
|
||||
<div class="callout">Zero-config by default, fully pointed overrides when you need them. That's the whole story — read on for <a href="recipe-format.html">recipes</a>.</div>
|
||||
|
||||
<p><a href="kama-usage.html">← kama usage</a> · <a href="make-conf.html">make.conf</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>
|
||||
@@ -1,80 +0,0 @@
|
||||
<!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/<pkg>/PKGBUILD</code>, then <code>PKGDIR/<pkg>.sh</code>, then <code>PKGDIR/<pkg>/*.sh</code>. Naming a recipe file <code><pkg>.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>
|
||||
@@ -1,74 +0,0 @@
|
||||
<!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>Where the repos live</h3>
|
||||
<div class="code-block">github.com/AstralZX/kama # the manager (canonical)
|
||||
github.com/AstralZX/kama-packages # the recipe repository (canonical)
|
||||
github.com/AstralZX/KeruOS # the OS itself (canonical)
|
||||
|
||||
git.spectoria.dev/AstralZX/kama # mirror
|
||||
git.spectoria.dev/AstralZX/kama-packages # mirror
|
||||
git.spectoria.dev/AstralZX/KeruOS # mirror</div>
|
||||
<p>The canonical host is <strong>GitHub</strong>. Mirrors of all three repos now live on <code>git.spectoria.dev</code>. They are read-mirrors — push and issues stay on GitHub, and the mirrors can fall behind by however long it's been since the last sync. A Codeberg mirror is also under consideration.</p>
|
||||
|
||||
<div class="callout">No package recipes ship on the ISO, in the installer, or anywhere else. The recipe repository on GitHub is how you get packages — clone it or install Keru, which fetches it at build time.</div>
|
||||
|
||||
<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>
|
||||
@@ -1,79 +0,0 @@
|
||||
<!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 <pkg></code></td><td>Download and extract source for a package into the cache.</td></tr>
|
||||
<tr><td><code>kama build <pkg></code></td><td>Stage-build one package (configure/make) into its stage dir.</td></tr>
|
||||
<tr><td><code>kama install <pkg></code></td><td>Build + install a package into <code>$ROOT</code> (staging-aware).</td></tr>
|
||||
<tr><td><code>kama make <pkg></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 <pkg></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 a mirror you run 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>
|
||||
@@ -1,59 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,55 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,53 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,51 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,62 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,65 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,97 +0,0 @@
|
||||
<!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"
|
||||
|
||||
# Mirror for source tarballs (unset: fetch straight from upstream)
|
||||
# SOURCE_MIRROR="https://mirror.example.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>
|
||||
@@ -1,73 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Mirrors and cache — Keru OS</title>
|
||||
<meta name="description" content="How Keru and Kama download source tarballs: an optional mirror you run, upstream as fallback, and the download/source/stage cache layout.">
|
||||
<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> / mirrors & cache</p>
|
||||
<h1>Mirrors and cache</h1>
|
||||
<p>Where source comes from, and where it waits.</p>
|
||||
</header>
|
||||
|
||||
<section>
|
||||
<div class="wrap">
|
||||
<div class="prose">
|
||||
<p>Every Keru build is a network operation. Package recipes always come from the GitHub-hosted <a href="kama-repos.html">kama-packages</a> repo; this page is about the other half — the <em>source tarballs</em> each recipe downloads, and the cache they pass through.</p>
|
||||
|
||||
<h3>Download order</h3>
|
||||
<ul class="features">
|
||||
<li><strong>1. <code>SOURCE_MIRROR</code></strong> — tried first when set; run a mirror of source tarballs and point it here.</li>
|
||||
<li><strong>2. Upstream</strong> — the canonical source URL from the recipe. Used when no mirror is set or the mirror lacks a file.</li>
|
||||
<li><strong>Verification at every step.</strong> A file that doesn't match its checksum is dropped, and the next source in line is tried. Tampered files never reach a build.</li>
|
||||
</ul>
|
||||
|
||||
<h3>The cache layout</h3>
|
||||
<div class="code-block">/var/cache/kama/ # CACHEDIR (set CACHEDIR=/path to relocate)
|
||||
├── dl/ # downloaded tarballs, one per package
|
||||
├── src/ # extracted source (per package dir)
|
||||
└── stage/ # staged installs before they commit to $ROOT</div>
|
||||
|
||||
<table>
|
||||
<tr><th>Dir</th><th>Everything</th><th>Purpose</th></tr>
|
||||
<tr><td><code>dl</code></td><td>Downloads</td><td>Already-downloaded archives are reused, never re-fetched.</td></tr>
|
||||
<tr><td><code>src</code></td><td>Extracted</td><td>Extraction is skipped when the checked-out source is present.</td></tr>
|
||||
<tr><td><code>stage</code></td><td>Staged builds</td><td>Progress survives a failed build; re-running continues.</td></tr>
|
||||
</table>
|
||||
|
||||
<h3>Working offline, or your own mirror</h3>
|
||||
<div class="code-block"># warm the cache once, then build with the network down
|
||||
SOURCE_MIRROR=https://mirror.example.org kama fetch busybox
|
||||
...
|
||||
CACHEDIR=/var/cache/kama kama make busybox # no network needed</div>
|
||||
<p>Run a mirror yourself and point <code>SOURCE_MIRROR</code> at it. The layout mirrors <code>dl/</code>; the fetch layer treats it as a read-mostly source of truth.</p>
|
||||
|
||||
<h3>Cleanup</h3>
|
||||
<ul class="features">
|
||||
<li><code>rm -rf /var/cache/kama/src/*</code> — free extracted source (re-extracts on next build).</li>
|
||||
<li><code>rm -rf /var/cache/kama/dl/*</code> — dump downloads (re-fetches next time).</li>
|
||||
<li><code>rm -rf /var/cache/kama/stage/*</code> — discard staged builds.</li>
|
||||
</ul>
|
||||
|
||||
<div class="callout">A corrupt cache is the #1 source of confusing fetch errors. When in doubt, clear the relevant dir — downloads verify anyway, so you lose nothing but time.</div>
|
||||
|
||||
<p><a href="kama-usage.html">← kama usage</a> · <a href="troubleshooting.html">Troubleshooting</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>
|
||||
@@ -1,49 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,65 +0,0 @@
|
||||
<!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>) 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>
|
||||
@@ -1,54 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,52 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,55 +0,0 @@
|
||||
<!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(--ink-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>
|
||||
@@ -1,58 +0,0 @@
|
||||
<!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(--ink-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>
|
||||
@@ -1,53 +0,0 @@
|
||||
<!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(--ink-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>
|
||||
@@ -1,55 +0,0 @@
|
||||
<!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(--ink-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>
|
||||
@@ -1,77 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,53 +0,0 @@
|
||||
<!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 GitHub (a release asset). Nothing is recorded beyond what your server and service logs necessarily keep. If a mirror is ever added, this page will say so.</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>
|
||||
@@ -1,53 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,61 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,97 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Recipe authoring — Keru OS</title>
|
||||
<meta name="description" content="A practical HOWTO for writing kama package recipes: easy tier, real examples, common patterns, and how to get it merged into 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="docs.html">docs</a> / recipe authoring</p>
|
||||
<h1>Recipe authoring</h1>
|
||||
<p>Writing a kama recipe, top to bottom.</p>
|
||||
</header>
|
||||
|
||||
<section>
|
||||
<div class="wrap">
|
||||
<div class="prose">
|
||||
<p>Every package in a Keru system is described by a recipe: a plain POSIX shell script in <code>kama-packages</code>. Writing one is closer to filling a form than engineering a build.</p>
|
||||
|
||||
<h3>The template</h3>
|
||||
<p><code>kama-packages/TEMPLATE.sh</code> is the canonical starting point. Copy it, fill the easy tier:</p>
|
||||
<div class="code-block">name=hello # required
|
||||
version=2.12.1 # required for fetch
|
||||
url=https://ftp.gnu.org/gnu/hello/hello-2.12.1.tar.gz
|
||||
deps=() # build-time deps, compiled then purged
|
||||
|
||||
build() {
|
||||
./configure --prefix=/usr
|
||||
make -j"$JOBS"
|
||||
}
|
||||
|
||||
install() {
|
||||
make install DESTDIR="$pkgdir" # stage, never $ROOT
|
||||
}</div>
|
||||
|
||||
<h3>A real, complete recipe</h3>
|
||||
<p>This is the entire busybox recipe currently in the repo:</p>
|
||||
<div class="code-block">name=busybox
|
||||
version=1.36.1
|
||||
url=https://busybox.net/downloads/busybox-1.36.1.tar.bz2
|
||||
deps=()
|
||||
|
||||
build() {
|
||||
make defconfig
|
||||
make -j"$JOBS"
|
||||
}
|
||||
|
||||
install() {
|
||||
make install CONFIG_PREFIX="$pkgdir"
|
||||
}</div>
|
||||
<p>That's it. Kama downloads, extracts, strips the top dir, builds, stages, and installs.</p>
|
||||
|
||||
<h3>Stepping up</h3>
|
||||
<table>
|
||||
<tr><th>Need</th><th>Field / function</th></tr>
|
||||
<tr><td>Colliding with another package</td><td><code>provides=(...) conflicts=(...)</code></td></tr>
|
||||
<tr><td>Build deps that must stay</td><td><code>runtime_deps=(...)</code></td></tr>
|
||||
<tr><td>Arch-restricted</td><td><code>arch=(x86_64)</code></td></tr>
|
||||
<tr><td>Repo or vcs sources</td><td><code>noextract=("$url")</code> + own <code>build()</code></td></tr>
|
||||
<tr><td>Custom fetch (patch first)</td><td><code>pkg_fetch() { default_fetch; patch ...; }</code></td></tr>
|
||||
<tr><td>Post-install work</td><td><code>pkg_post()</code> · <code>pkg_split()</code> for subpackages</td></tr>
|
||||
</table>
|
||||
|
||||
<h3>Rules of the road</h3>
|
||||
<ul class="features">
|
||||
<li><strong>Stage, don't touch.</strong> <code>install()</code> installs into <code>$pkgdir</code>. Kama commits the staging dir to <code>$ROOT</code> only after a successful build.</li>
|
||||
<li><strong>Add pure build deps to <code>deps</code>.</strong> They're purged automatically after the build (AUR-style). Keeps the door clean.</li>
|
||||
<li><strong>Declare the license.</strong> <code>license=(SPDX)</code> — supply chain cleanliness starts here.</li>
|
||||
<li><strong>Pin exactly.</strong> A fixed <code>url</code> + <code>version</code>, never a moving "latest".</li>
|
||||
</ul>
|
||||
|
||||
<h3>Checking your work</h3>
|
||||
<div class="code-block">sh -n recipe.sh # syntax check
|
||||
kama info <pkgname> # metadata parses (name from the recipe)
|
||||
make recipe-check # lint the whole kama-packages repo
|
||||
kama make <pkgname> # build it for real</div>
|
||||
|
||||
<div class="callout">The behavioral spec lives at <a href="recipe-format.html">recipe format</a>. For hands-on, mirror the <a href="kama-recipes.html">recipe concept</a> page and start with <code>busybox.sh</code>, the smallest real recipe.</div>
|
||||
|
||||
<p><a href="recipe-format.html">← Recipe format</a> · <a href="kama-repos.html">The repos</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>
|
||||
@@ -1,115 +0,0 @@
|
||||
<!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 < ../my.patch
|
||||
}
|
||||
|
||||
build() { ./configure --prefix=/usr "$@" && 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>
|
||||
@@ -1,67 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Release process — Keru OS</title>
|
||||
<meta name="description" content="How Keru versions work, what a release contains, and the honest '0.1 when it's ready' timeline.">
|
||||
<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> / release process</p>
|
||||
<h1>Release process</h1>
|
||||
<p>How a release leaves the kiln.</p>
|
||||
</header>
|
||||
|
||||
<section>
|
||||
<div class="wrap">
|
||||
<div class="prose">
|
||||
<p>Keru's releases are honest about being releases: each one is a tested point in time of the three repos, assembled into an ISO that boots and installs without fanfare.</p>
|
||||
|
||||
<h3>Versioning</h3>
|
||||
<div class="code-block">keru-0.1.0.iso # {major}.{minor}.{patch}</div>
|
||||
<table>
|
||||
<tr><th>Bump</th><th>When</th></tr>
|
||||
<tr><td>major</td><td>The swappable set changes shape, or the philosophy moves — real milestones like the first ISO.</td></tr>
|
||||
<tr><td>minor</td><td>New swappable or a new kama feature that stays backward-compatible.</td></tr>
|
||||
<tr><td>patch</td><td>Recipe fixes, installer bugfixes, docs — anything that changes no contracts.</td></tr>
|
||||
</table>
|
||||
|
||||
<h3>What the release ISO contains</h3>
|
||||
<ul class="features">
|
||||
<li><strong>The installer.</strong> <code>installer/install.sh</code> plus its payload.</li>
|
||||
<li><strong>The live init.</strong> <code>live/init</code> — boot the ISO, installer auto-runs.</li>
|
||||
<li><strong>The repos.</strong> kama and kama-packages pinned at the release commit.<br>Everything else — every source tarball, every toolchain compile — is fetched and built at install time.</li>
|
||||
</ul>
|
||||
|
||||
<h3>Release readiness</h3>
|
||||
<table>
|
||||
<tr><th>Check</th><th>What passes it</th></tr>
|
||||
<tr><td>Combos boot</td><td>The proven set of the offered swappables all boot after install.</td></tr>
|
||||
<tr><td>Installer clean</td><td>A full install from a cold boot, no keyboard runtime.</td></tr>
|
||||
<tr><td>No blockers</td><td>Nothing warns-but-doesn't-block where it shouldn't; unproven combos warn loudly.</td></tr>
|
||||
<tr><td>Docs match</td><td>make.conf, recipes, and this website agree with the shipped code.</td></tr>
|
||||
</table>
|
||||
|
||||
<h3>Announcements</h3>
|
||||
<p>Releases are announced on the <a href="news.html">news page</a>, with a changelog and the exact repos/commits the ISO was cut from. "0.1 when it's ready" — as tracked in the status above — remains the only roadmap.</p>
|
||||
|
||||
<div class="callout">Deliberately unglamorous. A release is a checkpoint the community can trust, not a marketing event. Read the <a href="news.html">news</a> for the current one.</div>
|
||||
|
||||
<p><a href="contribute.html">Contribute</a> · <a href="news.html">→ Status / news</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>
|
||||
@@ -1,68 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Security — Keru OS</title>
|
||||
<meta name="description" content="Keru's trust model: source-only builds, verification against fetch, no binary packages, a small auditable toolchain, and clean licensing.">
|
||||
<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> / security</p>
|
||||
<h1>Security</h1>
|
||||
<p>The trust model, stated plainly.</p>
|
||||
</header>
|
||||
|
||||
<section>
|
||||
<div class="wrap">
|
||||
<div class="prose">
|
||||
<p>Keru's security stance follows from its design. No binaries, no opaque machinery, no hidden services. That shrinks the attack surface to things you can actually read.</p>
|
||||
|
||||
<h3>Source-only by construction</h3>
|
||||
<p>There is no binary package store to compromise. Every package is compiled in your install from original source fetched over the network. The "prebuilt artifact" class of attack simply doesn't exist.</p>
|
||||
|
||||
<h3>Verified fetch</h3>
|
||||
<ul class="features">
|
||||
<li><strong>Mirror then upstream.</strong> Downloads try <code>SOURCE_MIRROR</code> when set and fall back to upstream. Unset — the default — they go straight to upstream.</li>
|
||||
<li><strong>Integrity enforced.</strong> A fetched tarball that doesn't verify is refused, not untarred. Failed verification is a hard stop.</li>
|
||||
<li><strong>Pinned sources.</strong> Recipes pin the exact <code>url</code> and version. Nothing is ever pulled "latest" implicitly.</li>
|
||||
</ul>
|
||||
|
||||
<h3>A toolchain you can audit</h3>
|
||||
<div class="code-block">scripts/build-root.sh # ~shell; reads your make.conf
|
||||
profile/make.conf # your choices, explicit
|
||||
kama # ~225-line package manager
|
||||
kama-packages/*.sh # recipes as plain shell you can read top to bottom</div>
|
||||
<p>The whole vertical slice from "make.conf" to "booted system" is a handful of shell files. That's the honest counter to the "trust the distro binary blob" model.</p>
|
||||
|
||||
<h3>Privilege by your rules</h3>
|
||||
<p>Privilege elevation is swappable: <code>doas</code> (slender, auditable) is the default, with sudo, opendoas, and plain <code>su</code> available. Keru never preloads root-owned services or hidden daemons.</p>
|
||||
|
||||
<h3>Kernel hardening, if you want it</h3>
|
||||
<p>Pick <code>linux-hardened</code> at install for a hardened kernel, or stick with stable <code>linux</code>. The choice is yours and applied at the moment your system is built.</p>
|
||||
|
||||
<h3>Licensing, because supply chain is security</h3>
|
||||
<p>All three repos are <span class="tag accent">AGPL-3.0</span>. Recipes tag their <code>license</code> explicitly. Nothing in the pipeline is proprietary-black-boxed.</p>
|
||||
|
||||
<div class="callout">Trust is transitive: you still trust the sources you install and any mirror you point at. Keru's job is to make that trust chain visible and verifiable — not to pretend you can be protected from everything.</div>
|
||||
|
||||
<h3>Reporting</h3>
|
||||
<p>Found a flaw in the installer, kama, or a recipe? File it with the stage and the failing artifact. See <a href="contact.html">contact</a> and <a href="troubleshooting.html">troubleshooting</a>.</p>
|
||||
|
||||
<p><a href="troubleshooting.html">← Troubleshooting</a> · <a href="toolchain.html">Toolchain bootstrap →</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>
|
||||
@@ -1,120 +0,0 @@
|
||||
<!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="getting-started.html">Getting started</a></li>
|
||||
<li><a href="installation-requirements.html">Requirements</a></li>
|
||||
<li><a href="installer-walkthrough.html">Installer walkthrough</a></li>
|
||||
<li><a href="network-setup.html">Network setup</a></li>
|
||||
<li><a href="troubleshooting.html">Troubleshooting</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="recipe-authoring.html">Recipe authoring</a></li>
|
||||
<li><a href="build-pipeline.html">Build pipeline</a></li>
|
||||
<li><a href="toolchain.html">Toolchain bootstrap</a></li>
|
||||
<li><a href="mkfs-root.html">mkfs-root</a></li>
|
||||
<li><a href="live-init.html">Live init</a></li>
|
||||
<li><a href="kama-config.html">Kama configuration</a></li>
|
||||
<li><a href="mirror-cache.html">Mirrors & cache</a></li>
|
||||
<li><a href="security.html">Security</a></li>
|
||||
<li><a href="release-process.html">Release process</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: 48 pages, all served from <code>web/</code> in the KeruOS repo — plain static HTML, no framework, pure black, 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>
|
||||
@@ -1,75 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,54 +0,0 @@
|
||||
<!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>
|
||||
@@ -1,68 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Toolchain bootstrap — Keru OS</title>
|
||||
<meta name="description" content="Stage 0 in depth: how Keru bootstraps binutils, gcc, and a C library from nothing, and then builds everything else on top.">
|
||||
<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> / toolchain</p>
|
||||
<h1>Toolchain bootstrap</h1>
|
||||
<p>What "from scratch" actually means.</p>
|
||||
</header>
|
||||
|
||||
<section>
|
||||
<div class="wrap">
|
||||
<div class="prose">
|
||||
<p>A source distro that seeds its compiler is a lie wearing a costume. Keru's stage 0 builds the toolchain from nothing — the assembler, the compiler, the C library, then a self-hosted toolchain package — before a single package in your system tree is compiled.</p>
|
||||
|
||||
<h3>Why the order matters</h3>
|
||||
<table>
|
||||
<tr><th>Step</th><th>What runs</th><th>Why first</th></tr>
|
||||
<tr><td>1</td><td><code>binutils</code></td><td>as, ld, ar — you can't compile without an assembler and linker.</td></tr>
|
||||
<tr><td>2</td><td>a bare <code>gcc</code></td><td>The C compiler, built against nothing but binutils.</td></tr>
|
||||
<tr><td>3</td><td>your <code>libc</code></td><td>glibc, musl, or uclibc-ng. Everything userspace depends on it.</td></tr>
|
||||
<tr><td>4</td><td>a full <code>gcc</code></td><td>Re-built now that the target libc exists (self-hosting).</td></tr>
|
||||
<tr><td>5</td><td><code>toolchain</code> package</td><td>Freezes the whole toolchain as a kama package for the rest of the build.</td></tr>
|
||||
</table>
|
||||
|
||||
<h3>A bootstrap run</h3>
|
||||
<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> stage 0: bootstrap toolchain
|
||||
<span class="c">[ keru ]</span> binutils 2.42 <span class="p">... ok</span>
|
||||
<span class="c">[ keru ]</span> gcc 13.2 (bare) <span class="p">... ok</span>
|
||||
<span class="c">[ keru ]</span> glibc 2.39 <span class="p">... ok</span>
|
||||
<span class="c">[ keru ]</span> gcc 13.2 (self) <span class="p">... ok</span>
|
||||
<span class="c">[ keru ]</span> toolchain → ROOT <span class="k">... ok</span>
|
||||
<span class="c">[ keru ]</span> stage 1: base system</pre>
|
||||
</div>
|
||||
|
||||
<h3>Where it goes wrong</h3>
|
||||
<ul class="features">
|
||||
<li><strong>libc switch.</strong> Bootstrapping against musl or uclibc-ng rearranges the early stages; the exact package set lives with the <a href="libcs.html">libc page</a>. A combo that isn't proven yet gets a warning — never a silent block.</li>
|
||||
<li><strong>Host leakage.</strong> Everything must link against the freshly built chain, not the build host's. The recipes pass explicit <code>--host/--target</code> and <code>CC</code>/<code>CFLAGS</code> so nothing sneaks in.</li>
|
||||
<li><strong>Double-build cost.</strong> gcc is compiled twice by design. That's the price of honesty; it's also a warm-up for the rest of the arch.</li>
|
||||
</ul>
|
||||
|
||||
<div class="callout">This is the line Keru draws: before your base system, a full self-hosting toolchain exists that didn't exist before. After that, the rest is just — as one long build script — more of the same.</div>
|
||||
|
||||
<p><a href="security.html">← Security</a> · <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>
|
||||
@@ -1,78 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Troubleshooting — Keru OS</title>
|
||||
<meta name="description" content="Common Keru problems by stage — live boot, network, fetch, build, install, first boot — and how to fix each.">
|
||||
<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> / troubleshooting</p>
|
||||
<h1>Troubleshooting</h1>
|
||||
<p>Diagnose by stage. The stage points at the file to blame.</p>
|
||||
</header>
|
||||
|
||||
<section>
|
||||
<div class="wrap">
|
||||
<div class="prose">
|
||||
<p>Almost every Keru failure lands in exactly one of five stages: <strong>live boot</strong>, <strong>network</strong>, <strong>fetch</strong>, <strong>build</strong>, or <strong>finalize</strong>. Figure out which, and you're most of the way to a fix.</p>
|
||||
|
||||
<h3>Live boot</h3>
|
||||
<table>
|
||||
<tr><th>Symptom</th><th>Cause / fix</th></tr>
|
||||
<tr><td>Drops to an emergency shell</td><td><code>live/init</code> couldn't find the installer payload or mount buffers. Check the ISO layout and that you wrote the whole image, not just the files.</td></tr>
|
||||
<tr><td>Installer never auto-starts</td><td>The live init runs <code>installer/install.sh</code> on boot. Run it by hand from the shell to see its errors directly.</td></tr>
|
||||
<tr><td>Nothing on screen</td><td>Terminal TTY not your display? Verify the kernel picks your console; a plain <code>getty</code> on tty1 is the default.</td></tr>
|
||||
</table>
|
||||
|
||||
<h3>Network</h3>
|
||||
<ul class="features">
|
||||
<li><strong>Installer says offline.</strong> It probes several hosts (<code>1.1.1.1</code>, <code>github.com</code>) and loops: it will offer to run <code>nmtui</code>, then re-check. Let it. GitHub reachability matters — package recipes are fetched from GitHub.</li>
|
||||
<li><strong>DHCP won't bite.</strong> Use <code>nmtui</code> and set a static address. The installer doesn't care how the link comes up, only that it does.</li>
|
||||
<li><strong>Slow fetch.</strong> When <code>SOURCE_MIRROR</code> is set it's tried first; upstream is the fallback. A broken mirror yields timeouts — fix or unset <code>SOURCE_MIRROR</code>.</li>
|
||||
</ul>
|
||||
|
||||
<h3>Fetch</h3>
|
||||
<ul class="features">
|
||||
<li><strong>404 on a download.</strong> The recipe's <code>url</code> missed a version bump. Fix it or report it — sources are pinned in kama-packages.</li>
|
||||
<li><strong>Checksum mismatch.</strong> The tarball in the cache doesn't match the recipe. Clear the cache dir for that package: <code>rm -rf /var/cache/kama/dl/<pkg></code>.</li>
|
||||
<li><strong>Mirror poison.</strong> If a third-party mirror serves a tampered file, fetch fails verification and refuses to proceed — by design.</li>
|
||||
</ul>
|
||||
|
||||
<h3>Build</h3>
|
||||
<table>
|
||||
<tr><th>Symptom</th><th>Cause / fix</th></tr>
|
||||
<tr><td>Compile error in a package</td><td>Often a <code>C(FLAGS)</code> interaction or a missing build dep. Add the dep and re-run <code>kama make</code> — stage dirs cache progress.</td></tr>
|
||||
<tr><td>Missing header</td><td>That's a temp-dep gap in the recipe's <code>deps=()</code>. Contribute the fix: one line in kama-packages.</td></tr>
|
||||
<tr><td>Toolchain failure</td><td>Stage 0 is the sharpest edge. A failing binutils/gcc/libc bootstrap is a bug — file it with the full <code>make.conf</code> combo.</td></tr>
|
||||
<tr><td>Kernel build dies with no reason</td><td>Free disk or memory on the build host first; kernel builds are hungry. Then check <code>KERNEL_CONFIG</code> in make.conf.</td></tr>
|
||||
</table>
|
||||
|
||||
<h3>Finalize and first boot</h3>
|
||||
<ul class="features">
|
||||
<li><strong>mkfs fails.</strong> The target device is in use or the filesystem tools for your pick are missing. Unmount and retry.</li>
|
||||
<li><strong>Won't boot.</strong> The init you chose must agree with how your bootloader was told to run it — check the boot command line and your init's expectations.</li>
|
||||
<li><strong>No network after boot.</strong> Your network tool choice (nmtui alone won't auto-connect) needs to be started on <code>default</code> runlevel or its service enabled.</li>
|
||||
<li><strong>Unstable combo.</strong> Keru warns on unproven pairs (musl+systemd, uclibc-ng, zfs root ...). Heed the warning or expect rough edges. It never blocks you.</li>
|
||||
</ul>
|
||||
|
||||
<div class="callout">When you file an issue, include the stage, your full <code>make.conf</code> combo, and the failing output. That's everything a maintainer needs. See <a href="contact.html">contact</a>.</div>
|
||||
|
||||
<p><a href="getting-started.html">← Getting started</a> · <a href="security.html">Security model →</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>
|
||||
Reference in New Issue
Block a user