Now I am on Void Linux though, and even if I have access to the latest and greatest software. I decided to return for dwm for a while. Maybe permanently?

I managed to patch everything I ever wanted. Even if I had to do quite a bit of manual work. What I did was use the patching guide by uoou, which used git branches for every patch you apply, and, in my case as suggested by a comment. A “build” branch where I merge all the branches into one, which leads to less errors? Maybe its a placebo, but its quite easy to do.

Patches applied

In the post I mentioned before, I had already mentioned some of my reasoning behind the patches I’ve used. Here I’ll just list them again in case you are too lazy to check that other post. They can be found in dwm’s website.

• alwayscenter
• attachbottom
• autostart
• functionalgapps(+pertag)
• movestack
• shift-tools
• systray

Other changes

For my bar, I went with the default and used aslstatus. Its pretty good! I am using the same configuration I shared in my previous post. Pretty much exactly, even though some more features were added to the tool that you may wanna check out.

Picom, the compositor I use, makes window borders transparent. A couple of lines fix it pretty nicely.

Right now I am still using some systray stuff, like volumeicon, which kinda duplicates the volume info. I will fix it one of these days…

Regardless, here’s how its looking!

Final words

In the end I am quite happy with my current setup. Everything works just fine. I had heard that the systray patch was hard to apply. I don’t know if its the relatively recent patch for dwm 6.4 or if its just that the patching method I mentioned is better. All I did was create a branch with every c+patch applied, then a branch specifically for the systray patch, and I merged them both, there were no errors at all. Thankfully I doubt I’ll add any more patches anytime soon. This is great as it is.

You can find my configuration here. Just build it and it will be good to go.

This is day 13 of #100DaysToOffload

Because of this, I decided to just stay in XFCE, the Mint edition I got, for a while, until I figured something out. I could build spectrwm from source, but there is no official guide and, while I think its probably super easy, I figured that if I was going to build a WM from source, it would be dwm.

While I don’t really dislike XFCE, I really wanted to go back to tiling, some things just didn’t work as I wanted them to, and some programs didn’t like to stay where I put them, or couldn’t be resized as easily, and XFCE just lets them be, even if I just want them to be smaller or something. During some free time I got, I decided it was finally time to set dwm up once and for all.

I have switched to dwm in the past, in fact I’ve even made a post about the setup I used back then, but I never wrote something for this blog about it. I guess it was about time.

My patch selection

The patches I’ve decided to use are quite pretty similar to what I would get with spectrwm default keybindings with a few additions. I think its a pretty simple and minimal set.

• attachbottom: This is a really simple patch that I really, really like, I discovered thanks to HexDSL, and I prefer it a lot from the default, since windows appear at the bottom of the stack and don’t move around the rest. Its pretty comfy and easy to apply.
• functionalgapps+pertag: I like this patch because it basically applies two in one. This makes it so each tag (or workspace) can have different modes, like, if you have a tag floating, you can have others in master and stack, or another tag maximized. Of course, I also really like gaps, even if they can be a bit useless sometimes, but I can resize them in real time and stuff like that, it makes my brain feel happy.
• movestack: This is a basic function that should be there by default, changing the position of a window in a stack is something I consider fairly important. Dwm only allows moving something from the stack to the master position, and a lot of people can only live with that, so you might now actually need this, but I do.
• alwayscenter: This makes it so if you have something configured as floating in the config file, it will be centered each time you open it. It does not center stuff you make float manually tho, which fits my needs
• movecenter: This lets me use a keybinding to center whatever window I have floating around, its pretty useful and complements the previous patch nicely.
• shift-tools: Another useful patch that lets me move around tags with something other than MODKEY+number, for example, drag a window an switch tags alongside it, and other nice features. This is a must for me, might as well be the most important patch, I guess I could live without the rest somehow, but I am just too used to this one, which is available in most tiling window managers by default.
• autostart: I decided to have an autostart patch due to some problems I had while using .xinitrc and some programs failing to run properly, but this patch lets me have more control and be completely sure that whatever I want to run will do just do it.

Notes

There is still one patch I have not added, but I used in my previous configuration, and that is status2d, because it lets me use custom colors, which is what I wanted to have in spectrwm in the first place, but I didn’t feel like adding it right now, since I am happy with my current bar.

I also was a bit interested in swallow, but I don’t really need it, I am used to other methods already and the situation where it could be useful isn’t really that common for me.

My bar

There are many ways to customize the bar, from xsetroot, to dwmblocks or slstatus, all of them are pretty good ways to make use of it. However, I went ahead and used aslstatus, which is basically the same as suckless’ original tool, but asynchronous, I can make my volume update in real time, while the weather info is only updated every 30 minutes or so. Its pretty good and I really like it, and it works with status2d and colors, whenever I get the time to set it up properly.

It’s what I used in the mastodon post I shared above, so it works great. Its also the reason I went with an autostart patch, since running it from .xinitrc was not reliable.

Finishing up

There isn’t really a lot else to say, I guess I could share the current config in my git repository. I will probably do it soon enough, there are still some things I want to change but I am pretty happy with how it looks now. I like the simplicity I went for. Sadly, LabVIEW, the program I installed yesterday, hates being told where to stay, so I’ll have to stick with XFCE during those classes.

You can see my configuration file for dwm here, but its nothing too special. My bar is also just using the defaults, and this is at the bottom:

static struct arg_t args[] = {

/* function		format		argument	interval (in ms) */

{ netspeed_rx,  "  %sB/s",     IFC,        2 _SEC, END },
{ netspeed_tx,  " -  %sB/s |", IFC,        2 _SEC, END },
{ disk_free,    " %s |",		"/",	    25 _SEC,END },
{ cpu_perc,	    "  %3s%% |",	NULL,		1 _SEC,	END },
{ vol_perc,		" %s |",	    NULL,		0,		END },
{ wifi_perc,	" 直 %3s%% |",	IFC,		2 _SEC,	END },
{ battery_perc,	"   %3s%% |",	"BAT0",		1 _MIN,	END },
{ datetime,		"  %s ",	    "%H:%M:%S",	1 _SEC,	END },

};

This has been day 95 of #100DaysToOffload

First, it was a school assignment, I would win some extra points and I was already willing to make the move. But also, I was pretty dumb and couldn’t figure out printing, as well as some graphical issues, where the screen would blink and glitch seemingly at random.

Endeavour OS is great

I really enjoyed my time using Endeavour, it was a really easy to use distribution that provided me with everything I needed out of the box. I was finally able to enjoy a pretty minimal, yet usable Arch configuration, I had everything working almost perfectly, and if something was going wrong it was usually just me being dumb and setting some config incorrectly.

I may go back to this distro in the future, or even finally give a change to pure Arch in my machine, since I found it all pretty smooth and it was always fun to have updates waiting for me almost everyday.

The problem

My main problem has nothing to do with Endeavour or Arch itself, its just an AUR package that required an old Python version, and prevented me from updating my system once Python got an update. There where some comments in the AUR website, but it seems like it can’t be easily fixed until the maintainer decides to step up.

Another slight problem was just the amount of stuff I felt was not needed by me. For example, Endeavour OS comes packaged with a lot of small terminal utilities that can do everything from changing wallpapers, checking for updates, making logs and such. All of these had small dependencies that were quite annoying, because I didn’t really use them. A lot of those packages depended on each other too, and it was difficult to get rid of them all.

But, being honest, I guess the main reason I left Endeavour was because I was no longer able to update it, which is kind of the whole point.

Letting go of my early tether

I have went with many distros for a while now. But something they all had in common was that all of them were dual-booted alongside Windows, and of course, all of them had broken bootloaders at least once in their lifetime, because of some random Windows update.

Funnily enough, as soon as I was done backing up my files and config files to a second hard drive, I rebooted to Windows to do the same to the files I had there. Then rebooted once more, for a second check on my Linux site, and voila, my bootloader was gone.

Frustrated, I decided to just go for it and plug my USB drive, change the boot order and install Void alone, once and for all.

Void everywhere

Have you ever heard of Guru Laghima?, he was a wise man, who wrote something I decided to apply here:

“New growth cannot exist without first the destruction of the old.”

I ran the void-install script, an ncurses screen showed up, I configured everything. It was finally the point of no return, the partitions had to be wiped and reset, I also finally made a new, separate /home partition, and wrote the changes.

Endeavour was gone, Windows was gone, and even some files I forgot to back up, were also, gone.

But you know what, that is completely fine, as Guru Laghima once said:

“Let go your earthly tether. Enter the void. Empty and become wind”

With nothing installed, I was finally born again, Void was even more beautiful than I remembered, there were a lot of new things and the packages available have grown quite a bit. There are still some problems here and there, but in the end, I know everything is going to be alright.

This has been day 64 of #100DaysToOffload

That works fine, but it’s not the best way to backup the constant changes I usually do to customize the way my programs look or act, and as a customization freak, that happens quite often.

I had seen many different ways to backup dotfiles: git bare repos, yadm, symlinking scripts, and of course, GNU Stow.

All of these methods have their up and downs, but in the end, stow convinced me, and I decided to give it a try. According to their home page:

GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place.

If you don’t really understand it yet, don’t worry, I don’t either! But in this blog, I will do my best to show you the steps to backup your current config files, I hope whoever reads this finds it useful.

Creating a dotfiles repository

The first step to backup your dotfiles, is to create an empty repository in some hosting service, such as GitHub, Codeberg or SourceHut. This is optional if you only want to see how stow works, but necessary to have an external backup outside your computer. Once you are done, clone the empty repo to your home directory, or in any place you want. (This tutorial will be using the home directory).

To clone a repo, just do:

git clone https://site.com/link/to/repo

In my case, I use Tildegit, a Gitea instance, so my command looks like this.

git clone https://tildegit.org/chrono/dotfiles.git

You can clone my dotfiles if you want to use them, here they are if you are interested.

Using stow to backup your configuration

Before actually backing something up, we need to install stow, depending on your distribution, you can install it with your package manager of choice. In my case, Endeavor is based on Arch, so I do:

$ sudo pacman -S stow

Lets start by backing up the configuration of a single program. While we can backup our whole .config folder, that’s not a good idea, since some programs store important information that should stay private, and I think its better to only backup what we have actually configured. For this example, I will backup my picom configurations.

The first step is to create a new directory to use as a base (if you cloned your empty repo, you’ll be using that). You also have to create a folder structure, depending on where you want the configuration to be stored, this depends on the location the program will read its configuration from. We’ll refer to this folder as dotfiles.

If you want to add a README file or other stuff that you is not a config files, you can create another directory inside of dotfiles, in my case, I have made a stow_home folder, which will be where we’ll run the stow command. ¹

Lets explain how stow works. Picom expects its config file in ~/.config/picom/picom.conf, so, inside of the new home_stow directory, we recreate that folder structure, but using the program name (picom) instead of the tilde (~), which usually refers to the home folder. ²

Lets put all of this together in the terminal.

mkdir dotfiles && cd dotfiles # mkdir only if you didn't clone it
touch README.md other_file.txt # optional
mkdir -p ~/dotfiles/stow_home/picom/.config/picom/
mv ~/.config/picom/ ~/dotfiles/stow_home/picom/.config/

Once you do that, your picom folder is no longer in the .config directory, but inside of dotfiles/home_stow, following the same folder structure, as if home_stow was the /home directory, followed by the user picom and the path to the picom configuration files. ³

Now we repeat this process with all of the files and directories we want to back up. Once done, the behavior of the programs you use, such as vim, should revert to their default configurations, since the user config files are no longer there. So, now its time to fix that! Inside of stow_home, run the following command:

stow -vt ~ *

This will symlink everything inside of stow_home ⁴, targetting ~ as the starting point. The -v flag will let you know of everything being done, so you should see an output like this, depending on the programs you backed up:

# $ stow -vt ~ *
LINK: .config/awesome => ../dotfiles/stow_home/awesome/.config/awesome
LINK: .config/bat => ../dotfiles/stow_home/bat/.config/bat
LINK: .config/dunst => ../dotfiles/stow_home/dunst/.config/dunst
LINK: .config/nvim => ../dotfiles/stow_home/nvim/.config/nvim
LINK: .config/picom => ../dotfiles/stow_home/picom/.config/picom
LINK: .config/rofi => ../dotfiles/stow_home/rofi/.config/rofi
LINK: .config/spectrwm => ../dotfiles/stow_home/spectrwm/.config/spectrwm

File versioning with git

If you stumbled upon this guide, you probably know the necesary git commands to backup everything to the service you chose at the beginning of this guide.

Generally, everytime you do changes you only need to follow these three commands, inside of your dotfiles folder.

git add *
git commit -m "Added config files"
git push

Remember that the last command will not work if you don’t have an external repository.

The manual of GNU Stow contains a lot more than what I mentioned here, like unlinking and other flags that can be used and might be useful for your use case.

Finishing up

Anyways, that’s all folks, this has been day 54 of #100DaysToOffload, you can check out my dotfiles if you want to see how stow looks once setup, besides, my Spectrwm configuration is quite sick if I do say so myself.

If you feel like a step is not clear enough, please let me know in the comments or via e-mail.

Secret bonus script!

So, if you read until the end of this blog. I actually did a pretty decent bash script to automate everything here.

All you need to do is configure it to your liking and run it like this

dotstow file_or_folder

The script is as follows, it uses basic tools like cut and of course, stow

#!/usr/bin/bash
# Dotstow - Backup your chosen dotfiles in one go using stow.
# Run it outside of the folder/file you want to back up
# $ dotstow file-or-program
# This program was made by joelchrono12

STOW_DIR=$HOME/dotfiles/stow_home
DIR=$(pwd | cut -d '/' -f4-)
NEW_DIR=$STOW_DIR/$1/$DIR
mkdir -pv $NEW_DIR
mv -v $1 $NEW_DIR
cd $STOW_DIR
stow -vt ~ $1

The program does not check if a folder already exists or anything like that. So feel free to send any suggestions and changes to it in a comment or using git send-email to my email address.