SolOS: coeso por fora, modular por dentro

Existe uma pergunta incômoda que todo sistema ambicioso precisa encarar: a arquitetura está ficando realmente melhor ou apenas maior?

O SolOS chegou a esse ponto.

A tese sempre buscou uma experiência menos fragmentada. Ghost, Wallet, Apps e approvals não deveriam parecer produtos soltos colados a um desktop. Para quem usa, o ambiente precisa ser legível como um único sistema.

Mas integração de experiência não pode significar concentração de código.

Por isso, esta nova fase ganhou uma regra curta:

Coeso por fora, modular por dentro

O SolOS continua com três camadas claras:

• Linux como base confiável do sistema;
• Daemon/runtime em Rust como mediação persistente;
• SolOS como operating layer visível.

Dentro do runtime, porém, as responsabilidades passam a seguir seus espaços naturais: host, Ghost, Wallet, Apps, approvals, quota, eventos e contratos.

Não é uma corrida para criar microserviços. É um monólito modular: um Daemon, uma experiência coerente e fronteiras internas que podem ser testadas, observadas e evoluídas sem transformar tudo em um arquivo ou controlador central.

A correção já entrou no código

Esta não é apenas uma mudança de redação.

O primeiro corte separou a descoberta do host Linux e a montagem do catálogo operacional em módulos próprios do runtime. O contrato externo da RC1 foi preservado, então a shell continua entendendo o mesmo estado enquanto o núcleo ganha fronteiras melhores.

A auditoria também encontrou dois defeitos reais que uma compilação verde não mostrava:

• a Home e o Agent abriam com bindings QML inválidos em listas importantes;
• o servidor web local retornava 404 quando o caminho de assets não era configurado manualmente.

Os dois foram corrigidos.

E o gate mudou. Agora não basta compilar: a verificação sobe o servidor web, inicia o Daemon, abre a shell nativa e falha se encontrar erro QML, módulo ausente ou encerramento precoce.

Uma tese menos exagerada e mais precisa

O SolOS não precisa abandonar a ideia de um ambiente integrado. Essa é uma das suas partes mais fortes.

O que ele precisava era separar duas coisas:

• unidade para a pessoa;
• limites para a engenharia.

Home pode resumir o todo. Ghost pode conversar com Wallet e Apps. Approvals podem atravessar a experiência. Mas cada domínio precisa continuar reconhecível, revogável, observável e governado por contratos explícitos.

Isso torna o sistema mais seguro e também mais humano. Uma pessoa não deveria precisar compreender a estrutura interna para sentir continuidade. Já quem desenvolve e audita precisa conseguir localizar responsabilidade, falha e impacto.

O que ainda falta

O SolOS continua sendo um release candidate, não um sistema diário pronto.

Os próximos cortes precisam:

• dividir o controlador amplo da shell por domínio;
• mover estado e eventos duráveis para stores pertencentes ao Daemon;
• manter o snapshot agregado como leitura de compatibilidade, sem transformá-lo no único barramento interno;
• provar o appliance em VM;
• completar uma jornada real de Ghost, aprovação, execução e resultado persistido.

Sem fingir autonomia. Sem esconder custo. Sem sacrificar segurança para parecer pronto antes da hora.

Construir e comunicar também custa

Código, infraestrutura, vídeo, distribuição e marketing exigem recursos. O Fundraising do SolOS existe para sustentar exatamente essa travessia: transformar uma tese autoral em software utilizável, testado e conhecido por pessoas reais.

Os apoios são avulsos e oferecem reconhecimento e utilidade dentro do ecossistema. Não são investimento, equity, dívida, rendimento ou promessa de retorno financeiro.

Quem apoia ajuda a financiar desenvolvimento, segurança, infraestrutura e a comunicação necessária para o SolOS encontrar seus primeiros usuários.

Uma nova fase não precisa fazer mais barulho.

Precisa organizar melhor o que já nasceu — e levar essa construção até as pessoas certas.

https://luiz-bella-artes.net/solos/fundadores