It’s reasonable for an engineering standpoint. Bummer for people who don’t want to run HASSIOS or install HA on an already provisioned system without having to fuck with docker.
I seem to be unable to wrap my head around Docker. I have one application running through Docker (Immich) but I have no idea how it works. It’s running, and until further notice, I ain’t touching it.
I have Home Assistant running through an instance on my Proxmox server. That I can understand much better than anything Docker.
It’s worth taking the effort to learn if you want to self host stuff. The neat part is once you learn it, you can self host basically anything. Think of a container like a little packaged application that can only interact with the outside world through pathways you give it, either through volume mounts (files) or port mappings (network).
Immich is one of the more complicated and intimidating docker-compose files out there. Try something like glance or miniflux to get a gentler introduction.
So far I’ve created a new ProxMox container for each application I wanted to run.
So I have pihole running in an LXC, Nextcloud in another LXC, Audiobookshelf in yet another LXC, Home Assistant in a VM, etc.
I’m sure that could be done more efficiently with Docker, but for some reason that just doesn’t want to click. I don’t know where the applications end up installed at, I don’t know how to configure stuff, nor how to run multiple docker containers on the same machine.
Immich is the first application I have managed to get running full time in Docker, but I’ve already encountered an issue with uploads that I can’t solve, because I have no idea where to find the config files, nor how to restart it. So I’ll leave it as is, for now. Maybe when my brain can get engaged, I can try again.
It’s literally the same thing as running the app from base repo. There is no “fuckery”. The entrypoint of a container is the same as just running the python runtimes for any project. You have zero idea what you’re talking about.
Dudebro, I write software and run servers for a living. Admittedly I don’t work with python, but I have developed web applications that run both on bare metal and in docker containers and I’m telling you that the amount of fuckery required to spin up anything on bare metal will 99% of the time be more than what’s needed to spin up the same application in a container. The end result will be more brittle and more likely to conflict with other software on the same machine.
Also, sure it’s not hard to install HASS in a pyenv now, because the dev team specifically ensured it. Maybe that requires tradeoffs that they don’t want to make anymore?
Seriously quit being a dick to people in niche software communities, it’s pathetic
What turns me off is software that insists on running with unreasonable privileges. Rootless podman containers are the way to go – you can decide the privileges of the user account running the container, and the container image is inspectable (and tweakable if you find something you don’t like). And for the devs, maintaining (just) a container image is way less overhead than managing distribution-specific packages for 5 different package managers and dozens of distributions
Funny part is I’m responsible for some software which needs just a little privilege.
The direct install option runs as a broadly unprivileged user, thanks to systemd service for imparting one, surgical ambient capability to the process.
A team that wraps it in a container however demands it be run privileged, because they say the container runtimes dont support the same granularity, so the container users end up with unreasonable privileges while the direct install users are almost completely running unprivileged.
It’s reasonable for an engineering standpoint. Bummer for people who don’t want to run HASSIOS or install HA on an already provisioned system without having to fuck with docker.
Docker is so much easier to fuck with than python
I seem to be unable to wrap my head around Docker. I have one application running through Docker (Immich) but I have no idea how it works. It’s running, and until further notice, I ain’t touching it.
I have Home Assistant running through an instance on my Proxmox server. That I can understand much better than anything Docker.
It’s worth taking the effort to learn if you want to self host stuff. The neat part is once you learn it, you can self host basically anything. Think of a container like a little packaged application that can only interact with the outside world through pathways you give it, either through volume mounts (files) or port mappings (network).
Immich is one of the more complicated and intimidating docker-compose files out there. Try something like glance or miniflux to get a gentler introduction.
So far I’ve created a new ProxMox container for each application I wanted to run. So I have pihole running in an LXC, Nextcloud in another LXC, Audiobookshelf in yet another LXC, Home Assistant in a VM, etc.
I’m sure that could be done more efficiently with Docker, but for some reason that just doesn’t want to click. I don’t know where the applications end up installed at, I don’t know how to configure stuff, nor how to run multiple docker containers on the same machine.
Immich is the first application I have managed to get running full time in Docker, but I’ve already encountered an issue with uploads that I can’t solve, because I have no idea where to find the config files, nor how to restart it. So I’ll leave it as is, for now. Maybe when my brain can get engaged, I can try again.
Docker is the same thing as executing the runtime of the same program.
WITAF are you even talking about?
From a fuckery standpoint? Docker is way easier, and it works the same way for everything.
It’s literally the same thing as running the app from base repo. There is no “fuckery”. The entrypoint of a container is the same as just running the python runtimes for any project. You have zero idea what you’re talking about.
No it’s not and yes I do you goober. How are dependencies handled in each scenario?
pip install for both. Apparently you are new to 'puters. Go play elsewhere.
Why are you running pipinstall when using a docker container?… Or are you talking about manually creating your own container?
Read the dockerfile. Do you know how any of this works?
Dudebro, I write software and run servers for a living. Admittedly I don’t work with python, but I have developed web applications that run both on bare metal and in docker containers and I’m telling you that the amount of fuckery required to spin up anything on bare metal will 99% of the time be more than what’s needed to spin up the same application in a container. The end result will be more brittle and more likely to conflict with other software on the same machine.
Also, sure it’s not hard to install HASS in a pyenv now, because the dev team specifically ensured it. Maybe that requires tradeoffs that they don’t want to make anymore?
Seriously quit being a dick to people in niche software communities, it’s pathetic
Removed by mod
Yeah, easiest way to turn me off a project is pushing black box installers. Don’t trust software that tries hiding what its doing.
Well that’s not really an issue since it’s open and you can see what it’s doing anyway.
What turns me off is software that insists on running with unreasonable privileges. Rootless podman containers are the way to go – you can decide the privileges of the user account running the container, and the container image is inspectable (and tweakable if you find something you don’t like). And for the devs, maintaining (just) a container image is way less overhead than managing distribution-specific packages for 5 different package managers and dozens of distributions
Funny part is I’m responsible for some software which needs just a little privilege.
The direct install option runs as a broadly unprivileged user, thanks to systemd service for imparting one, surgical ambient capability to the process.
A team that wraps it in a container however demands it be run privileged, because they say the container runtimes dont support the same granularity, so the container users end up with unreasonable privileges while the direct install users are almost completely running unprivileged.