Numa conversa da comunidade em maio de 2024, o diretor de tecnologia da IceWhale, Tiger, e o programador da comunidade Axel discutiram por que motivo os ecossistemas de aplicações do CasaOS e do então emergente ZimaOS avançaram para normas comuns de contentores, em vez de dependerem de um formato de pacotes específico da plataforma.
A ideia central era simples: um ecossistema de aplicações cresce mais rapidamente quando os programadores podem reutilizar ficheiros Docker Compose familiares, adicionar uma pequena quantidade de metadados da loja de aplicações e distribuir aplicações sem terem de negociar diretamente cada contribuição com a equipa principal.
Esta foi uma orientação técnica de 2024, não uma especificação de uma versão atual
A conversa ocorreu enquanto o ZimaOS ainda evoluía a partir de bases partilhadas com o CasaOS. As declarações sobre futuras APIs, workshops, extensões de terceiros e modularização com systemd-sysext descreviam intenções ou experiências numa fase inicial naquele momento. Não devem ser interpretadas como promessas de que todos os conceitos seriam disponibilizados no prazo sugerido.
Por que motivo o formato JSON personalizado inicial das aplicações criou dificuldades
Tiger explicou que a loja de aplicações inicial do CasaOS utilizava um formato JSON personalizado. O ficheiro descrevia metadados associados a uma imagem Docker, incluindo o título da aplicação, o ícone, capturas de ecrã e detalhes de configuração.
O problema não era o JSON não conseguir descrever uma aplicação. O problema era a integração de contribuidores: qualquer pessoa que quisesse publicar uma aplicação tinha primeiro de aprender um formato específico do CasaOS. Esse passo adicional de tradução limitava a rapidez com que projetos de contentores existentes podiam tornar-se aplicações instaláveis.
Por que motivo o Docker Compose se tornou a base do empacotamento de aplicações
A equipa concluiu que o Docker Compose era suficientemente extensível para transportar a definição do contentor e, ao mesmo tempo, acomodar os metadados adicionais necessários à loja de aplicações. Assim, os projetos Compose existentes podiam ser adaptados em vez de reconstruídos num sistema de empacotamento separado.
Esta mudança alterou o modelo de contribuição:
- As imagens de contentores e as definições de serviços podiam continuar a utilizar convenções Docker familiares.
- Os campos da loja de aplicações, como títulos, ícones, capturas de ecrã, portas e informações sobre volumes, podiam ser adicionados à definição Compose.
- Os contribuidores podiam reutilizar o trabalho a montante em vez de manterem um pacote independente e exclusivo da plataforma.
- O ZimaOS e o CasaOS podiam beneficiar do ecossistema mais amplo de alojamento próprio.
O que o Docker Compose mudou nas contribuições da comunidade
A entrevista utilizou uma contribuição inicial da comunidade como exemplo. Tiger recordou que um contribuidor conhecido como Wisdom Sky converteu cerca de 150 imagens de contentores em aplicações CasaOS numa só noite, enquanto o suporte da loja de aplicações baseado em Compose começava a surgir. Anteriormente, a equipa esperava apenas um aumento modesto face ao ritmo antigo de uma ou duas aplicações novas por mês.
Esta foi uma anedota da conversa de 2024, não uma referência à velocidade com que todas as aplicações podem ser empacotadas. Cada aplicação continua a precisar de portas, volumes, suporte de arquitetura, permissões e comportamento de atualização corretos, além da revisão de um responsável pela manutenção.
Como as lojas de aplicações de terceiros se integram no ecossistema
A equipa também descreveu o suporte para fontes de aplicações de terceiros. Em vez de exigir que todos os pacotes da comunidade entrassem no catálogo oficial, um responsável pela manutenção poderia alojar uma fonte independente que os utilizadores poderiam adicionar ao CasaOS ou ao ZimaOS.
Este modelo aumenta a escolha e reduz o estrangulamento da revisão pela equipa oficial, mas também separa a disponibilidade do aval. O facto de uma aplicação aparecer numa fonte de terceiros não significa automaticamente que a IceWhale mantém a sua imagem, audita o seu código, garante as atualizações ou oferece suporte ao seu comportamento de tratamento de dados. Antes da instalação, os utilizadores devem verificar o publicador da imagem, o repositório, os privilégios solicitados, o armazenamento mapeado, a exposição de rede e o histórico de atualizações.
O equilíbrio proposto entre componentes abertos e código proprietário do produto
Tiger afirmou que o ZimaOS estava a ser desenvolvido com base em componentes abertos do CasaOS, incluindo partes da sua base de gateway e barramento de mensagens, enquanto outras camadas do produto permaneceriam proprietárias. A equipa pretendia continuar a aceitar contribuições de código aberto e estava a ponderar disponibilizar mais APIs aos programadores de extensões.
A entrevista não afirmou que todo o código do ZimaOS se tornaria de código aberto. Descreveu uma fronteira híbrida: expor interfaces reutilizáveis e componentes direcionados à comunidade, mantendo privada uma parte selecionada da implementação do produto.
O que a modularização com systemd-sysext pretendia possibilitar
A conversa mencionou um mecanismo muito inicial baseado em systemd-sysext. O objetivo era permitir que terceiros adicionassem extensões ao nível do sistema sem modificarem diretamente o núcleo imutável, de forma semelhante, em princípio, ao desenvolvimento sobre uma interface de plataforma definida.
Como Tiger descreveu explicitamente este trabalho como estando numa fase inicial, esta secção deve ser lida como contexto arquitetural. A publicação não fornecia um SDK público para extensões, um contrato de API estável, uma política de compatibilidade nem uma data de lançamento confirmada.
O princípio mais amplo: reutilizar normas em vez de as reinventar
A conclusão mais duradoura foi a preferência por normas comunitárias existentes. A reutilização do Docker e do Compose reduziu o trabalho específico da plataforma tanto para a equipa da IceWhale como para os contribuidores de aplicações, ligando simultaneamente a loja de aplicações a um conjunto muito maior de software de alojamento próprio.
A visão geral atual do ZimaOS apresenta agora uma loja de aplicações baseada em cenários, suporte Docker de terceiros e um catálogo com mais de 800 aplicações. Esta descrição atual do produto mostra como o ecossistema evoluiu, enquanto a entrevista de 2024 explica o raciocínio de design que a precedeu.
Veja a conversa original sobre o ecossistema da loja de aplicações
O vídeo completo preserva o tom e o contexto histórico da discussão entre Axel e Tiger.
Perguntas frequentes sobre o ecossistema da loja de aplicações do ZimaOS
Por que motivo o CasaOS abandonou um formato de aplicações exclusivamente baseado em JSON personalizado?
O formato personalizado acrescentava uma etapa de aprendizagem para os contribuidores. O Docker Compose permitia aos responsáveis pela manutenção reutilizar uma definição de serviços amplamente conhecida e adicionar os metadados necessários à loja de aplicações.
As lojas de aplicações ZimaOS de terceiros são iguais à loja de aplicações oficial?
Não. As fontes de terceiros podem aumentar a disponibilidade de aplicações, mas os seus pacotes podem ser mantidos e analisados por pessoas diferentes. Antes da instalação, os utilizadores devem avaliar a fonte e a configuração do contentor.
A entrevista confirmou uma API pública de extensões do ZimaOS?
Não. A equipa afirmou que estava a ponderar APIs, workshops e desenvolvimento de extensões. A conversa não publicou uma API estável nem uma data de disponibilização.
O systemd-sysext já era uma funcionalidade concluída do ZimaOS em maio de 2024?
Não. Tiger caracterizou o mecanismo de modularização como estando numa fase muito inicial. Foi apresentado como uma possível via para extensões em torno de um núcleo imutável.
Todo o código do ZimaOS é de código aberto?
A entrevista descreveu um equilíbrio entre componentes abertos e código proprietário do produto, não um sistema operativo totalmente de código aberto.
