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

• #118 urandom0 őstag bambano #116

  Új Válasz 2024-12-08 18:35:22 #118

  Ú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

  Privát üzenet küldése

  

  urandom0

  őstag

  LOGOUT blog (1)

  válasz bambano #116 üzenetére

  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.

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