Vlákno názorů k článku RPM, DEB, anebo něco zcela jiného – pár slov k nadcházející linuxové ®evoluci od bez_přezdívky - Základní problém vidím ve stylu vývoje - perou...

Základní problém vidím ve stylu vývoje - perou se tu dvě skupiny - tvůrci „knihoven“ a tvůrci „aplikací“. V uvozovkách je to proto, že teď nemyslím jen .so a spustitelnou binárku.

Aplikace, ty ať se vyvíjí, mění přidávají funkcionalitu, přeskládávají UI a cokoliv... A knihovny... Ty se musí vyvíjet taky. Ale s podstatně větším ohledem na ty aplikace. S ohledem na zachování zpětné kompatibility a dlouhodobou podporu. Pokud se ve své aplikaci potřebuji vázat na konkrétní verzi knihovny (a nemůžu jít k novější), tak je to špatně (teď nemyslím přechod typu kernel 2.2 -> 2.4 -> 2.6, GTK2->GTK3 atd, tam je to jasně dané).

Druhou stránkou věci je to, že aplikace dosáhly takové komplexity, že je strašně těžké udržet je funkční. Vývojáři pak nemají na to zkoušet ještě různé verze knihoven.

To vše nastoluje pár otázek - chceme takové aplikace, které vlastně fungují jen náhodou a jejich funkcionalita není jednoduše replikovatelná? Neměli bychom se zabývat i udržitelností vývoje - nejen s ohledem na svoji knihovnu, ale s ohledem na ty, kteří ji budou používat ve svých aplikacích? Flatpak, Snap i Appimage může mít své opodstatnění, ale takhle mi to přijde jen jako vytloukání klínu klínem, rovnák na vohejbák a ... Prostě jen zavírání očí nad skutečným problémem.

Tady někdo rád svítí petrolejkou místo aby si vzal moderní baterku která stojí hned vedle :)

Akorat ta baterka ma kazdy tyden jine ovladani, jine napajeni a jine vlastnosti svetla.
Typicky frikulinsti junior develove tohle nechapou stabilizaci u velkych projektu. I vyvojar by mel vybirat knihovnu podle stability rozhrani.
Zazil jsem ale ultrakonzervativni pristup u solarisu nebo prvnich debianu kde to bylo ke skode projektu. Baliky i 10-15 let stare :-P

1. 8. 2025, 12:56 editováno autorem komentáře

A proto se u mnoha projektů po letech rolling-release vývoje začínají zase objevovat LTS verze. Že...

Od baterky čekám, že bude svítit vždy, když potřebuji. A ne, ze pokaždé budu muset nainstalovat zcela jiné baterky a k nim hledat kompatibilní žárovku. V takovém případě je ta petrolejka stabilně funkční řešení. Kupodivu. (A taky, 95% lidí si neumí představit situaci, kdy je petrolejka prostě lepší řešení, než cokoliv elektrického. Přesto takové situace existují.)

Ale o tomto není příspěvek, na který reaguješ. Jsi ve své reakci zcela mimo mísu. Není to o tom co chci používat (baterka versus petrolejka), ale o tom, že vývojáři by měli myslet nejen na fíčury, ale i na stabilitu. Je super, že libKnihovna-2.3.4.so umí SqělouFíčuru, ale k čemu mi je, pokud zásadně rozbije kompatibilitu s verzí 2.3.3 a ve verzi 2.3.6 o půl roku později je tato fíčura zase odstraněna. Pak raději jako vývojář zůstanu na řadě 1.13, která je sice stará, ale mám jistotu, že s ní moje aplikace poběží i když někdo náhodou vydá opravnou verzi.

U baterky, co vam bude rok stat na polici se take muze stat, ze vam neposviti, kdyz ji zrovna budete fakt potrebovat... :D

Druhou stránkou věci je to, že aplikace dosáhly takové komplexity, že je strašně těžké udržet je funkční. Vývojáři pak nemají na to zkoušet ještě různé verze knihoven.

Jestli je vůbec o něco takového zájem. Hádám, že předplatné softwaru nese víc, než jednorázový prodej.

Navíc bohužel linuxový desktop ani Mac nemají stabilní ABI a udělat program, co funguje několik desítek let beze změny prakticky nejde :-/