Linutil: a distro-agnostic Linux toolbox you drive from a terminal menu

What Linutil actually automates, and who the menu is for

Linutil is a distro-agnostic toolbox for everyday Linux tasks: setting up applications and optimizing a system for a specific use case, in the wording of the README. The unit of work is a script, and the interface is a terminal menu rather than a set of flags you memorize. That makes the target user someone who has just installed a distribution and wants a short path to a working desktop, not someone writing a provisioning pipeline.

The scripts live in the repository under core/ and tui/, and the workspace Cargo.toml lists those two as default members, with xtask as a third member for build tooling. The project is written in Rust, and the README describes that choice as providing performance and reliability. The practical consequence for a user is a single binary with a full-screen interface, not a Bash bundle you source into your shell.

Distro-agnostic is the claim worth examining. The README documents packages for Arch Linux (three AUR variants), OpenSUSE (zypper) and Cargo, and the install script routes through christitus.com. The scripts themselves have to detect the distribution at runtime, which is where a toolbox like this earns or loses trust: the same menu entry can resolve to apt on one machine and pacman on another. The README does not enumerate per-distro coverage, so treat the menu as the source of truth on your own system.

The TUI, the script layer, and the config file that bypasses both

The architecture is visible in the repository layout. There is a core/ crate and a tui/ crate in one Cargo workspace, plus a man/ directory and a linutil.desktop entry. The TUI is the front end that presents categories and entries; the scripts are the back end that performs the work. A selection in the menu runs a script, and the script is where all the system changes happen.

The part that changes how you use Linutil is the TOML configuration file. The README lists three options: auto_execute, a list of commands to execute automatically; skip_confirmation, a boolean equal to the --skip-confirmation flag; and size_bypass, a boolean equal to --size-bypass. The path to the file is passed with --config or -c. The README's example names entries as strings:

# example_config.toml
auto_execute = [
    "Fastfetch",
    "Alacritty",
    "Kitty"
]
skip_confirmation = true
size_bypass = true

Those three strings are menu entry names, not shell commands, and that is the design decision that matters. Automation here means replaying a known list of toolbox entries, not composing arbitrary commands. If you want a step that Linutil does not ship, the config file cannot express it. The README also notes that auto_execute can be combined with --skip-confirmation, which is exactly the combination that removes the human from the loop; the confirmation prompt is the last thing standing between a wrong entry name and an applied change.

Installing Linutil and running a first automated pass

The README gives a one-line install for the stable branch, which it recommends, and a separate command for the dev branch. The stable command pipes a script from christitus.com into sh:

curl -fsSL https://christitus.com/linux | sh

After that runs, you should have linutil available. The README points to linutil --help for available options, and for installer options specifically it shows the same curl command with arguments forwarded:

curl -fsSL https://christitus.com/linux | sh -s -- --help

If you prefer a package manager, the README documents three AUR packages for Arch Linux. linutil is the stable release compiled from source, linutil-bin is the stable release pre-compiled, and linutil-git is compiled from the last commit, which the README marks as not recommended. With an AUR helper the command is short:

paru -S linutil

OpenSUSE users get sudo zypper install linutil, and Rust users can install the published crate:

cargo install linutil_tui

The README notes that crates installed this way need manual updating with cargo install --force, and links to the user guide's Applications Setup section for update functionality inside Linutil. For a first real use, write the example config from the README to a file and point Linutil at it:

linutil --config /path/to/example_config.toml

With auto_execute populated and skip_confirmation set to true, the listed entries run without prompts. Start with one or two entry names you recognize, and check that the names match what the menu displays on your machine before adding more.

Where Linutil is the wrong tool

The README carries a warning worth repeating: since the project is still in active development, you may encounter some issues, and it asks for feedback through the issue tracker. That sentence is the honest boundary of the project. A toolbox whose entries run with elevated privileges and whose failure mode is a half-applied system change is not something to put in front of an unattended fleet without a rollback story, and the README does not document rollback.

The second limitation is scope by design. auto_execute takes menu entry names, so the automation surface is exactly the set of scripts the project ships. If your setup needs a step outside that set, you are back to writing your own script, and Linutil becomes an optional front end rather than the mechanism. Teams with configuration management already in place will find the TUI adds a manual step rather than removing one.

The third is the install path itself. The recommended install pipes a remote script into sh, which means you are trusting whatever christitus.com serves at that moment. The AUR and Cargo routes avoid that, at the cost of a package manager or a Rust toolchain. Choose deliberately; the README presents both without ranking them beyond calling stable the recommended branch.

How Linutil differs from a general-purpose configuration manager

The closest comparison is Ansible, and the difference is in what is being described. Ansible playbooks declare desired state for a host or a group of hosts, are idempotent by convention, and are checked into version control as the record of what a machine should look like. Linutil presents a menu of scripts and runs the ones you pick. It does not model desired state, and the README does not describe idempotency guarantees for the entries.

That distinction decides the use case. If you manage ten machines that must converge on the same configuration and you need to know when they drift, Linutil is the wrong layer: the TOML config replays a list of entries on one machine, and there is no inventory, no reporting and no drift detection in the documentation. If you manage one workstation and you reinstall it twice a year, a menu of maintained scripts beats writing and re-debugging your own post-install script, because someone else keeps the per-distro branches current.

A second reference point is the distribution's own package manager. zypper, pacman and apt install software; Linutil's entries often wrap those same commands plus configuration steps around them. The value is the curation and the distro detection, not a new installation mechanism. If you already know the commands for your distribution, the toolbox saves typing, not knowledge.

Maintenance, releases and the MIT licence

Linutil is not archived, and the last push to the default branch was on 2026-07-17. The release history shows tagged releases at 2026.04.07, 2026.05.21 and 2026.07.17, so the cadence over that window is roughly every six to eight weeks. The workspace version in Cargo.toml is 26.7.17, which tracks the release date rather than a semantic major.minor.patch scheme; expect version numbers to look like dates.

Upgrade cost depends on how you installed it. AUR and zypper installs follow your normal package upgrade path. A cargo install linutil_tui install does not update itself, and the README states that such crates require cargo install --force to update, while pointing to the user guide's Applications Setup section for update functionality inside Linutil. The curl install script is fetched fresh each time you run it, so what you get depends on what the server serves that day.

The project is MIT licensed, which the workspace Cargo.toml confirms with license = "MIT" and the repository carries a LICENSE file. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. That covers the code. It does not cover the scripts' effects on your system, and it is not a warranty; the README's development warning is the practical version of that point. This is a description of the licence terms, not legal advice for your situation.

Editorial conclusion

Linutil fits people who reinstall Linux often and want a menu of setup scripts instead of hunting down commands, and it fits anyone who wants to automate a known set of those scripts through a TOML config. It does not fit unattended fleet provisioning or hosts where you cannot tolerate a script changing system state, because the README states the project is still in active development and you may encounter issues. Before adopting it, read the documentation at linutil.christitus.com, run linutil --config with a small auto_execute list on one machine, and confirm which branch (stable or dev) your install command pulls.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes