Xyron

Xyron é uma linguagem de programação low-level concebida especificamente para sistemas operativos, combinando a velocidade e o controlo do C com a segurança e modernidade do Rust. O seu objetivo é permitir o desenvolvimento de sistemas operativos altamente eficientes, seguros e escaláveis, sem comprometer o acesso direto ao hardware. Ela possui:

Controlo total do hardware - Acesso directo à memória e aos registos do processador, como em Assembly e C.
Segurança de memória - Sem garbage collector, mas com verificações automáticas de buffer overflow, desreferenciação de nulos e condições de corrida, como em Rust.
Gestão inteligente de ponteiros - Ponteiros seguros que evitam a utilização após a libertação (use-after-free) sem a necessidade de um coletor de lixo.
Compilação híbrida - Pode ser compilada diretamente para Assembly otimizado ou interpretada em modo de depuração para depuração avançada.
Sistema de macros poderoso - Permite criar abstracções sem perda de performance, algo como inline em Assembly misturado com macros em Rust.
Competição nativa e eficiente - Utiliza um modelo de propriedade para evitar condições de corrida, mantendo o desempenho multithread sem bloqueios desnecessários. - Sintaxe de baixo nível otimizada - Inspirada em C, mas mais expressiva e segura, eliminando armadilhas comuns como overflows de memória e ponteiros pendentes.
Legível por Humanos - Tenta ser simples, fácil de entender, e human-readable, usando palavras invés de símbolos ou código em algumas partes, enquanto mantém code-like no que for necessário. Mas mesmo com isso, é incrívelmente poderosa.

Exemplo de código… Eis um pequeno código que acede à memória de forma segura no Xyron:

main in kernel(){
let pntr do: craft mutbl unsig8 = alloc(1024_bytes); \/*\/ Aloca 1024 bytes na RAM
if pntr ≠ null {
write(pntr value HexDec255); \/*/\ Escreve um byte na memória
free(pntr); // Releases memory
}else {
scream::"Memory allocation failure!";
}
}

(P.S: Para adicionar um "comentário" tipo // Comentário em Xyron, é necessário usar \/*\/ porque o // já é usado em outras coisas na linguagem). Porque é que o Xyron seria a melhor opção? Rápido como o Assembly, mas com uma sintaxe moderna e tenta ser fácil de entender, human-readable. Seguro como o Rust, mas sem uma curva de aprendizagem acentuada. Permite o desenvolvimento de sistemas operativos sem as dores de cabeça do C.

OnyxOS

"O Sistema Operativo De um Futuro de Minérios" / "The Operating System of a Mineral Future". O OnyxOS é um sistema operativo de código aberto, criado de raiz, que NÃO segue qualquer base Linux - NÃO é baseado em Linux nem em qualquer outra coisa. É totalmente desenvolvido de raiz.

Criado com a linguagem de programação Xyron, o OnyxOS combina um desempenho extremo com a segurança moderna, inspirando-se na estética e funcionalidade punk. O OnyxOS não é apenas uma alternativa aos sistemas operativos tradicionais; é uma reinterpretação do que significa utilizar tecnologia de ponta no mundo contemporâneo sem o fardo do bloatware ou da complexidade desnecessária.

Principais Características:

Turbo-Cyber Performance - O OnyxOS foi construído para a velocidade e o futurismo. O seu core foi concebido para tirar o máximo partido da arquitetura de cada máquina, sem sobrecarregar processos ou dependências desnecessárias. Não acumula processos em segundo plano ou bloatware, tornando o sistema incrivelmente leve e rápido.
Cyberpunk Level Security - Com a segurança de memória garantida pelo Xyron, o OnyxOS elimina falhas comuns como buffer overflow, desreferência nula e data races. A segurança é reforçada por um sistema de criptografia resistente à computação quântica que integra cibersegurança de última geração sem sacrificar o desempenho (Utilizando o Hash Function FreezeSNOW, o sistema de encriptação SeaVortex-EYE-SKS, o sistema de key exchange NeoplasmV9-FSC e o pwd hashing Scryptonite4Spectre).
Digital Hologram Interface - Inspirado no estilo punk, o OnyxOS utiliza uma interface skeuomorphism moderna, com animações e efeitos holográficos que têm um visual de vida-real (tipo skeuomorphism), concebida para imitar a aparência de um futuro distópico. A interface é altamente personalizável, permitindo ao utilizador moldar o ambiente digital de acordo com a sua estética pessoal, com temas metálicos, néon e estilos visuais imersivos. Tem um marketplace de Addons, Plugins, Extensões, Temas, Toolkits, Funções, Desktops, Ecosystems de Environment/UShell/Interfaces/Ambiances diferentes, além de muito mais para alterar até o núcleo do sistema—no caso do Kernel, não é possível alterá-lo diretamente por outro, mas tem adições, funcionalidades e mudanças diferentes que pode fazer. (NOTA: pode alterar o tema para um estilo não-punk, se desejar. O punk é apenas o tema padrão.)
Intelligent and Adaptive Kernel - O SardonyxKERNEL é inteligente e adaptável. Ajusta dinamicamente a utilização de recursos, aprendendo com o comportamento do utilizador e antecipando as suas necessidades. Isto permite um desempenho superior em tarefas exigentes, mantendo a estabilidade e a fluidez em máquinas com especificações mais baixas. Tem funções para matar automaticamente processos que estão a consumir muita memória, fazendo-o de forma dinâmica e inteligente, além de funcionalidades extras que se integram diretamente com o FileSystem.
Total Modularity - O OnyxOS é modular, permitindo aos utilizadores escolher exatamente o que pretendem instalar. Cada componente é independente e opcional, sem necessidade de instalar pacotes ou serviços desnecessários. Se não for utilizado, não ocupa espaço - a verdadeira filosofia "menos é mais".
Hyperconnected Data Network - O OnyxOS vem com o NeuroLink, um sistema de rede inovador que permite ao SO ligar-se diretamente a sistemas de rede distribuídos, simular ligações virtuais de baixa latência e até integrar-se em sistemas blockchain. O Modo CyberConnect facilita a integração com dispositivos inteligentes e o controlo através de comandos gestuais ou de voz, mantendo sempre a segurança e a privacidade do utilizador.
Total Control System - Cada interação no OnyxOS é fluida, direta e sem intermediários. Em vez de depender de múltiplas camadas de processamento, o OnyxOS permite ao utilizador ou programador aceder ao sistema de uma forma profundamente imersiva e altamente controlada. O Zero Mode dá acesso direto ao núcleo do sistema, permitindo modificações e personalizações em tempo real. … OK, OK, OK, sejamos sinceros, chega de conversa técnica aborrecida: Não há absolutamente nenhum bloatware no sistema. No instalador, pode escolher se pretende ou não pré-instalar utilitários do sistema, como o terminal, o gestor de discos, a Agatha Discover (a central de aplicações do sistema), os utilitários da máquina virtual, a calculadora, etc. Sim, pode optar por não instalar nenhum deles (não recomendado, tem duplo avisos detalhados do que cada um faz e do porquê seria necessário). E sim, pode optar por não instalar o terminal… Mas não recomendo (de qualquer forma, se não instalar o terminal, há sempre uma forma de o instalar mais tarde. O sistema tem o PURE Mode para gerir o sistema através de comandos e texto).

E, no instalador, pode pesquisar pacotes online para instalar no sistema durante a instalação. E não, NÃO é baseado em Linux, é mesmo um novo sistema operativo, com um novo kernel (SardonyxKERNEL) e utilizando a linguagem de programação Xyron. E com um sistema de ficheiros bem.. exótico e diferenciado, chamado Chalcedony. .. .. Mas ok, então, se não é baseado em Linux… Onde posso encontrar programas para o mesmo? Bem… Surpreendentemente, pode instalar programas Linux, macOS e Windows (e, se quiser, até mesmo qualquer flavour BSD—com o GhostBSD por padrão—e até mesmo sistemas mobile) directamente no OnyxOS. O OnyxOS foi desenvolvido com os serviços, ferramentas, pacotes e modos necessários para suportar aplicações Linux, macOS e Windows de forma nativa, sem depender de terceiros, sem depender de emulação, e embora esteja num directório chamado "Container" na raiz do sistema, eles estão aí por uma questão técnica, mais pra um Container Isolationless OS do que uma isolação tradicional—é container, mas sem isolação, para poder usar as aplicações dos outros sistemas nativamente e sem problemas de compatibilidade ou integração.

O OnyxOS possui ainda:

Integração com Cognitron - é opcional, não está ativada por defeito, mas pode optar por ativá-la durante a instalação, ou na tela de Out-Of-The-Box Starter ou ativá-la posteriormente.
Klank (O Legacy Tipo de Design de Aplicações) - O Klank é um tipo de desenvolvimento de aplicações legacy para o OnyxOS (Legacy porque era o que era utilizado antes do Krystal ser implementado). Com o Klank, pode criar a sua aplicação num contentor (NÃO em sandbox, é um contentor) ou não. Ou seja, quem vai criar uma aplicação no Klank pode decidir se quer ou não que a aplicação seja executada num contentor. O utilizador também pode ativar ou desativar o modo de contentor do Klank nas 'System Apps Settings'.
Krystal (O Novo Tipo de Empacotamento e Design de Aplicações) - Krystal usa um empacotamento diferente, melhorado, refinado e diferente do Klank (porém com opções de compatibilidade), feito para reinventar como aplicações são feitas para o OnyxOS. O Krystal, além de suportar tudo que o Klank suportava, e de forma melhor, refinada e mais nativa, ele também tem opções para instalar várias versões do mesmo programa ou aplicação, então não terá mais problema de "versão requirida não suportada", é só instalar a versão necessária com a opção de "Alternative" e, se quiser, configurar em quais casos ou maneiras essa versão será usada, e em quais exceções ou filtros outra versão será usada—mas por padrão, o OnyxOS detecta a versão de dependência que um pacote precisa e usa a mesma versão automaticamente—o sistema altera automaticamente a versão do pacote/app a ser usada caso necessário. Além de outras funções QoL.

OnyxOS Filesystem Structure

@ (Root)
├── Chalcedony (Filesystem Core)
│   ├── Structure
│   │   ├── Sources
│   │   └── Metadata (VertexSynth-Descriptors & Files and Folders Metadata/Data)
│   ├── Linkeds (System Symlinks)
│   │   ├── system.link -> @System
│   │   ├── sys.link
│   │   ├── krnl.link -> @System@SardonyxKERNEL
│   │   ├── img.link
│   │   ├── atomic.link -> @Atomic
│   │   ├── update.link
│   │   ├── onyx.link -> @Onyx
│   │   ├── personal.link -> @Personal
│   │   ├── software.link
│   │   ├── hardware.link
│   │   ├── platforms.link
│   │   ├── framework.link
│   │   ├── firmware.link
│   │   ├── build.link
│   │   ├── boot.link
│   │   ├── start.link
│   │   ├── lang.link
│   │   ├── settings.link
│   │   ├── tasks.link
│   │   ├── arch.link
│   │   ├── images.link
│   │   ├── backup.link
│   │   ├── rewind.link -> @Rewind
│   │   ├── optional.link
│   │   ├── containers.link -> @Container
│   │   ├── package.link
│   │   ├── klank.link
│   │   ├── krystal.link
│   │   └── kernel.link
│   ├── Files
│   ├── Data
│   ├── Allocation (Block Mapping)
│   ├── Blocks
│   ├── Architectures
│   ├── Partitions
│   ├── AtomicFS (Immutable Snapshots)
│   │   ├── rollback.sk
│   │   ├── img.sk
│   │   ├── syskernel.sk (Active Core)
│   │   ├── update.sk
│   │   ├── boot.link
│   │   ├── checksums.link
│   │   ├── active
│   │   │   └── current.link
│   │   ├── staged
│   │   │   └── pending
│   │   │       ├── deploy.link
│   │   │       └── verified
│   │   ├── signatures
│   │   │   └── vertex.link
│   │   └── integrity
│   │       ├── manifests
│   │       │   └── alpha.link
│   │       └── validation
│   └── Cache
│
├── System (Sardonyx Core)
│   ├── SardonyxKERNEL
│   │   ├── Start (Entry Points)
│   │   ├── Modules (Drivers/KITT)
│   │   ├── Framework (Aluminum/Lithium)
│   │   ├── Firmware
│   │   ├── Kernel (Binary)
│   │   ├── Hardware (Abstractions)
│   │   ├── Software (Daemons/WOOF)
│   │   ├── KernelRewind (Emergency Rollback)
│   │   └── Sardonyx (Internal API)
│   ├── Config
│   ├── Drivers (Active)
│   ├── Index
│   │   ├── Binaries (Core Utils)
│   │   ├── Library (Shared Objects)
│   │   └── Variables (Env Vars)
│   ├── Boot
│   │   ├── Img (AetherInitialize Payload)
│   │   ├── Mgr (quabm.sk)
│   │   └── Quartz (Boot Logic)
│   ├── Terminal
│   │   └── Shell (ForgelessShell)
│   ├── Tasks
│   ├── Arch (Architecture Specifics)
│   └── SystemRewind
│       ├── Images
│       └── Backup
│
├── Onyx (User Experience & Environment)
│   ├── Lang
│   ├── Desktop
│   ├── Ecosystem
│   │   ├── Environment (Ambiance)
│   │   ├── UShell (EcoUShell)
│   │   ├── Languages
│   │   ├── Interface (Digital Hologram)
│   │   ├── Community (Addons/Plugins)
│   │   └── Ambiance
│   │       └── Habitat
│   ├── Settings (Global)
│   └── Packages
│       ├── Format
│       │   ├── Klank (Legacy)
│       │   └── Krystal (Native Next-Gen)
│       ├── Manager (Agatha Discover)
│       └── Part
│
├── Personal (User Land)
│   ├── Users
│   │   └── Nanashi no Gonbei (Placeholder Name cuz everyone has different usernames)
│   │       ├── Home
│   │       └── ,secret (Deep Hide Folder)
│   │           ├── PrivateKeys
│   │           ├── Vault
│   │           │   ├── EncryptedData
│   │           │   ├── Private
│   │           │   ├── Sensitive
│   │           │   │   └── Credentials
│   │           │   └── BioMetrix
│   │           │       └── NeuralHash
│   │           └── HiddenAssets
│   ├── Definitions (User Preferences)
│   ├── UserBinaries
│   ├── UserVariables
│   └── UserLibrary
│
├── Build (Dev & Mounting)
│   ├── Points (Mountpoints)
│   └── Mount
│
├── Platforms (Cross-OS Integration)
│   ├── Programs
│   ├── Applications
│   ├── AppliData
│   ├── ProData
│   └── Share
│
├── Optional (Bloat-Free Modules)
│
├── Rewind (OwU-R & Titanium Atom)
│   ├── Props
│   ├── Time (Chronological Shots)
│   ├── Internal
│   │   ├── systemrewind.datalink
│   │   └── kernelrewind.datalink
│   ├── Reverse
│   └── Shift (State Switching)
│
├── Container (Isolationless Layer)
│   ├── BSD
│   │   └── GhostBSD (Pre-configured)
│   │       ├── Image
│   │       ├── Virtual
│   │       └── Package
│   │           ├── SoftwareStation
│   │           └── PKG
│   ├── Windows (L0 Integration)
│   │   ├── Image
│   │   ├── Virtual
│   │   └── Package
│   │       ├── EXE
│   │       ├── MSI
│   │       ├── APPX
│   │       ├── APPXBUNDLE
│   │       └── MSIXBUNDLE
│   ├── Linux (Seamless Integration)
│   │   ├── Image
│   │   ├── Virtual
│   │   └── Package
│   │       ├── DEB
│   │       ├── RPM
│   │       ├── PKG.TAR.GZ
│   │       ├── APPIMAGE
│   │       ├── SNAP
│   │       └── FLATPAK
│   ├── MacOS (Darwin Layer)
│   │   ├── Image
│   │   ├── Virtual
│   │   └── Package
│   │       ├── DMG
│   │       ├── PKG
│   │       ├── APP
│   │       └── MPKG
│   ├── Android (Mobile Runtime)
│   │   ├── Image
│   │   ├── Virtual
│   │   └── Package
│   │       └── APK
│   ├── iOS
│   │   ├── Image
│   │   ├── Virtual
│   │   └── Package
│   │       └── IPA
│   └── OtherOSes
│       └── Custom
│           ├── Image
│           ├── Virtual
│           └── Package
│               ├── RAW
│               └── Manifests
│
├── Git (Native Version Control)
│   ├── Repositories
│   │   └── System
│   ├── Local
│   ├── Remote
│   ├── Branches
│   │   └── Stable
│   │       ├── Main
│   │       └── Development
│   │           └── Nightly
│   ├── Commits
│   │   ├── Logs
│   │   └── Diff
│   ├── Staging
│   │   └── Index
│   │       ├── Tracked
│   │       └── Untracked
│   │           ├── Modified
│   │           │   ├── Cached
│   │           │   ├── Uncached
│   │           │   └── Delta
│   │           └── Ignored
│   └── Stash
│       ├── Entries
│       └── Patches
│
└── Atomic (Iron Rollbacks & Updates)
    ├── Rollback
    ├── Images
    │   ├── SystemImages
    │   ├── SysKrnlIMG
    │   │   ├── img.link
    │   │   ├── sys.link
    │   │   ├── krnl.link
    │   │   ├── base
    │   │   │   └── root.link
    │   │   ├── diff
    │   │   └── overlay
    │   └── KernelImages
    ├── Updates (LapisLazuli Managed)
    ├── History
    ├── Saved
    ├── Cache
    └── Patch

Explicação do Path e do Root (@)

O path do OnyxOS é feito usando @ ao invés do tradicional / (Unix) ou \ (Windows). Portanto, seria algo como, por exemplo: @Container@GhostBSD@Image. Desta maneira, arquivos, pastas e etc suportam caracteres tipo / no nome, cujo é impossível em qualquer outro sistema operativo. Isto obviamente irá causar problemas caso se tente mover um ficheiro com, por exemplo, o nome Coisas / Cenas e \Especiais\, comumente resultando em erros como "Nome Inválido". Não apenas / \ são agora suportados como nomes, literalmente qualquer outro caractere Unicode é suportado, até mesmo o @, que é usado para path, é suportado — que, embora usado para path, usá-lo em nome de arquivo não afetará em nada por conta da forma como o OnyxOS e o sistema em si gere path, arquivos e ficheiros. Um ficheiro com um caractere @ no nome ficaria assim no path: @Personal@Users@Nanashi no Gonbei@Home@Documents@Anotações de \*\@\*\Email.txt para um arquivo com o nome "Anotações de @Email". Como podem notar, usamos \*\ \*\ no path quando existe um @, isso porque no OnyxOS (e também no Xyron), nomes de ficheiros com esse tipo de caracteres são postos nessa "formatação" para ajudar o sistema a entender com o que está a lidar/trabalhar. Mas e caso o nome do arquivo seja "*@*", que já é usado para o path? Nesse caso, o nome ainda seria aceito, mas o path ficaria como, por exemplo: @Personal@Users@Nanashi no Gonbei@Home@Documents@Texto de \*\\*\@\*\Emails\*\.txt para um ficheiro do nome "Texto de *@*\Emails" — Tal como podem notar, foi adicionado um \*\ \*\ extra ao path. Mas e caso contenha ainda mais "*" no nome? Nesse caso, ficaria tipo: @Personal@Users@Nanashi no Gonbei@Home@Documents@Texto de \*\\*\\*\@\*\Emails\*\\*\.txt para um arquivo com o nome "Texto de "*\@*\Emails*". E arquivos com nomes que usam caracteres como / são exibidos de forma inteligente, no caso mais comum e sem complicações: @Personal@Users@Nanashi no Gonbei@Home@Documents@Cantadas / flertes para usar com ele.txt para um arquivo com o nome "Cantadas / flertes para usar com ele"

File Visibility Flags

O OnyxOS utiliza um sistema de prefixos para controlar a visibilidade dos ficheiros/directorias. Cada flag possui um nível de sigilo distinto:

. — {blue}Normal Hide — Ficheiros ocultos padrão, como os ficheiros de configuração do Linux. Aparecem quando a opção "Mostrar ficheiros ocultos" está ativada no Rover (gestor de ficheiros do OnyxOS). São utilizados para ficheiros de configuração, cache, dados de aplicações, etc.
, — {yellow}Secret Hide — Não aparece mesmo com a opção "Mostrar ficheiros ocultos" activada. Só é visível através de um atalho específico — e mesmo assim, temporariamente. Oculta-se automaticamente ao mudar de diretório, reabrir o Rover ou ao mudar o foco. É utilizado para a pasta ,secret dentro de cada directório de utilizador.
: — {orange}System Hide — Reservado para ficheiros críticos do sistema, marcados como OfSystem ou ToSystem. Mantém a infraestrutura principal do sistema operativo longe tanto dos utilizadores como dos gestores de ficheiros comuns.
; — {red}Infinity Hide — O nível mais profundo. A única forma de exibir é com atributos da funcionalidade SecretFlags desbloqueada no Rover. Requer ainda um atalho e oculta-se automaticamente após 1 minuto e 35 segundos, ou ao mudar de diretório, reabrir o Rover ou atualizar com F5. O Terminal é a forma mais fiável de interagir com estes ficheiros. Utilizado para ficheiros que genuinamente não podem — ou não devem — ser exibidos casualmente.

OnyxOS Structure & Insider-view

Boot Chain

O OnyxOS utiliza o seu próprio método e tecnologias de cadeia de arranque, descartando métodos comuns utilizados por outros sistemas para expandir, simplificar e promover avanços tecnológicos sem depender de ciclos de lançamento preexistentes ou de tecnologias comuns.

AetherInitialize (AIZ) — Substituição total moderna e especializada da Paradox para UEFI. Utiliza o NeoplasmV9-FSC-AIZ para validar a assinatura digital de cada peça de hardware instantaneamente. Após isso, utiliza as propriedades do elemento 197 Korsium (que foi convertido pra nível de software e firmware com um método de reshape7s) para sincronizar o clock de todos os componentes através de uma "ressonância de singularidade", eliminando a necessidade de drivers de barramento genéricos durante o boot. Prosseguindo para o Direct-to-Sardonyx (DtS), que invés de procurar um boot loader, ele mapeia o sistema de arquivos Chalcedony nativamente e injeta o syskernel.sk diretamente na memória RAM ultra-rápida.
- Utiliza camadas L0 Singularity Point (Micro-código em Xyron que acorda o processador e limpa os registos), L1 SVEGuard (Encriptação SeaVortex-EYE-SKS aplicada ao hardware para prevenir ataques de "Evil Mad") e L2 AetherShell (Um ambiente de pré-boot mínimo acessado apenas via comando; de emergência, para reparação de partições Chalcedony)
  - Processo de Boot (The Flash-Point)
    1. Power-On: O AIZ ignora o POST tradicional. Ele assume que o hardware está funcional e só para se o SVEGuard detetar uma anomalia.
    2. Mapping: Ele acede ao diretório @Chalcedony@Linkeds@boot.link e identifica o estado do sistema.
    3. Holographic Handover: Em vez de uma tela preta com texto, o AIZ projeta um frame estático da Digital Hologram Interface enquanto o kernel é carregado.
    4. Execution: O controle é passado para o SardonyxKERNEL em modo Zero Mode. O AIZ então se auto-apaga da RAM para não ocupar espaço, deixando 100% dos recursos para o proximo processo.
Quartz Boot Manager (quabm.sk): Depois do sistema de ficheiros Chalcedony e o SardonyxKERNEL forem inicializados, o Quartz passa para o processo para inicializar o restante dos drivers e serviços de uma forma Tudo-em-Um, que inicializa tudo exatamente ao mesmo tempo para diminuir tempos de espera de boot e inicialização mais rápida. Após isso, ele passa o trabalho para o Copper Loader, no próximo passo.
Copper Loader (copload.sk): Agarra no trabalho finalizado anteriormente pelo Quartz e inicializa o OnyxOS e todos os seus processos e serviços, como por exemplo, a interface de login e a interface gráfica. Ou seja, AetherInitialize -> Quartz Boot Manager -> Copper Loader

Serviços de Sistema & Daemons

o OnyxOS unifica isso tudo em um só; a Networking Stack, Power Manager, Audio Server, Logging Service e o Security Auditor é gerido pelo componente Worker Ordinal Operative Fluorite (WOOF)

Frameworks de Aplicativos & APIs

o OnyxOS utiliza um componente chamado Kernel Integrated Tracking Technician (KITT) para gerir, rastrealizar (os componentes/serviços, NÃO o usuário) e integrar os os toolkits que desenvolvedores e aplicações podem usar ao kernel e ao sistema. É composto por:

Aluminum: É a Drawing Library e o Graphics Engine usado pelo sistema para dizer à GPU como renderizar jogos 3D ou janelas 2D.
Lithium-UTK: É a UI Toolkit usada para e pelo os aplicativos.
Oxidation Cryptography Library (OxCL): Providencia uma "locked box" para o sistema e os aplicativos armazenarem passwords de forma segura. Usando a encriptação VertexSynth-2084-SR, o sistema de key exchange IsogenyX e o pwd hashing Scryptonite4Spectre internalmente integrado com o sistema de ficheiros Chalcedony, armazenando tudo no AetherInitialize Secured Information Module (AIZ-SIM), que serve também de uma substituição para o TPM, além de comunicar diretamente com.

Espaço de Usuário & Shell

A parte que o usuário realmente toca. Internamente integrado com o OnyxOS.

Coltan: É o componente de Display Manager, Window Server, Window Manager e Login Manager do sistema. Integra todos em um único processo, com processos isoladamente separados, para mesmo que estejam em um único processo, se um crashar ou parar de responder, os outros não serão afetados. Com a capacidade de reiniciar esses processos isolados sem afetar os outros.
EcoUShell: O "Shell" do sistema, que é composto pela UI (Interface de Usuário), UX (Experiência de Usuário), Desktop, Interfaces Gráficas e tudo o resto que providencia uma interface gráfica/etc ao usuário.

Componentes Internos (importantes a serem mencionados)

Os componentes internos usados pelo sistema. Apenas os importantes a serem mencionados serão listados aqui.

SarKShell: O "Shell" do SardonyxKERNEL e seria como se fosse um "tty". Porém, não é comumente usado ou acedido pelo usuário, serve mais como um componente interno para o kernel e as partes internas do sistema se comunicarem sem involver o usuário diretamente, feito para evitar atrapalhar e separar o sistema interno e kernel do "sistema usável" pelo usuário. Embora seja possível aceder usando o Zero Mode - que também possibilita aceder aos componentes de Boot Chain do sistema, mas com mecanismos e prevenções de segurança e integridade para evitar desastres ou acidentes.
Crash Accessible Throughput (CAT) & SarKShell Integrity Zone: É o componente que gere os crashes do sistema e redireciona para o , que seria como uma "Blue Screen" ou "Kernel Panic". Que, também é integrado com o SarKShell, mais especificamente com a parte SarKShell Integrity Zone que funciona de uma forma ligeiramente diferente do SarKShell padrão mencionado anteriormente, e é também a zona em que a Boot Chain executa (AetherInitialize, Quartz Boot Manager e Copper Loader, tal como os componentes internos desses mesmos).
ForgelessShell: É como se fosse o PowerShell/CMD ou Bash.

Backup & Restauração e Atualizações

O OnyxOS utiliza o componente e ferramenta Optimal Worker Unified Rewind (OwU-R) para criar backups, snapshots, timeshots e restaurações do sistema. Pode ser usado manualmente de forma gráfica ou usando o ForgelessShell, e também é usada de forma inteligente e automática antes de atualizações, mudanças críticas no sistema, modificações ou alterações de raiz. Os backups/rewinds em si são feitos pelo serviço, ferramenta e componente Titanium Atom, que é a forma do OnyxOS de gerenciar esse tipo de mudanças e também é usado na parte Atómica do sistema. O OnyxOS gere atualizações utilizando o LapisLazuli, que unifica as atualizações e é integrado com o componente Titanium Atom para a parte atómica e o Iron Rollbacks para os rollbacks do sistema. Em lista, estes componentes, ferramentas e serviços são integrados entre si:

Optimal Worker Unified Rewind - Ferramenta para facilidade de uso dos componentes de restauração e backup.
Titanium Atom - componente e gestor da parte Atómica do sistema, que é usado para as atualizações.
LapisLazuli - Serviço, componente e ferramenta de atualização do sistema.
Iron Rollback - Ferramenta, serviço e componente para Rollback em caso de atualizações quebradas, ou caso apenas se queira usar o OwU-R. A parte atómica do sistema são as atualizações, os patches, os rollbacks/rewinds, as imagens do kernel e imagens do sistema, a cache e o histórico interno do sistema.

Parte Imutável

O OnyxOS até tem uma parte Imutável, porém é difícil explicar de forma completa aqui porque depende MUITO das escolhas do usuário durante a instalação e do que ele escolher nas dezenas de opções avançadas durante o setup inicial do sistema. Porém, independentemente do que o usuário escolha, tudo funciona da mesma forma: É imutável, absolutamente TUDO que envolva modificar, alterar, gerir, escrever, apagar ou reescrever é RECUSADO e apenas os processos específicos, integrados, seguros, verificados e não-alteráveis do sistema são permitidos — embora OnyxOS seja aberto a customização e modificações, esta parte é a única cujo o usuário fica impossibilitado de mudar ou adicionar QUALQUER coisa — até mesmo as aplicações são recusadas e nem sequer têm a capacidade ou permissão para ver, analisar ou detectar qualquer coisa, arquivo, ficheiro, pasta, metadata ou etc das partes imutáveis — e o usuário restritamente consegue. É impossível adicionar um serviço ou exceção para ser capaz de fazer qualquer coisa na parte Imutável, o sistema escolhe e gere automaticamente isso durante a instalação e após isso fica impossível de se fazer qualquer alteração. Nem mesmo modificações no kernel, sistema ou Boot Chain serão capazes de fazer qualquer coisa. O usuário durante a instalação tem a capacidade de controlar isso, mas apenas durante/antes da instalação (no Setup) — e mesmo assim o sistema tenta gerir automaticamente as escolhas que o usuário fez para impedir qualquer coisa que é melhor não ser feita. Por padrão, o OnyxOS escolhe e gere automaticamente a parte Imutável baseado nas outras escolhas do usuário durante/antes da instalação, caso o usuário queira alterar alguma coisa da parte Imutável, é necessário usar a instalação no modo Specifically Advanced Development (SAD) que costuma não ser recomendado, porém possível de usar APENAS DURANTE/ANTES DA INSTALAÇÃO. Literalmente tudo desta categoria (Parte Imutável) só pode ser gerido durante a instalação e algumas partes super específicas no setup inicial, a partir daí é impossível de fazer qualquer coisa. Exploits tecnicamente não são impossíveis, nenhum exploit é impossível, porém a dificuldade disso é insana. Até porque temos propositalmente muita pouca documentação ou explicações sobre isto, para prevenir brechas.