HassOS 3 released! Raspberry Pi 4 support

no actually.
You can just install HA in a Venv on any linux distro.
Any variety of hassio runs in docker… be it with HassOS or a generic linux install (in docker)
You can also install Home Assistant in Docker - not hassio but Home Assistant.

The issue is there is no ‘approved’ way of referring to the generic linux install of hass.io (other than the whole sentence it seems)

I would see the install as:
HassOS
Hassio in docker
Home Assistant in Docker
Home Assistant in Linux
Home Assistant in venv.

That’s running HassIO on docker, which is not the same as running it "in* docker.

HassIO necessitates Docker, since it’s made up of docker containers.

It’s possible (but highly ill advised) to run docker inside docker; so you have HassIO running on docker, all inside docker.

Even trying to put it in words seems to get very confusing very quickly.

I honestly truly fail to see the distinction.

But as far as I know not one person means that when they say “hassio in (or on) Docker”. It seems to be generally accepted (amongst the hoi polloi at least) that Hassio in docker is simply just short hand for “hassio in a generic linux server”.

1 Like

Hmmm. I would argue that since Docker is the concept of containers (and running things in containers) then we are talking about HassIO being in Docker. We don’t normally put things on a container, we put them in a container.

In this case, we put HassIO spread out in mulitple containers :slight_smile:

Not unless you want them to fall off :rofl:

Yeah, I can conceptualize the distinction in my head just fine, but have difficulties easily spelling it out.

But, I easily recognise your name, I know you know what you’re doing. I’m sure you understand what “running docker inside docker” means. IE Running a VM on your host system vs running a VM inside a VM. In the same way, You can install HassIO (docker) inside a docker container, when HassIO is meant to be a set of containers running on docker on the host. Not a set of docker containers running inside a single docker container running on the host.

Oh I fully agree. I think that this particular distinction (running “on” vs running “in”) is totally pointless.

The real breakdown in terminology is Is HA Vs. HassIO Vs. HassOS.

I liked the infographic @cogneato put together for it, though I think I could use an improvement or two (For example, the boxes should be nested to show one is inside the other, not just a hierarchy, like this)

I know you’ve seen my own posts breaking down HA Vs. HassIO Vs. HassOS (since you’ve upvoted them), and think we 100% agree that something like that would be super helpful in the primary site docs.

So why did you make it? It just confuses things more.

I didn’t make it, just attempted explaining it. The OP made the original distinction.

He knows more than anyone else that HassIO runs on docker. As such, he must mean that it doesn’t run in it, it runs on it.

The thing is that some people seem to be implying that Hassio is the “ecosystem” that runs a plain HA in a container alongside another container that runs a supervisor (and recently a DNS server in a third container) but it’s not like that. I submit that that idea is wrong.

“Hassio” is a completely separate version of HA that additionally includes the ability to run add-ons by interacting with the supervisor container.

If it was just simply a dockerized version of regular non-hassio HA (see I even have to do it now to explain this…) then I could see that the distinction between saying “hassio” & “hassio in docker” would be redundant. But it’s not that way.

I have a non-hassio HA running in a docker container and my version of HA doesn’t have the ability to run add-ons from HA. so it is “non-hassio HA running in Docker”. Since I didn’t install Hassio via a HassOS image then the opposite version of that would then logically be “hassio running in docker” but since all hassio runs in docker and there are multiple and mutually exclusive ways of installing it on a machine then you need some way of distinguishing between those as well.

So the end result is that you have several distinctions that need to be made when talking about the intricacies of the technology depending on the needs of the conversation taking place.

I fail to see why the powers that be have issues with the way that the users of the software have come to “organically” refer to those distinctions.

And yes, I liked the way you described the differences in your post. It was well written and informative. But we need a way to communicate quickly when in a thread and trying to suss out which HA the user is using to most effectively give the best answer to a problem without writing out long paragraphs of explanation to get there.

1 Like

I agree.

I think most of the people here having the discussion (I think it’s unfair to call it an argument) are all mostly on the same page, but with slightly different perspectives or ideas on how to best go forward.


Overall though, Thank you @frenck and everyone else on the dev team for making this release happen, and for the great progress on the project in the past few years, and years to come.

2 Likes

3 Likes

The funny thing is I didn’t even know this was an issue until this thread.

Don’t get me wrong, I knew there was confusion around hassio/nonhassio/venv/etc but I didn’t know there was dissent even down to the words we in the community were using to try to sort out the mess created by the naming of the different versions of the software.

Oh yeah… “Hassio in Docker” is a hanging offence… it’s even worse on Discord.

Ok I think the smart-@$$/serious question has been resolved… :roll_eyes:

Let me try to figure out the cryptic message message you are trying to provide here…

if you are saying that hassio is a completely constructed “system” of docker containers then I respectfully refer you to the post above.

Wrong.

hassio is a different version of HA. Both of which can be installed in docker. Hassio just happens to also be installed alongside of another docker container called a supervisor.

Wow! I guess I’m glad I never gotten into that.

I’d have been banned a long time ago.

Home Assistant itself is exactly the same… It’s just a different install method.

1 Like

:laughing: :laughing: :laughing:

2 Likes

Yes, the underlying software is the same but I am trying to show that there is a difference between a vanilla “Home Assistant” (installed in docker or venv or whatever) and Home Assistant with the functionality of Hassio thrown on top.

As I said My HA installed in Docker is not the same HA as Hassio since my HA doesn’t have the additional features that Hassio provides. So it’s different.

Hassio uses the same version of HA anyone else uses.

a completely constructed “system” of docker containers

This is exactly what it is. Your version has the whole world of dockerhub to explore as “addons” which you have to integrate to HA yourself. Users in the docker channel of discord do this all the time. There’s a lot more flexibility and freedom running it this way.

The Hassio ecosystem is a more curated version of that. Less freedom, and more convenience. And yes, it adds some management and backup features as a result of this control and fencing in/walling off, whatever you want to call it. It takes docker and makes it a tool for a more specific purpose (home automation using home assistant), in a similar way to how unraid has an “app store” which also uses docker and it’s own templating system for images/containers.

There are images for each architecture (qemux86-64, armfh, etc). This is simply a matter of the queue and the time it takes to render them. Sometimes the vanilla docker image is first. Sometimes it isn’t. Sometimes it stalls halfway through the list for whatever reason.

2 Likes

Perhaps it’s exactly the same software, but since it does not detect that it’s running in a HassIO “environment” it does not display those features?

It certainly looks and act different, but it might be the same code, just presenting itself differently based on the environment it detects.