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

This document describes how we can actually build a Venux system. Don't be impatient; start with something basic and let computational evolution do the rest.

Core

First, you need an operating system to install the software (Venux is only software and requires an operating system to work in and with). We have it: GNU/Linux.

Modularity

When I discovered modularity in software, I understood that it is the key to making good software. The principles of modularity should always be applied when we write big software. All my ideas are based on modularity. Do not forget that.

The idea of modularity is to connect components. Why is this good? Imagine a car in a single piece. If something breaks or needs to be changed, you need to trash the entire car. But by using modularity (pieces), you can change only the required piece. You can create a better piece, but you need to maintain compatibility with the other ones. If you need to change how it is plugged in, then you need to change the piece it connects to as well. The same thing can happen with modular software.

Pieces

We can make all the pieces of the Venux puzzle in, for example, a big C application. C is good, stable, portable, and the best-optimized language. But we don't need optimization yet; the system is very new, and writing pieces in C is time-consuming compared to other languages.

So, the pieces need to be simply applications. Different applications, each doing a different type of task. For example, one application retrieves data, another adds data, another parses data, another does special calculations, etc. Every application returns data as a result of what was requested.

Plug in Pieces

Like in a car, to plug piece A into piece B, it needs to be compatible. For that, every application needs to have a header describing how it works (data asked, data returned, options, etc.) and a version number. Think of them as individual programs that understand if they are compatible with each other.

Example: Plug in Pieces

Piece B knows the version number of piece C before it connects to it. If the version number of piece C is higher than that of B, then piece B checks if an update is available. If there is, it updates and asks its parent if it has an update available too. When there are no updates available, piece B checks if the specs of piece C (header of how it works -> data management) are compatible. If not, it uses the old version of piece C that is still available on the system.

Version Numbers

The version number is simply the current date (day + time + microseconds). By doing this, we ensure that a bigger number always means a newer version, never the reverse.

Updates

An update is a package, created automatically and very quickly when required. Old updates are never deleted; they are stored in a historical archive accessible by Venux if needed. Historical versions will only be deleted after a minimum number of years of inactivity.

Packages Technology

Packages need to use the NIX packaging technology. This is a package system that includes the features of both static and shared libraries. Anything compiled and packaged with NIX will NEVER be deprecated. It will always work, even after thousands of years, and you can have multiple versions of a package (application) running on the same system. You can use any of these versions at the same time, and there will never be a conflict between versions or libraries with this technology.

Evolution

Evolution is very simple: Somebody has a better idea for a piece, more efficient, faster, etc. They then write it and present the proposal/result to the Venux Operating System. Venux, like everything else in the Venus world, evaluates the proposal. It does thousands of calculations to determine if it is "good" or "bad" compared to the current system, the specs, the resources required, and maybe even the votes from humans about whether they like it or not. If accepted, 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 it is compatible, and there is no need to wait for an update. Everything continues working thanks to the packaging technology, as simple as evolution.

Communication

The pieces need to use a standard method of communication. The communication system is also just another piece of the modularity. When the communication system evolves to something better, its version changes, and its specifications change if needed. All pieces that use communication (almost all of the Venux system) know they need to be updated before they can use the new communication protocol.

As explained in the Packages Technology section, the Venux system can work with both communication protocols at the same time. This continues until all pieces using the old protocol are updated.

Interface

The interface is just another piece. It is a layer between the computer and the human to communicate in the best way possible. This piece is connected with the pieces that communicate with the data and is shown to the human through the communication system.

The Evolution rule will use the best interface too. For example, it will start with a command-line interface, then somebody will propose a better graphical one. The evolution of the system will use the graphical one after the required pieces are connected to the new one. Later, an interface that is easier to manage or has more possibilities may appear, and the same process will follow.

History Example

The first version of the Venux system has three bash scripts written by somebody in less than a day:

• data-get
• interface
• data-add

They are very basic and work simply. Running the interface, you have two options: to get data and to add data. For example, we add the data gold, then we add its specs (composition, category, atomic weight, heat fusion, etc.), and we also add silver. Later, we want to know the specs of gold, so we use data-get. It works, very simple and functional.

Later, somebody adds a new piece that retrieves all the data stored on Wikipedia, parsing the HTML pages and getting the values of every element of this world.

Later, somebody adds a new piece that calculates the impact of every piece on nature.

With this idea, somebody creates a piece for choices calculation. For example, if we need the best material to use in the sea, the Venux system will calculate the best choice: an abundant material for the current needs. It also calculates future probability needs, checks the resistance of the material with saltwater, the impact on nature, etc. This piece shows the best choice possible, much better, faster, and more efficient than a human with studies.

Later, we see that the system becomes very slow at retrieving data because we have a lot of data and we made data-get quickly; we just wanted it working. Then somebody creates a better way to store data: compressed, sorted alphabetically, etc. Eventually, somebody will present a new version of data-get with more optimized algorithms for faster searches. In the future, somebody will present an even better algorithm using probability and usage statistics to retrieve data even faster.

Somebody creates a piece to back up all the data, just like the pieces and everything.

The interface changes to something better. We can now use tags and other special features. But for that, we need to update data-get and data-add to use tags too. The interface is presented and accepted, but until data-add and data-get are compatible with the new interface version using tags, it will not be used. Some days later, somebody finds that the tags are added to new elements but not to the old elements and writes a new version of interface that requests adding tags when the element doesn't have any yet. This version of the interface is updated but has not changed its compatibility, so it is directly used by Venux.

The data is stored in XML, which is slow to parse. Then somebody writes a piece that converts all the XML data to something more binary and faster to search by data-get. Someone also writes a feature in data-get to be compatible with the new data structure, and some days later, writes another piece that manages the XML as the original ones, updating the binary versions when the XML is 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 being re-written.

Main Feature Concepts

• Filesystem: BTRFS or an equivalent filesystem with special features like snapshots, subvolumes, object-level mirroring and striping, checksums (integrity) of data, incremental backup, filesystem mirroring, etc.
• Development: Use GIT because it is much more advanced than other distributed version control systems.
• Database: Initially, we need a good way to manage data. I recommend using plain text files since they are the easiest to manage, hack, and convert. We can migrate to databases or other solutions in the future when needed.
• Languages: Since everything is modular at the application level, we can use any language. Sometimes we need optimization (C), and sometimes we need to code quickly (

Python). Evolution will handle 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 and are essential for a correctly made Venux system. If you like them, ​the full book is a good read too.

Notes

• This page was originally published in 2010