Just wondering why anyone would go through the hassle of installing home assistant on Linux when the fantastic hassOS exists which will run perfectly virtualized.
Because we want to run more than just Home Assistant on the same OS?
Because traditionally OS and application layers were separated?
Because we trust mature Linux distros more when it comes to LTS and security patches?
Because we already know our way around Debian/Ubuntu/Nix/etc.?
Absolutely this. Once you get into the game of running apps at home with certain quality assumptions you end up having to bolt on various things (VPN, DNS, log aggregation etc) that are better wrapped around the application instead of having them run within it. And having an AppOS typically just gets in the way of all that plus what edejong said that you already know how to do it on the typical production OSes and learning to do it for every AppOS is just cumbersome.
Using Proxmox with lxc containers, there is no second kernel. It uses the host kernel’s native cgroups and namespaces for process isolation. You can actually achieve the same with just systems and namespaces.
Having said that, I think if you prefer traditional distro packaging, you should absolutely stick to that.
I'm aware of the tradeoffs here. For home assistant specifically, there's two options if you want to stay on the path of first-class support. Run it bare metal or in a VM.
Going a different path isn't a bad choice, or even a big downgrade.
I had fun with all the different ways of running home assistant 6+ years ago, and then decided to embrace a solution that required the least fuss and would hold up long term. I'm happy with my choice, and it gave me exactly what I was expecting.
I'm also running dozens of things alongside HA and I don't have to use proxmox.
It's not hard to run HA in unsupported mode. The only real difference is an annoying reminder that you're unsupported. Everything else works, including plugins/add-ons.
I've run HA a bunch of ways. It doesn't really matter all that much. Use HACS to fill any gaps.
One-click updates work from the dashboard? I don't think they would.
Of course you don't have to go the proxmox route, but it is an easy route.
I have a proxmox cluster, so moving things between machines, high availability, and backups are a breeze. Had an SSD go bad a few months ago, and I just moved everything on that machine to another node until the new drive showed up. It was a pleasant experience.
There's plenty of other ways to achieve this, but this is what I chose and I'm happy with it. It's simple, and I can manage everything from my phone if needed.
Yes, one click updates work just fine. The only difference is the unsupported message which only appears after reboots or an update. Click ignore and it goes away.
I used to use Home Assistant via Docker, but I've since switched to Proxmox with HAOS in a VM and a second Debian VM for everything else. My main reason for this is that it seems like the more supported scenario. For example, when the Voice Assistant stuff first came out the setup was only really documented via HAOS add-ons. I managed to get it working with standalone Docker containers but it was a pain to figure out. It really is simpler to just use HAOS IMO.
As was already mentioned, people rarely want to run a dedicated physical server for just a single purpose. The concept of Home Assistant Operating System requires exactly that.
Also, it is Debian-based. It uses the `apt` package manager which is slow. Some people may prefer something faster and more modern, like `pacman` or `dnf`.
> run perfectly virtualized
Fair enough.
But that obviously requires virtualization being set up on the server. If people do not use virtualization for anything else on their server, they may as well set up Home Assistant directly.
Finally, I think there is one more issue.
Many of the integrations which are possible with Home Assistant Operating System require physical hardware being connected to that server. A reader, a receiver, something like that.
But these home servers are often placed in some inaccessible locations, like an attic, where the data from sensors is unavailable. It may be impractical to run cables there. And the wireless devices may be too far away for a receiver located there to be able to read them.
So people need to come up with work-arounds to get their data to their server. They set up various signal proxies and thin clients which receive the data from the sensors on the spot where they are available and then send them over network to the Home Assistant server.
Unfortunately, from my experience, many integrations completely ignore this usecase. They are likely focusing on a happy path where everything is connected locally to "the one" server. And only then they behave nicely and work out of the box. But as soon as you need any special step or behavior, it is necessary to dig deeper and create custom layers to transport the data from your devices to the server.
Home Assistant Operating System does not make any of that simpler. Perhaps on the contrary, it forces you to use a specific Debian-based distribution with possibly outdated packages that you cannot easily upgrade without breaking Home Assistant.
Which is why it makes little sense to bother with it, in my opinion, for these kind of installations.
> Also, it is Debian-based. It uses the `apt` package manager which is slow. Some people may prefer something faster and more modern, like `pacman` or `dnf`.
Do people really care if it takes 5 seconds to parse a package index vs 1? I don't get this argument at all.
Yes, you are right. There is one more abstraction layer.
Home Assistant Operating System uses Buildroot which uses Docker to run container with Home Assistant Supervisor. And only that container is Debian-based [0].
A couple weeks ago I powered a laptop that had been sitting unused for several months. It had Ubuntu 22.04 installed. The initial `apt-get update` took some time to download new indexes, and almost 3 minutes to process them all afterwards, while I was right there staring at the screen wondering why I was there staring at the screen for so long, because this experience always happens as soon as any of my machines stay off for more than a couple weeks. apt is indeed very slow.
I just installed python3 on Debian and Alpine. It takes 16s vs 4s (I ran the test three times, and kept the fastest measurement for Debian and the slowest measurement for Alpine).
Sure a one-time wait of 12s doesn't change my life. But I won't use apt/apk _once_; I'll use it every single time that I install something. It low-key bothers me when my flow is interrupted by having to wait for machines to do their job, increasing that by 300% doesn't help.
This wouldn't be a deciding factor for me. But it doesn't add points for the Debian-based approach.
