RFC: Linux client naming — cmux vs lmux

[Jesssullivan]

Summary

This RFC tracks the Linux client naming question (cmux vs lmux or another fork-specific name).

It is intentionally non-blocking.

Current stance as of 2026-04-21

• do not let naming churn block distro proof, upstream ingestion, or parity work
• the repo can continue shipping and validating the Linux client while this issue remains open
• revisit only after the distro-proof lane is in a materially better state

Revisit triggers

• Linux release/distribution posture changes enough that the name creates real user confusion
• a packaging/distribution surface requires a clearer split between macOS-first cmux and Linux client branding
• there is a concrete migration plan, not just naming preference discussion

References

• docs/linux-mvp-architecture.md
• docs/fork-landscape.md
• #55

[Jesssullivan]

Status refresh as of April 13, 2026.

This RFC is still valid, but it is not on the Linux delivery critical path.

The current blocker set is:

• distro validation
• parity promotion based on real proof
• packaging/runtime confidence
• clear constrained-distro handling for Rocky 10

Naming should stay explicitly non-blocking until those are in a healthier state.

Checked-in references:

• docs/program-status.md
• docs/component-portfolio.md
• docs/linux-program-plan.md
• docs/linux-parity-matrix.md

[Jesssullivan]

Current recommendation after the distro-readiness review:

• keep cmux as the product, repo, binary, and package name for now
• keep #76 explicitly non-blocking
• revisit only if a real rename trigger appears, such as:
  1. distro packaging requires cmux and a Linux-specific variant to coexist as distinct installable products
  2. Linux becomes a materially different product surface
  3. the release/docs story becomes actively confusing under the shared name
  4. there is a concrete migration plan for binary names, package names, and user docs

Reference: docs/distro-testing-readiness-plan.md.