- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Rap, Hip-hop 90'
- Luck Dragon: Asszociációs játék. :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Parci: Milyen mosógépet vegyek?
- btz: Internet fejlesztés országosan!
- NASsoljunk: ZyXEL NSA-310 és az FFP
Új hozzászólás Aktív témák
-
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. -
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. -
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.
-
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.
-
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.
-
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.
-
#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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
/troll 
Új hozzászólás Aktív témák
Hirdetés
- Milyen videókártyát?
- Router gondok
- Otthoni hálózat és internet megosztás
- Forza sorozat (Horizon/Motorsport)
- Megjelent a Poco F7, eurós ára is van már
- Kertészet, mezőgazdaság topik
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Milyen okostelefont vegyek?
- Hobby elektronika
- Autós topik
- További aktív témák...
- ROG Maximus Z790 Dark Hero
- Új MSI KATANA 17 Gamer Tervező Laptop 17,3" -35% i7-13620H 10Mag 16/1TB RTX 4060 8GB FHD 144Hz
- Apple Iphone 13 128gb csillagfény színű OLCSÓN . Csere/beszámítás
- OnePlus Pad 2 + OnePlus Pad 2 billentyűzet + Extrák
- AKCIÓ!!! GAMER PC: Új i5-14400F +RTX 4060/5060/4070/5070 +Új 16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ!
- Bomba ár! Dell Latitude E7250 - i7-5GEN I 8GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- BESZÁMÍTÁS! ASUS Z390 i5 9500 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA Thermaltake 500W
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RTX 3050 6GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude E6520 - i7-2760QM I 8GB I 256SSD I Nvidia I HDMI I 15,6" HD+ I W10 I Gari!
- BESZÁMÍTÁS! Asus B760M i7 12700KF 32GB DDR4 512GB SSD RX 6800 16GB Rampage SHIVA FSP 700W
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged