Defaults are usually fine for most users. People who know they are going to distro hop or need to move data later should have a separate /home, but that’s about it until you get into special purpose installs.

Tailscale is both a client and server. If you use only Tailscale, you have to pay for the service after so many devices are connected, which by all means support the company and do so and avoid using Headscale.

Headscale is an open source implementation of the Tailscale service, so it’s free to use with all the usual Tailscale clients published. You setup Headscale somewhere, register your Tailscale clients to it, and use it like usual. It’s just skipping the need to pay for Tailscale servers as a service, and gives you greater control over how traffic routed. Completely optional.

Tailscale+Headscale or Zerotier, use whatever backup software you want for the local backups. Simple script to rsync backups to other sites and remove copies past a certain age.

Pretty simple, and no need to expose machines in any less than safe ways.

The GitHub repo IS the source code. That’s what open source means. All of the code is right there, and the releases ARE the FOSS version. There is no closed-source code for this project.

You don’t need to use Apache if that’s confusing you. The project seems to include a full Caddyfile so that’s probably going to be easier for you.

It’s really just personal preference, and either way is fine.

Cache commitment is not a memory leak. Hard commit is.

Think about limiting the resources it can see/use and move forward.

Everything in Linux is flat files. Don’t panic.

Back up ~/home, do a clean install, then drop your stuff back in.

They are the minority, but have large player bases. Eliminating that barrier would mean that Linux devices (not just desktops) would be a one-shot win for most consumers.

Well if it doesn’t show as a valid output devices there’s your problem. You might want to start searching on how to use pipewire configs to force it into being a properly advertised output device.

The speaker probably doesn’t advertise it’s capabilities properly.

Install qasmixer or pavucontrol (both available in all distro repos) and see if you can find the right combo of selections to get sound on it.

Well…it has the opportunity to be. More native integration and/or wine fixes for certain issues, and anti-cheat being allowed would definitely put it on track to be there.

But what are you trying to use fail2ban for?

You know what makes it really easy to move things around? Proper IaC configuration management in revision control. Build pipelines if you really want to be proper about it with containers.

Using containers as an excuse for “well, I can just move it somewhere else” is the exact reason to not be using containers for absolutely everything. This is the reason why web devs are horrible at infrastructure, and devops is suddenly back in demand. Removing yourself from the actual issues of properly versioning and controlling all your things just to rely on containers is a detriment to actually understand the interactions of what you’re running, where you’re running it.

Containers are an abstraction on top of the OS and hardware that directly communicates with the UPS versus the bare device access needed to communicate via host.

So then you have to run a privileged container for exclusive access to a specific HID port, map said port, and then hope that every OS update you do for whatever your particular container runtime doesnt causes disruptions or comms issues to trigger events on the UPS itself.

Or…just run it on the host and only worry about the NUT server itself. Also to be frank, I don’t imagine that NUT utils in themselves are very container fluid or aware because…why?

I honestly hate that people have become so null to the argument that host things are better at host things. Software that uses direct port access has absolutely no reason to run in a container UNLESS you have no other option. People using containers as default just cuz is bad practice. They have a place and purpose, and this isn’t one of them if host is an option.

Host. There’s no benefit to running it in a container, and there’s all the problems with running it in a container.

Why? Fail2ban is best placed on the host closest to a network entrypoint. Unless you’re intentionally avoiding a bridged network, this isn’t going to do much for your security unless the containers are directly addressed by an attached interface and an open service.

I won’t go into a whole diatribe, but you should be running containers as single-process instances of applications. You only cause issues by cramming other process to run inside a container.

What are you using it to block, exactly?

Ah, yeah. The manual nature of it is either a pro or con, depending. I don’t think there is a workaround for that if you’re not able to just drag and drop menu entries for existing menus because it’s in a different context. It SHOULD use the same launcher format as Gnome though, being an extension and all, so maybe have a look at where on the filesystem it’s creating the entries, and see if you can just cp existing launcher configs over to Arcmenu, or symlink them.

I might be getting hung up on this confusing part:

“…it lacks app grouping support of any kind…”

I’m looking at it right now, and it has groups, it’s just manual. Is your issue that it’s not automatically grouping things? In order to do that, there would need to exist information in whatever method of installing packages to give it some sort of category to group by.

That’s just generally not how the Linux ecosystem works at all, mainly because there is no one DE, hence not many packages baking in direct support of one vs another.

Gnome has transitioned away from menu-based launching, and everything is designed around launcher by actions: text search, gesture, launch bars…etc.

You can try installing an extension like this one to do something more like you’re suggesting.