Přispívat do GNOME nebylo nikdy jednodušší

Chcete začít přispívat do GNOME? První kroky jsou teď díky Builderu a Flatpaku výrazně jednodušší. Více v příspěvku Přispívat do GNOME nebylo nikdy jednodušší na blogu Jiřího Eischmanna.

12.4.2017 02:22 | Ladislav Hagara | Zajímavý článek

Komentáře

[Spitzbube]

Opravdu nechápu, co to zas vymýšlí za píčo*ny!

Propána, kdo potřebuje vlastní IDE? Úplě by stačil nějaký build systém a pak ať si člověk používá klidně VIM nebo EMACS!

Stejně je to se snahou protlačit vlastní balíčkovací systém, i když snad každé distro dnes nějaký (slušně fungující) má. Pak to dělá jenom bordel v systému, protože část aplikací je nainstalovaná pomocí systémového balíčkovacího systému a část pomocí toho jejich...

Kdyby se raději soustředili na něco užitečného a přestali takhle škodit!

[Kate]

Jojo, ./configure; make; make install pro aplikace co nenajdu v repozitáři bylo mnohem lepší a bordel nedělalo. Nebo snad chceš aby tvůrce nového programu balil pro všechny majoritní distribuce? Takhle je aspoň možnost vydat program ve formátu který se dá snadno nainstalovat všude, i když si ho zatím maintaineři distribucí nevšimli.

[smazáno]

> Nebo snad chceš aby tvůrce nového programu balil pro všechny majoritní distribuce?

To je prace pro distribuci - a ty s kvalitnim (=jednoduchym) balickovacim systemem to zvladaji v pohode.

Je to rozhodne mnohem mnohem lepsi situace nez kdyz ten progam nefunguje nikde. Ten vyblitek co vyjde z flatpaku muze povazovat za funkcni fakt jen totalni geek a to jeste castecne slepej - vychozi fonty a temata a vlastni freetype + nerespektovani systemovych certifikatu ani niceho - ne to opravdu neni funkcni aplikace ale mozna tak demo.

A pritom by to slo udelat i spravne, ale o to neni zajem - muj predpoklad je, ze cilem flatpaku je rozbit linux desktop aby na nej slo utocit i po zverejneny ruznych bezpecnostnich der.

[Petr Tomášek]

Nebo snad chceš aby tvůrce nového programu balil pro všechny majoritní distribuce?

Ano. Buď on, nebo tvůrce distribuce.

[Martin Tůma]

Nebo snad chceš aby tvůrce nového programu balil pro všechny majoritní distribuce?

Ano, jako uživatel si to přesně takto představuju. Bohužel v dnešní "Nové době" se aplikace již očividně nevyvíjí pro uživatele, ale pro programátory co je píší. Narážim na tuto filozofii dnes a denně, čím dál víc. Podpora jiných než bleeding edge systémů? Nezájem, nešlo by použít všechna ta krásná "nová kola", co jsou zrovna cool! Závyslosti na 365 obskurních balíčků/knihoven (samozřejmě mimo systémové repozitoře v CPANu, PIPu, NPM, ...)? Žádný problém! Hlavně, že vývojář nemusí napsat 20 řádků navíc. Uživatelé si buď poradí, nebo mají prostě smůlu, koho nějakej uživatel dneska zajímá?!

Přitom s dostupností systémů jako OBS se dá i to balíčkování dělat "pořádně" s prakticky stejnou námahou, jako výroba Flatpack balíčků. Jde jenom o to chtít...

[smazáno]

Haha, odpoved na stejnou otazku pod tim blogem "Kdo chtěl vyvíjet pro GNOME, musel si aktuální master sestavovat JHBuildem, který je výrazně nesystematičtější než Flatpak."

To jsou fakt patlalove - dulezitost ABI a API kompatibility se snad vysvetluje uz v prvnich kapitolach "zaciname s C". Hosi z gnome to nedokazi pochopit, tak si vytvori radeji vlastni balickovaci system, build system, IDE a kdo vi co jeste .

[smazáno]

Co si pomatuju, tak ani pitivi neslo zkompilovat z masteru bez toho jejich jhbuild ... v ten moment jsem pochopil proc na nem nikdo nedela a zahodil to :). A ne, opravdu se to nezmeni nejakym "IDE".

[smazáno]

A pro srovnani, vlastni gnome (+gtk, atk...) jde klidne zkompilovat primo na rhel6 s 8 let starym libc, freetype atd.

[smazáno]

Vlastne s tim freetype uz byl trochu problem - nejnovejsi harfbuzz potreboval verzi freetype 2.4.2 (2.3.11 v rhel6 nestacila) - ale i freetype 2.4.2 byl vydana pred 7 lety, ne mesici (a to i tech 7 mesicu by gnome stacilo aby rozbili jak ABI, tak API) ...

Propána, kdo potřebuje vlastní IDE? Úplě by stačil nějaký build systém a pak ať si člověk používá klidně VIM nebo EMACS!

Tenhle přístup je přesně ten důvod, proč GNU/Linux na desktopu téměř nikdo nepoužívá.

[Petr Tomášek]

Jo, jakože přestože existují desítky dobrých editorů a IDE, tak je pokaždé nutné pro každý cílový projekt vytvořit IDE nové a to prohlásit za oficiální? _TO_ je přesně ten důvod, proč to s GNU/Linuxem na desktopu jde do hajzlu...

Desítky dobrých IDE? Tak určitě. S GNU/Linuxem to na desktopu "do hajzlu" rozhodně nejde, naopak, v posledních letech vznikla řada skvělých desktop-oriented technologií a celkově začíná linuxový desktop tak nějak dospívat, což je samozřejmě proti srsti mnoha "oldschool linuxákům", kteří by i dnes nejraději používali archaický linuxový desktop z konce 90. let.

[Kimi]

Ty by sis mel na desktop nainstalovat android nebo mit desktop ve Flashi. Kdyz uvazujes takhle nainstaluj si Windows nebo Ma a neser Linux komunitu.

Lidi jako ty tomu systemu hodvno rozumi, jste jen hloupi klikaci, kdyz vam tlacitko po kliku nic neudela tak jste ztraceni. Linux byval o tom, ze mel clovek vsechno pod kontrolou. A ta kontrola se prave ztraci vsemi temi vrstvami balastu, kterym malokdo rozumi.

Butthurt much?

Mimochodem, pro tvou informaci, Linux používám od roku 2003 (Debian, následně Gentoo) a neřekl bych, že jsem "jen hloupý klikač".

[Petr Tomášek]

Jistěže ne. Soudě podle toho, jak se tu projevuješ, jsi hloupý i při jiných činnostech...

[clayman]

Nevidím nic špatnýho na tom, když chce někdo používat GUI pro nastavení systému. Naprostá většina distribucí stejně klikací není a že těch pár jde cestou vzájemné integrace dílčích komponent proto, aby se zvýšilo uživatelské pohodlí, to tobě může být naprosto buřt. Používej si svoje distro a nech lidem to jejich.

[Petr Tomášek]

Jistě, na tom nic špatnýho není (pokud je možnost to paraeleně nastavit i slušným způsobem např. přes příkazovou řádku). Nicméně problém je hlavně v tom, že spousta věcí už není možná nastavit vůbec, dokonce ani ne ručně přes potvory typu gconf.

[Petr Tomášek]

řada skvělých desktop-oriented technologií

Ale hovno. V posledních letech se desktop na Linuxu totálně zmrvil, jen se podívej třeba na GNOME 3, všechen vývoj je ovládanej několika pošahanými dogmaty a pokud s tím uživatel nesouhlasí, má smůlu, protože na uživatele a jeho potřeby a představy se naprosto sere.

KDE není o moc lepší...

[ika]

+1

[little.owl]

To je porad stale dokola - je to subjektivni hodnoceni a vsem vyhovet nelze.

[ika]

Že ta parta co protlačuje Gnome 3 na uživatele kašle není subjektivní pocit. To je fakt.

Subjektivní může být tak maximálně to, zda se někomu Gnome 3 líbí nebo ne. Mi se třeba líbí vzhledem, ale nejsem v něm schopen pracovat, takže používám dwm a jsem happy. P.S. Kecám, nelíbí, je hnusné jak fekál.

[little.owl]

Že ta parta co protlačuje Gnome 3 na uživatele kašle není subjektivní pocit. To je fakt.

K posouzeni pouzivate vami subjektivne vybrana kriteria a casto to byva postavene na falesne premise, ze vyvojar ma vuci neplaticimu uzivateli nejake zavazky. Uzivatel dostavate kod s licenci, ktera mu umoznuje si to upravit ci nechat upravit, a uz jen to fundamentalne popira vasi argumentaci.

[smazáno]

Ty mas fakt super pristup pri progamovani ... uzivatele? neplati? nasrat!

To chci taky! Cloveku pak fakt odpadne 90% stresu.

[ika]

Sociopatie. Samozřejmě má závazky. Obecně možná ne, ale v takovémto případě ano. Přečtěte si Malého prince.

[little.owl]

Obecně možná ne, ale v takovémto případě ano.

Proc zrovna v tomto pripade ano? Vyhoda FOSSu, pokud za nej vyvojari z pozice zamestnance nejsou placeni, je svoboda kterou vyvojari maji, a to zahrnuje nejen volbu co a jak implementovat, ale i moznost praci na projektu ukoncit. Pripadne dopady na uzivatele, ktere zacali produkt pouzivat, jsou vetsinove kompenzovany tim ze stavajici kod je k dispozici, nepsany kontrakt mezi uzivatelem a vyvojarem neni menen zpetne a pokud nekomu soucasna verze nestaci nebo chce dalsi vyvoj ci vyvoj jinym smerem, je na mem zacit tahat pilku. Plno programatoru omezi sve aktivity ve FOSS v okamziku kdy si treba poridi rodinu, coz je svym zpusobem prirozeny vyvoj a casto pak byvaji zastoupeni nekterym z uzivatelu, kteri maji zajem na pokracovani projektu a nebo projekt umre, a nebo se najde nekdo kdo je ochoten za vyvoj platit. Sociopatii zde budete velmi tezko zduvodnovat.

[ika]

Vývoj Gnome 3 není veden radostí ze svobody ale křiváckou motivací korporací a za korporátní prachy. Howgh

[Fluttershy, yay!]

Zrovna v GNOME se koncentrují lidé s vizí a posláním. Zvláště dyzajnéři.

[little.owl]

Ano, cast vyvojaru Gnome je placena Red Hat a Red Hat pak ma roli platiciho uzivatele, ktery ma vetsi vliv na smerovani projektu do nichz prispiva. Je to dobra symbiosa mezi FOSS a komercni firmou a jako neplatici uzivatel mam z investic Red Hat prospech a to nejen u Gnome.

ale křiváckou motivací korporací a za korporátní prachy.

A ted tu o zlych kapitalistech.

[božena]

Podobné plky jsem četla v té brožuře, ze které často cituje Rezza.

[Kimi]

Uplne ti rozumim. Jak by nestacilo ze uz python moduly, perl moduly a ruby moduly se instaluji extra a jsou s tim casto problemy (neco mam nainstalovane systemovym instalatorem neco pres gem/pip a upgrade interpretu rozbiji zavislosti).

Je to asi i tim ze vyvojar je kazdy nouma co umi trochu javascript nebo php. Zkuseni programatori postupne odchazi do duchodu. Proto dneska nativni app je javascriptova sracka se zabalenym chromem majici 200MB a trvale zrouci CPU jak kdysi Flash. :/

[Kate]

Och bože, pip a gemy… Jaká hrůza! Já si můžu nainstalovat python knihovny do userspace, nebo dokonce do jednoho virtualenvu v prostředí, mít jich na serveru víc verzí podle potřeby té které aplikace… A jde to snadno! Jaké to ničení svobody a linuxu.

Mimochodem, v package indexu je momentálně přes 105 000 balíčů. Hodně štěstí v jejich balení pro všechny distribuce, aby se to dalo dělat „čistě“.

[smazáno]

Hruza jsou vyvojari a admini co nechapou jake ma zavislost na pip, npm apod. negativni dusledky - proste to nejak rozchodime a jsme stastni, ze dokazeme, ze se to aspon nejak pusti. To ze to casto zpusobuje vic problemu nez resi ... to uz nikdo, radeji, nevidi.

Treba npm je vylozene odpadni tech, kde se ti dejou takovy srandy, ze treba presne specifikujes verze zavislosti a stejne se ti zmeni pod rukama.

A teda .. ona casto nefunguje sama ani ta instalace pres pip ze.

[Kate]

A jakou máš alternativu? Distribuční balíčky se často nehodí, takže balit si sama všechno co používám, hlídat si jestli je něco nového místo centralizovaného update virtualenvu… No, víš co. Já bych se celkem ráda věnovala i vývoji.

[smazáno]

Hodne by se mi libil pypi, ve kterem jsou pouze overene balicky - tzn. nemuze tam nahrat kdo chce co chce, ale balicky muze nahravat a updatovat pouze uzka skupina lidi, napr. z python foundation.

[xm]

WTF? To že si tam může nahrávat vývojář balíčky sám je největší výhoda PyPI (stejně jako je to obrovská výhoda AUR v Arch Linuxu).

Jistě, nějaký dodatečný způsob ověřování/kontroly by se také hodil (třeba něco jako Trusted Users a community repo v Arch Linuxu, ale dovedu si představit i jiné způsoby), nicméně základní princip, že balíčky tvoří a nahrává sám vývojář, je to nejdůležitější co se rozhodně nesmí změnit.

[smazáno]

Jasne ze ne jako nahrada PyPI ale s big fat warning, ze PyPI by se nemelo verit.

[smazáno]

To dnesni pouziti - napis "pip install xyz", nic neres, vsechno je super, je stejne spatne (ale na opacne strane toho spektra) jako pouzivat pouze balicky z distra a za zadnou cenu nic jineho.

[Kate]

Pokud někdo používá kleště k zatloukání hřebíků, je to jeho chyba. Ne chyba kleští. Například pro instalaci do systému by se tyhle package managery měly používat jen v případě naprosté nutnosti (kterou si moc představit nedovedu), ne při každé příležitosti. Naopak, to že mi moje webová aplikace při deploy rovnou zkontroluje svoje závislosti a aktualizuje si knihovny, i když v tu chvíli nemá rozhodně práva roota docela ocením :) Automatizovat to také není problém.

[smazáno]

Nechtel jsem tam ten virtualenv ani psat, vzdyt "pip install" primo do systemu vse akorat rozbije (jak pises). virtualenv je nutnost, ale problemy s tim, ze pak tvoje aplikace zavisi na kodu, ktery jsem nahral do PyPI treba ja a absolutne netusis co dela (krade hesla tvojich zakazniku?) ani ze na nem vlastne zavisi - nemluve o tom, ze tu stejnou verzi v PyPI muzu, iirc, prehravat tam a zpatky.

[Kate]

Virtualenv nebo instalace do home.

A z git repa té knihovny zjistíš jestli má nějaké bezpečnostní problémy? Když tu knihovnu najdeš v repozitáři, máš jistotu že ten kód někdo celý prošel? Je tedy lepší programovat vše úplně od nuly a nepoužít žádný framework, knihovnu, nic?

To nakolik dané aplikaci / knihovně důvěřuješ je ve výsledku jen na tobě. Pokud nějaký magor instaluje knihovnu co používá 5 lidí, vývojář do repa pushnul naposledy před 8 lety a svěří té knihovně přihlašování do své webové aplikace, je to jeho chyba. A stejně tak by ji mohl stáhnout z gitlabu.

[smazáno]

do home ti to asi chvilu fungovat bude - ale mas tam eventualne ten stejny problem, protoze python neumi resit konflikty verzi, bohuzel.

Na ten zbytek reagovat nebudu, z toho uz je jasne, ze ten problem chapes.

[trekker.dk]

Když tu knihovnu najdeš v repozitáři, máš jistotu že ten kód někdo celý prošel?

Přinejmenším mám jistotu, že když ho někdo projde a opraví tam nějaké chyby, tak aktualizuju tu knihovnu a mám vyřešené všechny aplikace, co ji používají. Narozdíl od různých flatpaků, sám-si-stáhnu řešených závislostí webových aplikací a spol.

Samozřejmě i to druhé je legitimní přístup - ani vývojář, ani uživatel softwaru zpravidla nenese žádnou odpovědnost za škody (typu DDoS z prostřelené děravé aplikace), které ten bordel způsobí, takže proč se namáhat.

[AsciiWolf]

Narozdíl od různých flatpaků

Většina Flatpak aplikací používá oficiální Runtimes, které jsou pravidelně aktualizovány.

[smazáno]

To uz fakt musi byt mysleno jako vtip ten flatpak :). Tohle tam preci zavadi ty problemy co maj s updatovanim knihoven distribuce (tzn. ten originalni problem, ktery chteli vyresit) a to jeste v horsi mire, protoze to nikdo nedokaze testovat jako celek. Zacina se mi to libit :).

[Kate]

Prostě, celé je to o tom, nepoužívat nástroj k čemu nebyl určen a jako blázen. Jenže za to opravdu nemůže nástroj.

[smazáno]

Ano, presne tak! Problem neni v tom ze nekdo vytvori pip a pypi nebo flatpak nebo docker. Problem je, ze se umyslne mlci o tom jake to zpusobuje problemy! A cela "komunita" kolem tech projektu krici "nase nove kleste jsou to nejlepsi na zatloukani hrebiku!".

Doufam, ze to za tohle neschytam jako Ian M.

[Kate]

Ale vždyť jo, můj problém byl hlavně s člověkem co všechno zavrhne s tím že je to k ničemu a zvěrstvo, přičemž ty technologie svůj smysl mají a mají potenciál usnadnit život. A jako si těžko budu stěžovat na nůž, že mě pořezal při otvírání konzervy, nebudu si stěžovat na balíčkovací nástroj, když ho použiju jak nemám a udělá mi nepořádek v systému.

Pokud jde o normální programy, beru priority – hlavní repozitář, AUR / neoficiální repo kterému věřím, flatpak (pokud by byl k dispozici). Pokud by šlo o proprietární software který bych z nějakého důvodu potřebovala, flatpak bych naopak považovala za pravděpodobně nejlepší možný způsob instalace. Už jen proto že mabízí nějaký sandboxing a bude menší šance, že se upgradem nějakých systémových knihoven rozsype program co potřebuji k práci :) Navíc je mi opravdu nevolno, když si stánhu program .run.sh, ze kterého na mě po spuštění vyskočí next->next instalační dialog. Děkuji, nechci. To mě raději zahrňte flatpaky.

[xm]

problemy s tim, ze pak tvoje aplikace zavisi na kodu, ktery jsem nahral do PyPI treba ja a absolutne netusis co dela

Vždy když používám nějaké balíčky třetí strany jako závislost svého projektu, vždycky si projdu jejich zdrojové kódy (pravda u opravdu velkých závislostí jen zběžně) a koukám i na to jak je projekt známý/používaný (prostě "prestiž" projektu). Takže to co píšeš rozhodně není pravda.

nemluve o tom, ze tu stejnou verzi v PyPI muzu, iirc, prehravat tam a zpatky

Jakmile jednou nahraješ do PyPI nějakou konkrétní verzi, už jí znovu přehrát nemůžeš. Jedině smazat a nahrát jinou verzi (s jiným číslem).

[smazáno]

A zavislosti zavislostí zavislostí taky kontrolujes? A v pripade napriklad requests i vsechny "nabundlovane" zavislosti kontrolujes proti jejich upstream verzi? A kontrolujes i zmeny pri kazdem updatu?

Tim ze to delas u PyPI zavislosti a u zavislosti z distra ne alespon docenis tu obrovsku vyhodu, ze to nekdo dela za tebe.

Jakmile jednou nahraješ do PyPI nějakou konkrétní verzi, už jí znovu přehrát nemůžeš. Jedině smazat a nahrát jinou verzi (s jiným číslem).

Pomatuju si ze s tim byly nejake problemy v "kerberos" balicku, ale detaily si uplne nepomatuju.

[smazáno]

Ten kerberos si tak nejak pomatuju, protoze jsem japkum radil jak to opravit ... protoze mely v PyPI nekolik mesicu uplne rozbitou verzi (kde verze-1) nekolik let fungovala. Aha?

[Kate]

Původní stížnost byla vůbec na existenci takových repozitářů, která svůj smysl rozhodně má a standardní repozitáře distribucí to prostě nahradit nemohou. S tvou výhradou souhlasím jen částečně. Asi by nebyl problém zavést flag „verified package“ který dostanou ověřené balíčky a přidat nastavení, které umožní limitovat instalaci jen na ně. Většinou ovšem stejně postupuji na základě popularity a kvalit balíčku. Pokud je to hojně využívaná věc s dobrou dokumentací a pravidelnými příspěvky, beru. Když je to minoritní balíček na který už nikdo nesáhl dva roky, jsem silně obezřetná (někde to ovšem vadit nemusí)

[Petr Tomášek]

Původní stížnost byla vůbec na existenci takových repozitářů, která svůj smysl rozhodně má a standardní repozitáře distribucí to prostě nahradit nemohou.

Ne, nemá, je to normální zhůvěřilost. Důsledek je totiž, že se vývojáři už naprosto přestanou snažit vytvářet/pomoci vytvářet balíčky pro jednotlivé distribuce a to je ZLO!

Místo toho, by se mělo dělat vše pro to, aby vytváření balíčků pro jednotlivé distribuce bylo co nejjednodušší (nástroje, kompilační farmy, atd.).

Nesystémové balíčky jsou zlo, protože jednak dělají v systému bordel a taky představují bezpečnostní riziko!

[xm]

Nemůžeš chtít po vývojáři, aby udržoval balíčky pro ty hromady existujících Linuxových distribucí. To je absolutně nereálný nesmysl. Maximálně ti tak udělají balíček pro distribuci kterou sami používají (a někteří třeba taky vůbec nepoužívají Linux).

Tohle je práce packagerů dané distribuce, jenže při množství existujících Python balíčků (či Ruby, Go, NodeJS, atd., doplň si dle libosti) je naprosto nereálné aby to stíhali. Dále pak také distribuce jsou často zamrzlé na starých verzích, kdežto vývojář chce, aby uživatelé používali primárně nejnovější verze.

[Kate]

A naopak. Pokud převedeš například starší webovou aplikaci na novější verzi serverového OS, mohou tam být knihovny v nových, s aplikací nekompatibilních verzích, i když jsou staré verze tvůrcem stále podporované. Pip a podobné nástroje umožní držet major verzi a updatovat jen minor bugfixy.

[Petr Tomášek]

Nemůžeš chtít po uživateli, aby si rozesíral systém nějakým podělaným rádoby-balíčkovacím systémem, když už má v základu systému jiný balíčkovací systém

Samozřejmě je to ale všechno o tom, že programátor nebude dělat nekompatibilní změny mezi verzemi, že nebude naschvál používat nejnovější píčoviny z knihoven, které nejsou vůbec nutné a že připraví zdrojové balíčky pro různé distribuce. I na to existují nástroje. Pak už stačí balíček překompilovat pro to konkrétní dané distro a je jedno, jestli distro je 7 let staré nebo právě vylezlo krávě z pod ocasu...

[Kate]

Takže až budu vyvíjet nějaký program, musím si nastudovat specifika balíčkovacích systémů všech majoritních distribucí, specifika jejich adresářové struktury a případné odklony od FHS, ubalit to pro ně, udržovat to proti novým knihovnám a dávat pozor na nově vycházející verze, ubalit desítky balíčků a ty udržovat a dělat jim podporu? Hele… A programovat mám kdy? Výhodu FlatPaku vidím hlavně u věcí, co se snadno do distribuce nedostanou, protože nemají tolik uživatelů. Instalaci z repozitáře stále beru jako prioritní. Rozhodně to nedělá nepořádek v systému už kvůli principu své funkce.

U Pip a podobných je pak výhoda jinde a standardní balíčkovací systém je nahradit nedovede už z principu, ale vysvětlovat to podesáté asi nemá smysl.

Mimochodem, zrovna v mé momentální práci python knihovny z repozitářů používáme. Máme totiž adminy, kteří nám udržují vlastní repozitář debianu. Jestli na to máš čas doma, závidím. Jestli to nepotřebuješ, asi v těch jazycích neprogramuješ.

[smazáno]

Jestli hodlas vysledek distrubovat jako FlatPak a zbytek te nezajima tak radeji neprogamuj.

[Kate]

Nehodlám, minimálně bych navíc vydala PKGBUILD v Auru, protože bych ho sama potřebovala. Všechno co teď dělám jsou ovšem soukromé webové projekty a jedna Android aplikace v Qt, kterou z principu nebude mít moc smysl provozovat a balit na desktopu (i když tam funguje).

Víš ale třeba kolik aplikací začalo jako repozitář na Sourceforge s návodem ./configure; make; make install, než si jich pro popularitu všimli maintaineři distribucí? Považuješ to za lepší způsob instalace a šíření aplikace než Flatpak? Jestli ano, tak promiň… Jsi blázen. O komerčních proprietárních aplikacích nemluvě, ty se do repozitářů často roubují dost špatně. Opravdu ocením když začnou vycházet ve flatpaku, který mi při „odinstalaci“ zaručí spolehlivý úklid všeho a nezanášení nepořádku do systému custom instalátorem.

[smazáno]

Rozhodne se na to nedivam jako "autoconf a nezajem" vs. "flatpak a nezajem" ... takova situace ani nikdy nebyla.

Co me stve je zamlcovani problemu, ktere flatpak/docker apod. zpusobuji!

[smazáno]

a teda co se tyka integrace tak flatpak je jedna velka regrese proti "./configure; make; mak install"

[little.owl]

V okamziku, kdy potrebujete sandboxing ci si nechcete system plevelit zavislostmi nebo upgradovat na jejich novejsi verze, tak ne.

[smazáno]

ano, je mozne dostat to do stavu, kdy to funguje stejne spatne jako flatpak, ale to je uplne mimo tuto debatu

[smazáno]

Jak uz jsem psal, ja jedu tenkou vrstvu nad autoconf (a jinymi build systemy), mam nejnovejsi aplikace na RHEL6 a integrace mi funguje - a to jsem si to cele postrojil jen pro sebe, funkcni integraci povazuju za samozrejmost.

[smazáno]

Sam si dam vic prace s integraci aplikaci mimo balickovaci system do sveho desktopoveho prostredi nez vyvojari FlatPaku a to je pouzivam jen sam pro sebe! V soucasne podobe je FlatPak na urovni nejakeho interniho demo - chodit s tim ven a rikat jak je to skvely a schvalne zamlcet, ze zpusobuje vic problemu nez resi - to jsou proste hovada. Chapu, ze nekdo nevidi, ze ma nastaveny jinak freetype a renderuje trosinku jinak fonty, ale ignorovat problemy s tim, ze se pouziva zcela jiny font, natoz temat - to uz je umyslne hovadstvi.

Nemluve o tom, ze FlatPak praci koncovym vyvojarum pridava, protoze pak musi roky a roky resit zname bezpecnosti diry ve vsech zavislostech svoji aplikace.

[Petr Tomášek]

Takže až budu vyvíjet nějaký program, musím si nastudovat specifika balíčkovacích systémů všech majoritních distribucí, specifika jejich adresářové struktury a případné odklony od FHS, ubalit to pro ně, udržovat to proti novým knihovnám a dávat pozor na nově vycházející verze, ubalit desítky balíčků a ty udržovat a dělat jim podporu?

A na to nejsou už hotové nástroje, které dokáží vygenerovat balíčky pro různé distribuce?

Rozhodně to nedělá nepořádek v systému už kvůli principu své funkce.

Tyjo, alespoň nám tu přestaň lhát do očí. Samozřejmě, že bordel v systému to dělá a jak! Když chci zjistit, co je např. nějaký soubor zač a ze kterého balíčku je, tak se to u takovýchto prasáckých balíčkovačů standardními nástroji distribuce nedovím. A o tom to celé je...

[Kate]

Jsou. Super. Takže třeba one man show projekt člověka který si jako hobby dělá aplikaci pro radioamatéry musí zahrnovat hlídání několika distribucí najednou a tak. Ten člověk se ti na to vykašle. Pokud se kolem projektu nabalí větší komunita, balit to nejspíš začnou sami, ale fakt je fajn když má možnost vydat program v nějakém univerzálním formátu, i kdyby jen na vyzkoušení.

Než mě začneš obviňovat z lhaní, zkus se alespoň podívat na to o čem diskutuješ. Flatpak nedělá nepořádek v systému už z toho principu, že neinstaluje soubory mezi ostatní systémové aplikace, ale používá sandboxové kontejnery v home. A hurá, umožňuje to dokonce instalovat aplikace lidem co nemají roota.

[Martin Tůma]

"Hlídat" distribuce by vůbec nemělo být potřeba. Ale to jsme zase u toho, jak a pro koho se vývoj vlastně dělá. Pokuď pro programátora samotného místo uživatelů, tak to potřeba dost často je. Pokuď se vývoj ale dělá pro uživatele a používají se pouze standardně dostupné komponenty, které nemění 3x do měsíce zpětně nekompatibilně API, nastane problém zcela výjmečně. U distribucí, co nemají rolling updates by pak z principu nastat neměl vůbec.

Samozřejmě, že i pokuď použijete tooly/služby (OBS), které většinu balíčkovací práce udělají za vás je potřeba něco o DEB/RPM nastudovat. To je ale u Flatpacku potřeba taky (i když méně), tak proč to nedělat rovnou pořádně a nutit uživateli 365. balíčkovací systém?

[Kate]

Studovat Deb, RPM, PKGBUILD, balit pro x distribucí v x verzích, pokud chci náhodou funkci třeba v Qt která ve verzi v Debianu není, odepsat Debian, i když z Flatpaku by to tam šlo... Já chápu že je ve většině případů lepší mít balík, ale stejně tak je potřeba koukat na to, že dokud si aplikace nevšimne distribuce, chceš po člověku který může být na to v té době sám a dělat něco ve volném čase netriviální práci navíc. Většinou to ubalí pro své distro a konec. Takhle to může balit pro své distro a k tomu pro všechny ostatní. Není to úplně hezké, ale funguje to a narozdíl od kompilace to neklade nároky na uživatele (a umí se aktualizovat, i když ne tak hezky jako nativní balíček)

Víš co. Pokud najdeš software který je pro tvou distribuci dostupný jen jako zdrojové kódy nebo Flatpak a vadí ti to, co takhle přiložit ruku k dílu a ubalit to sám, než abys autorovi diktoval co má ve svém volném čase dělat?

[Martin Tůma]

Studovat Deb, RPM, PKGBUILD, balit pro x distribucí v x verzích, pokud chci náhodou funkci třeba v Qt která ve verzi v Debianu není, odepsat Debian, i když z Flatpaku by to tam šlo...

A je to opět tady. Protože programátor CHCE použít nějakou hyper cool novou funkci, ukáže se prostředníček všem uživatelům jedné majoritní distribuce. Nebo se alespoň všem uživatelům této distribuce hodí klacky pod nohy v podobě nutnosti použít vlastní QT/nějakej Flatpack bazmek. Nová doba!

Já chápu že je ve většině případů lepší mít balík, ale stejně tak je potřeba koukat na to, že dokud si aplikace nevšimne distribuce, chceš po člověku který může být na to v té době sám a dělat něco ve volném čase netriviální práci navíc. Většinou to ubalí pro své distro a konec.

Problém je v tom, že ten balíček (nebo třeba instalátor na Windows) je nedílnou součástí kvalitně provedené "řemeslné práce". Není to něco "navíc" nebo něco "mimo", pro uživatele je to významná součást produktu, která klidně může zcela zničit výsledný dojem. Chci-li dělat kvalitní SW, musím ho i kvalitně zabalit (ostatně jako jakékoliv jiné zboží, ne nadarmo se říká, že "obal prodává"). A kvalitně znamená tak jak je uživatel zvyklý a tak jak mu to nejvíce vyhovuje. Což v případě linuxu je oprvdu málokdy Flatpack... Flatpack je prostě řemeslný zmetek, ojeb, nekvalitně provedená práce.

Víš co. Pokud najdeš software který je pro tvou distribuci dostupný jen jako zdrojové kódy nebo Flatpak a vadí ti to, co takhle přiložit ruku k dílu a ubalit to sám, než abys autorovi diktoval co má ve svém volném čase dělat?

Vtip je v tom, že mě zdrojové kódy nevadí. Pokuď jsou kvalitní a nepotřebuju pro skompilování shánět 365 obskurních knihoven, jsem ochoten si v těch pár vzácných případech, kdy ten SW není v mé distribuci ten balíček udělat sám. Je to pro mě asi stejně práce, jako instalovat nějakej Flatpack bazmek. A pokuď ta věc jednoduše skompilovat nejde, znamená to pro mě, že je to nekvalitní práce/produkt a nemá cenu s ním ztrácet čas. Ano, je možné, že výjmečně přijdu o nějaký zajímavý kus SW, ale jak už říkal Vincent Vega: "krysa z kanálu možná chutná jako jahody, ale to se nikdy nedozvim, protože jí neochutnám".

A když už jsme se dostali do osobní roviny, malá ukázka, proč si myslim, že SW takto kvalitně dělat lze i v "one man show" modelu.

[trekker.dk]

Flatpack je prostě řemeslný zmetek, ojeb, nekvalitně provedená práce.

Nemáte pocit, že jste právě popsal tu novou dobu a její de-facto standard? (Zejména, ale ne výlučně, co se vývoje a distribuce software týče.)

[AsciiWolf]

A když už jsme se dostali do osobní roviny, malá ukázka, proč si myslim, že SW takto kvalitně dělat lze i v "one man show" modelu.

Podpora pouze šesti distribucí a pro instalaci nutno otevřít terminál a přidat repo. To se mi nezdá být moc uživatelsky přivětivé. (Já osobně s tím samozřejmě problém nemám, nicméně se na to snažím pohlížet očima běžného uživatele, což mnoho "linuxových geeků" tak nějak nedokáže.)

[Martin Tůma]

Těch šest distribucí pokrývá majoritu linuxových instalací. A tam, kde balíčky dostupné nejsou je dostupný tarball, který se na 3 příkazy sestaví. Ano, jistě někde na světě existuje i BFU, co používá "Obscure Linux TM" ve vzácné verzi 6.8.2.3.5.1, který si s tím neporadí, ale ten by si s největší pravděpodobností neporadil ani s nutnou instalací Flatpacku...

Jinak samozřejmě není nutné otevírat terminál a přidávat repo, balíčky lze ze stránky i na jeden klik stáhnout a prakticky všechny podporované distribuce na to zareagují nabídkou instalace. Možnost přidat repo je nicméně preferovaná a to zejména proto, že umožňuje budoucí automatickou aktualizaci. A URL repozitoře lze samozřejmě zadat i do grafického rozhraní správce balíčků dané distribuce, příkazová řádka opravdu nutná není.

A konečně ad běžný uživatel - opravdu máte pocit, že vícero se duplikujících mechanismů na distribuci SW jsou pro něj výhoda? Že bude nadšený, že kromě balíčkovacího systému jeho distribuce bude muset řešit ještě dalších 5 takových systémů?! Nebo že ten běžný "one man show" vývojář co má hrozný problém si na OBS nechat vyrobit RPM/DEB si s radostí bude vyrábět Flatpack repo a ještě řešit, kde ho hostovat?!

[hypvofxy]

Možnost přidat repo je nicméně preferovaná a to zejména proto, že umožňuje budoucí automatickou aktualizaci.

Nektere balicky (treba *.deb s Google Chrome stazeny primo od Googlu) automaticky pridavaji repozitar, pokud jeste neexistuje.

[tomvec]

To řekl Jules Winnfield

[Martin Tůma]

Je to tak, došlo mi to hned jak jsem to "odeslal". Čekal jsem ale, že se někdo ozve dřív - všeobecný kulturní přehled zdá se dost upadá...

[Petr Tomášek]

Víš co. Pokud najdeš software který je pro tvou distribuci dostupný jen jako zdrojové kódy nebo Flatpak a vadí ti to, co takhle přiložit ruku k dílu a ubalit to sám, než abys autorovi diktoval co má ve svém volném čase dělat?

V takovém případě budu na daný software z vysoka srát a pokud ho budu skutečně potřebovat, napíšu si vlastní (bez sraček typu flatpack a připravené tak, aby se klasické balíčky daly jednoduše vyrobit pomocí make) nebo si to forknu a sračky typu flatpack z toho forku vymažu...

[Petr Tomášek]

Flatpak nedělá nepořádek v systému už z toho principu, že neinstaluje soubory mezi ostatní systémové aplikace, ale používá sandboxové kontejnery v home.

No, takže to dělá ještě větší bordel, protože normální člověk hledá aplikaci v (/usr)/bin, atd..

A hurá, umožňuje to dokonce instalovat aplikace lidem co nemají roota.

A tím se jako chlubíš??? Vždyť je hnus! Proč by někdo chtěl takovou blbost? Vždyť je to z bezpečnostního hlediska kravina, uživatel nemá co chtít co instalovat! (Stejně, normální lidi mají /home namountováno s noexec, stejně jako jakékoliv jiné místo, kam může uživatel zapisovat...)

[Petr Tomášek]

Takže třeba one man show projekt člověka který si jako hobby dělá aplikaci pro radioamatéry musí zahrnovat hlídání několika distribucí najednou a tak.

Tak tu aplikaci napiš tak, aby fungovala s 15 let starými knihovnami a máš po ptákách... Pokud to slušně uděláš, bez nějakých (zbytečných) serepetiček, bude ti to fungovat všude a pokud to uděláš skutečně čistě, tak tam bude i binární kompatibilita přes široké spektrum distribucí.