A Venux Operating System is something very simple to create and without much effort because it will be based on its own evolution just like the things in the nature. I wrote some concepts of design on this page that I think that is the best way to create a functional VOS, evolutive and non-destructive. If you want to read the functional/real example, go to the History Example section.

This Document describes how we can actually build a Venux system, just don't be impatient, start by something basic and let's the computational evolution do the rest.

Core

First of all is needed the operating system where to put the software (venux is only a software, it requires an operating system where to work in and with). We have it: GNU/Linux

Modularity

When I have discovered the modularity in the software I have understand that is the real key to made a good software, the modularity principles should be applied always and everytime we write a minimally big software, all my ideas are based on modularity, do not forget it.

The idea of the modularity is basically to connect things between themselves, why this is good ? imagine a car in a single piece, if something breaks or needs to be changed you need to trash it entirely, but with using modularity (pieces) you can change only the required piece, you can create a better piece but you need to maintain the compatibility to plug it with the other ones, and if you need to strictly change the method of how is plugged, then you need to change too the piece where it is pluged... with modularity happens exactly the same.

Pieces

We can make all the pieces of the puzzle of Venux in for example... a big C application, C is good, stable, portable, and the best optimized one, but we don't need optimization yet, the system is very new, and to write pieces in C is something pretty more slow than to write in other languages.

So then the pieces needs to be simply applications, different applications, every application (piece) do a different type of task, for example, one application that retreives the data, another one that add the data, another that parses the data, other that does special calculations, etc, every application returns data as result of what was been asked.

Plug in Pieces

Like in a car, to plug the piece A with piece B it needs to maintain a compatibility, for that, every application needs to have a header data of how it works (data asked, data returned, options, etc) and a version number. Think about it like individual programs that understand if they are compatible with eachother.

Example: Plug in Pieces

Piece B knows the version number of piece C before to connect with it, and if the version number of piece C is bigger than the one that B remembers, then piece B checks if it is available an update, if there's an update then update it and ask to his parent if has an update available too. When there's no updates available (B) then piece B checks if the specs of piece C (header of how it works -> data management) is compatible with him, if not, then uses the old version of piece C that stills available on the system.

Version Numbers

The version number is simply the actual date (day + time + microseconds), by doing this, we ensure that everytime a bigger number means a newer version, never the inverse.

Updates

An update is a package, they are done automatically and very fast when is required. Old updates are never deleted, they are stored in a historycal archiver that can be accessed with the same facility by Venux if needs to use it. Only will be deleted after a minimum of years of fully inactivity.

Packages Technology

Packages needs to use the NIX packaging technology, this is a package system that includes the features of both static and shared libraries so anything that is compiled and packaged with NIX, will be NEVER been deprecated, it will always works even if has passed a thousand of years, and you have multiple versions of a package (application) running in the same system, you can use any of these versions at the same time, never a conflict between versons or libraries can happen with this technology.

Evolution

Evolution is very simple: Somebody has a better idea for a piece, more efficient, more fast, etc... then write it and present the proposal/result to the Venux Operating System, Venux like all the other things on the Venus world evaluate the proposal, it does a thousand of different calculations of the good things and the bad things to know if is more "good" than "bad" compared with the actual system, the specs, the resources required, even maybe the votes from the humans about if like it or not, if is accepted then the operating system includes a new version that will be updated automatically by the system itself, the rest of the pieces will connect to this one if is compatible and if not then is needed to wait their updates too, but everthing continue working thanks to the packaging technology, simple as evolution.

Communication

The pieces needs to use a standard method of communication, that the communication is also just another piece of the modularity, when the communication system evolves to something better, his number version changes and his specification too if is needed, then all the pieces that uses communication (almost all of the Venux system) knows that needs to be updated before to use the new communication protocol.

At the same way explained on teh Packages Technology, the Venux system can work with both communication protocols at the same time while there's any of the pieces that still need to use the old protocol and was not updated yet.

Interface

The interface is just another piece, it is a layer between the computer and the human in order to communicate at the best way with him. This piece is connected with the pieces that communicate with the data by the communication and also by using the communication it is show to the human.

The Evolution rule will use the best interface too, for example first will exist a commandline-interface, then somebody proposal a better one graphically, the evolution of the system will use the graphic one after the required pieces are connected to the new one, then later appears a interface more easy to manage or with more possibilities, same process... etc

History Example

First version of the Venux system: there's 3 bash scripts that was wrote by somebody in less than a day, they are:

• data-get
• interface
• data-add

They are very basic and works on a very simple way, running the interface you have 2 options, to get a data and to add a data, for example, we add the data gold, then we add his specs (composition, category, atomic weight, heat fusion, etc...), and we add also the silver one, then later we want to know the specs of the gold and we use data-get, it works, very simple and functional.

Later, somebody add a new piece that gets all the data stored on the wikipedia, parsing the html pages and getting the values of every element of this world.

Later, somebody add a new piece that calculates the impact of every piece with the nature

With this idea, somebody create a piece of choices calculation, for exmaple, we need the best material to use in the sea, the Venux system will calculate the best choice, an abundant material for the actual needs, it also do calculations of future probability needs that are considered too, it checks the resistance of the material with the salted sea, the impact with the nature, etc etc... So this piece shows the better pice choice possible, a lot better, faster, and efficient than a human with studies.

Later we see that the system becomes very slow by retreiving data because we have a lot of data and we have made data-get in a very fast way, we have wanted it just working, then somebody creates a better way to store data, compressed data, sorted alphabetically, etc... At the same way that someday somebody will pressent again a new version of data-get with a lot more optimized algorithms for fast search. In again a future day somebody will present a better algorithm that uses probability and usage statistics to retreive the data even faster, etc...

Somebody create a piece for backup all the data, just like the pieces and everything.

The interface changes to something better, we can use now tags and other special features, but for that, we need to update also data-get and data-add in order to use tags too, the interface is presented and accepted, but until there's no data-add and data-get compatible with the new version of the interface using tags, it will be not used. Somedays later somebody found that the tags are added to the new elements but not for the old elements and write a new version of interface that request to add tags when the element doesn't has any yet, this version of the interface is updated but has not changed his compatibility so it is directly used by Venux

The data is stored on XML that is slow to parse, then somebody write a piece that converts all the XML data to something more binary faster to search by data-get, he also write a feature in data-get to be compatible with the new structure of the data, and some days later, write another piece that manages the XML as the original ones updating the binary versions when the XML are updated.

Some time later it is found that the binary form can't manage some special features of the XML version, we can still go back to the XML version while the new version of the binary form is writed.

Main Feature Concepts

• Filesystem: BTRFS or an equivalent filesystem with a lot of special features like: snapshots, subvolumes, Object level mirroring and striping, checksums (integrity) of data, incremental backup, fs mirroring, etc
• Development: Use GIT because is a lot more advanced than the other ones as a distributed version control system
• Database: We need in the start a good way to manage the data, I recommend to use just plain text files since is the most easy to manage, hack, and convert, we can migrate it to databases or other thing in the future when will be required
• Languages: Since everything is modular at the application level, we can use any kind of language, sometimes we need optimization (C) and sometimes we need to code it fastly (python), the evolution will do the rest

EXTRA

When creating the Venux system, we need to remember the rules of the Art of Unix Programming, don't take it as a joke, ​these rules are full of wisdom essential for a correctly made Venux system, if you like them, ​the full book is a good read too