Suckless replacement audit

Dotfiles and workstation stack
12 August 2026

Executive conclusion

Your desktop is already built around the four most relevant Suckless programs: dwm, dmenu, st, and slstatus. The audit found only one clear simplification:

  1. Move the ten global shortcuts from sxhkd into dwm and remove sxhkd. This eliminates a daemon and a configuration language while preserving the same scripts and keys.

Most other apparent matches are false economies. surf cannot replace your Chromium-based authenticated browser workflow; tabbed and experimental scroll cannot replace the persistence, panes, popups, and remote operation you use in tmux; sam/ed cannot replace your LSP-based development editors; and Suckless base utilities should not displace Debian/Ubuntu userland underneath these dotfiles.

A cautious outcome is therefore: make one replacement, keep the rest, and do not install Suckless programs merely because they exist. That is more consistent with simplicity and frugality than growing the toolset.

Scope and method

I compared the official projects listed under the Suckless home, tools, and core sections against:

“Using” means declared or directly referenced by these dotfiles. It does not mean that every installed package is used daily. The audit deliberately excludes projects merely listed on Suckless’s “Stuff that rocks” page: those share the philosophy but are not the first-party Suckless tool catalogue requested here.

Recommendations were judged on functional coverage, integration cost, security/reliability, and whether the change actually reduces total complexity. A name or category overlap alone was not treated as a replacement.

Your existing Suckless stack

Suckless program Evidence in the dotfiles Finding
dwm .config/sx/sxrc ends with exec dwm Already the right Suckless window manager.
slstatus .config/sx/sxrc starts it before dwm Already supplies dwm’s status text.
dmenu .local/lib/sh/dmenu.sh, clipboard history, bookmarks, notes, password, OTP, and Bluetooth scripts Deeply integrated and appropriately reused.
st Password, OTP, notes, and bookmark scripts invoke it Already the default lightweight X terminal for these workflows.

This matters because the largest credible substitutions—window manager, launcher, terminal, and status monitor—have already happened. The remaining software mostly handles jobs for which the official catalogue has no equivalent.

Plausible matches that should not be adopted

tmuxtabbed, scroll, or multiple st windows

Recommendation: keep tmux.

tabbed is a generic XEmbed tab container. It can group XEmbed-aware st instances, but it is not a terminal multiplexer. scroll is a terminal scrollback helper whose own page calls it experimental and not recommended for productive use; the page also says a proper experience would require a new terminal emulator like screen or tmux.

Your tmux configuration depends on:

  • named, detachable sessions;
  • windows and split panes;
  • session switching from shell functions;
  • 100,000-line history and copy mode;
  • popups used by Helix’s nnn picker and interactive shells;
  • session restoration plugins;
  • operation inside terminals and remote environments.

Replacing that with tabbed st windows would lose persistence and remote/headless operation while moving pane management up to dwm. It would also break explicit Helix and shell integration. tabbed is suitable only for a narrower, purely local X tab use case that is not evident here.

Helium and LibreWolf → surf

Recommendation: keep the current browsers.

surf is a minimal WebKit2/GTK browser with no native tab UI. It is a credible focused browser for simple sites, but your browser is infrastructure, not just a document viewer:

  • BROWSER=helium is the global default;
  • helium-agent.sh maintains a persistent automation profile;
  • the Pi container installs a pinned Helium build and Selenium support;
  • backup/restore preserves browser state;
  • browser automation requires Chromium-compatible control;
  • bookmarks optionally open LibreWolf;
  • likely work authentication and modern web applications need broad compatibility.

Surf’s own documentation warns, “Compile your own webkit or expect hell,” highlighting WebKit packaging complexity. Installing it would add another browser engine without retiring the existing one. That is the opposite of the desired simplification.

Helix, Neovim, and VS Code → sam or ed from 9base/sbase

Recommendation: keep the development editors.

9base includes Plan 9 sam and ed; sbase also provides ed. They can replace a basic text editor, not the development contract visible here. Helix is integrated with language servers, formatters, tmux popups, nnn, and clipboard commands. Neovim and VS Code are optional but deliberately provisioned with plugins/extensions.

Adopting sam could be an interesting personal experiment, but it would be a new editing workflow rather than a like-for-like replacement. It should not be presented as a complexity reduction unless the language-server and IDE requirements are intentionally abandoned.

BusyBox, GNU utilities, and util-linux → sbase, ubase, or 9base

Recommendation: do not replace the host userland.

Suckless describes sbase and ubase together as a smaller base system comparable to BusyBox. 9base supplies a separate Plan 9-flavoured command set. Your target, however, is explicitly Ubuntu/Debian with apt-get, and the scripts use host-specific command behavior and packages such as flock, setsid, lsblk, udisksctl, and GNU-style options.

Replacing commands in PATH creates subtle semantic risk across bootstrap, backup, cloud, and service scripts. It also does not let you uninstall the distribution’s essential packages safely. BusyBox is intentionally installed for its ash shell and compact applet set, so swapping it for two source-built collections is unlikely to reduce the maintained surface.

Use sbase/ubase only in a deliberately isolated image built and tested around their semantics—not as a shadow userland on this workstation.

runit user supervision → sinit/svc

Recommendation: keep runit.

The X session starts one runsvdir tree, and services already use runit-compatible run/finish scripts. sinit is a minimal PID 1, not a drop-in user service supervisor on Ubuntu. Suckless svc is described only as service scripts and control programs; migrating the mature user tree would create system-integration work without a demonstrated benefit. Replacing Ubuntu’s init is outside the workstation requirement and would increase operational risk substantially.

Screenshot stack (shotgun + hacksaw) → farbfeld ecosystem

Recommendation: keep the current stack.

The screenshot script supports full-screen, selected-region, and active-window capture, then writes PNG to disk and the X clipboard. farbfeld is primarily a simple lossless image format and conversion toolkit, not a direct screenshot workflow. Its page links to xscreenshot, but that utility is listed as a third-party implementation, not one of the official tools in the catalogue. Region selection and clipboard publication would still require other programs.

Changing the intermediate image format would add conversions while final outputs remain PNG. There is no simplification here.

xclipsselp

Recommendation: keep xclip.

sselp only prints the current X selection. Your configuration mostly needs the opposite direction: writing usernames, passwords, filenames, copied tmux text, and PNG screenshots into the clipboard. It also distinguishes primary and clipboard selections and uses MIME type image/png.

sselp could replace the single primary-selection read in clipboard history, but xclip would remain required for every write. Adding a second selection utility to replace one invocation is net complexity.

sxiv and ImageMagick → farbfeld

Recommendation: keep them.

sxiv is used as an image viewer by .local/bin/open.sh and has a configured key handler. Farbfeld itself is a format plus converters, not a first-party graphical viewer. Its ecosystem can interoperate with viewers, including sxiv through imlib2, but does not remove the viewer requirement. ImageMagick and farbfeld also have different breadth: replacing general conversion and manipulation with pipelines would require a task-by-task audit not justified by current evidence.

OBS/ffmpeg → blind

Recommendation: keep OBS and ffmpeg.

blind is a command-line video-processing collection for composing video. Its documentation explicitly says it is not designed for small edits, uses very large raw intermediate data, has no audio support, and expects ffmpeg for extracting or adding audio. Your scripts use ffmpeg for screen/audio recording, and OBS has a recording profile. Blind cannot replace capture, live composition, hardware encoding, or audio; it would supplement ffmpeg rather than remove it.

Python publication server → quark

Recommendation: keep the current publisher.

quark is a small GET/HEAD static server. publish.py, however, is not only static hosting: it renders Djot, publishes atomically, maps stable job-log URLs to the newest rotated file, converts ANSI logs to HTML, and sends no-store headers. Quark could serve the generated static report directories only, but the Python service would remain for dynamic log behavior—or that behavior would need a separate generator and routing scheme.

That split adds a daemon and interface. The existing Python standard-library server has no extra package dependency and keeps the contract in one auditable file. Quark becomes attractive only if publication is redesigned to be entirely pre-generated static content for an independent reason.

Slack/Matrix → ii, sic, or lchat

Recommendation: no replacement.

ii, sic, and lchat are IRC clients/frontends. Your tools target Slack and Matrix protocols and APIs. Similar user intent (“chat”) does not provide protocol compatibility. A bridge would add infrastructure rather than remove it.

Grafana/SearXNG/FreshRSS → quark or other Suckless tools

Recommendation: no first-party replacement.

Grafana serves interactive SQLite-backed dashboards; SearXNG aggregates search engines; FreshRSS maintains feed state and an API consumed by scheduled jobs. Quark only serves static files. Suckless’s “Stuff that rocks” page mentions sfeed, but it is outside the official catalogue and replacing FreshRSS’s server-side state, API, and mark-read workflow would be a separate product decision. None is a direct substitution.

Tools with no meaningful official counterpart

The following declared or configured areas should not be forced into a Suckless comparison:

The correct Suckless choice here is often no new tool.

Decision matrix

Current tool or subsystem Candidate Functional fit Net simplification Decision
sxhkd dwm built-in keys High High Replace
tmux tabbed / scroll Low Low Keep
Helium / LibreWolf surf Low for this workflow Negative Keep
Helix / Neovim / VS Code sam / ed Low Negative Keep
BusyBox / GNU / util-linux sbase / ubase / 9base Medium in isolation Negative on Ubuntu Keep
runit user tree sinit / svc Low Negative Keep
shotgun + hacksaw farbfeld ecosystem Low Negative Keep
xclip sselp Partial, read-only Negative Keep
sxiv / ImageMagick farbfeld Partial Negative Keep
OBS / ffmpeg blind Low Negative Keep
publish.py HTTP service quark Partial, static only Negative today Keep
Slack / Matrix ii / sic / lchat None: different protocols Negative Keep
Grafana / SearXNG / FreshRSS quark and related tools None/partial Negative Keep

Final plan

Do now

  • Make the dwm source and patch set reproducible in the dotfiles.
  • Move the ten sxhkd shortcuts into dwm.
  • Remove sxhkd only after complete shortcut testing.

Do not do

  • Do not replace tmux, the browser, editors, userland, runit, screenshot stack, xclip, media tools, or services with weaker category matches.
  • Do not add Suckless tools as optional alternatives without a concrete workflow that retires an existing dependency.

Revisit only if requirements change

  • Consider slock if you need an X screen locker; there is no current locker to replace. Note that xhisper is speech dictation, not locking.
  • Consider sent for future plaintext presentations, not as a replacement for an existing configured tool.
  • Consider quark only if publication and logs become fully pre-generated static files.
  • Consider sbase/ubase only inside a purpose-built minimal image, not on the Ubuntu host.

Sources

Official Suckless pages

Local evidence reviewed

  • README.md, mkfile, bootstrap.sh
  • setup/install-tools.sh, setup/packages/*.sh, setup/toolchains.sh
  • .config/sx/sxrc, .config/sxhkd/sxhkdrc, .config/sxhkd/scripts/*
  • .config/tmux/tmux.conf, .config/helix/*, .config/sh/env, .config/sh/functions
  • .local/bin/screenshot.sh, .local/bin/open.sh, .local/bin/publish.py, browser and recording scripts
  • Grafana, SearXNG, FreshRSS, runit, OBS, sxiv, and Pi configuration present in the repository