mirror of
git://git.savannah.gnu.org/guix/maintenance.git
synced 2023-12-14 03:33:04 +01:00
87 lines
5.4 KiB
Text
87 lines
5.4 KiB
Text
[duration]
|
|
21
|
|
[notes_position]
|
|
RIGHT
|
|
[last_minutes]
|
|
3
|
|
[end_user_slide]
|
|
14
|
|
[notes]
|
|
### 1
|
|
|
|
### 2
|
|
Itt az első követelmény lazítható, úgy, hogy ekvivalens bemenetetek esetén ekvivalens kimeneteket várunk el.
|
|
|
|
A második követelmény valójában annyi, hogy perzisztens adatszerkezetben tároljuk az eredményeket.
|
|
|
|
A gyakorlati megvalósításokban irányított aciklikus gráfot használunk.
|
|
|
|
A cél az, hogy ha szükséges, akkor egy tetszőleges verziót újra elő lehessen állítani. Az adatszerkezetben csak konzisztens állapotoknak megfelelő konfigurációt tárolunk.
|
|
|
|
Ez egy node esetén nem okoz problémát, de nagyobb deployment esetén ezt így nem lehet csinálni.
|
|
|
|
Olyan módszerek is kellenek, amik ellenőzik, hogy az állapot valóban összeegyeztethető a tárolt gráffal.
|
|
### 3
|
|
Például frissítés közben megszűnik az áramellátás, vagy egyszerűen valamelyik csomag frissítésekor hiba lép fel. A régi csomag függőségek már eltávolításra kerültek, esetleg maga a régi csomag is, az új csomagot pedig nem sikerült feltelepíteni. Ez azt jelenti, hogy az adott csomag funkcionalitása nem elérhető. A legsúlyosabb esetekben ez akár bootolhatatlan rendszert is eredményezhet.
|
|
|
|
Ugyanez az időablak a nix és guix esetében egy symlink atomikus átváltására szűkül. Ha ez nem sikerül, akkor egyszerűen annyi történik, hogy a régi rendszeren maradunk.
|
|
|
|
A nix és guix semmi olyan szoftvert nem töröl, ami valaha a rendszeren telepítve volt, erre kifejezetten kérni kell. Ilyen esetben a csomagkezelő azokat a szoftvereket törli, amelyekről bizonyítani tudja, hogy azt más szoftver a rendszeren nem használja. Lehetőség van bizonyos szoftvereket megjelölni, hogy használatban vannak, így lehet kezelni a nem guix-el telepített szoftverek függőségeit, amiről a guix nem tudhat. Jobb módszer, ha lehetséges guix csomagot készíteni, mert így rendszeren belülre hozzuk a függőségeket.
|
|
|
|
A nixos és guixsd konfiguráció központosítja a konfigurációkezelést, és a GuixSD esetében lehetővé teszi a konfigurációs függőségek megvilágítását is (Shepherd service extension).
|
|
|
|
Fontos alap feltételezés, hogy a központi csomagkezelés csak akkor működik, ha mindent nix-el/guix-el csomagolunk.
|
|
### 4
|
|
A bitről bitre reprodukálhatóságnak rengeteg előnye van. Az egyik legfontosabb, hogy helyi újrafordítással az eredményt összehasonlítva meggyőződehetünk róla, hogy a csomagot ugyanúgy állították elő, mint ahogy mi tennénk.
|
|
|
|
Ezen felül lehetőséget biztosít a helyettesítőcsomagok hash alapján történő azonosítására.
|
|
|
|
Szintén lehetőséget ad arra, hogy a központi tároló tartalomcímezhető legyen. Ebben az esetben kialakítható zero trust architektúra, hiszen bárhonnan letöltve a helyetttesítőcsomagot, biztosak lehetünk benne, hogy tényleg ugyanazt a szoftvert futtatjuk, nem vagyunk ráutalva arra, hogy megbízzunk a helyettesítőket biztosító szerverben.
|
|
### 5
|
|
Ez egy nix kifejezés. Ez a nix csomagdefiníciós nyelve.
|
|
|
|
Alapvetően egy haskell típusú nyelv, némi bash szkripttel vegyítve.
|
|
|
|
Ez egy külső DSL, saját ad-hoc szintaxisa van, és külön értelmező kell hozzá.
|
|
|
|
Ezeket a kifejezéseket host side kódnak hívják.
|
|
|
|
A build side kód c++.
|
|
|
|
Külön repositoryban kezelik a host és build side kódokat.
|
|
### 6
|
|
Ez egy guix csomagdefiníció.
|
|
|
|
A nyelv egy belső DSL, a hostnyelv a guile scheme.
|
|
|
|
A nyelvet g-exp-nek nevezik. A scheme a define-syntax konstrukciójával különösen alkalmas belső DSL-ek definiálására, amik teljes mértékben olyan érzést eredményeznek a programozás során, mintha eleve a nyelv részét képeznék.
|
|
|
|
A host side és build side kód ugyanabban a repoban van, és guile scheme nyelven íródott.
|
|
|
|
Az egyetlen olyan rész ami még mindig C++ az a daemon. Jelenleg folyamatban van az újraimplementálása schemeben.
|
|
### 7
|
|
A GuixSD egy teljes mértékben GNU FSDG-vel kompatibilis disztribúció.
|
|
|
|
Ez a hivatalos GNU disztribúció.
|
|
|
|
A GNU Guix a GNU hivatalos csomagkezelője.
|
|
|
|
A GNU Guile scheme a GNU hivatalos kiterjesztési nyelve.
|
|
### 8
|
|
Ezen kívül lehetőség van minden felhasználó számára tetszőleges profilokat definiálni, és bármelyik profil bármelyik generációjára váltani.
|
|
|
|
Szintén lehetőség van profil manifesteket készíteni, ami lehetővé teszi például a csomagok verzióinak kötését.
|
|
|
|
Lehetőség van egyszerű parancssori argumentumokkal a szoftver patchelt vezióinak fordítása a tesztelési fázisban.
|
|
|
|
A csomagkezelő nyelv lehetővé teszi a csomag örököltetését egy másik csomagból, ami azt jelenti, hogy kisebb variánsok, például egy patchelt verzió, vagy egy olyan, amin nem futtatjuk le a teszteket, esetleg más konfigurációs flagekkel, vagy bemenetekkel fordítunk csak néhány sor.
|
|
### 9
|
|
Itt fontos megjegyezni, hogy milyen mértékben lehet azt funkcionálissá tenni. A GuixSD itt egy elég extrém irányt vett, a funkcionális működéshez szükséges dologkat a lehető legkorábban, már az initrd-ben betölti.
|
|
|
|
Tulajdonképpen így a bootloader és a kernel parancssor kerül ki a funkcionális konfiguráció keretei közül.
|
|
|
|
Ezen kívül jelenleg a rendszertelepítés nem funkcionális, elsősorban nincs funkcionális particionáló nyelv.
|
|
|
|
Tehát itt fordulhatnak még elő inkonzisztenciák.
|
|
|
|
Jelenleg igyekszünk, hogy lehetőséget biztosítsunk a rendszertelepítés funkcionálissá tételére, illetve a bootloader konfiguráció és a kernel command-line monitorozására.
|