On Fri, Mar 9, 2018 at 3:11 PM, R0b0t1 <[email protected]> wrote:
> On Fri, Mar 9, 2018 at 10:17 AM, Alec Warner <[email protected]> wrote:
>> The containers are nominally stateless, so there is less chance of 'gunk'
>> building up and surprising me later. It also makes the lifecycle simpler.
>>
>> Obviously its somewhat harder for stateful services (databases, etc.) but I
>> suspect things like SANs (or Ceph) can really provide the storage backing
>> for the database.
>> (database "schema" cleanliness is perhaps a separate issue that I'll defer
>> for another time ;p)
>>
>
> Containers are stateless, which prevents programs from munging state,
> because there is none. This is okay except when one needs state, which
> one does for most desktop activities.
>

Containers don't have to be stateless.  However, if you want them to
be completely disposable then they obviously need to be.

Bind-mounting something into a container is a simple solution for many
situations.  If your desktop only stores state in /home then that is
probably very practical.  You still need to be able to rapidly build a
suitable desktop container and easily deploy it in the context of
something like a laptop.  But, I don't think this was being proposed
as a solution for desktops in the first place, which of course then
raises the issue that until they do cover desktops containers aren't
really a substitute for keeping your filesystem reasonably clean.

-- 
Rich

Reply via email to