> That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem. > So if

> That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem. > So if you pack data (which can be modified and runtime!) into a container, it's a similar concept to an embedded resource in an executable, except it can change. > Now, in a container, any changes made to data at runtime inside the container won't persist unless the container is given persistent storage. > What I've been wondering lately is why we didn't invent some kind of single "executable plus volatile data space embedded within the executable", so that programs and data (say, a database) could couple together into a single file. Things like this have existed before, and I presume still exist. For instance, before MacOS X, applications for Macintosh for (vaguely) similar to "application bundles. Leaving aside the technical differences of implementation, classic Macintosh applications had a "resource" store that included code and 'static' data (pictures, text, whatever) but could be modified by running program. Changes could be persisted without using any other files. In practice, changes were often persisted elsewhere, be cause if a fault occurred during modification, the executable could be corrupted, and because this made things like resetting to defaults easier (by deleting or moving an external preferences file, for example).