NAPA OS XX (Pacifica)

NAPA OS XX

Developer	PrototAutomaton
Written in	Assembler compiler, S programming language
OS family	Modular-like
Working state	Current
Source model	Source available
Released to manufacturing	May 30, 2024 (2024-05-30)
General availability	June 6, 2024 (2024-06-06)
Marketing target	"User-Developer", "RTOS-V".
Available in	9 languages Austral Crabry Alman Crabry Aegean Karnetvorian Crabry Garaan Pelinese Hinomoto Crabry Montacian Sedunnic Cimbrian
Update method	NUS AE Automata
Package manager	Custom installer (.asm), Executable file (.accrt), Universal platform (.ineg)
Platforms	48-bit native, Customisable
Kernel type	Modular Exokernel and Unikernel native
Userland	Multiplex API-Syscalls
Default user interface	Modular.
License	Source-available software.
Preceded by	NAPA-OS-X

NAPA-OS-XX is an operating system designed and published by the Nasphiliti-based copany PrototAutomaton which was publicly published and released in 2024 under the LR of the Board of Committee leadership of Jonas Val It's main components are modularity and containerization; The former providing support for different architectures (from 2¹B to 2²⁵⁹B), while the latter allowing for built-in data integrity and data authenticity. It features it's modular assembly code, as well as it's own assembler-compiler named "INEG" (Illuminate New Environment Genesis); whose mnemonic instruction "ACCESS" initiates other native applications, such as: "ACCRT" (Application Cross-Compiler Real Time) and the mid-level programming language "SOLOMON" (S). Finally, it features its own file system: the "Rhizome File System Hash" (RFSH). All instructions (of either INEG Assembler-Compiler or the ACCRT cross-compiler). It should be noted in the beginning that "Modules" correspond to "Editions" in older Operating Systems, while "Containers" in RFSH correspond to "Directories" or "Folders". During public beta of the Operating System, the File System was called "Multiple File System within Single File System architecture" of MFSNSS for short. Upon publication, it was changed to the RFSH.

Initialisation of the NAPA-OS-XX assembler-compiler is mnemonic-oriented, the Operating System is physical into assembler-compiler. It returns information gathered about the hardware architecture in the device, on low-level machine code it is mnemonic, while the presentation is written is plain tongue. Upon boot-up, it awaits user input if it detects emulating abilities regarding the use of available CPU and motherboard architectures. The praised manual ^{(received in both a physical copy if purchased and as a tiled window throughout use)} calls the OS "Non-Endian", telling the user that it lacks any privilege level escalations or de-escalations as to avoid memory misallocations; It defines itself as "Block-code op-code encoding capable".

Modularity of the Operating System is in the initialisation process, where, upon detection and reverse engineering of the device microcodes, is prompts the user the best "module" for their architecture. Addresses are memory-paradigmed into containers segmented across the "rhizomemap" (RFSH), wherein mnemonics, through use of the Assembler-Compiler, dynamically use containers to instruct operations performed on the device. The containers may be seen as application calls, or from the Assembler-Compiler POV as system calls. Caching is direct real-time (RAM) or accessed addresses which are dynamically re-allocated upon each initialisation to avoid scrambling of the memory map. The registry of all calls made or available is in constant Cycle I (through the use The NUS Artificial Entity.

Development, Modules and Initialisation

In regards to "Modules", in plain tongue, they are analogous to other Operating Systems "Editions". NAPA-OS-XX's various distinct features have been in development since 1999. (the "No-endian" design) to 2014. (official consolidation of prior projects into a cohesive system). The mentioned wide support for different architectures is avilable, though primarily targets he "Garden Gate" (47/48 bit byte architectures), the "User-Developer" (x56 or x112), and he "Controller-Infrastructural" (x28, x31 and 128-bit) "Modules". The "Modules"are selected upon first initialisation in which the native assembler-compiler detects hardware components of the device, memory type and space from ROM components, data type and space from RAM components, and "Cycle capacity" from CPU components. It then proceeds to offer the "effective optimum modules" (EOM), though any can be chosen and later manually changed due to built-in virtualisation technology.

Initialisation (from a consumer perspective) begins upon an installation media being inserted, after which it notifies the user to disconnect the device from "commonly known networking", including powering off all modems, routers, printers and Bluetooth around the Module-respective perimeter. It will refuse initialisation if this is not done prior to rebooting. The initialisation proceeds to temporarily disable I/O hardware itself (including PCIe, USB NICs, and non-SATA I/O capabilities). Concurrently, it removes BIOS and UEFI, decrypts hardware microcodes, runs the Assembler-Compiler detection, creates "container-addresses" on separate memory blocks via the RFSH which is self-created and self-mounted by the native, built-in NUS AE. The procedure is the first instruction call (INEG). Depending on the Module choice, the assembler-compiler will mnemonically "MANIFEST" different instruction sets and manuals accordingly, hence "No-endian".

Abstraction Layers, API calls to Machine code, and Environments

Regardless of Module choice, the NUS AE does not support privilege levels, as the assembler-compiler may be run at any time. It has two "Abstraction Layers"; the assembler-compiler and the "ACCESS" instruction of it which initiates the native "ACCRT" (Application Cross-Compiler Real Time) layer of the mid-level programming language "SOLOMON" (or "S" for short). Abstraction separates the "INEG" and "MANIFEST" assembler-compiler (syscalls) which recognises only memory and data as computable; from the "ACCRT" and "S" language (API calls). These are not hard-walled separations. Namely, the syscalls can mnemonically "RETRIEVE" application calls (write to them), but the API layer has no means of communicating to syscalls unless initiated to do so by the user utilising the "RECEIVE" syscall.

Upon mount and boot, it will display a drop-down menu for re-initialising networking, while powering back on I/O devices in the background. This drop-down menu mimics the "Modules". "Enclosed" networking is meant for use as a home server-client; "Infrastructural" is meant for use in RTOS-V (R-V) environments; "Mainframe" offers standard internet access; while the "TrueframeAnew" calls the NUS AE to enable a server-client mode, with access to all topographies of the network when called. NUS will not allow the device to connect to two topographies synchronously, a reboot is required when changing "public-facing" internet layers (such as when accessing the relay/TOR protocol, Intranet, I2P, file sharing I2P...)

Post-Setup

Languages and foreign libraries

Upon setting up the "Workstation-Developer", including the correct networking ("Regular layer" AKA the server-client layer), the end user is forced to "TAKE A TOUR (4)" (the first option with sequence indexing of seven other options), as not to have a "STAR A TOUR (0)" -- In which case the user should restart the OS and choose "Regular-User-Regular" Module option. Alternatively, the user may choose the "User-Developer" option, in which case it will show as "TAKE A TOUR (1)". This is done due to the aforementioned Modularity and built-in Manual modularity of the OS.
For instance, the first option mentioned "TAKE A TOUR (4)" is a specific developer option of the entire manual. In plain tongue, The "TAKE A TOUR" option is Module-dependent as well. This modularity part of the Operating System has been widely praised by all users, with built-in functionality of setting up "your" IP address as a private-facing server, in a TTY which has been modified to resemble a GUI installation process. In the "User-Developer" mode, it additionally offers a built-in e-mail and e-mail client; "web hosting" to routers so that an RSS aggregator and reader with multi-media functionality could later be set up. Much of these account to the NUS AE running the assembler-compiler code on RAM.

Requirements and Caching

The installation media is 750KiB, while the post-initialisation is 485MiB. As swapping memories is not supported, PrototAutomaton recommends running the application abstraction layer via an external ROM storage device with SATA connectors. Caching is done on the RFSH in a container which the user is encouraged to heavily encrypt. All caching reads data by full authenticity and integrity as it stores the device-native byte bits. NUS AE will auto-encrypt the container either way. RAM is erased on each power off/on, with hibernation and sleep mode remaining unsupported due to the aforementioned lack of swapping. No PIDs will run on later power on instances except the NUS AE. CPU requirements may vary by the "Module" chosen, though the OS is notable for specifically being only CPU-intensive by design.

Real Time, Ahead of Time and Just in Time capabilities

Regardless of Module chosen, NAPA-OS-XX utilises Just-in-Time initialisation upon first successful boot-up. This is required as to allow the initialisation to reverse engineer hardware microcodes as to include them in the options. This option is later used in conjunction with Ahead-of-Time Operating System environment.

Bit Byte Dependency and Memory Management

Everything in NAPA-OS-XX is dependent on bit byte reading. The Operating System runs natively in 47B mode as to deal with memory allocation. This allows for Modules, which is to say modularity across different architectures. The index is generates always on the first bit block (x,y or 0), which then hashmaps the remaining architectures. For instance,
malloc()
performed by a 16 bit instruction is read by virtual separation of 8 blocks automatically, increasing the speed of reading while ensuring data authenticity and integrity. Namely, the first block (0) indices up to two blocks initially. In an 8 bit architecture, the blocks are read 7+1 until the full 8 bit is indexed into memory. Instead of causing memory misallocation issues when moved to the 16 bit memory, the mid-level language S treats it as separated virtual blocks.

Encryption Mechanism Dependency and Data Management

After copying files in the first boot process prior to deleting the BIOS and UEFI, a set of encryption mechanisms are attached to the bit bytes. Namely, the NUS AE attaches unique mnemonics to each device based on gathered information regarding ROM and RAM usage as well as Motherboard (also called the GUID and UUID by KRYPTOS-III Operating System of the AID). This is passed through to the CPU to generate unique data for each device, and back into ROM to encrypt Containers. Later upon the device usage, the unique data bytes are passed through SHA-512 and MD-10 encryption for everything required in the networking (SSL) and further Containerisation.

This essentially means that every users data transfer is uniquely, by hardware components and cryptography, encrypted. Handshakes are performed upon every transaction with another device. During such stages, NUS AE is used to find the lowest common denominator prior to data exchange.

Open Source Codes, Application Suite and License

Application suites are chosen upon the initialisation base upon the Module chosen. The Operating System is licensed wherein the source code is publicly available to: "end-user" and "sys-admin-netadmin" (called "server admin" in NAPA-OS-XX). However, it is prohibited to use the open source code for commercial use without purchasing the Operating System.

Reception

Several other companies (namely domestic hardware related) have adopted the production of components needed for fully implementing NAPA-OS-XX. Lead early adaptations include ENGeNs BGA-SSDs and MXCHA's Linear Tape Open Drives and Serpentine Tape Drives.

Kons Inc., the lead applicant for infrastructural plans enacted in April 2024 in Nasphilitae, had praised the environment. Thanks to other legislation subsequently adapted (liberalisation of Nasphiliti trade markets and the formation of Associations of Unions and the Associations of Investors and Employees), it's helped raise the profit of the company in the project by 18%.

The AID (Agency for Identification and Documentation), had been critical of NAPA-OS-XX since release of the public beta. RANDICE says this was due to AID inentionally stalling the development since 2014., through the use of KRYPTOS-III Operating System.

See also

• KRYPTOS III
• PrototAutomaton
• NUS AE
• List of Companies in Nasphilitae
• Randice