Programiści AerynOS, wcześniej znanego jako SerpentOS, opublikowali szczegółowy artykuł, w którym omawiają koncepcję i techniczną realizację projektu, uzasadniając podjęte decyzje architektoniczne. Kierownik projektu Ikey Doherty podkreśla, że AerynOS to nie tylko 'jeszcze jedna dystrybucja Linuksa', ale platforma, fundament i zestaw narzędzi, stworzony zgodnie z jasną wizją.
Główna idea projektu została sformułowana w formie pytania: 'Co, jeśli system operacyjny będzie działał jak nowoczesna infrastruktura?'. AerynOS jest przedstawiony jako odpowiedź na to pytanie — system zbudowany od podstaw, a nie oparty na tradycyjnym modelu wbudowanych mutacji w ramach dystrybucji. Projekt opiera się na doświadczeniu autorów w tworzeniu innych dystrybucji, w tym Solus i Clear Linux.
Wśród kluczowych rozwiązań technicznych AerynOS można wymienić:
- Użycie narzędzi LLVM zamiast GNU, z domyślnym zastosowaniem libc++ i compiler-rt. Programiści wyjaśniają tę decyzję nie tylko preferencją dla LLVM, ale jako strategiczny wybór, by zapewnić lepszą diagnostykę, poprawność i przenośność pakietów. System stosuje glibc zamiast musl, co jest świadomym wyborem na rzecz kompatybilności i wydajności.
Jak wskazano w artykule: 'Zaleta glibc nad musl w wydajności jest dobrze udokumentowana, szczególnie dla obciążeń obliczeniowych oraz aplikacji wymagających optymalnej wydajności wielowątkowej'. Twórcy podkreślają, że ich celem jest zbudowanie funkcjonalnego i użytecznego systemu dla wielu scenariuszy zastosowania.
- Koncepcja 'statelessness' (brak stanu) — pakiety nie mogą zawierać plików poza katalogiem /usr. Jak wyjaśniają programiści, to podejście wymusza zapewnienie rozsądnych wartości domyślnych na wszystkich poziomach i eliminuje 'straszne konflikty trójstronnego łączenia podczas aktualizacji pakietów'. Konflikty nie występują, ponieważ wszystko w /etc i /var należy do użytkownika, a /usr jest wyłącznie dla systemu. Koncepcja ta została opracowana w czasach Clear Linux i Solus, a w AerynOS zyskała dalszy rozwój.
- Atomowe aktualizacje — każda transakcja moss jest atomowa. System szybko tworzy nowe drzewo /usr z wykorzystaniem twardych linków z deduplikowanego cache'a. Po pomyślnym utworzeniu i przygotowaniu, nowe drzewo atomowo zastępuje istniejące. Faktycznie przygotowana transakcja jest wymieniana z rzeczywistym katalogiem /usr za pomocą renameat2 z flagą RENAME_EXCHANGE. Aktualizacja odbywa się albo w całości, albo wcale, bez pośrednich stanów.
- Zarządzanie ładowaniem opiera się na projektach blsforme i disks-rs. Charakterystyczną cechą podejścia jest to, że system dynamicznie formuje parametry dla linii poleceń jądra, odczytując superbloki urządzeń głównego systemu plików, dlatego w AerynOS nie ma pliku konfiguracyjnego zawierającego parametr „root=”. Co więcej, identyfikator transakcji moss jest kodowany w linii poleceń jądra i przetwarzany podczas wczesnego ładowania w initramfs. „Mówiąc krótko, oznacza to, że każde jądro jest prawidłowo zsynchronizowane z odpowiednim głównym systemem plików, a cofanie zmian jest tanie, proste i dostępne bezpośrednio z menu rozruchowego” — wyjaśniają deweloperzy. Kolejną zaletą jest brak /etc/default/grub, a jeśli ESP zostanie usunięty, moss może go przywrócić od podstaw.
- Format pakietów .stone to autorski binarny format pakietów z nagłówkiem niezależnym od wersji, aby zapewnić przyszłe zmiany. Każdy pakiet .stone zawiera cztery konkretne typy danych (ładunek), każdy z nich może rozwijać się niezależnie dzięki wersjonowaniu:
- Ładunek treści (Content payload) — sekwencyjny blok deduplikowanych danych, czyli sama zawartość plików pakietu.
- Ładunek indeksowy (Index payload) — zawiera przesunięcia dla ładunku treści, zindeksowane według hasha XXH128 zawartości (planowane przejście na Blake3). Umożliwia to efektywne znajdowanie i wydobywanie danych.
- Ładunek układu (Layout payload) — opisuje przewidywany układ systemu plików po zastosowaniu pakietu, czyli gdzie i jakie pliki powinny zostać zainstalowane.
- Metadane (Metadata payload) — sekwencja ściśle typowanych, oznaczonych rekordów metadanych, takich jak nazwa pakietu, oferowane możliwości itp.
Kompresja wszystkich obciążeń odbywa się za pomocą Zstd, co zapewnia doskonałą wydajność dekompresji przy zachowaniu dobrego współczynnika kompresji. Proces "instalacji" .stone zasadniczo różni się od innych systemów. Zamiast bezpośredniej instalacji plików, pakiet jest buforowany, a jego zawartość splata się w wspólne repozytorium z adresowaniem według zawartości (CAS). Metadane i informacje o layoucie są przechowywane oddzielnie i wykorzystywane przy tworzeniu transakcji. Takie podejście zapewnia atomowość aktualizacji i możliwość wycofania, ponieważ każda transakcja tworzy nowy korzeń, a nie modyfikuje istniejący.
Programiści zauważają, że obecne podejście do emulacji imperatywnego zarządzania pakietami "jest całkowicie bezsensowne" i "w rzeczywistości wprowadza więcej błędów, niż rozwiązuje". Ponieważ dla każdej transakcji tworzony jest nowy rdzeń systemu plików, w przyszłości planowane jest stworzenie nowego grafu dla każdej transakcji, rezygnacja z wbudowanych zmian na rzecz podejścia deklaratywnego, podobnego do Gentoo lub Nix.
Inne interesujące wyjaśnienie dotyczy niezmienności (immutability). Twórcy zauważają, że często AerynOS opisuje się jako system operacyjny o niezmiennej strukturze, ale "to nie do końca prawda". Choć każda transakcja prowadzi do nowego drzewa /usr, a lokalne zmiany nie są zachowywane, system nie jest niezmienny w sensie dostępu tylko do odczytu. W przyszłości planowana jest realizacja prawdziwej niezmienności systemu bez potrzeby ponownego uruchamiania z wykorzystaniem erofs i overlayfs.
Obecnie AerynOS jest aktywnie rozwijany, już wydaje obrazy ISO z środowiskiem GNOME, jest przystosowany do gier (wsparcie dla sterowników NVIDIA, Steam, Flatpak), ma rzeczywistych użytkowników, którzy zauważają stabilność i innowacyjność systemu. Według twórców, projekt znajduje się w fazie wersji alfa i nie jest wolny od problemów, ale już stanowi spójną całość, która "po prostu działa".
Źródło: opennet.ru
