Sure.. Creating a zone was easy, it was managing it that was impossible.<p>So the way I used to use debian was I was using xen.  If I needed something like a tftp server, I would bring up a tiny VM with nothing but the base debian system installed.  Then I would simply apt-get install tftp-server-whatever (via puppet) and call it a day.<p>Since all it was running was sshd+syslog+postfix(bound to lo) and the tftp server, patching was easy.  I didn&#x27;t have to deal with managing updates for 2000 packages that I was not using.  I could also upgrade each vm separately.<p>Zones did not work that way at all.  You could do a &#x27;sparse&#x27; zone, which would inherit some directories from the host system, or whatever the opposite of that was that would just go and install a full 4G+ solaris system into the zone.  When I complained about the fact &#x27;single use&#x27; zones had to have 4G of software installed, I was told to just use clones, which did not use extra disk space.<p>The problem is those full clones then needed to be patched.<p>It was basically impossible to create a small single purpose zone that did not contain 4G of software and was easy to manage.<p>The sparse zones were not usable because then you could not install or update software in isolation.  I see the same thing on the ez-jail page:<p>&gt; Because the basejail&#x27;s copy of the userland is shared by the other jails, updating the basejail automatically updates all of the other jails. Either source or binary updates can be used.<p>So, if an update to basejail breaks something, it breaks every jail linked to it?  What if I want to test my software on FreeBSD+1?<p>Really, the problem wasn&#x27;t the zone technology, the problem was the horrible user-hostile solaris userland.  This is why Triton appeals to people.