.
I use a Linux LiveUSB as my everyday computing medium by choice. I prefer to maintain
my Windows hardware unaltered, except for OEM boot media selections. In other words,
I don't care to even dual-boot Linux and Windows on the same hardware.

A LiveUSB with self-contained read-write persistence has served me well for years as
a proxy for an 'installed' Linux system architecture. The down-side of this architecture
is the volatile nature of the persistence mechanism which may easily be catastrophically
corrupted by inadvertent user commands. Knoppix allows making iso9660/cloop-compacted
overlays, which combine compaction and protection in that these compacted overlays are
read-only and virtually immune to being inadvertently written-over and corrupted.
Up until now, combining overlays with Knoppix either is either restrictive on whether base
and overlay material 'overlaps' in use of address space, or prohibitively demanding in
workspace required to carry out the combining of overlapped material.

In its simplest form overlays are assumed not to refer to any storage addresses in common
and may therefor be combined in a simple additive manner. If there is some overlap
of common address material, simple addition is not appropriate. The best example is
where a program in an earlier overlay is 'deleted' in a later overlay. Simple addition
will not recover the unused space the 'deleted' program occupies.

A more involved treatment known as re-mastering is often used to more properly join the
net material represented as a result of the final overlay with redundant use of
storage eliminated. This is usually achieved by first expanding any compacted overlay,
then dealing with redundancies, and finally joining and re-compacting the resultant
material. The workspace required to do this is often larger than twice the size
of the original, un-compacted live system. The final result may be either larger
or smaller than the initial configuration to be re-mastered, depending on the net
additions and subtractions that are involved.

Mint 17.2 uses overlayfs as a replacement for aufs to perform the necessary LiveUSB
start-up capability of combining compact read-only base OS material with read-write
persistence file contents. But, as an enormous bonus, with the advent of overlayfs,
there now exists, in principle, a way to combine COMPACTED material rather than only
EXPANDED material to achieve the effect of re-mastering. The resultant workspace
required is much less in this instance. For example, fully within the capability
of an 8 Gb LiveUSB to contain both persistence and the ability to re-master an identical
8 Gb clone.

Dav Stott has provided a blog to describe-, and a bash program using overlayfs on
a Ubuntu LiveUSB- to carry-out an actual proof-of-principle of 'merging' compacted
program material to achieve the same end as 're-mastering' un-compacted program
material and in much less workspace. Dav's September 14, 2013 blog is here:
http://davstott.me.uk/index.php/2013...stent-storage/
Dav's March 23, 2015 updated bash program is here:
https://github.com/davstott/ubuntu-u...aster/mergeusb

I used Dav's program to 'merge' the basic squashed 1.5 Gb of my Mint Linux OS with
~400 MB net of my unique ext3 persistence additions, and one subtraction. The
result being a fully functional new squashed 1.4 Gb tailor-made-adaptation of
Mint 17.2 to suit my own specific needs. My one 'subtraction' was Ubiquity,
Mint's borrowed Ubuntu installed-program installer, which I don't need.
I provided for ~4.0 Gb of Fat32 persistence (ext3fs) in order to have enough
workspace for this effort. Even so, there is still 2.2 Gb yet-unused Fat32
filespace on my 8 Gb LiveUSB. More-than 4.0 Gb persistence would have exceeded
Fat32 address space limitations, and 2.0 Gb isn't quite enough to do the job
in this instance.

To use Dav's program, one's Mint 17.2 LiveUSB also needs its own squashfs-tools,
which Mint 17.2 currently doesn't otherwise need. Mint 17.2 does use overlayfs, but
only for the usual start-up combining of the squashed Mint OS and the ext3 persistence material.
It took 24 minutes using an exact clone of the original un-merged 64-bit Mint 17.2
Xfce to carry-out the merge on an 8 Gb Class 10 SDHC.
The clone used a 7.51 Gb partition of a 16 Gb USB3 SanDisk Cruzer; 7.51 Gb is
the same size as the '8 Gb' SDHC to facilitate dd cloning.

I've been composing all this on my first mergeusb/re-mastered Mint 17.2 LiveUSB,
while enjoying all my favorite tweaks and additions. I have a whopping 3.6 Gb of
unused volatile persistence to use, and a good feeling that most of my own tweaks
and additions are now protected in read-only form, alongside a slimmed-down
Mint 17.2 sans Ubiquity.