Can we have an estimation when we will get the final dissicion? Will it be a few days or a month for example
Thanks
What I don’t understand is the architectural choice to do supervisor as distinct from just docker containers. What I mean by that is that given a need to continue to support pure docker setups, why not architect the additional supervisor stuff to be fully compatible with that. I understand the general statement that one can install HA core in docker and then install all the add-ons from their native locations but that requires the user to figure out how to make the relevant connections between the containers which to my searches is not documented anywhere. I run HA Core on Docker but was considering moving to supervised so that I could get VSCode to work. I searched pretty diligently for how to get that via pure Docker but couldn’t find it (and I far from a newbie, having spent nearly 50 years in software). I am fully competent about running my own system - I just don’t want to have to do explorative searches every time some possibly useful new add-on gets identified. Supervisor and the addon stuff should be architected to be compatible with pure Docker installs such that the differences between Supervised and Docker Core go away.
Sorry, wasn’t my intent to demand an answer… I’ll remove it.
My point was mostly that I even don’t understand in what category my own install falls.
Hassos/Supervisor/core/docker/…
It’s really not that easy to understand.
So I have (I think)
[NUC Hardware] => Ubuntu => Docker => HassOS => (=> again docker???) Hassio (=> And addons?)
And I understand the Ubuntu & Docker part need to be removed? (But what about all the different hardware options and possible driver issues)
So apart from the " no to we’ll get back to you" can anyone explain this to me? I try to learn also of couse.
Thanks a lot!
I fairly new to Home Assistant and I guess I am in the minority but I am in support for deprecating the supervisor on a generic install and I think the team did a good job on illustrating the reasons why.
When I first started trying to use HA it wasn’t very clear to me on the differences between Home Assistant, Home Assistant Core, and Supervised Home Assistant. (I think that the majority of the confusion is “Home Assistant” is both the name of service/server as well as the bundled OS). I wanted to run on a NUC running Fedora (so all my automation worked the same way across all my servers) and the documentation made Home Assistant Core sound undesirable (I have learned this is actually what i wanted) and getting Supervised Home Assistant working with podman wasn’t worth it.
Fast forward, I installed HA on a Rpi4, learned a lot of the terminology and how Supervisor, OS, etc all work together and am ready to go back and run Home Assistant Core on a NUC with Fedora/Podman and think this makes the most sense.
What would be nice is for any add-on is if there is good documentation and maybe even “blessed” docker images that would work to just enable or upgrade components allowing for both users to choose their own distro/hardware but get some of the benefits of the complete solution.
If you say you installed Ubuntu and you see a “Supervisor” option in the main menu, then you have installed Home Assistant Supervised on generic Linux.
If you installed Ubuntu and don’t see the “Supervisor” option then you are running Home Assistant Core.
An alternative maybe could be give a kind of setup, where you choose if enable supervisor things ( addons, backup&restore etc etc ) or have plain home assistant, in a way to handle who want addons and who want pure home assistant but having docker under the hood.
That would be a minority opinion because even Paulus himself apologized for the poor communication.
There’s that and the fact a sufficient number of users opposed the deprecation to cause it be put on hold. Basically, they miscalculated its prevelance and popularity.
Nevertheless, it doesn’t change the fact they are short of resources and something has to change. Either volunteers are found to help out or it will be deprecated as originally planned.
Same with me…
Most of the time I am ignored or told that I am not behaving correctly toward core developers, how can be equally mean and dismissing …
I complied about yaml, as configuration template, as it is crap, and even offered to work oin moving this to json or INI key=value pair.
Shutdown, without any reasonable explanation.
Now I am seeing that linux will be dropped, and I do support project via paying for cloud bridge.
I am hoping that linux stays, as I am not interested in topping excellent kernel with another one (docker) and dealing with yet another os.
Please point out to what are the reasons to drop linux generic installation… I did not find anything on this…
That would be a minority opinion because even Paulus himself apologized for the poor communication.
Communication and a proper deprecation plan could have used some work but, for me, the reasoning is fairly sound from a technical point-of-view.
Really there should be two solutions (and which i think was proposed but again maybe without the clearest in communication). Managed OS or non-managed OS. The in-between of supervised adds way to many different variables and supporting even with a fully staffed/employed team is still very difficult if not impossible to support every distro, every version of docker (or podman), every other tool that wants to manage containers, etc.
So the question then is, how do you bring your own hardware and have a managed os. Perhaps Virtual Machines, the solution proposed in the blog, isn’t for everyone but there is a single distro that is blessed that can run supervisor + HA in a good way and leave the “choose your own distro” out.
managed OS and non managed OS…but both with all features or one full featured and one lame?
Because with deprecated supervised installation you end up without addons, backup&restore etc etc…why should i lost it if can’t afford to use hassOS?
Why should i lost it if previously there?
Why not give that for both installations?
There was a long explanation describing the complexity of maintaining the software followed by this:
Sadly after 3,5 years, there are still no other contributors to help. This has resulted in his responsibilities outgrowing what one can expect from a full-time employee.
Followed by the decision to terminate official support for it immediately.
As others have already mentioned, the short-staffing situation should have been brought to the attention of the community before it got so dire that the developer’s health was affected. A call for volunteers could have relieved the burden. If none were found, the reason to deprecate would be very compelling. That’s what you normally do in a community-run project.
Instead, the communication was delivered as a foregone conclusion without consulting the community. That rubbed many people the wrong way, to the point where the decision was suspended for further review.
Nothing is going to happen in a few days. I’d guess a month at least. I will also guess that Debian would be a good choice right now if you want to start or continue a generic linux install.
not everyone are developers, many are just more expert than average but can’t afford it, by time, by knowledge etc etc.
If it’s a matter of hire someone to develop, they could request a fund, maybe?
It’s just an idea like many others here.
You have either Ubuntu as your operating System, or HassOS as your Operating System. Not both. (That’s what the “OS” stands for).
Firstly, they only officially supported Debian and Ubuntu and not every distro. Even though it worked on Raspbian (a variation of Debian) they hesitated to officially bless it.
Secondly, users have found the arrangement to be stable and trouble-free. So it’s unclear why it’s alleged to be a source of complaints. Perhaps they should have cited a few cases where it proved to be the root cause.
Thirdly, tools to manage containers aren’t likely to damage anything unless misused by an end-user. Frankly, you can do extensive damage with the existing, officially supported Portainer Add-On.
managed OS and non managed OS…but both with all features or one full featured and one lame?
Supervisor is really for managing containers (HA and others) and doing some basic OS changes. This is a managed OS.
Supervisor running on a “generic linux” means you are trying to manage an every docker install on a every distribution with tons of variables.
The “lame” you talk about is still possible you just actually need to issue some linux commands to make it happen. This can be solved through good documentation and is easier for it to be maintained by the community then some fancy gui.
If Want the fancy gui for managing your containers/OS? Use fully tested distribution system (today offered in some specific hardware images) which tests/bundles the distro with the system trying to manage that distro (supervisord)
There is no conspiracy to take away features that aren’t justified and continuing to claim that “it’s just the core devs wanted to ship a “lame” system” isn’t helping here.
Why should i lost it if previously there?
Maintaining the system takes a lot of resources (i.e people) to make sure it works. It is much easier to either
a) test/develop/ship a complete system (OS and all) as either hardware or VM images
b) Allow for power users to be able to install their own OS/distro and then also allow them to manage their own containers/OS.
The in-between of trying to run your own OS and then also have a supervisor try to manage it is madness. Companies with fully paid developers don’t even do this because the cost of support every time your distro changes a default option, or docker changes some behavior, or (in my case) your distro uses podman and not docker with docker command aliased to podman. That level of customization is EXTREMELY hard to do without round the clock testing (usually manual and by humans).
This leaves for a “middle ground” that is going to be broken. HA doesn’t want to ship a feature that has a tendency to break and you would be just as mad, if not more angry if the feature was broken then removed.
Why not give that for both installations?
See above for the detailed answer. I think some sort of blessed/tested distribution (lets say a version of debian) that is allowed to run supervised HA is probably the best mix between a stable OS / software designed to managed that OS.
What i think is important here is to not demonize the developers of HA. They are literally building some of the most advanced home automation software available and giving it away completely for free. Removal of Supervised Home Assistant on generic linux probably wasn’t taken lightly and the alternatives aren’t nearly as bad as you are making them out to be.
Thanks! I am with ubuntu 18.4. Should I remove it and install debian?