Configuration

Configuration should describe intent and safe limits, not force users to edit a generated launcher blindly. The exact version-bound Pro schema and migration commands belong to the private operator documentation.

ternux Pro is not publicly released. Names and defaults described here are product concepts until they are frozen in a private-beta release.

Graphics route

Mode	Intended behaviour
Automatic	Detect the device evidence and select the supported route
Turnip / Zink	Preferred route for supported Qualcomm Adreno devices
VirGL	Compatibility route for Mali, Xclipse, PowerVR and other GPUs

Automatic should be the normal choice. Forcing Zink cannot make non-Adreno hardware support Turnip, and forcing VirGL on a healthy Adreno device may reduce performance.

A graphics-route change is not complete until the desktop is restarted and the renderer is verified. A visible desktop with llvmpipe is not an accepted accelerated configuration.

User and locale

The Debian desktop should run as a normal container user. Root is reserved for narrow administrative operations. The username is chosen before deployment; renaming it later affects home paths, ownership and runtime directories and should use a documented migration rather than search-and-replace edits.

UTF-8 locale and font coverage are separate concerns. Keeping English diagnostic messages can make troubleshooting easier while still installing fonts for Bangla and other scripts.

Workload profiles

Optional profiles should be independent and opt-in:

Profile	Typical contents	Main constraint
Development	Git, build tools, Node.js and selected terminal agents	Dependency storage and third-party credentials
Local AI	Vulkan-enabled llama.cpp and local-model controls	RAM, model/context size and thermals
Creative	Blender and selected media tools	Scene complexity, texture memory and sustained load
Security lab	Defensive discovery, analysis and audit tools	Authorisation and Android/PRoot hardware limits

Add one profile at a time and verify renderer, audio and free storage after each change. The desktop itself should not depend on optional profiles.

Local-AI resource policy

Reasonable phone defaults favour reliability over a peak screenshot:

Compact 1–2B Q4 models first
Conservative context size
One compile or inference job when memory is tight
Loopback-only local service by default
Explicit thermal cooldown before assuming a software regression

Build parallelism should be derived from available memory as well as CPU count. Using every core can trigger memory pressure, Android process policy and thermal throttling.

Blender profile

The lightweight creative profile should start with modest texture sizes, conservative viewport samples and a small validation scene. It should not change the desktop’s global graphics route just to optimise one application without re-running renderer acceptance checks.

Treat final-render settings separately from viewport settings. A smooth viewport on a low-poly scene does not establish a safe long-render configuration.

Shader cache

A persistent Mesa shader cache reduces repeated startup work. Cache size is a trade-off:

Larger caches improve repeat launches for varied GL applications.
Smaller caches preserve storage on devices carrying local models or media.
Clearing the cache is a troubleshooting action, not routine maintenance.
The first launch after clearing it will be slower.

The private operator guide should name the version-specific location and safe cleanup control; users should not delete unrelated cache or driver files.

Audio and local services

Audio and local model services should bind to loopback by default. Moving a service from 127.0.0.1 to all interfaces changes the security model: it may become reachable by other devices on the network.

Any intentional network exposure needs authentication, firewall scope, a clear listen address and a documented stop procedure. Never publish provider tokens inside launcher files or URLs.

Security hardening

Use the normal Debian user for daily work and coding agents.
Keep secrets out of shell history, Git and support bundles.
Review third-party install scripts before execution.
Restrict passwordless administrative access to the minimum supported set.
Keep local endpoints on loopback unless network access is intentional.
Back up before driver, package or desktop-environment changes.
Use security tools only within written or explicit authorisation.

A single-user phone container has a different risk profile from a shared server, but it is still capable of storing valuable source code and credentials.

Update policy

An update should have four artifacts:

Current toolkit and renderer report
Backup or verified recovery point
Release notes describing graphics and schema changes
Post-update renderer, audio, storage and launch checks

Mesa changes deserve special caution because the desktop can continue opening while silently changing graphics route. The Pro updater should preview and verify those changes rather than relying on package-manager success alone.

Configuration ownership

Generated configuration should include its toolkit version and distinguish user-owned values from installer-owned state. Manual edits to generated files need either a supported override or a warning that the next update may replace them.

The private Pro documentation will publish the supported schema, accepted values, migration rules and recovery behaviour for each release. Placeholder flags or illustrative installer commands are deliberately not published here.