classic mode (v1)

Gustavo Niemeyer gustavo.niemeyer at
Mon Nov 23 17:28:23 UTC 2015

As discussed previously with Michael, preventing updates at all (option 1)
would be awkward. I'd prefer to have option 2, which is to prevent updates
until explicitly requested, in which case the stored state is reset (not
$HOME, which is bind-mounted, as properly brought up by mvo).

On Mon, Nov 23, 2015 at 2:56 PM, Mark Shuttleworth <mark at> wrote:
> We also discussed that you might have a "reset" command, which gives you
> a fresh (and entirely up to date) classic dimension. Something like
> classic.reset.

+1; this might be simply a matter of purging the data, as John mentions.

I don't think we want to use an overlay-on-snap-content because, as you
> say, problems. Rather we want to *construct* the classic environment as
> efficiently as possible, but treat it as a one-time exercise until the
> reset.

The agreement in the sprint was to use an overlay, IIRC. You might remember
us discussing this inside the glassy room, where we talked about the fact
this is similar in nature to how the live CD works.

It sounds like there's a distinction being driven there which I don't quite
follow, though. The overlay-on-classic-snap-content is still a one-time
exercise until reset. (?)

For now, we want the classic environment to persist between shell
> invocations (so you can make it comfortable and reuse it). We don't
> worry about things like daemons starting in the background, all
> processes from the classic dimension can terminate when you exit the
> classic shell.


gustavo @
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the snappy-devel mailing list