I don’t think you realize that if your goal is to have a simple install method anyone can use, even redirecting the output to install.sh like in your examples is enough added complexity to make it not work in some cases. Again, those are not made for people that know bash.

If you can’t review a bash script before running it without having an unnecessarily complex one-liner provided to you to do so, then it doesn’t matter because you aren’t going to be able to adequately review a bash script anyway.

Showing people that are running curl piped to bash the script they are about to run doesn’t really accomplish anything. If they can read bash and want to review the script then they can by just opening the URL, and the people that aren’t doing that don’t care what’s in the script, so why waste their time with it?

Do you think most users installing software from the AUR are actually reading the pkgbuilds? I’d guess it’s a pretty small percentage that do.

That reddit thread is horrible advice, it’s just mapping the LXC root user to the host root user, which is just a privileged LXC with extra steps (and maybe less secure).

The reason you’re probably having issues is that your root user in the LXC is mapped to the host user 100000 by default, and that user doesn’t have access to the share, but you can change that with mount options or creating a user with 100000:100000 and adding it to a group with access.

I use Tautulli, but I’m not sure if that is going to cover all the same use cases.

I haven’t gotten around to spinning it up yet, but I was just looking into this myself and was going to try out Pinchflat. If anyone has used it and has any feedback I’d love to hear it.

I was between it and Tube Archivist.

For anything. You can get a push notification for anything you can make run a script or send an http request.

This has strong “nobody needs a monitor over 120Hz because the human eye can’t see it” logic. Transparency is completely subjective and people have different perceptions and sensitivities to audio and video compression artifacts. The quality of the hardware playing it back is also going to make a difference, and different setups are going to have a different ceiling for what can be heard.

The vast majority of people are genuinely going to hear zero difference between even 320kbps and a FLAC but that doesn’t mean there actually is zero difference, you’re still losing audio data. Even going from a 24-bit to a 16-bit FLAC can have a perceptible difference.

Nobody “needs” to listen to music over Bluetooth at all, but why not make it sound like it’s supposed to?

Just run docker in an LXC. That’s what I do when I have to.

I’m not really worried about it. Each LXC runs as its own user on the host, and they only have access to what they need to run each service.

If there’s an exploit found that makes that setup inherently vulnerable then a lot of people would be way more screwed than I would.

I don’t have anything publically accesible on my network (other than wireguard), but if I did I’d just put whatever it was on its own VLAN, run a wireguard server on it, and use a VPS as a reverse proxy that connects to it.

I only use unprivileged LXCs and everything I host on my network runs in its own LXC, so I’m not really worried about someone getting access to the host from there.

I don’t know of anything like what you’re looking for, but I have been using CachyOS for over a year now and I really like it. If you’re looking to get the most performance out of your machine for gaming I wouldn’t think you’d want such a stable release like Debian anyway.

Edit: like the other poster mentioned, I never did any testing or anything, but I also didn’t notice any major improvements when I switched from vanilla Arch to CachyOS to be fair.

I will put in the time and effort to migrate to this from proxmox eventually.

Truly one of the most embarassing things I have ever seen someone share publically.

Over polite comments responding to an opinion about a video game.

lol I would open every port on my router and route them all to wireguard before I would ever consider doing this

I use notifications in Thunder and I’ve had no issues. I haven’t compared the difference or anything, but when I’ve happened to check battery usage it’s always been a reasonable amount for how much I’ve used it that day. It does generate a decent amount of network traffic since it’s regularly checking with you instance for it, and that traffic is generated for each account you have reaching out to each instance. That should be how any FOSS app works though, the alternative would be something like Sync where you pay to have actual pushes sent from their server.

I use Nextcloud with Nginx Proxy Manager and just use NPM to handle the reverse proxy, nothing in Nextcloud other than adding the domain to the config so it’s trusted.

I use Plex instead of Jellyfin, but I stream it through NPM with no issues. I can’t speak to the tunnel though, I prefer a simple wireguard tunnel for anything external so I’ve never tried it.

Edit: unless that’s what you mean by tunnel, I was assuming you meant traefik or tailscale or one of the other solutions I see posted more often, but I think one or both of those use wireguard under the hood.

The issue is that the docker container will still be running as the LXC’s root user even if you specify another user to run as in the docker compose file or run command, and if root doesn’t have access to the dir the container will always fail.

The solution to this is to remap the unprivileged LXC’s root user to a user on the Proxmox host that has access to the dir using the LXC’s config file, mount the container’s filesystem using pct mount, and then chown everything in the container owned by the default root mapped user (100000).

These are the commands I use for this:

find /var/lib/lxc/xxx/rootfs -user 100000 -type f -exec chown username {} +;
find /var/lib/lxc/xxx/rootfs -user 100000 -type d -exec chown username {} +;
find /var/lib/lxc/xxx/rootfs -user 100000 -type l -exec chown -h username {} +;
find /var/lib/lxc/xxx/rootfs -group 100000 -type f -exec chown :username {} +;
find /var/lib/lxc/xxx/rootfs -group 100000 -type d -exec chown :username {} +;
find /var/lib/lxc/xxx/rootfs -group 100000 -type l -exec chown -h :username {} +

(Replace xxx with the LXC number and username with the host user/UID)

If group permissions are involved you’ll also have to map those groups in the LXC config, create them in the LXC with the corresponding GIDs, add them as supplementary groups to the root user in the LXC, and then add them to the docker compose yaml using group_add.

It’s super confusing and annoying but this is the workflow I’m using now to avoid having to have any resources tied up in VMs unnecessarily.

I’ve been doing this for at least a decade now and the drives are just as reliable as if you bought them normally. The only downside is having to block one of the pins on the SATA connector with kapton tape for it to work.