Hirdetés

  2. Fórumok
  3. [Linux] Vanilla OS, egy Debian alapú immutable operációs rendszer
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD témák
Keresés

Új hozzászólás Aktív témák

  • #29 urandom0 senior tag hcl #28
    Új Válasz #29
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    senior tag

    válasz hcl #28 üzenetére

    Fedora atomic esetében a rendszerfrissítéseknél ez így is van. A Fedora fejlesztők készítenek egy rendszerképet, amibe benne van az összes csomag, ami a rendszert alkotja. A kliens ezt tölti le, és amikor frissítés történik, akkor egyszerűen letölti a rendszer az új rendszerképet, és újraindítás után arról bootol be. Annyi "könnyítés" van a dologban, hogy mint a delta RPM-nél, ugyanígy rpm-ostree esetében is lehet delta commitot csinálni, azaz valójában nem a teljes rendszerkép töltődik le minden egyes alkalommal, hanem csak egy különbözeti kép. De a végén a rendszeren ez így is egy teljes rendszerképként fog megjelenni.
    Így az összes olyan gépen, amin adott verziójú Fedora fut, pontosan ugyanaz a rendszerkép lesz meg. Ez a rendszerkép megbonthatatlan egységet képez, tehát nem tudsz se hozzáadni, se kivenni belőle csomagokat. Ha pl. le akarod cserélni a Firefoxot (ez benne van a képben), akkor nem fog menni. Override-dal lehet uninstallálni, ami azt jelenti, hogy nem lesz elérhető, nem lehet elindítani, de fizikailag attól még ott lesz a lemezen.
    Ugyanúgy override-dal lehet egy-egy csomagt hozzáadni vagy frissíteni, de ezek sem a rendszerképbe kerülnek bele, hanem ráülnek egy új rétegben.

    MicroOS, Aeon és Kalpa esetében ezt nincs így, ott csak simán a zypper telepíti a csomagokat, csak köré van húzva a transactional-update, ami megoldja azt, hogy milyen csomagtelepítés új snapshoton jöjjön létre. De simán törölhetsz csomagokat az alaprendszerből, bár nem ajánlatos.

    Vanillánál ugyanez, lehet törölni vagy hozzáadni bármilyen csomagot az alaprendszerhez, az más kérdés, hogy nagyon nem ajánlott (és erre külön figyelmeztet is).

  • #27 urandom0 senior tag hcl #26
    Új Válasz #27
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    senior tag

    válasz hcl #26 üzenetére

    Mindegyik rendszeren lehet csak egy-egy csomagot frissíteni, nem kell az egész rendszerképet letölteni. Aeonon (ill. Kalpán és MicroOS-en) eleve a zypper frissíti a rendszer, csomagonként jön le minden. Fedorán az rpm-ostree update-tel lehet csak egy csomagot frissíteni, Vanillán pedig a VSO-val.

  • #25 urandom0 senior tag hcl #24
    Új Válasz #25
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    senior tag

    válasz hcl #24 üzenetére

    Csak akkor miért immutable ;] /troll :D

    Ez egyébként nem egy rossz kérdés. Az overlayfs és a systemd-sysext nem változtatja meg a lemezen lévő binárist, csak egy megadott könyvtár tartalmával összefésüli egy kiválasztott, immutable könyvtár tartalmával. Igazából nem is hétköznapi felhasználásra lett kitalálva, hanem elsősorban fejlesztőknek, akiknél előfordul, hogy MUSZÁJ mondjuk az /usr-be tenni egy binárist. Példának okáért magának a Systemd-nek a fejlesztése során is használják a systemd-sysext-et: https://0pointer.net/blog/testing-my-system-code-in-usr-without-modifying-usr.html
    Én arra használtam, hogy Gnome console-t kicseréljem a Ptyxis-re, de nem volt annyira jó ötlet, úgyhogy letettem róla...

    Meg amikor kijön egy 0-day, és hamar kéne javítani :D

    Ezt most nem értem, hogy jön ide :U

  • #18 sh4d0w félisten hcl #17
    Új Válasz #18
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    sh4d0w

    félisten

    LOGOUT blog

    válasz hcl #17 üzenetére

    Annyira nem, hogy egy AIX-en futó middleware managelése vett rá a Linuxra váltásra.

  • #16 urandom0 senior tag hcl #15
    Új Válasz #16
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    senior tag

    válasz hcl #15 üzenetére

    Illetve : ennek a szétkonténerezett rendszernek még céges használatban lehet előnye, mert ugye tök el lehet választva egy olyan környezet, amiről a managelt rendszerekre mászkálsz, meg az, amiről levelezel-stb.

    Én erre nem használnám. A distrobox (és a toolbox) pont azért jött létre, hogy a konténer és a host között minél transzparensebb legyen az átjárás, tehát itt semmilyen biztonság nincs. Docker, Podman vagy Lilipod konténerben lehetne futtatni mondjuk egy levelezőprogramot, de a konténer nem GUI-s alkalmazásokra van kitalálva (nem is mindegyik működik jól konténerben).

    Alapvetően a konténer nem biztonsági megfontolásokból jött létre, hanem hogy az adott program a fejlesztő által megálmodott függőségeivel együtt futhasson.
    Ha én mondjuk írok egy programot, van 28 függősége, de csak Debian 12 alá készítem el, viszont te Fedora 41 alatt akarod futtatni, akkor bajban leszel, mert lehet, hogy Fedora alatt nem is érhetők el azok a függőségek, amik Debian alatt igen. Mit teszel? Felhúzhatsz egy vm-et, és telepíthetsz bele egy Debian 12-t, csak ez sok esetben kicsit overkill.
    Egyszerűbb (és sokkal erőforráshatékonyabb), ha én készítek egy docker image-t a programomból, belerakom a függőségeit, te pedig letöltöd és használod, függetlenül attól, milyen rendszered van.
    És ha egy szép napon úgy gondolod, hogy Fedora helyett Hanna Montana Linuxot akarsz használni, akkor csak feltelepíted arra is a dockert, lehúzod az általam készített image-et, csinálsz belőle egy konténert és használod tovább, mint ha mi sem történt volna.

  • #14 urandom0 senior tag hcl #13
    Új Válasz #14
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    senior tag

    válasz hcl #13 üzenetére

    Nem azt akarom mondani, hogy ha csomagokat akar kezelni, akkor terminálba megy, hanem azt, hogy ha terminálba megy, akkor általában azért teszi, hogy csomagokat kezeljen.
    Meg eleve, immutable rendszerben azért van distrobox (meg toolbox), hogy az ember oda telepítse a csomagokat, ne az alaprendszerbe.

  • #9 urandom0 senior tag hcl #8
    Új Válasz #9
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    senior tag

    válasz hcl #8 üzenetére

    Jó a vm is, és nem is teljesen csereszabatos a konténerekkel. Egyiknek is van egy felhasználási területe, a másiknak is, a kettőnek van közös metszete, de nagyon sok esetben nem cserélhető fel a kettő.

    Cégnél nálunk is minden szolgáltatás vm-ből fut, mondjuk ott van erőforrás, a Proliantok elbírják (nameg a főnököm nem ért a Linuxhoz, szerintem azt se tudja, mi az a konténer). Itthon már csak a kis RPi-m van, ezen nyilván nem futtatok vm-et. De konténerből elmegy rajta a Gitea, a Radicale, meg pár egyéb dolog. Ezekre nagyon jó a konténer.

  • #7 urandom0 senior tag hcl #6
    Új Válasz #7
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    senior tag

    válasz hcl #6 üzenetére

    Már úgy értem, hogy mindig bent van az az SSD a gépben, ha tesztelek, akkor arra telepítek és onnan bootolok.

    Vanillában is ugyanígy jelenik meg, ott is Distrobox van, csak elé van téve az apx, hogy könnyebb legyen boldogulni vele (na, nem mintha a Distrobox olyan bonyolult lenne). Mondjuk az apx GUI-nak szerintem nincs sok értelme, kezdő felhasználó nem fog konténerekkel dolgozni, haladó felhasználó meg megoldja GUI nélkül.

  • #4 urandom0 senior tag hcl #3
    Új Válasz #4
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    senior tag

    válasz hcl #3 üzenetére

    Ezeket lehet érdemes lenne egy virtuális gépen próbálgatni :)

    Van ilyen célra fenntartva egy külön SSD-m. Azért nem akarom vm-ben tesztelni őket, mert úgy nem hozzák ugyanazt a teljesítményt, mint bare metálon.

    Akkor már tényleg az kéne, hogy a desktopról észre se vedd, hogy melyik konténeren fut az a dolog, amit indítottál.

    Igazából a GUI-s appokra az ajánlott telepítési mód a flatpak, a konténerezés inkább a CLI-s programoknak van kitalálva.
    De a legtöbb GUI-s program is fut konténerből, és pont az a cél, hogy a user szempontjából ez transzparens legyen. Most Aeon alatt, ha egy Fedora konténerbe telepítek egy Geany-t, és exportálom, az így jelenik meg a menüben:

    Ha elindítom, akkor teljesen olyan, mint ha az alaprendszerbe lenne telepítve:

    Ha nem lenne odaírva az indítóikonjához, hogy "on fedora", akkor nem tudnád megmondani, honnan fut.

    Vanilla OS-en még annyival is transzparensebb a folyamat, hogy nem neked kell exportálnod, az apx automatikusan megteszi helyetted.

Új hozzászólás Aktív témák