Vlákno názorů k článku
Ubuntu přestane nabízet Flatpak od Mintaka - Je to trochu ubíjející sledovat. Dřív se velcí hráči...

Je to trochu ubíjející sledovat.

Dřív se velcí hráči snažili o vendor lock na úrovni HW a návazně SW. Když už to s HW tak dobře nešlo, protože nastoupila, jakž takž, standardizace a modulárnost, snažili se o lock na úrovni OS a následných aplikací. Když to, také významnou měrou nešlo udržet, také díky GNU, OSS a dalším, tak se vymyslel koncept kdejakých uzavřených ekosystémů "Store/repozitářů aplikací".

"Krucipůsk", jsme tu společně na jedné hroudě kamení letící vesmírem, což takhle postoupit dál, od konceptu soupeření mezi korporáty a vložit tu energii raději do nepředstírané spolupráce.

vidis to jednak cerne a druhak zaslepene ;-)

autori nejake distribuce muzou (a casto maji) nejake specialnejsi pozadavky, ktere nejake zazita(nebo vznikajici) komponenta, nedokaze (ci nechce) splnit, tezko pak budou si narokovat pridani do upstreamu neceho co by chteli jen oni, nebo naopak to rozbijelo neco co si preji/kam smeruji puvodni/hlavni autori te komponety...

takze je pak logicke ze se bud udela fork, nebo neco na zelene louce, stejne tak je logicke ze casem (z jakychkoliv duvodu) se to muze zmenit a prejde se ne neco "mainstreamove" se zachozenim toho sveho (viz napr. Unity, Mir u Canonicalu)

u snapd kterej byl od pocatku zamyslen na server, IoT atd (ale tvurce Canonical ho mohl dle sveho upravit i pro Desktop aby si to sjednotil), by asi tezko se zahodilo a preslo na flatpak, kterej byl od pocatku zamyslen pro Desktop (a pokud vim stale neumi bez Desktopu fungovat, takze nepouzitelne pro server, IoT, atd)

Flatpak byl navržený jen pro desktopové aplikace, protože v době, kdy vznikal, už široce rozšířené řešení pro serverové aplikace existovalo - Docker. Plýtvat energii na soupeření se zavedeným řešením místo toho, abychom ji věnovali zaměření na to, pro co jsme to vytvářeli primárně - desktop, nedávalo smysl. A to mi trochu přijde, že je problém Snapu, snaží se to být řešením na všechno, ale na nic pořádně. Minimálně na desktopu to tak vypadá.
Jinak Flatpak je sice jen pro desktop, ale snaží se držet co nejblíž ostatním kontejnerovým technologiím. Nakonec dá se i zabalit a distribuovat ve formátu OCI kontejneru a používat tak stejné repozitáře jako Docker/Podman.

Pls, je mozme pomocou flatpacku mat viacero nezavyslych instancii tej istej aplikacie? Nieco ako ma Snap https://snapcraft.io/docs/parallel-installs ?

RE. Černě a zaslepeně:

Nevím, na kolik jsi se věnoval tématu multiplatformního nasazování aplikací, nebo jejich životnímu cyklu. Studoval jsem to, věnoval tomu část diplomové práce, od roku 1994 v pozici systémového administrátora pro několik společností to mám denně na talíři, učím o tom studenty.
Není to záruka, že to nevidím černě a zaslepeně, ale snad to z mé strany není jen hospodský žblept Neználka.

Nejsem zastáncem "jediného správného řešení", mám rád diverzitu, když přináší nové pohledy a nová řešení. Zároveň jsem přesvědčen o tom, že nás stojí obrovské prostředky, když vázne spolupráce, nebo když se někdo snaží na vydělat pomocí vendor lock. Ten vendor lock vidím spíš v Google Play, App store, Steamu, Epic store,... Problematickou spolupráci vidím v oblasti apt / deb / rpm / snap / flatpack / emerge / pacman / pip / brew / gem / zypper / ... (a dalších > 60 technologií nasazení SW). a to nemluvím o tom, že si kdejaký SW řeší aktualizace sebe a případných addonů, pluginů, modů po svém.

Autoři distribucí, nebo celých OS, mohou mít speciální požadavky, to ale neznamená, že by tu neměl být standardizovaný základ, protože většina procesu nasazení aplikace v nějakém systému je stále o stejných úkonech.
IMHO ani server vs desktop nejsou v tomhle natolik odlišné světy, aby potřebovaly dva různé standardy pro stejnou věc.

25. 2. 2023, 09:54 editováno autorem komentáře

Balíčkovací systémy – ono se to snadno řekne, ale provedení už není tak triviální. Dejme tomu, že bychom chtěli udělat nějaký společný základ. Vidím tu dvě možnosti:

a. Udělat nějaký standard, a k němu jednu implementaci. Tady řešíte, ve kterém jazyce to má být. Pro některé balíčkovací systémy byste asi neuspěl s ničím vyšším než C, případně možná Rust. Pro npm/pip/gem by to asi nějak šlo, ale muselo by tu být zatraceně dobře navržené API, aby do toho základu nepotřebovali vývojáři npm/pip/gem moc sahat.
b. Udělat nějaký standard, a k němu několik implementací v různých jazycích. Jednu v JS, jednu v C, jendu v Ruby, … Moment, tady už toho ale moc nešetříte, a ještě přidáváte overhead na vzájemnou domluvu – dejme tomu, že třeba vývojáři emerge budou chtít nějakou změnu kvůli use flags. Místo toho, aby si upravili svůj software, budou řešit schválení změn standardu s vývojáři, které use flags reálně nezajímají. Nakonec to použije Cargo, ale i tam ty use flags vypadají jinak.

Dále když dva dělají totéž, často to není totéž. Představte si třeba situaci, kdy se v dependency graphu objeví dvě různé verze téhož balíčku. Nainstalovat obě? Nainstalovat tu novější? Vyhlásit konflikt? Rozhodnout se podle toho, jak moc se liší čísla verzí? Nemáte tu jediné správné řešení. A obávám se, že takovýchto rozdílů při troše hledání najdeme mraky. Reálně by tak společného základu možná až tolik nebylo. Možná servery nabízející balíčky by mohly být někdy stejné.

A nakonec, co z toho? Ušetřená práce na vývoji balíčků? Asi moc ne. Větší vzájemná kompatibilita? Asi taky ne, ani třeba u deb nemůžete použít ten stejný balík pro Ubuntu a Debian, nebo pro různé verze distribuce. Jednotné rozhraní? Možná trochu, ale totéž můžeme mít i v současném situaci – vizte třeba PackageKit. Nemám pocit, že by získal nějakou velkou popularitu.

Tím neříkám, že by nějaký společný základ udělat nešel, nebo že by nic nepřinesl. Spíše se obávám, že náročnost je neúměrně vysoká vzhledem k přínosu.