Hirdetés
- Brogyi: CTEK akkumulátor töltő és másolatai
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- gban: Ingyen kellene, de tegnapra
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Luck Dragon: Asszociációs játék. :)
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- koxx: A bajnokok egere? Lamzu Maya Champions Edition 8K gamer egér
- ldave: New Game Blitz - 2025
Új hozzászólás Aktív témák
-
DarkByte
addikt
Nehéz ez után komolyan venni amiket írsz, hogy még mindig nem volt meg ezen a ponton hogy a Flatpak hozza magával a libc-t. Pedig annyiszor írtam én is a Docker-t hasonlatnak, ott is ez történik.
Egyébként továbbra sem értem, hogy neked miért ennyire valagfájásod ez a Flatpak téma, amikor látszólag te a szerver vonal jövőjét félted, pedig ott nem is akar versenyezni, mert GUI alkalmazások terjesztésére van kitalálva.
Szerver oldalt a Docker-re kellene orrolnod amiért már bő egy évtizede ugyanezt csinálja.
(és azóta se semmisült meg a világ) Jó, oké, ott általában az alap image-ekben benne van a kicsontozott OS image csomagkezelője továbbra is, de ez nem törvényszerű, lehet akár egyetlen nagy statikus bináris is a konténerben. (meg glibc helyet musl libc, vagy akár a binfmt_misc-et kihasználva valami teljesen más architektúrához tartozó dolgok) -
DarkByte
addikt
válasz
Kisgépkezelő
#168
üzenetére
Azért lehet próbálkozni az értelmes vitával. Bár a többség lehet bontja a sátorfáját és.. csomagol.

-
DarkByte
addikt
válasz
Kisgépkezelő
#123
üzenetére
Én pont a Bottles-t próbáltam ki Flatpak alatt nemrég. Egy régebbi CD iso-s játékot akartam beüzemelni, a CDemu-s emuláció azért megtréfált a Flatpak sandbox-olásával, de Flatseal-el meg sikerült oldani hogy lássa amit kell, és gyönyörűen ment utána. Kimondottan örültem hogy a kísérletezéssel nem a host gépet kellett szétbarmolni, így bármikor eldózerolhattam és újrakezdhettem.
-
DarkByte
addikt
Egyébként a Flatpak ad API-t. Portal API.
-
DarkByte
addikt
válasz
urandom0
#113
üzenetére
Windows-on csakugyan nincs, de ez szerintem leginkább OS limitáció.
Tudtommal elég sok minden nincs meg az alkalmazás szintű ilyen szintű szeparációhoz.Pl. Video/audio server alternatívának kb. csak az RDP van.
Igaz azzal is vannak mókás lehetőségek, pl. FreeRDP képes csak egy-egy Windows alkalmazást az ablakaival áthozni Linux-os window session-be a teljes desktop távoli elérése nélkül. (a WinApps nevű cucc használja pl. aktívan)Ami létezik és legközelebb van filozófiában az talán a PortableApps és a self executable programok.
Elvetemültebb lenne, de úgy tudom Wine-t jó sok szenvedés árán le lehet fordítani Windows-ra is, és azzal már lehet namespace-eket csinálni. Régi játékokhoz egyébként gondoltam már erre, csak ennyire nem vagyok elvetemült

Viszont a Flatpak WSL2-ben működik már egy ideje. Persze megint kérdéses mi értelme van, ha WSL2 distro-ból annyit hozol létre a gépre, amennyire szükséged van.
-
DarkByte
addikt
Ezzel nem tudok vitatkozni, tény hogy borzasztó fragmentált a Linux.
Ha hirtelen a világ eldöntené, hogy mostantól akkor csak Debian-al és deb-el megyünk tovább, akkor az egész Flatpak-esdi értelmét vesztené, de amíg ilyen nem történik (és valljuk be, ennek sokkal nagyobb az esélye, pont az általad leírt dolgok miatt) addig a Flatpak is elfér a futottak még kategóriában.(Egyébként én nem érzem akkora nagy technológia wasistdas-nak a Flatpak-et, hogy őszinte legyek. Nem néztem jobban utána de tippre ez is az cgroup, namespacing és társait használja a kernel-ben, amúgy meg lényegében a layer-ezett fájlrendszer, mint amit a Docker is csinál. Kb. a portal-ok rész az ami kicsit kreatívabb.
Inkább a felismerés hogy így is lehet terjeszteni alkalmazásokat, találkozva azzal hogy van sok kezdő/lusta/sandbox-ot preferáló user akinek ez valós igénye.
Ahogy nézem kb. 10 fős kis csapat viszi. Ennyi ember a Debian jobbá vagy rosszabbá tétele szempontjából nem zavar vizet.)
-
DarkByte
addikt
Szerintem itt kicsit elbeszélünk egymás mellett. A Flatpak nem céloz kiszolgálókat. Arra ott a Docker és alternatívái, nem is volna értelme versenyezniük. Tisztán végfelhasználói, ott is leginkább grafikus alkalmazások terjesztésére kitalált dolog.
Végfelhasználói Linux Windows-osításában értettem úgy hogy a Canonical előrehaladott az Ubuntu-val. (egyébként ők is tolják a Snap-ot, ami a Flatpak saját megfelelője)
Nem tudom beleférek-e a gyűjtődbe. Linux-on/ra fejlesztek, de az is igaz hogy az leginkább Java, kisebb részt shell és automatizáció. Van itthon homeserver Proxmox-al (Debian, Home Assistant), Raspberry-k, Microtik router, saját laptopon Arch KDE-vel, desktop-on Win11-en WSL2, stb.
A Red Hat-ot mondjuk én nem bírom, a ló túloldala. A fizetős support-jukhoz volt közöm a Keycloak kapcsán és ritka undorító az a több rétegű subscription wall mögé pakolása az információknak amit csinálnak. De ugyanezekért nem a szívem csücske az Oracle sem

Kár hogy már nehéz ennyire átszellemült lenni a szakma után egy ideje, kicsit kiölte belőlem a meló mókuskereke azt a fiatal lelkesedést.
-
DarkByte
addikt
Nem látom hogy attól hogy a Flatpak létezik neked mitől lett rosszabb a Debian-od.
A Flatpak amúgy sem használható az OS rendszeralkalmazások terjesztésére, egy alap környezetnek futnia kell ami felett el lehet az ilyen programokat indítani. Szóval a klasszikus csomagkezelők ugyanúgy kellenek továbbra is.
Maximum azt érheti el az törekvés, hogy a rendszer csomagkezelője rejtettebb szintre lesz pakolva pár distro-ban, eldugva az avatatlan szemek elől. (az immutable OS ezt tkp. meg is valósítja, a SteamOS kiváló példa, átlag Józsi ne tudja tönkre tenni ha nem ért hozzá, de amúgy még azt is fel lehet oldani ha kell)
Kb. úgy tekintek a Flatpak-re mint Android-on a Play Shop-ra, vagy Windows-on a Steam-re vagy a Chocolatey-re. Egy plusz alkalmazás terjesztési csatorna.
Én személy szerint üdvözlöm hogy a Linux-on egyre több lehetőség van.
Az elit önző hozzáállással nem tudok mit kezdeni.Nem kötelező használni. Közelébe nem kell menned, ha nem akarod. Docker helyett is lehet deploy-olni szerverre a mai napig a klasszikus módon, vagy virtuális gépet futtatni, vagy amit akarsz. Pedig volt egy időszak amikor a microservice folyt a csapból is.
Biztos vagyok benne hogy amíg létezni fog Linux lesz legalább egy olyan distro amelyik továbbra is a klasszikus csomagkezelést fogja preferálni elsődlegesként.
A Linux kommerszé tételével próbálkozás amúgy se újdonság, a Canonical ezt próbálja elérni már idestova 20 éve.
-
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. -
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.
Új hozzászólás Aktív témák
- TCL LCD és LED TV-k
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Félmillió felett a kiszállított Xiaomi autók száma
- ASUS routerek
- OLED TV topic
- Revolut
- Le Mans Ultimate
- Linux kezdőknek
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- Brogyi: CTEK akkumulátor töltő és másolatai
- További aktív témák...
- AKCIÓ! ASUS ROG G16 (2025) G615LR 16 - Ultra 9 275HX 32GB DDR5 1TB SSD RTX 5070Ti 12GB WIN11
- BESZÁMÍTÁS! Asus H370 i7 8700 16GB DDR4 512GB SSD RTX 2060 Super 8GB Zalman S2 TG Cooler Master 650W
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD RX 6600XT 8GB DeepCool CC560 Thermaltake 730W
- Honor 200 Lite / 8/256GB / Kártyafüggetlen / 12HÓ Garancia
- Honor 400 Lite / 8/256GB / Kártyafüggetlen / 12Hó Garancia
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
(és azóta se semmisült meg a világ) Jó, oké, ott általában az alap image-ekben benne van a kicsontozott OS image csomagkezelője továbbra is, de ez nem törvényszerű, lehet akár egyetlen nagy statikus bináris is a konténerben. (meg glibc helyet musl libc, vagy akár a binfmt_misc-et kihasználva valami teljesen más architektúrához tartozó dolgok)


