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 54b25708c3 Demand paging, the RTL8168H, links that come up late, and Ctrl+Alt+F1..F12 
- Anonymous memory can be reserved without being backed: large mappings,
  MAP_NORESERVE and PROT_NONE are recorded and each page appears, zeroed,
  on first touch -- from trap() for the program, from uva2ka() for the
  kernel on its behalf. WebKit reserves 4 GB at start and touches a sliver;
  backing it all failed with ENOMEM and Epiphany aborted.
- r8169: the 8168G generation and later (the laptop's 8168H, XID 541) are
  taken from the firmware's out-of-band mode, get their PLL powered, the
  receive gate opened, and their PHY reached through the OCP window. The
  PHY's power-down bit is cleared; the old code kept it while restarting
  autonegotiation. Untested on the hardware so far.
- The network thread follows each device's link into lwIP. The link was
  read once at attach, 0.02 s into boot; real autonegotiation takes
  seconds, so on hardware the interface stayed down for good.
- Twelve terminals, switched with Ctrl+Alt+F1..F12 by default: the keys X
  uses, so the console and the desktop agree. AltGr+F-key is gone from
  the defaults (chvt -c altgr+F brings it back).
- SO_PASSCRED on Unix sockets, with SCM_CREDENTIALS delivered by recvmsg.
  WebKit sets it on its IPC sockets and aborted when refused.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
2026-10-25 11:27:48 +01:00

321 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="nv-steps nv-steps--vertical origin">
<li class="nv-steps__item">
<span class="nv-steps__marker">1</span>
<div class="nv-steps__body">
<span class="nv-overline nv-text-tertiary">Step one</span>
<h3 class="nv-steps__title">The loader</h3>
<p class="nv-steps__text">
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>
</div>
</li>
<li class="nv-steps__item">
<span class="nv-steps__marker">2</span>
<div class="nv-steps__body">
<span class="nv-overline nv-text-tertiary">Step two</span>
<h3 class="nv-steps__title">The kernel log</h3>
<p class="nv-steps__text">
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>
</div>
</li>
<li class="nv-steps__item">
<span class="nv-steps__marker">3</span>
<div class="nv-steps__body">
<span class="nv-overline nv-text-tertiary">Step three</span>
<h3 class="nv-steps__title">A shell</h3>
<p class="nv-steps__text">
<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>
</div>
</li>
<li class="nv-steps__item">
<span class="nv-steps__marker">4</span>
<div class="nv-steps__body">
<span class="nv-overline nv-text-tertiary">Step four</span>
<h3 class="nv-steps__title">Twelve terminals</h3>
<p class="nv-steps__text">
<code class="nv-code">Ctrl+Alt+F1</code>…<code class="nv-code">F12</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>
</div>
</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">GPL-2.0-or-later, 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