Názory k článku Firefox na Waylandu: proč ho chtít a jaké má výhody?
-
Ondra Satai NekolaZlatý podporovatelVšimni si, že tvůj komentář je ve své podstatě hluboce politický ;-)
Ale k pochvale článku se mohu jen připojit.
-
Já Wayland zkouším pravidelně s aktualizacemi na Manjaro KDE a není to zatím pro stabilní použití není (a to mám pouze Intel integrovanou grafiku). Seká se to, špatně funguje scalling atp. Mám tedy kompozitor Weston, tak asi zkusím nějaký jiný. To je ale podle mě dost problém, měl jsem dojem, že to mělo být univerzální řešení a když do google dáte "wayland compositors" tak první co vyskočí je "20 Best Wayland compositors as of 2019 - Slant". Zase tedy 100x nesmyslně duplikovaná práce spousty lidí a uživatel musí zbytečně vybírat něco u čeho to, aspoň dle mě, nemá smysl (něco jiného je třeba prostředí KDE, Gnome...)
-
-
null null (neregistrovaný)
@Fuki Fuki
Já pořádně čítal. Když pominu nějakou nespecifikovanou "většinu", tak některé zásadní věci zdá se jsou dané rozhraním Waylandu, nikdo s nimi nepočítal a budou se muset nějak přibastlit oproti původní koncepci. Dále několik věcí, jako ty kompozitory, Wayland vůbec neřeší, takže je to vlastně k ničemu a to že má být na řeklo by se "exotických" zařízeních daleko lepší než X11 je trochu zkalené tím že ještě právě nepřibastlili všechno co je potřeba a už teď se to ohýbá jak bambus ve vichřici ... Já tomu právě moc nerozumím, proto se snažím něčeho dobrat, protože pořád čtu Wayland Wayland a tady čtu že většinu věcí ani zatím neřeší a z toho co řeší se muselo kdeco naohýbat ....
28. 11. 2019, 11:36 editováno autorem komentáře
-
Wayland byl od začátku navržený jako rozšířitelný protokol. Od začátku byl plán zahrnout do samotného Waylandu pouze ten společný základ a rozšiřovat to pomocí tzv. Wayland protokolů o funkce, které vyžadují jednotlivé platformy. Kompozitor v mobilním zařízení tak může implementovat relativně jednoduchý protokol a nemusí vůbec řešit věci, které jsou relevantní pouze na desktopu.
-
Navyse bol rieseny nielen ako rozsiritelny (to bol aj X11), ale aj aby mal minimalnu povinnu funkcnost, ktoru musia vsetci implementovat. Jednym z cielov bolo vyhnut sa tomu, co sa stalo s X11, kde je cely kresliaci model zodpovedajuci hw z 1980 povinne v core a kazdy, kto dnes udrzuje X11 server ho musi udrziavat tiez, aj ked ho ziadna aplikacia nikdy nepouzije.
Takze vyhodenim rozsirenia sa da zbavit kodu, ktory uz nie je aktualny.
-
null null (neregistrovaný)
@Jiří Eischmann
Promiňte, vím že do toho vidíte více než já, ale toto je taková omáčka - "rozšiřitelný protokol", "společný základ" a klasické "může si kdo chce implementovat" .... to jsou takové idály, nic proti, ale právě jsem si v článku přečetl že to krom aplikací kterým je to šumák celé, (takže asi bylo i na X?), je to v praktickém užití další, byť jiná, sada celkem netriviálních problémů - netvrdím že přímo s Waylandem, ale prostě pokud hlavní problém leží v těch kompozitorech, tak toho pak zase moc neřeší, krom toho že jsou tam zas i na tom základu dané problémy, jaky ty hierarchie a kdoví co ... to je to na co jsem se vlastně ptal, protože mě to celkem zarazilo oproti tomu že Wauland měl být jakási revoluce - aspoň z pohledu mého odněkud z hlediště ...
28. 11. 2019, 16:38 editováno autorem komentáře
-
null null (neregistrovaný)
@Martin Stransky
Když vydrží ok, proč ne, ale to je to kritérium? Nevím. Já měl z těch věčných hype okolo Wayland jako pozorovatel pocit že se buduje něco jednoduššího co "elegantně" bude řešit problémy X11 ... a teď se dozvídám že začíná trpět kdečím úplně stejně .... a pokud je to většíně aplikací jedno, proč je pak potřeba to měnit?
V článku je napsané že je to výhodné pro menší zařízení, ok, no ale zatím to vypadá že to neplatí tak úplně protože zatím se ukazuje že bude potřeba kde co změnit a naohýbat?Nevím, možná je to jen můj pocit, tak se ptám ....
-
Tak to hype je trochu nestastne protoze asi slibuje neco co neni pravda. Bezny uzivatel by zkratka zadny rozdil poznat nemel (nebo jen pozitivni), ale vzhledem k funkcnosti X11 o tom pochybuju.
Modifikace Wayland protokolu nejsou velky problem, jak jsem psal protokol je verzovany a jde to velmi jednoduse, spis je pak problem s podporou v kompozitorech.
A proc menit X11 za Wayland? Protoze jednoduse X11 uz nikdo nic delat nechce, je to zastarale, slozite a tezko se to udrzuje a lidem to uz proste leze krkem. Wayland je jednoduchy a prehledny a oproti X11 miniaturni.
Na druhou stranu bylo by fer rict "Chceme delat Wayland protoze nas to bavi a chcem to udelat lepe nez v X11" nez si vymyslet bachorky jak to bude pro uzivatele lepsi.
-
null null (neregistrovaný)
@Martin Stransky
No já jako pouhý uživatel budu rád, jak už to tak bývá, když se mi nic nerozbije :-D :-D :-D
Problém bude asi v tom že se budil ten dojem že jde o nějaký převrat a zatím to prakticky vypadá že se jenom vyměnilo rozhraní ke starým problémům, některé odstranilo, některé přineslo + kdoví které to ještě přinese ... každopádně dobrý vědět ...;-) Díky
-
"a pokud je to většíně aplikací jedno, proč je pak potřeba to měnit?"
Ano, aplikaci, která vše dělá přes GTK nebo Qt, to může být jedno, protože ty grafické toolkity ji od toho odstíní, ale už to není jedno vývojářům těch samotných toolkitů a už vůbec ne vývojářům, kteří dělají na věcech níže v grafickém stacku. Je dobré si připomenout, že Wayland není nějaká iniciativa z venku. To je iniciativa, která vzešla od vývojářů Xorg. Xorg má hrozně nízký bus factor, dobře mu rozumí jen nižší jednotky lidí na celém světě. Vím to, protože několik takových lidí máme v týmu, a všichni do jednoho by vám řekli, že Xorg je prostě dlouhodobě neudržitelný. Nové věci se v něm dělají komplikovaně, je tak komplexní, že noví lidi nemají moc šanci se v něm zorientovat, takže není žádná nová generace vývojářů. Táhnou to ti samí lidi, kteří to táhli před 15-20 lety.
-
Peter FodrekZlatý podporovatel
>Xorg má hrozně nízký bus factor, dobře mu rozumí jen nižší jednotky lidí na celém světě. Vím to, protože
>několik takových lidí máme v týmu, a všichni do jednoho by vám řekli, že Xorg je prostě dlouhodobě
>neudržitelnýNízke jedotky ľudí je 1,2 alebo 3 kusov. Ak ich máte niekoľko, tak máte minimálne 2 ks a teda 66% tých, čo tomu rozumejú...
-
Vývojářů, kteří dobře rozumí Waylandu, je IMHO výrazně víc. To jde vidět už jen na tom, kolik vzniklo nezávislých implementací kompozitoru (Weston, Mutter, Kwin, Lipstick, Enlightenment, wlroots...). Prostě protože to je jednodušší než Xorg. Lidí, kteří dělají přímo na Waylandu a rozšiřujících protokolech, je zhruba stejně, protože to jsou vesměs ti samí lidi, kteří stále udržují nebo poslední roky udržovali Xorg. A protože jich je málo, přišli s něčím, co se dá v omezeném počtu vývojářů udržovat i do budoucna.
-
No "rozumet Waylandu" je jedna vec ale realne ho nasadi je vec druha. Wayland sam o sobe je mala knihovna ktera spojuje aplikaci a kompozitor. Je pravda ze je jednoducha a IMHO dokaze ji v radu jednotek dni nastudovat prumerny student VS a stejne tak podle toho vyrobit jaks-takys kompozitor.
Zasadni rozdil je ale v tom, jak je dany kompozitor udelany a jak je onen wayland protokol realne napojeny na kernel (GBM). A to je klicova cast ktera vyzaduje znalosti kernelu/ovladacu/GL a celkoveho vyladeni systemu. V podstate to same jako low level X jen trochu jiny protokol. Je dost rozdil jestli se ty buffery primo kresli pres DRM nebo se renderuje pres GL nebo je tam nejaka SW emulace.
-
Ja jsem navstivil na OpenAlt-u prednasku Martina Stranskeho prave na toto tema (firefox + linux + wayland) a myslim, ze by si linux zaslouzil vic lidi, kteri se tomu budou venovat. Jinak se z toho pan Stransky taky muze zvencnout a to by byla skoda :)
Podle me vzhledem k tomu ze X jsou slozita a wayland v zakladu jednoduchy a muze tim padem jet na kdejakem slabem HW (linux vsude...) je tohle docela dulezita oblast...
Nebo je na tom RedHat tak spatne? :) -
Naopak, je možné použít více bufferů - Mesa GL používa tři. Ale pro softwarové kreslení je rychlejší kreslit do stejného bufferu a kompozitoru poslat jen změněné oblasti.
Ohledně změn, Wayland protokol je verzovaný takže kompozitor/aplikace mají možnost použít novou verzi toho samého rozhraní (např. xdg-shell který se stará o zobrazení okna na desktopu má poslední verzi 6).
-
Díky za upřesnění. Chápu, že kreslení do stejného bufferu je pro aplikaci rychlejší. Na druhou stranu výsledek určuje souhra všech částí/vrstev. Ale beru, že pokud bude ve výsledku méně složitosti pro aplikaci (tedy pro aplikační vývojáře) a to maso (které z principu nelze nijak obejít) bude řešit kompozitor, nad kterým si budou lámat hlavy specializovaní profíci, pak je to cesta kupředu.
Vidím trochu paralelu s alsa + pulseaudio. Alsa má obrovsky složité API, protože z principu musí umožnit vše možné. Použití z aplikací není nijak jednoduché. PA nabízí vývojářům celkem snadné API, ale uvnitř řeší vše to "maso", které se prostě vyřešit musí. A trvalo hodně dlouho, než to "maso" začalo fungovat tak, aby mohlo být vnější API jednoduché.
-
Tu je tiez zaujimavy clanok o realnom nasadeni Waylandu:
https://www.swalladge.net/archives/2019/10/14/are-we-wayland-yet/Literrny zaner je tragedia v troch aktoch :-)
"This will be a tragedy in 3 parts: the switch, the trial, the switchback"
-
Peter FodrekZlatý podporovatel
ja som robil v X11 cez xlib a Athenu a veľmi málo v openGL a tak vítam Wayland. mal by ísť po sieti ako X Window System. Ale Wayland je stršne citlivý na zmeny v balíčkoch. Napr., je problém v KDE5 so spodnou lištou. A aspoň viem prečo.
-
Mě osobně na debianu testing wayland střídavě funguje a nefunguje. Po nějaké aktualizaci cca měsíc zpět mi teď když spustím firefox nebo nějaké video buď padá celé gnome do login screenu, nebo padá jen firefox a video se nevykresluje (zasekne se na prvním frame). Podle strace čekal na nějaký nedostupný prostředek, a po přečtení tohoto článku odhaduji, že to je zmíněny wayland buffer... a včera po aktualizaci už nenajelo ani gnome po přihlášení, celé se sekne jako to video a nic se nevykresluje. A pamatuji že tak cca půlrok zpět jsem musel úplně purgnout nějaký wayland balík, jinak po cca půlhodině provozu došla paměť a oom killer většinou zabil jádro... a odhaduji, že to bylo nějaké chybějící uvolnění paměti po použití bufferu, ale to bylo opravené celkem rychle...
Každopádně díky ua článek, jsem zase o něco chytřejší
-
To vypadá jako na problémy specifické pro Debian. Ve Fedoře je Wayland výchozí už tři roky a takové problémy se stabilitou tam nepozorujeme. Největším problémem, s kterým se uživatelé setkávají je to, že když GNOME běží na Waylandu, tak tam není nic, co by v případě pádu GNOME Shellu podrželo sezení s otevřenými klienty. Kompozitor Mutter totiž běží ve stejném procesu jako GNOME Shell a za Mutterem už nic není. Nicméně GNOME Shell sám o sobě běží stabilně, za 99 % jeho pádů můžou rozšíření třetích stran. Je to negativum návrhu GNOME Shellu, které umožňuje rozšířením upravovat přímo jeho kód. S Waylandem to nemá nic společného, ten ten problém jenom obnažil.
-
Mir se naučil být Wayland compositorem a Canonical ho v nějaké míře pořád vyvíjí pro IoT nasazení, asi tam, kde by byl Mutter moc těžký. Od Waylandu se to lišilo zásadně v tom, že Wayland je protokol, zatímco Mir display server s API. Žádnou podstatnou výhodu oproti Waylandu neměl, snad jenom to, že jako display server mohl nabízet některou funkcionalitu za kompository, které si to musí u Waylandu implementovat samy. Ale úlohu tohoto sjednocujícího prvku dokonale vyrušila CLA s nesymetrickými právy přispěvatelů. S takovým ujednáním IMHO neměli šanci se prosadit napříč desktopovými projekty. No a pak byla jeho nevýhoda to, že už existoval Wayland bez CLA a on oproti Waylandu nic podstatného navíc nepřinášel.
Kdyby se prosadil Mir místo Waylandu, tak se řeší úplně ty samé problémy.
-
A ještě jeden podobný. Psal si, že je aktuálně 5 core vývojářu Xorg a z toho dva jsou u vás.
Co se matně pamatuji, tak Xorg vznikl jako fork XFree86, když jim začalo vadit, že to používají všichni, ale nikdo o tom vlastně neví a začali vyžadovat zobrazení loga při startu X serveru. Jsou nějací vývojáři ještě kolem toho, nebo to už je mrtvý projekt, případně natolik vzdálený, že už je to jedno?
