Usage
Daily operation, performance habits and realistic workloads for a working ternux desktop. This page assumes the environment is already installed; it does not reproduce the private deployment procedure.
Starting and stopping
x # start the desktop
killx # stop it and clear stale session state
xgo # open Termux:X11, then start the desktop
The usual sequence is: open Termux:X11, leave it running, switch to Termux,
type x, then return to Termux:X11. xgo combines the app launch and desktop
start.
Keep Termux running in the background while the desktop is active. If Android ends the session without a useful error, see the public support boundaries.
Everyday shell controls
| Command | Purpose |
|---|---|
x |
Start the desktop |
killx |
Stop the desktop and clear stale X11/audio state |
xgo |
Open Termux:X11 and start the desktop |
db |
Enter Debian as the normal user |
droot |
Enter Debian as root; use only when required |
sysmon |
Show CPU, memory and GPU-node information (Pro) |
clean-mesa |
Clear the Mesa shader cache (Pro) |
ai |
Open the local-model launcher when the AI profile is installed (Pro) |
Files and Android storage
Your Debian home and Termux home are separate. Use shared storage for documents that must be visible to Android apps:
termux-setup-storage # one-time Android permission request
cp report.pdf ~/storage/shared/
Keep source code in Git and back up irreplaceable project files outside the container.
Prove graphics acceleration first
From a terminal inside Xfce4:
glxinfo | grep -i "renderer string"
vulkaninfo --summary
| Renderer | Interpretation |
|---|---|
zink ... Adreno ... MESA_TURNIP |
Preferred hardware-accelerated path |
virgl ... |
Expected compatibility path on non-Adreno hardware |
llvmpipe |
CPU rendering; treat this as an unhealthy accelerated setup |
A short glmark2 run is useful as a personal baseline, but scores are not
portable between phones. SoC, display resolution, Android build, Mesa version,
thermal state and background apps all matter.
What runs well?
| Workload | Practical fit | Notes |
|---|---|---|
| Xfce4, terminal, Git, editors | Good | The everyday core of the environment |
| Firefox ESR and light web apps | Good with RAM discipline | A few tabs are better than a desktop-sized session |
| Lightweight Blender work | Useful on a strong Turnip device | Low-poly modelling, simple materials and modest scenes |
| Local 1–2B Q4 models | Useful, device-dependent | Vulkan helps; RAM, context and temperature still set the limit |
| Node.js and coding agents | Good for terminal workflows | Provider accounts and API/model terms still apply |
| Network/security lab tools | Useful with Android limits | For authorised testing; low-level radio access may be unavailable |
| Heavy rendering or simulation | Poor fit | Long jobs expose thermal and memory limits |
| Sustained cryptocurrency mining | Not recommended | Heat, battery drain and wear outweigh the novelty |
Lightweight Blender
Blender is a notable proof of what the accelerated desktop can do. On the author’s tested Turnip-enabled phone, the viewport was smooth enough for lightweight modelling and scene work.
Good targets
- Low-poly modelling and mesh edits
- Basic UV work and simple materials
- Small scene layout and object transforms
- Reviewing assets or making quick corrections away from a PC
- Short viewport sessions with modest texture sizes
Set realistic limits
Complex sculpting, high-resolution textures, dense geometry, simulations and long final renders are desktop workloads. Keep scenes small, prefer solid or material-preview modes when possible, lower viewport samples, save frequently and watch device temperature.
The Blender observation is an author-reported result, not a controlled cross-device benchmark. Performance can change substantially with GPU, driver, RAM and scene complexity.
Local AI with Vulkan
The optional Pro AI profile uses llama.cpp’s Vulkan backend on the same graphics path as the desktop. Compact GGUF models can provide private, offline chat and small assistant workflows directly on the phone.
Practical starting points:
- 1–2 billion parameters
- Q4 quantisation
- Conservative context size
- One active inference job at a time
Start through the supplied ai launcher or the local dashboard. Keep local
servers bound to 127.0.0.1 unless you deliberately add authentication and
network controls. Binding an unauthenticated model endpoint to all interfaces
exposes it to other devices on the network.
GPU offload does not remove thermal limits. If generation slows over time, check temperature and allow the device to cool before changing software.
Development and AI agents
A Debian environment can host Git, build tools, Node.js/npm and terminal-based coding assistants such as Claude Code, Hermes Agent or OpenCode. Treat each as a separate third-party product:
- Check its current licence, model-provider and account requirements.
- Store API keys in the tool’s supported credential mechanism, not in shell history, project files or public screenshots.
- Review proposed commands before approval, especially when running as root.
- Keep repositories committed and pushed before allowing broad automated edits.
- Expect large dependency trees to consume storage quickly.
No assistant is “always free” by virtue of running inside ternux; model access, quotas and pricing are controlled by its provider and can change.
Authorised network and security lab
Standard Debian packages make ternux useful for portable defensive work:
- Discovery and inventory: Nmap and Masscan
- Packet and protocol analysis: Wireshark and related command-line tools
- Web assessment: Nuclei, Nikto, Gobuster and SQLMap
- Password auditing: Hashcat and John the Ripper
- Framework-based validation: Metasploit in a controlled lab
Use these tools only against devices, applications and networks you own or have explicit permission to test. Keep written scope for professional engagements.
PRoot is not a full privileged Linux host. Wi-Fi monitor mode, packet injection, some raw-socket operations, direct USB access and high-performance GPU compute may be restricted by Android, the kernel and device drivers. A phone can be a useful console and analysis station without replacing dedicated lab hardware.
Audio
Test audio from inside the desktop:
speaker-test -c 2 -t sine
Silence usually means the Termux-side audio bridge is not healthy. A clean
killx followed by x restarts the session. If it persists, see
Support & diagnostics.
Performance and thermals
- Expect a slower first launch. Mesa compiles and caches shaders.
- Prefer native/light applications. Every Debian process competes with Android for the same RAM.
- Close unused browser tabs and background agents. Memory pressure often looks like a graphics problem.
- Use short, representative tests. A phone may benchmark well for a minute and throttle during sustained work.
- Keep airflow around the device. Stop if the phone becomes uncomfortably hot or Android shows a thermal warning.
- Do not optimise blindly. Save a known-good renderer and benchmark baseline before changing Mesa or environment variables.
Maintenance
Inside Debian, apply routine package updates deliberately and review what they will replace. On Adreno, do not casually unhold or overwrite the Mesa components selected for Turnip.
Before a major update:
- Save or commit current work.
- Create a container backup.
- Record the current renderer and toolkit version.
- Read the ternux release notes.
- Update, restart cleanly and verify graphics/audio again.
Pro users should prefer the version-matched updater and run --status or
--doctor after maintenance.
ternux — Copyright (c) 2026 Sobuj Miah (@soobujmiah) · MIT