- sziku69: Fűzzük össze a szavakat :)
- Gurulunk, WAZE?!
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- Argos: Szeretem az ecetfát
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
-
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. -
urandom0
senior tag
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).
-
urandom0
senior tag
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.
-
-
urandom0
senior tag
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
-
urandom0
senior tag
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. -
-
Arra nagyon kíváncsi leszek, mi lesz a megoldás, ha egy hónapokkal korábban bevezetett változás (amióta már készült tucatnyi snapshot) vezet megoldhatatlan problémához, azt hogyan fogják kezelni...
-
urandom0
senior tag
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. -
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.
-
urandom0
senior tag
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. -
-
urandom0
senior tag
É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.
-
"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.
-
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. -
urandom0
senior tag
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.
-
É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. -
urandom0
senior tag
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.
-
"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 -
urandom0
senior tag
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.
-
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
-
#2
urandom0
senior tag
Hieronymus
#1
urandom0
senior tag
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. -
#1
Hieronymus
veterán
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.
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
Hirdetés
- iKing.Hu - Samsung S25 Ultra - Titanium Black - Használt, karcmentes
- Apple Ipad 10.generáció
- Új HP Pavilion x360 14-ek Érintős hajtogatós Laptop Tab 14" -35% i5-1335U 8/512 FHD IPS Iris Xe
- RTX 4080 SUPER,16GB. Ryzen 7 7800X3D, 32 RAM Fury RGB! Garancia!
- Asztali PC , i7 9700K , RX 5700 XT , 32GB DDR4 , 500GB NVME , 1TB HDD
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RTX 4060 Ti 8GB GAMER PC termékbeszámítással
- Tablet felvásárlás! Samsung Galaxy Tab S10+, Samsung Galaxy Tab S10 Ultra, Samsung Galaxy Tab S10 FE
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5070 GAMER PC termékbeszámítással
- Bomba ár! Lenovo X1 Yoga 1st - i7-6G I 8GB I 256SSD I 14" WQHD Sérült I W10 I CAM I Garancia!
- Telefon felvásárlás!! Xiaomi Redmi Note 13, Xiaomi Redmi Note 13 Pro, Xiaomi Redmi Note 13 Pro+
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest