This is why I said “most containers most of the time should”. It’s a bad practice to write to the inside of the container and a better practice to treat them as immutable. You can go as far as actively preventing them from writing to themselves when you build them or in certain container runtimes, but this is not usually how they work by default.

Also a container that is stopped and restarted will not lose its internal changes in most runtimes. The container needs to be deleted and recreated from the image to do that

Yes, technically chroot and jails are wrappers around kernel namespaces / cgroups and so is docker.

But containers were born in a post chroot era as an attempt at making the same functionality much more user friendly and focused more on bundling cgroups and namespaces into a single superset, where chroot on its own is only namespaces. This is super visible in early docker where you could not individually dial those settings. It’s still a useful way to explain containers in general in the sense that comparing two similar things helps you define both of them.

Also cgroups have evolved alongside containers at this point and work rather differently now compared to 18 years ago when cgroups were invented and this differentiation mattered more than now. We’re at the point where differentiation between VMs and Containers is getting really hard since both more and more often rely on the same kernel features that were developed in recent years on top of cgroups

A million times this. A major difference between the way most vms are run and most containers are run is:

VMs write to their own internal disk, containers should be immutable and not be able to write to their internal filesystem

You can have 100 identical containers running and if you are using your filesystem correctly only one copy of that container image is on your hard drive. You have have two nearly identical containers running and then only a small amount of the second container image (another layer) is wasting disk space

Similarly containers and VMs use memory and cpu allocations differently and they run with extremely different security and networking scopes, but that requires even more explanation and is less relevant to self hosting unless you are trying to learn this to eventually get a job in it.

Which starts at $20/mo. Meanwhile I bought plex pass lifetime for $50 over 12 years ago. Even with the new pricing monthly plex pass is cheaper than cloudflare tunnel

Same here except we’ve also started living somewhere with managed internet and we don’t have the ability for port forwarding or upnp anymore. Plex relay is the only reason I can still stream to my phone or my family and jellyfin has no equivalent.

This is incredibly common in smaller countries that are double natting inside their ISPs. This used to be very common in the US before the FCC blocked apartments from contracting with ISPs. Unfortunately for many of us this is coming back rapidly since the current FCC has reversed that rule and landlords can force you on a specific ISP and equipment again.

I can go way out of my way to make this work anyway with a lot of router on a stick style garbage out to a cloud host somewhere and retrain my entire family to connect a jellyfin app to my server or I can keep using plex and not work that hard

They actually also can relay. I’ve been stuck in an apartment with managed internet and no NAT or UPnP and my media streams over plex relay instead.

This is also useful for countries and communities that are double natted

Lots of people in this thread are confusing direct streaming and plex relay as the same thing

They actually also can relay. I’ve been stuck in an apartment with managed internet and no NAT or UPnP and my media streams over plex relay instead.

This is also useful for countries and communities that are double natted

Lots of people in this thread are confusing direct streaming and plex relay as the same thing