makccr dotfiles: one author's Arch-first desktop configuration

Arch first, with everything else held at arm's length

The author is explicit about the platform this configuration targets. Arch is the primary system, with Manjaro and Cachy OS named as flavours of it that are used when the author feels lazy. Ubuntu LTS and Fedora Workstation are run from time to time and the configurations are kept working there as well. FreeBSD is described as a daily drive for brief periods, with the clear admission that no real effort goes into making the configs work there.

The stated use case is writing, some light web design, and the general scripting that comes with window managers and lightweight systems. The conclusion drawn from that is a design preference: things are kept minimal and performant.

Two platforms sit outside that seriousness. There are OSX and Windows specific configs in the repository, and the note about them is blunt: they only get updated on the rare occasion the author uses them and finds an issue needing a fix. So the repository is not uniformly maintained, and the maintenance level differs sharply by platform.

For a reader, that distribution tells you where to look. The Hyprland, Neovim, Zsh and Alacritty configuration is the living part of this repository. The Windows and OSX directories are archaeological layers that may or may not work today, and the README is honest about that.

The repository was last pushed to on 2026-10-05, and it carries no releases, so there is no version to pin and no changelog. The homepage is makc.co.

What is actually in the tree

The top level listing is short and tells you how the configuration is organised. There are loose files at the root, including .Xresources, .gitconfig, .tmux.conf, .xbindkeysrc and .zshenv. Then there are four directories: .config for the per-application configuration, .scripts for helper scripts, images for the screenshots used in the README, misc for odds and ends, and suckless.

The suckless directory is the interesting one. It refers to the suckless.org projects, the minimal window manager and tool set associated with dwm, and its presence at the top level rather than buried inside .config shows that these configurations are a significant part of the setup rather than a leftover.

The .config directory is where the modern half of the setup lives. The topic list of the repository names the software involved: alacritty, bspwm, dmenu, dwm, hyprland, neovim, polybar, ranger, st, tmux, vifm, vim, waybar, wayland, x11 and zsh. That list is a directory listing in prose, and it covers the whole desktop: terminal emulator, window manager, status bar, launcher, shell, editor, multiplexer and file managers.

Two entries are worth calling out because they are alternatives rather than parts of one stack. ranger and vifm are both terminal file managers, and tmux is present alongside a Wayland-oriented setup where tmux is not strictly required. The repository keeps more than one answer to each question, which is a deliberate consequence of the long history the topic list implies.

The five things the author actually maintains

The README lists the main contents, and the list is more informative than a directory tree because it names what is current.

First, the Neovim configuration, which is listed first and is the largest single piece of work by implication. Second, the Zsh configuration. Third, the window manager setup, described as primarily Hyprland these days, with the note that BSPWM, DWM and Awesome WM were used extensively in the past and those configurations are also contained in the repository. Fourth, the Alacritty configuration, along with what the author calls a few backup terminals, which is where the st entry in the topic list fits. Fifth, the status bar configuration.

The status bar entry explains a migration. With the switch to Wayland, the status bar of choice became Waybar, but an extensive amount of Polybar configuration is also present in the files.

Two things follow from this structure. The first is that there is no single blessed configuration here. If you are a Hyprland user, the working setup is Hyprland, Waybar, Wayland, Alacritty, Neovim and Zsh. Everything else in the tree is history, kept because it was once how the author worked and because rewriting from scratch is harder than maintaining an old directory.

The second is that the author has migrated more than once, and each migration left a working configuration behind. That is the pattern to look for when reading any single file here: ask whether it belongs to the current stack before you copy it.

Installation is symbolic links, and the clone URL points elsewhere

The usage section describes a manual process: clone into the ~/Documents folder or another convenient location, then use symbolic links to put things where they belong.

The first step is to move into the target directory:

cd ~/Documents

The clone step uses a codeberg.org address, not a GitHub one, even though the copy you are reading sits on GitHub:

git clone --depth 1 https://codeberg.org/makccr/dot

The shallow clone is worth keeping, since the repository has no releases and you are only interested in the current state of the tree.

After cloning you move back to your home directory, and then create the links:

cd 

ln -sf ~/Documents/dot/.config .
ln -sf ~/Documents/dot/.scripts .
ln -sf ~/Documents/dot/.gitconfig .
ln -sf ~/Documents/dot/.zshenv .
ln -sf ~/Documents/dot/.tmux.conf .
ln -sf ~/Documents/dot/.Xresources .
ln -sf ~/Documents/dot/.xbindkeysrc .

Seven links, all pointing into your home directory. The -f flag means an existing file at the destination is replaced, which is the part that deserves attention: if you already have a .gitconfig or a .tmux.conf, this silently replaces it with a symlink into the cloned tree.

The author notes that a script automates this, setup.sh in the .scripts folder, and states that it makes the symbolic link process take about 0.36 seconds. The invocation given is:

./~/Documents/.scripts/setup.sh

Note that the path in that command points at ~/Documents/.scripts rather than ~/Documents/dot/.scripts, which means it expects the links to have already been created, or a different layout. That inconsistency is a small signal about how much the automated path is exercised.

What makes these dotfiles worth reading and what makes them awkward

The value of a personal dotfiles repository is that it shows working configurations for software you have not set up before. Reading a Neovim setup written by someone who uses it daily teaches you plugin choices and key bindings in a way that a wiki page does not, and the same goes for a Hyprland layout with a status bar wired to real apps.

What you cannot get is support. This is one person's setup, tuned for one person's hardware, screen sizes, habits and workflow. There is no issue tracker policy, no compatibility matrix, and no indication of how much of the OSX and Windows configuration still runs.

The licensing position is also unresolved from what is available. The repository licence is listed as something GitHub cannot classify, and there is no licence file among the top level entries, which means the terms for copying and redistributing this configuration are not stated in a way you can rely on. If your organisation requires an approved licence for anything you adopt, this repository does not give you one, and that applies to the individual configuration files inside it as much as to the README.

There is also the single user factor. Everything here assumes one account, one home directory and one machine layout. A multi user system, or a shared workstation, is outside what the seven symbolic links support, and you would be building something else on top of these files rather than installing them.

Used as reference rather than as an installer, none of that matters much. Read the config for the piece of software you are setting up, take the ideas, and write your own file.

Editorial conclusion

Adopt these dotfiles as a reference for how a minimal Wayland desktop is wired together, particularly if you already live in an Arch derivative and use Neovim, Zsh and Hyprland. Do not expect a supported installer, because the setup is a list of symbolic links that replaces files in your home directory, and the licence is not stated in the repository. Before you run the setup script, read every line it creates and back up the seven paths it links, since ln -sf overwrites them, and remember that the clone command in the README points at a codeberg.org address rather than the GitHub copy you are reading.

Frequently asked questions

Official sources

1. Issues
2. makccr/dot on GitHub
3. Project website
4. README