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.

  1. AetherInitialize (AIZ) — Substituição total moderna e especializada da Paradox para UEFI. Utiliza o IsogenyX para validar a assinatura digital de cada peça de hardware instantaneamente. Após isso, utiliza as propriedades do elemento 197 Korsium 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 VertexGuard (Encriptação VertexSynth-2084-SR 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 VertexGuard 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.
  2. 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 OnyxOS, no próximo passo.
  3. 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 a instalação — 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 a 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 A 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.

Built with LogoFlowershow