If Pascal needs support from community on Supervisor, then let’s help the man. i feel bad for the guy and he should not compromise his health or anything close to that for any projects including HA.
There is plenty of good Python devs here, I am one of them and I can if needed help on this.
Canceling whole linux generic installation, to me is really, really bad thing, as you are not allowing a bigger open source community to drive project.
If that is the case, then say it load that this product is not anymore open but ratter proprietary and please don’t tell us that docker is mature product that you will be able to utilize better than linux os for purpose of HA.
You are trying to replace dependency of one product linux to multiple dependencies, linux + docker with many more points of failures confusion and simply crappy experience.
There are folks like me in this community that setup large installations of HA and now we need to figure out ether to fork a projects and start maintenance and development on our own or totally abandon project and go to alternate solution.
Sad …
Well I mean you do collect some data right? Like by default the updater component is enabled with reporting set to true and include_used_components set to false. And I remember in one of the episodes of the home assistant podcast you pulled up the numbers from that to show just how high the percentage was of users on Pis compared to other deployments.
I think what might help here is if you published more of that data. A big part of the concern here is clearly communication and I think a good chunk of that is not enough insight into why. Like I assume part of the reason Pascal has been working overtime on this is because not only is it particularly complicated but the data you have on ‘percentage of users with a Home Assistant Supervised on generic Linux type installation’ is not high enough to warrant allocating another full-time developer to it. Or perhaps not cost effective given the return on investment to Nabu Casa from people with that type of installtion vs. other types.
This kind of data would really help to explain to people the situation and understand the reasoning behind your decisions. Also if people saw exactly what data was being collected and how it was being used they’d probably be more willing to turn on the reporting features in updater so you could get more accurate data for decisions. I know there’s lots of people that immediately disable reporting features like that in products they use but I think people would change that if you showed:
That the data was actively being used for resource and priority decisions that mattered to them
That the data was completely open and clearly anonymous
Anyway just my two cents. I’m personally running Home Assistant on a Pi 4 so my installation isn’t being deprecated. But I don’t like seeing the kind of anger and animosity raised in the responses to this post (as well as the previous YAML one). I think coupling these kinds of major decision announcements with more openness around the data driving said decisions would really help.
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.
That is fair, but even the images for Raspberry Pi are very customized to make it work.
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.
It takes work to make that happen year after year. What works today won’t continue working tomorrow. 15 years managing linux systems has taught me that.
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.
Support and maintence of a project != allowing users to do damage. I never stated and i never meant to imply anywhere that this is about controlling damage. It’s about shipping code that works and continues to work.
I just have to respond to the suggestion that having custom “device”-like OS doesn’t mean you can’t have the ability to add other software. Hassos could have a packaging system. It chooses not to. If that choice had been different, much of this whole damn saga may have been avoided.
I believe you may have misunderstood my point. They claimed Supervised on generic was the cause of Home Assistant stability complaints yet that comes as a surprise to users. The alleged instability, and the efforts to correct it, were reported to be too much effort. However, few users have experienced this variation as being the root cause. There’s a disconnect between the reported culprit and what people have observed.
not really, containers are not integrated in HA UI like supervised does: if i want to use a particular addons ( container ) because it needs for my HA setup, it’s handy have it in home assistant UI and control from that UI.
Who talked about conspiracy?
The alternative is to install an hypervisor, a dedicated VM for HA + a VM for everything else, while as of today it’s all working on your own OS, not wasting resources or abilities ( many sbc or nuc are not powerful enough for managing an hypervisor + VMs, not everyone have server grade HW for home, lol ).
And that ( hypervisor ) i don’t see it as an alternative but a regeression.
As i said, it’s all about alternatives: there is none if we want to use the light way but full featured. Like we have now.
And it’s not an alternative to buy new HW, spend hours/days to rebuild everything out of a way faster decision to break a feature many people use.
You missed a point: it was an official installation method like the other,
I don’t know what are you talking about: no one demonized HA team, we are just pointing our view. Someone saw the Moon, someone the finger. That’s all.
As of now it’s not removed and i hope it will not.
If for you afford new HW, time and other sh*t to have the same setup as before is “not bad”, than i’m happy for you.
Different point of view, as always, deal. I don’t have to justify my mind
It takes work to make that happen year after year. What works today won’t continue working tomorrow. 15 years managing linux systems has taught me that.
Funny, what is alternative - docker or anything else does not need managing?!
Between Linux and docker you will have more managing to do on docker side then Linux. I do not understand how someone can’t see that. Docker depends on OS system changes has crappy logging facilities and it is not mature …
And really, please anyone give me an example of anything from HA bringing down linux kernel …
If that is the case than something is seriously wrong with the product …
I managed just about any *nix distribution for about 30 years + developed on it…
So I have the “Supervisor” option, that’s already half good
I think my confusion comes from my RPI install there I saw HassOS, and indeed my production environment states " Ubuntu 18.04.4 LTS"
They could but it raises the question of how this project is governed. What started as a non-profit community-run project has morphed into a product managed by paid employees of Nabu Casa.
Nabu Casa sells a remote-access service exclusively for Home Assistant. The sales of this service raise enough money to operate the service and to support the employees who also build and direct the construction of Home Assistant.
It’s a complex relationship. There is a financial incentive to make Home Assistant accessible to a wider audience because they are likely to purchase Nabu Casa’s services. Nabu Casa benefits and so does the community because Nabu Casa can grow and continue to improve Home Assistant.
The flip side is that control of Home Assistant’s direction slips away from the community. Nabu Casa must walk a fine line, balancing the needs of expanding its market yet not alienating its established base (which produces the majority of all integrations and most of the technical support).
Knowing all this, they can certainly ask for more people to subscribe to their services and you can do what some do, namely convert it into a donation by not actually using the service. However, do that with the understanding of the bargain you are striking with a private company.
May I ask. Right now I have installed HA supervisor in docker with this [guide] on Intel nuc. (https://drive.google.com/drive/u/0/mobile/folders/1oKhnQ1rz-Yd5HheA8rNk5YNq8e67-5Kh)
What are the steps if I would like to replace ubuntu with debian?
Can I just format my Nuc install debian and just follow the same instructions?if yes how I can format it?
The answer is yes and during the installation of Debian it will detect the state of your disk and offer several options where one of them is to format your disk and perform a fresh installation.
I ran that way for a long time, but when it came time to move to a new version of python, I got stuck in dependency hell. That is when I tried Hassio (or what ever it was called at the time) and was very pleasantly surprised.
I recently upgraded from a Raspberry Pi 3 to a NUC (J5005 Pentium Silver). Went with a supervised install on Ubuntu 20.04 Server and it was rock solid and fast. First time I’ve ever been really pleased with evrything for HA. I then saw this announcement and because of my OCD, went straight for an install of Ubuntu with Desktop and VirtualBox. HA works fine but performance is not so good and looking at my performance statistics, I’m using a LOT of resource on my NUC. Before I was using hardly anything. Seems like a backward step to me. Surely Home Assistant is a ‘hub’ of sorts. People want to use something reliable, but not too expensive. Therefore a SBC is not a great option long term and an i5 is really too expensive for a ‘hub’! I plan to go back to a supervised install on my NUC, so I hope that this is a supported option going forwards… Please, I love Home Assistant but can’t afford expensive servers to run it!
The Portainer add-on is not an official add-on and thus not supported by Home Assistant itself.
It is an add-on in the community add-ons repo, which is my personal side project.
Thank you; I stand corrected. It’s not part of the officially supported Add-Ons.
I’d like to add that its description provides fair warning regarding its ability to damage the system. Plus it has a rating of 1 indicating the Add-On has the highest degree of access to the system. Thank you for ensuring people are aware of the tool’s “sharpness”.
Me. My main machine is a NUC but I got one of those cheapie XCY’s from alibaba or similar and without thinking I specified nuc as the machine type and it runs perfectly. So I never bothered reinstalling it.
The install for debian is simple, but be sure to look up how to use the keyboard to manipulate the installation menus. Read this to figure for all the keyboard combinations. I recommend buster without the graphical install. You also need to keep in mind that debian is bare bones. For example, I didn’t bother installing any of the wifi libraries that are requested during install because I’m hard wired to my network. Once you’re up and running, it’ll just be terminal. Then lastly, there is about 5 commands that need to be executed for the install. Unfortunately I don’t have them memorized and they are already removed from the docs.
