- AMD K6-III, és minden ami RETRO - Oldschool tuning
- OLED monitor topik
- Fujifilm X
- Azonnali notebookos kérdések órája
- Milyen RAM-ot vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- IGP nélküli processzorokkal készül az Intel és az AMD
- Nem indul és mi a baja a gépemnek topik
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Monitor hiba topik
Új hozzászólás Aktív témák
-
urandom0
senior tag
a flatpak csomagot nem kell elkészíteni és letesztelni?
De, viszont elég egyetlen egy formátumot készíteni belőle és elég egyetlen egy disztrón tesztelni. Ha azon jól működik, a többin is jól fog.
a flatpak nem helyettesíti a csomagkészítést, hanem plusz munkaként jelenik meg.
Kivéve annak, aki eddig minden disztróra külön csomagot csinált és mindegyiken külön letesztelte, és mostantól úgy dönt, hogy csak flatpakban terjeszt.
-
urandom0
senior tag
És az szerinted nem vonja el az erőforrásokat, hogy ha egy fejlesztő közzé akar tenni egy programot úgy, hogy minél több felhasználót elérjem, akkor legalább 2-3 csomagot kell belőle készítenie? És nem is a csomagkészítéssel van a probléma, mert azt még elég jól lehet automatizálni, hanem hogy mindegyik disztrón le kell tesztelni?
Nem egyszerűbb egy darab flatpak csomagot készíteni, és ezzel kb. le van fedve minden disztró? -
bambano
titán
Amit próbáltam leírni, hogy a flatpak fejlesztésére elvont erőforrások hiányoznak az alap fejlesztésekből. Plusz a linux elwindowsosítására felhasznált erőforrások is hiányoznak. Nem az a probléma, hogy neked lesz flatpaked, hanem az, hogy ettől nekem rosszabb lesz a disztróm. Meg attól is, ha olyanok kedvéért marhaságokat erőltetnek a linuxokba, akik egyébként nyugodtan felrakhatnának maguknak egy windowst.
"De szerintem a Linux szélesebb körű elterjedéséhez": ez önmagában probléma. Ne terjedjen tovább a linux, ha az az ára, hogy windowsos marhaságokat kell beleerőltetni a disztrókba. Ne kelljen már nekem freebsd-re átszoknom, hogy másoknak jobb legyen a linux kernelre alapozott windowsuk.
-
DarkByte
addikt
Nem tudom hogyan számolod ezt az 5x annyi variást, de Win10/11 van mint aktívan karbantartott végfelhasználói OS. De legyen, tekintsük külön változatnak az éves service pack-okat is.
Linux-on ha eltekintek az egzotikus alfajoktól, van durván 10 mainstream Linux disztró, és a többségnél van legalább 2-3 de valahol akár 5-6 választható desktop environment is (endeavourosOS setup-ja felajánl 9-et). Ezeket összeszorozva elég sok variáció kijön.
A leírtakból egyik sem lesz teljesen ekvivalens a Flatpak-el. Vagy disztró specifikus lesz a csomag és akkor mindegyikre újra kell csomagolni (illetve függsz a distro repository-kban elérhető dependency-ktől); vagy amit kibontasz neked kell frissítgetni kézzel (ha a .tar.gz alatt a becsomagolt executable-t és lib-jeit értjük).
A Flatpak-re szerintem tényleg a Docker a legjobb analógia, konténerizált végfelhasználói alkalmazások, amelyek csak a kernel-ben közösek.
Senki sem mondta ennek nincs hátránya a natívhoz képest (több lemezhely, nagyobb erőforrásigény, duplázódások; kb. minden ami a Docker-re is igaz, ha bőlére van eresztve). De előnye is van hogy hülye biztosabb, alapból sandbox-olt. Ez kb. szerintem Flatpak csomagonként változik melyiknek mennyire jó a jóság faktora.
Egyénileg kell mérlegelni neked van-e rá szükséged. Ha nem, hát nem.
Nem csak egy nézőpont létezik. De szerintem a Linux szélesebb körű elterjedéséhez kellenek az ilyen egységesítési törekvések.
Majd az idő megmondja tényleg így van-e. -
bambano
titán
Hát ja, hiszen linuxra milyen bonyolult fejleszteni, bezzeg windowsra, amiből kb. 5x annyi variáns van, triviális.
Másrészt meg az üzleti fejlesztőknek nem kell mindenre fejleszteniük. Elég 2-3 üzleti disztró aktuális verziójára fejleszteni, és kész. Valójában nincs egetverő különbség az alapvető dolgokban."A Flatpak-el össze lehet zárni az app-ot a függőségeivel": szemben például a tar.gz-vel, amiben szintén össze lehet zárni a programot a függőségeivel. Csak nem kell hozzá a flatpaket is ismerni. Meg deb-ben is össze lehet zárni, csak ezt büdös megtanulni.
-
DarkByte
addikt
A Flatpak előnye az egyszerűbb bináris terjesztés.
Ahogy Torvalds is mondta, a nagy cégek szempontjából pont az egyik nagy probléma a Linux-ra fejlesztéssel, hogy rengeteg környezet lehetséges, és ezek összes kombinációjára lehetetlenség érdemi QA-t és support-ot adni értelmes költség mellett. (azt hiszem a DebConf14-es talk-jában magyarázta, hogy egy búvárkomputerhez való szoftvert fejleszt a cége, és konkrétan egy ponton inkább felhagytak a Linux támogatással, mert egyszerűen nem térül meg.. ouch)
A Flatpak-el össze lehet zárni az app-ot a függőségeivel amivel garantáltan tesztelve lett és menni fog. Kvázi Docker az app-okra. Egy lóugrással átugorja a disztrók különbözőségeit, azok csináljanak amit akarnak.
-
urandom0
senior tag
Nem cseszték el a Fedora csomagolók sem
És a Debiant pláne nem akarja elcseszni senki sem, nem is nagyon lehetne, mivel az teljesen közösségi disztró. Nem hiszem, hogy lesz Debianból immutable változat (mert már most is van, EndlessOS-nek hívják
), legfeljebb valami oldalhajtás. -
urandom0
senior tag
Ha valaki szeretne érveket/ellenérveket olvasni a flatpakról, az Redditen sok ilyet talál (nyilván angolul): https://www.reddit.com/r/linux/comments/1h7ze64/why_flatpak_is_a_blessing_for_linux_beginners_and/
Ez friss, most írták ki 3 órával ezelőtt (nem én voltam, istenbizony!). SAJNOS a Redditnek van egy olyan hülyesége, hogy elrejti a mínuszos lepontozott, pedig ezek a vélemények is érdekesek (többnyire). Én az összes ilyen leminuszoltat felpontoztam
-
urandom0
senior tag
Ez jó kérdés.
Én lassan egy hónapja Aeont használok az asztali gépemen (a közeljövőben arról is írok majd, egyébként a cikkben lévő screenshotok mind azon készültek), és Fedora Silverblue-t a laptopon.
Az immutabilitás még a Flatpaknál is egy sokkal nehezebben "eladható" dolog, mert baromi nehéz átadni, hogy miért jó, miközben vannak azért erős hátrányai is. Én sem tudom biztosra mondani, hogy van értelme desktopra, de azt sem, hogy nincs.A magam részéről két előnyét látom, egyrészt nagyon gyorsan lehet rollbackelni a rendszert korábbi verzióra (ezt amúgy megteszik maguktól is), de ezt meg lehet tenni pl. btrfs-en snapperrel is. Másrészt nem keverednek a rendszercsomagok a felhasználói programokkal, de egyrészt ezt megint csak meg tudod tenni más disztrón is (flatpak+distrobox), márészt egyes csomagokat így is az alaprendszerbe kell telepíteni.
-
urandom0
senior tag
Igen.
Írtam #23-ban, hogy a Fedora/Suse és Gnome voanlon nagyon afelé haladunk, hogy minden (vagy majdnem minden) flatpak lesz idővel. Az Ubuntura ugyanez igaz, csak ott snap lesz.
Az Ubuntu Core-ban nincs már apt, csak snap (igaz, ez nem is asztali rendszer, hanem IoT). A Fedora Silverblue-ban/Kinoite-ban/Atomicban nincs dnf. A SUSE-féle Aeonban/Kalpában van zypper, de csomagtelepítéshez/törléshez/frissítéshez nem tudod használni.
Ezek a corporate rendszerek nagyon ebbe az irányba mennek. És esélyes, hogy az immutable lesz a fő irány. -
urandom0
senior tag
Hát ne is haragudj, de ilyet leírni, hogy megnézed a disztrowacsi első 20 helyezettjét akkor 2 db csomagkezelési rendszert találsz: deb és rpm. Slussz.
Azért ez kicsit erős, mikor az első 20 helyezettben ott van az MX (.deb), ott az EndeavourOS (.pkg.tar), ott a Fedora (.rpm), NixOS (.nixpkgs)...
És ugye ezek csak a csomag formátumok, de van egy csomó csomag, ami megy Ubuntun de nem Debianon, megy Fedorán de nem megy Suse-n, ....
-
urandom0
senior tag
Erre van a --prefix
Akkor most megint ismétlem önmagam: meg assemblyben is meg lehet írni mindent, mégsem abban fogok nekiállni weboldalt csinálni.
Hagyjuk már ezt a csilliózást... megnézed a disztrowacsi első 20 helyezettjét akkor 2 db csomagkezelési rendszert találsz: deb és rpm. Slussz.
ROTFL?
Én egy percig nem gondolnám itt senkiről, hogy nem ért a Linuxhoz, de akit ilyet leír, arról sajnos azt kell gondolnom, hogy nem ért a Linuxhoz. -
Vladi
nagyúr
A kodekre vannak a 3rd, pontosabban 2,5rd party tározók, mint az epel és az rpmfusion. Ide se kell flatpakolni.
#42 Rowon
Érdekes centos 7-re még sikerült a fedora 80%-át például epelben becsomagolni, alma 9-en ez már nem egy.
Arról nem is beszélve, hogy a libek felét kihagyják tehát forrásból is megy lőve.urandom0:
Erre van a --prefix
+49:Hagyjuk már ezt a csilliózást... megnézed a disztrowacsi első 20 helyezettjét akkor 2 db csomagkezelési rendszert találsz: deb és rpm. Slussz.
Sőt! 3-4 alap tárolót találsz összvissz, mert például a debian tárolóit használja az ubuntu, a mint, az antix az mx meg még kitudja ki más. Tehát ugyan abból a forrásból vannak.
Fedora tárolóira épül az összes ellinux, redhat, rocky, alma, stb.De mivel ez a 2-3 az már sok, most csináltak még 3-at. Engem nem érdekel, de az azért hajmeresztő, hogy a disztribútor lustaságból kirúgja a csomagok garmadáját. Oldja meg valaki más.
Ráadásul úgy rúgja ki pl. el linuxból, hogy végtelen számú fedora srpmből válogathatja össze. Nem mellesleg az el linux eleve úgy készül, hogy fedora srpmből válogat...
-
urandom0
senior tag
Mert a böngésző egy moving target, és amikor komolyabb webappot fejlesztesz, akkor ott van előtted egy krva nagy kompatibilitási mátrix, ahol azt kell lesegetned, hogy adott böngésző adott verziója éppen mivel kompatibilis.
Ha odacsomagolod a böngészőt az app mellé, akkor meg nincs ilyen probléma.
-
urandom0
senior tag
de még mindig kérdés: aki veszi a fáradtságot és becsomagolja a discordot flatpakbe, az miért nem csomagolja be deb-be és kész? vagy deb-be és rpm-be, és jónapot?
Mert deb-ből is van Ubuntu 20, Ubuntu 22, Ubuntu 24, Debian 11, Debian 12, MX, Mint 20, Mint 21, Mint 22, és így tovább.
Lefordíthatod úgy is a programot, hogy az összes forgalomban lévő Ubuntu alapú rendszeren elfusson 20-tól a 24-ig, de ekkor le kell mondanod az új szolgáltatásokról. Talán még Minten, sőt Debianon és MX-en is elmegy.
De akkor még ott vannak az Archosok (Arch, EndeavourOS, Manjaro, CachyOS, Garuda stb.), ott vannak a Fedorások/RHEL-esek (Fedora, Nobara, Alma, Rocky, stb.), és ott vannak a Suse-sok (OpenSuse TW és Leap), meg a többi sok kis disztró. -
Az sem világos, miért kell olyanokat becsomagolni bármibe, ami webapp? Discord, Teams, Zoom, Slack stb. mind webapp, böngészőből használható. Csomagolva kapsz egy electronjs alkalmazást, ami pont ugyanazt a felületet jeleníti meg, amit a böngészőben is látna a user.
-
urandom0
senior tag
és? az összes modern deb frontend képes letölteni és felrakni a függőségeket is. és így egy csomag nem x giga, hanem pár mega.
Melyik az a deb frotend, amelyik elérhető legalább ennyi disztróra? Melyik az, amelyik sandboxolja is az alkalmazásokat?
mert közben minden fejlődött. a libc6 is. tehát a flatpak is megakadhat, nem lehetsz biztos benne.
A libc, libstdc és ilyen alap libek benne vannak a Freedesktop runtime-ba.
Amit fent belinkeltem Flathubos oldalt, ott van egy rakat disztró, azok közül mindegyiken mennek a flatpak programok. -
bambano
titán
"Meg a deb függ kb. mindentől.": és? az összes modern deb frontend képes letölteni és felrakni a függőségeket is. és így egy csomag nem x giga, hanem pár mega.
"De még egy 20.04-es Ubuntura is csak problémásan tudok feltelepíteni egy olyan deb-et, ami 24.04-hez készült.": mert közben minden fejlődött. a libc6 is. tehát a flatpak is megakadhat, nem lehetsz biztos benne.
de még mindig kérdés: aki veszi a fáradtságot és becsomagolja a discordot flatpakbe, az miért nem csomagolja be deb-be és kész? vagy deb-be és rpm-be, és jónapot?
-
urandom0
senior tag
és ahhoz, hogy legyen csomagolt discord meg teams, meg a többi, és fel tudja tenni és frissüljön, ahhoz minek flatpak?
ezen funkciók közül a deb mit nem tud?Mondjuk a deb-et nem tudom feltelepíteni egy Slackwarre. Vagy OpenSuse-ra. Vagy Arch-ra. De még egy 20.04-es Ubuntura is csak problémásan tudok feltelepíteni egy olyan deb-et, ami 24.04-hez készült.
Meg a deb függ kb. mindentől. A flatpak meg egy dologtól függ, a flatpak csomagtól, ami minden disztrón ott van. -
urandom0
senior tag
nem, a debian alaprendszere koncepcionálisan jó.
mindent meg lehet vele csinálni.
csak érteni kellene hozzá.Persze, meg assemblyben is meg lehet írni mindent, mégsem abban fogok nekiállni weboldalt csinálni.
egyébként miért baj, hogy van egy jó csomagkezelő rendszer? ha mellé van még másik 3, ami ócska, de nem kötelező használni, akkor mit számít?
Csak kérdezem, mitől lenne ócskább mondjuk az rpm, mint a deb?
-
bambano
titán
"Az lenne az utolsó, amit csinálnék egy Linux rendszeren, hogy egy weboldalról töltsem le a telepítőt": amíg biztos vagy benne, hogy nem térítették el a dns rezolválásodat (mondjuk DoH-val, ugye mozilla???), addig nyugodtan felrakhatod a mozillától a böngészőt. ki más tudná jobban lefordítani, mint a mozilla?
meg a windows userek is így rakják fel, nem történik tőle semmi. -
bambano
titán
nem, a debian alaprendszere koncepcionálisan jó.
mindent meg lehet vele csinálni.
csak érteni kellene hozzá.egyébként miért baj, hogy van egy jó csomagkezelő rendszer? ha mellé van még másik 3, ami ócska, de nem kötelező használni, akkor mit számít?
az szerintem is pazarlás, hogy amikor már volt egy jól működő, korszerű deb, akkor a retekhatnek mi a fenéért volt fontos kitalálni az rpm-et, ami akkor még nagyságrendekkel gagyibb csomagkezelő volt.
"Az informatika már csak ilyen, mindig van mit tanulni, és mindig vannak újdonságok.": majd ha megfizetik. egy csomagoló se erőszakolja rám a munkaidőm elpazarlását.
"ami nem fog egy rendszerfrissítés után bootolhatatlanná válni":
vi hires_utolso_mondatok.txt -
urandom0
senior tag
tehát usernek egyszerűbb felrakni egy flatpaket és utána abban letölteni egy böngészőt, mint hogy elmenjen a mozilla főoldalára és simán letöltse, kicsomagolja és kész?
Igen. Mert ha a usernek nem csak böngésző kell, hanem kell mondjuk egy Discord, egy Teams, egy Zoom, egy Skype, egy média lejátszó, egy akármi... és ezeket mindet le tudja tölteni flatpakból. És még automatikusn frissül is mindegyik.
-
urandom0
senior tag
a debiani csilozófiába mondjuk nem biztos, hogy jó belenyúlni a frissesség kergetésével.
Szerintem meg nagyon jó dolog az, hogy van egy nagyon stabil Debianod, ami nem fog egy rendszerfrissítés után bootolhatatlanná válni, de ugyanakkor használsz friss verziójú programokat is.
-
urandom0
senior tag
1. Az alaprendszer koncepcionálisan rossz. Az, hogy van kismillió disztró, az nem baj, de az, hogy a kismillió disztró mellé van kismillió egyezer csomagkezelő és csomagformátum (és nagyjából mindegyik ugyanazt tudja), na, annak nincs értelme. EZ az, ami ordenáré nagy pazarlás. Az egyik deb-be csomagol, a másik rpm-be, a harmadik PKGBUILD scritet ír, a negyedik a negyedik formátumba csomagol... teljesen elaprózza a fejlesztői erőforrásokat.
2. Az informatika már csak ilyen, mindig van mit tanulni, és mindig vannak újdonságok.
-
-
urandom0
senior tag
ezek közül melyik problémát nem lehetne megoldani egy rendesen lefordított, /usr/local-ba települő programverzióval?
Akkor mondd meg neki, hogy odatelepüljön, már ha megtudod. Mert ha csak nem magad fordítod, vagy nem írod át a csomagfájlt, akkor nem fogod tudni megoldani szerintem. Már ha egyáltalán van csomagfájl a disztróhoz, amit használsz...
-
bambano
titán
tehát usernek egyszerűbb felrakni egy flatpaket és utána abban letölteni egy böngészőt, mint hogy elmenjen a mozilla főoldalára és simán letöltse, kicsomagolja és kész?
a program karbantartójának meg egyszerűbb megcsinálni a szokásos deb és rpm mellé a targz után, hogy még van flatpakje, snapje meg a fene tudja még mije? -
bambano
titán
"Kezdve azzal, hogy ha gcc-ből is eleve más verziót kér valami, meg vagy lőve, hiába szánnád rá a mókolási időt.": igen, azok álltak neki flatpacket fejleszteni, akik nem tudták, hogy egyáltalán nem vagy meglőve másik verzióval. Debianon legalábbis biztos nem, és, szerintem, bármelyik másik disztrón is meg tudnám oldani nem nagy mókolással.
A biztonsági frissítésekkel sincs baj, van security-updates oszt jónapot. A windows ebben biztosan nem jobb. mondjuk másban se...
-
-
totron
addikt
Nem a frissel van gond a flatpaken kívüli működés esetén, hanem az ellenkezőjével. A backports meg csak egykézen megszámolható, fix lehetőségpakkot tartalmaz, amiben nincs olyan ami kellene. Biztonsági foltozás esetén számít a gyorsaság és egyértelmű az irány, egyebekben előremutatóbb egy temperált, lomhább módot követni, van elég alfa, meg béta kiadás a világban.
Alapvetően nem lehet nagy ákombákomokat elkövetni linux alatt verziószámilag, kevésbé férnek meg korszakok egymás mellett. Kezdve azzal, hogy ha gcc-ből is eleve más verziót kér valami, meg vagy lőve, hiába szánnád rá a mókolási időt. Ebben jobb a Windows. -
totron
addikt
Ha meg nem lenne egyénieskedés, az volna a baj, mivé lenne a szabadság, a választható alternatíva. Összetartozó és széthúzó, kompatibilis és inkompatibilis mozog együtt, tart dinamikában/fejlődésben és tesz ki egy egészet. Nehéz elválasztani egyébként is, hogy honnantól vagy miért indokolt egy saját gyökerű feleslegbe belekezdeni. Némelyiknek még haszna is akad, a flat egy ilyen.
Van, hogy jogos a dolog: a főágba írási joggal nehéz bekerülni, ötletek vannak a világban, csak épp rendre lepattannak és pár ember irányítja a fősodrot - ami jó is, meg nem is. Vagyis a vázolt problémára nincs megoldás#35urandom0, a debiani csilozófiába mondjuk nem biztos, hogy jó belenyúlni a frissesség kergetésével. Az viszont jó, hogy régebbi verziók futtatása is képbe kerülhet Debiantól függetlenül.
-
ahelyett, hogy csinálnának egy friss kodekpakkot és azt terjesztenék?
Ezt Te látod jobban, én egy igencsak friss Linux felhasználó vagyok. Nekem a legelső Linux a Focal Fossa volt (Ubuntu 22.04 LTS). Azt is a Covidnak köszönhetem, különben sose kezdek el foglalkozni vele.
Elérhető egyébként az Enterprise rendszerekre is a kodek csomag, de ahhoz külső repókat kell hozzáadni a rendszerhez. Én ezeket nem szeretem, mert tartok attól, hogy ilyen-olyan ütközéseket fognak csinálni a rendszeremben alapból jelen lévő csomagokkal és az OpenSUSE-nál már volt is ebből gondom, amikor a Packman ütközött a disztró saját csomagjaival. Aztán csak egy sz*ros kodekcsomagot akartam telepíteni...
-
bambano
titán
Egyébként a következő az alapbajom:
1. ha azt a rengeteg erőfeszítést, amit ilyen hülyeségek kifejlesztésére elpazaroltak, az alaprendszer hibajavításába ölték volna, az alaprendszer is jó lenne.
2. amikor ilyen plusz hülyeségek megtanulására kényszerítik a felhasználókat, rendszergazdákat, az is ordenáré nagy pazarlás.Mondjuk rögtön elkezdhettük volna 30 évvel ezelőtt, hogy mi a fenének rpm, mikor már volt egy rendes csomagkezelő. Csak hát a redhat mindig is egyénieskedett...
-
bambano
titán
tehát ha nincs rendesen fent friss kodek, akkor ki kell találni egy új csomagolási rendszert és abban kell terjeszteni a kodekeket, ahelyett, hogy csinálnának egy friss kodekpakkot és azt terjesztenék?
ez olyan, mintha nem tudnék lejátszani egy filmet, és az lenne a javaslat, hogy rakjak fel kvm-et, libkvm-et, abba virtualizáljak egy windowst, abba rakjam fel a phvm drivereket, meg egy médialejátszót és azzal nézzek filmet... mindezt persze cloudba, mert ma már cloud nélkül nem ember a júzer.
egyébként nekem az mplayer mindent vitt eddig. csak a vlc-vel fordult elő, hogy nem látott mindent, de az nálam tárgytalan.
-
a flatpak rendesen megold és az alap oprendszer nem tudja?
Szerintem vagy ide, vagy máshová írtam nem olyan régen. Az Enterprise Linuxokra épülő rendszerek, pl. OpenSUSE, Fedora, stb. nem szállítják natívan a kodek csomagokat, így az ilyen gépen nem tudom nézni a filmjeimet, de még böngészőn sem indul el sok videó. A flatpakekben benne van előre csomagolva a kodek és sokszor újabb verziót is adnak mellé, mint amit mondjuk egy LTS kiadású rendszer kínál. -
urandom0
senior tag
Valaki tud olyan problémát mondani, amit a flatpak rendesen megold és az alap oprendszer nem tudja?
Én 3 disztrót+1 RPi-t használok. Nálam pl. megoldja azt, hogy ha az egyik gépen Debian van fent, a másikon Fedora, a harmadikon Tumbleweed, akkor mindhárom gépen ugyanazt a verziót tudom használni a flatpakos programokból.
Megoldja azt, hogy amikor leülök a gyerekkel játszani, ő a Windows 11-es gépével én meg a Linuxossal, ugyanazt a verziót tudjuk használni Widelandsből, Minetestből, ... mert a flatpakos verzió friss, függetlenül attól, hogy nekem mondjuk Debianom van.
Megoldja azt, hogy amikor valaki távsegítséget kér tőlem, csatlakozni akarok a gépéhez, és azt mondom neki, hogy töltsd le a Rustdesket, akkor az ő verziója kompatibilis lesz az én verziómmal.
Megoldja azt, hogy ha valakinek, akinek más disztrója van, mint nekem, és azt mondom neki, hogy töltse le XYZ programot, akkor ő le tudja tölteni, ha van flatpak verzió az adott programból. Teljesen mindegy, milyen disztrója van.
Megoldja azt, hogy BIZTOS, hogy nem fogom tönkretenni a rendszerem azzal, ha valamilyen flatpak programot eltávolítok. Mert azért futottam én már bele olyanba, hogy le akartam törölni valamelyik gyári Gnome alkalmazást, aztán vitte volna az egész Gnome Shell-t. Meg láttunk már olyat, hogy valaki el akarta távolítani a Klippert, és vitte volna magával az egész KDE-t.
Teljes nyugalommal telepítek és törlök flatpak programokat, mert tudom, hogy annak rossz vége nem lehet. -
urandom0
senior tag
Nem az a lenyeg, hogy visszaellenorizheto-e, hanem hogy megteszi-e valaki, mielott a userhez eljut a file es nem, nem teszi meg senki.
Hogy érted, hogy nem teszi meg? Bárki megteheti, akinek gyanúja merül fel. Ha a Githubos upstreamben sebezhetőség vagy rosszindulatú kód van, a flatpak verzióban is benne is; ha nincs, akkor nem.
A linkeden ezt írják: "If an app has the static filesystem permission for
home, it can place this override file to give itself any possible permission."Én tudtam, hogy erre gondolsz, amikor azt írtad, hogy "egyszeru dotfile-lal torheto". Ezért írtam le #11-ben, hogy "Mert amúgy a ~/.local/share/flatpak/ könyvtár a flatpak alkalmazások számára NEM elérhető, amíg explicit módon nem adsz rá engedélyeket."
Tehát ez nem úgy működik, hogy a kedves posztoló elképzeli, hogy amelyiknek appnak filesystem=home jogosultsága van, az felül tudja írni a többi app jogosultságát. Nem így van!
A Flatseal csak azért tudja ezt megtenni, mert xdg-data/flatpak/overrides:create; jogosultsága van.Meg egy szo a Flatsealrol, mert korabban nem olvastam azt az oldalt. Ez a masik olyan alkalmazas, ami ebben az egesz okoszisztemaban iszonyu veszelyes - ha valami, hat ez a root jelszo a sima usernek, mert nem csak a jogosultsagok szukebbre vonasara alkalmas, hanem azok kitejesztesere is.
Igen, a Flatseal azért működik így, mert ez az elvárt viselkedés. Ez ilyen by design.
De még mindig távoll áll a root jelszótól, mert (és megint ismétlem magam): "Másrészt ezzel a módszerrel csak olyan jogosultságok adhatók az appoknak, amivel egy csomagkezelőből letöltött program vagy egy appimage alapból rendelkezik. Tehát még mindig van egy plusz védelmi réteg a flatpak appoknál, amivel a csomagkezelős programok, a random weboldalakról letöltött csomagok vagy binárisok, illetve az appimage-ek nem rendelkeznek."És újfent ismétlem magam, ha valaminek minden jogot megadsz arra, hogy tönkretegye a rendszered, akkor nincs mit csodálkozni azon, ha tönkre is teszi.
-
"A legtöbb flatpak csomag közvetlenül a Github repóból készül a Flathub infráján, teljesen nyitott manifest fájllal. Az ilyenek visszaellenőrizhetők."
Nem az a lenyeg, hogy visszaellenorizheto-e, hanem hogy megteszi-e valaki, mielott a userhez eljut a file es nem, nem teszi meg senki.
"Ez kb. ugyanaz a szituáció, mint ha fognál valakit, leültetnéd a géped elé, adnál neki root jogokat és kijelentenéd, hogy a Linux nem biztonságos, mert bárki feltörheti.
Ha valaki random dolgokat tölt le a netről, és vakon ad nekik futtatási jogosultságokat, és le is futtatja őket, akkor ne csodálkozzon, ha lyukas a rendszere, mint az ementáli."Ezzel most nem mondasz ellen, hanem pont egyetertesz velem a sandbox semmilyenseget illetoen.
"Igen, azt a pillanatot várom én is, amikor az átlagos Linux felhasználó SELinux policyket fog írkálni."
Javasolnam, hogy ne menjunk egy bizonyos szint ala.
/.local es tarsai: iden aprilisi a bejegyzes a Fedora project foruman.
Meg egy szo a Flatsealrol, mert korabban nem olvastam azt az oldalt. Ez a masik olyan alkalmazas, ami ebben az egesz okoszisztemaban iszonyu veszelyes - ha valami, hat ez a root jelszo a sima usernek, mert nem csak a jogosultsagok szukebbre vonasara alkalmas, hanem azok kitejesztesere is.
Mindezek melle koszonom, hogy jobban kitertel a security-re is, meg ha az by design nem is jo.
-
sonar
addikt
Vladi,
Én sem örülök, hogy új csomag kezelőt kell használni, de pont most futottam bele egy olyan problémába, hogy kicad és freecad egyszerre nem lehet fent.
Erre nekem speciel jó megoldás volt, hogy a freecad-et flatpak-kel raktam fel.urandom0
Még nem mentem utána, de nem láttam olyan parancsot ami megmondaná, hogy a repo-ban milyen verziós az adott program. Magyarán az apt show parancs megfelelője mi lenne? -
-
urandom0
senior tag
Igen, Fedorán Flathubos VLC-t (vagy Celluloidot) haszálni, az jó ötlet.
De amúgy a Fedora ugyanúgy nem tehet közzé kodekkel ellátott flatpakot, mint ahogy nem teheti bele az alaprendszerbe sem a kodekeket. Ezért van a Fedora Flatpak repó, abban csak FOSS szoftverek vannak.
A laptopomon olyan Firefox van, amit onnan telepítettem, kb. minden második-harmadik videót nem tudom lejátszani...
-
urandom0
senior tag
Az nem a Flatpak hibája, hogy XY cég egyik napról a másikra eldobja a natív csomagot. Én is jártam úgy, hogy a csomag egyik kiadásban még benne volt, következőben már nem. Ez van.
Ez jön a többi disztróban is.
Egyébként igen, a Fedora/Suse és Gnome voanlon nagyon afelé haladunk, hogy minden (vagy majdnem minden) flatpak lesz idővel.
pár hónap alatt másodjára kapom meg, hogy vegyek hardvert
Hát, szerintem ez sem a Flatpak hibája.
-
Vladi
nagyúr
A flathub. Az a 3. fél. Eddig a disztribútor csomgaolt, most szemrebbenés nélkül mondja, hogy használj ilyet, a másik szutyok egyikét. Ezt végignéztem enterprise linuxon. Egyik kiadásban még sikerült mindent becsomagolni a következőben már a flathubra mutogattak. Köszi. Persze fedorában ott a csomag, nem lenne nagy meló átportolni. Ez jön a többi disztróban is.
2. nem. Adott disztróban. Tehát a dnf/rpm mellé kapok még egyet.
3. nem növekedett túlzottan... köszi. pár hónap alatt másodjára kapom meg, hogy vegyek hardvert. Bocs, de ez a hozzáállás a microsoft sajátja, nagyjából ilyenek miatt jöttem el abból a világból. Ez most jön utánunk.
-
urandom0
senior tag
1. a csomagkészítést ezzel ksizerverzték 3rd partynak
Ki a harmadik fél és ki nem a harmadik fél? Hagyományos csomagkezelésnél a csomagokat vagy maga a fejlesztő készítette el (ez a ritkább), vagy a maintainerek. Ez ebből a szempontból nem változott, most is elkészítheti a fejlesztő, vagy egy külsős, bár Flathubon a csomagok többségét maga a fejlesztő teszi közzé, ami jó.
2. csináltak a csomagkezelés mellé egy másik csomagkezelést.
Igen, a meglévő hatezer csomagkezelő mellé, amik jellemzően csak a saját disztrójukon működtek, csináltak még egyet, ami cross-distro.
3. megnövelték feleslegesen az erőforrás igényt.
Kinek mit jelent az, hogy felesleges. Egyébként nem növekedett túlzottan, egy átlagos gépen alig lehet észrevenni, egy komolyabb gépen pedig semennyire.
Csak én érzem úgy, hogy adtak a szarnak egy pofont?
Biztos mások is éreznek így
De szerintem nem így van. -
urandom0
senior tag
Hadd válaszoljak én neked.
Az appimage sokkal rosszabb. Ott nincs sandbox, nincs jogosultságkezelés, nincs verifikációs rendszer, a legnagyobb appimage disztribútoron, az Appimagehub-on nagyon sok programnál nincs jelölve a licenc, ráadásul míg a Flathubnak elég részletes szabályzata és irányelvei vannak (https://docs.flathub.org/docs/for-app-authors/submission/), addig az Appimagehub-nak van egyodalas valamije, aztán kalap... össze sem hasonlítható a kettő.A snap kb. pariban van a flatpakkal, ilyen szempontból annyi a lényegi különbség, hogy a Snapcraft backendje nem nyílt forráskódú, a Flathubé igen.
-
Vladi
nagyúr
"Néha előfordul az is, hogy sem a Flatpak csomag, sem egyik runtime sem tartalmaz egy függőséget, ez esetben a fejlesztők jelzik a felhasználók felé, hogy az alkalmazás működéséhez telepíteniük kell az adott csomagot a disztribúció csomagkezelőjével."
Akkor jövök és széttrollkodom itt a bulit. Ez van, ilyen vagyok.
Tehát:
1. a csomagkészítést ezzel ksizerverzték 3rd partynak
2. csináltak a csomagkezelés mellé egy másik csomagkezelést.
3. megnövelték feleslegesen az erőforrás igényt.Csak én érzem úgy, hogy adtak a szarnak egy pofont?
Cserébe a disztribútor lerázza a válláról a munka egy részét. Odanyomja ezt a felesleges rendszert a usernek.
Persze mindezek után ezt mind elkerülni nem lehet...Tényleg csodás rendszer.
-
urandom0
senior tag
Nem. Ha sudo-val telepítesz egy flatpak csomagot, az csak a telepítési folyamatot érinti, és csak azért kell, hogy tudjon írni a /var/lib/flatpak alá.
sudo-val közvetlenül ha akarnál se tudnál futtatni flatpak appot, mert egy ilyen hibaüzenetet fogsz kapni:
hiba: "flatpak run" is not intended to be run as `sudo flatpak run`. Use `sudo -i` or `su -l` instead and invoke "flatpak run" from inside the new shell.Ha
sudo -i-vel próbálod futtatni, akkor is kapsz egy-két hibaüzenetet, és nem fog elindulni, hasu-ból, akkor pedig ilyesmit kapsz:bwrap: Can't find source path /run/user/1000/.flatpak/4124128034: Permission deniedMeg lehet próbálni pkexec-szel, azzal sem fog menni. Alapvetően a flatpak úgy van tervezve, hogy ne fusson rootként.
-
urandom0
senior tag
Egy élő példa, tavaly nyáron találtak egy malware-t, ami Minecraft modokba rejtettek el. A malware a ~/.config/systemd/user vagy /etc/systemd/system/, és a ~/.config/.data mappákba rakta a fájlait. Ha a Minecraftot olyan launcherrel futattad, amit csomagkezelővel töltöttél le vagy a netről szedtél le, akkor meg tudta fertőzni a rendszered, be tudta írni magát a ~/.configba és a saját service-ét a ~/.config/systemd/user-be.
Ha viszont flatpakos launcherrel futtattad, akkor viszont nem tudta beírni magát ezekre a helyekre, mert nem volt hozzá jogosultsága. Most végignéztem az összes launchert flathubon, amiket a 'minecraft' szóra kidobott, egyetlen egyet találtam, aminek filesystem=home jogosultsága van, a többi viszont nem tud írni a ~/.config-ba. -
urandom0
senior tag
A legtöbb flatpak csomag közvetlenül a Github repóból készül a Flathub infráján, teljesen nyitott manifest fájllal. Az ilyenek visszaellenőrizhetők.
Vannak persze olyanok is, ahol prebuild binaryt töltenek fel, de hát ez elkerülhetetlen olyan esetekben, amikor nem nyílt forráskódú programról beszélünk. De hát még magában a kernelben is vannak closed-source részek...Biztonsag szempontbol egy olyan platform, ami egy egyszeru dotfile-lal torheto,
Ez kb. ugyanaz a szituáció, mint ha fognál valakit, leültetnéd a géped elé, adnál neki root jogokat és kijelentenéd, hogy a Linux nem biztonságos, mert bárki feltörheti.
Ha valaki random dolgokat tölt le a netről, és vakon ad nekik futtatási jogosultságokat, és le is futtatja őket, akkor ne csodálkozzon, ha lyukas a rendszere, mint az ementáli.Mert amúgy a ~/.local/share/flatpak/ könyvtár a flatpak alkalmazások számára NEM elérhető, amíg explicit módon nem adsz rá engedélyeket.
Másrészt ezzel a módszerrel csak olyan jogosultságok adhatók az appoknak, amivel egy csomagkezelőből letöltött program vagy egy appimage alapból rendelkezik. Tehát még mindig van egy plusz védelmi réteg a flatpak appoknál, amivel a csomagkezelős programok, a random weboldalakról letöltött csomagok vagy binárisok, illetve az appimage-ek nem rendelkeznek.
Egyébként a hosszútávú cél az, hogy a statikus jogosultságok megszűnjenek, vagy legalábbis a minimumra csökkenjen a használatuk, és a helyüket átvegyék a portálok.
az minden, csak nem biztonsagos, ennel meg a normal csomagokra vonatkozo ACL-ek (SELinux, AppArmor) es filesystem jogosultsagok is nagyobb vedelmet nyujtanak.
Igen, azt a pillanatot várom én is, amikor az átlagos Linux felhasználó SELinux policyket fog írkálni
Az érveid közül én egyedül azt látom aggályosnak, hogy a flatpak csomagban lehetnek olyan binaryk, amiket nem nyílt forráskódból építettek, illetve nem bizonyítható, hogy az adott app abból a forráskódból épült, amire hivatkozik. De hát ez utóbbi biztosítása sem jelent garanciát, lásd az xz esetét.
Egyébként a Flathub webes felületén van olyan szűrő, ahol be tudod pipálni, hogy csak nyílt forráskódú és csak verified appokat mutasson: https://flathub.org/apps/search?q=image
-
Meg mindig nem erted. A fejleszto sajat maga rakja bele az arto kodot a fejlesztesebe, miutan az installbase eleg nagy lett. Itt aztan alairhatsz barmit.
Biztonsag szempontbol egy olyan platform, ami egy egyszeru dotfile-lal torheto, az minden, csak nem biztonsagos, ennel meg a normal csomagokra vonatkozo ACL-ek (SELinux, AppArmor) es filesystem jogosultsagok is nagyobb vedelmet nyujtanak.
De az utolso mondattal legalabb egyet lehet erteni.
-
urandom0
senior tag
A verified flatpak az egvilagon semmilyen biztonsagot nem ad, mert artalmas kod kesobb is belekerulhet az appba, hiaba egy a fejleszto es a koder.
Az összes repó, csomag, minden alá van írva, abba biztosan nem nyúlkál bele senki.
A usernek pedig nem olyan szoftvert kell adni, amirol reklamozzuk, hogy secure es kozben egy mozdulattal megsemmisitheto a vedelmi vonala, hanem olyat, ami tenylegesen biztonsagos.
Szerintem olyan nincs, hogy a kényelem és a biztonság ne mennének egymás rovására. Eleve nehéz azt definiálni, hogy mi a biztonság, és mi a biztonságos. Legfeljebb elvárható biztonságról lehet beszélni, ebből a szempontból a Flatpak szerintem jól működik. Ő a technikai felételeket biztosítja hozzá, azt, hogy ha pl. letiltod a hozzáférést a /home-hoz, akkor ahhoz nem fog hozzáférni. És én meg arra utalok vissza, hogy ezt ilyen könnyen nem tudod megtenni hagyományos csomagkezeléssel.
Egyébként minden védelmi vonal megsemmisíthető, ha a user elég ügyes hozzá. -
Speciel Debian eseten van biztonsagi ellenorzes a csomagokra, mielott a stable-be kerul. Az olyan slendrian disztribuciok, mint az Ubuntu, persze futyulnek erre, tobbek kozott ezert kaptak be az xz-alapu ssh backdoort.
A verified flatpak az egvilagon semmilyen biztonsagot nem ad, mert artalmas kod kesobb is belekerulhet az appba, hiaba egy a fejleszto es a koder. Megint visszautalok az xz-re, ahol egy uj fejleszto vette at a csomag karbantartasat, majd idovel becsempeszte a backdoort.
A usernek pedig nem olyan szoftvert kell adni, amirol reklamozzuk, hogy secure es kozben egy mozdulattal megsemmisitheto a vedelmi vonala, hanem olyat, ami tenylegesen biztonsagos.
-
urandom0
senior tag
Ez igaz, de:
1. a runtime-ok folyamatosan frissülnek, egyébként jelezve van (paranccsorban is, Flathub felületén is, Warehouse-ben is, Gnome Software-ben is) ha valamelyik runtime túllépte az EOL-t.
A flatpakon belüli binárisok állapota valóban lehet kérdéses, erre találták az a f-e-d-c-t, ami végigellenőrzi, hogy van-e elavult függőség a csomagban. Ezt nem csak a fejlesztők használhatják, hanem maga a Flathub is használja folyamatosan, és ha elavult függőséget talál, a Flathub bot pull requestet küld.
De egyébként a csomagtelepítős programok közül is van olyan, ami saját binárisokat hoz magával, azokra sincs garancia, hogy nincs bennük sebezhetőség.2. az appok jogosultságait te, mint felhasználó, nagyon egyszerűen meg tudod nézni (Flathub felületén pl. ott is van, hogy tudja írni/olvasni a home foldert) és át tudod állítani, ellentétben a csomagkezelőből érkezett programokkal, amikkel ezt azért sokkal nehezebb megtenni.
És ha verified flatpakot töltesz le, akkor biztos lehetsz benne, hogy ugyanaz készítette a flatpakot, mint aki a programot is, tehát szándékosan rossz indulatú kódot nagy valószínűséggel nem tartalmaz.De azzal szerintem te is egyetértesz, hogy nem lehet úgy odaadni a végfelhasználónak egy szoftvert, hogy ne lenne filesystem=user jogosultsága. Nagyon sok program így gyakorlatilag használhatatlanná válna.
-
Koszi az irast, szep munka, hogy utana mentel - azt viszont sajnalom, hogy a biztonsagrol szolo resz csak egy ocska marketing duma, semmi tobb.
Eloszor is, a flatpak nem fog frissulni, tehat biztonsagi hiba eseten meg kell varni, mig a csomag karbantartoja elkesziti a friss flatpeket - ha egyaltan megtortenik. Masodszor, a flatpak annyira biztonsagos, amennyire azza tette a fejleszto. Harmadszor, a sandbox sem ugy igaz, ahogy azt az egyszeru halando kepzeli, mert a flatpak meg mindig nem szabalyozza az appok jogosultsagait, hanem az appokra hagyja, hogy elkeszitsek a sajat policy-juket. Ha egy flatpak alkalmazas filesystem=host vagy filesystem=home jogosultsagokkal van konfiguralva, akkor meg ebbol a gyengen vedett sandboxbol is eleg egyszeruen ki lehet torni.
-
Szuper írás lett!
-
#5
urandom0
senior tag
Krugszvele
#3
urandom0
senior tag
válasz
Krugszvele
#3
üzenetére
Igen, ez online, itt nem te töltöd le a zenéket, hanem csak rákeresel, és a Spotify letölti és lejátssza.
Azért van ilyen sok kliens, mert a gyári Spotify app electronos, az electronos appok pedig nem a sebességükről és erőforráshatékonyságukról híresek. Az alternatív kliensek mind gyorsabbak és kevesebb erőforrást használnak. Viszont ha Spotifynál API oldalon változik valami, és az alternatív kliens ezt nem követi le, akkor nem is tudod használni. Illetve vannak olyan funkciók, amik nem érhetők el alternatív klienssel, de ezek jellemzően olyanok, amiket ritkán használ az ember (pl. jelszóváltoztatás, ilyesmik). -
#2
UnA
Korrektor
Krugszvele
#1
válasz
Krugszvele
#1
üzenetére
Így van, nagyon jó cikk lett. És tetszett az ajánló is.
-
#1
Krugszvele
senior tag
Krugszvele
senior tag
Még több ilyen cikket a logoutra!
Új hozzászólás Aktív témák
Hirdetés
- WoW avagy World of Warcraft -=MMORPG=-
- Suzuki topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Samsung Galaxy A56 - megbízható középszerűség
- Samsung Galaxy A52s 5G - jó S-tehetség
- OLED monitor topik
- Milyen autót vegyek?
- Fujifilm X
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- További aktív témák...
- Thinkpad X230 legenda: i7 CPU, IPS kijelző, 12 GB, dupla SSD, magyar villbill, webcam, fingerprint
- Honor X6b 128GB Kártyafüggetlen 1Év Garanciával
- Apple Watch SE2 / 44mm / Midnight / Black Sport / Cellular (99%)
- Iphone 13 Pro Max 128 GB /// 86% Akku // Számlával és Garaniával
- Iphone 12 Pro Max 128 GB /// 88% Akku // Számlával és Garanciával
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Azonnali készpénzes nVidia RTX 3000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- Apple iPhone 14 Pro 128GB Kártyafüggetlen, 1Év Garanciával
- Csere-Beszámítás! Asztali számítógép PC Játékra. I5 12400F / RTX 3070 / 32GB DDR4 / 1TB SSD
- Lenovo ThinkCentre M720q/ Dell OptiPlex 3060- 3070/ Hp EliteDesk 800 mini, micro PC-Számla/garancia
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged