FlashOS Overview

FlashOS is an experimental, terminal-first operating system for x86_64. Its shell is Flash, a non-POSIX language used both at the prompt and in .fsh automation. Commands and scripts share the same syntax, values, process handling, statuses, and jobs.

External programs still exchange bytes. Flash makes the transition to structured values visible:

^printf '[{"name":"build","active":true},{"name":"deploy","active":false}]' \
| from json array \
| where {|item| $item.active} \
| select name \
| collect \
| to json \
| ^cat

This is the checked-in json-boundary.fsh example. It prints [{"name":"build"}]. The conversion steps matter: Flash does not quietly treat bytes, text, values, and source code as the same thing.

What ships today

Area	Current boundary
Architecture	x86_64
Target ABI	x86_64-unknown-redox
User environment	Keyboard-first, text-based interface
Primary interface	Flash at /usr/bin/fsh
Flash contract	Flash 1.0 component release; availability in a FlashOS version or image is qualified separately
Evaluation baseline	QEMU q35 with UEFI firmware; physical results are device- and artifact-specific
Maturity	Pre-alpha evaluation software, without production security or support guarantees

FlashOS currently uses the Redox kernel and other parts of the Redox ecosystem. The product configuration, Flash integration, documentation, tests, and roadmap are maintained here. FlashOS is not an official Redox OS distribution and is not affiliated with or endorsed by the Redox OS nonprofit.

Why Flash belongs in the system

Flash keeps structured values intact until a program asks for a conversion. External executables receive arguments directly; Flash does not translate its source through another shell. A nonzero exit remains a normal Status, while check turns that status into an error where failure should stop the current flow.

The result is one language for exploring the system interactively and for writing automation that can be checked into the repository. FlashOS uses it as the login shell and, where fsh is already available, for public project automation.

Over time, commands and higher-level terminal views should be able to work with the same actions and data. That design still needs a dedicated TUI and a stable FlashOS system API, neither of which ships today. Flash and FlashOS explains the idea; the Roadmap shows where it fits.

Quick start

From an existing clone, review the planned host changes, run the repository setup, and verify the environment:

./setup.sh --plan
./setup.sh
./setup.sh --check

Build and boot the development image:

./build.fsh -c flashos all
./build.fsh -c flashos qemu

The Getting Started Guide covers host requirements, configuration, image files, login details, live images, troubleshooting, and writing an image to physical media.

Product guide

• Getting Started — Build, boot, log in, and diagnose the first QEMU session.
• Flash and FlashOS — Understand the shipped system integration and future interaction direction.
• Flash by Example — Run small checked programs, then continue to the complete Flash documentation.
• Architecture — Follow the current build-to-boot layers and ownership boundaries.
• Roadmap — See what is being finished now and what may follow.
• About Me — Personal background, motivation, and the working approach behind FlashOS.
• Contributing — Report issues, discuss proposals, prepare changes, and run reproducible checks.
• Complete Documentation Index — Find every guide, policy, record, and focused technical reference.

Verification and evidence

Different checks answer different questions. Source checks do not prove target behavior, target compilation does not prove that an image works, and a QEMU run says nothing about a particular physical machine. CI selects checks based on the files changed. Release candidates also record the source, images, manifests, checksums, SBOMs, provenance, and runtime results that belong together.

Start with Verification and Testing. CI/CD Contracts documents the scripts and hosted workflows in detail. Results from physical machines are recorded in Hardware Compatibility.

Issues and security

The contributor guide links to templates for bugs, documentation problems, hardware reports, and proposals. This is a one-person project, so response, review, acceptance, and release times cannot be guaranteed.

Do not disclose suspected vulnerabilities in a public issue. Follow the private reporting instructions and evaluation limits in the Security Policy.

License and attribution

Original FlashOS material is available under the primary FlashOS MIT License unless a file or component states otherwise. Flash carries a component-local license; inherited Redox infrastructure, the kernel, packages, and other third-party material retain their applicable licenses and notices.

For attribution and project-name details, see NOTICE, the Trademark and Project Identity Policy, and Upstream References.