Same here, parents. Feel free to turn on automatic updates. It’s never broken anything, and vulnerabilities do need patching.

Thank you very much for the detailed and well-sourced write-up! I’ve saved it for later when I get to drill down on this.

It kind of proves OP’s point though: distros do come with a lot of idiosyncrasies of “how things are done around these parts”.

I have zero experience with that. 😄

Basically, anything that isn’t packaged as a flatpak needs to be installed from the CLI using distrobox containers, which will go over the heads of the majority of new users.

Just like your “opponents” are over-generalising, you’re deliberately picking the most extreme examples to make your argument. (Batocera as a daily driver - you know that’s what Hanna Montana Linux is for!)

My Linux axioms are: for most new users…

1. choice of DE is most noticeable and decides whether they like their initial experience.
2. choice of base distro family does matter a lot in the long run (Debian-based vs. Arch-based vs. Redhat-based); if you stay inside the same family (e.g. Pop!OS vs. Ubuntu vs. Zorin vs. Mint), choice matters a lot less (and DE is most impactful, c.f. point one).
3. choosing a distro with specialised security hardening (immutable systems, Nix, Qubes, Bazzite) does matter; most of these will make new users unhappy or even question their sanity.

Where you are right: yes, the choices embedded within these three axioms do matter a lot and are noticeable, so it is helpful to have an experienced user recommend a distro to you when starting out.

Where the “distro don’t matter” people are right: there are a lot less choices to be made than meets the eye. Effectively, it can be boiled down to three.

Define what you mean by “locked down”. If you don’t give your user superuser privileges, every distro is locked down because the user can only ever write to their own /home

I’d strongly recommend Mint:

• with Cinnamon DE: very Windows-esque UI
• Ubuntu / Debian-based, i.e. rock-solid, unlikely to break
• 100% automated updates (including automatic removal of old kernels so your /boot won’t get clogged
• Timeshift system snapshots in case something does break. (Note: I’ve only ever used Timeshift to un-fuck systems that I, personally, had fucked with superuser rights and manual meddling.)

VLC for files in local storage.

Tempus for streaming / downloading the rest from my Navidrome instance.

In the laptop, I tried Supersonic to stream music from my server, but for some odd reason it audibly degraded sound quality, so I ditched it. I have since been using my browser. I might try it again, though, and see if the issue has been fixed.

I don’t recommend auto updates, because updates break things and dealing with that is a lot of work.

Learnt this the hard way. Been version pinning ever since.

Nice setup! Are all those LXCs rootless docker containers?

I don’t like Ansible, other tools can be easier to use. But I don’t want to recommend something concrete.

Which ones do you like to work with? (Even though it’s not a recommendation ;) I’ve only dabbled in Ansible so far and found it overkill for most of the things I do, but maybe one of yours isn’t?

That’s what I use it for as well. Updating 7+ VMs is no fun. With Ansible? No worries.

But as a result you’ll have a self-documented configuration-as-a-code that will allow you to scale your setup as you need. Reproducing something won’t require reading your notes, remembering your actions etc.

Until you realise that

• you don’t really need to scale a homelab that much
• if something breaks, you just want to quickly fix it manually because “doing the Ansible” is more of a pain
• now idempotency and documentation-as-code is out of the window. ;)

(I’m being tongue-in-cheek here. I don’t doubt this may work for you, but it takes much more discipline than I have.)

How does Bento compare to local tools such as PDFSam?

If by “getting” music you mean “self-host stuff you already own”: Navidrome is an obvious choice, with Tempus for Android clients. It’s ridiculously low on resources, rich in features and quite pretty.

Nice setup! I particularly like the kitchenowl deployment - it’s such an amazing tool and relatively unknown.

One suggestion: the title header says “Family homepage”, yet the page contains admin tools that none other than you will ever use. I noticed that all this “admin clutter” was so off-putting that it kept others from actually using the dashboard. I’ve therefore created another homepage instance that showcases user-facing services only. It makes the UI much cleaner - and users more likely to actually find the services they may be looking for.

It’s not this or that. Security comes in layers. So while I would assume that the Jellyfin developers do their best to secure their application, I acknowledge the fact that bugs do exist and that Jellyfin is developed in and for hobbyist contexts, and thus not scrutinised and pentested for vulnerabilities in the way software meant for professional environments would be. Therefore I’ll add an extra layer of security by putting it behind a VPN that only whitelisted clients can access. If a vulnerability is detected, I can be sure it hasn’t already been exploited to compromise my server because we’re all “among friends” there.

This. And for everyone you just can’t figure it out on their own, there’s RustDesk for remote assistance. It, too, can be self-hosted.

YOU MIGHT WANT TO GET THAT CAPS LOCK KEY FIXED, MATE!

I can’t see why somebody objecting to TrueNAS flirting with closed source would want to switch to a fully proprietary system like Unraid.

Tbh, I’ve never bothered to figure out how SSHing into an Android device works.

You’re right about the security of older versions of Synching-Fork if you remember to configure it to only do syncs locally (it’s not configured like that by default).