|
Version: 1.02 Last modified by Venux on March 17, 2010, 6:09 pm
The system is designed to solve key problems with today's society and also suggests the complete re-design of modern network also known as The Internet.
The goals of the Venux;
- Preservation of human history
- Unification of information into useful, single system
- Intelligent automation of physical tasks world/universe wide
- Freedom and accessibility of information for everyone
- Simplification of programming at core so it will be easy to learn and use
Venux was designed to uphold the values proposed by The Venus Project. In a resource based economy, humanity survival and prosperity is based on an ability to invent and use resources wisely. Information, also can be referred as knowledge, in my opinion is one of the most important resource humans have. Of course, there are very valuable resources that considered a necessity of life, such as air, food and shelter. But, at some point, if/when humans will develop technologies that can produce air, food and all other necessities in any quantity we need, knowledge of how to produce it will become more important than resources themselves.
Having said that, I believe that knowledge should be preserved at all costs! Should be organized, accessible and universally useful! The system I'm proposing is also designed to preserve our history! There will be NO changing of history!!! We should learn from it, not modify it for political games. I have spent great amount of time, implementing algorithms that will prevent modification of history for any purposes. Even after release of the source code, no body, including me, will be able to change OUR history! Period.
Venux proposes many new concepts the way information is stored, organized, processed, transformed, accessed and transported. Many new concepts and algorithms have been designed to achieve the best performance possible at the moment on a software level.
General Venux Architecture
Venux unified under X key components that make whole system work. Each component can be controlled by XML in structural way. The system also proposes new kind of programming concept - Hierarchical Structured Programming (HSP) which will be discussed later. Venux can be viewed as large directory/database/program of knowledge where each "topic/function/program" is represented as file in specific directory, all of it called resources.
Everything in Venux can be accessed and modified by XML at any level of structural hierarchy.
Knowledge Organization
This is a list of basic directories;
earth/ earth/resources/ history/internet/ history/internet/web/ history/internet/irc/ history/internet/irc/dalnet/#russian history/internet/irc/efnet/#chatzone history/radio/ history/tv/ technology/ technology/xml/ technology/xml/automation/ technology/xml/functions/ technology/xml/frameworks/ art/ art/music/ art/movies/ people/ people/profiles/ people/profiles/SDFG-DFGH-2345-FGHF-45SS/DFGK-JHBI-UYTS-D3TR.xml science/ science/math/ science/physics/ science/chemistry/
and so on...
Venux can be made of millions/billions of root directories, but, with time, it will organize itself by its own design.
XML - Extensible Markup Language
Many IT people today believe that XML is only suitable to represent documents, mostly of textual nature, sometimes modify them using various extensions such as XSLT and/or xPath. But, in reality, XML opens up a lot more possibilities, such as storing information thus structuring it, transport information and actually writing complex programs with it.
XML's potential for programming was much unexplored because many established programming languages already exists. Many books exist as well as bunch of software already written, source code of which freely available on the Web.
But, all established technologies can never perform as efficient as they possibly can as they are build on concepts of individualism. All computers, servers, phones, devices connected to the internet, are designed for private use, thus, many security levels exists in systems which limit accessibility of information. Because of competition, a lot of different, not compatible systems are trying to operate together either directly or indirectly. In most cases, all incompatibilities between competing parties are resolved through other extensions that are designed to understand one system and transform requests to another. Something like different human languages requires translators to "remove" language barriers.
These barriers made the whole system to evolve into complex, unmanageable network with thousands of different, incompatible technologies trying to achieve whatever they are designed to achieve. Without unified system, a modern programmer has to code a website in at least 4 different languages such as PHP/MySQL/HTML/JavaScript. Each technology has its own rules, syntax and logic, incompatible to each other but more or less integrate-able into one another.
Modern server/desktop operating systems (MS Windows - Respect to Bill Gates, Linux - Respect to Linus Towards, Apple - Respect to Steve Jobs, and others, please excuse me if I forgot anybody) are designed for individual use. Because of that, before accessing any file in the system, various checks are going on such as if the accessing program have a right to access that file, is that program runs under a user account allowing that file to be accessed, either another program is already working with the file and so on. Operating systems usually work with huge number of files simultaneously, thus whole system slows down dramatically. Leaving out other problems in modern computer architecture, such as limitations of speed, memory, storage medium speeds (HDD) make modern computers to startup sometimes up to couple of minutes. And yet, potentially, modern Quad core CPU processes up to 8 billion operations per second!
In these conditions, organizations producing software have to deal with a lot of problems, proposing new technologies that will solve problems created by technologies already in existence only to find out some time later that another component is needed to solve X amount of problems created by previous "solutions".
And all of this ... is powering our Internet!
This process of patching and updating, virus infecting, antivirus installing, virus removing, routers reconfiguring, system reinstalling processes are very un-efficient way to use information.
Having said that, Venux proposes a simplified XML language that is somewhat compatible to W3C standard and yet is not designed to represent information, rather process, produce and modify it.
So, why XML?
Whole geniality of XML is not in its W3C standards, it is simply "<", ">" and structurization that make XML unique. Name-spaces, DTDs, Schemas and other things in XML v1.0 are symptoms that XML evolution is going in a wrong direction because it is structurally incompatible to logical technologies that are being used. Venux proposes a simplification of XML, unification of all components into single, XML based language that is easy to learn and understand.
Here are 20 reasons why whole world's information should be unified under single, manageable, understandable and most importantly changeable format;
- Easy to learn & understand code written by others;
- It is a simultaneously human- and machine-readable format;
- No forward/backward incompatibilities;
- No incompatibilities between programs;
- Data can be stored, processed and transported all in one format (no need to deploy different methods);
- XML program can be interpreted by a device/computer/entity, for which, originally, the program wasn't designed for (unknown tags can be ignored or supported in an incomplete way);
- New features can be introduced without breaking already working code;
- Platform (Software/Hardware) independent, thus immune to changes in technology;
- Information reusability (single source, multiple outputs);
- Targeted update/retrieval (programs/data accessed & updated in a structural way);
- Allows the same paradigm of modern logical languages (complex mathematical expressions, metamorphism, loops, logical statements and so on);
- The hierarchical structure is suitable for most (but not all) types of documents/data representations;
- It supports Unicode, allowing almost any information in any written human language to be communicated and/or processed;
- It can represent the most general computer science data structures: records, lists and trees;
- Its self-documenting format describes structure and field names as well as specific values;
- The strict syntax and parsing requirements make the necessary parsing algorithms extremely simple, efficient, and consistent;
- Provides user-selected view of data;
- By design, reflects structure and semantics of information allowing better searching and navigation;
- Allows single document/program to be used many ways;
- At any point in the future, if/when humanity will find a better way to store and organize information, whole human knowledge can be "easily" converted to new form/medium due to XML's structural nature
There are negative sides in XML, such as informational overhead comparing to the same data represented in binary form but all of these “side-effects” are eliminated by the fundamental design of the Venux.
XML Syntax
There are 4 types of tags in XML, each tag opens with "<" and closes with ">". Each type of tag has its specific purpose.
Types; - Functional tags
- Informational tags
- Complementary tags
- Comment tags
Functional tags
The format of functional tag is as described in W3C standard. Each tag name is a name of the component that is going to be contacted/connected/accessed, then, colon ":" and the name of a function that is going to be called from the component along with parameters to the function.
Example;
1.<usd:import location="earth/usa/florida/robots/model-abc44/execute.xml" select="startup" />
USD is storage medium where all resources of information are stored. "import" function to this component means to get/download/import a XML resource at location "earth/usa/florida/robots/model-abc44/execute.xml" and select internal structure "startup".
This particular tag will load information from specified location, selects part of a XML document/resource, along with child tags and executes it. Anything that is being imported or exported is a resource even if it is a part of another resource/file. So, this tag can initiate a chain of commands in "imported" resource.
Example;
Let's assume we have a XML resource at address "earth/usa/florida/robots/modelabc44/execute.xml" which looks like this;
... 1.<startup>
2.<xtr:for-each location="people/profiles/*" select="preferred-food">
3.<usd:import location="art/cooking/recipes/meats/*" />
4.<usd:import location="art/cooking/recipes/fruits/*" />
5.<usd:import location="art/cooking/recipes/vegetarian/*" />
6.<xtr:for-each>
7.<startup>
...
The imported resource above, will initiate a loop through directory "people/profiles/", accessing all resources that have an internal structure starting with tag "preferred-food".
XTR - XML Transform
This component is designed for, as name suggests, modifications of XML structures. There are 5 functions that allow this component to process XML resource/part of resource in any desirable way.
<xtr:value-of> element extracts the value of a selected node.<xtr:for-each> element allows you to do looping in XML.<xtr:sort> element is used to sort the output.<xtr:if> element is used to put a conditional test against the content of the XML output.<xtr:choose> element is used in conjunction with <xtr:when> and <xtr:otherwise> to express multiple conditional tests.
XTR component is relatively standard to XSL technology proposed by W3C standard but views information a little different.
More details and examples of Venux XML programming are presented in the second document titled “Venux XML”.
X64
Every thing in Venux is stored and transported in X64 format. This format contains information in a transformed state. The algorithm on which it is based allows transformation of any state into 64 bytes representation. This transformation is possible because of "structural paralysis" of the algorithm itself.
Every XML resource, movie, music, picture, document is transformed and stored/transported in X64. On request or update, each resource transported to a requesting person/program and transformed back into its original state for review/execution.
In modern science, such a compression is impossible, but, in reality, it is not a compression, it is a transformation from one state to another. It is not based on any known compression algorithms nor is it limited by any known barriers that modern algorithms have.
Proof;
Fact: There are 256 possible combinations of 0's and 1's in a single byte of information. Fact: There are 65536 possible combinations of 0's and 1's in 2 bytes.
16,777,216 in only 3 bytes and 4,294,967,296 in 4! In only 5 bytes, we have more 0's and 1's than people on this planet. 6 bytes contains more 0's and 1's than there are starts in a Milky Way galaxy.
In only 22 bytes, there are more combinations of 0's and 1's then there are atoms in entire earth, which is 133,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000!
In 30 bytes, there are more combinations than there are atoms in a whole Milky Way galaxy.
64 bytes of data represents more information that we know about universe today and probably all alternative ones, if they exist.
USD
Venux is based on a single storage medium, called USD. USD stands for many things, such as "Unlimited Space Drive", "Ultimate Server Disk", "Unified Storage Device" whatever you prefer. All interpretations of storage, disk, drive, space are correct, because it is basically an infinite, distributed storage medium. Everything in USD is resources. Every file, movie, picture, document is a resource. All resources are organized in directory structure. Resources can be created and updated, but cannot be deleted. Deletion happens automatically, depending on an attribute of a resource. As for updates, each previous copy stays in a system, for as long as resource is relevant, which can be accessed with historic parameters. Some resources will never be deleted, such as historic information and some will be deleted after being read only once.
Resource Attributes
In USD, each resource has an attribute associated with it. There are 4 attributes;
- Historic resources are never deleted! Under any circumstances! Humanity can store whole history in digital form under resources with this attribute. As something always happening in the world/universe, resources with Historic attributes will always be a dominating part of Venux.
- Read/Write resources are the most active part of USD as they will always be updated. All programs and data will be stored in resources with R/W attributes.
- Active/Task attribute is managed by UTC (Universal Task Control) component.
- UniversalID attribute is designed for user accessibility and discussed below.
HSP - Hierarchical Structured Programming
Structural programming is somewhat resembles object oriented programming (OOP) but instead of manipulating classes and objects, selection of structures is taking place. Venux infinitely hierarchical, because of directory-like structure, but, unlike modern operating systems, highest directory doesn't necessarily most important one. The most important thing in hierarchy is a point of execution. In Venux, there are no independent projects, any XML resource, at any directory, can be imported one into another. What this basically means, that, Venux is one big project. Whatever you design for your own needs, can be used by another project without copying someone's work, simply linking to another program. No project have a name, it is a resource(s) located at some directory.
For example, person A designs a spell checker program, person B can design a word processor program and link A's spell checker into it, having a cool word processor with a spell checker in his/hers own possession. Yet allowing person A to use hers/his creation and improve it without even knowing that person B using it. Person C can design an email program and integrate B's word processor with already linked A's spell checker with almost no effort. At the same time, all 3 projects that are not dependant on each other can be improved by other people making a good quality email program for everyone to use. Some programs can evolve into frameworks of basic functions and algorithms that later can be linked into more complex programs.
Resources that are no longer in use, become irrelevant, thus automatically deleted. Some frameworks for specific tasks will emerge with time, they will be used for some period until humanity will find a better way to achieve the same task therefore completely different framework might be needed, thus old framework becomes obsolete. Most of XML programs in Venux are Read/Write resources. By default, each R/W resource gets deleted by the system upon 6 months of inactivity (including all historic copies). Thus, if all programs abandon usage of some framework it will be removed. Venux treats all XML resources separately, if some files in a framework become obsolete; only those files will be deleted.
This architecture creates automated, unneeded resources deletion cycle that free people from ever manage and/or cleanup Venux, also, preventing imposing rules on the Venux as a whole to keep it organized. At the same time, Venux design creates an opportunity for everyone to create whatever is relevant for themselves and improve everyone's life simultaneously.
UTC - Universal Task Control
Venux design proposes not only unification of information into single, manageable, controllable environment but also unification/coordination of physical tasks. XML, in its nature, structural by design, so all tasks can be organized. UTC allows creating and accessing resources with attributes (Active/Task). Active Tasks are different from other resources with their ability to be read only once. As soon as performer reads what to do next, resource gets deleted by the system. Performer can be a physical machine, a program performing some task or any intelligent agent that is connected to the system.
Each performer, designed/developed for any kind of task(s) can coordinate itself with other performers/machines, allowing doing their jobs. UTC can control virtually any number of machines; any type of machine that can interpret XML, can be connected to and controlled by the UTC. Each machine doesn't have a need to be intelligent to perform its tasks; it must have a physical capability and XML interface that can control its functions. Thus, even simplest machines can act and perform intelligently, be aware of each other, cooperate with each other and most importantly, have an access to the whole world's knowledge to solve problems needed to perform its task(s).
An example;
A refrigerator, connected to the Venux, may run a program at "technology/xml/frameworks/refrigirators/model-12/start.xml" which will execute a startup program for a refrigerator's functions. In this example, refrigerator, according to a startup program will upload information about each item it contains. In tern, another program can generate a list of possible dishes that can be cooked from available items. Assuming refrigerator has a physical capability; UTC can guide an unintelligent refrigerator to plan, process and prepare food for a person when he/she gets home. At the same time, all recipes for dishes can be used by other programs, for different purposes and supported by people who have nothing to do with refrigerators at all. Any program or function, created for any purpose is automatically contributed to the overall functionality of the Venux.
With this design, everyone becomes a contributor to everyone else!
UTC can control machines to build houses, build/control power plants, prepare/grow food, control resources extraction machines and even control machines that build and/or fix other machines.
As Venux being open, controllable, unified resource of information, with every person on the planet having free access to any inner-workings of any machine and/or program, with an ability to change anything, situations as described in "Terminator" or "The Matrix" will never happen!
Machines Sustainability
Now, the theory; If machine A will be able to repair machines B and C then either machine B or C should be able to fix machine A, therefore leaving one machine to perform specific task(s) to the best of its abilities. Having bunch of A's, B's and C's will create sustainable network of automated workers performing specific tasks.
Number of machines should be proportional to the amount of work that needs to be done, ability of a single machine to perform its task(s) in reasonable timeframe and fail rate of a single machine. Fail rate can be calculated statistically over some period of time or mathematical research can be applied to find the best way. I believe statistics will do well because improvement of machines will minimize fail rate and naturally, statistics will force machines to re-organize.
Organization of machines under UTC also proposes that most machines can be made from relatively standard components. Such as XML processor (XPU), Venux connector (VC), sensors that transform world's information into XML and functional devices needed to achieve tasks. At any state, machine performing a task can access Venux for guidance, complex program will be run, current task can be read and the next action for a machine can be calculated taking into account, what machine does, what it needs to accomplish, what machinery is around it, own ability to perform tasks (check if all sensory works, if there are any damages in any part of a machine) and so on. As damages/defects detected, requests for repairs can be initiated with current GPS coordinates and machine's serial number. Another machine can get to it, guided by the UTC, and repair it, guided by the UTC.
Another useful feature that can be added to fault detection is a ping/pong mechanism. If machine's power supply fails, machine will not be able to request assistance. Machines traveling along one another can send each other signals (ping), sound, light or anything that do not occur naturally and does not disturb people, animals, plants and nature in general. On each such request, machine(s) sensing it should respond (pong), doesn't matter who initiated it. If machine dies because of power failure, it will not be able to respond to a ping request so other machines will pass a signal to the Venux with coordinates for emergency fix-ups.
I'm not an engineer so I can only speculate but, reasonably, all machine components should be designed in a way that each can be identified with a sensor, easily detached/attached, can be validated by a ping/pong mechanism thus making repairing machines to perform fast and accurate.
UID - UniversalID
As the name suggests, it has something to do with identification. In Venux, there is a special kind of resource that can be encrypted fully or partially. Resource cannot be accessed by name; it can be accessed by directory/location/address, username and password. Name of a resource is created by MD5 generated hash from username and password, a directory is created with this name and encrypted resource stored in it. Everything is this directory is encrypted by username and password. By directory and/or file being generated, no body will know which ID belongs to which user. This is done so; any person on the planet can have some privacy :)
Now, by design, this resource, allows creating Universal User Profiles programs without invading anybody's privacy. Encryption happens on a client side, Venux only stores information associated with this resource. Universal Profile program allows any person to have hers/his own private space where users can store private documents, private pictures, favorites as in modern web browsers directly from whole history and anything anybody wishes. There is one drawback, the passwords cannot be recovered because it is not stored anywhere. This concept increases security for everyone and make people to take their accounts seriously because if password is forgotten, no body can help you!
Universal Exposure
Universal Profile program may allow any kind of exposure the user wishes to share with the world. Since, UniversalID attribute allows full of partial encryption, by default, whole profile starting from user's name can be encrypted. Thus, anybody connected to Venux may see that resource exists but it is 100% anonymous. If a user prefers to be completely private, it is his/hers basic right. Fine, be like that, at least, people/machines will know you exists so resources will be provided to you. If, on the other hand, I don't mind to expose my name, age, sexual preferences, hobbies and so on, it is my basic right as well. Thus, everyone may access my information; communicate with me, of course if I feel like talking to anybody. By design, the system can have millions of people with username "Eugene Nosko", as long as passwords along this login name does not cross, these will be different profiles. The chances of cross or accidental password guess is very low. In case if/when this will happen, I believe "victims" will change to other profiles with other passwords.
So, in other words, Universal Profile is your email, your personal book where you keep your notes from everyone, your personal files, music you like, movies you planning to watch, express crazy ideas you have.
As well as Read/Write resources, UniversalIDs expire within 6 months of inactivity. So, if a person forgets the password, will not access an account or dies, it will be deleted. Since it is no longer relevant, nobody can decode it without username and password. Everyone has a free time from Venux for 6 months on the other hand, without worrying about their private things.
Social Restrictions
The age of an account provides certain privileges. The older the Universal Profile is, the higher your access to the root. In other words, as you register a Universal Account, you have an access to everything, you can explore everything, but you can't modify everything, in any directory that is 4 directories (in USD) left to the root! You won't be able to change anything in directory "earth/resources/", you won't be able to change "art/movies/". You will be able to change everything in your profile, explore and access anything, you may use any program, see how it works, participate in topics, write your own programs, at directory higher than root plus 4. Every 6 months, user's account will be allowed to go closer to the root by one point, thus, in 6 months of an account, you'll be able to participate in any project at a root+3. In two years, the user will have a full access level to the Venux, with an ability to modify anything!
This law is designed to restrict people from violent behavior either intentional or unintentional towards the system. Venux’s structural organization must be preserved, should be clean and understandable. Thus, if everyone given an opportunity to create anything at root, many people will experiment with their programming skills and might create billions of resources at root that will expire in 6 months. At the same time, new people joining Venux will see bunch of none-sense directories, explore them thus extend their "auto-deletion"/expiration cycle. In this case, navigation within the system will be difficult.
The restriction, teaches people to respect the system since the person needs to spend 2 years to be able to go to the root. Along this time, any person can do as many experiments as desired (at higher directories), learn as much as possible.
People who are not technical, who only want to use Venux to learn, listen music, watch movies, communicate with other people, within 2 years will have the same right to the root as everybody else. Even thought they do not have any experience with XML.
Restrictions in accessibility of information for minors
Personally I believe that we should not restrict minors from any content. We as a society should teach minors about real world, including sex/pornography as it is the most natural thing people experience through their entire life. We should present it in respectful matter; teach about sexually transmitted diseases, love, child birth and everything associated to the topic. But, I always had strong opposition from most of the people I presented this idea to so I had to figure out a solution.
I believe that practical solution is to design a serious of questions that will be presented to everyone as “restricted” content is being accessed. Once a person answers some percentage of these questions right, she/he might be considered as an adult. If not, content will be restricted.
These questions should be designed in a matter to identify person’s life experience to some degree. As practice show, 10 year old people do not have the same life experience as 18/25 year olds. On the other hand, some people mature faster than others so as person is mature enough for this kind of content at 14 and another is not as mature at 20, why should we restrict the younger one thus paralyzing his/hers knowledge acquisition and allow older to view/study the content? I knew everything about sex at 13 (as most kids do, they just act innocent) and absolutely nothing about love. Thus got hearten many times through out my life because information was kept away from me and I didn’t know how to deal with it.
Even thought I present this solution, I believe we really need to reconsider it!
Social structure & dynamic control of the Venux
Everything in Venux is a subject to interpretation, making whole system under control of majority, not minority, hence it is the most democratic system ever build. Every person has a right to participate in any topic. There can be infinite number of topics going on at the same time. Topic is a forum like concept that allows people to discuss any program or function at any directory.
An example;
Person A builds a program at resource "technology/xml/experimental/my_stuff/test.xml". Person B comes along and modifies the program to, preferably better one, but, person A doesn't like the change and since being a direct member of a program/topic, denies the request for change. In this case, B's copy of a program stays in as a historic copy and keeps connected to B's profile as a vote for this version of a program. Another person C, joins the topic, sees all members, what are they voting for, inspects each case, may suggest another solution with modifying existing program of person A or B, or, support B's version of the program. In case of support of B's creation, program written by B becomes a default copy of a resource in this directory. Because 2 people voted for B's version against 1 A's. Now, person A may leave the project, and never come back or, invite hers/his friends for support. If more people will support person A, his/hers version will be dominating resource at specific address/directory.
As Venux evolves, there will be comminutes on all topics we can imagine. Some small, experimental programs may have 2 to 5 members. Some important programs may have thousands of opposing solutions with all people voting by proposing better solutions.
In this environment, any person may come to any topic and express his/hers view in a workable, not vocal way. There will be no propositions; there will be solutions with different points of view, without anyone shutting up anybody else.
This dynamic concept also filters out inactive members. As in example above, if person A doesn't attend the project/topic within 30 days, his/hers profile automatically looses a link to the vote thus A's vote no longer relevant in that topic. This is done to ensure the topic will not be paralyzed with thousands of voters who attended and voted in topic a year ago, all forgot about it but still voting for a program that way too outdated. If anybody lost an interest in a project/topic, you are not obligated to anything, just leave and let other people to evolve it. If some of your principles are being touched upon, you may fight for years, attend the same projects all the time, propose whatever you believe is right and try to convince the majority of users in the topic to get on your side.
Unlike today's Political System, one person gets elected to solve all problems, Venux proposes to all people to solve problems by voting for each other's practical solutions in the framework that des not “minimize” anybody.
Venux Accessibility & Usage
So far we discussed technical organization of the Venux. From regular, non technical user point of view, the system is designed to be easy to use, accessible and organized into 6 major categories.
- Earth
- History
- People
- Technology
- Science
- Art
Now, for simplicity of access, I propose to use a cube, something like XGL technology with 6 sides, which can be easily rotated, each side is designed for specific view. I believe this is the most efficient way to present most important things in life.
This is just an example of a cube-like desktop based on XGL technology.
Another angle;
Another example
Let's start from Category People
Every user, registered with Universal Profile can use Venux; communicate with other user, either by messaging (something like instant messaging), video chat and voice chat. No user can write/contact another user without permission. Users can lookup one another, search database of profiles (assuming people do not use complete account privacy). Users can meet each other, introduce one to another and have a complete social life if needed to.
Category Earth
The Earth category should be educational, all cities, their locations, locations of resources, photography/real-time view from space, access to real-time public cameras in any city (which by the way should be stored in history so future generations can see how cities/earth evolve), information about resources. Life of animals, plants (all of these can link into videos at "art/movies/english/nature//"), current earth population (can be calculated by amount of Universal Profiles), information about resources, how they are produced (with information about machines gathering/harvesting them) and in what technologies particular resources are used. Of course, logically, if the user clicks on particular technology, she/he will be transported/rotated into category Technology where everything about that and other technology can be learned. One of the important things is sustainability counter. This should be placed and visible preferably all the time as a user browse category Earth. Venux proposes that a program can be developed that calculates at what rate society grows (according to Universal Profiles), resources availability, resources consumption, energy consumption, current capacity of energy that can be produced. In theory, we as society should be able to calculate a sustainability number that represents how long we can sustain if leave everything un-altered. Let's say, counter shows 100 years. Improving anything should theoretically increase that number.
Here are 2 theories;
Let's say we'll add more solar-batteries to whole system and connect it with Venux. More energy means more machines can be powered thus produced and powered! As more machines available, more work can be done and so on and so on. Sustainability number will at least in theory grow.
In other case, we'll modify some common machine's component, we'll find a way to produce it out of more available resource, which we have a lot more in nature, or we can produce it cheaply, out of common resource which we have a lot, or, it is much easier to extract, less machines required to produce/process it, with actually lowering power consumption on whole system, and then, as a side-effect, same process as described in first theory, more power in the system means more work that can be done, new machines created and so on, thus improving sustainability number even more rapidly.
Of course, to achieve it on a global scale, this program will be designed after World Unification. But, sustainability numbers can be calculated for separate cities as they emerge and new technologies applied.
There will never be financial crisis, recessions, depressions, unemployment as everyone on earth will be able to be free of work, be sure that tomorrow is covered (not because some politician said so, but because anyone can see that everything is stable for xxx,xxx years and the number is scientifically proven).
Category History
As name suggests, this category should contain whole human history, in simple, searchable manner. Any Venux user, is able to select a date range, let's say from January 2010 to February 2011 and experience, web, radio, TV, internet chats (public ones), search engines as they were at that period.
History can be searched, thus Phrase Based Indexing is used to achieve topic relevancy.
Phrase Based Indexing is based on co-occurrence and co-exclusion (duality) mechanism. All historic information, as being recorded, is being indexed at the same time. The base of the mechanism is simple.
Theory; 90% of websites containing keywords/phrase "Bill Gates" most likely will also have a phrase "Microsoft", thus, co-occurrence of common phrases. At the same time, phrases "Bill Gates" and "Play Soccer" most likely will not co-occur in the same document. Thus, they are co-excluded. Based on these principals, Venux’s design for historic resources does collect, extract keywords/phrases out of it, stores resource in X64 and then builds an index of newly added/modified index. Common phrases, such as "did you know", "on the top", "from there", "Copyright", "All rights reserved" e.t.c are ignored. These phrases are almost in all documents, they are always co-occur and co-exclude at the same time in relation to other phrases. With removing of common phrases, a useful list of phrases emerges with a network of phrases linked to each other as one, topic oriented network of knowledge.
As user searches for let’s say “Microsoft”, the user will be able to find everything on it ranked by PhraseRank technology, in addition to search results, the user will be suggested to look into “Bill Gates”, “Windows Vista” and all other highly associated phrases to a given keyword.
Category Technology
Now, this is an interesting at least for me as being naturally a technical person. Technology should be organized in such a way that any known technology might be explored in details. Technologies should be linked with available resources and their power consumptions, if any.
For example;
We have a technology called an iPhone. Let's assume that we have a complete knowledge of how to build it, we have the resources. All we need to do is to run a program that will calculate how many iPhones can be produced from available resources, for every person on the planet.
If needed, complex program can be executed to organize all resources extractions machines (that are not busy with other things), all resources processing machines, to get, process, convert and produce needed amount of iPhones as well as distribute them to everyone. Fully automatically! Of course it is a dramatization, we have more important priorities to do first, but, linking of technologies, their power consumptions, resources, all together, will help us to be informed of our own abilities as a society.
Category Art
Here are my 2 cents. All music, movies, pictures, musical books, art galleries, (links to anything about art from history), philosophy and so on, goes in Art. Music must be organized by language, year, style, artist/band. This structure allows developing a personal player inside Universal Profile where every user will be able to search, listen, build own links to music in form of play lists. As user browses any category, player can play music adding overall enjoyment while using Venux.
As for movies, similar structure is required. Thus Universal Profile will allow everyone to enjoy movies, which, will be started/previewed on request, without waiting for hours/days for them to download, since they are all in X64 format. Each user will be able to have a private collection of favorite movies, organized by whatever user wants them to be organized.
Similarly, digitized art related books; art related technologies should be presented to the user request. And again, as user selects technology, she/he will be transported/rotated to category Technology where user will be able to learn anything about it.
Category Science
This category should be designed in a way to improve efficiency and elaborateness of science. Each topic, such as Math, Chemistry, Physics e.t.c may be represented in organized, easy to learn fashion.
Every topic should have full information starting from basics, concepts of which should be linked to technologies where they are applied. Different points of view should be expressed (alternative algorithms) to the same problems.
As science, in its nature is not created, rather discovered by people, we should always keep this category up to date with the most recent findings. None of us know what we’ll find out tomorrow so it is pretty much important to keep it organized. To allow people to learn and be attracted to science, it should be linked to videos from “art/movies/science/math/multiplication-table/basics.xml” where video materials will be presented by people who like to teach and want to reach as many people as possible with their point of view.
Practical Implementation
At the moment, Venux is designed as a monolithic kernel, SMP (Symmetric multiprocessing)/Multi-core, multithreaded, network aware operating system. Unlike modern operating systems mentioned above, Venux OS is simplified, reduced, optimized platform that is made of 3 components.
- XML Processor (XPU)
- Venux Connector (VC)
- USD
XPU - XML Processor
At the moment, XPU is designed for modern AMD64/x86-64 which is actual parser that processes XML and executes its commands. This design amplifies processing speeds way over all other Operating Systems that are based on concepts of individualism. And yet it is NOT the most efficient way to run Venux.
Modern CPUs are logical processing units. Whey know many commands (hundreds that are documented, don’t know how many there actually are), they can (in theory) perform any logical operation but in practice are limited by speed. Complexity of modern CPUs are growing with each year and as side effect, instead of reduction to basic algorithms, more redundant features are added.
Modern CPUs are multi-core, can run up to 8 billions operations per second (8 GHz) and yet, software execution slows down, since it is being emulated on the hardware level. Programs have privileges to the hardware in some structure. The basic program, called “kernel” usually plays a role of organizing all other programs into some structure usually called Operating System. This program takes care of all computer resources management; such as how much memory needs to be allocated to what program, if that program has a right to access that file e.t.c. Over the years, there has been tremendous leap in technology but it still takes the same amount of time to boot, for example Windows Vista on modern multi-core CPU and Windows 95 of original Pentium with single core, 66/100 MHz Intel based chip. This is the direct evidence that we should reduce/simplify software and hardware in order to achieve more efficiency; And that’s what Venux does naturally by its own design.
“Emulated” XML parser, as efficiently as I think I designed/coded it, can NEVER perform as efficient as XML parser based on hardware. Instead of emulating the parser we need to develop a hardware based XML chip. Instead of executing 8 billion operations to emulate the chip which actually processes 50 million of XML tags per second, we can claim 8 billion XML tags per second and more and even in multi-core fashion.
VC - Venux Connector
As stated above, all informational resources are transported in X64. Modern packet-switching technology (also known as TCP “Transfer Control Protocol” network) which is the base of the internet, allow transporting information in chunks over randomly connected architecture. Any device that can interpret TCP can exchange information with any other device. The TCP concept was designed to transport information over “unknown” source; cables, radio-waves, Bluetooth and so on. This is all done by check summing of the data that is being transmitted. Every chunk of information (called packet) has an associated header information containing route/destination of the packet and its integrity number. This number is calculated by a checksum function such as CRC32 or Adler32 to ensure a correct delivery of information. As information travels via radio wave for example, it can be altered by something else transmitted at the same frequency thus may damage the data. After a receiver gets the chunk, it can calculate an integrity number and check against claimed number arrived with the packet. If been altered/damaged, these numbers will not match thus receiver requests from sender to resend the information. It works great over all information transportation mediums we tried such as cables, radio-waves, bluetooth, light, sound.
This architecture, even though was designed more than 40 years ago performs GREAT but used wrong.
VC alters transportation of information in specific way that allows devices to communicate at very high speeds. At the moment, VC is designed at software level and performs incredibly fast but can be further improved by porting it at hardware level to increase speeds billions of times from what it is today.
We can consider transporting X64 resources over TCP with a little modification that will allow devices to communicate with each other either they are Venux/VC aware or not.
Example;
Device A (based on VC) connects to device B and starts sending information. Now, device A assumes at first that device B is also VC compatible, sending information the same way, in X64 form and with integrity number calculated by proprietary hash function. Receiver B, gets the packet, tries to validate it with standard TCP hash function and since different hash functions produce different integrity numbers, the receiver will request sender to re-send data again assuming data was damaged. In this case, device A can switch into standard, TCP packet switching mode and send information as it is being sent over the internet now. On the other hand, if receiver B is actually VC compatible, it will send information to the sender that transportation is complete. Whole transaction, no matter how “big” amount of information there is, can be transported with 2 packets each of which is 64 bytes + header. Thus all of devices, connected to the Venux may operate in traditional or VC optimized way. This kind of optimization improve speeds drastically, naturally forces all devices to integrate VC technology. At the same time, VC is backward compatible to ‘old’ devices that are not aware of Venux.
Another concept that proposes an improvement in transportation speeds over the light is based on layering. The way modern fiber technology is used is efficient enough to send information close to speed of light. Information is actually traveling at the speed of light but receiver, as sophisticated as it might be cannot receive information at those speeds.
Layering suggests transmitting of information in different colors! As we know, information is represented in 0’s and 1’s thus, with fiber, data is transported by (1 – light on, 0 – no light) or more light is 1, less light is 0. If we’ll allocate 4 different colors, we can send 2 bits with one light impulse. Let’s assume;
00 – green 01 – red 10 – yellow 11 – white
Thus, sending an impulse in red will mean 01 to a receiving end. We can also look at it as sending information twice as speed of light since 2 independent peaces of information were sent at speed of light with one impulse.
Allocation of 8 colors allows us to send 3 bits with one light impulse. 256 colors will transmit whole byte (8 bits) and so on. As colors range (in theory) is unlimited, then in theory we can send information unlimited times over the speed of light.
USD Component
USD is an actual hard drive (HDD) that is formatted in special way to efficiently store X64 resources. Resources are stored at their locations calculated by CRC32 function. There is no such a thing as file-system. Resource at address “art/paitings/test.xml” produces let’s say number 345876234 by CRC32 algorithm so USD stores resource under this location (sector) on the hardrive. X64 stream stores whole directory transformed in it with all its history changes/copies. In case we want to access a resource from that location, USD converts address using CRC32 function to get to location and accesses it.
Venux is a distributed system so, USD employs something I call independent awareness. Each server in the network can calculate what others are doing. Without centralized authority! Just like USD calculates addresses to access and update resources locally on HDD, it also calculates on which servers they are should be stored. At this moment I decided to store 8 backup copies of each resource spread across whole network and calculated by awareness algorithm. This decreases chances of any data loss since chances that 8, geographically distributed servers, will go down at the same time is very low. On update, each copy is updated and on increase of servers on the network, it slowly adopting it by re-calculating new addresses for resources without compromising data loss and/or efficiency! That means, we can have 20 servers linked together, operate under full capacity, with several thousands/hundred of thousands of users/machines, process information at the same time and we can maintain it in the state! As servers go down for any reason, we can simply install Venux OS on clean machine, connect it to Venux and it will adopt it, meaning old resource addresses as being updated will consider storing resources on new added server calculated by awareness algorithm.
An example;
User/program connects to server A, requests for or update resource at “earth/history/violence/war/define.xml”, the address of the sector on HDD for that resource location is 34587623 but, by that number we can calculate addresses of other server(s) we need to store resource by simply calculating 8 times the CRC32 values of the previous value. And that’s exactly what awareness function does, it simply calculates array of 8 numbers (server locations as they are all have unique numbers) that are currently online and ready to accept update/request! Of course if any user and/or program wishes to access specific resource, depending to what server user is connected to, USD will calculate where copies, on which servers are located and Venux Connector will ensure fast delivery to a requestee server/user.
USD “prevents” data loss in case of sudden decrease in servers (in case tsunami hits one of our cities and knock down a local Venux network; Which I believe we should prevent by city’s design) Venux will decrease in speed and will be forced to relocate resources. It can be viewed as a self-defense mechanism and sustainability to current conditions. Each server, on its own, as pass resources through it will recalculate new locations to store X64 streams and if we’ll look on the whole picture, any increase/decrease of physical sources (server) connected to the Venux, it will act adoptively/sustainable. On the other hand, as we’ll grow, add more servers to it, it will exponentially increase in speed, response times, ability to hold more people and machines connected to it simultaneously.
End of part 1
Well, this was a general overview; There are 2 more documents coming, one is “Venux XML” with lots of XML examples, how to code for Venux, how to automate things/machines and basic Universal Profiles programs. Along the second document, the prototype technology will be represented which I will try my best to run on hardware I have or hardware that will be sponsored/donated for our project.
The third document proposes a DNA extension to the Venux which actually enables us to collaborated DNA study, decode-encode it in structural way.
Venux can be viewed as many different things; such as another version of more efficient internet or global manager for information/machines.
I realize that we, as humans, need some kind of a framework (to avoid anarchy) and not structural hierarchy that leads to elitism and corruption. The most natural framework for any human being is a FREE WILL! No matter what rules you’ll impose on a person, if it is not natural and if the person is intelligent/educated enough, he/she can break them. So, let’s not install government upon ourselves, let’s install it over machines/knowledge and be free.
Thank you!
Written and coded by Eugene Nosko Logo done by Eugene Rasporskiy
(c) 2009 Earth. |