FlashOS v0.2.0 Release Notes

FlashOS v0.2.0 is an x86_64, keyboard-first, TUI-only pre-alpha evaluation release. It brings the frozen Flash 1.0 language and shell into a deliberately small FlashOS image, strengthens qualification and release integrity, and publishes a coherent guide to the system that actually ships.

This is evaluation software. It is not a production operating system, a security boundary for valuable data, or a promise of broad hardware support.

Highlights

• Flash 1.0 at /usr/bin/fsh provides the login shell, structured values, explicit byte and process boundaries, static checking, formatting, modules, typed interfaces, a language server, mixed pipelines, interactive editing, and the supported job-control contract.
• FlashOS selects its dedicated x86_64 platform adapter and qualifies the advertised target capabilities through exact image runtime fixtures. The indivisible Signals capability remains withheld because stopped-child transitions are not qualified on the target.
• Public project automation uses Flash wherever a usable fsh can exist. Retained shell and Python entry points are limited to reviewed bootstrap, recovery, external-interface, or independent-validation boundaries.
• The release image contains the intentional TUI package and service closure; inherited graphical profiles, windowing stacks, GUI applications, stale build targets, and the work-in-progress recipe collection are removed.
• CI separates fast source checks from risk-routed image qualification. Release candidates build disk and live images once, boot those exact raw bytes, and bind source, tree, checksums, SBOMs, provenance, logs, and runtime results in one manifest.
• The product guide now connects installation, Flash, architecture, development, automation, verification, hardware, security, contribution, and the shipped-versus-future roadmap through checked examples and links.

The exhaustive public delta is in the FlashOS changelog. Flash maintains its independent component history in the Flash changelog.

Images and integrity

The release publishes two x86_64 image forms:

• an installed-disk image qualified through the QEMU NVMe path; and
• a live image qualified through the QEMU USB mass-storage path.

The candidate bundle also includes source and image CycloneDX SBOMs, SHA256SUMS, a generated cookbook resolution, QEMU logs and results, target performance evidence, reviewed release notes, and candidate-manifest.json. Publication promotes the already-qualified candidate bytes; it does not rebuild or substitute them.

Verify SHA256SUMS before decompressing or using an image. GitHub build provenance records workflow identity for the published subjects, but it is not proof of bit-for-bit reproducibility or an independent security audit.

Access and security boundary

The release profile locks the root account against direct password login. The regular user account is passwordless and belongs to sudo, so anyone with local-console access can obtain administrative authority. Treat the console as unauthenticated and run FlashOS only with disposable, non-sensitive data on an isolated network.

No remote-login service is selected. The image still contains an inherited network stack and DHCP client, and the wider inherited kernel, driver, userspace, and toolchain surface has not received a complete security audit. See the Security Policy for the threat model, accepted high risks, private reporting route, and immutable-release correction policy.

Qualification scope

The automated reference is QEMU q35 with UEFI firmware. The installed-disk and live-image paths separately check product identity, release credentials, login, Flash startup, interactive editing, scripts, redirection, external and structured pipelines, supported foreground and background behavior, capability markers, installed services, and clean exit or shutdown behavior.

Physical qualification is limited to the exact candidate live image and the Sony VAIO VPCEB4L1E console baseline. A physical result applies only to the recorded device, firmware, image digest, boot medium, and observations; it does not generalize to related models or untested subsystems. The Hardware Compatibility record is authoritative for what was actually observed. The Intel iMac and all other physical systems are outside the v0.2.0 qualification scope.

Known limitations and non-goals

• FlashOS remains pre-alpha and offers no production security, unattended installation, long-term support, or guaranteed response timeline.
• The release has no graphical desktop, graphical installer, browser, stable FlashOS system API, general cloud SDK, infrastructure state engine, or AArch64 support.
• The future dedicated TUI, shared semantic actions, services, and persistent Flash interface are roadmap direction, not v0.2.0 features.
• Hardware support is device-specific. QEMU success is not physical-device evidence, and untested networking, audio, storage, pointing-device, power, and firmware behavior remains unknown.
• Flash programs are code, not sandboxed documents. Run untrusted source only in a disposable instance with the authority and data you are prepared to expose.

Using the release

FlashOS does not provide an in-place upgrade path. Download the appropriate image from the GitHub release, verify its checksum, and follow the Getting Started Guide for QEMU or removable-media evaluation. Writing removable media is destructive: identify the exact target device first and never infer it from a drive letter or broad path.