# Torsionfield Linux An AI metadistribution research project by Torsionfield. ## The proposal Boot a small independent Linux environment into full Chrome, Proton Pass and the owner's subscribed browser ChatGPT. Start the owner's personal MCP services, including browser automation, Desktop Commander and VNC, with authenticated Cloudflare tunnels. ChatGPT then has the tools to inspect, install, recover and maintain a target Linux system even when its installed desktop cannot start. The live environment remains a real Linux OS. ChatGPT is the intended primary installation and recovery interface. Internet access, account sign-in and the account's actual MCP capabilities must work. Offline terminal tools remain useful when the cloud interface is unreachable. Personal credentials are provisioned separately from a redistributable image. ## Reconstruct before replacing Import native package manifests in bulk. One installed package accounts for all its owned paths. Retain exact package/source versions, archive locations and reference checksums. Compare observed contents separately. Investigate residual files by groups: repository checkout, locked language environment, local build, generated output or personal data requiring a preserved backup. For every required artifact, identify an obtainable package, pinned source and build recipe, regeneration rule or verified preserved artifact. Original author identity is irrelevant. Missing sources stay unresolved; a database row does not make a source available or establish reproducibility. ## An installer intelligence can account for Adapt an existing open-source installer into an explicit sequence of operations. Preserve its upstream license and notices. Instrument or rewrite the orchestration so decisions, inputs, preconditions, target identity, actions, return status and post-install checks are recorded from the first step. Begin with one distro adapter and a disposable VM before targeting real disks. Ubuntu Subiquity's autoinstall interfaces and Arch's archinstall library are concrete upstream starting points. The installer adapter is proposed work; this project has not yet rewritten or shipped either installer. ## The SQLite system record Separate sources and recipes, artifact provenance, observed state, desired state and action evidence. The accompanying system-schema.sql is an executable draft of that model. The current dpkg inventory collector uses its own observation schema; its import into this orchestration schema is a future adapter. The agent queries this record through tools and attaches new observations after operations. SQLite is inspectable persistent state, not a model or a package manager. Its transactions cover database writes. External filesystem changes, package installation and partitioning require journalling, idempotent operations and crash reconciliation; they cannot be rolled back by a SQLite transaction. Reverting an OS operation requires a separately verified inverse or checkpoint. Action status labels in this draft are not proof of execution: a future executor must enforce state transitions and validate supporting events and evidence. Keep credentials outside records, command logs and public artifacts. ## Beyond one distribution The long-term target is a common orchestration layer that understands multiple distro adapters. Start with Ubuntu's base and package ownership. Add selected capabilities inspired by Arch's explicit configuration and Gentoo's source-build policies, using compatible native packages, isolated environments or pinned builds as appropriate. Check ABI, dependencies, init/service policy, ownership, updates and recovery for each integration. Arbitrary mixing of native package databases is not a compatibility strategy. Any distribution is a potential adapter target. Complete recreation is established by available inputs and a verified rebuild, not by the scope of that ambition. ## Omakub, Omarchy and LINA OS: influences and proposed extensions These projects help make the proposal more concrete. They are independent upstreams, not integrations or partners of Torsionfield Linux. Reviewed 23 October 2026; their features and maturity may change. Omakub supplies the Ubuntu precedent: a curated setup applied after installing fresh Ubuntu 24.04 (its current manual also lists 25.10). The manual now marks it as legacy, superseded by Omarchy Quattro for new installations. Distinguish that Ubuntu overlay from current Arch-based Omarchy. Our proposed adapters should support fresh construction and incremental changes to inventoried systems; Omakub's fresh-install setup is not a migration recipe for a customized machine. Omarchy combines Arch, Hyprland and Quickshell into a deliberately curated desktop. Its agent setup, skills and crash-diagnosis workflow show how an agent can become part of everyday system customization. Adopt that emphasis on an immediately usable experience: offer versioned profiles rather than asking each user to design a desktop from scratch. A future Omarchy adapter would record its upstream version, native packages, configuration inputs and user changes. This project has not implemented that adapter. ### Quattro: concrete architecture to build on DHH's linked Quattro presentation broadens the comparison beyond desktop polish. The following details are checked against the upstream manual at revision 967bbdd7346e6e2ff1a6af33c5d762ea784832cc. The presentation and current source may differ; this is not a claim that every demonstrated feature has been tested here. - Package-owned defaults and user overrides: Omarchy separates its system files from personal configuration. Track upstream inputs, local overrides and the effective configuration, with compatibility checks after migration. Record source and build recipes for agent-generated themes, widgets and applications. - Coordinated update policy: the stable Arch mirror is one month delayed, while the updater coordinates packages, migrations and snapshots. Record repository state, artifact availability, update owner, migration and checkpoint. Delay provides time for integration testing; it does not by itself prove stability or establish a security-response policy for our future adapters. - Independent agent-tool cadence: many agent CLIs are managed by mise, with exceptions documented upstream. Track the actual manager and resolved version per component, together with skill revisions and MCP compatibility. Do not install a second unmanaged copy over a manager-owned tool. - Evidence-linked diagnostics: Omarchy can pass a systemd-coredump crash to an agent skill. Extend the system record to connect the fault, relevant versions, diagnosis, patch, action and regression result. Task notifications do not prove that a repair works; check the resulting system behavior. - Recovery coverage: Omarchy's snapshot restoration restores root but leaves home directories and their configuration unchanged. Test the restored OS with the retained personal and agent/MCP state, including configuration format compatibility. Our independent live environment must also work when the installed desktop and its local agent launchers cannot start. Omarchy already demonstrates extensive agent integration. Our proposed contribution is portable construction provenance and verified recovery across distributions, with browser ChatGPT and personal MCPs as the initial control interface. A first adapter must demonstrate this combination in practice. ### LINA OS composition LINA OS describes an exploratory Omarchy-based environment composing LINA Core, Node and app releases. Its composition design specifies version/digest manifests, device and VM modes, main/headless/connected-device profiles and one update owner. It also distinguishes OS snapshots from LINA restoration. LINA Core is separately usable without LINA OS; the underlying Core project currently states it has no runnable release. Treat the OS material as design work, not a shipping integration. The extension proposed here is a common construction and recovery record that can span these experiences and other distributions. Browser ChatGPT and the owner's authenticated MCP services remain the initial interface. The record belongs to the managed system and can be queried by a later conversation or model. This does not imply automatic compatibility with LINA's protocol or any other agent runtime. ## Profiles, manifests and recovery units 1. Define a useful experience as a versioned profile: desktop, applications, services, build choices and verification requirements. Resolve the profile through a target distro adapter, checking dependency and ABI compatibility. 2. Lock the resolved inputs in a component manifest: upstream revision, artifact digest, configuration recipe, ownership and dependencies. Preserve that intended input separately from the SQLite observations and action journal. An exact digest identifies an artifact; retrieval and rebuild tests establish that it is still obtainable and useful. 3. Describe deployment roles explicitly: rescue USB, workstation, headless/VM and connected tool device. Give each managed component one update owner and each target one active orchestrator. Keep native package-manager ownership; reconcile external changes before applying the next action. A VM obtains host access only through explicitly connected tools and permissions. 4. Define recovery units for the base OS, personal files, agent/MCP state and orchestration database. Provision credentials separately. Record checkpoints, recovery ordering and consistency requirements. Test boot, data and every required authenticated tool against the intended target after restoration. Neither an OS snapshot nor a SQLite commit proves complete recovery. 5. Carry a hardware binding alongside the portable experience: machine identity, kernel, driver and firmware versions, with boot, display, networking and suspend/resume results. Preserve the known working configuration while testing an update. A profile resolving successfully does not prove hardware support. Omacom's philosophy adds another useful constraint: provide coherent defaults, then let the owner make substitutions. Record those deviations and explain the operations behind them. Keep native terminal and keyboard workflows available; agent assistance should help the owner learn and inspect the system. Practical commercial tools fit this approach, including the requested full Chrome, Proton Pass and browser ChatGPT. A successful update must demonstrate improvement on the target machine; a newer version number alone is insufficient evidence. The profile/manifest format, ownership enforcement, recovery coordination and inventory import are future adapter/executor work. The current SQL file remains a draft record, not an implementation of these mechanisms. The first acceptance trial should rebuild a pinned profile in a disposable VM, interrupt an operation, reconcile it and demonstrate recovery from the independent browser environment. ## Status Implemented locally: dpkg package and root-path inventory in SQLite; a reusable Linux recovery workflow skill. This site also publishes the design and draft orchestration schema. The source for the workstation's exact working Ubuntu kernel has been acquired for later investigation. No kernel patch is claimed. Next: resolve residual provenance, define the first pinned profile and manifest, implement and test the first installer adapter and interruption/recovery behavior, build the personal live environment, and verify boot plus every MCP service from the browser. No boot-tested ISO or universal installer is available yet. This may be useful to Linux power users, developers maintaining unusual machines, rescue-media builders and researchers in reproducible systems. Its usefulness must be demonstrated by repeatable recovery and installation trials. General consumer onboarding and support remain open engineering work. ## Upstream references - Omacom philosophy: https://learn.omacom.io/3/omacom - Omakub's Ubuntu setup and legacy status: https://learn.omacom.io/1/read/4/getting-started - Omakase computing: https://learn.omacom.io/3/omacom/76/omakase-computing - Omacom doctrine: https://learn.omacom.io/3/omacom/81/doctrine - Learning and ownership: https://learn.omacom.io/3/omacom/87/it-needn-t-always-be-easy - Linux hardware: https://learn.omacom.io/3/omacom/74/good-linux-hardware - Omarchy: https://omarchy.org/ - Omarchy source and manual: https://github.com/omacom/omarchy - Omarchy manual at the reviewed revision: https://github.com/omacom/omarchy/blob/967bbdd7346e6e2ff1a6af33c5d762ea784832cc/manual/01-welcome-to-omarchy.md - DHH's Omarchy Quattro presentation (supplied for comparison): https://www.youtube.com/watch?v=F7fe9pa8OeE - Agent tooling and crash diagnostics: https://github.com/omacom/omarchy/blob/967bbdd7346e6e2ff1a6af33c5d762ea784832cc/manual/17-ai.md - Update channels and orchestration: https://github.com/omacom/omarchy/blob/967bbdd7346e6e2ff1a6af33c5d762ea784832cc/manual/30-updates.md - Configuration ownership: https://github.com/omacom/omarchy/blob/967bbdd7346e6e2ff1a6af33c5d762ea784832cc/manual/31-dotfiles.md - Snapshot restoration coverage: https://github.com/omacom/omarchy/blob/967bbdd7346e6e2ff1a6af33c5d762ea784832cc/manual/47-system-snapshots.md - LINA OS: https://github.com/lina-system/lina-os - LINA OS composition design at the reviewed revision: https://github.com/lina-system/lina-os/blob/ff0926dd4824f492b7985babfad3a340de41ceaf/docs/design.md - LINA Core and its current development status: https://github.com/lina-system/lina - Ubuntu autoinstall: https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html - Arch installer: https://github.com/archlinux/archinstall - SQLite transactions: https://www.sqlite.org/lang_transaction.html - ChatGPT MCP eligibility: https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt - Cloudflare Tunnel: https://developers.cloudflare.com/tunnel/ - Proton browser extension deployment: https://proton.me/support/deploy-browser-extension Independent project; not affiliated with or endorsed by these upstream projects.