[mindslight]

Right up until the Home Assistant UI turns into a lagfest, the installation dies, and you can't debug why because Docker. At least that's what happened to me. And no, it wasn't RPi SD power issues. This happened on an otherwise-stable amd64 server.

The Home Assistant authors' hostility towards simple native distributions is now a show stopper for me. Long term reliability is more important than quick initial setup.

[cyberax]

HA is actually pretty debuggable. Just install the SSH plugin, then SSH into the HA box, and then simply "docker exec" into the target HA container.

[mindslight]

... and then not have any of your usual development tools, environment, system layout, or repair techniques because you're inside someone else's "works on my system" that they threw over the wall.

It's obviously possible to debug what goes on inside a Docker image. It's just not something I'm particularly interested in dealing with, especially under duress.

[cyberax]

> ... and then not have any of your usual development tools, environment, system layout, or repair techniques because you're inside someone else's "works on my system" that they threw over the wall.

The thing is, the "it works" is reproducible because of containers. Which is a step above just hoping that it works.

HA is also easy to "patch". You can just install your custom components in `config/custom_components`, it can also be used to "override" core HA files.

Finally, if you are doing intrusive development, you can easily launch HA locally. macOS, Linux, and WSL are supported. You will lose the ability to install add-ons via the addon manager, but that's about it.

FWIW, I had the same aversion to their custom OS and their crazy container-based setup initially. For a couple of years, I used to run HA as a Python app and managed the dependencies manually. Then I tried the HAOS and it... kinda just worked.

[TeMPOraL]

> because you're inside someone else's "works on my system" that they threw over the wall.

FWIW, this can also be called stable state you can retreat to. And build upon, e.g. adding a layer of debugging tools.

I don't really like to deal with Docker, but at least I have reasonable certainty it'll work. I prefer system package manager or MSI, but if not that, it beats having to build something when it's near-guaranteed that what I'll get is not the binary the authors had in mind, if it even runs at all.

(Then again, I routinely rebuild Emacs to stay on the bleeding edge. But it took a while to work out all the usual dependency mess, and I even broke my system once doing it.)

[mindslight]

It's certainly within my gamut to jump into an embedded system to debug it, bringing/building tools as I go. I'm just not looking to opt into doing that on something that doesn't need to be that complex in the first place. Same reason I run one decently powerful amd64 server that does many things rather than a stack of Raspberry Pis, one per software package.

[cyberax]

But how would you do it differently?

You need to host a bunch of daemons (MQTT, ZWave and ZigBee bridges, and whatever else you might need). And a bunch of these daemons can have their own gnarly dependencies (e.g. they can be written in JS and built with NPM, ugh).

So you kinda _need_ to use Docker to make it at least sane.

And if you're using Docker for the plugins, then why not use it for the HA core itself?

And once you do that, you don't really need much from the host system. So why not use a minimalistic OS instead of something like Debian?

[mindslight]

At the time my setup didn't require other daemons like that. But if I had been in that position, I would have just set up the other daemon under Debian and pointed HA at it.

These days I'd say that NixOS captures that requirement, allowing orchestration of many daemons and other system config to be abstracted into a packaged solution (eg NixOS Mailserver), that the user can override as much or as little as they'd like.

I believe NixOS does package (or at least attempts to package) HA, but given my past experience and what I believe is still the throw-it-over-the-wall desire of the HA maintainers, I'm wary of adopting it as an overarching solution. I'm certainly not ruling it out for performing some functions, like UI. I just would rather set up my automation efforts as MQTT-first, keep logging and automation rules as their own separate things, and not be fully committed to HA.

[baq]

It's a Python app, of course being distributed as a docker image is the sanest way of doing it. I don't see why you couldn't just pip install it if you really wanted, but having been a Python developer for close to two decades, I wouldn't want to.

[Izkata]

That was the standard way a long time ago, and the first startup would take a really long time because it would install even more stuff. And sometimes fail. It wasn't very reliable if you used any addons, and some required a ton of extra steps that it couldn't automate like the modern deployments do now.

[mindslight]

I'm talking about distribution package managers, not pip.

[darkwater]

I happily ran a dockerized HA on a Debian for years now, no need to do any complicated debugging (and even if I did, it would not be difficult to inspect it properly)

[mindslight]

Dockerized HA on Debian is exactly what died on me. About 5-6 years ago. I'm sure it works just fine for most people. Just once bitten, twice shy.

[tw04]

Nobody is preventing you from running Home Assistant core and deploying everything else yourself manually.

Demanding the authors who gave you the software for free also provide support for an installation method they've offered up with no support is a bit ridiculous, don't you think?

That attitude is what causes open source projects to die though...

[mindslight]

What do you mean "demanding support" ? I remember Home Assistant authors being actively hostile to people packaging their software outside of the official Docker or RPi images. Which is why it wasn't in the Debian repository, pushing me down that Docker path in the first place. Here's the same dynamic on an associated project in 2021: https://github.com/NixOS/nixpkgs/pull/126326

If anyone chimes in and says they've been running Home Assistant from nixpkgs (where I am now) for several years with no hiccups, then I will certainly reconsider my opinion. But based on my experience and what I've continued to read since, it feels like trying to do that is an uphill battle. One I'm not looking to take on, especially for automation I'm relying on.

[tw04]

So... your example is a developer of HA stating that he sees major flaws with how they're distributing his package, and that he has absolutely no interest in supporting users that pull his code in a way that is unmaintainable by him.

YOU believe he should support this anyway, because of various "we promise end-users won't reach out to you" which is comically incorrect because history has shown repeatedly that a user's first step when something is broken is to google package_name broken - which will absolutely turn up the author's name.

BECAUSE he doesn't want to support his software being repackaged in a way he believes isn't supportable, you're upset. You want him to support your unicorn config because that's what you want to do, and his refusal to comply makes him a bad person.

Thank you for reinforcing EXACTLY why open source devs burn out. He has a workflow that he is willing and able to support and doesn't want to support anything outside of that. Your response is: but you need to do it for me because it's what I want.

[mindslight]

Did we read the same thread? Nobody asked the HA developer to support anything, rather that developer started the conversation by making demands and then kept at it.

[tw04]

“Making demands” which were: please don’t package my code in your distro that has dozens of out of date packages my code depends on that will break. Because I don’t want to deal with end users bugging me about it being broken.

I think the most surprising thing is that you can’t see how unreasonable your complaints are.

[mindslight]

If you attempted explaining how you think my stated position is unreasonable, perhaps I could see it. So far you've only attacked strawmen, such as claiming that I am demanding support from HA or claiming upstream was being asked to support nixpkgs.

What I do see is a project calling itself FOSS, while its maintainers really don't like it being used as Free Software. If one wants to control downstream uses of one's software, the answer is quite simple - release it under a proprietary license. Don't grant freedom while going on and on about how you support freedom, but then be upset when someone actually uses that freedom to do something.

> deal with end users bugging me about it being broken.

The nixpkgs maintainers asked how much this was actually happening, and even preemptively proposed solutions. OP didn't engage and just repeated his demands. And in general how is this any different from the common DRM-authoritarian refrain that companies are justified locking down devices they make, lest end users modify them and then clueless people might attribute the outcome to the original manufacturer?