Establish InkUI architecture and Linux delivery options #6

New Issue

2026-09-25T17:48:48Z

xavierk commented

2026-09-25 17:48:48 +00:00

Part of Find the way to Odin’s build-ready specification.

Question

What current architecture and delivery options can satisfy the required InkUI terminal experience on modern x86_64/aarch64, glibc/musl, Void/xbps, deb and rpm distributions?

Inspect the exact kamlesh723/inkui source, React/Ink/runtime constraints, release maturity, MIT source-copy model, themes, keyboard focus, mouse events/hit testing, graph limitations and terminal cleanup. Verify terminal/SSH/tmux/console, Unicode/color/NO_COLOR/non-TTY accessibility behavior and fallback requirements. Compare current maintained Node/Bun or other compatible runtime options and whether measurement helpers require another language; do not choose a stack solely because it is new. Investigate runtime/kernel floors, portable artifacts versus distro packages, offline execution/dependency acquisition, privilege boundaries, process supervision/cancellation, capability probing and measurement isolation from UI overhead. Propose a certification matrix and distinguish VM coverage from real hardware needs.

Deliver cited tradeoffs and explicit unsupported assumptions; the UI library is a user constraint. Do not implement the application or install packages.

Part of [Find the way to Odin’s build-ready specification](https://git.bongbetic.com/xavierk/odin/issues/1).  ## Question What current architecture and delivery options can satisfy the required InkUI terminal experience on modern x86_64/aarch64, glibc/musl, Void/xbps, deb and rpm distributions? Inspect the exact kamlesh723/inkui source, React/Ink/runtime constraints, release maturity, MIT source-copy model, themes, keyboard focus, mouse events/hit testing, graph limitations and terminal cleanup. Verify terminal/SSH/tmux/console, Unicode/color/NO_COLOR/non-TTY accessibility behavior and fallback requirements. Compare current maintained Node/Bun or other compatible runtime options and whether measurement helpers require another language; do not choose a stack solely because it is new. Investigate runtime/kernel floors, portable artifacts versus distro packages, offline execution/dependency acquisition, privilege boundaries, process supervision/cancellation, capability probing and measurement isolation from UI overhead. Propose a certification matrix and distinguish VM coverage from real hardware needs. Deliver cited tradeoffs and explicit unsupported assumptions; the UI library is a user constraint. Do not implement the application or install packages.

xavierk added the wayfinder:research label 2026-09-25 17:48:48 +00:00

xavierk added a new dependency 2026-09-25 17:49:50 +00:00

#9 Choose Odin’s runtime and Linux compatibility contract

xavierk added a new dependency 2026-09-25 17:50:00 +00:00

#12 Define local results, history, and export behavior

xavierk added a new dependency 2026-09-25 17:50:04 +00:00

#14 Set distro, VM, and physical-hardware validation gates

xavierk self-assigned this 2026-09-25 17:50:16 +00:00

xavierk commented

2026-09-25 18:03:01 +00:00

Research resolution

The research establishes viable architecture options and their constraints; it does not select the final stack.

The requested InkUI is a source-copy component collection targeting React 19 and Ink 6. Its themes, keyboard controls, basic charts, and source ownership are verified; terminal mouse interaction and complete accessibility/fallback behavior need application work.
Node 24 is a maintained baseline candidate. Node 20 is EOL. Ink 7.1.1 offers useful coordinates and terminal controls, but adapting copied InkUI components beyond their declared Ink 6 range needs qualification.
Bun offers artifacts for both architectures and libcs, but documented subprocess/process differences make it a candidate behind a compatibility gate, not an automatic portability solution.
Node’s official glibc floor and experimental/absent musl platform tiers differ from downstream Void packages. Void explicitly excludes proprietary NVIDIA drivers on musl; packaging cannot remove that hardware-software constraint.
The report compares native packages, portable runtime archives, and compiled Bun artifacts, including update ownership, reproducible versions, offline acquisition, and xbps/deb/rpm differences.
Keyboard parity, mouse hit testing, resize/scroll coordinates, terminal cleanup, plain/non-TTY output, color/Unicode policies, and screen-reader behavior need an interaction proof.
Measurement supervision and narrowly validated privileged operations should be owned separately from the UI. Live rendering still competes for hardware even in another process, so quiet windows and an overhead budget need validation.
Proposed certification lanes distinguish runtime/package/terminal VM coverage from GPU, SMART, thermals, and memory evidence that needs physical hardware.

Read the cited research report. Evidence is recorded at commit 20681cd4f184 on research/portability-ui.

Still for the human decision tickets: runtime/Ink version pair; packaging/update ownership; exact distro/kernel/libc floors; optional workload acquisition; mouse/accessibility criteria; containment, cancellation and UI-overhead thresholds; physical validation access.

Evidence limits: this is source research, not cross-platform certification. No application builds, installations or benchmark runs were performed. Context7 did not index the requested InkUI project; the exact repository, released manifests, and registry were inspected instead.

## Research resolution The research establishes viable architecture options and their constraints; it does **not** select the final stack. - The requested InkUI is a source-copy component collection targeting React 19 and Ink 6. Its themes, keyboard controls, basic charts, and source ownership are verified; terminal mouse interaction and complete accessibility/fallback behavior need application work. - Node 24 is a maintained baseline candidate. Node 20 is EOL. Ink 7.1.1 offers useful coordinates and terminal controls, but adapting copied InkUI components beyond their declared Ink 6 range needs qualification. - Bun offers artifacts for both architectures and libcs, but documented subprocess/process differences make it a candidate behind a compatibility gate, not an automatic portability solution. - Node’s official glibc floor and experimental/absent musl platform tiers differ from downstream Void packages. Void explicitly excludes proprietary NVIDIA drivers on musl; packaging cannot remove that hardware-software constraint. - The report compares native packages, portable runtime archives, and compiled Bun artifacts, including update ownership, reproducible versions, offline acquisition, and xbps/deb/rpm differences. - Keyboard parity, mouse hit testing, resize/scroll coordinates, terminal cleanup, plain/non-TTY output, color/Unicode policies, and screen-reader behavior need an interaction proof. - Measurement supervision and narrowly validated privileged operations should be owned separately from the UI. Live rendering still competes for hardware even in another process, so quiet windows and an overhead budget need validation. - Proposed certification lanes distinguish runtime/package/terminal VM coverage from GPU, SMART, thermals, and memory evidence that needs physical hardware. [Read the cited research report](https://git.bongbetic.com/xavierk/odin/src/commit/20681cd4f184a9fc0164dd638a252de44ef230f5/docs/research/portability-ui.md). Evidence is recorded at commit `20681cd4f184` on `research/portability-ui`. **Still for the human decision tickets:** runtime/Ink version pair; packaging/update ownership; exact distro/kernel/libc floors; optional workload acquisition; mouse/accessibility criteria; containment, cancellation and UI-overhead thresholds; physical validation access. **Evidence limits:** this is source research, not cross-platform certification. No application builds, installations or benchmark runs were performed. Context7 did not index the requested InkUI project; the exact repository, released manifests, and registry were inspected instead.

xavierk closed this issue

2026-09-25 18:03:03 +00:00

xavierk referenced this issue

2026-09-25 18:03:04 +00:00

Find the way to Odin’s build-ready specification #1

Sign in to join this conversation.