From 9136401f6975119af5d37f13b20cd92937b06118 Mon Sep 17 00:00:00 2001 From: Sadeep Madurange Date: Sat, 29 Nov 2025 22:00:01 +0800 Subject: Suckless software. --- _site/archive/suckless-software/index.html | 142 +++++++++++++++++++++++++++++ 1 file changed, 142 insertions(+) create mode 100644 _site/archive/suckless-software/index.html (limited to '_site/archive/suckless-software') diff --git a/_site/archive/suckless-software/index.html b/_site/archive/suckless-software/index.html new file mode 100644 index 0000000..e19125b --- /dev/null +++ b/_site/archive/suckless-software/index.html @@ -0,0 +1,142 @@ + + + + + Suckless software + + + + + Suckless software + + + + + + + + + +
+ +
+ + + +
+
+

SUCKLESS SOFTWARE

+
30 NOVEMBER 2025
+
+

Since suckless software requires users to modify the +source code and recompile to customize, I need a way to maintain patches over +the long term while retaining the ability to upgrade the software as new +versions are released.

+ +

Initial setup

+ +

When using a suckless program, I usually begin by cloning the project and +setting the remote URL to push a copy of the source code with my patches to my +own git repository:

+ +
git clone git://git.suckless.org/dwm
+git reset --hard <tag>
+git remote set-url --push origin git@git.asciimx.com:/repos/dwm
+
+ +

This way, I can pull updates from the upstream project whenever I want, while +committing my changes to my own git repository. The git reset command aligns my +branch head with a stable release before applying patches or installing the +software.

+ +

If all I want to do is reconfigure the software (e.g., change key bindings), +which is what I need most of the time, the recommended approach is to modify +the config.h file. If the config.h isn’t yet in the project, the following +command generates it from the defaults and compiles the software:

+ +
make clean <target>
+
+ +

Where <target> is the name of the application (e.g., dwm) found in the +Makefile. I modify the resulting config.h file and run make clean install to +install the software before committing and pushing my changes to my git repo.

+ +

dwm and slstatus

+ +

Since dwm and slstatus are always running, make install will likely fail for +them. The operating system will prevent the installer from replacing running +executables with new ones. Hence, we must first stop the running instances of +these programs:

+ +
    +
  1. Quit the window manager: Mod + Shift + q (or if you have modified the +command, use that instead).
  2. +
  3. Switch to tty: Ctrl + Alt + F1.
  4. +
  5. Log in and change the directory to where dwm/slstatus is.
  6. +
  7. Run make install to install the software.
  8. +
  9. Switch back to the graphical session: Ctrl + Alt + F5.
  10. +
  11. Verify installation: dwm -v/slstatus -v.
  12. +
  13. Commit changes to git and push.
  14. +
+ +

The key combinations for switching to the tty and back may differ across +systems. The ones listed above are for OpenBSD.

+ +

Subsequent upgrades

+ +

When suckless releases a new version, I run git pull --rebase to fetch the +upstream changes and rebase my patches on top of them. Because I tend to use +stable versions, I perform another interactive rebase to drop the commits +between the latest stable version tag and my patch before installing the +software.

+ +

Commit log before upgrading:

+ +
dt236  My patch.
+3fkdf  Version 6.5.
+
+ +

Commit log after pulling:

+ +
w467d  My patch.
+gh25g  A commit.
+g525g  Another commit.
+3fkdf  Version 6.6.
+vd425  Old commit.
+q12vu  Another old commit.
+3fkdf  Version 6.5.
+
+ +

Commit log after the interactive rebase:

+ +
h57jh  My patch.
+3fkdf  Version 6.6.
+vd425  Old commit.
+q12vu  Another old commit.
+3fkdf  Version 6.5.
+
+ +

And finally, commit and push all the changes to my own git repository.

+ +
+ +
+
+ + + -- cgit v1.2.3