DotFriedRice Review: Nick Janetakis' 1,300-Star Dotfiles Repo Is Doing Something Most Don't
I'll be honest: when I first heard about another dotfiles repo, my eyes glazed over. We've all seen the "ultimate dotfiles" repo at least once a month on r/unixporn. Most of them are someone's personal config dumped onto GitHub with a bootstrap.sh that works for exactly one person's machine and one person's taste.
Then I looked at nickjj/dotfriedrice more carefully. 1,321 stars. 201 forks. Trending. Active development in August 2026 (yes, the last push was this month). And it's not just a dotfiles repo — it's a curated, opinionated, yet customizable system bootstrap that works across Arch, Debian, Ubuntu, WSL 2, and macOS.
I spent a few days with it. Here's what I think.
What it actually is
DotFriedRice isn't a dotfiles repo in the traditional sense. It's a meta-system: a set of shell scripts that will, in a single command and roughly five minutes, set up your machine with a coherent set of CLI tools, programming language runtimes, and — if you want — a full niri-based Wayland desktop environment on Arch.
The key insight here is the "source of truth" architecture. Everything is declared in _install/default/ as plain text files. Packages, scripts, language toolchains, config symlinks — all there in files you can read and edit before the installer runs. The installer reads those files, asks for confirmation, and provisions the system.
The branding is cute (fried rice as a metaphor for mixing and matching), but underneath that is a real engineering decision: you shouldn't have to fork this repo to make it yours. Instead, you configure it. The "fried rice" metaphor is doing actual work — it's saying "pick the ingredients you want, skip the ones you don't."
Why this matters right now
There are three trends colliding that make this repo interesting in 2026.
1. Niri is having a moment. niri, the scrolling Wayland compositor, has gone from niche curiosity to genuinely solid daily-driver material. The maintainer (someone who clearly knows what they're doing) has been shipping rapidly, and the docs are excellent. If you've been on the fence about trying a tiling compositor and Hyprland felt too unstable or too animation-heavy, niri is the answer right now. Nick made a strong call betting on it for this project, and it paid off.
2. The Linux desktop is getting weirdly good. Between niri, Wayland maturing, COSMIC on the horizon, and distros like CachyOS gaining traction, the "I use Arch btw" crowd finally has real choices beyond "do I want GNOME or KDE today." A repo that ships a complete, coherent desktop experience with a focus on TUI apps over GUI apps is timely.
3. Dev environments are too damn complicated. The average senior dev's machine is a mess of half-installed language version managers, orphaned dotfiles from a previous employer's onboarding, and a ~/.config directory that's accumulated like sediment. A repo that says "here's a working baseline, edit the manifest before you run it" addresses a real pain.
The "peaking" trend status isn't a fluke. This is the right idea at the right time.
Key features worth your time
I'm not going to list everything — the README does that — but here are the things that stood out to me as a developer evaluating whether to adopt this.
1. Pre-flight configurability
The install flow doesn't just dump stuff on your machine. It lets you review and edit the package list, the scripts, and the symlinks before anything happens. For a dotfiles repo, this is huge. Most repos either work with their exact config or you fork. DotFriedRice has explicit, documented ways to customize without forking. There's a dfr-configure workflow that lets you tweak things at runtime too.
If you've ever hesitated to run a stranger's install.sh because you didn't know what it would do, this is the answer. You read the files, you edit what you don't want, then you run the installer.
2. The CLI tool selection is genuinely good
The package list isn't just "install all of brew" or "here's my personal favorites." It's a curated set: modern alternatives (eza, bat, ripgrep, fd, fzf, zoxide), solid dev tools (lazygit, delta, btm), and the right defaults for zsh and tmux. The author clearly uses these tools daily — this isn't a list assembled by scraping awesome lists.
The Neovim config is similarly opinionated but practical. Not a from-scratch distro, not a 2,000-line LSP config you'll never debug — a working setup that gets out of your way.
3. Cross-platform without the usual mess
Supporting Arch, Debian, Ubuntu, WSL 2, CachyOS, and macOS from a single shell script is genuinely hard. The recent commit log shows the pain: "Use more OS_DISTRO_LIKE references for CachyOS," "Fix OS_DISTRO reference for CachyOS" — these are the real-world edge cases that kill most cross-platform installer scripts. The fact that CachyOS support is actively being debugged tells me this isn't a "supports my exact machine" situation.
WSL 2 support is the killer feature for me, honestly. Most dotfiles repos pretend WSL doesn't exist. This one treats it as a first-class target.
4. The theming system
dfr-theme-set THEME_NAME will swap themes across all the configured apps — Neovim, GTK apps, terminals — and they live-update. There's a --menu flag for previewing in the desktop environment. The included themes (Tokyonight Moon, Gruvbox Dark Medium) are well-chosen, and the JSON-based theme metadata makes adding your own trivial.
Wallpapers have synergy metadata too, so a theme and its compatible wallpapers stay matched. Small detail, but it shows the author thought about the actual UX of switching.
5. The desktop environment isn't an afterthought
When you opt into the niri desktop mode, you get a real, cohesive setup: niri itself, Waybar, Walker (the app launcher), theming, wallpapers, hotkeys, trackpad support, and a clear preference for TUI apps over GUI. The README is upfront that this only works on Arch-based distros — it doesn't pretend Wayland compositors are interchangeable.
The "Why niri and not XYZ?" section is worth reading. The author isn't religious about it, just honest about what made niri the right choice for them after 25 years of using computers.
Who should use this
Yes, use it if: - You're setting up a new Arch machine (or CachyOS) and want a sensible starting point without hand-picking every package. - You've been wanting to try niri but didn't want to assemble the whole stack yourself. - You work in WSL 2 and want a Linux-style terminal environment that actually feels coherent. - You prefer TUI apps over GUI apps for as much as possible (this is a stated philosophy, not an accident). - You're tired of maintaining your own dotfiles and want to maintain a config layer on top of someone else's sensible defaults.
Skip it if: - You're already deeply invested in Hyprland, Sway, or another compositor. This isn't a swappable component. - You want a fully GNOME or KDE experience. This is anti-that. - You don't trust running installation scripts from the internet — and I respect that. Even though you can pre-review, the script runs as root on Arch during install. - You need a fully declarative NixOS-style system. This is shell scripts and config files, not a Nix flake. - You want bleeding-edge everything. This is curated and tested, not a "track every git HEAD" situation.
Honest concerns and limitations
I don't do puff pieces. Here are my real concerns after spending time with this.
It's still fundamentally a personal config. Even with the customization layer, the opinionated choices (zsh over fish, Neovim over Helix, niri over Hyprland) are baked in. The README is honest about this. But "you can customize it" and "it'll be exactly what you want" are different things. If your taste differs significantly, you'll be fighting the defaults.
The desktop only works on Arch. Debian, Ubuntu, macOS, and WSL 2 users get the CLI setup only. If you wanted a turnkey desktop experience on Ubuntu, this won't do it. The README is clear about this constraint, but it does mean the most interesting part of the repo isn't available to most users.
The single-author risk. Nick Janetakis has 1,166 of the 1,200+ commits. That's amazing dedication, but it also means if he stops maintaining it, the project could stagnate. The 8 commits from the next contributor are a thin base for a bus-factor concern. That said, the recent activity is strong (August 2026 push) and the architecture is straightforward enough that a fork wouldn't be a disaster.
No releases. The repo uses commits as the source of truth, not tagged releases. If you want to pin a known-good version, you're reading commit logs. For a personal dotfiles repo that's fine; for a tool you might deploy across a team, I'd want releases.
The pyproject.toml is just for ruff config. The project is shell, not Python, and the pyproject.toml is essentially a linting config for any Python that might appear. Not a concern, just a minor thing I noticed — don't expect a Python project here.
One open issue. That's actually a good sign, but it also means whatever issue is there hasn't been addressed. The recent commits suggest it's something minor (maybe the ipapi.co account requirement mentioned in the most recent commit log).
The verdict
Here's my honest take: if you're the target user — an Arch-based Linux developer who wants a coherent, well-curated, themable, TUI-leaning desktop and CLI environment set up in five minutes — this is the best dotfiles-style repo I've seen. Not "one of the best." The best, for that specific use case.
The customization-before-install workflow addresses my biggest objection to running someone else's dotfiles. The niri integration is real, not a thin shim. The cross-platform support is maintained, not abandoned. And the recent commit cadence shows this isn't a "I got it working once and stopped" project.
For everyone else — it's worth studying the architecture even if you don't run it. The pattern of "declarative defaults + pre-install review + minimal post-install config" is something I'd copy into my own projects. The _install/default/ directory is a small, well-designed piece of engineering.
Adopt it if it fits. Read it either way.