A term describing a system without a kernel. The idea looks like it is original as far as operating systems are concerned, but it is so natural that for any other kind of software (and one of our points is that there should be no such privileged notion as that of an "Operating System" well-separated from "Applications") where there isn't such a stubbornly overwhelming tradition, it is the very idea of a kernel that looks odd.
Software in a no-kernel system works just like most any software: various objects interact, each doing its part of the work. The difference compared to software in kernel-based systems? No-kernel software is not limited to a single centralizing entry point like the Unix syscall() or DOS interrupts, whose overhead, limitations, bugs and misdesign you must cope with or work around. Instead, objects can directly interact one with the other, and you can upgrade/extend/modify any unlocked part of the system anytime.
Surely, there are objects that control other objects, for security reasons, and may be that at a given moment on a given host running Tunes, a given object is such that it controls "most" other objects as far as a criterion of number of entities, space used, time used, or combination thereof is concerned. Still, none of these possible objects constitutes a "kernel": none is a permanent system-wide totalitarianly centralizing invariant entity, through which all non-local information is bound to pass; any may be replaced anytime by another, better, more suited and/or more advertised. The set of available objects constitutes a library, not a kernel.
For instance, let's take task-switching. Each thread has its own task switching (meta-)code. But this task-switching code does not float over the void. Rather, objects are built from other objects. Hence, when you built an object, you chose an execution meta-object that controls task switching. Most probably, you let the system implicitly choose it for you; and because a development system is open, unless you explicitly gave the execution meta-object, the one given to you by default allows you to later migrate your object to another meta-object, that will better suit the needs that you've realized you had in the meantime.
As an example, typical commands run from the UI will be interpreted by a shell that cooperatively switches to other tasks inside the same pool; optional passes of partial evaluation might compile (part of) the commands into cooperatively taskswitching code. Insecure tasks, such as Unix/DOS programs running in an emulation box, or a low-level reflected implementation of the system being under development, will be isolated from the rest of the system by the traditional protection barrier, and be fully preemptively taskswitched.
Tunes needs not be preemptive or cooperative. It can be either, or any combination of the two, or anything you can imagine and implement. Because Tunes is reflexive, meta-objects, that control the behavior of objects, are fully accessible like any other object, and you can choose whichever you want (among implemented ones), to control the taskswitching of your own Tunes system; or you can use default taskswitcher provided with your system by whichever distributor you chose. I can imagine that the Yggdrasil Tunes distribution won't be quite the same as RedHat Tunes, etc.
See relevant explanations about no-kernel design among Mailing List Posts of Interest.