moonpiedumplings

There is also no way to verify that the software that is being installed is not going to do anything bad. If you trust the software then why not trust the installation scripts by the same authors

Just because I trust the authors to write good software in a popular programming language, doesn't mean I trust them to write shell scripts in a language known for footguns.

The problem with a central script repository is that bash scripts are difficult to audit, both for malicious activity, but also for bad practices and user errors.

A steam bug in their bash script once deleted a user's home repository.

Even though the AUR is "basically" bash scripts, it's acceptable because they use their own format that calls other scripts other the hood, and the standardized format makes it easier to audit. Although I have heard a few stories of issues with this, like one poorly made AUR package moving someone's /bin to /opt and breaking everything.

So in my opinion, a package manager based on bash basically doesn't work because of these issues. All modern packaging uses some kind of actual standardized format, to make it easier to audit and develop, and to either mitigate package maintainer/creator error, or to prevent it entirely.

If you want to install tools on another distro that doesn't package them currently, I think nix, Junest, or distrobox are good solutions, because they essentially give you access to the package managers of other distros. Nix in particular has the most packages out of any distro, even more than the AUR and arch repos combined.

https://wiki.archlinux.org/title/Arch_is_the_best

garden seems similar to GitOps solutions like ArgoCD or FluxCD for deploying helm charts.

Here is an example of authentik deployed using helm and fluxcd.

Firstly, I want to say that I started with podman (alternative to docker) and ansible, but I quickly ran into issues. The last issue I encountered, and the last straw, was that creating a container, I was frustrated because Ansible would not actually change the container unless I used ansible to destroy and recreate it.

Without quadlets, podman manages it’s own state, which has issues, and was the entire reason I was looking into alternatives to podman for managing state.

More research: https://github.com/linux-system-roles/podman: I found an ansible role to generate podman quadlets, but I don’t really want to include ansible roles in my existing ansible roles. Also, it intakes kubernetes yaml, which is very complex for what I am trying to do. At that point, why not just use a single node kubernetes cluster and let kubernetes manage state?

So I switched to Kubernetes.

To answer some of your questions:

Am I really supposed to have a collection of small yaml files for everything, that I use with kubectl apply -f ?? It feels wrong and way too “by hand”! Is there a more scripted way to do it? Should I stay with everything in Ansible ??

So what I (and the industry) uses is called "GitOps". It's essentially you have a git repo, and the software automatically pulls the git repo and applies the configs.

Here is my gitops repo: https://github.com/moonpiedumplings/flux-config. I use FluxCD for GitOps, but there are other options like Rancher's Fleet or the most popular ArgoCD.

As a tip, you can search github for pieces of code to reuse. I usually do path:*.y*ml keywords keywords to search for appropriate pieces of yaml.

I see little to no example on how to deploy the service containers I want (pihole, navidrome, etc.) to a cluster, unlike docker-compose examples that can be found everywhere. Am I looking for the wrong thing?

So the first issue is that Kubernetes doesn't really have "containers". Instead, the smallest controllable unit in Kubernetes is a "pod", which is a collection of containers that share a network device. Of course, pods for selfhosted services like the type this community is interested in will rarely have more than one container in them.

There are ways to convert a docker-compose to a kubernetes pod.

But in general, Kubernetes doesn't use compose files for premade services, but instead helm charts. If you are having issues installing specific helm charts, you should ask for help here so we can iron them out. Helm charts are pretty reliable in my experience, but they do seem to be more involved to set up than docker-compose.

Even official doc seems broken. Am I really supposed to run many helm commands (some of them how just fails) and try and get ssl certs just to have Rancher and its dashboard

So what you're supposed to do is deploy an "ingress", (k3s comes with traefik by default), and then use cert-manager to automatically apply get letsencrypt certs for ingress "objects".

Actually, traefik comes with it's own way to get SSL certs (in addition to ingresses and cert manager), so you can look into that as well, but I decided to use the standardized ingress + cert-manager method because it was also compatible with other ingress software.

Although it seems complex, I've come to really, really love Kubernetes because of features mentioned here. Especially the declarative part, where all my services can be code in a git repo.

Can you share your setup? I'd really like that because I don't think nixgl works with GPPU apps like CUDA or lc0 (chess engine that uses gpu).

EDIT:

Is this it: https://github.com/juipeltje/configs/blob/54e971f6a6da47d6cfd02a6409be97d5e1051b0f/scripts/cron/nix-drivers.sh ?

Although this seems like it would just symlink opengl? What if I wanted GGPU like OpenCL or CUDA?

Edit2: wait, I think I might be misunderstanding how it works. I think nixgl already supports opencl, because it's mesa that implements opencl and opengl. But how would I get mesa support? I don't think the symlink to /run trick works.

About Steam's DRM, many games on steam don't actually require the client to launch:

https://steam.fandom.com/wiki/List_of_DRM-free_games

Yeah, but I only discovered it now.

Looking on github though, it looks like people combine builtins.map with this to wrap a bunch of packages at once though.

Cause it’s just translating to x and back to Wayland

You have a citation for this claim? I can't find anything that backs it up.

Why is waypipe not the answer?

I actually tried this right after I made this post, and it was not where near as smooth as I wanted. KDE would put the window that I had assigned to all desktops on top, whenever I would switch virtual desktops.

I found a solution though, it looks like mpv has support.

Maybe nginx proxy manager can do this.

https://nginxproxymanager.com/