Názory k článku
Přímá podpora aplikací pro MS-DOS a Java v rámci KDE Plasma
-
Trosku offtopic, jsem jediny komu prijde divne, ze dnesni doba pouziva na vsechno ruzne kontejnery kde se duplikuji knihovny, data, atd. ? Flatpak, docker, atd. jen na to, aby clovek spustil nejakou aplikaci protoze je moc slozite mit v systemu nejakou rozumnou sadu kompatibilnich knihoven.
Prijde mi to jako reseni ze si zaplevelim dum bordelem a misto toho abych si uklidil postavim dalsi dum vedle.
Jako uplny bizar mi prijdou virtualy na spusteni nejake aplikace, ktera se stale jeste prodava, ale asi uz je pro prodejce nemozne/nerentabilni ji aktualizovat aby bezela treba treba pod novymi Windows (zdravim Xilinx, Alteru a Lattice).
-
Michal SmržStříbrný podporovatelCo je na tom divného, odpovídáte si sám. Aplikace sestavé k mému OS používají společné knihovny - desktop, základní nástroje... Aplikace třetích stran, co mají běžet "všude" pak jinou možnost něž nějakou tu vrstvu virtualizace - alespoň vlastní knihovny, mít musí. Ve Windows to tak je, i nejobyčenjější aplikace si tahá desítky dll včetně qt5 a nikoho to nepohoršuje. "Nějaká rozumná sada kompatibilních knihoven" se můžeme hádat do krve, co to je. Ale Flatpak má sdílené vrstvy, ty vrstvy jdou oznažit za "rozumnou sadu kompatibilních knihoven".
Nerentabilní je aktualizace jakékoliv aplikace, co je důkladně ozkoušená a otestovaná - musí se důkladně ozkoušet a otestovat znova a ještě udržovat víc verzí. Je li možnost hodit kompatibilitu na třetí stranu, pak ideál.
-
Aplikace třetích stran, co mají běžet "všude" pak jinou možnost něž nějakou tu vrstvu virtualizace - alespoň vlastní knihovny, mít musí.
To rozhodně nemusí. Mohou používat systémové knihovny, přičemž v repositářích jsou prakticky všechny další knihovny, které stačí jen doinstalovat. A pokud nejsou, tak si je ta appka může sama tahat s sebou v tom svém balíčku (nebo obecně lépe mít další balíček pouze s těmi potřebnými knihovnami).
-
To rozhodně nemusí. Mohou používat systémové knihovny, přičemž v repositářích jsou prakticky všechny další knihovny, které stačí jen doinstalovat.
A tím si často přivodit problémy navíc. Ač jsem to původně neplánoval, tak jsem se uvolil k tomu, aby Meshy bylo sestavitelné na posledním vydání Debian Stable, čímž jsem si ale uřízl věci z posledních několika vydání knihoven, které používám. U libadwaita musím kontrolovat, které widgety jsou ve verzi, která je v Debianu, a případně jejich absenci obcházet vlastní implementací v GTK.
A pak může člověk narazit na to, že některé závislosti jsou v určitých distribucích ve stavu, který není v souladu s upstreamem a tím, co vývojář očekává, protože to tak potřebují zase kvůli něčemu jinému (tady se zase kolega spálil s Boxes nad libvirtem v Arch Linuxu), nebo jsou tam pořád chyby, které jsou v upstreamu dávno opravené (ahoj, Ubuntu Universe!).
Tohle jsou prostě problémy, které ten vývojář nechce a nemá zapotřebí.
-
A tím si často přivodit problémy navíc.
Na tohle se evidentně neshodneme. Já jsem vždy považoval výhodu distribucí právě v tom, že je tam dlouhodobě stabilní prostředí, že (rozumné) knihovny mají nějaké sémantické verzování (a hlavně vývoj toto akceptující), takže jakýkoliv správně napsaný program tam poběží mnoho mnoho let. S tímto ohledem si ostatně (jako admin, ne desktopový uživatel) vždy vybírám programy do svého portfolia.
Pokud autor používá poslední cutting edge funkce některých knihoven (zrovna adwaita je 15 let stará, tak by mě, bez ironie, zajímalo, co je tam tak nové, že je potřeba to použít a okamžitě distribuovat), tak je to v mých očích právě on, kdo je zodpovědný za to, že mu to (ještě) nepojede. Mě celá (a to hodně let nazpět) diskuse spíše připomíná snahu tam naházet hodně klacků pod nohy jen proto, aby to nejelo. A toto je vlastně jeden z nich (použití verzí knihoven mimo distribuce).
-
zrovna adwaita je 15 let stará
Není, to si pleteš s Adwaita jako designovým jazykem a tématem pro GTK. Knihovna libadwaita vznikla v roce 2021 a probíhá v ní dost živý vývoj. Používat u knihovny, která má 5 let, několik let starou verzi je opravdu sakra omezující. Chápu, že pro někoho, kdo se pohybuje v serverovém prostředí, kde ta setrvačnost je mnohem větší, je tohle hůře pochopitelné. V desktopovém světě ti nikdo několik let na knihovnu čekat nebude a ani uživatelé už dnes nechtějí čekat rok dva na novou verzi aplikace, ale chtějí ji hned.
-
Ok, dík za upřesnění. No potom je ovšem ke zvážení, zda používat takto novou knihovnu, když to s sebou nese popsaná rizika.
Chápu, že pro někoho, kdo se pohybuje v serverovém prostředí, kde ta setrvačnost je mnohem větší
To je, ale já to nepovažuju za špatnou vlastnost toho prostředí. Když si vezmu ty roky hádek kolem balíčkování a nebalíčkování, tak si vždy vzpomenu na svou první instalaci Linuxu (1998) kdy jsem z časopisu Chip vzal buď SUSE nebo RHEL (vyšlo tam oboje), nainstaloval default desktop a byl tam GIMP, který je v balíčku i dnes. Prostě u některých programů to jde těch 30 let a u něčeho je jaksi stále problém.
Proto taky už 11 let používám FreeBSD, kde se mi líbí jejich přístup nejdřív přemýšlet a potom to udělat. I tak mám na serveru cutting edge verze všeho, co potřebuju, protože si to prostě zkompiluju z portů. Funguje to bez problémů, nevím přesně, jak toho docilují, protože kdejaká blbost si s sebou natahá hromadu sdílených knihoven (opět z portů) a ty fungují pro celý systém. Ještě jsem nenarazil na problém, že by něco chtělo verzi 2 a něco jiného verzi 1.
Ale to jsem odbočil. Podle mě autor čehokoliv na sebe bere tíhu rizika, jestli mu to někde pojede nebo ne. A i podle tohoto kritéria by měl zvážit, jaké nástroje k tomu použije. Přístup "tady je můj program a je mi jedno, jak to spustíte" se mi opravdu nelíbí a nepovažuji jej za profesionální.
-
Michal SmržStříbrný podporovatel
Ale jemu to není jedno. Proto přibalil potřebné knihovny a vy i tak nejste spokojen. A často raději ty knihovny s aplikací, než případy, kdy si musím nainstalovat desítky libs a libs-dev a python balíčků a venvů plných knihoven a do home/.local desítky věcí, abych spustil jednu aplikaci, pak se mi nelíbila, smazal jsem ji a ... už v životě neuklídím. V tomhle je bundlování či nějaké ty flatpak vrstvy naopak zlaté.
-
Proto přibalil potřebné knihovny a vy i tak nejste spokojen.
To já chápu, že je přibalil. Ale ta chyba je buď na straně distribuce (tedy že tam konkrétní knihovna není - pro což může být závažný důvod) a nebo na straně autora (který použil nějakou extra novou/divnou knihovnu).
A často raději ty knihovny s aplikací, než případy, kdy si musím nainstalovat desítky libs a libs-dev a python balíčků a venvů plných knihoven a do home/.local desítky věcí
Což může být docela rozumný předpoklad k tomu, že ten program dáte na blacklist a je to hotové.
V tomhle je bundlování či nějaké ty flatpak vrstvy naopak zlaté.
Jo, je to kontejner alias nádoba na odpadky. ;-)
-
To já chápu, že je přibalil. Ale ta chyba je buď na straně distribuce (tedy že tam konkrétní knihovna není - pro což může být závažný důvod) a nebo na straně autora (který použil nějakou extra novou/divnou knihovnu).
S tímhle by ten vývoj nikam nepokročil. Proč psát kolo když ho někdo napsal? Možná že jsem poznamenaný backendovým vývojem, ale prostě místo abych psal po Nté furt to samé co napsali lidé předemnou, raději se kouknu po knihovně a pokud je dle mého pohledu v pořádku (nějaká historie, počet stáhnutí, letmo projdu kód, testy, dokumentaci), napíšu raději gem/composer install/cargo add (vyberte si nástroj dle své preference).Ale abych se vrátil k desktopu a flatpacku -- autor fakt není maintainer distribucí. Autor píše kód. Patrně (u opensource převládá že ve svém volném čase) tak aby mu to fungovalo na jeho setupu a vyřešilo jeho problém. Autor tady fakt není od toho aby přemýšlel "ježiši na debianu to nebude fungovat protože je prehistorický. Ježiši na <vyberte si distro dle preferencí> to nebude fungovat protože tam je moc nová verze.
Proto třeba osobně kontejnerizaci vidím jako dobrý kompromis a hlavně elliminaci běžného "It works on my machine." -
"Proč psát kolo když ho někdo napsal? "
Jenze on to kolo vezme ... a dal se o to nezajima. Pokud vemu hranolek kterej je v distru a zakulatim si ho, tak holt budu muset neco pripsat, zato se o ten hranolek bude starat maintainer distra. Zatimco kdyz si pouziju nejaky kolo, tak bych se mel hotl starat i o to kolo, ale to autori-patlalove nedelaji.
"Patrně (u opensource převládá že ve svém volném čase) tak aby mu to fungovalo na jeho setupu a vyřešilo jeho problém. Autor tady fakt není od toho aby přemýšlel "ježiši na debianu to nebude fungovat protože je prehistorický. Ježiši na"
=== nikdo nikdy to nebude pouzivat. Jak proste. Presne proto se vsude pouzivaj ty widle. Protoze u nich jednak pisatel appky vi, ze dost pravdepodobne tam ten hranolek i za 30 let jeste bude a druhak, ze ho soudruzi z MS budou chte nechte nejak lepit. A vedi to i uzivatele/spravci.
Appek postavenych nad tuxem, kde nemuzu aktualizvat ani obstarozni sshcko mam pod spravnou nekolik ...
-
Možná že jsem poznamenaný backendovým vývojem, ale prostě místo abych psal po Nté furt t samé co napsali lidé předemnou, raději se kouknu po knihovně
Asi došlo k nepochopení. Já rozhodně neargumentuju proti knihovnám jako takovým. Ale ten autor přece nese odpovědnost za to, jaké knihovny si vybere a toto nemůže (neměl by), házet na někoho jiného. A pokud je ta knihovna tak extra dobrá, tak by se její autor zase měl postarat o distribuci. To k jejímu vývoji prostě patří. (Ono pokud bude opravdu tak extra dobrá, tak se o to postará určitě někdo jiný.)
autor fakt není maintainer distribucí
To není, ale to přece neznamená, že se může na vše vykašlat. Pokud je cílem autora to, aby jeho appku někdo používal, tak on by si měl vybrat takové prostředí, aby se to dalo snadno rozběhnout.
A tohle mi nepřijde vlastně nic proti autorům programů. Spíše naopak. Pokud autor ví, co má k disposici a může se na to spolehnout, tak o to snadněji se mu může programovat, protože už nemusí přemýšlet nad tím, co kde a odkud použije, protože vše už má v nabídce.
Mě prostě celá argumentace proti mě v (nejen) této diskusi přijde jako kdyby se podle vás mělo vyvíjet stylem, že všem je všechno jedno, ale musí to prostě běžet. Takto se nedá vytvářet stabilní prostředí a tohle jednání nefunguje nikde jinde v průmyslu. Stejně jako v průmyslu se všichni dodavatelé musí shodnout jaké šrouby a závity se budou používat, tak stejně tak u vývoje OS (a appky jsou nedílnou součástí díla) se prostě musejí dohodnout jak to budou dělat. A ano, někdo může argumentovat, že kontejnery jsou ta domluva, ale to potom rozhodně není nějaké špičkové technologické řešení, ale jen další krok stranou, jak se ten nepořádek alespoň nějak zakryje.
-
> Mě prostě celá argumentace proti mě v (nejen) této diskusi přijde jako kdyby se podle vás mělo vyvíjet stylem, že všem je všechno jedno, ale musí to prostě běžet. Takto se nedá vytvářet stabilní prostředí
Lenže stabilné prostredie nevytvoríš tak, že zadeklaruješ zmrznutie sveta v jednom okamihu a odteraz nafurt všetci musia používať tento zmrznutý svet.
Takto nejako totiž fungujú klasické distribúcie. Používateľ má dajme tomu ubuntu 22.04 lts, (ktoré už v roku 2022 obsahovalo balíčky z éry 2017-22) a teraz očakávame od ostatných, že sa tomuto prispôsobia a všetci sem skonvergujú. Nie, nebude to fungovať.
V iných systémoch máme SDK targety. Každý SDK target predstavuje nejakú sadu[1] knižníc v nejakých verziách (t.j. definované ABI), na ktoré môže aplikácia cieliť. Nová verzia sa môže prekrývať so starou, ale nemusí. A teraz pozor: nové releasy operačných systémov obsahujú nové targety (t.j. aj Windows 11 25H2 je iný target ako Windows 11 24H2). Jeden operačný systém ich môže obsahovať niekoľko.
No a v Linuxe sú presne flatpak runtimes implementáciou týchto SDK targetov. Vývojár môže cieliť na starší (pokiaľ udržuje nejakú staršiu aplikáciu), alebo na novší (pokiaľ potrebuje nové fičúry) a používateľovi pobežia obe aplikácie, každá v prostredí, čo očakáva. Áno, daňou za to je, že musí mať na disku runtime pre oba targety.
No a pokiaľ si niekto myslí, že "stačí", keď budú knižnice dodržiavať "správne" verzionovanie a "správne" sonames, a bude možné ich inštalovať paralelne vedľa seba z distribučných balíčkov, tak sa hlboko mýli. Jednak to autori knižníc nedodržiavajú (už len definícia čo je "správne" je vecou diskusie / názorov), jednak nejde len o knižnice, ale aj ich assety, formáty súborov a protokoly, ktorým sa bavia s okolitým svetom. No a nakoniec aj samotné distribúcie obsahujú často pravekú verziu knižnice a občas ešte ďalšiu, ešte staršiu verziu, ale backporty novších nerobia.
No a preto sa vrstvou, na ktorú cielia autori, stávaju kontajnerové runtime. Autori majú svoj baseline, na ktorý cielia a používatelia majú svoju obľúbenú distribúciu, ktorú používaju. Vadí to puristom, ktorí chcú mať presne jednu implementáciu nejakej funkčnosti a predstavujú si, že celý svet skonverguje na nimi vybranú sadu. To nikdy fungovať nebude, aspoň nie v "konfekčnej" sfére. Fungovať to môže v prísne zákazkovej implementácii -- za príslušné peniaze.
[1] **Sadu**. Nie povyberanej po jednej, a keď sa mi niečo nepozdáva, tak to odinštalujem a vo výsledku je každý jeden systém jedinečná snehová vločka. Naopak, autor sa môže spoľahnúť, že na systéme s daným targetom daná funkčnosť bude.
-
Tenhle problém řeší distribuce jako Guix nebo Nix. Oproti tradičním .deb/.rpm distribucím lépe podporují instalaci více verzí téže knihovny. Běžným uživatelům bych to asi zatím nedoporučoval, ale směr to je správný. Pak je splněno oboje - každá knihovna/verze je v systému instalovaná jen jednou a zároveň aplikace má přesně ty verze knihoven, které chce.
-
Obvykle bývají mezi prvními uživateli programátoři a pokročilí uživatelé, kteří snesou určitou míru nepohodlí a mají potřebné znalosti, aby si případné problémy dokázali vyřešit – běžně si kompilují software ze zdrojáků a experimentují s ním. Ty zdrojáky i čtou nebo upravují.
Přenášet tuhle experimentální fázi na běžné uživatele mi přijde nezodpovědné. Na první pohled to vypadá přívětivě, ale ten software je nezralý, má krátkou životnost, autor se na to vykašle nebo zase dojde k nějaké revoluci, musí se vše předělat, nové verze jsou nekompatibilní nebo v nich mizí funkce.
-
Možná by tomu desktopu neškodilo se inspirovat tím serverovým světem. Desktop GNU/Linuxu byl skvělý už někdy v dobách KDE 2 (pomalu čtvrt století zpátky). Z dnešního pohledu tam pár věcí chybělo, ale ty se mohly doplnit evoluční cestou. Jenže místo toho máme nekonečnou sérii revolucí.
Uživatelé nechtějí nejnovější verzi nějaké libadwaita. Uživatelé chtějí stabilní fungující systém.
-
Myslím, že mám dostatečný kontakt s velkým počtem uživatelů a nesouhlasím. Vývojáři ty nové verze knihoven nepoužívají jen tak z plezíru, ale protože mají vlastnosti, které uživatelé chtějí. Používám třeba novější verze knihovny libshumate, protože mají konečně podporu pro vektorové dlaždice. Když jsem používal rasterové, v jednom kuse si někdo stěžoval, že je to rozmazané a ošklivé, ale asi jsem jim měl místo nasazení novější verze knihovny vysvětlit, že si nemají na co stěžovat, protože to je přece ten skvělý a téměř dokonalý svět KDE 2. :)
-
Nerad jsem takhle negativní, ale ty máš zpětnou vazbu od uživatelů, kteří ti „zbyli“. Ale uživatelé, kteří na tu „permanentní revoluci“ nejsou zvědaví, s tebou ani nekomunikují. Ti prostě odešli – ne kvůli nějakým „vektorovým dlaždicím“ ale kvůli tomu, že jim nefungovaly základní věci.
6. 8. 2026, 11:37 editováno autorem komentáře
-
Meshy vzniklo před půl rokem, těžko od něj mohli uživatelé za tu krátkou dobu utéct kvůli permanentní revoluci. ;)
Jinak linuxový desktop právě teď roste na popularitě nejvíc v celé své historii, takže ta tvoje teorie o útěku uživatelů nemá moc oporu v empirii. Naopak kdyby nereagoval na neustále se měnící požadavky a vývoj světa kolem něj včetně hardwaru a chtěl se primárně zalíbil staromilcům, podle kterých desktop dosáhl dokonalosti v roce 2000 a vše potom jsou až na výjimky zbytečnosti, tak nemá dnes 5 %, ale tak 0,5 %. "Popularita" systémů, které mají toto v programu, budiž dostatečným důkazem.6. 8. 2026, 12:21 editováno autorem komentáře
-
Mluvím o GNU/Linuxovém desktopu obecně a ten „velký počet uživatelů“ jsem chápal v kontextu tvojí práce v červeném klobouku.
Windows mají obrovský náskok z historických důvodů, díky agresivní politice Microsoftu, různým dohodám s výrobci a prodejci o předinstalovaných Windows, díky síťovému efektu atd. jsou to věci na hraně morálky a zákona... To je jádro problému. Ale zároveň je potřeba si přiznat, že chyba je i na naší straně a že řada uživatelů, kteří zvažovali přechod na GNU/Linux na desktopu nebo jim s tím někdo i pomohl, tak to nakonec vzdají. Proto jsem psal o uživatelích, kteří „zbyli“.
To, že se čísla ve statistikách trochu zlepšují, je dané spíš tím, že Windows (a obecně proprietární software) jsou s každou verzí horší a horší a ty firmy se chovají k uživatelům čím dál tím hůř. Lidem pak dochází trpělivost a tlačí je to ke změně. Fakt to není tím, že se věci ve svobodném desktopu Xkrát zahodily a přepsaly a ta Xtá verze je už najednou dobrá.
-
ta Xtá verze je už najednou dobrá
Dobrá podle čeho? Chybná už je ta premisa, že tu existují nějaká objektivní a neměnná kritéria, podle kterých to jde hodnotit. Třeba po zvukovém serveru se před 25 lety chtěly jiné věci než dnes. Tehdejší zvukový server pro Linux třeba neuměl Bluetooth, dnešní ho umí. Znamená to, že ten starý zvukový server byl horší? Hodnoceno tehdejšími požadavky ne, protože tenkrát nikdo Bluetooth hardware neměl. Hodnoceno dnešními požadavky? Byl by naprosto nekonkurenceschopný, protože Bluetooth sluchátka už dnes má skoro každý.
Nový software nevzniká primárně kvůli tomu, aby lépe řešil staré problémy, ale aby řešil ty aktuální, s kterými stará řešení ani nepočítaly. Někdy se to dá ještě naroubovat na to staré řešení, někdy už to holt není z pohledu pracnosti vývoje a udržitelnosti praktické a vznikne něco nového.6. 8. 2026, 13:09 editováno autorem komentáře
-
"Třeba po zvukovém serveru se před 25 lety chtěly jiné věci než dnes. "
Fakt? A jake proboha .... uzivatel chce aby to zvukovalo. Jednoduse a bez toho aby musel cokoli kdekoli nastavovat a zkoumat.
BT sluchatka ma tisicina miliontiny promile uzivatelu.
Jestli neco uzivatele na win vytaci dobela, tak to jsou prave zmeny. A kdyz se podivaji na tuxe, tak zjistej, ze je to jeste horsi. Staci kdyz vemu buntu ... a kazda verze nejen vypada a se i chova uplne jinak ... to nikdo pri smyslech pouzivat proste nebude.
Kdyz sem naposled jedno domaci buntu aktualizoval ... tak sem stravil 2 hodiny zkoumanim, jak probuh dostanu na plochu tu JEDNU ikonu JEDNE aplikace kterou uzivatel pouziva ... protoze to ze bych to tam proste z toho naprosto nepouzitelneho nestrukturovanel ala widlebordelu proste pretah ... to ne.
Na tyhle planete neexistuje zadnej uzivatel, kterej by chtel prohledavat hromadu stovek obrazku a mezi nima hledal ten co chce, tohle vymejslej dmenti v distribucich a vyvojari (a MS ...).
-
BT sluchatka ma tisicina miliontiny promile uzivatelu.
Vám nevím, ale ve své soc bublině mám 1 (slovy: jednoho) známého co má kabelové sluchátka. Zbytek má bluetooth.a kazda verze nejen vypada a se i chova uplne jinak ... to nikdo pri smyslech pouzivat proste nebude.
Stačí se podívat na marketshare Apple/Windows/Linux ;-) Lidi nechtějí pracovat v prostředí které vypadá jak vystřižené z 90tek ;-) -
Tehdejší zvukový server pro Linux třeba neuměl Bluetooth, dnešní ho umí.
Skoro se bojím zeptat, abych se zase nedozvěděl nějakou hrůzu, ale co přesně musí zvukový server podporovat na BT a proč? Zvukový server pracuje se zvukovými zařízeními a je mu jedno, co to konkrétně je. Takže pokud se BT tváří jako normální zvukovka, tak s tím umí pracovat jako s jakoukoliv jinou zvukovkou. (BT sluchátka k desktopu jsem nikdy nepoužil, takže se reálně ptám.)
-
Ale BT sluchátka nejsou BT "zvukovka" (tj. pošlete PCM data a děj se vůle boží, zvukovka se s tím popasuje). Taková sluchátka podporují spoustu profilů, spoustu různých kodeků, spousty různých stavů. Zvukový server si musí dojednat správný profil a kodek do kterého samozřejmně musí kódovat, řešit různé stavy... Navíc ty profily a kodeky jdou přepínat "on-the-fly" podle různých potřeb.
-
Čo sa týka zvuku: pred 20 rokmi bola zvuková karta "statická" - buď v počítači bola, alebo nebola. Keď bola, tak v ňom bola počas celého behu programu. Dnes sú zvukové zariadenia (vrátane BT a USB) dynamické - môžu pribudnúť alebo zmiznúť počas behu programu, používateľ môže chcieť prehodiť výstup na zariadenie, ktoré pri štarte aplikácie nebolo pripojené. Dnešný BT má aj kontrolný kanál (párovanie, status -- používatelia chcú z nejakého dôvodu vidieť stav baterky, ovládať hlasitosť, noise cancellation, apod), a môže mať aj nejaké obmedzenia (BT má limitovaný bandwidth, takže používateľ môže mať buď dobrý zvuk jedným smerom -- na slúchadlá, alebo blbý zvuk oboma -- slúchadlá + mikrofón; lepšie implementácie dynamicky prepínajú, keď je mikrofón idle). Rovnako môže mať fičúry, ktoré hardware v minulosti nemal, napr. hw kodeky - BT zariadenie (a aj ďalšie zariadenia, napr. receiver v obývačke) vie deklarovať, aké kodeky a aké formáty vie dekódovať samostatne, tak pokiaľ server má zdroj v danom kodeku, tak robí len passthrough, nedekóduje ho, veď netreba. Slúchadlá, ktoré vedia AAC alebo receiver, ktorý vie EAC3 dekódujú presne ten stream, ktorý prišiel zo siete/disku, bez toho, aby bol niekde po ceste transcoding a aby sme všade posielali PCM.
-
Rovnako môže mať fičúry, ktoré hardware v minulosti nemal, napr. hw kodeky - BT zariadenie (a aj ďalšie zariadenia, napr. receiver v obývačke) vie deklarovať, aké kodeky a aké formáty vie dekódovať samostatne, tak pokiaľ server má zdroj v danom kodeku, tak robí len passthrough, nedekóduje ho, veď netreba. Slúchadlá, ktoré vedia AAC alebo receiver, ktorý vie EAC3 dekódujú presne ten stream, ktorý prišiel zo siete/disku, bez toho, aby bol niekde po ceste transcoding a aby sme všade posielali PCM.
Hmm, super. Ale dík za vysvětlení.
-
Pokud chceš posílat hudbu do sluchátek, tak ji musíš enkódovat do vykomunikovaného kodeku, parametry enkódování se můžou měnit i dynamicky podle síly signálu. Musíš umět přepínat profily. Normálně používat A2DP, ale když je potřeba, přepnout do HFP/HSP. To si dnes chtějí aplikace vyžádat přes API: pošloucháš hudbu, používá se kodek s nejkvalitnějším přenosem, který zvládnou obě strany, ale pak zapneš Google Meet a ten si přes prohlížeč požádá o přepnutí do HFP/HSP, v kterém se sníží bitrate odchozího streamu, aby v šířce pásma zůstala kapacita na stream z mikrofonu. Pak musíš řešit latenci, která je u drátových sluchátek konstaktní, ale u Bluetooth se neustále mění a zvukový server se tomu musí přizpůsobovat. Uživatel to chce kombinovat: sluchátka má Bluetooth, ale mikrofon napevno připojený a synchronizace musí být perfektní. A mohl bych pokračovat...
Good luck s používáním Bluetooth sluchátek a zvukového serveru, který tyhle věci vůbec neřeší a jen posílá zvukové streamy jako na klasickou zvukovku. -
Good luck s používáním Bluetooth sluchátek a zvukového serveru, který tyhle věci vůbec neřeší a jen posílá zvukové streamy jako na klasickou zvukovku.
No já jsem si tohle vyřešil už poměrně dávno nákupem Marantz + repro Bowers And Wilkins + sluchátka Beyerdynamics DT990 Pro + T70 + mikrofon Rode, takže tento "Good Luck" u mě ještě nikdy nenastal. Proto jsem se ptal zcela vážně. Takže už chápu, že BT je něco jako zcela komplexní zařízení v OS jen s tím rozdílem, že to ještě potřebuje poslat specifický signál a ještě navíc je to na zvuk.
-
Podpora Bluetooth je opravdu dost komplexní oblast a za tím, že si uživatel vezme sluchátka, jednou je spáruje a potom už mu to "just works" (vytáhne sluchátka, strčí je do uší a notebook se s nimi automaticky spojí a přesměruje na ně zvuk, může přes to vést hovory s mikrofonem ve sluchátkách atd), je fakt hodně práce, kterou musí zvukový server zvládnout.
Ale to byla jen odbočka od toho argumentu, že nový software primárně nevzniká proto, aby řešil staré problémy, ale aby řešil ty aktuální. PipeWire nevznikl proto, aby řešil problémy, které řešil OSS před 25 let, a že si Wim Taymans řekl, že to zvládne lépe, ale aby řešil ty aktuální jako podporu Bluetooth, které před 25 lety ani neexistovaly a tudíž je architektura tehdejších řešení pro jejich vyřešení často úplně nevhodná. To ale ani z jednoho nedělá lepší nebo horší řešení, prostě vznikaly v jiné době s jinými potřebami.
-
Upřímně, u něčeho tak komplexního je "just works" spíš zbožné přání. Tam je tolik věcí, co se může pokazit že tu a tam něco prostě nastane. Krásně se to kombinuje s moderním přístupem k UX, kdy je snaha uživatele za žádnou cenu neobtěžovat nějakými informacemi. Takže něco je blbě a pomůže akorát restart.
U mně stav "just works" nastal až když jsem ve stavu zoufalství výtáhl jackový kabel a celou tu komplexitu přemostil. Až pak jsem si uvědomil, že mi vlastně vůbec nic nechybí a přínos celé té složité bezdrátové technologie je zanedbatelný.
-
Jo, já Bluetooth nijak neobhajuju, je to komplexní věc a často hrozný bordel. Plno kodeků, některé z nich proprietární, každé zařízení se chová trochu jinak... Pamatuji se, že Wim z AOSP přebíral dlouhý seznam s pravidly pro konkrétní zařízení ("pokud identifikuješ BT zařízení XY, udělej toto a toto"), jen s dodržováním specifikací si člověk nevystačí. Není to bezchybné, ale v rámci možností to PipeWire zvládá dobře, určitě nejlépe ze všech zvukových serverů pro Linux.
-
Ale to byla jen odbočka od toho argumentu, že nový software primárně nevzniká proto, aby řešil staré problémy, ale aby řešil ty aktuální.
Jenže jsme se stále nedozvěděli, co konkrétně tak super přináší libadwaita a proč ji bylo nutné použít. Opravdu tady nechci grilovat tvůj program, jen jsem čekal, že napíšeš, které vlastnosti bylo nutné použít a které ve stávajících knihovnách nejsou.
Odbočka k BT navíc jde trochu mimo koleje. Pro programy se nic nemění, ty stále vysílají signál do zvukového serveru a ten si s tím potom nějak poradí. (Nehledě na fakt, že PipeWire rozhodně není první server, který BT umí.)
-
libadwaita je nadstavba nad GTK, poskytuje třeba řadu widgetů navíc (ty jsou na rozdíl od čistého GTK adaptabilní, takže se přizpůsobují malému displeji, aniž by pro to musel vývojář mnoho udělat, Meshy používá celkem dost lidí na mobilu). Nové widgety přibývají s každou verzí. Není to samozřejmě nic, bez čeho by ta aplikace nemohla existovat, ale pokud chce vývojář dosáhnout toho samého, tak potom tráví mnohem víc času tím, že to samé implementuje pomocí obecnějších prvků z GTK. Čistě z pohledu vývojáře neexistuje žádný důvod, proč je lepší používat několik let starou verzi libadwaity oproti nejnovější. Je to krvavý kompromis, aby to mohlo být v konzervativních distribucích. A když dnes mají jiné způsoby, jak dostat aplikaci k uživatelům, nedivím se, že ty kompromisy nechtějí dělat. Já je dělám, ale nadšený z toho nejsem. Je to práce navíc, která aplikaci nijak neposouvá, co se týče funkčnosti a kvality, spíš naopak. Když si ten widget dělám sám, spíš tam udělám nějakou chybu než člověk, který se na to zaměřuje.
To samé libshumate: uživatelé jsou dnes zvyklí na mapy, které jsou ostré v každém přiblížení. Starší verze vektorové dlaždice neumí. Ano, dá se to tam dohákovat. Je to hromada kódu a času navíc. Proč to dělat, když můžu použít nejnovější STABILNÍ verzi knihovny, která to umí? -
> Pro programy se nic nemění, ty stále vysílají signál do zvukového serveru a ten si s tím potom nějak poradí. (Nehledě na fakt, že PipeWire rozhodně není první server, který BT umí.)
Tak třeba:
* Možnost poslat komprimovaný zvuk, aby se nemusel dekódovat a následně znovu enkódovat.
* Kompromisy latence vs. kvalita apod. Jiné kodeky se hodí na akční hry (latence vadí), jiné na hudbu (latence moc nevadí).
* Synchronizace videa se zvukem – typicky zpoždění obrazu o latenci BT sluchátek.Jo, přijde mi to jako strašný bordel, kde za odměnu dostanu navíc potenciální bezpečnostní problémy bezdrátu a nutnost nabíjet. Ale uživatelé to holt chtějí…
-
Fakt to není tím, že se věci ve svobodném desktopu Xkrát zahodily a přepsaly a ta Xtá verze je už najednou dobrá.
S tím osobně nesouhlasím. Pro normální uživatele je důležitá bezpečnost, fancy grafika a přehlednost (UX). Bezpečnost se vylepšuje přepisováním na modernější protokoly za použití modernějších jazyků které předpokládají že na každém druhém rohu je bad-guy (např. Wayland vs. X) a programátoři jsou tvorové omylní, fancy grafika a přehlednost s tím že to je s dobou. V roce 2000 bylo úplně jiné ovládání počítače, UX možná tak tlačil komerční svět ale OS aplikacím stačilo že to má uživatel v 20 levelu menu (nebo ještě hůř v konzoli).
Běžní lidé od počítače a programů dnes neočekávají složitou věc ke které musejí nastudovat 20 manuálů, ale něco co pochopí hned jak k tomu sednou.tak to nakonec vzdají
Ano, což je do jisté míry dle mého způsobené tím že dřív se o UX a libovolném WM(pro běžného uživatele není Linux kernel nebo distro, ale to co vidí a v čem pracuje) fakt mluvit nemohlo :-) -
Tak Flatpack je například určité řešení neřešitelného problému s distribucí binárek pro všechny možné a nemožné distribuce GNU/Linuxu bez nutnosti balíčkovat pro každou distribuci zvlášť.
Ad Docker. No nevím, jak jinak bych jakž takž pohodlně distribuoval serverovou aplikaci založenou na node.js se stovkami závislostí a dodržel zcela přesné verze všech závislostí.
-
Ondřej KolínZlatý podporovatel
Pozor tady se resi jenom balickovani (Flapak bez C), ale ono to ma jeste jeden aspekt. A to je sandboxing a prace s nim.
Specialne pokud najednou zacnete rychle tahat balicky od zdroje (zdravi do AURu) - chcete se branit pred nejakymi potencialnimi utoky.
-
Michal SmržStříbrný podporovatel
Má to i nevýhodu, např. Code ve Flatpak se snaží snaží některé rozšíření sandboxovat a padá na hubu, protože sandboxování nejde vrstvit. run --no-bubblewrap není možný.
-
Ondřej KolínZlatý podporovatel
Je to tak. Tluce se to napr. se standardnim sandboxingem v Chrome apod. Ale to uz se nejak musi mezi sebou dohodnout jak to vyresi. Pokud vim, tak se to aktivne resi (moznost presunout NS i do techto sandboxu) - coz prechod na Flatpak v2 o kterem se ted mluvi (nebo ktery si nekteri preji) by mohl vyresit.
-
Michal ŠmucrStříbrný podporovatel
Ale prd ;)
Většina těch flatpaků s sebou zdaleka nenese všechny své závislosti (není to portable AppImage nebo něco podobného, což je častý omyl při srovnávání).
Není k tomu důvod, pokud ty knihovny existují v runtimech z Flathubu, které jen přidáš do manifestu jako závislosti. Ty runtimy pak v sobě obsahují většinu důležitých knihoven. Od nějakých crypto věcí jako openssl, gnutls, NSS, co jsou součástí org.freedesktop.Platform, přes GUI knihovny a frameworky, multimediální knihovny ve svých runtimech.. atd. Stejně jako je tam třeba Python, nebo různé verze OpenJDK v tzv. SDK extensions.
Ty runtimy mají svou deklarovanou dobu podpory a v ní normálně dostávají aktualizace, jako běžná distribuce.Takže automaticky neplatí to, že flatpak znamená automaticky staré knihovny. Také ty flatpaky neznamenají to, že je to tam všechno duplicitně (jakože 10 aplikací, co používá stejný OpenJDK JRE, tam bude mít 10 krát to samé JRE).
-
"automaticky neplatí to, že flatpak znamená automaticky staré knihovny. Také ty flatpaky neznamenají to, že je to tam všechno duplicitně "
jo, neni nad to se obcas podivat na realitu ze?
Realita je takova, ze kazdy jeden balik (nejen flatpack) OBSAHUJE JINE verze TYHZ knihoven. A samozrejme ze nikdo na tyhle planete neni schopen udrzovat aktualni ani desitky, natoz stovky ruznych zavislosti. A ani to delat nechce a nebude.
Prozmenu tvurci tech knihoven (a treba i jadra) nejsou ochotni drzet jakoukoli kompatabilitu api/abi ... a presne k tomuhle to pak vede.
Ono totiz tech 10 aplikaci nebude mit stejne jre, ona bude mit kazda jinou verzi.
-
Michal ŠmucrStříbrný podporovatel
Paušalizující nesmysl.. sorry.
To, které runtimy se sdílí mezi flatpaky, se samozřejmě může každý podívat přímo v systému. Navíc každý program na Flathubu má u sebe odkaz na manifest, s kterého je sestavený, tam je to samozřejmě taky vidět.
Do každého nainstalovaného flatpaku se také dá normálně dostat, projít /app/lib, spustit ldd atp., ujistit se, odkud kterou knihovnu bere atp.> Realita je takova, ze kazdy jeden balik (nejen flatpack) OBSAHUJE JINE verze TYHZ knihoven.
Really..?> A samozrejme ze nikdo na tyhle planete neni schopen udrzovat aktualni ani desitky, natoz stovky ruznych zavislosti. A ani to delat nechce a nebude.
Přesně tak, a protože jsou vývojáři obecně docela líní, tak pokud vyloženě nemusí (neříkám, že k tomu občas není objektivní důvod), tak co jde vzít z těch runtime, o které se stará někdo jiný, tak také použíjí.. :)
Protože proč by se trápili sestavováním vlastních knihoven, řešili mulitplatformní build skripty, bundlovali to tam, když to můžou dynamicky linkovat na sdílené knihovny (úplně analogicky jako když dělají balíček v jakékoliv jiné distribuci).> Ono totiz tech 10 aplikaci nebude mit stejne jre, ona bude mit kazda jinou verzi.
To je nějaký Murphyho zákon?
Znovu, když se podívám do distribuce, tak taky většina balíčků, co vyžaduje JRE se odkáže na odpovídající balíček v systémovém repozitáři.. tohle je analogické, primárně použiju to, co mám k dispozici na Flathubu. -
Mít přehled o závislostech, zvlášť v prostředí, kde jsou potřeba audity a compliance, má svoji hodnotu a ty kontejnerové a bundlovací technologie to určitě znesnadňují. To je objektivní fakt.
Ale vždycky žasnu nad tím, když někdo označí flatpak za nebezpečný a často používá aplikace třeba z Universe nebo AURu, které jsou bídně udržované a mají automaticky přístup ke všemu, k čemu má uživatel práva, a má pocit, že to je bezpečné, protože to používá systémové knihovny. Přitom na Flathubu člověk musí projít review, které je přísnější než ve většině distribucí, musí tam obhajovat, proč má mít aplikace vůbec přístup k souborům uživatele a nemůže to dělat přes kontrolovaný přístup přes portál. Kde vám klidně již přijatou aplikaci zablokují, pokud neplní nové požadavky.
A to jen kvůli tomu, že to může bundlovat závislosti; byť většinou nerizikové, protože ty rizikové jako krypto knihovny už jsou zpravidla v runtimu. A na tom Flathubu vám taky nedovolí bundlovat cokoliv. Čím rizikovější komponenta to je, tím těžší je si to v review obhájit.
-
"zvlášť v prostředí, kde jsou potřeba audity a compliance"
"a má pocit, že to je bezpečné, protože to používá systémové knihovny."
Bych tak nejak rek, ze mixujes zcela nesouvisejici veci. Pokud resim compliance, tak jednak mam treba nejaky konkretni distro protoze ma nejaky konkretni vlastnosti a nejaky konkretni pristup k aktualizacim. A druhak resim zcela konkretni aplikace, a rozhodne nikdo nikde nema "nejake libovolne cosi odkudsi".
-
Pracoval jsem v runznych firmach na ruznych pozicich a musim priznat, ze my sysadmini jsme nekdy neskutecny k*k*ti. Dostat aplikaci na produkcni server v korporatu je nekdy oser. Docker, K8S, ... a dalsi jsou technologie jsou reakci sveta vyvojaru na tuhle situaci. Serverless tuhle prekazku obchazi a konecne mame zpusob jak nainstalovat aplikaci do produkce bez toho aby nekdo nekde skemral o prava.
To same Flatpak, drive Linuxove distribuce zjednodusovaly castu aplikace od vyvojare k uzivateli. Dnes naopak mohou tu cestu blokokovat. Je snazsi vystavit Flatpack na Internetu nez zadat o prijeti aplikace do distribuce. Nehlede na to jaky je dodnes bordel v nazvech ruznych klihoven mezi jednotlivymi distribucemi.
O te doby co jsou storage a pamet levne, je to nejsnazsi cesta pro vyvojare.
5. 8. 2026, 15:00 editováno autorem komentáře
-
Je snazsi vystavit Flatpack na Internetu nez zadat o prijeti aplikace do distribuce.
Hlavně autor aplikace chce pracovat především na samotné aplikaci, ne místo toho řešit všechny možné distribuce a formáty. Třeba u Meshy mám k dispozici flatpak: je to formát, který může uživatel jednoduše nainstalovat na 99 % distribucí. Komu to nevyhovuje, může si to sestavit ze zdrojáků, zabalit pro libovolnou distribuci. Když za mnou došel packager z Debianu, že potřebuje udělat některé změny, aby se mu to líp pro Debian balilo, rád jsem je udělal, ale ač jsem Fedora ambassador, tak ani pro Fedoru sám balíčky nedělám, protože jak s tím člověk začne, tak se budou ozývat lidi, abych dělal balíčky pro další a další distribuce a tím fakt čas trávit nechci.
-
Co se tyce tech "organu" tak zatim nejvetsi zhuverilosti byly od programatoru a deploy zdrzovaly procesy.
Posledni kdo dopatla appku do neinstalovatelne zhuverilosti je sysadmin. Cekejte spis deva.Totiz casto programatorske kreativni lizatko po vyvoji na konci netusi kde vsude se appka rozleze. Fajn mame kontejner. Ale toto kreativni bordelareni nezna hranic a tak pokracuje v network flows. Kdy soucasti instalace je ptani tu a onde na to ci ono. A nejde vsude srv autodiscovery. A ne vsude se za horami pravidel je mozne doptat. A predpoklad ze prod bude mit treba stejna uuid ci nazvy jako dev je mylny.
A pak se s ti lejnem od devu sysadmin stejne drbe a musi to prebalit / ohackovat skripty / doplnit parametrizaci (plus rici devops at si aktualizuji pipeline).6. 8. 2026, 10:49 editováno autorem komentáře
-
Budu reagovat pod sebe, zajimave komentare ve stromu nad timto postem.
Vetsina je o reseni real-world problemu, hlavne z komerce. To je validni problem, ale rekl bych, ze se resi na spatnem miste. Flikujete myslim jednu chybu (ve strukture korporatu/firmy) jinou.
Ja jsem ale miril spis z pohledu meho sveta na uziti kontejnerizace na desktopu nekoho, kdo timto neni svazan. Dobra myslenka jsou ty revoluce misto evoluci, to je myslim jadro problemu. Nekdo se rozmysli, ze je fajn neco udelat jinak, prida funkci. Nekdo dalsi ma jeste lepsi napad a zase neco zmeni. Pritom obvykle oba napady jsou casto nekoncepcni. Tohle vidim jako velkou nevyhodu open-source - centralne rizeny projekt, je-li v jeho cele dostatecne silny a kompetentni "architekt", muze mit z tohohle pohledu daleko lepsi vysledky. Budu ukamenovan, ale prvotni navrh Win32 API (jeste toho 16bit) nebyl s ohledem na tehdejsi moznosti az tak spatny. To same NT kernel, je hrozne slozity (ve srovnani s POSIXem/Unixy), ale veci tam maji hlavu a patu.
-
decenkBronzový podporovatel
Velmi zajímavá diskuze pánové. Jako linuxový uživatel a pamětník, toho času na Mint 22.3 jsem si instaloval malý prográmek Warpinator. Měl jsem na výběr buď distribuční balíček 13 MB, nebo flatpak verzi 809 MB - požadované místo na úložišti 2,7 GB.
Já chápu argumenty vývojářů, ale přeci jen mi to přijde jako overkill. Za chvíli nám k tomu budou přibalovat celý operační systém ;-) -
Asi to nechapu. JRE/SDK ci dosbox mi snad stahne dnf/apt/whatever jako zavislost. A vysledek ma launcher. Zrovna ta java porebuje nastavit classpath a kdo vi co jeste. Pochybuju ze to za me udela.
Pokud je to z webu, vetsinou to ma secko ssebou. Pokud je to jen polotovar co ma launcher, ale nema jre/sdk/dosbox tak je to na dodavatli sw to poradit?
-
Taky úplně nechápu, co je tak převratného na wrapperu. V nadpisu je "přímá podpora", což je vysloveně nesmysl, když to údajně nedělá nic jiného, než že to stáhne JRE/Dosbox tak, jak by to udělal každý gramotný uživatel. Jediný rozdíl je, že to aspoň podle zprávičky sviní systém flatpakem i když ho používat nechci...
-
Asi tak. JDK nainstaluji jako distribuční balíček a když chci pak použít jinou verzi, než jakou jsem si zvolil jako výchozí, tak na to mám jednoduchou funkci v shellu:
_jdk() { export PATH="$1/bin:$PATH"; export JAVA_HOME="$1"; } jdk-graalvm-21() { _jdk ~/opt/graalvm-community-openjdk-21.0.2+13.1; } jdk-8() { _jdk /usr/lib/jvm/java-8-openjdk-amd64/; } jdk-11() { _jdk /usr/lib/jvm/java-11-openjdk-amd64/; } jdk-17() { _jdk /usr/lib/jvm/java-17-openjdk-amd64/; } jdk-25() { _jdk /usr/lib/jvm/java-25-openjdk-amd64/; }V případě potřeby se do toho dá přidat i přepínání verze Mavenu, Antu nebo jiných nástrojů.
ČLÁNKY DO MAILU