EXT

So, these days, I'm always trying to find and follow the conf.d tradition. The rationale of this tradition looks like:

• /etc/somepackage/somepackage.conf is where the default configuration is.
• /etc/somepackage/conf.d/ is where the overrides are; this is where you put your user conf.

Normally somepackage.conf is managed by the package manager. When the package gets upgraded (shipping a new version of somepackage.conf), and there are local changes, the package manager will ask you: To overwrite with the maintainer's version or to keep yours.

This question is often difficult to answer, especially if you can't, for the life of you, remember what the heck that package is about. Even "show diff" sometimes fails to help. You have to resort to searching.

Keeping your confs under conf.d helps you avoid this altogether. It also helps you separate them, selectively include/exclude some of them to a system, and prioritize them (the 00-my.conf and 99-my.conf pattern).

But that makes me wonder: If all of my user conf will stay inside conf.d, why bother? Why have /etc/somepackage/somepackage.conf at all? Why is it under /etc anyway? Legacy. /etc/resolv.conf is the first example to come to mind. Different apps fight over the control of this file, so sometimes you encounter advice like sudo chattr +i to prevent any change. Absurd, but it works!

So today I briefly wondered if there's any ongoing effort or a new clever solution to address this. Well, there's NixOS which nullifies quite a bit of my point. I've always liked its idea since like 15 years ago. But is there anything else, anything new, for my existing (less exciting) systems?

…I asked ChatGPT 5-Thinking about this, and its answer was mostly expected. The only thing that amused me was the discovery of etckeeper. OK that looks interesting.

OH MY GOD I CAN TURN ON MORE TOOLBARS

I'M GOING INTO HYPERSPACE

TIL: Use install to create the directory layout on GNU/Linux.

Suppose you need to create a file at a nested path like /etc/systemd/zram-generator.conf.d/10-writeback.conf. (Happens all the time.)

That means you need to create the parent directories recursively as needed. The portable, POSIX way would be:

mkdir -p "$(dirname /etc/some/deep/path/to/your/file)" && : > /etc/some/deep/path/to/your/file

Eeek!

But install can come handy. Originally it's about copying the files from one directory to another. So install SOURCE DEST copies files in SOURCE to DEST. But there's -D option:

-D: create all leading components of DEST except the last, or all components of --target-directory, then copy SOURCE to DEST

Together with a good default mod (-m 0644), you can:

install -m 0644 -D /dev/null /etc/some/deep/path/to/your/file

...And it works! Far more memorable, plus it works nicely with Fish's powerful history autocompletion. No need to add a custom function or script.

The -D option is GNU/Linux only. On other systems like macOS, you will have to:

install -d "$(dirname /path/to/file)" && install -m 0644 /dev/null /path/to/file

But this would be worse than the mkdir -p circus above.

i am a firm believer in bringing back PCMCIA and irda now that the patents have expired. let’s make a pcmcia GPU based on the PS2 or gamecube

For the servers I own and manage, I'd chsh to Fish. That alone eased the whole sysadmin thing a lot.

But today, configuring a new server, I'm trying out a new approach: Don't chsh, but always SHELL=/usr/bin/fish tmux whenever I do stuff manually via SSH.

I'm expecting two advantages: Scripts that expect Bash will have less chance of breakage, and it will remind me to never start anything outside of Tmux.

So far this seems to be working.

OK now it seems to be fixed… (sigh)

As soon I try logging in to Discord on Firefox on GNU/Linux, I get this error. Chromium works fine. Am I the only one experiencing this? :(

About Haskell package ecosystem, Nikita Volkov wrote an advice: Internal convention is a mistake – Functional programming debugs you

It has been roughly seven (!) years, but I think it's still a pretty good article based on a pretty good idea. I guess no one has come up with a better solution?

I love DFRobot's CM4 Router Board hardware. I can't find anything to complain about. The closest thing would be that the sysfs LED control at /sys/class/leds/PWR/trigger doesn't work. The PWR LED is always on. (Controlling ACT works perfectly well.) So you can see how insignificant it is. In other words, I love my router.