Hirdetés
- UHD filmek lejátszása
- Újabb koronát kapott a Gigabyte alaplapja
- Pánik a memóriapiacon
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Házimozi belépő szinten
- Fujifilm X
- Milyen notebookot vegyek?
- Kettő együtt: Radeon RX 9070 és 9070 XT tesztje
- Gaming notebook topik
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
Új hozzászólás Aktív témák
-
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).
-
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.
-
Csak akkor miért immutable
![;]](//cdn.rios.hu/dl/s/v1.gif)
/troll 
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
Ezt most nem értem, hogy jön ide
-
Most így hirtelen elképzelni sem tudok ilyet, de ilyen esetben általában az szokott lenni, hogy jön valami új fejlesztés, és átáll rá a disztró. Pl. az X-nek is van egy csomó koncepcionális hibája, amit a Wayland javít. Vagy a SysV initnek is vannak korlátai, amiket másik init rendszer javít.
Magának az immutabilitásnak vannak olyan következményei, ami miatt egyes dolgokat nem lehet (vagy nem olyan könnyen lehet) megoldani ilyen rendszeren, mint hagyományos rendszeren igen. Pl. egy disztró által szállított binárist felülírni. De erre is van megoldás, Fedora atomicnál pl. az rpm-ostree override, más rendszereken pedig a systemd-sysext, vagy az overlayfs. Tehát azt akarom mondani, hogy előbb-utóbb mindenre lesz (valamilyen) megoldás. -
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. -
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. -
Én nem szeretném, hogy egységesek legyenek, sőt pont az az érdekes bennük, hogy melyik milyen válaszokat ad az egyes problémákra.
terminalt inditva nem csak csomagmuveleteket vegzunk
Én próbálok mindig a kevésbé terminál orientált user fejével gondolkodni (úgynevezett "átlag felhasználó"), és ilyen szemszögből próbáltam kitalálni megérteni a motivációt az egyes disztrófejlesztői döntések mögött. És arra jutottam, hogy az egyetlen értelmes motiváció amögött, hogy a shell egy konténerbe nyílik, hogy az a felhasználó, aki általában mindenre GUI-t használ, jellemzően csomagokat kezelni jár a terminálba. Aztán persze lehet, hogy hülyeség, de mi más lehetne az indok?
Fájlokat ritkán kezel az átlag felhasználó terminál alól, Nvidia drivert nem lehet konténerből telepíteni, az alaprendszert nem lehet konténerből menedzselni...
Én sokat terminálozok, nekem pont ezért nem jó az, ha egyből oda nyílik a terminál. De akkor kinek jó?Volt tobb dolog is, ami meglepett az irasodban, tobbek kozott a mount es jelszocsere koruli "anomaliak" - hiszen Te magad irtad le, hogy terminalt inditva a kontenerben indul a shell, nem pedig a hoston.
Ez mondjuk igaz, ha kicsit jobban átgondoltam volna a dolgot, nem értek volna meglepetések.
nagyon helyes, hogy a jelszovaltoztatas es a mount az immutable rendszeren tortenik, ha nem ott tortenne, a lenyeget veszitene el.
A jelszóváltoztatásra azt mondom, igen, az így oké. De az, hogy a user home-ja át van mappelve a konténer home-jára, DE a home-ba csatolt fájlrendszer már nem jelenik meg a konténer home-jában, az szerintem egyértelműen hiba. Ezt nem lehet mivel megindokolni, a biztonság itt nem játszik, mert a distrobox konténer eleve nyitott, pont az a cél, hogy transzaprens legyen a felhasználó számára az, hogy a hoston van, vagy konténerben.
-
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.
-
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.
-
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.
-
#2
urandom0
őstag
Hieronymus
#1
válasz
Hieronymus
#1
üzenetére
Így van.
Ez egy viszonylag egyszerű és bombabiztos megoldás, nem nagyon van, ami tönkremehet menet közben. Viszont eléggé korlátot.
Az Aeon-féle snapperes megoldás komplexebb, mint ahogy az OSTree is, viszont rugalmasabbak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
/troll 
Új hozzászólás Aktív témák
- NFL és amerikai futball topik - Spoiler veszély!
- Samsung Galaxy S21 FE 5G - utóirat
- UHD filmek lejátszása
- Újabb koronát kapott a Gigabyte alaplapja
- A középkategória egyik legjobb vétele - Dreame L40 Ultra AE
- Elemlámpa, zseblámpa
- Arc Raiders
- Pánik a memóriapiacon
- Xiaomi 15T Pro - a téma nincs lezárva
- LEGO klub
- További aktív témák...
- Bomba ár! Lenovo ThinkPad L13 G1i - i5-10GEN I 8GB I 256SSD I 13,3" FHD I HDMI I W11 I Cam I Gar
- Bomba ár! Lenovo ThinkPad L390 - i5-8GEN I 8GB I 256SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- Lenovo ThinkPad X1 Carbon Gen 9 i7-1185G7 32 GB RAM Iris Xe 4k kijelző törésgarancia
- Bomba ár! Lenovo ThinkPad X13 G1- i5-10310U I 16GB I 256SSD I 13,3" FHD Touch I Cam I W11 I Gari!
- Eladó Denon 4400h
- Gamer PC i5 14. gen. // RTX 3080 // BOLTBÓL 27%-os SZÁMLÁVAL, GARANCIÁVAL //
- Nuki Smart KeyPad 1 okos zár kiegészítő
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- 2db Apple Lightning - jack átalakító eladó egyben 1999 Ft
- REFURBISHED és ÚJ - DELL Universal Dock UD22
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest