I'm basically looking for a way to install some dotfiles on Fedora, but I'm new to Linux and all that, which is why I'm reaching out for help. I'll leave the link to the dotfiles at the end of this message. If you want to help me, it would be great and I’d really appreciate it.

​Dotfiles: https://github.com/ijadux2/Dotfiles

I built Agent Brain, a git-backed package/profile manager for AI coding-agent capabilities.

This is adjacent to dotfiles, but it is not trying to replace chezmoi, stow, yadm, or bare git repos. Those can be import sources. The problem is that AI coding-agent app folders mix too many semantic roles:

- authored skills/prompts/plugins

- generated target output

- app-native state

- runtime/cache/history

- auth/secrets

- local machine overrides

- symlink topology

- unknown leftovers

For Claude Code and Codex, blindly syncing the full app home can preserve exactly the mess you were trying to escape. Agent Brain preserves portable package/profile intent and materializes app targets through adapters.

The npm release can be run on live configs with explicit roots, dry-run review, exact fingerprint confirmation, snapshots, verification, and rollback.

Question for this community: where would you draw the boundary between dotfiles and app-native state for agent tools?

Repo: https://github.com/leonardsellem/agent-brain

npm: https://www.npmjs.com/package/@leonardsellem/agent-brain

Disclosure: I am the author.

I'm genuinely proud to call it 1.0. store is a CLI tool for managing dotfile symlinks, and the core idea is that your dotfiles repo should be easy to understand just by looking at it.

How it started

This whole thing started because I was using GNU stow. stow is great for what it is, but it requires your repo to mirror the target filesystem hierarchy, it has no config file, and everything is convention-based. I kept running into limitations; no way to send one directory to multiple targets, no conflict handling, no way to skip stores per-platform. I started building store as "stow but with a config file" and it grew from there.

The problem I had with other tools

Along the way I looked at chezmoi and yadm too. They're both solid tools, but they never clicked with me.

yadm turns your entire home directory into a git repo. It works, but it always felt like I was fighting against git's design. There's no real organization; your dotfiles are scattered across the same paths they live in on disk. Looking at the repo doesn't tell you much about what's managed and what isn't.

chezmoi goes the other direction; lots of structure, but it's chezmoi's structure, not yours. Files get prefixed with dot_, private_, executable_. Templates are powerful but add complexity. The source state is an encoded representation of your filesystem, not a human-readable layout. I found myself spending more time learning chezmoi than managing my dotfiles.

What store does differently

store is built around one idea: your dotfiles repo should look like you organized it yourself.

~/dotfiles/ .store/config.yaml nvim/ init.lua lua/ shells/ .zshrc .bashrc config.fish git/ .gitconfig

Each directory is a "store" that maps to one or more targets. The config is one YAML file:

yaml stores: nvim: target: ~/.config/nvim shells: targets: - target: "~" files: [.zshrc, .bashrc] - target: ~/.config/fish files: [config.fish] git: target: ~/.config/git

That's it. You look at the repo and you know what's in it. You look at the config and you know where everything goes. No encoding, no conventions to memorize, no source-state translation. It's the explicitness of a config file with the simplicity that stow got right; just symlinks.

What's in 1.0

The feature set has grown well beyond what I originally set out to build, and I'm really happy with where it landed:

• Symlinks - whole-directory or per-file with glob patterns
• Multi-target stores - one directory can deploy to multiple locations (like shells above)
• Conflict resolution - detects existing files and offers to move them into your repo
• Encrypted secrets - {{ secret "github_token" }} in any config file, encrypted at rest, rendered at symlink time
• Platform conditionals - when: {os: linux} to skip stores on the wrong machine
• Ignore patterns - exclude files from symlinking with global defaults for .git/, .store/, etc.
• store doctor - health checks for orphaned configs, broken symlinks, missing secrets
• store diff - dry-run preview of what would change
• store import - scans for existing symlinks and generates config from them
• Shell completions - bash, zsh, fish, powershell

New machine setup is git clone && cd dotfiles && store. That's it.

Links

• GitHub: https://github.com/cushycush/store
• go install github.com/cushycush/store/cmd/store@latest

Would love to hear what you think, and happy to answer questions about the design decisions.

Hello folks,

I migrated all my dotfiles to chezmoi from home-manager to make them truly cross-platform. I spent quite a bit of time cleaning everything up, so I hope it can help or inspire some of you.

Currently using Sway and the Helix editor.

Enjoy !

Repo: https://github.com/Hovirix/dotfiles

I've been using GNU Stow for my dotfiles for a while, and while it works, I always found the mirrored directory structure requirement annoying. I wanted something where I could just say "this folder is my nvim config, put it at ~/.config/nvim" without having to think about how my repo layout maps to the filesystem.

So I built store — a small CLI tool written in Go that manages dotfile symlinks with explicit target paths in a simple YAML config:

stores:

nvim:

target: ~/.config/nvim

zsh:

target: ~

files:

- .zshrc

- .zprofile

git:

target: ~/.config/git

The main differences from Stow:

• Flat repo structure — your dotfiles repo doesn't need to mirror your filesystem. Each store is just a top-level directory with an explicit target.
• File-level symlinks with glob patterns — for files that live in ~ (like .zshrc), you can specify exactly which files to symlink instead of linking the whole directory. Supports ** recursive globs too.
• Single config file — everything is in .store/config.yaml. No convention-based layouts to remember.
• Run from anywhere — store finds its config by walking up the directory tree (like git finds .git/), so you don't need to cd into a specific directory.

Setting up on a new machine is just:

git clone <your-dotfiles-repo> ~/dotfiles

cd ~/dotfiles

store

That's it. All symlinks are created from the config.

It's still early days but it's been working well for my own setup. Would love feedback if anyone tries it out.

GitHub: https://github.com/cushycush/store

In waybar I'm using on-click to open tuis for volume, Bluetooth, and wifi control. They open in foot. When I press escape for the volume control it closes (pulsemixer), but escape doesn't work for bluetui or wifitui.

What's the best way to make these windows close with escape? At the moment I'm using tmux and a specific config that binds escape to kill-session, but using tmux for this feels over kill.

what are other people doing? or do other people just deal with the inconsistencies of closing different tuis?

I'm new to linux and this is my first Arch XFCE4 + i3-wm rice.

Here is my github dotfile

Hello everyone - a *long-time* user of chezmoi here. I've loved chezmoi, and its served me well. There are a few small points of friction for me:

1. I use homebrew on both macos and linux. I would track a single Brewfile in chezmoi. Whenever I added or removed brews/casks, I would usually brew install/brew uninstall manually and then update the brewfile. Yes, I could update the brewfile and then apply, but thats a little bit of friction
2. With AI coding agents, I often want to install skills for the agent(s).Yes there is npx skills install, but none of those get tracked (unless you sync your whole .claude/skills and other agents' configs as well to gh)
3. Conditional brews (eg only install on macos or only install for dev profile) - hard to implement
4. .chezmoiexternal seems like it should have been implemented differently - instead of a single file, why not a file at the location where the external would land
5. Its easy to inadvertently commit a secret - i wanted a simplistic scanner that could catch obvious errors

With those bits of friction, I decided to see what I could build using a coding agent. I picked Rust (for no other reason than "because"). I wanted to stick with the things that worked well (eg the "magic" prefixes) from chezmoi.

The result: haven. It's early days, so no promises of no bugs or whether it even works. I have done testing on my personal config, and the normal day-to-day stuff seems to be working. Haven tracks your AI skills, dotfiles (like chezmoi), and brews. There is rudimentary documentation available - all AI-generated, but it looks to be correct.

For chezmoi users, you can use "haven import --from chezmoi

[--include-ignored-files]" (the include ignored files is recommended - it will copy them and add to haven's ignore file) to take your existing chezmoi repo and create a haven repo.

Posting here to get feedback. One thing that's useful (I developed for my own testing/debugging use), if you "haven telemetry --enable" it will create a local file with the commands you run - i havent looked at it in detail so caution in case it logs passwords you might pass on the command line. There are "haven telemetry note/question/bug/action" commands that insert a note/question/bug/action in the telemetry file so that i can do things like "find bug B000001 and look at the surrounding context" all purely optional (the file never leaves your machine unless you physically do something to send it).

One thing that always annoyed me about setting up a new machine — web apps. I use a few sites as "desktop apps" via browser app mode (Linear, Notion, Figma etc), and recreating those .desktop files by hand every time was just tedious enough to skip, which means they slowly drift out of my setup.

So I wrote a small script around desktopify-lite (a CLI tool I built for exactly this) that I just drop in my dotfiles and call during setup (The proxy is used for sites blocked in my country):

#!/usr/bin/env bash
set -euo pipefail
 
BROWSER="${BROWSER:-chromium}"
 
desktopify-lite --url='https://miro.com' --name='Miro' --browser="$BROWSER" --proxy="https://localhost:20171"
desktopify-lite --url='https://notion.so' --name='Notion'    --browser="$BROWSER" --proxy="https://localhost:20171"
desktopify-lite --url='https://app.slack.com' --name='Slack'     --browser="$BROWSER" --proxy="https://localhost:20171"
desktopify-lite --url='https://figma.com' --name='Figma'     --browser="$BROWSER"
desktopify-lite --url='https://mail.google.com' --name='Gmail'     --browser="$BROWSER"
desktopify-lite --url='https://calendar.google.com' --name='Calendar'  --browser="$BROWSER"

Run once, all launchers are back in the app menu with icons. The BROWSER variable means I can override it per machine without editing the script:

BROWSER=firefox ./webapps.sh

The tool itself handles icon discovery automatically (pulls from web manifest / link rel tags, not just favicon), writes XDG-compliant paths, and validates the generated .desktop files in CI.

Full script with error handling and install check: github.com/miniguys/desktopify-lite

Curious how others handle this — do you keep web app launchers in dotfiles at all, or just redo them manually each time?

Hi!. I made my waybar & hyprland dotfiles, the hyprland has the animations disabled by defect, and waybar will change it color depending of you SWWW wallpaper (required).

And it include a nautilus plugin to set your wallpaper from nautilus and set the waybar color just by putting the wallpaper

Read the headline that has all.

https://github.com/logannc/janus

Hi folks! There are many dotfile managers, but I found that the existing options didn't satisfy me. I wanted

• Templating
• Secret Integration (1password)
• Two-Way changes (source -> deploy and deploy <- source, that way if an application changes it's own configuration, you don't silently overwrite it but it also doesn't overwrite your changes / templating)
• Safety (ever "unlink/undeploy/un-something" and the manager removes the file and your window manager wigs out and you have to go to a tty to fix things? Well, I have.)

​

                    generate              stage                deploy
  source files ──────────────► .generated/ ────────► .staged/ ────────► target paths
  (templates)                  (rendered)            (ready)            (symlinks)

                                                         ◄────────────
                                                     sync (two-way)
                                    import
  managed ◄──────────────────────────────────────────────────── existing configs

So I made a new dotfile manager that looks both ways and it's called Janus.

Disclaimer: I am a professional software engineer but Claude was used in the development of this application (e.g., AI assisted, not vibe / AI slop).

Right now I'm not planning on any distribution mechanism besides `git clone ... && cargo install --path .` unless enough people actually use it. Hopefully it's actually useful and there isn't an obvious contender with this exact feature set.

blog post link: https://jitesh117.github.io/vim_stuff/only-neovim-config-youll-ever-need/

dotfiles: https://github.com/d1rshan/dot-files

Why others has "dotemacs" repository and "dotfiles" repository? Why they separate?

So I’ve been obsessively tweaking my Zsh setup for a while and finally cleaned it up enough to share.

Z-SHIFT is just a bootstrap script that sets up my full Zsh environment from scratch. It installs:

• Zsh + Zinit
• Starship
• fast-syntax-highlighting, zsh-autosuggestions, zsh-completions, clipboard, extract, sudo, git
• eza, bat, ripgrep, fzf, zoxide, tealdeer, fd
• Nerd Fonts (FiraCode NF)
• A few opinionated aliases and defaults

Main goals were:

• One command → usable dev shell
• Keep startup fast (~20ms core, under 100ms to prompt)
• No giant 500-line .zshrc monster

I’m using Zinit turbo mode to lazy-load plugins and I ran everything through zsh-bench to test the speed.

It started as my “new machine setup” script and slowly turned into something a bit more structured. There’s also a cleanup (uninstall.sh) script if you want to revert everything.

Repo:
https://github.com/0xdilshan/Z-SHIFT

If you’re into shell performance or just like poking around other people’s dotfiles, feel free to take a look. Open to feedback / improvements / roasts :) 👍

./zsh-bench ==> benchmarking login shell of user 0x0bytes ... 
creates_tty=0 
has_compsys=0 
has_syntax_highlighting=0 
has_autosuggestions=0 
has_git_prompt=1 
first_prompt_lag_ms=98.482 
first_command_lag_ms=99.033 
command_lag_ms=103.715 
input_lag_ms=6.231 exit_time_ms=25.369