Új hozzászólás Aktív témák

• bambano titán

  #124

  #118 urandom0

  2024-12-08 19:19:56

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bambano

  titán

  #118 urandom0

  #118 urandom0

  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.

  "Ezt értem az alatt, hogy a flatpak nekem stabil, fix, kiszámítható API-t ad.": na mégegyszer: NEM a flatpak adja a stabil apit. a flatpak, nevezzük most egyszerűen, egy konténer formátum, amibe konkrét fixált verziójú libeket raknak és attól lesz stabil az api.

  Tehát a fejlesztés úgy zajlik, hogy összeválogatod a libeket, lefordítod velük a programodat, *választasz* egy csomagformátumot és becsomagolod. Miért választod a flatpaket, miért nem választod mondjuk az rpm-et? semmi nem akadályoz meg téged abban, hogy rpm-et (vagy deb-et) válassz, a hype miatt választod a flatpaket.

  É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.

  "Igen, csak nincs minden disztróban dpkg": hát legyen. 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.

  Az is a kond, hogy igen gyakran kiderül, hogy egy rendszer túltervezett. Mindenáron bele akarják erőltetni a legújabb technológiákat, fancy cuccokat, ha kell, ha nem. Én dolgoztam isp-nél, amikor indult a szolgáltatás, minden nagy cég tolakodott, hogy az ő cuccát használjuk, meg hozták a prezentációikat, meg a rendszerterveiket. Én meg röhögve kihajítottam mindet, és töredékéből megcsináltam jól. Jártam úgy másik melómban, hogy nem tudtam elejét venni a túltervezésnek, baj is volt belőle folyamatosan.

  "Ezzel szemben flatpaknál az van, hogy tudom, hogy milyen verzió van a org.gnome.Platform 47-es verziójában": é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? É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.

  Az opensuse, az arch, a fedora, a debian *NEM GYÁRT* libeket. Tehát neked nem disztróhoz kell megnézni a függőségeket, hanem lib verziószámhoz. ugyanolyan verziószámú lib *MINDEN* disztrón ugyanazt az apit nyújtja. 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. debianban például beleírod a kontroll fájlba, hogy melyik lib milyen határok közé eső verziószámú kiadásával működik a programod, oszt jónapot.

  Ha én fejlesztő lennék, három választási lehetőségem lenne:
  1. minden disztróra lefordítom
  2. megtanulom a flatpaket
  3. megtanulom egyszer és mindenkorra, hogy hogyan kell normálisan fordítani a programot, hogy mindenhol működjön

  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.

  Ilyen architekturális meg stratégiai kérdésekben redhatesnek lenni eléggé komoly anti-ajánló. Ugye arról a redhatról beszélünk, akik elbarmolták a gcc-t, anno, akik erőltették pöcsteringet, akiknek nem volt jó a deb, kellett az rpm, stb? ha a redhat anno elfogadja a deb-et, ami egyébként anno kilométerekkel jobb volt bárminél, nem véletlenül másolja azóta is mindenki, akkor most töredék ennyi csomagolási probléma sem lenne a linux világban.

  "Szerintem ő több programot csomagolt be, mint amennyivel mi egy év alatt találkozunk.": ezt ugye elég nehéz megítélni, mivel itt mindenki anonim. Másrészt ha az lesz az indoklás, hogy ő többet csomagolt be, mint én, akkor nagyon hamar elő fogom venni a légy meg a tehénoutput esetét.

Új hozzászólás Aktív témák