2
0
Fork 0
mirror of git://git.savannah.gnu.org/guix/maintenance.git synced 2023-12-14 03:33:04 +01:00
maintenance/talks/szabad-szoftver-konferencia-hu-2018/talk.pdfpc
2018-05-14 10:45:02 +02:00

88 lines
5.4 KiB
Plaintext

[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.