Doted jsem mel v Mintu DEB balicky. Neco ze zdroju distribuce, obcas mela aplikace vlastni repozitar.
Neni to na 100% skvely system, ale funguje.
Nyni budu mit krome DEB balicku jeste Flatpak, Snap, Modularity, AppImage. Za par dni mozna pribyde neco dalsiho.
Takze kazdy s techo systemu si bude sam resit aktualizace a vsechno kolem toho. Jako na windows, kde mi ve spravci uloh trvale bezi firefox/chrome/adobe/... updater.
Nejsem uplnym zastancem systemd, ale alespon prinesl sjednoceni, takze ve vysledku jde o pozitivni zmenu oproti starym init skriptum.
Proc ale potrebujeme flatpak/snap/...? Nestacil by jeden? Prdpokladam, ze tvurce aplikace si vybere jeden a ja, jako uzivatel budu mit 10 techto systemu.
Proc by taky tvurce aplikace tvoril "balicek" pro 10 techto systemu? To uz by vyslo nastejne, kdyby udelal nyni deb/rpm pro 10 nejpouzivanejsich distribuci.
A i do toho deb balicku mohl zabalit binarni knihovny a celou aplikaci mit treba v /opt.
Nejvetsi vyhodu vidim v sandboxu, ale tim to pomalu konci :-(
Problem s Cannonicalom je ten, ze
1) tvori technologie preto, aby ich "vlastnil". Mir vznikol kvoli ocakavaniu konzultacneho biznisu pre Cannonical s vyrobcami zariadeni. Snap ma centralizovany store, aby zabetonoval Cannonical ako prostrednika.
2) pouzivaju pristup, ze treba nieco rychlo vytvorit, je to sice nedomyslene, ale cakaju, ze ako prvi obsadia trh a vsetko sa casom nejako vyriesi. Vid napr. riesenie dependencies v upstart, alebo izolacia v Snap.
Kombinacia tychto dvoch faktorov sposobuje, ze nakoniec ich riesenie je slepa ulicka, ktora iba fragmentuje prostredie a pribrzduje jeho rozvoj.
Podotýkám že ty updatery některých SW ve Windows jsou zavedené po přihlášení uživatele, ale není to nijak náročné na zdroje. Samotný executable je jen memory-mapped file, a navíc naprostou většinu času jen čeká na timer. Takže když je tam RAM potřeba, tak jí prostě použije jiná aplikace. Teprve když pingne timer, tak se těch pár stránek paměti může dotáhnout z původní binárky, případně ze swapu.
Windows ale mají vestavěný Task Scheduler. Někteří výrobci ho používají, a jiní z nějakého důvodu ne. Asi jde buď o setrvačnost, nebo se snažili o kompatibilitu s Windows XP, které měly jen starší verzi API (která neuměla například spustit task při přihlášení, po zápisu správného eventu do event logu apod.).