Jak Snappy odnosi się do Nixa i Guixa?

Szukałem porównania, ale nie znalazłem i nie jestem wystarczająco dobrze poinformowany, aby sam to zrobić.

Wszystkie zapewniają aktualizacje transakcyjne, ale różne poziomy powstrzymywania.

• Snappy kompiluje się statycznie w bibliotekach, aby zapewnić wiele wersji zależności binarnych. Deklaruje dostarczone (i potrzebne?) Usługi jako metadane. Pakiet jest dostarczany jako pojedynczy obraz?
• Nix zajmuje się dynamicznym łączeniem w celu zapewnienia wielu wersji zależności binarnych? Deklaruje dostarczone i potrzebne usługi jako metadane. Pakiet jest dostarczany przez repozytorium zajmujące się zależnościami.
• Guix jest jak Nix, ale oferuje integrację GNU.

Bardziej szczegółowe porównanie między Nixem a Guixem podaje Sander van der Burg , którego nie studiowałem szczegółowo. Zgaduję, że ktoś w Canonical dokonał analizy istniejących rozwiązań. Istnieją inne systemy wdrażania oparte na obrazach, jak mi powiedziano CoreOS.

Jak więc Snappy Ubuntu odnosi się do Nixa i Guixa? Jakie są główne różnice?

Ostatnio sam dokonałem oceny. Jestem współtwórcą Nix / NixOS i byłym badaczem zainteresowanym technologią wdrażania.

Starałem się jak najbardziej trzymać się faktów, ale prawdopodobnie nie mogę pozostać całkowicie bezstronny. Podsumowując moje ustalenia:

• Oba podejścia przechowują pakiety osobno . Snappy przechowuje aplikacje i frameworki w folderach przy użyciu następującej konwencji nazw /app/name/version.vendor:, podczas gdy Nix używa /nix/store/hash-name-version.

  Konwencja nazewnictwa Nix jest bardziej wydajna, ponieważ korzysta z prefiksów skrótu pochodzących ze wszystkich zależności kompilacji . Dzięki Nix możesz łatwo rozróżnić dowolny wariant pakietu i przechowywać je obok siebie. Każda zmiana (np. Inna procedura kompilacji, aktualizacja biblioteki, aktualizacja kompilatora) daje nowy skrót, umożliwiając przechowywanie każdego możliwego wariantu obok siebie.

• Aby umożliwić pakiet aby odnaleźć jego zależności, Nix wiąże je statycznie do pliku wykonywalnego (np modyfikując RPATHo binarnym ELF) lub przez owijanie ich w skryptach, które wyróżniają odpowiednie zmienne środowiskowe (np CLASSPATH, PYTHONPATH, PERL5LIB, itd.).

  Snappy komponuje kontenery, w których pliki wykonywalne mogą znaleźć swoje zależności we wspólnych lokalizacjach FHS, takich jak /libi/bin

  Jednak Nix obsługuje również podejście kontenera Snappy'ego, ale jest ono używane tylko w bardzo rzadkich przypadkach. Najbardziej znanym pakietem Nix wykorzystującym podejście kontenerowe jest Steam w NixOS, ponieważ Steam jest narzędziem do wdrażania o sprzecznych właściwościach.

• Snappy Ubuntu Core używa tak zwanego schematu partycjonowania „A / B” w celu uaktualnienia (i przywrócenia) systemu podstawowego. Obsługuje tylko ograniczoną liczbę wersji (zwykle dwie) jednocześnie.

  W przeciwieństwie do tego, NixOS (dystrybucja Linuksa oparta na Nix) komponuje system podstawowy z pakietów Nix również w sklepie Nix i jest znacznie potężniejszy. Możesz przywrócić poprzednią konfigurację, która nie została jeszcze zutylizowana. Ponadto można udostępniać podobne pakiety systemowe między pokoleniami.

• Oba narzędzia obsługują nieuprzywilejowane instalacje użytkowników . Jednak Snappy przechowuje wszystkie pliki w katalogu domowym użytkownika. Jeśli dwóch użytkowników zdarzy się zainstalować ten sam pakiet, wówczas są instalowani dwukrotnie w systemie.

  W przeciwieństwie do tego, pakiety Nix pozwalają również zwykłym użytkownikom instalować pakiety w centralnym sklepie Nix, aby identyczne pakiety mogły być współużytkowane przez użytkowników. Częściowo ze względu na konwencję nazewnictwa (używanie skrótów) można to zrobić w bezpieczny sposób.

• Snappy ogranicza zachowanie pakietów uruchomieniowych po wyjęciu z pudełka, podczas gdy Nix nie

• Snappy nie pomaga użytkownikom w konstruowaniu pakietów z kodu źródłowego. Nix ma jednak DSL, który pozwala ludziom to zrobić dość łatwo i automatycznie instaluje wszystkie zależności kompilacji (kompilatory, narzędzia kompilacji, biblioteki itp.) W razie potrzeby

• Snappy prawie nie obsługuje modularyzacji i ponownego użycia . W przykładowych pakietach wszystkie zależności bibliotek są spakowane statycznie, zużywając znacznie więcej miejsca na dysku i pamięci RAM. Co więcej, dokumentacja nie wydaje się zapewniać żadnych ułatwień poza ramami. Jednak ramy nie są przeznaczone do ponownego wykorzystania zgodnie z dokumentacją

  Dzięki modułowym pakietom Nix i bezpiecznemu zarządzaniu zależnościami są to niektóre jego kluczowe cechy.

Pełny wpis na blogu można znaleźć tutaj: http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html

Mam nadzieję, że przeczytanie go jest interesujące i być może jest w nim kilka rzeczy, o których warto pomyśleć.