I've been trying to do a bit of "spring cleaning" on my PC by getting rid of things like unused dotfiles and packages, and I've been wondering as of late whether the XDG dir spec is worth following considering its aims to unclutter the home directory.
How worthwhile is it to adhere to their spec — in spite of everything else that fd.o likes to throw at people like systemdicks — and what solutions does Artix provide for users who would like to stick with it to that extent?
I've removed directories such as Documents and Videos for a good while now, almost nothing complains, not even Wine, and xdg calls are nice enough to not recreate them unless a client program explicitly does so (very rare).
The only problems are when a program wants to write to those paths (also rare ish), some are smart enough to write directly in the root of the home directory (if you're not careful and you use an exotic program, watch out that it doesn't litter your home directory this way), others will silently throw an error.
The dotfiles are all safe to remove except the one in Desktop (if you use a form of DM session that is, otherwise remove that too)
Those I don't have that much issue with since I would try to make use of those when I was still on Windows a good few years ago. What I was referring to more was the adherence to things like
XDG_CONFIG_HOME and trying to make sure as much of the software installed makes use of it instead of its own dotted folder under
HOME.
The Arch wiki (https://wiki.archlinux.org/title/XDG_Base_Directory) seems to cover a pretty exhaustive list of cases, for example, which I've been taking a look at for my own reference just now.
Okay, now I get it. I never thought of such a use case before, i only knew of moving the entire /home to another partition.
The idea of having XDG_CACHE_HOME write to a ramdisk is certainly very interesting, especially when you wipe that directory often.
Otherwise the rest like .config for me don't make sense, probably for testing maybe.
I'll try to test it quickly, one sec
LE: Oh my, it does work, as a test i pointed XDG_CACHE_HOME to /tmp and nothing gets written in ~/.cache anymore
I'll actually do this from now on, just gotta automate the creation of a separate directory in /tmp before the session loads to avoid conflicts
And probably point it to another path when making big 10GB compiles :D
Wait, how'd you manage that?! Are you using something akin to
~/.bashrc for that? I can't seem to replicate that for every program right now.
LQXt Session Settings in my case, you can also use .Xprofile etc etc.
Interesting thread. (to me :) )
I like to keep the data away from the dotfiles. For ease of backups.
My setup
I have a directory ~/Files. It's a separate partition, it is mounted there in fstab.
Directories such as Desktop, Downloads, Pictures etc etc are all under ~/Files and setup in KDE as such.
I make a daily incremental backup of ~/ with rsnapshot-timestamp. 7 days / 4 weeks /forever months
I keep important stuff in various ~/Files/Nextcloud/* directories so that gets backed up on my nextcloud server.
I further complicate things by having a folder ~/Files/.dotfiles and big stuff I'm not so fussed about losing, from ~/.local/share , is actually stored there then linked back to ~/.local/share (lutris, wine prefixes, emulator stuff etc).
~/.cache is it's own ram tmpfs
tmpfs /home/user/.cache tmpfs noatime,nodev,nosuid,size=28G
@gripped Hmm so force mounting the path in fstab does the same thing, interesting.
Does the tmpfs volume scale itself dynamically so I can size it above physical ram (and e.g. go into swap in case it ever gets big)? Or you have above 28gb ram? Cause I would like to not worry about the cache dir ever to cause a OOM and get something killed/be deleted unexpectedly.
PS my backup scheme is primitive, I do a semi manual backup of the home dir with some exclusions in tar, and put that on hard drive every week or so :)
use xdg-ninja (https://github.com/b3nj5m1n/xdg-ninja) to find packages that are supported.
If you care enough, you can always keep the output of
~$ ls -al | wc -l
to less than 30
i recommend keep your home close to this
.cache
.config
.local
.ssh
Desktop
Documents
Downloads
Music
Pictures
Public
Templates
Videos
mnt
.xprofile
.zprofile
i gave up on .git .java .librewolf .gitmodules .gitignore .steam .steampath .steampid
Any recommendation for
.dbus, then? I don't quite trust at the moment that none of my software actually uses D-Bus and Arch's recommendation for it is something that basically requires soystemd for its service, so I wonder if there's some equivalent to it that would be usable on Artix.
Yes tmpfs scales itself and will use swap if needed, though of course we don't want that. I used to have no size set for .cache but yay compiles in there and something was running out of space and failing with the default 16G.
It only uses what it needs to
~/Files 10:15:55
❯ df -h |grep tmpfs
tmpfs 28G 353M 28G 2% /home/user/.cache
tmpfs 16G 5.6M 16G 1% /tmp
tmpfs 3.2G 16K 3.2G 1% /run/user/1000
Check this out https://github.com/kmccormick/rsnapshot-timestamp . It's a wrapper around, and improves upon greatly, https://rsnapshot.org/ , itself a wrapper around rsync !
It's not been updated in years but it still works very well.
Every night cron jobs do incremental backups of my home dir, my local mini-pc server (nextcloud, email server, websites), and four remote vps's (some mine, some other peoples). And I don't have to lift a finger :) Any thing goes wrong and i can revert to a chosen (available) date.
I got it now, thank you.
I'll certainly try that utility, maybe with this occasion i won't longer find rsync to be as weird as i thought it is :D
used to have a thin client myself, didn't use it for much back in the day so when it's psu broke in a power surge i just gutted it out for parts, I'd get one now to use as a router, (openwrt is in kind of a bad state right now due to their aggressive policy of updating kernel, and also kinda rushing nft), wireguard offload, server indeed and a few other things.
Turns out there is a
dbus-broker (https://gitea.artixlinux.org/packagesD/dbus-broker) package also maintained on Artix. Now the question is what the setup for it as a drop-in replacement for regular dbus init looks like, since the documentation is written exclusively with systemd in mind and there don't seem to be any packages for an alternate init script (in my case,
runit).
The general separation of things into the .cache/.config/etc. directories I find helpful and useful. Cluttering the home directory with junk is not something I'm fond of. Fortunately, most programs nowadays respect this. There's just a few notable outliers left (dbus, mozilla, etc.)
Unfortunately, the init/launcher for dbus-broker is written specifically for systemd. There's no way for us to write user scripts for it until someone adds a non-systemd dependent launcher for dbus-broker.
For those who might still be curious, someone has recently released a utility (https://github.com/ValveSoftware/steam-for-linux/issues/1890#issuecomment-1522831854) for Steam that allows it to adhere to the XDG spec, eliminating the need for the .steam* files within the HOME directory.