- Több tucat gyorsító összeköthetőségét kínálja az Instinct MI400 sorozat
- Imádja az alteregókat az új AMD Software
- Csak úgy szórja a dollár milliárdokat adatközpontokra az Amazon
- Mexikó tisztázta a Google-t a monopóliummal kapcsolatos vádak alól
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Kormányok / autós szimulátorok topikja
- Hobby elektronika
- Milyen billentyűzetet vegyek?
- Amlogic S905, S912 processzoros készülékek
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- OLED TV topic
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- TCL LCD és LED TV-k
- Külső merevlemezek - USB, eSATA, FireWire HDD
- Apple MacBook
Új hozzászólás Aktív témák
-
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
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.
-
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) -
Nem gondolod, hogy ennél azért már tovább jár a történet? 2024-et írunk, nem 1984-et. Haladni kéne a korral.
A windows meg egy rémálom, fusson ámokot máshol.
Elnézve az Linux ~4% körüli asztali részesedését, amit 30 (!) év alatt össze tudott hozni... hát annyira nagyon nem rémálom a Windows hozzá képest. Pont ezaz, hogy a Linuxot kellene versenyképessé tenni. -
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. -
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
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. -
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
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. -
-
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.)
-
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.
-
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.
-
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ó? -
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. -
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
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
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...
-
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...
-
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.
).
Új hozzászólás Aktív témák
Hirdetés
- ALIENWARE Area-51 R6 Threadripper Edition 1920X
- 118 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 9 7945HX, RTX 4070 - UK billentyűzet
- BESZÁMÍTÁS! Asus M5A99FX PRO R2.0 990FX chipset alaplap garanciával hibátlan működéssel
- Lenovo ThinkPad dokkolók: USB-C 40A9/ 40AY/ 40AS/ Thunderbolt 3 40AC/ Hybrid USB-C DisplayLink 40AF
- AKCIÓ! VALVE INDEX virtuális valóság szemüveg garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest