ajhahn.de

FlashOS

A keyboard-first operating system with one structured language for commands and automation.

v0.2.0pre-alphax86_64-unknown-redox

View repository

One language, visible boundaries

External bytes become values because the program says so.

# External bytes become values only at the explicit JSON boundary.
^printf '[{"name":"build","active":true},{"name":"deploy","active":false}]' \
| from json array \
| where {|item| $item.active} \
| select name \
| collect \
| to json \
| ^cat
output[{"name":"build"}]

external bytes→ByteStream→from json→ValueStream→to json→bytes

Why Flash

The prompt and the automation language are the same system.

  • Flash 1.0 is both the interactive login shell and the language used for .fsh automation.
  • Byte streams, text, structured values, and source remain distinct; conversion at an external-process boundary is visible in the program.

What ships today

A deliberately narrow system, delivered as inspectable release artifacts.

System facts

Target
x86_64-unknown-redox
Interface
Keyboard-first · TUI-only · pre-alpha
Shell
Flash 1.0 at /usr/bin/fsh
System base
Pinned Redox kernel and Redox-derived layers
Images
Installed-disk and live x86_64 images
Boundary
Evaluation software; no production, security, support, or broad-hardware guarantee
Runtime path
  1. UEFI
  2. Redox kernel
  3. services
  4. console and login
  5. /usr/bin/fsh

Flash 1.0

Structured commands without hiding the process boundary.

  • An unsuccessful external status is data, not automatically a runtime error; check deliberately escalates it.
  • The release includes modules, static checking, formatting, a language server, jobs, and bounded non-executing plan inspection.
  • A dedicated x86_64 FlashOS platform adapter exposes only target capabilities backed by the shipped boundary and runtime evidence.

Read Flash and FlashOS →

Current architecture

Ownership is explicit; it does not imply reinvention.

FlashOS owns its product profile and Flash integration while borrowing a pinned, inspectable Redox boundary for the kernel and inherited system layers.

Ownership boundary

FlashOS-owned
Product profile, Flash integration, documentation, and release verification
Pinned or patched
Build recipes, packages, relibc, bootloader, and selected Redox layers
Upstream boundary
Redox kernel, drivers, filesystems, services, and inherited userspace

Build to boot

  1. Configuration
  2. Toolchain and recipes
  3. Image
  4. UEFI and bootloader
  5. Pinned Redox kernel
  6. Services and login
  7. /usr/bin/fsh

Read the architecture guide →

Future direction

Possible extensions remain visibly separate from what ships.

Direction — not shipped in v0.2.0

  • A stable system API and shared semantic actions could let Flash and a future View present the same operations.
  • A dedicated TUI, services model, controlled apply, secret capabilities, and persistent audit artifacts are direction—not v0.2.0 features.

Direction — not shipped in v0.2.0

Evidence, bounded by what it proves

Build once, qualify exact bytes, publish qualified bytes.

The v0.2.0 candidate binds source identity, image digests, runtime results, checksums, SBOMs, logs, performance evidence, and publication metadata. QEMU is the automated reference—not a physical-hardware claim.

Published release evidence

Release
v0.2.0
Target
x86_64-unknown-redox
Profile
flashos-release
Tree
c41b976e0362
All 12 published assets

Checksums bind downloaded bytes. GitHub provenance records workflow identity for published subjects. Neither is proof of bit-for-bit reproducibility, a security audit, physical hardware support, or production readiness.

Release v0.2.0 on GitHub → Read the release notes →

Engineering case study

Narrow the promise. Clarify the boundary. Make evidence part of the release.

  1. 01

    Keyboard-first scope keeps the product idea testable while leaving graphical and broad-hardware work outside the current promise.

  2. 02

    The project moved from the archived AArch64 experiment to an x86_64, Redox-based product and made Flash—not a kernel rewrite—the owned center.

  3. 03

    The release separates source checks, image construction, exact-byte QEMU qualification, and device-specific physical observations so each claim stays within its evidence layer.

Behind FlashOS

Why I build FlashOS—and how I work.

Creator and maintainer

Anton Hahn

FlashOS began as a way for me to learn by building. It brings together operating systems, language design, architecture, tools, and testing—and gives me room to follow an idea from its first outline to something I can run, test, and improve.

About me and the project

Documentation

Follow the reader task, not a repository tree.

The reader-facing v0.2.0 documentation is mirrored from its canonical Markdown. Direct source references remain bounded, read-only, and first-order.

Start hereGetting StartedEvaluate the release in QEMU or on carefully selected removable media.ProductProduct GuideSystem scope, architecture, development, verification, hardware, and roadmap.LanguageFlash documentationLanguage guide, scripting, architecture, development, examples, and test references.EvidenceVerification modelWhat source, image, QEMU, and physical evidence do—and do not—prove.