Yeah, management positions are often filled by people who:

A) Want to get a higher paying job and don’t care about the product or the industry necessarily (MBA-circlejerk types).

B) Are Devs/Artists/Creatives that wanted increased compensation, and the only way up was as a manager where they have less aptitude.

Executive staff needs to better integrate management as “servant leaders” within teams, and compensate EVERYONE better

Another shitty thing about Plexamp is there is no easy way to download your entire library in a converted format and auto download any new additions.

The developer said that “this is not the intended use of Plexamp”, but the reasoning is flawed IMO

The only thing keeping me on Plex is iOS downloads supported natively.

The second Swiftfin gets that I will be switching fully to Jellyfin

Yeah I saw a post about it a long time ago on Reddit for users with lots of devices

Basically it is just setting up one or two “central devices” that know all the client devices, but not linking the client devices individually.

IE: One server is connected to your phone, laptop, tablet, desktop, etc. But the phone is not directly connected to your laptop or desktop or tablet.

To be fair I don’t actually know if this is the best approach anymore or if just connecting all of them in a mesh is better 🤷

Here is a forum post describing it.

Plex, PiHole, Photoprism, Home Assistant, Syncthing in a hub and spoke config, Caddy for reverse proxy, custom containers for: yt-dlp, restic, and rsync.

I bought a .com for like $10 CAD from Cloudflare that uses a URL not linked to me.

Maybe overly paranoid, but it also makes it easy to get SSL certificates for my lab.

From a user perspective, Distrobox is a tool that lets you “spin up any distro inside your terminal”.

You can basically create a mini Linux environment of any distro that you can access through the terminal. You can set it to share your home folder, our create a new home folder just for that mini environment.

Behind the scenes Distrobox is creating and managing containers through Podman or Docker. You could technically achieve the same thing by manually setting up Podman containers, Distrobox just makes it very easy to create and maintain those containers with the correct permissions. It also has useful tools where you could install an app in a Distrobox container, but then add that app to your host OS app list.

This makes it especially useful for immutable OSs. Instead of adding packages to your base OS, which should be kept as minimal as possible, you can just install them in a Distrobox, so your host’s root filesystem is unaffected.

I daily drive Fedora Silverblue on my laptop and distrobox has been great.

I have layered only two packages: USB Guard and Distrobox. I run syncthing in a rootless podman container, and the rest goes through Distrobox.

I was even able to setup ProtonVPN in distrobox and it functions as if it was directly installed on the host (just need to map your home folder and some permissions).

I hope that immutable becomes either the standard or at least all major distros start offering it as an alternative. Makes everything foolproof and makes me much more willing to try new packages and tools because I can always just roll back.

The only thing that would really make it perfect is if files in /etc/ where also handled in a similar manner. IE: Can make changes to configuration files, and easily roll back to defaults at any time.

I run everything in rootless containers using systemd service files generated with podman generate systemd.

Podman Compose is a “community effort”, and Red Hat seems to be less focused on its development (here is their post about it).

There are ways to get it working but I find it easier to go with podman containers and pods through systemd because the majority of documentation (both official and unofficial) leans in that direction.

I don’t know how much you already know, so here is just a summary of things that worked for me for anyone reading.

Podman uses the concept of “Pods” to link together associated containers and manage name spaces, networking, etc. The high level summary for running podman pods through systemd:

• Create an empty pod podman pod create --name=<mypod>.
• Start containers using podman run --pod=<mypod> ... and reconfigure until containers are working within the same pod as desired.
• Use podman generate systemd to create a set of systemd unit files. Be sure to read through the options in that man page. – this is more reliable than creating systemd unit files by hand because it creates unit files optimized for the podman workflow.
• place the generated systemd unit files in the right place (user vs. system) and then it can be started, enabled, and disabled as with other systemd unit files.

Note: for standalone containers that are not linked or reliant on other containers, you can should skip creating the empty pod and can skip the --pod=<mypod> when starting containers. This should result in a single service file generated and that container will operate independently.

This post goes over pods as systemd services.

This doc goes over containers as systemd services.

The Red Hat Enterprise Linux docs have a good amount of info, as well as their “sysadmin” series of posts.

Here are some harder to find things I’ve had to hunt down that might help with troubleshooting:

• Important: be sure to enable loginctl enable-linger <username> or else rootless pods/containers will stop when you log out of that session.
• If you want it to run a container or pod at system startup you will need to specify the right parameters in the [Install] section of the systemd file, see this doc page. Podman generate systemd should take care of this.
• If you are using SELinux there is a package called container-selinux that has some useful booleans that can help with specific policies (container-use-devices is a good one if your container needs access to a GPU or similar). Link to repo