Linux bind mounts

Right. And who would ever need more than 640k lol...

No the point is that there probably is a perf impact once the number goes up, and considering how all these distros seem to like these packs it's not inconceivable that the number does go up. 'mount | wc -l' currently shows *59* on this system - enough that some "work-around" is required if you just want to see the actual disk mounts (read: usefulness). The second point is that bind-mount really isn't the right spot for what MAC does already and (much more) cleanly. The third is that since these app packs are composed by 3rd parties I wouldn't necessarily trust them to do it right, and with potentially not much insight (without digging out source/build files) into how it's actually put together. The fourth I've already pointed out, which is that even if the admin is diligent and updates are applied regularly, the packs might for one reason or another skip updating these dependencies. The fifth I've also pointed out, which is the duplicity of versions of these packs. An old pack might have vulnerable binaries which might conceivably be available as a vector, say by LD_PRELOADing some libs from old/other packs; not that I know of one atm, but still. The sixth is, again, waste of resources by keeping multiple copies; disk is cheap, sure, but I'd prefer not having to constantly up-size partitions. #7 I like a *single* tool on the system to install sw, not mixing apples and oranges; dunno 'bout you but I don't fancy a mixed deb/rpm/snap/flat/whatever system with overlapping namespaces; besides, consider that these packs are a supposed "solution" to the problem of non-unified sw management - devs don't like deb or rpm or don't want to provide both, so they provide a... third... and fourth... and fifth... type, 'coz that's so much "better" and "solves" the problem of too many different pkg managers... right.. so even just listing all the installed software.. umm.. you get the idea. Anyway, #8 taking all of the above in consideration, there are very few salient selling points to these packs; "more secure" certainly isn't one of them - simply unpacking a tgz in /opt/app and providing some standard way of sandboxing ("chroot", except not chroot) would probably be just as good as any app pack out there, if not better, for the simple reason that it'd be standard, inspectable, verifiable and not dependent on the 3rd party to do it right while at the same time keeping various other interfaces clean (mount, df etc)