The contrasting *(term) to _(centralized): not obeying to a one guide, chief, fhrer, duce, central _(committee), or any other kind of grand beloved all-mighty all-knowing (individual or collective) leader. Not even having such an organization in any part of the system.

As for the runtime software executive in an _(Operating System), <em>decentralized</em> means that there is no portion of code that would centralize execution, communication, scheduling, and more generally (meta)service dispatch, as current primitive centralized systems do.

In that latter meaning, Tunes will be decentralized: At runtime, this means no "system call" mechanism, but function calls being directly linked/inlined where needed. As for protection, scoping, typed languages, proof systems, and user wrappers provide much quicker, finer, more expressive protection than a kernel will ever allow. A centralized (kernel-based) architecture is just <em>overhead</em>, and brings <em>no</em> functionality of any kind that couldn't be brought better-faster-cheaper otherwise. The only advantage of it is for throwing off a running implementation quicker, which is good in early design/alpha-test stage, but should certainly not be made a standard interface that would prevent further improvements. See _(no-kernel) systems.

Runtime software decentralization can be implemented efficiently with a reflective architecture: the system can abstract any part of itself (whether by ability or by a priori assistance) and further replace it. Then a runtime _("code generator"|Code Generation) (that itself can be replaced/upgraded) will replace all of interpreter, compiler, linker, _(kernel), etc. Functionality (including _(higher-order)) all goes into libraries, where it belongs.