I'm a nobody and even I have had run-ins with certain people on the project. I think they have a similar problem to many hugely popular FOSS authors - you spend 99.99% of the day explaining things to idiots who don't get why things are the way they are, so when the 0.01% of useful, constructive issues float past they get written off by habit.

I personally think some of their leaders also have an over-reliance on gut reaction - have never once seen them admit to being wrong, even on multi year issues where context has changed. I think a useful litmus test for anybody in a position of power is "when did I last change my mind". If the answer is "never", either you're perfect or you need to think about how you've been making decisions.

Used it for five years. You've distilled the all the problems of HA nicely to its source. The product is fine for a while, until the arrogance and disregard the devs have against the user base inevitably breaks something and you have to spend time fixing things. And it happens often.

Edit: Just went through the DNS thread. Good lord. Just their typical M.O. on breaking things in the past.

Human factors aside, the practical result of this is that the methods of getting Home Assistant running are trash. Sure if you stick it on a dedicated RPi with their prebuilt image or use Docker, it "just works". But both of those methods basically guarantee suddenly needing to tinker when your setup randomly breaks. Ultimately if I can't simply apt-get or environment.systemPackages it, I don't really consider it sustainable software to rely on.

I did give in and actually had it running with Docker for some time. Eventually it just got real laggy and stopped responding to input or device state changes promptly. I had no idea why that would have been, and had no desire to wade through Docker manure to figure out how to debug it, so my setup just kind of fell by the wayside. Now when I think "home automation would be nice to have again", I envision just writing my own mqtt-native daemons some day.

The Docker container is the least evil of the choices, but it does have very pointless intentional limitations. Like not bothering to handle the difference between bind and externally visible IP, or by making logs difficult to mount outside the container (to a tmpfs to spare the SD card).

It's not even about "having to support someone's setup" it's about basic best practices, practices other software implements relatively effortlessly.

Very much akin to Canonical's Snap ~/snap folder thousands of users are pleading them to move to a more normal location.

IMO those all seem like predictable results of using Docker. By duplicating a whole system, containerization creates a whole bunch of unwanted complexity. Developers then fail to address every single concern, and when they do address a concern they often end up creating a novel way of managing it rather than integrating it into the standard ways.

I agree Docker is the "least evil" option for HA which is why I gave it a shot. But I still got random breakage, even with their auto update auto everything solution. So I'd say it's more like they haven't done the work to make reliable software, and instead of letting others start to apply pressure so that work gets done, they've dug their heels in with the modern way of saying "works for me". Container images are basically the contemporary .EXE.

If I can be running Internet-facing postfix, powerdns, nginx, asterisk, etc through distro packages and have them stay updated, a home automation daemon that is exposed only to my own network can most certainly do the same. It's tedious work to get software packaged for wider audiences, but if Home Assistant wants to bill itself as one of the leading solutions for libre home automation, then it's work that needs to be done.

I wouldn't say this is a result of using Docker, it's just very visible in that case. It's also not about handling "every single concern", it's users getting punished for poor assumptions made by the developers.

Point being that this incompatibility is active instead of passive, so this effort could be or could have been spent better.

If frenck is a core HassOS developer I never want to touch anything HassOS with a ten-foot-pole. They state in the linked PR they "tried to be friendly" but their tone is anything but the entire thread. They are completely unwilling to engage with the extremely patient Nix people, reiterating hard stop sentences. Zero attempt at developing discourse, just ornery, rude, commandments from on high.

It's not reasonable to ask people to remove your code from their project when they've already done the work on integrating it and it's published under an accommodating license. (edit: It seems the person requesting the removal of his project is an HA dev, some context for those links would have been useful.)

As for the DNS issue that seems to be a technical or design issue, I don't see in that thread any bad behaviour on the part of the devs, unless I missed a post.

> As for the DNS issue that seems to be a technical or design issue, I don't see in that thread any bad behaviour on the part of the devs, unless I missed a post.

The whole thread brings back PTSD when I was running it. It is reminiscent of every major problem they've had.

> seems to be a technical or design issue

This is the exact issue. The head devs don't keep contributors in line or provide any guidance at all. People just submit things, there's no checks on "is this a good idea?" and into master it goes. Does anyone actually want this? Does it make sense on how it's implemented? Will it break anything?

Those are questions for later.

The fallback DNS was put into place because some users have local DNS that returns non-conforming responses in a way that breaks dns resolution in alpine containers (think broken implementations in some of those shitty router-modem bundles that most ISPs give you). Home Assistant OS is based on containers, many of which run Alpine. They had a lot of bug reports about these issues, and they all went away once the fallback DNS was implemented.

They did not originally allow this fallback behavior to be disabled because it should not have been needed, and would only result in those original bug reports returning.

However there was a problem in the original design for fallback, where it had an issue where DNS could get stuck always being routed to the fallback servers. Which means local DNS names won't resolve. While annoying, this is often reasonably easy to work around, as one can typically just assign static IPs to relevant local devices and use the IP addresses. They did eventually fix this, so that it cannot get stuck using the fallback as the primary, and local dns names work again.

Furthermore, they are now able to detect when locally configured DNS is broken in ways that break alpine containers, so they now offer a feature where you can turn off fallback DNS, but if you have broken local DNS your system will be flagged as unsupported, which means that the devs can summarily close your bug reports without investigating, unless you have reproduced the issue on a supported installation too.

Are there any good alternatives? I currently run HA but have avoided upgrading past when they broke YAML configuration "for my own good". I haven't yet found any other good options

I switched to node-red, node-red dashboard and Mosquitto mqtt. Those run just fine runs in an lxd container.

Almost all my devices are flashed with tasmota or have mqtt in them.

Maybe there is a lot less hardware support, and certainly much worse google home support but the 30 devices I have around the house work fine. All family friendly. The light switches just work. The doorbell works and no one knows it goes via an RF bridge to a home made/written mqtt to mp3 player.