- OLED TV topic
- Azonnali alaplapos kérdések órája
- A Windows 11 lett az úr az asztali PC-k piacán
- Micro Four Thirds
- Milyen billentyűzetet vegyek?
- 3,6 GHz fölé kúszott a Galax GeForce RTX 5090D GPU órajele
- HP EliteBook / ZBook topik
- Bambu Lab 3D nyomtatók
- Szünetmentes tápegységek (UPS)
- Kormányok / autós szimulátorok topikja
Új hozzászólás Aktív témák
-
urandom0
senior tag
És ez már minden jelentősnek mondható disztróban benne van, legalább van valami közös pont.
Igen, én pont ezért döntöttem úgy, hogy maradok a Systemd-nél. Mert akárhova megyek (mondjuk másik munkahelyre), vagy akármilyen projektet kapok meg, szinte biztos, hogy Systemd-es disztróval fogok találkozni. Akkor már érdemesebb azt megismerni és használni, mint harcolni ellene.
A kis Pepper roboton, amiről tettem be képet, azon immutable Gentoo van, az is Systemd-es. Ezen meg is lepődtem.
-
urandom0
senior tag
aki beilleszkedik a debianos közösségbe és megtartja a szabályokat, az debian karbantartó. aki nem illeszkedik be és egyetlen célja, hogy áthágja a unixos és a debianos szabályokat, és hogy meghajlítsa a közösséget maga felé, az gyüttment.
Jia Tan is tök jól beilleszkedett. Egy mintagyerek volt, a lépcsőházban is mindig előre köszönt
Nekem ennyit megér a stabilitás.
Minden vicc nélkül mondom, ha a rendszerprogramok és az alkalmazások el vannak különítve (akár flatpakkal, akár dockerrel, akár csak egy distrobox konténerrel), akkor a rendszer stabilabb lesz.
---
Debianban a contrib, non-free és a non-free-firmware repókat nem tekintik a rendszer részeinek, ezért a security team nem is foglalkozik vele. Ezt eddig nem tudtam...
"Some non-free packages are distributed without source or without a license allowing the distribution of modified versions. In those cases no security fixes can be made at all."
Ez bizony szomorú.
Innentől fogva viszont egyáltalán nem tekintenem ezeket a repókat biztonságosabbnak, mint a flatpakot. Gyakorlatilag ugyanúgy 3rd party repók.
-
urandom0
senior tag
Külön weboldala is van az anti-systemd fan clubnak: https://nosystemd.org
Nem mondom, hogy nincsenek benne értelmes érvek, mert vannak. De a Systemd körül kialakult gyűlöletet túlzónak érzem, és szerintem sokan csak azért utálják, mert új, és más, mint ami korábban volt.
Én teljesen jól elvoltam SysV inittel is, a Slackware-féle BSD-szerű init rendszerrel is, és elvagyok Systemd-del is. Nem tapasztaltam egyikkel sem problémát. -
urandom0
senior tag
Ezért most egy nuc-ot használok, testing debiannal,
Ajajj, az nem annyira jó. Azt tudod ugye, hogy a testing biztonsági frissítéseit nem menedzseli a security team?
Erről a Firefoxos problémáról más is írt, azt hiszem, a kezdő topikban.
-
urandom0
senior tag
te honnan veszed, hogy ennyire bízunk a disztrók saját tárolóiban?
Onnan, hogy ezt bizonygatjátok itt már napok óta
De arra senki nem számít, hogy jönnek gyüttmentek, és ezt a kockázatot jelentősen megnövelik.
De pont ez nem tudta nekem eddig még senki sem elmagyarázni, hogy mitől gyüttmentek a flatpak maintainerek (gondolom, rájuk gondoltál), és miért nem azok a Debian maintainerek? Meggyőző észérvet még senkitől sem olvastam.
Nekem voltak szervereim, amik nemrég még 6-os debiant futtattak. *MINDENT* meg tudtam csinálni rajtuk, amit a munka igényelt. Minek változtatni?
De nem csak te létezel a földön, és nem csak a te használati eseted létezik, van még rajtad kívül pár millió Linux user, egészen eltérő elvárásokkal.
-
urandom0
senior tag
Én meg pont azt nem értem, hogy miért bízik mindenki ennyire a disztrók saját tárolóiban. Még mindig nem találtam meg például azt, hogy hol van leírva, hogy milyen ellenőrzéseket végeznek a csomagokon.
Azt viszont nem jelentheted ki, hogy a Flathubon nincs biztonsági ellenőrzés. #163-ban leírtam, hogy mi a helyzet Flathubnál, ennél többet sajnos nem írnak. Tehát legfeljebb azt mondhatod, hogy nem tudjuk, pontosan milyen ellenőrzések vannak Flathubon.
Azt biztosan tudjuk, hogy van code review, van manuális ellenőrzés, megnézik a csomagok jogosultságainak változásait is, és ha kell, visszatartják a csomagot. -
urandom0
senior tag
De azt melyik sorom üzente számodra valaha is, hogy ilyen fajta lennék? Hogy az csipegetem ki a világ történései közül ami nekem tetszik? A tényállás az, hogy ettől pont hülyét kapok és nem egy 'önsorsrontásom' volt már, ami ennek kiváló tanúbizonysága.
Oké, akkor lehet, hogy én értelmeztem félre. De mindegy is szerintem.
Mindezek ellenére nem haszontalan, hogy körbejáródik a flatpak/egyéb csomagz témaköre.
Igen, szerintem is.
-
urandom0
senior tag
Ne az én fogalmázáskészégemről szoljón a topik, kérlek titeket. Lehet persze kritizálni, csak nem biztos, hogy van értelme.
totron
Nem arról van szó, hogy Árnyék kolléga jobban meg tudta fogalmazni, hanem arról, hogy azt írta, amit hallani akarsz.
sh4d0w
Én abszolút értékelem, hogy a Debian security csapat ilyen sokat tesz a biztonságért, nekem csak annyi a problémám, hogy eddig senki nem tudta bemutatni azt a dokumentációt, ami leírja, hogy a csomagbefogadás során mit és hogyan ellenőriznek.
Az AI véleményére pedig, ha nem haragszol, nem adok egy lyukas garast sem.
Azt pedig kizártnak tartom, hogy alapos codereview-t végeznek minden egyes programon. Mennyi csomag van most egy Debianban kiadásban, 65 ezer? Ha ezeknek csak a negyede szoftver, az is 16 ezer csomagot jelent. A világ összes programozója nem lenne elég arra, hogy ennyi csomagot alaposan átnézzen.Abban egyetértünk, hogy a 3rd party repó legyen az utolsó, ahhonan az ember letölt bármit is. Csak abban nem, hogy én a Flathubot nem tartom úgy 3rd party repónak, mint mondjuk az AUR-t vagy a COPR-t, mert azokat senki nem ellenőrzi. Ahhoz képest egyébként, hogy mennyire nem ellenőrzi az AUR-t senki sem, eddig egyetlen egy esetben találtak benne veszélyes programot, az is egy kriptominer volt. Egyébként a miner a user systemd unitjai közé írta be a sajátját - flatpak esetén ezt alapból nem tudta volna megtenni, mert nincs hozzá jogosultsága.
Én nem tartom veszélyesebbnek a Flathubot, mint mondjuk az universe vagy multiverse repókat.-----
Viszont a gyakorlatban alig van olyan ember, aki csak a repó által biztosított csomagokat használja. Ha valaki töltött le valaha az életben egy Gnome kiterjesztést, egy KDE témát, egy akármilyen .sh fájlt, egy scriptet a Gimphez, bármilyen Python vagy NodeJS modult... akkor ő már eleve veszélynek tette ki magát. De akár egy szimpla böngésző-kiegészítő is lehet veszélyes.
-
urandom0
senior tag
Miért?
Ha a libc nem kompatibilis a kernellel, maximum nem indul el a program. De egyrészt én ilyet még nem láttam, pedig elég sok flatpak programot futtatok különféle disztrókon, másrészt elméletben is elég kicsi rá az esély.Az újabb verziójú libc kompatibilis a régi kernelekkel, elég hosszútávon visszamenőleg.
-
urandom0
senior tag
És most akkor harmadszor is: a libc6 bent van a Freedesktop runtime-ban. Meg egyébként olyan libek is, mint a libstdc++, illetve a coreutils-ból kb. minden.
Egy flatpak alkalmazás nem támaszkodhat a host libjeire. Nem is nagyon tudna, mert a flatpak futtatókörnyezet felcsatolja a saját /usr könyvtárát az alkalmazás számára, ami a Freedesktop /usr könyvtárára fog mutatni, tehát az alkalmazás az /usr/{lib,lib64} alatt a Freedesktop libjeit tudja csak elérni.
Ez egészen addig így van, amíg explicit nem adsz host-os jogosultságot az alkalmazásnak, de a host /usr könyvtára akkor is csak a /run/host könyvtárba fog felcsatolódni, tehát az /usr marad továbbra is a Freedesktop-féle /usr. -
#170
urandom0
senior tag
Kisgépkezelő
#168
urandom0
senior tag
válasz
Kisgépkezelő
#168
üzenetére
Sokszor nem válaszolok egy-egy hozzászólásra, az pont azért van, mert nem akarom tovább boncolgatni a témát.
-
urandom0
senior tag
Próbálj kicsit túllátni a Debianon, nem csak az az egy disztró létezik.
Ha valaki nem csak a Debianra akarja kiadni a programját, hanem a lehető legtöbb disztróra (vagy legalább a 4-5 top disztróra), akkor mindegyik disztrón le kell tesztelnie a programját (sőt, igazából minden disztró minden forgalomban lévő verzióján le kell), függetlenül attól, hogy a libreadline-t a fejlesztő és a csomagoló már letesztelte. Ez már így elég sok teszt.A fejlesztő így is-úgy is tesztel, hisz az az egyik feladata. Neki csak könnyebséget jelent, hanem X disztrón kell tesztelnie, hanem csak a flatpak runtime-mal.
-
urandom0
senior tag
erős opció, hogy ha egy kívülről jövő meteort bontogatsz/futtatsz, akkor abban lehet bármi
De miért tartod a Flathubot kívülről jövőnek, a disztró saját csomagjait pedig belülről jövőnek?
Az én meglátásom szerint, egy Flathub csomag "befogadási procedúrája" és karbantartása gyakorlatilag nem különbözik egy belülről jövő csomagétól.
A Flathub ezt szépen leírja: Submission"Once your pull request has been submitted, it will be reviewed. Reviewers may post comments and may ask for certain fixes or clarifications. Once all comments are resolved, a test build can be started on the pull request by commenting
bot, build $FLATPAK_ID.
If the test build is successful, the application is tested by installing and running it. Further feedback may be provided after that." (kiemelés tőlem)A csomagkarbantartási vonatkozóan szintén vannak elvárások: Maintenance
"A test build will be started on every push to a pull request and if it is successful the bot will post a link to a Flatpak bundle generated from the PR contents. This temporary build can be used to test the changes made in the PR.""Whenever an official build from a merge commit is built, if any permission is changed or any critical Appstream field changes value, the build will be held for moderation.
Moderators will manually review the build and the permission change and can approve or reject the change if it is wrong or ask for more information."
Kérdezem én, ha te magad töltesz le egy forráskódot és te magad fordítod le, abban sem bízol meg? Mert gyakorlatilag a Flathub is ezt csinálja (kivéve a zárt forráskódú programoknál, de az eredet ott is visszaellenőrizhető).
Csak mellékesen: a csomagok fordítási folyamata is nyít és átlátható, itt lehet követni: https://buildbot.flathub.org/
-
urandom0
senior tag
AI... amit ma "AI"-nak hívnak, az gyakorlatilag egy statisztikai alapon működő szöveggenerátor. Nem mondom, hogy ne lenne hasznos, de a valódi intelligenciától még nagyon távol áll.
A munkahelyemen van egy ilyen robotunk: [link]
Mostanában kísérletezünk azzal, hogyan lehet összekötni az OpenAI API-val. A kommunikáció megy, de az ún. "mesterséges intelligencia" nem elég intelligens ahhoz, hogy beszéd közben mozgassa is a robotot. Úgyhogy egylőre ott tartunk, hogy áll egy helyben, mint a cövek, aztán mondja a magáét -
urandom0
senior tag
Milyen egy biztonsági ellenőrzés egyébként?
Hát ez az, pont erre várom én is a választ tőletek
Leírjátok, hogy vannak-e biztonsági tesztek a Debian csomagokon, de azt nem, hogy mit értetek biztonsági teszt alatt, vagy hogy mit kellene vizsgálnia, vagy mi lenne a célja pontosan az ilyen teszteknek...?Én amit tudtam, leírtam: Vannak automatizált tesztek, amik bizonyos patterneket (SQL injection, XSS, stb.) illetve megtalálnak backdoorokat, malware-eket.
Ezek azok a területek, amiket automatizált tesztekkel viszonylag könnyen le lehet fedni.
Ami ezeken túl van, pl. az, hogy egy alkalmazás mennyire kezeli biztonságosan a sessionöket, vagy hogy milyen fájlokat ér el futás közben, milyen hálózati forgalmat generál, stb., azokat úgy lehet tesztelni, hogy az ember tesztkörnyezetet állít fel, és tesztesetek vizsgál.
De egyrészt ez nem a maintainerek munkája, hanem a szoftverfejlesztőé (van olyan fejlesztési módszer, ahol először a tesztet írják meg, és utána írják meg a programkódot, aminek meg kell felelnie a teszteken), másrészt ez borzasztóan sok energiát igényelne. Ilyeneket biztosan nem csinál senki sem. -
urandom0
senior tag
Ezek nagyrészt hibaellenőrzések, nem biztonsági ellenőrzések.
És tudod, mi a legszebb ebben? Hogy ezekre alapvetően azért van szükség, mert a csomag, miután a Debian befogadta, onnantól a rendszer része lesz. Függ más csomagoktól, és más csomagok is függhetnek tőle. Ez az egész ellenőrzési folyamat rengeteg energiát emészt fel a maintainerek és tesztelők részéről.
Ezzel szemben, ha az adott alkalmazás kikerül a függőségi rendszerből, onnantól fogva teljesen a fejlesztő feladata biztosítani azt, hogy a lehető leghibamentesebben működjön, és onnantól fogva a rendszer maintainereinek és tesztelőinek nem kell vele foglalkozni, ergo rengeteg erőforrás szabadul fel rendszeroldalról.
A tesztelés és a hibamentes működés bizotsítása egyébként is a fejlesztő feladata, és a fejlesztő futtat is mindenféle teszteket a szoftveren. Csak Linuxon a függőségi rendszer miatt muszáj azt is külön letesztelni, hogy a csomag hogyan illeszkedik a disztróba.
Más operációs rendszereken ilyet nem látsz, ott csak a drivereket és egyéb rendszerkomponenseket ellenőrzik ilyen szinten.
-
urandom0
senior tag
Ja értem, oké
Tehát tulajdonképpen nincs semmilyen vizsgálat. Pedig jó lenne, ha lenne, talán akkor a Debian stable sem lenne tele sebezhetőségekkelDe távol álljon tőlem, hogy bántsam a Debiant, egy nagyon jó rendszernek tartom. A maintainereknek is minden elismerésem.
De némi józan ésszel könnyen belátható, hogy nincs olyan teszt a világon, ami - néhány triviális biztonsági problémát leszámítva - alkalmas lenne arra, hogy a csomagok biztonságát garantálják. Vannak automatizált tesztek, amik bizonyos patterneket (SQL injection, XSS, stb.) illetve megtalálnak backdoorokat, malware-eket. Ilyeneket le lehet futtatni, de ehhez is kell szakember, idő, energia.A legbiztosabb módszer a sebezhetőségek kiszűrésére az, amit Lasse Collin is megtett, hogy sorról sorra, commitról commitra végigellenőrizni a forráskódot.
-
-
urandom0
senior tag
-
urandom0
senior tag
a másik flatpak csomagot is összerakhatta volna deb-ben
Amikor elkezdődött ez az egész flatpakos történet, 2007-ben, akkor még talán lehetett volna deb-et használni. Hogy miért nem arra esett a választás, én nem tudom megmondani, de komolyan írni fogok egy e-mailt Alexander Larssonnak, megérdeklődöm tőle
még mindig hangsúlyozom, hogy a flatpak egy csomagolási módszer.
Nem CSAK csomagolási módszer, hanem ott van még mellette a futattókörnyezet, ami elindítja a programot, kezeli a jogosultságokat (a Bubblewrap segítségével), meg ott a flatpak-builder, ami csomagokat épít, meg az egyéb infrastruktúrális dolgok, pl. a távoli repók kezelése, stb.
de itt az is a probléma, hogy a fejlesztő a saját problémáját át akarja tolni az userre. userből nagyságrendekkel több van, tehát ez pazarlás.
Korábban azzal volt problémád, hogy a flatpak fejlesztésére elvont erőforrások hiányoznak az alap fejlesztésekből, most meg az a gond, hogy a usereknek problémát okoz a flatpak... most akkor döntsük el, hogy ki szívjon, a user vagy a fejlesztő?
Én azt gondolom, a usereknek semmilyen jelentősebb töbletterhet nem jelent a flatpak. Sőt, a userek is profitálnak abból, ha a fejlesztőnek nem kell 3-4-5-6-akármennyi disztróra csomagolnia, tesztelnie, hanem azt az energiát a szoftver fejlesztésére, unit tesztelésre és hibajavításra fordíthatja. -
urandom0
senior tag
és akkor ez pontosan miben is más, hogy összeválogattad és flatpaket csináltál belőle, mintha debet csináltál volna?
hint: semmiben.
q.e.d.Dehogynem, ugyanis egy flatpak csomagban nincs benne minden függőség, hanem a nagyrészük a runtime-okban van. Mielőtt azt mondanád, hogy ezt is meg lehet oldalni mondjuk apt-vel, közlöm, hogy pl. Suse-ra nincs apt. Tudom, forgassak magamnak egyet...
És akkor még mindig csak a csomagkészítésről van szó, arról nem is beszéltünk, hogy nem csak elkészíteni kell a csomagot, hanem illik azért letesztelni minden egyes disztrón is.
És akkor arról még nem beszéltünk, hogy a flatpak tud sandboxot is...akkor az azért nem fog települni debianon, mert az ubuntu alaprendszer újabb
Igen, ezt írtam én is.
következmény: fel kell raknod duplikátumként azt a libet, amelyik az alaprendszerben régebbi, de azt fel kell raknod flatpak esetén is, meg deb esetén is.
Igen, meg ha az a lib egy másik libre hivatkozik, azt is fel kell raknom. És ha van 5 ilyen libem, meg azoknak van még 15 tranzitív függősége, akkor már 25 libem, amire folyamatosan ügyelni kell. Frissítgetnem kell őket, vigyáznom kell, hogy ne törjenek el, stb. És közben minden egyesnél release-nél tesztelnem is kell minden rendszeren.
Miközben flatpak esetén kikötöm, hogy org.freedesktop.Platform 23.08-as verzió kell és kész, ennyi. Két évente pedig frissítem, mert egy ilyennek 2 év a támogatása.A baj az, hogy te csakazértsem akarod átlátni ezt az egészet, és nem akarod megérteni, hogy egy csomagot kiadni Ubuntura, Debianra, Fedorára, Archra, Suse-ra az mondjuk 25 emberóra, míg ugyanezt flatpakban 1 emberóra.
Akárhogy is csűröd-csavarod, mindig ott lyukadunk ki, hogy a te megoldásod sokkal melósabb. -
#133
urandom0
senior tag
Kisgépkezelő
#131
urandom0
senior tag
válasz
Kisgépkezelő
#131
üzenetére
A legtöbb programnál nincs gond a flatpak futási sebességével. Az indulási sebesség az, ami lassabb, mint a csomagkezelős appoknál, illetve sok helyet foglalnak a flatpakos appok, mint a natívak.
-
urandom0
senior tag
Miért választod a flatpaket, miért nem választod mondjuk az rpm-et?
Mert a flatpakot oda tudom adni az Archosnak, a Debianosnak, az Ubuntusnak, a Fedorásnak, az OpenSuses-nak, és működni fog.
Én értem, hogy a fejlesztőnek problémás, hogy melyik csomagformátumot választja, de akkor azt a problémát kell megoldani, nem flatpaket meg snapet fejleszteni helyette.
A probléma megoldása maga a flatpak és a snap
egyébként csomagolj rpm-be, debianra van rpm->deb konverter, tehát fel lehet rakni rpm-et debianra. gyakorlatilag ha aktuális fedorara fejlesztenél, lefednéd vele a számba vehető disztrók 95%-át flatpak nélkül.
Na látod, pont erről beszélek. Csomagoljam be rpm-be, a Debianos konvertálja át magának deb-re, és tesztelje is, ha már úgyis ott van. Vagy konvertáljam át én, és teszteljem le én? Oké, megteszem, de akkor már kétszer annyi munkát végzek, mint ha feldobtam volna Flathubra.
Egyébként az átkonvertálás egyáltalán nem ilyen egyszerű. Ha én megcsinálom a csomagot mondjuk Ubuntura, és ez van a debian/control fájlban:
Depends: efibootmgr (>= 17), python3 (>= 3.9), libgtk-3-dev (>= 3.24)És ha ezt a csomagot egy Debianosnak odaadom, akkor a Debianosnál azért nem fog települni, mert efibootmgr-ből nála csak 16-os van, az OpenSusesnál azért nem fog futni, mert nála a libgtk-3-dev helyett libgtk3-devel van, az Archosnál meg azért nem, mert nála meg csak AUR-ban van efibootmgr (ott is csak forráskódban).
Nem hülyeségből találták ám ki a flatpakot meg a snapot, ha ez ilyen könnyen menne, mint ahogy állítod, akkor nem találták volna ki.és a többi verzióban? Legyen fent az org.gnome.Platform csomagból több az user gépén, mert a te cuccod a 47-esre dependál, a másik cucca a 48-asra?
Igen.
És ha a válaszod igen, ezt miért nem tudod megcsinálni debiánon? Egyszerűbb neked felrakni a flatpaket, ahelyett, hogy megnéznéd a helyes megoldást, és rákényszeríteni a leendő felhasználóidat, hogy szemeteljék tele a gépüket flatpakkel, miattad? Akkor nem kell a programod.
Mert ha megcsinálom Debianon, akkor az még nem lesz megcsinálva Fedorán, Archon, OpenSusén, satöbbin. Esetleg azt csinálhatom, hogy deb-be csomagolok, és belerakok minden libet, amire szükségem van (vagy eleve statikusan fordítom le a programom), és azt konvertálgatom át rpm-be, tar.gz-be, stb. És akkor gyakorlatilag feltaláltam az appimage-et
Side note: a flatpak nagyon minimálisat szemetel. Magának a flatpaknak csak néhány függősége van, többségében olyanok, amik úgyis fent vannak a gépen (libc6, libsystemd0, stb.), és maguk a flatpak appok is összvissz 2 könyvtába pakolják a dolgaikat. Én örülök neki, hogy a rendszer és az appok két teljesen más rétegben vannak.Szerencsére dönthetsz úgy, hogy nem kell a programom, ez teljesen elfogadható. Vagy oda is adhatom a forrást, és lefordítod magadnak. De akkor neked kell gondoskodnod, hogy a program megfelelően fusson a disztródon, neked kell beszerezned a függőségeket hogy egyáltalán leforduljon, stb. De nyilván az átlagos végfelhasználóktól ezt nem várhatom el.
tehát NEM IGAZ, hogy minden disztróra foglalkoznod kell a lib apijával, azzal kell esetleg foglalkoznod, hogy van-e megfelelő verziószámú lib a disztróban
Igen, erre próbáltam utalni én is a libadwaitás példámmal.
akkor én tuttira a harmadikat választanám. Pláne, hogy nem kellene túl sok disztróra megtanulni, elég lenne csak az, ami az üzleti világban elterjedt.
Oké, de nem lehet mindenki ilyen született talentum, mint te. Én azt értem, hogy ha te csomagolsz be egy programot, az a program el fog futni DOS 6.22-tól kezdve a Haikun keresztül a NetBSD-ig bezárólag mindenen, még tamagochin is. De sajnos vannak nálad gyengébb képességűek is
-
urandom0
senior tag
Hát igen, ez nézőpont kérdése is. A Red Hat erősen viszi egyfajta irányba a Linuxot, nézőpont kérdése, hogy kinek tetszik vagy nem tetszik ez az irány. Ha megkérdezel egy Devuan usert, neki nem annyira fog tetszeni
Meg a Red Hat sem fekete-fehér (hanem piros), nyilván vannak jó és rossz döntései. Pl. amit a CentOSsel tettek, az sokaknál kiverte a biztosítékot. -
urandom0
senior tag
válasz
urandom0
#118
üzenetére
Még egy dolgot el is felejtettem.
Nagyon sok disztrónál legalább két csomagváltozatot kell karbantartani, van egy "stable" és egy "oldastable". Debian, OpenSuse, Fedora... mind így csinálják.
Namost, ez meg a csomagkarbantartókra ró igen nagyon terhet.
De ha egyik napról a másikra úgy döntenek, hogy innentől fogva nincs natív csomag, hanem van egyetlen egy flatpak csomag, akkor a maintainerek is rengeteg munka alól mentesülnek.
Nézd meg pl., hogy mennyi elárvult Debian csomag van. Mert a maintainernek nincs ideje, nincs motivációja, stb. Ha nem is mindet, de sokat át lehetne tenni flatpak csomagba, és akkor legalább nem oldstable és stable verziókat kell karbantartani, hanem csak egy current verziót. -
urandom0
senior tag
válasz
DarkByte
#114
üzenetére
Windowson esetleg Dockerrel lehetne megoldani a sandboxingot (de a Windowsos Docker tulajdonképpen Hyper-V+egy minimal Linux distro), a függőségeket (runtime-okat) msi csomagba lehetne rakni, a függőségkezelést pedig wingettel lehetne talán megoldani. És igen, maguk a programok statikusan fordíttott self executable-k úgy, hogy a runtime-okban lévő libeket onnan húzzák be.
De Windows-on senki nem akar ilyet csinálni, mert ott ott vana WinApi, az MFC, a .net, mint stabil API-k, azokra lehet építkezni. -
urandom0
senior tag
a flatpak nem ad apit. semmilyet, se stabilt, se instabilt. az apit a linuxos programok, libek adják
Igen, ez így van. Stabil API alatt nyilván a runtime-okban lévő libeket értem.
Ha fejlesztek egy programot, és mondjuk a org.freedesktop.Platform runtime 23.08-as verziójára dependelek, akkor van egy stabil API-m, teljesen függetlenül attól, hogy a disztrókban milyen csomagok vannak. Ezt értem az alatt, hogy a flatpak nekem stabil, fix, kiszámítható API-t ad.ugyanezt egy deb-be vagy targz-be is bele lehet csomagolni.
Igen, csak nincs minden disztróban dpkg. Persze, le lehet fordítani minden disztróra a dpkg-t meg az apt-t is vagy bármit, és lehetnének deb csomagok flatpak csomagok helyett, csak akkor kb. ugyanott lennél, mint most a flatpak.
Te alapvetően azt nem veszed figyelembe, hogy hatalmas nagy különbség van aközött, hogy valami lehetne, és aközött, hogy valami kész van, lehet használni, és van hozzá infrastruktúra. Ahogy DarkByte írta, nem technológiailag nagy dolog a flatpak, hanem mert felismerték, hogy ez egy működőképes dolog, és van rá igény.
nem feltétlenül jó, mert nem tudjuk, hogyan kerül bele egy csomag. max. azt tudjuk, mit írtak le arról, hogy hogyan kerül bele egy csomag, de hogy az alapján konkrétan mi történik, senki nem tudja.
Miért bízol meg jobban a disztród maintainereiben, mint a flatpak maintainerekben?
a sereg disztró sem igaz. a disztrók zömében azonos szoftvereket csomagolnak, legfeljebb sebességbeli eltéréseik vannak. oké, most a nagyon egzotikus disztrókról ne beszéljünk a musl libc-vel.. de a disztrók zöme, főleg, amik üzleti szempontból számítanak, gnu libc-t, gnu compiler collectiont, ugyanazt az X apit,
Menj fel a valadoc.org-ra. Bal oldali oszlopban látsz egy határ libet (pontosabban az API doksijukat). Ezek azok a libek, amik a legtöbb disztróban ott vannak, általánosan elérhetők. A Linuxos programok többsége ezek közül legalább egyet, de inkább többet használ. Nézzük meg mondjuk a libadwaitát, ezt majdnem minden GTK-s program használja.
A kérdés az, hogy ha én szeretném használni a programomban mondjuk a TabOverview komponenst, akkor azt támogatja-e az Ubuntu 20.04-ben lévő libadwaita, a 22.04-ben lévő, a 24.04-ben lévő, a Debian 11-ben lévő, a Debian 12-ben lévő, az Arch-ban lévő, az OpenSuse Leap-ben lévő, az OpenSuse Tumbleweedben lévő, a Fedora 40-ben lévő, a Fedora 41-ben lévő, ... ezeket így mindet végig kellene zongoráznom. És ha használok mondjuk 4-5 ilyen libet (ami nem sok), akkor ezt mindegyiknél végig kellene tesztelnem.Ezzel szemben flatpaknál az van, hogy tudom, hogy milyen verzió van a org.gnome.Platform 47-es verziójában, a flatpak csomaggal arra dependelek, és kész, nincs vele több dolgom. Ez az a különbség, ami miatt a flatpak appterjesztésre használhatóbb. A sandboxingról nem is beszélve, de azt most szándékosan figyelmen kívül hagyom.
Személetbeli különbségeink vannak.
Te nagyon elméleti oldalról közelíted meg.
Persze, hogy meg lehet csinálni ezt meg azt is, hiszen meg tudja oldani a Firefox is, meg az OpenTTD is. Nyilván be lehet csomagolni targz-be az egész világ, meg lehet fordítani akármi --prefixxel, meg deb-be is belefér minden.
Csak te azt nem veszed figyelembe, hogy ha egy szoftverfejlesztőnek választania kell aközött, hogy lefordítja, teszteli és csomagolja a programját az összes céldisztróra, vagy aközött, hogy megcsinálja mindezt egyszer, és működik, akkor nyilván az utóbbit fogja preferálni. Főleg, ha fizetős szoftverről van szó, nagyon nem mindegy, hogy 2-3 manuális tesztelőt kell alkalmazni, akik napi 8 órában tesztelgetik az új funkciókat minden egyes céldisztrón, vagy egyet, aki teszteli a flatpak csomgot és kész.Senki nem akar azzal szopni, hogy na most akkor Mint 22-n azért nem megy, mert a libadwaita más flagekkel van fordítva, most Debianon azért nem megy, mert kettővel korábbi apt verzió van fent, most Leap-en hibára fut mentéskor, mert ott SELinux van, Garudán KDE-n összeesik a layout, mert custom téma van megadva GTK_THEME-nek...
a flatpakesek nem értenek hozzá, különben nem lenne flatpak.
Azért ennyire ne nézzük már butának a másikat. A flatpak egyik "élmunkása" Alexander Larsson, aki "Senior Principal Software Engineer" volt a Red Hatnél, több, mint egy évtizedig. Szerintem ő több programot csomagolt be, mint amennyivel mi egy év alatt találkozunk. Hidd el, hogy jobban képben van a dolgokkal, mint itt mi mindannyian. -
urandom0
senior tag
válasz
DarkByte
#105
üzenetére
Igen, ez így van, de ha a flatpakot kell más operációs rendszerekben lévő megoldásokhoz hasonlítani, akkor nem tudok jobbat, mint a MacOS-féle app bundle. Az más kérdés, hogy maga az app bundle az appimage-hez jobban hasonlít.
Olyan beépített Windows-os megoldást viszont nem tudok mondani, ami hasonlítana a flatpakhoz.
-
-
-
urandom0
senior tag
A Red Hat nem kommercializálta a Linuxot, nem is volt célja. A Canonical volt ráálva erre a témára kb. 20 éven keresztül, de pár éve (sok milliárd EUR elégetése után) rájött, hogy ez nem fog működni. Azóta gyakorlatilag annyi az Ubuntu, hogy fognak egy Debian unstable-t, újraforgatják egy saját patch settel, aztán megbrandelik saját névvel, hátterekkel, egyebekkel és kiadják más néven. Nem mintha ez olyan rossz lenne, szerintem az Ubuntu azóta jó, amióta a Canonical csak minimálisan nyúl bele.
A fejlesztőcégek folyamatosan azon pörögnek, ha szóba kerül a Linux, hogy nehéz rá fejleszteni, mert semmi sem egységes. Se a disztrók, se a csomagformátumok, se az asztali környezetek, semmi. A flatpakkal kapcsolatos egyik várokozás az, hogy ezt a szétszórtságot kicsit összerakja, lesz egységes csomagformátum az appoknak, egységes store (legalább webes, ha asztali egyelőre nem is), és lesznek fizetős appok is, így az appfejlesztők majd nagyobb kedvvel fordulnak a Linux felé, ami elméletileg több és jobb minőségű appokat eredményez, ami több Linux usert, és így nagyobb piaci részesedést vonz be.
Majd meglátjuk, így lesz-e.Amúgy ez inkább Macesítés, mint Windowsosítás. A Flatpak a MacOS-féle .app formátumhoz hasonlít.
-
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ó? -
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. -
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ó. -
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. -
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?
-
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...
-
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.
-
-
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.
-
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.
-
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
-
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á. -
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.
-
#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).
Új hozzászólás Aktív témák
Hirdetés
- Elite: Dangerous
- bitpork: MOD Júni 28- Augusztus 2- szombat jelen állás szerint.
- OLED TV topic
- A OnePlus Nord 5 sem sokkal marad le akkuméretben
- Nintendo Switch
- Otthoni hálózat és internet megosztás
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Azonnali alaplapos kérdések órája
- A Windows 11 lett az úr az asztali PC-k piacán
- Nintendo Switch 2
- További aktív témák...
- MSI Cyborg 15 A13VF - 15.6"FHD 144Hz - i7-13620H - 16GB - 512GB - RTX 4060 - Win11 - 2,5 év garancia
- Epson Expression 12000 XL Nagyformátumú A3 szkenner
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- AKCIÓ! ASUS ROG Zephyrus GA403UV Gamer notebook - R9 8945HS 16GB RAM 1TB SSD RTX 4060 8GB WIN11
- NEC MultiSync V421 monitor (42") 1920 x1080px
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest