On Frenck’s website, it says this is how he runs HA ?
How I run Home Assistant
I run Home Assistant, which powers my home, on a custom build computer running Proxmox. In Proxmox, I have created a virtual machine running Linux (Debian Buster) for Home Assistant. I’ve used the Generic Linux Installer for Hass.io to install Home Assistant. Yes, I run the Hass.io Ecosystem.
There are several methods of installing Home Assistant, and really, there is no “best” way. Whatever somebody tells you, it is a personal choice. I love Hass.io as the way of running Home Assistant since it removes a lot of time wasted on system maintenance, allowing me to focus more on what matters: Automating my home.
will se what “made available differently” will be.
i used HA because of docker system, the alternative is to use an hypervisor to run hassos and waste resources? i really don’t know why of such decisions.
at the end of the day as long as its somewhere it should be ok. You can still use it.
No need to change what your doing, they never supported the installation method anyway
what kind of “support” are you refering about?
if supervised is removed from website installation method they may break it, one day or another.
And if someone want to use proxmox, esxi or any other hypervysor, fine…but maybe not every systems are made to have an hypervysor consume resources, while having a generic ubuntu OS with docker is much lighter than have an hypervysor + hassos for automations + os for other things.
I’m not quite sure what “made available differently” will be ?
Who edits/modifies the code (if not an HA dev) to get it in line with current developments ?
Who compiles it ?
Who updates that image on the web site ?
How will we know it’s changed (or do we assume a lockstep with HASSOS ? Will that be syncronised ? or will it be 2 weeks later ? or will it be … “Sometime” Later ???)
Hope they will not break this installation type. This was the only way I managed hass with addons to work on my intel stick, as I can’t get it to boot hassos any other way…
p.s. maybe “made available differently” will be https://developers.home-assistant.io/?
I sure nailed that one… 
it’s getting too easy to see these coming a mile away anymore.
Unfortunately it’s become the modus operandi of HA development.
Who edits/modifies the code (if not an HA dev) to get it in line with current developments ?
Who compiles it ?
Who updates that image on the web site ?
It has always been only one person, which is part of the issue.
Another part is user expectation/understanding. The images that are flashed to an SD include a minimal OS and Docker. When something breaks, issues can be tracked down. Everything is a known.
When something breaks on a “supervised” install there can be a dozen unknown reasons, most of them having to do with user choices or expectations: Watchtower is installed and being used to pull :latest. Portainer or docker commands are being used to start/stop containers instead of allowing the Supervisor container to do its job. Docker itself gets updated by a user, or the wrong version of Docker is installed to begin with. An Ubuntu update changes how networking or dns is handled. Users run the install script but without the correct permissions. Users are shocked when the “reboot host” command actually reboots the whole server and they expect it behave differently than exactly what it was made for. All of this ends up falling on the shoulders of one dev with no one else maintaining it. Meanwhile “how to’s” get passed around and Youtube videos are referenced (I’m guilty of such guides myself), making it simple to set up but not as simple to keep running, and OP of these tutorials is rarely the one users go to when there are problems. Instead they clutter the issues page on github.
There’s been plenty of “stop catering to noobs” when it comes to HA changes. Yet these guides pull in just as many if not more confused new users to the discord support channels and the forums. Many barely understand how to describe what they are running. And it isn’t even a matter of being a noob or an expert. Where they get confused is in understanding how HA is using docker and the supervisor’s role in managing everything. They aren’t familiar with how it ran on a SoC and jumped right into running it on the latest greatest Ubuntu which they installed for the first time ever.
This ecosystem was intended for a dedicated machine, but many users think it’s only a loose collection of containers which can be easily merged onto an existing platform and it simply is not so.
What else would they expect, if they want to reboot the docker, do that from the host (I’m actually agreeing with you here)
I’m not disagreeing with you here. I spent my life building industrial systems to be as reliable as possible and you don’t get that way by adding tinsel, KISS is the adage. Especially with something as important as home automation. For the price of a pi dedicated servers is the best option. NAS server does NAS stuff, LMS server does Music, HA server does…
I think your post puts things in context, but it doesn’t change things for me. A pi 4 won’t boot from ssd, when it does (rpf eft boot sorted) I may go back to hassos, until then … But if I move to a NUC… All bets are off. My problem is that I luuuuve hardware.
There’s a new command in the most recent version of HA OS I want to try which moves the /data partition to a connected drive. This is something that is highly requested and I’m eager to see how it works.
I love the move towards a standard image, it means bugs and bits can be easier to track down, which helps everyone and helps the move to a 1.0 release.
However I don’t like docker, it’s a centralised place controlled by one company (please do correct me if I’m wrong)
Don’t get me wrong I run the python virtual install and love the fact I can just do what every I want to the OS
docker version is there…it’s only supervised that is deprecated, supervised is like a layer or proxy, that controls addons, HA updates and other things.
p.s. deprecated doesn’t mean it’s not working or you have to switch now.
Looks like they underestimated the backlash on that one.
Personally, I found this to be a really helpful summary of the subtleties that motivated the initial decision. As a “generic Linux supervised install” user, I was blissfully ignorant of details like these, but getting an understanding of them has given me a good perspective on why this course of action was pursued.
Same here!
