Yeah this is the way. Debian stable has outdated packages, debian testing has broken packages. Ubuntu is difficult for beginners because of snap. Linux mint is the perfect just-works debian-based beginner distro. Same for DE: Gnome is hard to use, KDE is bloated and unstable, and XFCE is too minimalist/diy/quirky for beginner users (you need to add a panel applet in order for the volume keys to work? Huh??). Cinnamon is the perfect middle ground between resource usage and features.

Make sure during installation that you create a 4 GB swap partition too

Or at least as large as your RAM if you want to be able to hibernate.

What desktop environment? KDE, right? Just make sure you aren’t using the encFS backend for your vaults, it’s insecure https://defuse.ca/audits/encfs.htm

I don’t use KDE, so they may have already dropped support for encfs, idk. Just wanted to leave a warning for you/anyone else

but I do have encrypted directories for my sensitive data

What do you use for encrypted directories? Ecryptfs?

Looks like it works! Congrats!

Not sure if any of that is helpful for your case but I recommend trying something if you’ve got spare hardware, and see how it goes on dummy data, then blow it away try something else.

This is good advice, thanks! Pretty much what I’m doing right now. Already tried it with IPFS, and found that it didn’t meet my needs. Currently setting up a tahoe-lafs grid to see how it works. Will try out ceph after this.

How is ceph working out for you btw? I’m looking into distributed storage solutions rn. My usecase is to have a single unified filesystem/index, but to store the contents of the files on different machines, possibly with redundancy. In particular, I want to be able to upload some files to the cluster and be able to see them (the directory structure and filenames) even when the underlying machine storing their content goes offline. Is that a valid usecase for ceph?

Yep. Intel atom D525

If GRUB is too confusing, just uninstall it? You said you have a UEFI system, you don’t need a bootloader. You can just put the vmlinuz and initramfs onto the ESP and boot into it directly. You can use efibootmgr to create the boot entry, something like this:

efibootmgr \
	--create \
	--disk /dev/sda \
	--part 1 \
	--index 0 \
	--label "Void linux" \
	--loader /vmlinuz-6.6.52_1 \
	--unicode " \
		root=PARTLABEL=VOID_ROOT \
		rw \
		initrd=\\initramfs-6.6.52_1.img \
		loglevel=4 \
		net.ifnames=0 \
		biosdevname=0 \
		nowatchdog \
		iomem=relaxed \
		"

• --disk /dev/sda: What disk is the esp on?
• --part 1 What partition number (counting from 1) is the esp on?
• --index 0 At what index in the boot menu should the boot entry appear?
• --loader Path to the vmlinuz file. These are normally in /boot, you have to move it to the esp yourself
• root=PARTLABEL=VOID_ROOT this is the linux root partiion. I’m using PARTLABEL to identify mine, but you can use pretty much anything that /etc/fstab supports
• initrd=\\initramfs-6.6.52_1.img Again, you have to move the initramfs file from /boot into the esp. For some reason this uses backslashes, not forward slashes as path separator (double backslashes in this case are to prevent the shell from interpreting it as an escape sequence)
• The rest of the arguments are just misc kernel parameters that I use

Just search for EFISTUB for more info.

A lot of “hardware raid” is just a separate controller doing software raid. I thought I lost access to a bunch of data when my raid controller died, before I realized that I could just plug the disks directly into the computer and mount them with mdadm. But yes, hardware raid seems a bit pointless nowadays.

modular daemons

A message bus won’t magically remove the need for developers to sit down together and agree on how some API would work. And not having a message bus also doesn’t magically prevent you from allowing for alternative implementations. Pipewire is an alternative implementation of pulseaudio, and neither of those rely on dbus (pulse can optionally use dbus, but not for its core features). When using dbus, developers have to agree on which path the service owns and which methods it exposes. When using unix sockets, they have to agree where the socket lives and what data format it uses. It’s all the same.

It can even start the receiving daemon if it is not yet running.

We have a tool for that, it’s called an init system. Init systems offer a large degree of control over daemons (centralized logging? making sure things are started in the correct order? letting the user disable and enable different daemons?). Dbus’ autostart mechanism is a poor substitute. Want to run daemons per-user instead of as root? Many init systems let you do that too (I know systemd and runit do).