CLI tool
nickjj/dotfriedrice avatar
nickjj/dotfriedrice

DotFriedRice: an opinionated developer workstation setup

Set up a developer friendly niri / Arch Linux system in minutes. Also supports WSL 2, Debian, Ubuntu and macOS for CLI tools!

1,350 stars202 forksShellMIT

At a glance

What is it?
DotFriedRice packages shell, terminal, editor, security-key, and optional niri desktop configuration into a customizable installation flow for Arch Linux, Debian, Ubuntu, WSL 2, and macOS. It suits developers who want a ready-made workstation, but its opinionated defaults and limited release history require review before adoption.
Who is it for?
DotFriedRice is a reasonable choice for a developer or power user who wants a fast, opinionated starting point, especially on Arch Linux with niri. It is less suitable for users who need a minimal, vendor-neutral setup or expect documented upgrades and formal releases.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly Shell, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 21, 2026, and from our analysis. They are not legal advice.

Editorial analysis

DotFriedRice's workstation scope and supported platforms

DotFriedRice is a Shell-based collection of configuration files and scripts for setting up a developer-oriented workstation. The project targets developers and power users who care about terminal tools, keyboard-driven workflows, and a consistent set of application configurations. Its stated goal is to reduce the time needed to turn a new or existing system into a usable command-line environment. The README estimates roughly five minutes for the setup, although that estimate is the project's own description rather than an independently measured result.

The command-line portion supports Arch Linux, Arch-based distributions such as CachyOS, Debian, Ubuntu, WSL 2, and macOS. WSL 2 support applies to supported Linux distributions, while the optional niri desktop environment is documented as an Arch Linux feature. This distinction matters because the repository combines a broad cross-platform tools layer with a more specific Linux desktop layer. A user can therefore adopt the shell and terminal configuration without accepting the complete niri workstation.

The included components include zsh, tmux, Neovim, SSH and GPG key generation, programming languages, and modern command-line tools. On Arch-based systems, the optional desktop path adds niri, Waybar, Walker, and related applications. The project is explicitly opinionated, but its configuration files and symlinks are meant to be editable before installation. That design makes it closer to a curated starter environment than a general-purpose installation library.

How DotFriedRice organizes installation and customization

The repository uses a file-oriented layout. Configuration data is stored under `.config/`, with additional user files under `.local/`. Installation-related files are under `_install/`, including `_install/default/`, which the README identifies as the source of truth for packages, standalone scripts, programming languages, and related files. Themes are kept separately under `_themes/`, while wallpapers are under `_wallpapers/`. This separation means that the installation input, desktop configuration, and visual customization are not merged into one opaque script.

The documented setup process uses an automated script that checks system compatibility and installs or configures the selected components. The README says that the user chooses where to clone DotFriedRice and can review or edit what will be installed. That review step is significant for an opinionated system setup, because package selection and symlink destinations affect the existing workstation. The repository also contains `bootstrap`, `dotfriedrice`, `run`, and `dotfriedrice-config.example`, but the README excerpt does not provide their complete invocation details.

DotFriedRice supports customization without requiring a fork as its stated design goal. Users can change packages, configs, and symlinks, and can add themes or theme additional applications. The approach favors a coherent local set of files over remote dependency management. It also means that adoption is partly an editorial decision: the exact behavior depends on the files present in the selected checkout, not only on a versioned installer command.

DotFriedRice's command-line and niri desktop layers

The command-line layer is the common foundation. It configures zsh and tmux, configures Neovim, can create SSH and GPG keys when they are absent, and installs command-line tools and programming languages. The README specifically describes the project as TUI-focused on the desktop path, with applications selected for development and media creation. This is not a minimal shell setup. It is closer to a full personal workstation profile assembled as a repository.

The optional desktop layer is based on niri, a Wayland compositor. It adds Waybar for status information and Walker as an application launcher, with additional applications described as part of the desktop configuration. The project explains its choice of niri in terms of scrolling, tiling, and floating window handling, multi-monitor integration, keyboard focus, mouse and trackpad support, resource efficiency, and documentation. Those are the project's stated reasons for choosing niri; the README does not provide a comparable performance measurement.

The desktop path is intended for users who want a complete graphical workstation rather than only terminal configuration. It also creates a larger upgrade surface because changes can involve the compositor, bar, launcher, themes, wallpapers, and desktop applications together. A terminal-only adoption avoids that desktop-specific portion, while still inheriting the package and configuration choices in the common installer.

DotFriedRice themes and first configuration steps

DotFriedRice includes theme switching for GTK applications, many terminal applications, and supported desktop components. The README documents two themes, Tokyonight Moon and Gruvbox Dark Medium. The command below lists available themes and, when a name is supplied, sets the requested theme. The command supports an interactive preview in the desktop environment through `--menu`.

sh
# Get a full list of themes by running: dfr-theme-set --list
# There's also a --menu flag to preview themes in the desktop environment.
#
# Optionally you can skip adding a theme name and the next theme will be picked.
dfr-theme-set THEME_NAME

The README states that GTK applications update live when the theme changes and that most terminal applications do as well. Existing tmux shells may need the documented `SZ` alias to source the new theme-related configuration. The alias is presented as a workflow convenience, not as a general replacement for restarting applications.

For the desktop path, wallpaper selection is handled separately:

sh
# Get a full list of wallpapers by running: dfr-theme-set-bg --list
# There's also a --menu flag to preview wallpapers.
#
# Optionally you can skip adding a wallpaper name and the next wallpaper will be picked.
dfr-theme-set-bg WALLPAPER_NAME

The README says wallpapers can be cycled among those compatible with the active theme. Compatibility is controlled by the `_theme.json` file in each theme directory, under the `wallpaper.synergy` object. This gives the setup a defined relationship between visual themes and available wallpapers, although custom themes still require adding the relevant configuration.

What DotFriedRice does not document

DotFriedRice's strongest documentation topic is setup scope and customization. Its upgrade path is less clear. The repository has no GitHub releases, so there is no release-based upgrade procedure visible in the repository information. The README does not document rollback, migration from an older checkout, conflict handling when dotfiles already exist, or a supported way to remove every installed package and symlink.

That absence is not proof that rollback or removal is impossible. It does mean an adopter cannot rely on a documented lifecycle command without inspecting `_install/` and the scripts directly. This is especially relevant for SSH and GPG keys, because the project can create them when they do not already exist. The README does not state whether rerunning the installer detects changed keys, overwrites files, or prompts before replacing existing user configuration.

The project is also opinionated about applications and workflow. Users who want a small shell, a different desktop environment, or a carefully controlled package list may find that the default profile includes too many choices. The README presents customization and mix-and-match configuration as supported directions, but it does not quantify how much work is required to remove defaults cleanly. Inspect the source of truth under `_install/default/` before treating the setup as safely repeatable on an important machine.

DotFriedRice maintenance, licensing, and adoption trade-offs

The repository is not archived, and the last push was on 2026-09-25. That date indicates recent repository activity at the time of evaluation, but DotFriedRice has no GitHub releases. Users therefore cannot infer a formal release cadence or a versioned upgrade contract from the release history available here. The README's statement that the repository will keep the demo setup up to date describes the author's intention, not a published compatibility policy.

The project uses the MIT license. That is relevant for organizations reviewing code reuse and redistribution, but the repository's license should still be reviewed directly before incorporating its scripts or configuration into a product or internal distribution. The license does not answer operational questions such as whether every package has compatible terms or how an existing workstation should be migrated.

Compared with assembling individual shell, editor, tmux, SSH, and desktop configuration files manually, DotFriedRice offers a faster starting point and a coherent set of choices. Compared with a minimal installer, it has more opinions and a broader maintenance surface. The main trade-off is therefore adoption speed against control and review effort. The first useful verification is to inspect the install inputs and scripts, then choose the command-line layer alone or the niri layer according to the target system.

Editorial conclusion

DotFriedRice is a reasonable choice for a developer or power user who wants a fast, opinionated starting point, especially on Arch Linux with niri. It is less suitable for users who need a minimal, vendor-neutral setup or expect documented upgrades and formal releases. Review `_install/default/`, inspect the scripts, and confirm the target platform and desktop requirements before running the installer. The repository's last push was on 2026-09-25, and it has no GitHub releases.

Frequently asked questions

Which operating systems does DotFriedRice support?

DotFriedRice supports Arch Linux, Arch-based distributions, Debian, Ubuntu, WSL 2, and macOS for its command-line tools. The optional niri desktop environment is documented for Arch Linux and Arch-based distributions.

Can I customize DotFriedRice without forking the repository?

Yes. The README says packages, configs, and symlinks are configurable, and it presents customization as a way to avoid maintaining a fork. Users can also add custom themes and theme additional applications.

How do I list or change DotFriedRice themes?

The README documents `dfr-theme-set --list`, `dfr-theme-set THEME_NAME`, and the `--menu` flag for previewing themes. Wallpapers use the corresponding `dfr-theme-set-bg` command, with compatibility managed by each theme's `_theme.json` file.

Official sources

  1. Issues
  2. License: MIT
  3. nickjj/dotfriedrice on GitHub
  4. Project website
  5. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/nickjj-dotfriedrice.svg)](https://hysenlabs.com/projects/nickjj-dotfriedrice)

Was this useful?