Ten wątek najlepiej czytać jako migawkę ZimaOS z końca 2025 roku, a nie jako aktualną listę funkcji. Autor opisał rzeczywiste problemy po przejściu z CasaOS: problemy z ponownym łączeniem klienta macOS, instalacje aplikacji, które wyglądały na zawieszone, awarie sieci mostkowej po zainstalowaniu aplikacji proxy, słabą lokalizację na język rosyjski, celowo ograniczony system operacyjny hosta, ograniczone przekazywanie urządzeń w ZVM, podstawowe działanie kopii zapasowych oraz pusty panel btop.
Część z tych problemów była błędami, część wynikała z decyzji architektonicznych, a kilka z nich od tego czasu rozwiązano. Oryginalny autor osobiście potwierdził, że monitorowanie za pomocą btop działało po aktualizacji do wersji 1.5.2. Obecne ZimaOS 1.7.1 ma również nowszy App Store, wersjonowane procesy tworzenia kopii zapasowych, szerszy zakres poprawek dotyczących pamięci masowej i sieci oraz znacznie dojrzalszy katalog aplikacji i narzędzi AI. Model urządzenia z systemem tylko do odczytu pozostaje jednak zamierzonym rozwiązaniem.
Problem z monitorowaniem btop został potwierdzony przez autora jako naprawiony w wersji 1.5.2
Autor zaktualizował wątek, informując, że monitorowanie systemu działało poprawnie po przejściu na ZimaOS 1.5.2. To jeden z najjaśniejszych przypadków: nie było to trwałe ograniczenie produktu.
Obecna dokumentacja ZimaOS nadal obejmuje monitorowanie systemu oparte na btop, które pierwotnie wprowadzono w serii 1.3.x.
Zawieszona instalacja aplikacji może wynikać ze stanu interfejsu, stanu Dockera lub problemu z rejestrem
Odpowiedź społeczności sugerowała, że Docker czasami kończył pracę, podczas gdy interfejs nie otrzymywał aktualizacji. Jest to prawdopodobne, ale w tym wątku nie była to diagnoza firmy IceWhale. Współczesne problemy z App Store należy rozdzielać na:
- problemy z pobieraniem obrazu, DNS-em lub rejestrem;
- problemy z utworzeniem lub uruchomieniem kontenera;
- działający kontener, ale nieaktualny stan panelu;
- nieprawidłową konfigurację WebUI lub sieci aplikacji.
Nie należy uznawać „uruchamiania NAS-a ponownie za każdym razem” za trwałe rozwiązanie dla obecnej instalacji.
Nie udowodniono, że V2RayA powodował awarie aplikacji korzystających z sieci mostkowej z powodu błędu podstawowego ZimaOS
Autor źródłowy napisał, że aplikacje korzystające z sieci mostkowej przestały się otwierać po zainstalowaniu V2RayA. Odpowiedź społeczności sugerowała, że zmiany proxy lub DNS mogły zakłócić rozwiązywanie nazw w mostach Dockera. Wątek nie zawiera logów ani potwierdzenia IceWhale łączącego awarię z konkretną regułą DNS lub routingu.
Gdy kontener proxy lub VPN zmienia routing, DNS, iptables/nftables albo przestrzenie nazw sieci Dockera, należy najpierw przeanalizować te zmiany, zamiast obwiniać każdą dotkniętą aplikację.
Host tylko do odczytu to decyzja projektowa, która nadal obowiązuje
Autorowi nie podobało się, że nie mógł instalować dowolnych pakietów w systemie hosta. Krytyka ta jest uzasadniona w przypadku użytkowników, którzy chcą konwencjonalnego serwera Debian/Ubuntu, ale nie jest to przypadkowy błąd. Obecna dokumentacja ZimaOS nadal opisuje większość folderów systemowych jako tylko do odczytu i zakłada, że aplikacje będą uruchamiane za pośrednictwem Dockera, modułów, maszyn wirtualnych lub obsługiwanych rozszerzeń dla deweloperów.
Skorzystaj z obecnego modelu systemu plików CLI w ZimaOS, aby zdecydować, czy podejście urządzeniowe pasuje do Twojego sposobu pracy.
Przekazywanie urządzeń w ZVM było ograniczone, ale sytuacja się zmieniła
Pod koniec 2025 roku oficjalne odpowiedzi w innych miejscach nadal opisywały przekazywanie urządzeń PCIe jako element planów długoterminowych. Do 2026 roku społecznościowe moduły, takie jak ZVM-Extra, dodały przekazywanie urządzeń USB/PCIe na bazie libvirt, ale nadal jest to oprogramowanie społecznościowe, a nie dowód, że każdy scenariusz przekazywania urządzeń jest obecnie wbudowaną i obsługiwaną funkcją ZVM.
W przypadku krytycznego przekazywania urządzeń GPU/HBA/USB sprawdź bieżący interfejs ZVM i grupowanie IOMMU, zamiast traktować skargę z 2025 roku lub społecznościowy moduł beta jako pełny obraz sytuacji.
Stwierdzenie, że „kopie zapasowe tylko kopiują pliki”, jest dziś historycznie niepełne
Obecne rozwiązanie Backup w ZimaOS obsługuje zaplanowane zadania, wznawialne i odporne na błędy transfery, lokalne, USB, chmurowe oraz inne urządzenia Zima jako miejsca docelowe, a także wersjonowane punkty przywracania. Nadal nie jest jednak tym samym produktem co narzędzie do tworzenia zaszyfrowanych archiwów, takie jak Duplicati.
Zapoznaj się z obecnym modelem kopii zapasowych ZimaOS, zanim powtórzysz ograniczenie z 2025 roku.
Interfejs resetowania pokazuje filozofię odzyskiwania urządzenia
Trwałe pytanie brzmi: czy potrzebujesz systemu urządzeniowego?
Użytkownicy, którzy chcą nieograniczonego zarządzania pakietami, ręcznie konfigurowanych usług hosta i konwencjonalnej dystrybucji desktopowej lub serwerowej, mogą nadal preferować Debian, Ubuntu, Proxmox, Unraid albo inną platformę. Użytkownicy, którzy chcą zarządzanej warstwy NAS, Docker App Store, interfejsu pamięci masowej, zdalnego dostępu i chronionych partycji systemowych, mogą preferować ZimaOS.
Wątek z 2025 roku jest wartościowy, ponieważ pokazuje ten kompromis, ale obecnej oceny należy dokonywać na podstawie ZimaOS 1.7.1, a nie zakładać, że każdy objaw z ery 1.5 nadal występuje.
Najczęstsze pytania dotyczące wad ZimaOS
Czy problem z panelem btop został rozwiązany u oryginalnego autora?
Tak. Autor wyraźnie napisał, że monitorowanie zaczęło działać po aktualizacji do ZimaOS 1.5.2.
Czy system plików hosta tylko do odczytu nadal jest zamierzonym rozwiązaniem?
Tak. Obecne ZimaOS nadal jest systemem w stylu urządzeniowym, w którym większość folderów hosta jest tylko do odczytu.
Czy obecne kopie zapasowe nadal ograniczają się do jednorazowego kopiowania plików?
Nie. Obecne rozwiązanie Backup obejmuje harmonogramy, wznawialne transfery, wiele typów miejsc docelowych, wersje i punkty przywracania.
