This seems reasonable to me?
If you’re running it that way you still can, they’re just not going to accept bug reports or have end user docs anymore. All the developer docs will still cover it.
It’s an open source project and they need to focus their energy on known good configs.
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
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.
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.
Fortunately:
No support for Core or Supervised—can I still use them?
You can still use them even if we no longer support them. There are many users running Home Assistant in all kinds of unofficial ways. This change just means we are removing it from our end-user documentation and will no longer recommend using these installation methods from an official standpoint.
Will the developer documentation on these things remain?
Yes, those will remain. The developer documentation for running Home Assistant’s Core Python application directly in a Python virtual environment will remain. This is how we develop. This proposal is about removing end-user documentation and support.
I’m on supervised install on Ubuntu server. All worked fine for many years, except Supervisor being bitchy about me having Portainer installed for no reason. Last week or so, my machine started acting weird. After reboot I couldn’t access it via local ip, only via external hostname. What keeps happening is after reboot Supervisor creates new network config for my ethernet, that causes this. It uses the network-manager to do this. I have netplan doing the config. Nyone else?
Wait, does this mean they’re deprecating the docker image?
Nope. Docker and Home Assistant OS will be the only supported installation strategies
We have deprecated […] Home Assistant’s Supervised installation method, which involves running your own operating system, then installing the Supervisor and other requirements on top of that.
Tell us you can’t architect software like a first-year without using those words. Proper packaging has been out for 30 years.
My foray into self-hosted home automation was set to begin, but if they can’t release software like adults then fuc–uh, good luck to them.