It is both.
Home Assistant created an OS for appliance like installations.
But there is also the docker images, repo packages (I know Arch Linux has it in the repo) and pip based packages too.
I installed it on my home Ubuntu server many years ago. Every now and then I get notification in HA, that my OS is unsupported. And if I want to update HA, add-ons or Supervisor, I can’t, because “Docker is misconfigured” - I have Portainer installed. In order.to update, I have to stop Portainer and restart HA Supervisor. HA itself works, but sometimes I don’t get it. Especially the Portainer bit.
For some reason, on Ubuntu, the Supervisor container loses its “privileged” status. I’m not sure if it periodically restarts itself or something , but that also was happening to me.
I moved my setup to Debian 12, did a fresh Supervised install, and then restored a full backup from my Ubuntu instance and I haven’t had this issue since.
docker images
Is not distro packages.
Arch Linux
It’s not in Debian. There’s no Red Hat packages either. Or OpenSUSE. It’s not even in OpenWrt which would make the most sense. So it looks like no useful, practical distro packages.
pip
Is not distro packages.
You didn’t mention in your OP that it had to be debian distro packages. I just gave examples of HA being packaged in other ways than a complete OS.
I could have said: “If you want to run HA from packages, you need to install Arch!” But I didn’t. Chill out.
A lot of software isn’t packaged for Debian. Especially complex ones and webapplications tend to be Docker containers or something like that. Home Assistant has a lot of Python dependencies which are a chore to maintain the Debian way. Same probably applies to some other distros. I mean it can be done, as Arch and NixOS show…
And you have Docker, you can install HA core in a Python virtual environment on any distro, or install Supervised, or the appliance (OS).
So there are many ways to install it. And I have the same complaint for other software. For example I’d like Nextcloud and a few other collaboration services to be available as distro packages. Sadly they aren’t available like that.
A lot of software isn’t packaged for Debian.
Yes, often projects which are engineered without distros in mind. Which is to say, engineered poorly.
Home Assistant has a lot of moving parts, all the add-ons and extra user stuff. So they provide a docker image with everything you need, they also provide a full appliance install for easy setup.
If you did all that as a package install, you would complain about all the dependancies and if you didnt install the right version of something Home Assistant might not work at all
Do you have some links to read up on that? I saw the Nix stuff. And the Home Assistant devs seem pretty alright to me. Sometimes they make decisions which I don’t understand. But I’d like to know what kind of internet drama surrounds this…
This isn’t the very beginning, but a lot of the discussion can be read here - https://community.home-assistant.io/t/consider-to-avoid-adding-library-dependencies-from-frenck/315185
He alone has behaved like a child, dragging his end users along with him in his over-reliance on one failure point for his entire distribution system
Yeah, this is exactly as expected. Someone with poor engineering skills finding themselves in a position of power and making sure everyone knows they’re king of the hill. See this kind of thing all the time unfortunately :-(
all the add-ons and extra user stuff
You’re hand-waving the answer to my question :-) What add-ons and extra user stuff require Home Assistant to be an OS?
If you did all that as a package install, you would complain about all the dependancies and if you didnt install the right version of something Home Assistant might not work at all
That’s not how packages work. The packagers take care of all that. That’s the point.
Before I understood Docker, I used to have HA installed directly on bare metal side by side with other “desktop” apps.
To be able to access devices, HA needs many different OS-level configurations (users, startup, binding serial ports, and much more I don’t have a clue about). It was a giant mess. The bare OS configuration was polluted with HA configurations. Worse, on updating HA, not only did these configurations change, the installation of HA changed enough that every update would break HA and even the bare OS would break in some ways because of configuration conflicts.
Could this be managed properly through long term migration? Yeah, probably, but this is probably a ton of work, for which a purpose-built solution already exists: Docker. Between that and the extra layer of security afforded by dedicating an OS to HA (bare metal or virtualized), discouraging the installation of HA in a non-dedicated environment was a no brainer.
What do you mean with “Operating System”?
It is most often installed as Docker container, which isn’t an OS, but just includes all dependencies to run. You still need an OS (like Debian) as host.
SystemHome Assistant OS, the Home Assistant Operating System, is an embedded, minimalistic, operating system designed to run the Home Assistant ecosystem. It is the recommended installation method for most users.
What do you mean with “Operating System”?
If I go to
https://www.home-assistant.io/
and click on “Installation”, ignoring the custom Home Assistant hardware, the first relevant section is “DIY with Raspberry Pi” whose tutorial has a section “Install Home Assistant Operating System”.
The second relevant section of the Installation page is “Install on other hardware” with a paragraph whose second sentence is “The Home Assistant Operating System allows you to install Home Assistant on these devices even if you have little to no Linux experience.”
It’s most often installed as HAOS, which is a dedicated operating system that just runs Home Assistant. That is how anyone installing it on say, a Raspberry Pi, is likely to do it.
Home Assistant as a project is far more popular than every single other consumer focused server and as such it is often the first home server (and sometimes only) that many consumers will experience.
You should ask this to your favourite distro packagers, not to the home assistant developers.
In any case, it is such a mess of dependencies due to load of optional packages, very active development, that continuously break dependencies on the package repo.
What advantage would bring have a most of the time obsolete distro specific repo? On a maintainer POV this is the typical use case for distro agnostic deployment, maybe flatpak, maybe docker.
You should ask this to your favourite distro packagers, not to the home assistant developers.
I disagree. The Home Assistant developers are the ones who chose to create an OS. They could have chosen to create distro packages instead, or at least software which is amenable to being packaged by distros.
obsolete
What does that mean in the context of Home Assistant?
It comes down to what are the developers willing or able to support.
For smaller teams they usually don’t want the responsibility of maintaining the package for distros, and HA developers have chosen to not support that option themselves. In their case I see it - what’s the benefit or incentive to them to maintain packages and the associated support costs or headaches. Containers mean they get a known state and don’t have to try to support unknown environments.
Some interested people can maintain the packages for their chosen distro - for instance I see one for Gentoo but it’s only up to 2024.6. It’s the first that came up in a search but there are likely more too supported by the community.
In my case, I also think that using HAOS on a dedicated box has led to a more stable experience as it’s not competing for resources on my other hosts, and attaching devices to it is much simpler. I think encouraging a solid base for people means a better experience overall when to be honest it’s hard to get started with it to begin with for many people.
It seems to me they chose to provide a platform that vastly simplifies the installation of their software and maintenance of its code from a debugging standpoint. This seems perfectly reasonable. This appears to bother a particular community who feel entitled enough to demand multiple developers cater to their distribution’s needs. Shit needs to stop.
This appears to bother a particular community who feel entitled enough to demand multiple developers cater to their distribution’s needs.
Your reading of the situation is wrong.
Since HA depends on a lot of python packages, on external softwares and libraries it could not feasible to ensure that the versions packaged with the distribution will always be in line with those needed by HA
