Some Unix resources have always lived in their own namespaces, perhaps only meaningful to a subset of system calls. Examples include user and group IDs, environment variables, process IDs, the standard input and output streams, fcntl, ioctl, msgctl, and sockopt options, process arguments (argv[]), and permissions or access control lists.

Some resources could have been accessible via the filesystem structure if the filesystem had allowed a node to be simultaneously a directory and a leaf. For example, the user records in /etc/passwd could appear as individual filesystem objects, perhaps as an alternate view of the flat passwd file.

Still other resources have grown up outside the filesystem namespace. The difficulty of user-level extension to the filesystem could be partly to blame. For example, URLs are hierarchical like Unix paths, and have been shown to fit nicely into a pervasive namespace. Socket endpoints are named in a separate (address, service port) namespace. One could imagine a namespace interface to database systems that would allow the use of common tools on database objects.

While having objects share a namespace doesn't guarantee that they will be interoperable, having objects live in separate namespaces all but prevents interoperability. A pervasive namespace is an important first step toward enhancing modularity.