Chisle
The coding-agent plugin that bills 52% of a bare model across 20 live tasks. Terse persona + tool-output compressor + context diet.
A Linux distribution built around readable package recipes and explicit control: recipes built in isolated Ginux domains and atomic A/B updates by default.
Developer toolsGitHub @LevitateOSOnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
Repository information has not been collected yet.
No updates detected yet. GitHub releases will appear here.
A Linux distribution where you maintain your own packages. Write simple Rhai recipes, build from source, with local AI assistance. Full control, no upstream dependencies.
Loading the full README.
Read the full README ↗Customization from the package level.
A Linux distribution where you maintain your own packages. Packages are Rhai recipes that declare how to acquire, build and install each piece of software, and the installed system updates atomically: A/B slots are the default, a mutable install is an explicit opt-in.
LevitateOS and AcornOS are built by the same pipeline and offer the same
features: the same install flow, the same A/B updates, the same recipes, and a
live ISO with and without a desktop. They differ only in the facts each one
declares in its own distro/variants/<id>/distro.toml: package backend (Fedora
RPMs or Alpine APKs), libc and init, the admin tool (sudo or doas), the desktop
(Plasma or LXQt) and the kernel line (latest or LTS). distro_contract::load
reads and validates that file; the [profile] section holds the differing
facts.
Each has its own purpose. LevitateOS is the daily-driver workstation: glibc and systemd, so software built for mainstream Linux runs. AcornOS is the small, strict system: musl, OpenRC and the fewest parts that do the job.
Everything runs through cargo xtask; cargo xtask --help is the command
reference and xtask/README.md says what xtask owns.
architecture.md says where each fact lives (products,
scenarios, outputs).
The current Recipe/Ginux release integration remains provisional. Its release scope and acceptance queue requires both distros' base/live-tools products through guest installer, installation and A/B verification on the delivered combination. Maintained runtime delivery and final acceptance remain open; desktop products and external AI-provider interoperability are outside that agreed verification scope.
The live ISO boots into the install screen: a guide beside a shell, using the
rec* install tools. The same pages are on the website and in
docs/content.
One Rhai format and one engine, tools/recipe, serve two consumers:
| Collection | Owner and purpose |
|---|---|
distro/builder/os-recipes/ | The OS builder: acquire base packages, build the kernel and tools, and assemble system images and live overlays. recab owns system updates and A/B continuation, using Recipe for software operations. |
recipes/ | User-managed software: the application catalog, starting with ripgrep. Recipe activates packages and manages updates/removal independently of the OS image. |
The split is about who consumes the output and manages its lifetime. Apps bundled into the desktop image are OS-owned too. Both collections use Recipe API 2 and Ginux; there is no separate recipe language or execution engine.
recipe install ripgrep produces a verified package tree in Ginux and atomically
activates it. recipe update ripgrep uses the current catalog's pinned version;
recipe remove ripgrep deactivates it using the installed receipt. The OS builder
uses --no-activate to consume outputs without changing its host. Package profiles
and override recipes currently persist on shared /var. System changes and updates
belong to recab's A/B continuation lifecycle; shared profile activation is not a
substitute for changing an inactive system. Matching initial slots, incremental
continuation and Recipe targeting of the inactive system remain unimplemented.
See tools/recab/README.md for the intended lifecycle
and the current destructive image-staging limitations.
See docs/package-recipe-format.md for ownership
and output semantics, and tools/recipe/WRITING_RECIPES.md
for the shared format.
distro/ builder (products and ISOs), contract and variants (per-distro declarations)
recipes/ user-managed software catalog (ripgrep)
tools/ recipe, the rec* install and boot tools, ginux (upstream build domains)
testing/ install-tests (boot/install scenarios)
tui/ terminal apps for the live ISO and installer
docs/ content (site and live docs), website, design notes, history
xtask/ the cargo xtask front door
MIT OR Apache-2.0 for LevitateOS's own code; built images contain packages under their own licenses. See LICENSE.