Herein, we present examples of conceptual differences which make Tunes a completely different system from existing ones. See also the Examples page for concrete interaction examples with the TUNES system.
On existing systems, you're stuck, because the database will get mixed-up between ASCII control characters and your encoding, and even if your encoding doesn't use these, you won't be able to sort your entries according to the usual order from your encoding. Input and output will be a pain, and mixing ASCII and your encoding in data fields will be impossible.
Using TUNES, it's not a whole monolithic database application being provided (sold/given/whatever) to you, but a set generic database object, that manage the database-specific stuff, but are completely parametrizable as for the kind of managed data. Thus, you can manage usual ASCII text as data, but also any kind of raw data with any kind of manipulation properties, any kind of sorting orders on it, etc. Standard multiplexers will allow you to mix different kind of data in one data field, etc.
On existing OSes, you'll have to also rewrite all the software from scratch, or pay very expensively some company to integrate support for your hardware in their software product; in any case it'll cost you lots of time and money, and you'll be stuck to the specific package you choose, unless you're ready to pay again the same large investment all again.
In TUNES, you'd just write just a generic driver, that would run on just any software package you'll ever have, because they are generic, and really take as an input any module that provides the good basic operations.
Existing systems are coarse-grained: you cannot isolate this feature from lots and lots of other features you don't need. Either you choose to write your own software, and need reimplement all the existing features of the software you already have before you can add your own; or you buy some new software, and will have to buy not only just your feature, but many features you don't need, which not only will cost you money, but also occupy memory, thus slow down your computer as well as prevent you from installing other useful features. The whole world is a victim, as this forces people to waste lots of computer hardware to manage lots of useless features, the economical and ecological cost of this being tremendous.
By providing fine grain, TUNES will enable people to have just the feature they need, which will greatly reduce the cost of software for the individual as well as the global environment. This would lessen the price of hardware required for some software, of a software package, making software development easier. It would also reduce all these monetary prices as well as provider and consumer human time and pollution.
All that is possible because TUNES allow fine-grained modules to be delivered, not huge coarse-grained "applications".
Then, even though what you want is directly accessing the I/O ports, traditional system kernels will add a penalty at each access, by first intercepting each of them. Sometimes, the penalty is so large that you just can't do it; then, you must create a big security hole by modifying the kernel, or allowing direct, uncontrolled access to the I/O ports; in either case, this means no "normal user" can do it.
Using TUNES, you can access directly any visible object; either you cannot see the I/O ports you need, or see them wrapped in secure software layers, or you see them directly; every single object can be visible independently from the others. Hence, you may well see, say, the serial I/O port, and use it, without your needing be super user and have access to all other ports, and without a system kernel intercepting all your accesses. You just see it and access it directly. If some access combinations may endanger the system, you can either see the I/O directly wrapped by an adapted combo detector (based on actual dangers, not user-access rights that are independent from the user being able to use the port properly), or statically prove that all your accesses will be all right.
In either case, your performance is quite better than that of a kernel, and you have a much more secure system, as you're not filtered by a static, unadapted kernel, but by dynamically adapting tools. The system isn't trying to conform reality to arbitrary bureaucratic layering, but adapting security to actual hardware and software requirements.
With TUNES, computer power could be fully used: the system is built to automatically distribute code over the network, in a way that conserves security for both the one who furnishes the power and the one who uses it. Users don't have to rewrite everything from scratch, though they still can modify the details of everything to suit their needs. Thus, computer power is must less wasted, which leads to cheaper computers for higher effective horsepower.
With TUNES, you could distribute copies of data accross the network so access it quick, yet have the same security, and be much more maintainable (see notably the Amoeba stuff).
In TUNES, the system may automatically fetch the modules you need, and ensure that no one may cause harm through proof systems and trust systems, while keeping saving all the data the human user manually approved of.
With TUNES, the system may automatically dispatch the information flow among the computers, according to general human defined constraints so as (Finish this!)
With TUNES, the entire world is considered as virtually being a distributed system, with links being variously interesting, fast and trustworthy. New software is automatically taken into account; the system automatically manages transfer through slow human-aided media (floppies and such), so that it be as fast as possible by transfering just the needed data, but transfering it reliably; transfers are much faster because fine-grain and automatic module management greatly reduces the amount of information to be passed; merging is done non-destructively, and while the human is relieved from stubborn tasks, everything stays under his full control.
In TUNES, everything is automatically saved.
TUNES will save a log of changes at a fine grain, so they be reversible. Saving will be adapted to the objects, not added on far away layers of the system, so they will reflect actual changes more efficiently, with much less memory consumption.
With TUNES, only one language system is enough, which may be dynamically and seamlessly adapted to any existing syntax or semantics. Mixing programming styles becomes a trifle, and the system being one, efficiency is made possible by the absence of slow interfaces between the various sublanguages.
With TUNES, objects are defined according to their semantics, to what they actually mean, to their meaning, the way they interact with other objects. Thus having separately developped objects interact is easy, and storing or retrieving objects is cheap.
With TUNES, software may come with proofs of their correctness, and feedback from users about the software and competing products is freely available, not hidden from the customer. Competition will be fair, being based on objective information; natural selection will work very well.
With TUNES, all objects are failure-aware, and the user may define failure-recovery policies; that is, people can be confident that even after a hardware failure, the software will be able to start again at the point just before the hardware failed. Users and programmers needn't unnecessarily worry, and lose their time and money at preventing an eventual crash and recovering data.
We believe that all these features are linked. (This has needed updating and expansion for some time.)