- Gyertek a 11. BRSZK-ra! Lesz DFI UV alatt, és mart szilícium tapi!
- XIAOMI Smart Air Purifier 4 Compact EU - légtisztító újabb okoseszköz a lakásban
- Clickbait szülinapi sorsolás II - még drágább a clickbaited
- Optikai szál nem kell félnetek jó lesz, avagy a damil alapú hálózat
- A PC-m több mint 1 évtizedes története - AMD FX OC, 64GB RAM, ipari SSD - 1.rész
- bullseye: Clickbait szülinapi sorsolás II - még drágább a clickbaited
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: MárkaLánc
- GoodSpeed: XIAOMI Smart Air Purifier 4 Compact EU - légtisztító újabb okoseszköz a lakásban
- MasterDeeJay: Low budget (50.000 forint) light gémer gép összerakása
Ú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).
Igen, ezt tudtam, a deltát viszont nem. Köszi
"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)."
Biztonsági szempontból sem jó, az immutable egyik előnye, hogy nem tudsz belenyúlni. Mondjuk nem valami szörnyűség, hogy bele lehet, csak úgy voltam vele, hogy ez egy pozitív hozadéka. -
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.
Ért, eddig nekem valamiért az volt meg, hogy az immutable csak egyben frissül
-
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
Igen, hétköznapi felhasználásban pont az immutable biztonságát tehetné tönkre
Találnak egy friss sebezhetőséget, valami brutál gáz hibát, és mindenki elkezdi lerángatni a több száz megás updatet vs. kellene egy csomagnyi binárist leszedni... -
Csak akkor miért immutable
/troll
Ugyanott van az ember, hogy egy jól összerakott rendszer kell"Pl. egy disztró által szállított binárist felülírni. "
Meg amikor kijön egy 0-day, és hamar kéne javítaniCsak akkor miért immutable
/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.Csak akkor miért immutable
/troll
Ugyanott van az ember, hogy egy jól összerakott rendszer kell"Pl. egy disztró által szállított binárist felülírni. "
Meg amikor kijön egy 0-day, és hamar kéne javítani -
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.Tudom, hogy a Distrobox inkább kényelmi eszköz, de úgy általában, az ilyenfajta megoldások szeparációra is jók, VM nélkül.
Jellemzően egy Unix-jellegű szerveradminisztráció amúgy sem GUI-s dolog -
Ja, én inkább arra gondoltam, hogy azért se megy terminálba...
Tényleg az van, hogy terminál már akkor kell, amikor valaki professzionálisabb user használja a gépet; viszont akkor sem érthető a megoldás, ami ebben a cuccban van.
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.
-
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.Ja, én inkább arra gondoltam, hogy azért se megy terminálba...
Tényleg az van, hogy terminál már akkor kell, amikor valaki professzionálisabb user használja a gépet; viszont akkor sem érthető a megoldás, ami ebben a cuccban van.
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 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.
"az a felhasználó, aki általában mindenre GUI-t használ, jellemzően csomagokat kezelni jár a terminálba. "
....megoldja Synapticból. Barátnőm Unix admin, lehetetlen nagy fizikai gépeket kezel brutál bonyolult infrastruktúrával, de Linuxon nem hajlandó parancssorozni -
"Igazából nem egészen értem, hogy miért kell új nevezéktant bevezetni már létező fogalmakra, de ám legyen..."
Ez egy a sok indokbol, miert is van baj ezekkel a rendszerekkel es azt hiszem, hiu abrand azt gondolni, hogy majd valaha ezek a kulonbozo immutable rendszerek egysegesek lesznek, mert nem lesznek.
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. Masodszor: terminalt inditva nem csak csomagmuveleteket vegzunk. Mivel az a benyomasom, hogy valamilyen modon a professzionalis eleted is a Linuxhoz kapcsolodik, ez a velemeny szamomra nagyon meglepo. Harmadszor: nagyon helyes, hogy a jelszovaltoztatas es a mount az immutable rendszeren tortenik, ha nem ott tortenne, a lenyeget veszitene el.
Az alfas velemenyeddel nem nehez egyeterteni, bar en azt hiszem, mindegyik ilyen rendszer gyerekcipoben jar meg es meg mindig nem latom a piaci rest, amire keszul. Ha a munkahelyemen meglatok egy akarmilyen app image containert (ertsd: flatpak, appimage, snap), akkor jon fole a kontroll, mert szerveren ezeknek nincs helye, legfeljebb ha szoftvergyarto garantalja a biztonsagossagat es lehetoseget ad a whitelistelesre - explicit lista azokrol, ami image formaban felkerulhet.
É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.
Persze, feladathoz az eszközt. Itt a home szerveren mehetne a Nextcloud meg esetleg a webszerver is konténerben, biztonságosabb lenne, csak úgy alakult, hogy amikor összeraktam, akkor nem volt erőforrás, így maradt a natív telepítés.
Amint szükség lesz itthon valamire konténerre, azonnal lesz is Szórakoztam már Dockerrel, csak tényleg nem volt mire használni. -
Érteni, rebootolni se nagyon rebootolnék ezért
Tartalék lapost tartok ilyesmire, ha fizikai gépen kell másik rendszer. (Néha megesik.) De az esetek 90%-ában elég egy virtuális.Apx meg attól még jó lehet, pont ez az egész opensource lényege, mindenki fejleszthet, ami éppen kell.
Néha gondolkodok konténeren, de igazából nekem nem kell semmire; inkább virtuális gép, mert az egy külön valami (van egy NAS+virtuális host gépem, amin éppen az fut KVM-en, ami kell, így egy fizikai gép térfogatában van vagy húsz másik gépem - Windows, OpenVMS, ReactOS, pár Linux mindenféle feladatokra). Ilyen, hogy van egy valami feature másik disztrón, amit konténerben használjak, nem szokott előfordulni. -
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.
Érteni, rebootolni se nagyon rebootolnék ezért
Tartalék lapost tartok ilyesmire, ha fizikai gépen kell másik rendszer. (Néha megesik.) De az esetek 90%-ában elég egy virtuális.Apx meg attól még jó lehet, pont ez az egész opensource lényege, mindenki fejleszthet, ami éppen kell.
Néha gondolkodok konténeren, de igazából nekem nem kell semmire; inkább virtuális gép, mert az egy külön valami (van egy NAS+virtuális host gépem, amin éppen az fut KVM-en, ami kell, így egy fizikai gép térfogatában van vagy húsz másik gépem - Windows, OpenVMS, ReactOS, pár Linux mindenféle feladatokra). Ilyen, hogy van egy valami feature másik disztrón, amit konténerben használjak, nem szokott előfordulni. -
"Azért nem akarom vm-ben tesztelni őket, mert úgy nem hozzák ugyanazt a teljesítményt, mint bare metálon."
A működést lehet azon, és ha megéri feltenni fizikaira, akkor hajrá. A franc cserélgetné az elsődleges gépében a meghajót
De különben egy Linux virtuálgépen se különösebben lassabb, mint fizikain. Tapasztalat " Most Aeon alatt, ha egy Fedora konténerbe telepítek egy Geany-t, és exportálom, az így jelenik meg a menüben:"
Ja, de az Aeon -
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.
"Azért nem akarom vm-ben tesztelni őket, mert úgy nem hozzák ugyanazt a teljesítményt, mint bare metálon."
A működést lehet azon, és ha megéri feltenni fizikaira, akkor hajrá. A franc cserélgetné az elsődleges gépében a meghajót
De különben egy Linux virtuálgépen se különösebben lassabb, mint fizikain. Tapasztalat " Most Aeon alatt, ha egy Fedora konténerbe telepítek egy Geany-t, és exportálom, az így jelenik meg a menüben:"
Ja, de az Aeon -
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.
Na, most feldobtam három Geany-t, három különböző konténerbe
Balról jobbra: Fedora, OpenSuse, Debian.
-
Neked is, meg a fejlesztőknek is, mert azért tettek bele melót ahogy látom.
Ezeket lehet érdemes lenne egy virtuális gépen próbálgatni
Amúgy nekem ez túlságosan el van bonyolítva. Az immutable-t értem, miért jó (csak nem igénylem), a konténeres elválasztás is jó dolog, de a megvalósítás, ahogy leírod, hát, az elég érdekes. 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.
Az ABRoot filerendszer nem olyan meredek szerintem, két volume van mindenre, és azokat használja. Hogy a harmadik mit keres ott, az jó kérdés
A módszer amúgy hasonló az AIX alatt szokásos altdiskcopy-hoz
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.
-
hcl
titán
Neked is, meg a fejlesztőknek is, mert azért tettek bele melót ahogy látom.Ezeket lehet érdemes lenne egy virtuális gépen próbálgatni
Amúgy nekem ez túlságosan el van bonyolítva. Az immutable-t értem, miért jó (csak nem igénylem), a konténeres elválasztás is jó dolog, de a megvalósítás, ahogy leírod, hát, az elég érdekes. 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.
Az ABRoot filerendszer nem olyan meredek szerintem, két volume van mindenre, és azokat használja. Hogy a harmadik mit keres ott, az jó kérdés
A módszer amúgy hasonló az AIX alatt szokásos altdiskcopy-hoz
-
urandom0
őstag
Ehhez hasonló szoftver frissítést alkalmaz a Google a telefonjai esetében.
Gyakorlatilag egy aktuális másolatán végzi el a módosításokat, majd a frissített rendszerről indul.
Nagyobb frissítés esetében az előkészítés extra hosszú időt vehet igénybe. Bár az a telefon használhatóságát nem befolyásolja, háttérben fut. -
Hieronymus
veterán
Találnak egy friss sebezhetőséget, valami brutál gáz hibát, és mindenki elkezdi lerángatni a több száz megás updatet vs. kellene egy csomagnyi binárist leszedni... ![;]](http://cdn.rios.hu/dl/s/v1.gif)
/troll 
Új hozzászólás Aktív témák
- Visszatérés az aranykorba: Heroes of Might and Magic: Olden Era Early Access
- Külföldi prepaid SIM-ek itthon
- Mesterséges intelligencia topik
- E-book olvasók
- Hitelkártyák használata, hitelkártya visszatérítés
- Építő/felújító topik
- VGA kibeszélő offtopik
- Samsung Galaxy S25 - végre van kicsi!
- 6K-s és 5K-s gaming monitorok a Samsung védjegyével
- Okos otthon - Home Assistant, openHAB és más nyílt rendszerek
- További aktív témák...
- Mac Pro 6,1 2013 Late
- GAMER PC! i7-14700 / RTX 5080 / 32GB DDR5 / 1TB NVMe / 1000w Gold / BeszámítOK !
- ASUS ROG Strix SCAR 16 / Ultra 9 275HX / RTX5090 / 32GB / 2TB NVMe! BeszámítOK
- 27% - Corsair RMx Series RM1000x 1000W 80 PLUS Gold (CP-9020271-EU) Tápegység!
- White AM4 félkonfig! ASUS ROG B550-A + Ryzen 9 5950X BOX + 32GB DDR4 3600Mhz CL17
- Apple iPhone 11 Pro / 64GB / Kártyafüggetlen / 12Hó garancia / Akku:100%
- GYÖNYÖRŰ iPhone 15 Plus 256GB Black -2 ÉV GARANCIA -Kártyafüggetlen, MS5506
- Dell Latitude 5300 13,3" FHD IPS touch, i5 - i7 8665U, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
- OnePlus Open 512GB Voyager Black Karcmentes állapot 16GB RAM 6 hónap garancia
- BESZÁMÍTÁS! Asus Crosshair VIII Extreme Wifi alaplap garanciával hibátlan működéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: aiMotive Kft.
Város: Budapest