adaptive power & performance for Arch

Rush Linux is an Arch-based operating-system project that adapts power and performance to the work being done. optid observes the machine, classifies the workload, explains its decisions, and can apply guarded hardware settings when explicitly enabled.

Start here

I want to…	Best starting point
Try Rush in a VM or from USB	LiveDev for Linux/macOS or Windows
Compare optid on my current Linux install	Run the host benchmark
Understand the adaptive control loop	What optid does
Continue project development	Current work selector
Build Rush or contribute	Build and development

Rush LiveDev quick start

Environment: Linux / macOS

curl -fsSL https://raw.githubusercontent.com/Nan0pk/Rush-linux/main/tools/livedev-bootstrap.sh -o livedev-bootstrap.sh && bash livedev-bootstrap.sh

Detects an existing results USB, QEMU, or a USB-preparation path and chooses the useful next action.

Repository status

This table is generated from the repository's canonical version, build, and work-state files.

Item	Current state
Project stage	Early beta: dry-run is the safe default; automatic hardware actuation is not release-ready.
Version	0.7.0-beta.4
Active general repair	T1 — Build thermal sensing and a pure budget model (merged_incomplete)
Active safety repair	C1 — Model contracts with measured latency and provenance (next)
Build profiles	desktop, laptop, livedev, realtime-audio, server, testos
Safety architecture	D2 fail-passive
Canonical work state	optid package ledger

Choose a command

Pick the goal that matches what you want to do. Detailed options stay in the linked runbooks.

Goal	Environment
Run the smart LiveDev flow	Linux / macOS
Run the smart LiveDev flow	Windows PowerShell (Administrator)
Compare optid on an existing Linux install	Linux
Start a clean development task	Cloned repository
Run every check relevant to a change	Cloned repository
Build the LiveDev image	Supported Linux build host

Other command details

Run the smart LiveDev flow

Environment: Windows PowerShell (Administrator)

curl.exe -fL -o livedev-bootstrap.ps1 https://raw.githubusercontent.com/Nan0pk/Rush-linux/main/tools/livedev-bootstrap.ps1; if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }; powershell -ExecutionPolicy Bypass -File .\livedev-bootstrap.ps1

Open PowerShell as Administrator. Elevation is needed only for raw USB writing and temporary ESP mounting.

Compare optid on an existing Linux install

Environment: Linux

curl -fsSL https://raw.githubusercontent.com/Nan0pk/Rush-linux/main/tools/rush-host-bench.sh | sudo bash

No USB, VM, reboot, or Rush installation. Apply mode is experimental; a reboot remains the final recovery fallback.

Start a clean development task

Environment: Cloned repository

bash tools/start-work.sh "short task description"

Creates a work branch when needed and runs the fast starting-state checks.

Run every check relevant to a change

Environment: Cloned repository

bash tools/finish-work.sh --dry-run

Uses the same change-aware check runner as CI and does not commit or push.

Build the LiveDev image

Environment: Supported Linux build host

sudo bash tools/build-mkosi-image.sh --edition livedev

Requires Rust, mkosi, and the host dependencies listed in the build documentation.

How the smart LiveDev command behaves

The bootstrap command chooses the next step from what it detects:

Detected environment	Next action
Results USB present	Copy and validate results, then offer an evidence submission
QEMU available	Build or reuse the LiveDev image and start the VM path
Neither available	Prepare the real-hardware USB path and print boot instructions

It preserves an existing checkout and does not merge pull requests or mark milestones verified. USB writing needs sudo on Linux/macOS or an Administrator PowerShell on Windows. GitHub authentication is needed only when opening an evidence PR.

The full operator procedure is in the LiveDev runbook.

testOS remains the current boot backend and manual fallback for real-hardware USB testing.

What optid does

Every control-loop iteration follows the same basic path:

1. read pressure, power, thermal, application, and device state;
2. classify the workload as idle, light, interactive, latency-critical, throughput, or vm.guest;
3. resolve the desired contract and domain gates;
4. log intended actions in dry-run mode, or attempt guarded writes with --apply;
5. report support, skip, failure, and recovery outcomes.

Implemented paths include core CPU controls and initial runtime-PM, PCIe ASPM, SATA ALPM, backlight, VM-sysctl, PM QoS, and cgroup controls. The packaged apply service cannot yet reach all dynamic device paths, and the persistent verified D2 recovery protocol is not complete. Treat apply mode as experimental.

See adaptive engine for the control model and implementation status for the detailed inventory.

Build and development

The commands above are the supported entry points. Use these guides for detail:

Topic	Guide
Host dependencies, mkosi profiles, and image outputs	Build system
Source and packaging flow	How Rush is built
Claims, evidence, and release tiers	Testing and benchmarks
Risk-based contributor process	Project workflow

Only the human maintainer merges to main. A merged optid PR proves that code landed; package completion additionally requires production-path integration and independent committed evidence.

Project map

Area	Document
Product direction	Northstar specification
System design	Architecture
Current agent work	Current work selector
Current implementation work	Active optid completion plan
Compatibility	Hardware support
Release direction	Roadmap
Documentation index	All documentation

Latest release: v0.7.0-beta.4

Contributing

Start with CONTRIBUTING.md. The repository expects small coherent pull requests, change-aware tests, and evidence that matches the claim.

License

Apache-2.0. Copyright the Rush Linux authors.