Features of TUNES

This page ought to contain examples and wishes about what Tunes should actually do as a better computing system. It's a new page in there, so please excuse its still being a draft. Please also do send in your wishes for a new system...
Herein, we present examples of conceptual differences which make Tunes a completely different system from existing ones. Also see the Examples page for concrete interaction examples with the Tunes system.


General design

Tunes will be a fine-grained system.
  • Imagine you have a beautiful, perfect, database, but you're using text with a non-standard encoding (specialized ASCII extension, with specialized fonts).
    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.
  • Imagine that you've just made your own data-acquisition hardware for some specific job you're doing.
    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.
  • Imagine you really need just a small little feature to be added to some software you have.
    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, make software development easier and All these prices are in money 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".

Tunes will be a decentralized system.
  • Imagine that you want to access directly some computer capability, because the standard services won't allow you do so.
    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.

Tunes will be a distributed system.
  • Computer power is expensive.
    In today's computer networks, it is wasted: most of the time, most computers stay idle. Though using the full power of the network is theoretically possible today, existing programming languages and tools are designed to run on a single computer, the one on which the user is logged. To take advantage of the computer horsepower on the network, a user has to explicitly write his program for that, for which he can find little to no help. Moreover for security reasons, he most idle computer won't accept to work for him, and he will have to manually manage all the possible failures of the network.
    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.
  • Data integrity is important
    In existing systems, you have only lame slow unadaptable centralized architecture.
    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 existing systems, you must manually provide all the modules a program you install needs. Being painful, unadaptable, it leads to huge systems with lots of redundant modules, everyone being painful to install and maintain, and slow module upgrades. Moreover, you have absolutely no security on the modules you use.
    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.
  • In existing systems, you must manually give all references to the computer so that it does specific actions on a specific computer. It leads to awkward system interaction, and waste of both human and computer resources, as human must give trivial details, and do not have time to manually schedule computer activity, nor proficiency to do it efficiently.
    With Tunes, the system may automatically dispatch the information flow among the computers, according to general human defined constraints so as
  • In existing systems, humans must manage completely manually software installation on their computer: updating applications from the outside world, merging software from various sources, all that is done by the human user, clumsily and at his own risk, whereas it could be done by the machine. Users must also explicitly manage which software to transfer over floppies, disks, tapes, and other slow communication media. Because applications are coarse grained and there is no automatic mechanism that allows to trust required external packages to be present, communication and storage media are wasted, and transfer speed is slow. Installation software exists, but cease to be of any utility at the first problem, and then everything must be reinstalled from scratch, after the human being left alone to solve the problem.
    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.

Tunes will be a persistent system.
  • In existing systems, you have to explicitly save. How many times have work been lost because it wasn't automatically saved, whereas the computer was shutdown, or crashed, or there was a power shortage ?
    In Tunes, everything is automatically saved, .....
  • In existing systems, all changes are irreversible, so you always fear
    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.
  • .....

Tunes will be a unified system.
  • In existing systems, you must learn tons of different specific completely different languages, each having its powers and its flaws, and not being able to communicate easily with other languages. When something lacks in existing languages, there is no way it could be dynamically amended or extended in any efficient way.
    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.
  • In existing systems, objects are defined according to their syntax, their external appearance. Having separately developped objects interact thus becomes a challenge, while storing and loading objects is expensive.
    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.

Tunes will be a secure system.
  • In existing systems, you are forced to trust blindly or not use. Users trust software only according to their origin, and big software firms dictate their whim the non-technicians. Competition is flawed, being based on subjective arguments and lies; natural selection works very badly.
    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.

Tunes will be a system resilient to network failures.
  • In existing systems, you're never sure what happens when a hardware (particularly power or network) failure occurs, but you're sure than it will eventually occur, and crash your system with all its data.
    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.


Conclusion

We believe that all these features are linked: old


To Do on this page

  • Produce a table of contents (TOC)
  • Add lots and lots of examples.
  • Add pointers to other example pages.
  • Find a suitable format for OS comparisons
  • Point from example points to theoretical points, and conversely.
  • Point to Why a New OS article.
  • Unity....


    Back to the Tunes Home page.


    Page Maintainer:
    Faré -- rideau@clipper.ens.fr