Notatka od Zima
Dziękujemy, sbinske, za pokazanie, że użyteczny serwer domowy nie musi zaczynać się od specjalistycznego sprzętu serwerowego ani profesjonalnego doświadczenia w administracji. Twoja konfiguracja retro LAN party zmieniła nieużywane części komputera w system ZimaOS z uruchomionymi usługami Docker, wieloma maszynami wirtualnymi, DNS-em, TeamSpeakem i narzędziami pomocniczymi potrzebnymi do przeprowadzenia tradycyjnego wydarzenia w sieci lokalnej.
Szczególnie doceniamy to, że udokumentowałeś rozwiązywanie problemów równie jasno jak sam sukces. Zawieszanie się GT710, niestabilność karty sieciowej, ograniczenia napotkane w procesie korzystania ze Sklepu z aplikacjami oraz prośba o bardziej elastyczne łączenie pamięci masowej to właśnie ten rodzaj informacji zwrotnej, który pomaga pokazać, gdzie lekki system jest przystępny, a gdzie wciąż wymaga od hobbysty zbyt wiele.
— Zima
Poznaj sbinske
sbinske opisuje siebie jako nieprofesjonalnego użytkownika technologii i hobbystę DIY. To rozróżnienie ma znaczenie dla tej historii. Nie podchodził do ZimaOS jako administrator systemów szukający kolejnej platformy do testów porównawczych. Podszedł do niego jako ktoś, kto lubi coś budować, ponownie wykorzystywać sprzęt i osiągać praktyczne rezultaty bez przekształcania każdego projektu w infrastrukturę klasy enterprise.
Zanim zdecydował się na ZimaOS, przez długi czas szukał alternatywy dla Unraida. Przyciągnęło go nie odwzorowanie funkcji jeden do jednego. Właściwie jedną z rzeczy, które mu się spodobały, było to, że ZimaOS wydawał się lżejszy i nie próbował być tak rozbudowany jak Unraid.
Jego projekt z lutego 2026 roku stał się bardzo konkretnym testem tego pomysłu: czy stosunkowo lekki system operacyjny do serwera domowego może obsłużyć zestaw kontenerów, maszyn wirtualnych, sieci i pamięci masowej potrzebny podczas retro LAN party?
Retro LAN party stało się przypadkiem testowym
Serwer był przygotowywany na tradycyjny LAN party, podczas którego infrastruktura musiała działać lokalnie i obsługiwać wydarzenie bez uzależnienia od zestawu zewnętrznych usług.
W czasie dokumentowania budowy ZimaOS uruchamiał już dwa kontenery Docker: serwer TeamSpeak i serwer DNS. Oprócz nich działały trzy maszyny wirtualne: ETI-SyncServer, LanPage VM oraz kolejna maszyna wirtualna przeznaczona do organizowania pozostałych usług związanych z wydarzeniem.
To właśnie to obciążenie sprawiło, że projekt stał się ciekawszy niż zwykły test NAS-a. Pamięć masowa była tylko jednym z jego elementów. System musiał jednocześnie obsługiwać także usługi sieciowe i kilka odizolowanych maszyn wirtualnych.
Dlaczego ZimaOS sprawdził się jako lekka alternatywa dla Unraida
Porównanie sbinske z Unraidem było celowo praktyczne. Nie oczekiwał, że ZimaOS odtworzy wszystkie możliwości Unraida. Chciał mniejszego systemu, który obejmowałby funkcje, których rzeczywiście potrzebował, i pozostał na tyle zrozumiały, by hobbysta mógł z niego korzystać.
Gdy problemy sprzętowe udało się opanować, jego ogólne doświadczenia były pozytywne. System ustabilizował się i sprawnie obsługiwał obciążenie związane z imprezą LAN, wokół którego został zbudowany.
Obecna dokumentacja ZimaOS nadal opisuje maszyny wirtualne jako rozwijany element platformy, podczas gdy cały system łączy pamięć masową, aplikacje Dockera i wirtualizację w jednym interfejsie. Dzięki temu projekt sbinske jest dobrym przykładem wykorzystania tych elementów razem, zamiast traktowania każdej funkcji jako osobnego pokazu.
Pierwszy poważny problem wyglądał jak zawieszenie ZimaOS
Budowa systemu nie rozpoczęła się bezproblemowo. sbinske zgłosił, że ZimaOS całkowicie się zawieszał po około 20 minutach pracy.
Po sprawdzeniu dzienników i przetestowaniu podzespołów ustalił, że pierwsza seria problemów była związana ze starą kartą NVIDIA GeForce GT 710. Próbował ręcznie zainstalować sterowniki za pomocą terminala, ale nie rozwiązało to problemu. Bez powodzenia eksperymentował także ze zmianami związanymi z dyskami wirtualnymi.
Ostatecznie wyjął kartę graficzną, zresetował system i ponownie zainstalował ZimaOS bez niej. Czysta instalacja znów działała prawidłowo.
Należy traktować to jako zgłoszony przez twórcę problem ze zgodnością dotyczącą jego konkretnego komputera, a nie jako ogólne stwierdzenie, że każda karta GT 710 jest niezgodna z każdą wersją ZimaOS. Źródła opisują, co wydarzyło się w tej konfiguracji; nie ustanawiają uniwersalnej zasady dotyczącej sterowników.
Ponowne podłączenie GPU ujawniło bardziej złożony problem sprzętowy
Gdy sbinske ponownie podłączył kartę graficzną, zachowanie systemu się zmieniło. Zamiast jedynie problemu wyglądającego na związany ze sterownikiem grafiki komputer zaczął wielokrotnie rozłączać i ponownie wykrywać dyski twarde oraz karty sieciowe.
Dzienniki pokazywały błędy, ale nie mógł z przekonaniem przypisać ich do konkretnej karty sieciowej ani wyłącznie do karty graficznej. Zmienił więc metodę diagnozowania: usuwał sprzęt po jednym komponencie i obserwował moment, w którym system przestawał zgłaszać problemy.
Ten proces doprowadził do najbardziej jednoznacznego wyniku całej sesji debugowania. System był niestabilny przy trzech dodatkowych kartach sieciowych oraz wbudowanym interfejsie sieciowym płyty głównej. Przy zaledwie dwóch dodatkowych kartach sieciowych komputer działał prawidłowo.
Podejrzewał problem z przydzielaniem linii PCIe — ale go nie udowodnił
Host nie był serwerowym sprzętem zaprojektowanym do tego celu. Wykorzystano procesor AMD Ryzen 5 2600, płytę główną MSI B450 Plus oraz 64 GB pamięci RAM — zasadniczo dodatkowe podzespoły dostępne na potrzeby projektu.
sbinske podejrzewał, że połączenie płyty głównej, procesora, karty graficznej i kilku kart sieciowych mogło doprowadzić do problemu z liniami PCIe lub przydziałem zasobów. Nie kontynuował jednak dochodzenia na tyle długo, aby potwierdzić tę teorię, ponieważ komputer już spełniał jego potrzeby przy użyciu dwóch dodatkowych kart sieciowych.
Ta granica jest istotna. Znany jest rezultat udanego rozwiązywania problemu: po ograniczeniu kombinacji kart rozszerzeń system stał się stabilny. Dokładna przyczyna elektryczna, firmware’owa lub związana z przydziałem linii pozostaje hipotezą twórcy, a nie potwierdzoną usterką ZimaOS.
Gdy sprzęt przestał sprawiać problemy, serwer pozostał stabilny
Po zmniejszeniu liczby kart sieciowych i usunięciu problematycznej kombinacji sprzętowej sbinske poinformował, że system działał stabilnie.
To zmieniło jego postrzeganie projektu. Początkowe zawieszanie się sprawiało, że instalacja wyglądała na niestabilną, ale późniejsze zachowanie sugerowało bardziej złożoną interakcję między systemem operacyjnym a nietypowym zestawem używanych podzespołów komputerowych.
W przypadku samodzielnie zbudowanego systemu ta różnica była ważniejsza niż wskazanie jednej, idealnej przyczyny. Udało mu się skonfigurować system tak, aby usługi na imprezę LAN mogły działać, a dwie karty sieciowe już wystarczały do zaplanowanej roli.
To właśnie App Store sprawiał, że ZimaOS wypadał mniej przyjaźnie niż Unraid
Najpoważniejsza krytyka użyteczności w ankiecie sbinske dotyczyła korzystania z App Store dla zewnętrznych kontenerów Docker.
Jego punktem odniesienia był Unraid: zainstalować App Store, wyszukać kontener, postępować zgodnie z jasnym opisem i formularzem konfiguracji, a następnie go zainstalować. Uważał, że ZimaOS może osiągnąć ten sam rezultat, ale dodawanie nieznanego kontenera lub kontenera innej firmy wymagało zbyt dużej wiedzy od osób niebędących profesjonalistami i hobbystów.
Te opinie zebrano w lutym 2026 roku. Aktualna dokumentacja ZimaOS informuje, że użytkownicy mogą importować dowolne pliki YAML Docker Compose, bezpośrednio edytować konfiguracje, uruchamiać stosy złożone z wielu kontenerów oraz korzystać z utrzymywanych przez społeczność sklepów innych firm. Dokumentacja dla deweloperów opisuje również obecny proces pakowania aplikacji w App Store znacznie bardziej szczegółowo.
Te nowsze możliwości nie przekreślają jego pierwotnych doświadczeń. Zapewniają przydatny kontekst: przepływ pracy, który uznał za zbyt skomplikowany, dotyczył dokładnie obszaru, który ZimaOS rozwijał później, w 2026 roku.
Elastyczność pamięci masowej była drugim brakującym elementem
sbinske chciał również mieć większą swobodę w dzieleniu kilku dysków na różne grupy pamięci masowej dla odmiennych obciążeń.
Jego przykład był praktyczny: jedna para dysków mogła działać jako RAID 0, gdy pojemność i szybkość były ważniejsze niż nadmiarowość, podczas gdy druga para mogła działać jako RAID 1 dla danych wymagających dublowania. W szczególności obciążenie SyncServera wymagało ponad 4 TB przestrzeni, ale nie potrzebowało takiego samego poziomu ochrony danych jak ważniejsze zasoby.
Z jego perspektywy możliwość łączenia tańszych, posiadanych już dysków w macierze dopasowane do konkretnych obciążeń mogłaby obniżyć koszt sprzętu i pozwolić lepiej wykorzystać dostępne już dyski.
Aktualna dokumentacja ZimaOS obejmuje RAID 0, RAID 1, RAID 5, RAID 6, JBOD i ZFS. Jednak przejrzana na potrzeby tego artykułu publiczna dokumentacja nie potwierdza jednoznacznie dokładnego scenariusza pracy z wieloma macierzami, o który prosił sbinske — na przykład niezależnego utworzenia dwudyskowej macierzy RAID 0 i oddzielnej dwudyskowej macierzy RAID 1 na tym samym hoście za pomocą standardowego interfejsu. Z tego powodu ta strona zachowuje jego prośbę, zamiast twierdzić, że została ona w pełni zrealizowana.
Definicja sukcesu według użytkownika nieprofesjonalnego
Tym, co czyni ten projekt wartościowym, jest fakt, że sbinske nie oceniał systemu na podstawie liczby udostępnianych zaawansowanych funkcji. Oceniał go na podstawie tego, czy mógł obsłużyć usługi, które rzeczywiście chciał uruchomić.
Po rozwiązaniu problemów sprzętowych odpowiedź była w dużej mierze twierdząca. ZimaOS był lżejszy niż Unraid, ale było to do zaakceptowania, ponieważ jego serwer na imprezę LAN nie potrzebował wszystkich funkcji Unraid. Dwa kontenery Docker, trzy maszyny wirtualne, lokalny DNS, komunikacja głosowa, synchronizacja i usługi zarządzania wydarzeniami wystarczyły, aby serwer stał się użyteczny.
Jego krytyka wynikała z tego samego praktycznego podejścia. Łatwiejsza instalacja zewnętrznych kontenerów Docker zmniejszyłaby próg wejścia. Bardziej elastyczne grupowanie dysków mogłoby obniżyć koszt sprzętu. Lepsza zgodność z nietypowymi kombinacjami kart rozszerzeń do komputerów stacjonarnych sprawiłaby, że projekty wykorzystujące zapasowy sprzęt byłyby mniej nieprzewidywalne.
Historia wciąż się pisze
Historia sbinske'a i Zimy wciąż się pisze. Jego obecny projekt rozpoczął się jako lekka alternatywa dla Unraid na retroimprezę LAN party, a stał się praktycznym testem działania ZimaOS na używanym sprzęcie desktopowym przy mieszanym obciążeniu kontenerami Docker i maszynami wirtualnymi.
Końcowy rezultat nie był idealnie bezproblemową pierwszą instalacją. Był to działający system DIY, osiągnięty dzięki diagnozowaniu problemów na poziomie podzespołów: usunięciu GT 710, ograniczeniu liczby kart rozszerzeń, pozostawieniu dwóch potrzebnych kart sieciowych i kontynuowaniu pracy, gdy komputer utrzymał stabilność.
Dla osoby, która wyraźnie określa się jako hobbysta, a nie profesjonalista, może to być najbardziej wartościowy rezultat tego projektu. System nie ukrył przed nim wszystkich szczegółów technicznych, ale po uproszczeniu konfiguracji sprzętowej zapewnił lżejsze środowisko domowego serwera, którego szukał.
Aby poznać aktualny kontekst platformy, zobacz przegląd funkcji ZimaOS oraz aktualne informacje o konfiguracji RAID.
