Traditional systems enforce a "_(security)" _(paradigm) of a finite number of _(user)s, each controlling his own files, and having no <em>right</em> (a semi-legal *(term)) on those from others. Though it is certainly more secure than systems with no _(security) at all (e.g. MS-_(DOS)), such finite _(security) systems are just as insecure as soon as arises the need to share any data: whenever programs want to share data, one must blindly trust the others, because the finite _(security) semantics cannot map the infinite semantics of actual problems.

To circumvent this difficulty, many propose that no sharing be done; but then it is sometimes (it especially was in the time when no free _(Unix) was available to the masses, and perhaps still is when few _(user)s are concerned) better and cheaper to get a smaller machine for each human _(user) than to get a big _(centralized) one bogusly shared between them. Others (see _(VSTa)) have invented infinite protection systems, where _(user)s can have sub-_(user)s, which can in turn have sub-_(user)s, and so on, recursively.

While nobody can deny that such systems do restrict possible demises of the system, the kind of order enforced by such systems is very much that of a dictatorship, where power was left to a Leviathan to guarantee a civil peace, actually the peace of the dead.

None of these protection schemes tackle the essential problem of _(security); they just add tremendous overhead to programming and program execution, without really solving anything, just postponing insecurity.

TUNES despises such non-solutions to problems.

Traditional systems also use the "_(user)" concept as a way to have multiple (but statically many) differently customized versions of the system. 
In TUNES, there is no such concept of static "_(user)" erected as a fundamental axiom of the system. Instead, actual human _(user)s are free to define as many contexts as they like, to define variously specialized subcontexts indefinitely and dynamically. To the machine, no particular axiom is needed, the human _(user) being just a common attribute to some contexts. As for human-_(user)-wise _(security), the system allows these contexts to arbitrarily define lists of signatures or _(capabilities) as needed, and (dynamic)ally manage and share their resources at will. Again, _(dynamism) and _(higher-order) expressiveness, which allow adaptation, win over finite _(static) allocation.