genact fakes twenty-one kinds of work in your terminal

Twenty-one modules that print work without doing any

genact is a single Rust binary that streams text shaped like long-running terminal jobs. Start it with no arguments and a scene begins, then keeps running until something stops it. Each scene is a module, and the module set is fixed rather than extendable. The `--modules` flag enumerates 21 possible values: ansible, bootlog, botnet, bruteforce, cargo, cc, composer, cryptomining, docker_build, docker_image_rm, download, julia, kernel_compile, memdump, mkinitcpio, rkhunter, simcity, terraform, uv, weblog, wpt. Those names are the product. A bootlog or kernel_compile scene reads as believable because the surrounding lines stay consistent, and a passerby scans the names rather than the project behind them. What you cannot do is extend the list from outside the binary. There is no config file at the top level of the repository, no plugin directory, and no flag in the help output that points at the data/ or static/ directories, so a new scene means writing Rust and rebuilding.

Six install routes, and only one compiles from source

Prebuilt binaries for Linux, macOS and Windows sit on the releases page and are described as running without any dependencies. FreeBSD needs two lines and nothing special:

pkg install genact
genact

On macOS, Homebrew is the short path and MacPorts is the alternative:

brew install genact

sudo port install genact

Windows is covered by Scoop, and the raw artefact is a single .exe you double click:

scoop install genact

On Linux the release is a file you mark executable yourself:

chmod +x genact-linux
./genact-linux

The macOS release is the same two lines pointed at genact-osx. The crates.io route compiles from source and needs a recent Rust and Cargo:

cargo install genact
genact

That last one is also the one to watch. Cargo.toml sets edition = 2024, so an older toolchain fails at the manifest rather than at the program. A gah install line exists too, for people who manage binaries that way.

Speed factor and two exit flags decide how long the show runs

Four flags decide pacing and stopping. `--speed-factor` is global and defaults to 1, so a higher multiplier changes typing and delays across every module at once, not in one scene. `--instant-print-lines` also defaults to 0, which prints nothing instantly; raising it prints that many lines right away, the quickest way to fill an empty screen before the paced output resumes. Two exit flags matter more if something else has to stop the run:

./genact --exit-after-time 2h10min

The value is parsed with humantime, which the project depends on, and 2h10min is the format given in the help text. `--exit-after-modules` stops after a count of scenes instead of a duration, which is the flag that lets a display cycle and return. For inspection, `--list-modules` prints the names and stops. What the help text does not describe is any per-module tuning, a colour override, or a width setting, so line wrapping follows whatever terminal_size reports on native builds.

The WebAssembly build drops every flag that needs clap

A browser build runs at https://svenstaro.github.io/genact/ and takes two query parameters:

https://svenstaro.github.io/genact?module=cc&module=memdump

https://svenstaro.github.io/genact?speed-factor=5

The repeated module parameter narrows the show the way `--modules` does on the command line, and speed-factor sets the same global multiplier. The gap is in the flags. Cargo.toml puts clap, clap_complete, clap_mangen, ctrlc and terminal_size behind cfg(not(target_arch = "wasm32")), so argument parsing, shell completion, man page output and the interrupt handler exist only in the native binary. `--help`, `--print-completions`, `--print-manpage` and `--version` are unreachable from a browser tab. The wasm block pulls in console_error_panic_hook, js-sys, url, wasm-bindgen and a web-sys feature set trimmed to Window, Location and console. Between the three builds there is a real choice: native has the full flag set and terminal-aware width, the container image shares the same CLI so it buys isolation rather than features, and the browser has two parameters and nothing else:

docker run -it --rm svenstaro/genact -h

No HTTP client in Cargo.toml, so botnet and bruteforce stay on screen

Three module names read like offensive tooling: botnet, bruteforce and cryptomining. They are text scenes and nothing more. The dependency list in Cargo.toml holds anyhow, async-trait, tokio, chrono, fake, colorgrad, humansize, humantime, instant, progress_string, getrandom, rand, rand_distr, regex, sha2, hex and yansi. There is no HTTP client, no socket library and no credential handling code among them. The one platform-specific entry is keepawake 0.6.0, gated to Linux, macOS and Windows so the display stays awake during a scene. So a cryptomining scene in a screen share mines nothing and contacts no host, and the characters in a bruteforce scene come from the rand crates rather than from attempts against a real service. If your concern is someone running this to look busy during a review or a pair session, that boundary is the thing to know, and the README does not warn about it.

Trunk and upx are build tools the build steps never name

The documented build is three commands and yields the native binary only:

git clone https://github.com/svenstaro/genact.git
cd genact
cargo run --release

The homepage build comes from a Makefile target that the README never mentions:

RUSTFLAGS='--cfg getrandom_backend="wasm_js"' trunk build --release

Trunk appears nowhere in the install or build text, and the top-level Trunk.toml is the only trace of it. The three native packaging targets add a further layer: each one builds a cross target, strips the binary and then runs upx --lzma over it, so reproducing a release artefact needs musl or mingw toolchains, strip and upx present on your machine. The release profile in Cargo.toml is tuned the same way, with lto = true, opt-level = 'z' and codegen-units = 1, a trade of build time and execution speed for a smaller file. For local use none of this applies, and cargo install genact is the cheap route.

Eight months between v1.5.0 and v1.5.1, then v1.6.0 in October

Release cadence is uneven. v1.5.0 shipped on 2026-01-08, v1.5.1 on 2026-01-26, and v1.6.0 on 2026-10-01. The last push to the master branch was on 2026-11-02. The repository is current, but nine months separate the two recent minor lines, closed by a single patch release in January. The version field in Cargo.toml reads 1.6.0 and tracks the tag. Upgrade cost is low in the usual sense: there is no runtime configuration to migrate, and nothing on disk changes when you swap the binary. The same gap is the risk for anyone who pinned a build, since a Linux, macOS, Windows or FreeBSD binary from January can sit a full minor version behind. The maintainer keeps the release steps in the README as a personal note, which includes this command:

cargo release --execute <version>

Before that, CHANGELOG.md has to be updated, and the Arch package is updated after the release, so a new release does not mean every downstream package has moved.

Editorial conclusion

Adopt genact if you want a screen that looks occupied and nothing else, and take the native binary when you need the full flag set. Do not reach for it when you need real build, deploy or monitoring work, since the README says nothing is actually happening behind the output. Before you commit, check two things: whether the 21 module names match what your audience reads as real work, and whether your platform sits inside the cfg blocks in Cargo.toml, since keepawake only builds on Linux, macOS and Windows.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. svenstaro/genact on GitHub