User Tools
the_tech_manual
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
the_tech_manual [2020/02/24 17:13] lverona |
the_tech_manual [2024/05/15 08:52] (current) |
||
|---|---|---|---|
| Line 85: | Line 85: | ||
| Naperons are copies of the current STAR. Naperons are lower tier actors. They consist of 6 arms with nanoscopic links which allow standard tier to grab them. Their configuration makes them look like a star, which might explain the abbreviation for the manifest. | Naperons are copies of the current STAR. Naperons are lower tier actors. They consist of 6 arms with nanoscopic links which allow standard tier to grab them. Their configuration makes them look like a star, which might explain the abbreviation for the manifest. | ||
| - | Naperons contain no moving parts, and instead contain a hardware storage with a minimal operating system **clomdeut 3.2** which gives access to two files: the manifest and the log. | + | Naperons contain no moving parts, and instead contain a hardware storage with a minimal operating system **clomdeut 3.2**, which gives access to two files: the manifest and the log. |
| The manifest is in GLON format. The log file is in NLON format, which no standard tier actors have access to. Standard actors' operating system is also incompatible with the NLON format due to the way read/write operations are implemented. This secures the log from the manipulation by standard tier. A naperon will update the log each time someone accesses the system, as well as each time they sign off, noting the id of the actor and the timestamp. **Raiders** are able to read NLON files, although most of their readers will also corrupt the file upon signing off due to incompatible hardware parts. | The manifest is in GLON format. The log file is in NLON format, which no standard tier actors have access to. Standard actors' operating system is also incompatible with the NLON format due to the way read/write operations are implemented. This secures the log from the manipulation by standard tier. A naperon will update the log each time someone accesses the system, as well as each time they sign off, noting the id of the actor and the timestamp. **Raiders** are able to read NLON files, although most of their readers will also corrupt the file upon signing off due to incompatible hardware parts. | ||
| Line 152: | Line 152: | ||
| The Engine will require a different amount of drouscobs during its cycle, so the Dezque drouscob subroutine will modulate the randomizer. The most drouscobs are required closer to the end of the cycle, when the Engine requires more information about the system in order to set up a new cycle. However, drouscobs have no routines that take that into account, thus they are constantly queuing in front of the Engine, as if desperately trying to get in. The space in front of the Engine's gate is abundant, and drouscob clouds are easily dispersed if other actors are trying to get through, thus this is never a problem. | The Engine will require a different amount of drouscobs during its cycle, so the Dezque drouscob subroutine will modulate the randomizer. The most drouscobs are required closer to the end of the cycle, when the Engine requires more information about the system in order to set up a new cycle. However, drouscobs have no routines that take that into account, thus they are constantly queuing in front of the Engine, as if desperately trying to get in. The space in front of the Engine's gate is abundant, and drouscob clouds are easily dispersed if other actors are trying to get through, thus this is never a problem. | ||
| + | |||
| + | ===== Operating systems ===== | ||
| + | |||
| + | ==== clomdeut 3.2 ==== | ||
| + | |||
| + | [{{ :wiki:clomdeut.png?nolink&200|Contents of a naperon as displayed by clomdeut 3.2}}] | ||
| + | |||
| + | **clomdeut 3.2** is a naperon operating system. It contains only the minimal logic of providing access to the only two files: manifest.glog and log.nlog. clomdeut 3.2 was specifically designed to be able to handle only these two specific files, the format schemas of which are hardcoded in the pre-compiled kernel. | ||
| + | |||
| + | clomdeut's kernel contains a graphical interface which allows to actually see both files in a simple table. The interface does not provide functionality to actually inspect the files themselves. | ||
| + | |||
| + | ==== shorogyt os ==== | ||
| + | |||
| + | [{{:wiki:shorogyt_os.png?nolink&200 |shorogyt os root directory}}] | ||
| + | |||
| + | **shorogyt os** is shorogyt firmware. It contains the boot sequence, as well as a "manager" module, which is a set of scripts that handle the behavior of a shorogyt. | ||
| + | |||
| + | A "manager" module is completely event-based and will perform actions as a response to incoming data. Nevertheless, the response tree is very detailed and shorogyts will exhibit complex behavior. | ||
the_tech_manual.1582582391.txt.gz · Last modified: 2020/02/24 17:13 by lverona
Page Tools
