Sbinske e ZimaOS: Criar um servidor retro para festas LAN

Conheça sbinske

sbinske descreve-se como um utilizador de tecnologia não profissional e um amador de projetos DIY. Essa distinção é importante para esta história. Não abordou o ZimaOS como um administrador de sistemas à procura de outra plataforma para comparar. Abordou-o como alguém que gosta de construir coisas, reutilizar hardware e obter um resultado prático sem transformar cada projeto numa infraestrutura empresarial.

Antes de escolher o ZimaOS, passou bastante tempo à procura de uma alternativa ao Unraid. O que o atraiu não foi a paridade funcional. Na verdade, uma das coisas de que gostou foi o facto de o ZimaOS parecer mais leve e não tentar ser tão abrangente como o Unraid.

O projeto de fevereiro de 2026 tornou-se um teste muito específico dessa ideia: conseguiria um sistema operativo de servidor doméstico relativamente leve executar a combinação de contentores, máquinas virtuais, rede e armazenamento necessária para uma LAN party retro?

Uma LAN party retro tornou-se o caso de teste

O servidor estava a ser preparado para uma LAN party à moda antiga, em que a infraestrutura tinha de funcionar localmente e suportar o evento sem depender de um conjunto de serviços externos.

Quando documentou a montagem, o ZimaOS já estava a executar dois contentores Docker: um servidor TeamSpeak e um servidor DNS. Juntamente com eles, havia três máquinas virtuais: um ETI-SyncServer, uma VM LanPage e outra VM destinada a organizar os restantes serviços relacionados com o evento.

Essa carga de trabalho tornou o projeto mais interessante do que um simples teste de NAS. O armazenamento era apenas uma parte. O sistema também tinha de alojar serviços de rede e várias máquinas virtuais isoladas em simultâneo.

Porque é que o ZimaOS funcionou como uma alternativa leve ao Unraid

A comparação de sbinske com o Unraid foi deliberadamente prática. Não esperava que o ZimaOS reproduzisse todas as capacidades do Unraid. Queria um sistema mais pequeno que abrangesse as funções de que realmente precisava e que permanecesse suficientemente compreensível para ser utilizado por um amador.

Depois de controlar os problemas de hardware, a sua experiência geral foi positiva. O sistema estabilizou e suportou a carga de trabalho da LAN party que tinha criado em torno dele.

A documentação atual do ZimaOS continua a descrever as máquinas virtuais como uma parte em evolução da plataforma, enquanto o sistema mais abrangente combina armazenamento, aplicações Docker e virtualização numa única interface. Isso torna o projeto de sbinske um bom exemplo de utilização conjunta desses elementos, em vez de tratar cada funcionalidade como uma demonstração separada.

O primeiro grande problema parecia ser um bloqueio do ZimaOS

A montagem não começou de forma tranquila. sbinske relatou que o ZimaOS bloqueava completamente após cerca de 20 minutos de funcionamento.

Depois de verificar os registos e testar os componentes, concluiu que a primeira série de problemas tinha origem numa antiga NVIDIA GeForce GT 710. Tentou instalar manualmente os controladores através do terminal, mas isso não resolveu o problema. Também experimentou alterações relacionadas com unidades virtuais, sem sucesso.

Por fim, removeu a placa gráfica, repôs o sistema e reinstalou o ZimaOS sem ela. A instalação limpa voltou a funcionar corretamente.

Isto deve ser encarado como um problema de compatibilidade reportado por um criador na sua máquina específica, e não como uma afirmação geral de que todas as GT 710 são incompatíveis com todas as versões do ZimaOS. A fonte documenta o que aconteceu nesta configuração; não estabelece uma regra universal relativa aos controladores.

Voltar a instalar a GPU revelou um problema de hardware mais complexo

Quando sbinske voltou a instalar a placa gráfica, o comportamento mudou. Em vez de apresentar apenas aquilo que parecia ser um problema do controlador gráfico, a máquina começou a desligar e a redescobrir repetidamente discos rígidos e placas de rede.

Os registos apresentavam erros, mas não conseguiu atribuí-los com confiança a um adaptador de rede específico ou apenas à placa gráfica. Por isso, alterou o método de resolução de problemas: remover o hardware, um componente de cada vez, e observar o momento em que o sistema deixava de apresentar erros.

Esse processo conduziu ao resultado mais claro de toda a sessão de depuração. O sistema estava instável com três placas de rede adicionais, além da interface de rede integrada na placa-mãe. Com apenas duas placas de rede adicionais, a máquina funcionava bem.

Suspeitou da alocação das vias PCIe — mas não o comprovou

O anfitrião não era hardware de servidor concebido especificamente para esse fim. Utilizava um AMD Ryzen 5 2600, uma placa-mãe MSI B450 Plus e 64 GB de RAM — essencialmente, hardware suplente que estava disponível para o projeto.

O sbinske suspeitava que a combinação de placa-mãe, CPU, placa gráfica e vários adaptadores de rede pudesse ter causado um problema relacionado com vias PCIe ou com a atribuição de recursos. No entanto, não prosseguiu a investigação até ao ponto de provar essa teoria, porque a máquina já satisfazia as suas necessidades com duas placas de rede adicionais.

Essa distinção é importante. O resultado conhecido da resolução de problemas é o seguinte: reduzir a combinação de placas de expansão tornou o sistema estável. A causa-raiz exata, elétrica, de firmware ou de atribuição de vias, continua a ser uma hipótese do criador, não um defeito confirmado do ZimaOS.

Depois de o hardware estabilizar, o servidor manteve-se estável

Depois de reduzir o número de placas de rede e remover a combinação de hardware problemática, o sbinske comunicou que o sistema funcionava de forma estável.

Isso mudou a perspetiva dele sobre o projeto. Os bloqueios iniciais tinham feito a instalação parecer pouco fiável, mas o comportamento posterior sugeria uma interação mais complexa entre o sistema operativo e uma coleção invulgar de componentes de computadores de secretária reutilizados.

Num projeto DIY, essa distinção era mais importante do que identificar uma causa-raiz perfeita. Ele tinha chegado a uma configuração capaz de manter os serviços da LAN party em funcionamento, e duas placas de rede já eram suficientes para a função que tinha planeado.

Era na App Store que o ZimaOS parecia menos intuitivo do que o Unraid

A crítica de usabilidade mais forte no questionário do sbinske dizia respeito à experiência da App Store com contentores Docker de terceiros.

O ponto de referência dele era o Unraid: instalar uma App Store, procurar o contentor, seguir uma descrição e um formulário de configuração claros e, depois, instalá-lo. Considerava que o ZimaOS podia chegar ao mesmo resultado, mas que adicionar um contentor desconhecido ou de terceiros exigia conhecimentos excessivos por parte de não profissionais e entusiastas.

Esse feedback foi registado em fevereiro de 2026. A documentação atual do ZimaOS indica agora que os utilizadores podem importar YAML arbitrário do Docker Compose, editar configurações diretamente, executar conjuntos de vários contentores e utilizar lojas de terceiros mantidas pela comunidade. A documentação para programadores também descreve com muito mais detalhe o atual fluxo de empacotamento da App Store.

Essas capacidades mais recentes não apagam a experiência original dele. Fornecem contexto útil: o fluxo de trabalho que ele considerou demasiado complicado era precisamente o tipo de área que o ZimaOS continuou a desenvolver mais tarde, em 2026.

A flexibilidade de armazenamento era a outra peça em falta

O sbinske também queria mais liberdade para dividir vários discos em diferentes grupos de armazenamento, destinados a diferentes cargas de trabalho.

O exemplo dele era prático: um par de discos podia ser usado como RAID 0, quando a capacidade e a velocidade fossem mais importantes do que a redundância, enquanto outro par podia ser RAID 1 para dados que justificassem o espelhamento. Em particular, a carga de trabalho do SyncServer precisava de mais de 4 TB de espaço, mas não exigia o mesmo nível de proteção de dados que o armazenamento mais importante.

Na sua perspetiva, poder combinar discos existentes mais baratos em arrays específicos para cada carga de trabalho poderia reduzir o custo do hardware e permitir uma melhor utilização das unidades que já tinha disponíveis.

A documentação atual do ZimaOS já abrange RAID 0, RAID 1, RAID 5, RAID 6, JBOD e ZFS. No entanto, a documentação pública consultada para esta história não confirma explicitamente o fluxo de trabalho exato com vários arrays solicitado por sbinske — por exemplo, criar de forma independente um RAID 0 de dois discos e um RAID 1 separado de dois discos no mesmo anfitrião através da interface normal. Por esse motivo, esta página preserva o seu pedido em vez de afirmar que foi totalmente resolvido.

A Definição de Sucesso de um Utilizador Não Profissional

O que torna este projeto útil é o facto de sbinske não ter avaliado o sistema pelo número de funcionalidades avançadas que disponibilizava. Avaliou-o pela sua capacidade de suportar os serviços que realmente queria executar.

Depois da resolução dos problemas de hardware, a resposta foi, em grande medida, sim. O ZimaOS era mais leve do que o Unraid, mas isso era aceitável porque o seu servidor para a LAN party não precisava de todas as funcionalidades do Unraid. Dois contentores Docker, três máquinas virtuais, DNS local, comunicação por voz, sincronização e serviços de gestão de eventos foram suficientes para tornar o servidor útil.

As suas críticas vinham da mesma mentalidade prática. Facilitar a instalação de Docker de terceiros reduziria a curva de aprendizagem. Um agrupamento de discos mais flexível poderia reduzir o custo do hardware. Uma melhor compatibilidade com combinações invulgares de placas de expansão para desktop tornaria os projetos com hardware disponível menos imprevisíveis.

A História Continua a Ser Escrita

A história de sbinske e da Zima continua a ser escrita. O seu projeto atual começou como uma alternativa leve ao Unraid para uma LAN party retro e tornou-se um teste no mundo real de como o ZimaOS se comporta em hardware de desktop reutilizado, sob uma carga de trabalho mista de Docker e máquinas virtuais.

O resultado final não foi uma primeira instalação perfeitamente limpa. Foi um sistema DIY funcional, alcançado através de diagnóstico ao nível dos componentes: remover a GT 710, reduzir a combinação de placas de expansão, manter as duas placas de rede de que realmente precisava e prosseguir quando a máquina se manteve estável.

Para alguém que se descreve explicitamente como um entusiasta, e não como um profissional, esse pode ser o resultado mais útil do projeto. O sistema não lhe ocultou todos os detalhes técnicos, mas, depois de simplificar a combinação de hardware, proporcionou o ambiente de servidor doméstico mais leve que procurava.

Para consultar o contexto atual da plataforma, veja a visão geral das funcionalidades do ZimaOS e a referência atual de configuração de RAID.