KINGAI OS Edge | Edição para dispositivos de borda

Posicionamento

O Edge é voltado a dispositivos pequenos, gateways e nós de borda com prioridade off-line: a meta é viver dentro do equipamento e rodar por muito tempo, mantendo-se de pé sozinho quando a rede cai. Ainda está na fase de planejamento; esta página descreve a direção de design, e cada item só valerá quando houver imagem real e testes de hardware.

Direção de design

• Imagem pequena, pensando em dispositivos com armazenamento e memória limitados
• Prioridade off-line: sem rede, os dados são enfileirados e guardados localmente primeiro; quando a rede volta, são sincronizados de volta ao centro
• Atualizações seguras, agrupamento de dispositivos e gerenciamento remoto (todos metas de design, ainda não implementados)
• Arquiteturas amd64 e arm64; o arm64 é arquitetura-alvo e ainda não tem registros de validação
• TPM, elementos seguros e opções de inicialização segura, dependendo do hardware específico

Ver o roteiro das quatro edições → Ver o registro de versões →

Posicionamento: dentro do equipamento, de pé sozinho mesmo sem rede

O Edge mira um tipo de equipamento: pequenos gateways e terminais dedicados colocados em lojas, depósitos, cantos de salas de servidores ou caixas externas. Eles têm pouco armazenamento, memória limitada, rede que vai e volta, e é comum passarem meses sem que ninguém vá olhar pessoalmente. Para esse tipo de equipamento, a qualidade mais importante de um sistema operacional não é ter muitas funções, e sim: ser pequeno, não perder dados quando a rede cai e conseguir se levantar sozinho quando uma atualização falha.

Por isso, a ordem de design do Edge é primeiro sobreviver, depois ser gerenciado: receber e firmar os dados localmente primeiro, e sincronizar com o centro quando a rede voltar; uma atualização ou é concluída por inteiro, ou retorna à versão antiga e continua rodando — nunca para no meio do caminho. Na documentação do produto, tudo isso ainda são itens de design; esta seção os abre um a um — e depois de cada item vem a mesma frase: ainda não implementado.

Capacidades planejadas, uma a uma

Imagem pequena

Como o armazenamento e a memória dos dispositivos são limitados, a imagem precisa ser cortada na lógica de «instalar só o que for usado». A meta é um footprint pequeno; números concretos de tamanho só existirão quando houver uma imagem real, e na fase de planejamento não se anunciam números.

Fila off-line

Quando a rede cai, os dados coletados pelo dispositivo e os eventos a reportar são primeiro enfileirados e guardados localmente; assim que a rede volta, são sincronizados de volta ao centro, em ordem. Rede instável no local é o normal, e é esse mecanismo que decide se os dados vão simplesmente desaparecer durante algumas horas sem rede.

Atualizações imutáveis e de partição dupla

Em hardwares adequados, a partição do sistema é somente de leitura e a atualização é gravada na outra partição; se a inicialização falhar, o sistema volta automaticamente à partição antiga. Para equipamentos sem ninguém por perto, isso é muito mais realista do que «a atualização falhou, espera a equipe ir ao local». A aplicabilidade depende da forma específica do hardware; as palavras da documentação são where suitable.

Comandos de dispositivo assinados e grupos de distribuição gradual (canary)

Comandos enviados remotamente precisam de verificação de assinatura; se a origem não conferir, são rejeitados de imediato. Versões novas são enviadas primeiro a um pequeno lote de dispositivos (grupo canary) para observação, e só depois a todos. Esses dois itens são a base do gerenciamento de frotas (fleet) e, no momento, ainda estão na fase de meta de design.

Inicialização segura e opções de TPM

Inicialização segura, cadeia de inicialização confiável, TPM ou elemento seguro — tudo depende de o hardware do próprio dispositivo oferecer essas capacidades. A documentação os lista como opções, não como itens padrão, e esta página tampouco os garante.

Recuperação à prova de falhas

Depois de uma atualização interrompida, de uma queda de energia ou de uma configuração gravada incorretamente, o dispositivo precisa voltar a um estado funcional, e não virar um tijolo. O caminho de recuperação precisa de testes de interrupção específicos antes do lançamento — e esse é um dos requisitos abaixo.

Por que ainda não há ISO: quatro requisitos de lançamento

• Validação independente da matriz de hardware ARM64 — o arm64, por ora, é apenas arquitetura-alvo; nenhuma máquina real foi validada
• Testes de desconexão remota / reconexão — provar que a fila off-line e a sincronização na recuperação funcionam como projetado
• Testes de interrupção e reversão de OTA — no meio de uma atualização, cortar a energia e a rede; o dispositivo precisa se recuperar sozinho
• Assinatura da cadeia de suprimentos e revisão de licenças dos pacotes de software — a origem e a licença de cada pacote da imagem precisam ser examinadas

Nenhum dos quatro requisitos foi superado, e por isso o Edge não tem número de versão, não tem ISO e não tem botão de download. As palavras do catálogo oficial são: não se afirma suporte a hardware, OTA, gerenciamento de frotas (fleet) ou suporte a ARM64.

Progresso atual, com franqueza

Publicamente: planned, apenas isso. Na linha experimental interna, a equipe de engenharia compilou, na direção do Debian 13, uma imagem experimental amd64 do Edge e deixou registros de compilação, mas a imagem não foi conservada, não há entrada para download e não foi feita validação de inicialização por firmware. Entre uma compilação experimental e um lançamento público há os quatro requisitos acima; quem anunciar na internet um pacote oficial do KINGAI OS Edge não está falando em nome oficial.

Ver o roteiro das quatro edições → Ver o registro de versões → Ver antes a edição servidor já lançada → Acompanhar o progresso nas Issues →