nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/docs/Website/download.html
Nexoniarz 6490e5c759 site: rebuilt on Niveus, and the palette stops being a copy 
Niveus is the interface language the project uses from here on -- this site
first, applications after it. Rebuilding the site on it is what proves the
system is one, rather than a folder of CSS with a README.

**`style.css` is gone.** 21 KB that transcribed include/theme.h by hand:
palette, type scale, shadows, spacing, every component. The intent was right --
"a site describing an operating system should look like the operating system"
-- and the mechanism was a copy, which means two files that have to be kept in
step by remembering to. What replaced it is `app.css`, which is layout and
nothing else, and one declaration in each page:

    :root { --nv-brand: #7C5CFF; }

That is SCH_ACCENT. Niveus derives the accent and its states, the link colour,
the focus ring, the tint in the greys and how far the status colours lean, for
light and dark both. One number to keep true instead of forty.

**The site is now adaptive.** Dark by default, because the OS is dark, with a
Light/Dark/Auto group in the bar that is real. The choice is kept in
localStorage and re-applied by an inline script before first paint, so the page
never renders in one appearance and corrects itself while you watch.

**PSOGM keeps its one purple, and now says so structurally.** #4B1D9A is
spelled the way Niveus spells a subtree with its own colour -- `data-nv-brand`
with its own `--nv-brand` on that section -- so every role inside re-derives
from it rather than being painted on. Still exactly one place, which is what
branding/README.md asks for.

Content is unchanged; what changed is what it is made of. Cards are `.nv-card`,
tags are `.nv-badge`, the support table is `.nv-table`, the crash section is a
`.nv-bed`, and the docs reader's two rails are `.nv-nav--vertical` with the
current document marked by `aria-current` rather than a class of our own.
`docs.js` emits `.nv-table` and `.nv-code`, so a change to the system reaches
the documentation too.

Three things were found by looking at it in a browser rather than by reading
it, and all three are the same mistake: **a `.nv-card` carries no padding of
its own -- its parts do.** The stat tiles, the "One ISO, one stick" band and
the card headers were all built from bare children, so numbers ran to the card
edge, the USB mark hung off it, and a title and its badge sat at opposite ends
of a row meant for a title and a trailing slot. Where the component had a right
way to say it, the markup now says it that way; where it did not -- a tile has
no parts -- `app.css` supplies the padding and says why.

Checked: every nv- class used across the three pages and docs.js exists in the
CSS, every token referenced by app.css is defined, and app.css contains no hex
value at all. Niveus's own tools/check.py passes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-23 14:40:09 +02:00

309 lines
13 KiB
HTML
Raw Blame History

<!DOCTYPE html>
<html lang="en" data-theme="dark">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Download — SchOS</title>
<meta name="description" content="Get SchOS: a bootable ISO for a USB stick, what it needs, what it does on first boot, and how to build one yourself.">
<link rel="icon" href="Assets/shift.svg" type="image/svg+xml">
<link rel="stylesheet" href="niveus/dist/niveus.css">
<script src="niveus/niveus/niveus.js" defer></script>
<link rel="stylesheet" href="app.css">
<script>
try {
var saved = localStorage.getItem("schos-theme");
if (saved === "system") document.documentElement.removeAttribute("data-theme");
else if (saved) document.documentElement.setAttribute("data-theme", saved);
} catch (e) { /* storage unavailable — keep the default */ }
</script>
<style>
:root { --nv-brand: #7C5CFF; }
</style>
</head>
<body>
<nav class="nv-nav" aria-label="Main" style="--nv-selection-name: nv-schos-nav">
<a class="nv-nav__brand" href="index.html">
<img class="nv-nav__icon" src="Assets/shift.svg" alt="">
SchOS
</a>
<ul class="nv-nav__list">
<li><a class="nv-nav__item" href="index.html">Home</a></li>
<li><a class="nv-nav__item" href="download.html" aria-current="page">Download</a></li>
<li><a class="nv-nav__item" href="docs.html">Docs</a></li>
</ul>
<span class="nv-nav__spacer"></span>
<a class="pride" href="#pride-note"
title="SchOS stands with the LGBTQIAP+ community — every month of the year">
<img src="Assets/pride.svg" alt="Progress Pride flag">
</a>
<div class="nv-button-group appearance" role="group" aria-label="Appearance">
<button class="nv-button nv-button--sm" data-nv-theme="light" aria-pressed="false">Light</button>
<button class="nv-button nv-button--sm" data-nv-theme="dark" aria-pressed="true">Dark</button>
<button class="nv-button nv-button--sm" data-nv-theme="system" aria-pressed="false">Auto</button>
</div>
</nav>
<main id="top">
<!-- ====================================================================== -->
<header class="shell hero">
<div class="hero__copy">
<p class="nv-overline nv-text-accent">Download</p>
<h1 class="nv-display hero__title">
<img class="hero__mark" src="Assets/usb.svg" alt="">Put it on a stick
</h1>
<p class="nv-prose">
SchOS ships as one bootable ISO. It boots on UEFI, runs entirely from
RAM, and touches nothing on the machine unless you tell it to — there is
no installer yet, and that is the point of trying it this way.
</p>
<div class="nv-cluster">
<a class="nv-button nv-button--primary nv-button--lg" href="releases/schos.iso" download>Download the ISO</a>
<a class="nv-button nv-button--lg" href="#build">Build it yourself</a>
</div>
<p class="nv-caption">
<code class="nv-code">schos.iso</code> · about 62 MB · UEFI x86-64 ·
nothing is written to your disks
</p>
</div>
<!-- The support table. Deliberately not a compatibility list: one Chromebox
is the entire bare-metal record, and a longer table would be fiction. -->
<article class="nv-card nv-card--elevated">
<div class="nv-card__header">
<div>
<p class="nv-overline nv-text-tertiary">Before you do</p>
<h2 class="nv-card__title">This has booted on exactly one real machine</h2>
</div>
</div>
<div class="nv-card__body nv-text-secondary">
Everything below QEMU is honest reporting rather than a compatibility
list. SchOS drives real hardware, and it has been run on a very small
number of it.
</div>
<div class="nv-card__body">
<div class="nv-table-frame">
<table class="nv-table nv-table--compact">
<tbody>
<tr>
<td>QEMU / OVMF</td>
<td class="nv-table__actions"><span class="nv-badge nv-badge--success">boots</span></td>
</tr>
<tr>
<td>Asus Chromebox <span class="nv-text-tertiary">Guado CN62</span></td>
<td class="nv-table__actions"><span class="nv-badge nv-badge--warning">under test</span></td>
</tr>
<tr>
<td>Anything else</td>
<td class="nv-table__actions"><span class="nv-badge">unknown</span></td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="nv-card__footer nv-card__footer--plain">
<p class="nv-caption nv-text-tertiary">
If it does not boot, the kernel log is on the screen from its first line
— that is deliberate, and it is there because of this machine. A photo of
where it stops is a genuinely useful bug report.
</p>
</div>
</article>
</header>
<!-- ====================================================================== -->
<section id="write" class="shell section" data-reveal>
<div class="section__head">
<p class="nv-overline nv-text-accent">Writing it</p>
<h2 class="nv-heading">Two ways onto a stick</h2>
<p class="nv-prose nv-text-secondary">
Ventoy first, because it is the one that does not cost you the stick. An
ISO copied onto a Ventoy drive sits next to every other ISO on it, and the
drive stays an ordinary drive.
</p>
</div>
<div class="needs">
<article class="nv-card">
<div class="nv-card__header">
<h3 class="nv-card__title">Ventoy</h3>
<span class="nv-badge nv-badge--success">recommended</span>
</div>
<div class="nv-card__body nv-text-secondary">
Copy the file. That is the whole procedure — Ventoy finds it and offers
it in its menu at boot, and the stick remains usable for everything
else.
</div>
<div class="nv-card__body">
<pre class="nv-code cmd"><span class="nv-text-tertiary">$</span> cp schos.iso /run/media/<span class="nv-text-accent">you</span>/Ventoy/</pre>
</div>
<div class="nv-card__footer nv-card__footer--plain">
<p class="nv-caption nv-text-tertiary">
This is how SchOS is actually tested on hardware. No optical drive has
been involved at any point.
</p>
</div>
</article>
<article class="nv-card">
<div class="nv-card__header">
<h3 class="nv-card__title"><code class="nv-code">dd</code></h3>
<span class="nv-badge nv-badge--danger">destructive</span>
</div>
<div class="nv-card__body nv-text-secondary">
Writes the image over the whole device. <b>Check the device name
twice</b> — there is no confirmation and no undo, and the wrong letter
takes a disk with it.
</div>
<div class="nv-card__body">
<!-- Split across two lines on purpose: it was one long line first, and the
card clipped it at conv=. A destructive command that can scroll half of
itself out of view is a good way to take somebody's disk. -->
<pre class="nv-code cmd"><span class="nv-text-tertiary">$</span> lsblk
<span class="nv-text-tertiary">$</span> sudo dd if=schos.iso of=/dev/<span class="nv-text-accent">sdX</span> \
bs=4M status=progress conv=fsync</pre>
</div>
<div class="nv-card__footer nv-card__footer--plain">
<p class="nv-caption nv-text-tertiary">
<code class="nv-code">of=</code> is the whole device, not a partition —
<code class="nv-code">sdX</code> and never <code class="nv-code">sdX1</code>.
</p>
</div>
</article>
</div>
</section>
<!-- ====================================================================== -->
<section id="firstboot" class="shell section" data-reveal>
<div class="section__head">
<p class="nv-overline nv-text-accent">First boot</p>
<h2 class="nv-heading">What actually happens</h2>
<p class="nv-prose nv-text-secondary">
Written out because a system you have never seen before gives you no way to
tell "working" from "stuck", and the difference is worth knowing in advance.
</p>
</div>
<!-- Numbered because this is a sequence: each step only makes sense after
the one above it has happened. -->
<ol class="timeline">
<li class="timeline__step">
<span class="nv-overline timeline__when">Step one</span>
<h3 class="nv-title">The loader</h3>
<p class="nv-body nv-text-secondary">
A splash, and <b>F8</b> for boot options — including the resolution the
whole machine will come up in. It is a PE/COFF loader built with clang
and lld-link; there is no BIOS path, so the firmware has to be in UEFI
mode.
</p>
</li>
<li class="timeline__step">
<span class="nv-overline timeline__when">Step two</span>
<h3 class="nv-title">The kernel log</h3>
<p class="nv-body nv-text-secondary">
On screen, from the first line that can draw. Cores, the PCI bus, the
network card, the filesystem. If it stops, it stops somewhere you can
read.
</p>
</li>
<li class="timeline__step">
<span class="nv-overline timeline__when">Step three</span>
<h3 class="nv-title">A shell</h3>
<p class="nv-body nv-text-secondary">
<code class="nv-code">schinit</code> starts one on the console and a
second on <code class="nv-code">tty2</code>.
<code class="nv-code">mksh</code> is <code class="nv-code">/bin/sh</code>,
with <code class="nv-code">zsh</code> beside it and the real toybox
userland behind both.
</p>
</li>
<li class="timeline__step">
<span class="nv-overline timeline__when">Step four</span>
<h3 class="nv-title">Six terminals</h3>
<p class="nv-body nv-text-secondary">
<code class="nv-code">AltGr+F1</code>…<code class="nv-code">F6</code>
switches between them — the one chord a Linux host does not take for
itself — or <code class="nv-code">chvt N</code> from a shell.
</p>
</li>
</ol>
<p class="nv-body nv-text-tertiary section__note">
<b>Nothing is written to your disks and nothing persists.</b> The root
filesystem is in RAM; the machine is exactly as you left it after a reboot,
including the parts of it you were hoping to keep. There is no installer —
<a href="docs.html?doc=plan/1.0.md">1.0</a> is where that starts.
</p>
</section>
<!-- ====================================================================== -->
<section id="build" class="shell section" data-reveal>
<div class="section__head">
<p class="nv-overline nv-text-accent">Or build it</p>
<h2 class="nv-heading">Clone it, build it, boot it</h2>
<p class="nv-prose nv-text-secondary">
The toolchain is one file. On NixOS <code class="nv-code">shell.nix</code>
brings the whole thing in; elsewhere it is clang, lld, GNU make and a host
compiler — see <a href="docs.html?doc=guides/building.md">the build guide</a>.
</p>
</div>
<div class="nv-card nv-card--inset">
<div class="nv-card__body">
<pre class="nv-code cmd"><span class="nv-text-tertiary">$</span> git clone &lt;the repository&gt; schos &amp;&amp; cd schos
<span class="nv-text-tertiary">$</span> nix-shell <span class="nv-text-tertiary"># NixOS only; elsewhere see the build guide</span>
<span class="nv-text-tertiary">$</span> make iso <span class="nv-text-tertiary"># produces schos.iso</span>
<span class="nv-text-tertiary">$</span> make qemu <span class="nv-text-tertiary"># or just run it, without a stick</span></pre>
</div>
</div>
<p class="nv-body nv-text-tertiary section__note">
<code class="nv-code">make qemu</code> is the one to reach for first.
Everything on this page works there, it takes seconds rather than a reboot,
and a serial console beats a photograph of a screen.
</p>
</section>
</main>
<footer class="shell site-footer">
<div class="nv-divider"></div>
<div class="site-footer__row">
<span class="nv-body">SchOS — kernel <b>SchIFT</b>, filesystem <b>SchFS</b>.</span>
<span class="nv-code nv-text-tertiary">Apache-2.0, with the xv6-derived core under MIT.</span>
</div>
<p class="nv-body nv-text-secondary pride-note" id="pride-note">
<img src="Assets/pride.svg" alt="">
Built by, and for, people of every orientation and gender identity.
The flag stays up all year.
</p>
<p class="nv-body nv-text-secondary nv-prose" id="ai-note">
<b class="nv-text-primary">On AI.</b>
Parts of SchOS were written with AI assistance, and that is not the measure
of anything. A project is good when the people building it understand what
was built, and bad when nobody does — whoever, or whatever, typed it. Vibe
your way through and you get something no one can fix. Stay in the loop and
you get a system you can explain line by line. The bug writeups in
<a href="docs.html?doc=history/kernel.md">history/</a> are where that gets
checked, including the wrong turns.
</p>
</footer>
<script src="app.js"></script>
</body>
</html>
Reference in a new issue View git blame Copy permalink