Este tópico deve ser lido como um retrato do ZimaOS no final de 2025, e não como uma lista atual de funcionalidades. O autor relatou problemas reais depois de mudar do CasaOS: problemas de reconexão do cliente macOS, instalações de aplicações que pareciam bloqueadas, falhas da rede bridge após instalar uma aplicação de proxy, localização russa deficiente, um sistema operativo anfitrião deliberadamente restrito, passthrough limitado de dispositivos no ZVM, funcionalidades básicas de cópia de segurança e um painel btop vazio.
Alguns desses problemas eram erros, outros eram opções arquiteturais e vários foram entretanto alterados. O autor original confirmou pessoalmente que a monitorização do btop funcionava depois da atualização para a versão 1.5.2. O ZimaOS 1.7.1 atual também dispõe de uma App Store mais recente, fluxos de trabalho de cópia de segurança com versões, mais correções de armazenamento e rede e um catálogo de aplicações/IA muito mais desenvolvido. No entanto, o modelo de appliance apenas de leitura continua a ser intencional.
O problema de monitorização do btop foi confirmado como resolvido na versão 1.5.2
O autor atualizou o tópico para indicar que a monitorização do sistema funcionava corretamente depois de passar para o ZimaOS 1.5.2. Este é, portanto, um dos pontos mais claros: não se tratava de uma limitação permanente do produto.
A documentação atual do ZimaOS continua a incluir a monitorização do sistema baseada no btop, que foi originalmente introduzida na linha 1.3.x.
Uma instalação de aplicação bloqueada pode dever-se ao estado da interface, ao estado do Docker ou a uma falha do registo
A resposta da comunidade afirmava que, por vezes, o Docker terminava enquanto a interface não atualizava o estado. Isso é plausível, mas não foi um diagnóstico da IceWhale neste tópico. As falhas modernas da App Store devem ser separadas em:
- falha de obtenção da imagem/DNS/registo;
- falha ao criar/iniciar o contentor;
- contentor saudável, mas estado desatualizado no painel;
- configuração incorreta da WebUI/rede da aplicação.
Não considere “reiniciar o NAS sempre” uma solução permanente para uma instalação atual.
Não foi provado que o V2RayA a interromper aplicações bridge fosse um erro central do ZimaOS
O autor da fonte afirmou que as aplicações com rede bridge deixaram de abrir depois da instalação do V2RayA. Uma resposta da comunidade sugeriu que alterações ao proxy/DNS poderiam ter interrompido a resolução de nomes da bridge do Docker. O tópico não contém registos nem uma confirmação da IceWhale que associe a falha a uma regra específica de DNS ou encaminhamento.
Quando um contentor de proxy/VPN altera o encaminhamento, o DNS, o iptables/nftables ou os espaços de nomes de rede do Docker, analise essas alterações antes de atribuir a culpa a todas as aplicações afetadas.
O anfitrião apenas de leitura é uma opção de design que continua a existir
O autor não gostou de não poder instalar pacotes arbitrários no anfitrião. Essa crítica é válida para utilizadores que pretendem um servidor Debian/Ubuntu convencional, mas não se trata de um erro acidental. A documentação atual do ZimaOS continua a descrever a maioria das pastas do sistema como apenas de leitura e espera que as aplicações sejam executadas através do Docker, de módulos, de máquinas virtuais ou de extensões de programador suportadas.
Consulte o modelo atual do sistema de ficheiros da CLI do ZimaOS para decidir se a abordagem de appliance é adequada ao seu fluxo de trabalho.
O passthrough no ZVM era limitado, mas a situação evoluiu
No final de 2025, respostas oficiais noutros locais ainda descreviam o passthrough PCIe como uma funcionalidade prevista para uma fase posterior. Em 2026, módulos da comunidade, como o ZVM-Extra, adicionaram passthrough de USB/PCIe sobre libvirt, mas isso continua a ser software da comunidade e não prova que todos os fluxos de trabalho de passthrough sejam agora uma funcionalidade integrada e suportada do ZVM.
Para passthrough crítico de GPU/HBA/USB, valide a interface atual do ZVM e o agrupamento IOMMU, em vez de tratar uma queixa de 2025 ou um módulo beta da comunidade como sendo toda a realidade.
A crítica de que a “cópia de segurança apenas copia ficheiros” está agora historicamente incompleta
A cópia de segurança atual do ZimaOS suporta tarefas agendadas, transferências retomáveis e tolerantes a falhas, destinos locais/USB/nuvem/outro Zima e pontos de restauro com versões. Continua, contudo, a não ser o mesmo produto que um utilitário de arquivo encriptado, como o Duplicati.
Consulte o modelo atual de cópia de segurança do ZimaOS antes de repetir a limitação de 2025.
A interface de reposição demonstra a filosofia de recuperação de appliance
A questão duradoura é saber se pretende um sistema operativo appliance
Os utilizadores que pretendem uma gestão de pacotes sem restrições, serviços do anfitrião editados manualmente e uma distribuição convencional para desktop/servidor podem continuar a preferir Debian, Ubuntu, Proxmox, Unraid ou outra plataforma. Os utilizadores que pretendem uma camada NAS gerida, uma App Store Docker, uma interface de armazenamento, acesso remoto e partições do sistema protegidas podem preferir o ZimaOS.
O tópico de 2025 é valioso porque expõe esse compromisso, mas a avaliação atual deve ser feita com base no ZimaOS 1.7.1, sem presumir que todos os sintomas da era 1.5 ainda existam.
Perguntas frequentes sobre as desvantagens do ZimaOS
O painel btop avariado foi corrigido para o utilizador original?
Sim. O autor afirmou explicitamente que a monitorização funcionava depois da atualização para o ZimaOS 1.5.2.
O sistema de ficheiros do anfitrião apenas de leitura continua a ser intencional?
Sim. O ZimaOS atual continua a ser um sistema ao estilo de appliance, no qual a maioria das pastas do anfitrião é apenas de leitura.
A cópia de segurança atual continua a ser apenas uma cópia única de ficheiros?
Não. A cópia de segurança atual inclui agendamentos, transferências retomáveis, vários tipos de destino, versões e pontos de restauro.
