Homo-Sapiens

Homo sapiens is the only extant human species. The ingenuity and adaptability of Homo sapiens has led to its becoming the most influential species on the planet; it is currently deemed of least concern on the Red List of endangered species by the International Union for the Conservation of Nature.

In 200,000 BCE, Homo Sapiens was created as a fork of Homo Erectus. That project was a huge success with a large number of deployments over a period of nearly two million years. This was a very mature codebase but after lead developers announced on the mailing list that no significant releases were planned and pull requests were sitting ignored for well over 3,000 years, a group of developers decided it was time to fork.

The goals of the Homo Sapiens project are to:

Use efficient coding practices which result in more dependable instances.
Reduce degradation of long running processes and increase average uptime.
Establish a framework that supports many different flavors so that they don't fork the project.
Improve the build process to ensure a working product.
Maintain an accurate changelog.

Getting Started

Getting a working build of Homo Sapiens can be a little tricky. Follow these steps and, if you run into trouble, try again. If you've tried many times and still have no luck, see "Known Issues."

Identify an available development box from a female instance with an uptime over 6570 days (or as specified by your local polity)
1. For best results, run a profiler on the development box to determine the best time to continue with the steps below. (There are only 2-3 days each month that the install has a good chance for success.)
Secure 23 chromosome variables from a male instance. You only need a single copy of this file (~37 MB) but typically males will provide multiple copies so be prepared to transfer many TB of data.
Deploy the chromosomes into the development box. There are a variety of methods available which others have already explained.
Wait for the build to complete. This is a good time to RTFM. There are some bugs in the build process and there's no status indicator. However, you can watch the process if you have the right debugging tools.
1. During this time period, a unique key will be issued. While most developers expect this is simply a SHA4096 hash of the 46 input chromosome variables salted with an unknown constant, there are some who believe there is simply a pool of keys which are reused after each instance halts. Please keep discussions about this off the mailing list unless you have new information.
If the build is successful, you'll have a new running copy of Homo Sapiens in about forty weeks.¹ Congratulations! This instance only has a few processes running by default and installing new processes can be a pain, but tutorials are available.
1. Occasionally the status gets "stuck" at 99%. If this happens there is a way to

¹ This is not measured from when you deployed the chromosomes but from the last time the development box flushed it's cache.

Prerequisities

There are no prerequisites to running your own copy of Homo Sapiens and we encourage all interested developers to join the project!

Please be aware that all new instances run in the same production environment and each new instance reduces the available resources to existing instances.

Running the tests

Unit testing is part of the build process. If any unit tests fail, the build will not succeed and you will need to start over. There are many things that can go wrong in the build process. Most developers do not like sharing when a software build is unsuccessful especially when they cannot diagnose the issue on their own. You may feel like a failed build is unusual, but it occurs far more often than reported and often during the first few months.

Please search the mailing list before reporting any issues with builds in the first 90 days. If this is your first time attempting a build of Homo Sapiens, you may wish to secure an experienced vendor to assist you.

Deployment

Once deployed, you can begin installing new processes. Most developers, particularly first-time developers, describe this as a grueling process with many challenges along the way. These are the processes most developers focus on during the first few years:

I/O

Unfortunately, a fresh install only has the most basic I/O setup. Inputs are required every couple hours. A portion of the energy from the input is converted into auditory noise. The remaining mass is passed through an encryption process and ejected from the system. Please see the FAQ regarding "Law of Conservation of Mass" before reporting that the mass of the output is greater than the mass of the input. It's simply not possible.

Possible upgrades:

The frequency of required inputs can eventually be reduced to typically three inputs per day.
Increase efficiency of the mass-to-energy process.
Utilize energy to run other processes.
Instances with an uptime of 730 days can run their own garbage cleanup routines if you install the appropriate processes.

Networking

Fresh builds are only capable of sending very rudimentary metadata via UDP using their muscle system. You will need to interpret this data using your visual sensors. You will also receive a large amount of encrypted auditory data (sample data here).

Most instances ship with a networking toolbox that (once setup properly) enables effective communication with other nodes at up to 27.2 bytes per second through the auditory sensor.

Possible upgrades:

Removing the built-in encryption on auditory outputs
Installing a language (most developers use the same language pack they were initially installed with)
Installing additional languages (time-consuming and rarely done despite the reported benefits)
Enhanced metadata analysis

Please note: It's considered best practice to spend at least twice as much time working on receiving and processing packets as you spend on generating packets. Remember the robustness principle. This is a huge mistake most developers make which, unfortunately, tends to increase downstream errors in future instances.

Built With

Oxygen
Carbon
Hydrogen
Nitrogen
Calcium
Phosphorus

Reporting Issues

Homo Sapiens was originally designed to run on fewer than 10 million instances. Given there are currently 7.3 billion instances running and that the project adds 360,000 developers every day, it's no surprise that there are issues in the codebase.

Before reporting an issue, please search to see if it's already being tracked. If you have a new issue, please add as many details as possible, including how to reproduce the issue. This template is preferred:

# Summary

Quick summary of the issue

# How to reproduce

1. Detail the starting conditions to reproduce the issue
2. Describe the expected result/behavior
3. Describe the unexpected result you are seeing

# Ideas for resolution

Provide at least one potential solution.

The project is committed first to identifying all outstanding issues, prioritizing the work and then assigning out teams to work on solutions. With the size of the community, we are able to pursue many independent projects and can tackle multiple avenues of resolution for each issue.

Conflicts regarding how to address a particular issue are dealt with on the mailing list.

Versioning

We use Genealogy for versioning. For the versions available, see the tags on this repository.

Authors

Unknown (Due to poor documentation of original project.)

See also the list of contributors who participated in this project.

License

This project is licensed under the Apache License - see the LICENSE file for details

the-universe/Homo-Sapiens