The TUNES Project is a project to develop a free software computing system based on a reflective design, which system as a whole is also to be named " TUNES".
We want to get rid of the obsolete or plain misdesigned idiosyncrasies of current computing systems that standardize things from the low-level on, as the legacy of systems designed first for resource-poor computers, then under the constraints of proprietary software.
For instance, we want to replace filesystems with orthogonal persistence of objects, compilation and administration of program binaries with automatic consistency management of dynamically optimized code, user-interface-driven programming with structure-driven user-interfacing, explicit manual networking with implicit automatic distribution. See below if you like feature lists.
The common point about these features is that they consist not in something more that the user/programmer can do with some more work (implementing such "do" features is a "simple matter of programming", and requires no a priori system support besides the basic device drivers); they consist in the user/programmer being able not to do, about his not having to care, yet still achieve all that he does care about; they consist in relieving the human from work by letting the machine handle it for him, which is the essence of progress.
The ability to let the machine automatically do things that could previously be done only by manual interaction (which include typing programs), the ability to specify what one cares about and what doesn't care about and trusts the computer to handle all by itself, these are what the reflective design is all about.
Metaprogramming is the activity of manipulating programs that in turn manipulate programs. It is the most general technique whereby the programming activity can be automated, enhanced, and made "to go where no programming has gone before" (sic).
Reflection is the ability of systems to know enough about themselves so as to dynamically metaprogram their own behavior, so as to adapt themselves to changing circumstances, so as to relieve programmers and administrators from so many tasks that currently need to be done manually.
These notions are explained in my article, Metaprogramming and Free Availability of Sources, that also explains why a reflective system must be Free Software. You may also consult the Reflection section of the TUNES Review subproject.
Reflection is important because it is the essential feature that allows for dynamic extension of system infrastructure. Without Reflection, you have to recompile a new system and reboot everytime you have to change your infrastructure, you must manually convert data when you extend the infrastructure, you cannot mix and match programs developed using different infrastructures, you cannot communicate and collaborate with people with different background. At the technical level, all these mean interruption of service, unreliability of service, denial of service, and unawareness of progress; but at the psycho-social level, lack of reflection also means that people will have to make irreversible static infrastructural choices and close their mind to infrastructural change, and will not communicate with people having made different infrastructural choices.
Reflection is a deep technical benefit, but also a deep psycho-social requirement, that allows individual progress despite historical choices by evolution of the conceptual infrastructure, and community progress despite variety of individual and unshared backgrounds by unification of infrastructures.
We feel that the distinction between programming language and operating system is most unwelcome, and mostly a lie:
one never programs in a programming language independently from an operating system, or in a operating system independently from a language (be it universal or limited to end-user interaction).
Language-independence and system-independence are myths: whatever the language, to communicate with other people and programs, it will have to go through the only services provided by the system, with the sole mutual invariants that are expressible in the standard system-interfacing language.
TUNES is a project for an integrated computing system. We must implement a new language and concept, because we want a system that be more expressive that can be achieved with what exists today. We need implement a new OS infrastructure, because the language must control the whole system so as to be able to reliably enforce its invariants. Moreover, we expect a tight integration of language and OS infrastructure to ultimately yield much enhanced performance, too. Of course, we may achieve a programming language and a low-level OS framework that could be used separately, but we feel that much of the added value of the project resides in the integration of them into a one reflective architecture.
For a rationale behind the TUNES approach, why we feel it is a necessary step in the progress of computing, read the article Why a New OS?.
The functionality that we want TUNES to provide could be considered a challenge in itself. However, every single feature that we propose has been successfully implemented somewhere by somebody, although in complete separation from other features. So the real challenge about TUNES is not to implement difficult or impossible features; it is to build a system that can consistently coordinate separately developed features that each tackle very different aspects of computing with respect to the other features. And this is precisely what a High-Level Language capable of both logical reasoning (including quotients) and computational reflection is all about: being able to specify, implement, and verify arbitrarily complex a posteriori relationships between separate software components. The TUNES challenge is thus in achieving the core reflective system above which currently impossible (because over-complex) combinations of features can be built. Because reflection hasn't been satisfyingly formalized in the past, our challenge includes academic research on the theoretical foundations of reflection as well as an implemention effort towards a full-featured system.
Yes and no, depending on what is implied by ``normal''.
If you mean that TUNES be implemented as a user-level process that uses GNU/Linux (or whatever existing OS you prefer) for its I/O, taking over some resources (disk space and CPU) that it manage on its own, then yes, this is conceivable, and this is what the LLL/OTOP subproject is all about. Now, if you mean that TUNES be expressed as a user-level process in a way that other programs could benefit from the features of TUNES through normal Linux means, then no, this isn't possible.
Even if implemented on top of GNU/Linux, the functionality that TUNES provides can only be available to applications written in TUNES and for TUNES, and only if no other Linux process tampers with TUNES data without going through a normal TUNES request. These restrictions greatly bound both the applicability and the reliability of such TUNES implementation. This is why TUNES can unleash its full potential only by taking over the whole machine (or a private part of it) either as a well isolated set of daemons and file hierarchies, or as a standalone kernel; it cannot be merely a ``normal'' GNU/Linux application.
Sometimes, people wonder how TUNES relate to works in Artificial Intelligence, since TUNES promote having machines develop programs, which is a typical "intelligent" human undertaking. But there is not much more than that to add about TUNES and AI. TUNES does not pretend or strive to be AI technology, and does not depend on the existence of such technology. We do claim that we will automate some of the programming work currently done by humans, but precisely in as much as this work we automate isn't as intelligent as is too often presumed to be; of course, some AI researchers will say, the field "AI" is precisely about pushing back the limits of what can be automated and no more considered "intelligent"; however such is actually the goal of any and all technology, so we are not specifically AI-like in this respect.
Actually, if TUNES has any specific tie to AI in any respect, as compared to technologies of the same kind, this tie is our enabling many previously impossible new developments, including "AI" kinds of developments, but far from exclusively so, thanks to our reflective infrastructure. All in all, TUNES is upstream to AI developments; we will use expert system technology, declarative programming style, etc, but we do not consider that AI or AI research in itself, but rather as reuse of useful paradigms previously developed by AI researchers. Now, we're also convinced that a system such as TUNES will be a great tool for AI researchers. If AI is possible, we hope that TUNES will help toward reaching it; If it isn't, well, we hope that TUNES will help make the most of what is possible.