Choose Odin’s runtime and Linux compatibility contract #9
Assignees
xavierk (Xavier Karma)
Clear assignees
xavierk (Xavier Karma)
No Assignees
xavierk
xavierk
Notifications
Due Date
No due date set.
Blocks
Depends on
#13 Evaluate the Bongbetic TUI workflow with InkUI
xavierk/odin
#15 Approve Odin’s build-ready specification
xavierk/odin
Reference: xavierk/odin#9
Reference in New Issue
Block a user
Part of Find the way to Odin’s build-ready specification.
Question
Which runtime, architecture, process/privilege boundaries and packaging model should Odin use while retaining the required InkUI components? Set supported CPU/libc/distro/kernel/runtime versions, portable/deb/rpm/xbps delivery expectations, dependency acquisition and offline rules, capability fallbacks, Bash invocation, bounded measurement isolation, terminal restoration and cancellation semantics. Reconcile the desire for a bleeding-edge stack with the agreed compatibility promise using research evidence.
Resolve with the human; record a tradeoff ADR only when warranted.
Resolution
Odin v1 uses a TypeScript/React terminal application on Node 24, React 19, and Ink 6, with the requested
kamlesh723/InkUIcomponents copied and pinned from a reviewed source revision. Ink 6 stays within InkUI's declared major-version range. An Ink 7 migration is a separate compatibility decision after the interaction prototype proves its mouse, layout, and terminal behavior. Bun is not the v1 runtime. Pin exact dependency and source versions in the build; follow supported Node 24 security updates without silently changing workload identities.Delivery and supported platforms. Ship native
xbps,deb, andrpmpackages for certified cells. Use a maintained distro Node 24 package where one exists. Where a target distro does not supply Node 24, include a pinned Node 24 runtime in Odin's native package; Bongbetic owns its security updates, provenance, signatures, and transitive license notices. Do not make users add an unspecified third-party repository. Debian 13 supplies Node 20 and Ubuntu 24.04 supplies Node 18 today, so neither qualifies for a system-Node-24-only package. The v1 architecture targets are x86_64 and aarch64. Official Node 24 glibc binaries document a Linux kernel 4.18, glibc 2.28, andGLIBCXX_3.4.25baseline; this is a runtime ABI floor, not an Odin support or workload guarantee. Void musl uses a qualified distro-built Node and separately qualified helpers; do not treat Node's experimental x64-musl or absent arm64-musl official-binary tier as certification. Exact distro versions, kernel configurations, architecture/libc cells, and support claims become binding only after Set distro, VM, and physical-hardware validation gates verifies them. Probe actual interfaces, permissions, drivers, and resources for each workload. Report unavailable capability with its reason; do not silently substitute a tool or measurement. In particular, Void musl cannot promise proprietary NVIDIA support.Acquisition and offline rule. The installed core contains only rights-cleared, versioned assets. Optional browser, language, and other workload packs or tools are prepared explicitly before a benchmark run, with version, origin, digest, size, license/notice inventory, and cache location recorded. No ordinary run downloads, installs, upgrades, changes drivers, or tunes the kernel. If preparation or a required tool is absent, record a capability-coverage outcome. The full Speedometer 3.1 pack remains a conditional candidate: it can ship only after per-asset redistribution rights, a content-addressed manifest, and blocked-outbound-network offline validation are complete. If this cannot be achieved, choose a different browser workload and scoring identity in a new decision ticket; never present a reduced suite as official full Speedometer 3.1. The current archive is not cleared for redistribution.
Process and privilege contract. Keep the InkUI process and measurement runner separate and unprivileged. The runner owns immutable run parameters, explicit executable paths and arguments, controlled environment, resource/deadline limits, process-tree lifecycle, bounded outputs, and persisted partial outcomes. It does not construct workload shell commands. Any privileged diagnostics use narrowly validated operation and target requests; never elevate the whole UI or expose a generic root command runner. Distinguish read-only diagnostics from approved filesystem writes. Cancellation uses process-group ownership, staged termination, descendant/orphan cleanup, exit collection, fixture cleanup, and a durable cancelled or incomplete run record. Refuse active pressure modules when required containment and an independent watchdog cannot be established. Pause decorative UI updates during timed windows; Set distro, VM, and physical-hardware validation gates sets and tests the quantitative UI-overhead limit.
Terminal and Bash contract. Provide a normal executable CLI, stable documented exit statuses, machine-usable plain output for pipes/weak terminals, and no dependence on shell aliases or user startup files. Every action is keyboard-accessible; mouse interaction is available only where reporting is supported and qualified. Plain, no-color, ASCII, and screen-reader-friendly paths retain numeric measurements and warning text. Restore raw input, mouse mode, cursor, and screen state on normal exit and handled interruption; do not claim cleanup after SIGKILL. Evaluate the Bongbetic TUI workflow with InkUI must prove focus, scroll, resize, mouse parity, accessibility, and recovery behavior.
The product owner accepted the runtime, delivery, browser, process, terminal, and support choices in this live exchange. This resolution defines architecture and qualification rules; it does not certify a platform or clear the Speedometer assets.
Evidence: InkUI portability research, Speedometer pack decision, Ink 7.1.1 released manifest, Node 24 platform requirements, Debian 13 Node package, Ubuntu 24.04 Node package, Void musl limitations.
The conditional Speedometer packaging branch is settled in Choose a legally distributable v1 browser workload: v1 selects an Odin-owned browser interaction workload. Its exact pack and protocol remain in Specify Odin’s v1 browser interaction workload. Other runtime and delivery decisions here stand.