Home Assistant deprecates the "core" and "supervised" installation modes

That's spot on but misses the point of why I generally prefer Supervised in the first place!

An "elderly" laptop has a battery (built in UPS), a few USB interfaces and is generally capable of being optimised for a bit of power sippin'. You don't have to fire up the GPU unless you want to. With a SSD, you've got a pretty decent platform that can be powerful if needed but also quite modest, powerwise too.

OK that is still valid for HAOS. However HAOS is a cut down distro with no frills so you can't run anything else that is not already covered with a blessed HA container: "addon".

I run quite a few out of band things such as SMS daemons which are so uncool but so useful to my customers and me too.

It's all very well trying to reduce the support load but I don't need any guarantees. I'd just like some understanding. The last deprecation effort shoved a middle finger to Debian derivatives (Ubuntu) OK, I got it and rolled with it. Fairly major re-installations efforts done.

Now you are telling me I have to do all that again. Well, thank you very much. Is this the last one? It won't even be classed as a breaking change for the project but it will fuck over quite a few implementations.

I will roll with it all again because I have to but it isn't a good look and I don't see why it is necessary this time.

Do you need 2 GiB of RAM to monitor the house?

The reason you want more than enough RAM isn't that you can't set up a usable system with less, one of my test systems runs perfectly well in a 400MB VM. The reason is that if there's even a hint of memory pressure, the system might need to swap something in when you hit a light switch. Few things in a home automation setup are more annoying to the users, esp. the not-computer-savvy ones, than random delays.

The HA has a rule that integrations should not have any device interaction logic inside them, they should farm it out to a library. That's where most of 600 dependencies come from.

This makes it easier to develop device integrations, and forces a clean separation between device handlers and HA core logic.

Those 600 deps mean that HA uses existing and hopefully-tested-on-actual-hardware Python libraries to talk to $THING, which can be stubbed out for unit testing rather easily, instead of re-inventing 200 wheels that can't be tested without the actual hardware.

You can do that just fine with HA and containers. Have the HA run on a port like 8080, and set up your frontend webserver/proxy to redirect everything for the '/ha/*' path to that port.

HA itself works fine with URLs that are not rooted, I believe you just need to set the `external_url` property in the YAML config for that.

Amen, brother.

> I also don't want a specialized VM (which is what I'm currently using because ... no other viable choice),

I'm using a simple venv, and a startup script that activates it and then starts the HA that's been pip-install'd into it. Works perfectly fine. So I wonder what do you need the VM for?

It's not at all easy to replace that module there. In a "real" installation you can just update the requirements file with the version# with the bugfix and restart HomeAssistant.

That being said, this is for end users. A user won't muck about with Docker images, but then they wouldn't know how to edit their Supervised installation either (not without messing it up anyway). The user files the bug, somebody else notifies upstream with a fix, and you get that in the next regular update.

Actually *running* HA in Supervised mode will continue to work because they (and we) need that mode for development and testing. It'll just not be end-user-supported by them. After all, you can't rebuild a Docker image or re-provide+-boot your appliance every time you fix a typo, that'd take much too long.