Wayland má 15× menší API než X Server

A šup s tim brzo na MeeGo mobilni zařízení místo X serveru :)

Proč zrovna na MeeGo?

Protože MeeGo je čistý linux se vším všudy pro mobily i tablety.
A přiznávám, že je mi zcela u pozadí na čem budou zobrazovat mobily, co svoji WEB/HTML/JAVA nadstavbu prohlašují za systém. Já používám jen opravdové systémy. :)

Jo a protože Maemo / MeeGo už lěta používám k plné spokojenosti. :)

To je zase honění si ega. X protokol přežil už přes 25 let, a to že některé věci je na dnešním hardwaru lepší realizovat jinak než v roce 1986 předpokládal Jim Gettys & company, je jen logické. Podstatné je, že ten protokol funguje a není žádná větší překážka, která by bránila jeho uplatnění.

Co mi naopak na dnešních aktivitách kolem grafiky fakt vadí je, že čím dál víc věcí rezignuje na síťovou transparentnost, kterou X protokol přináší:

Jsou aplikace, které když zjistí že na tomtéž X serveru už ta stejná aplikace běží, tak ji požádají jen o otevření nového okna s příslušnými parametry (třeba prohlížeč PDF o zobrazení dalšího PDF), což pak selže na tom, že původní instance může běžet na jiném počítači než nová instance. Podobně třeba pulseaudio - to byla tak krásná příležitost k realizaci fakt síťově transparentního zvuku, a zůstala nevyužita. PA sice publikuje v X atomech informaci že existuje, ale vzdálené aplikace se k němu stejně nedostanou.

A je spousta dalších věcí které X protokol triviálně umožňuje, ale aplikace ji nepodporují. Dalším příkladem může být, že textarea ve firefoxu, do které právě píšu, by klidně mohla být realizována terminálem ve kterém by běžel vim, a já bych mohl tento komentář psát daleko pohodlněji. X protokol to normálně umožňuje, akorát toolkity a aplikace s tím moc nepočítají.

To že v X protokolu jsou věci typu management barevných prostorů nebo pseudo-color visual, které už dnes nejsou používané nebo se používají jinak, je jen důsledek té fakt dlouhé doby, po kterou X protokol existuje (měl jsem několik grafických karet, které fungovaly v pseudo-color režimu - včetně tehdy "high-end" věcí jako SGI Indy).

Takže k waylandu jsem trochu skeptický. Možná by mohli porovnat ne velikost celého API, ale toho co fakt používá některý toolkit (GTK, Qt).

-Yenya, http://www.fi.muni.cz/~kas/blog/

Hezký konzervativní pohled člověka od velkého kompu. Ale nikdo nechce vydat Wayland a X zadupat do země.

Ano, jedno řešení je zůstat u X, přidat hafo RAM, přidat výkon CPU a GPU a přidat trochu úložiště. Zcela běžné na běžném kompu, špatný pohled v případě mobilních zařízeni.

Pro lidi, kteří chtějí vyrábět mobilní zařízení postavené na linuxu, je to důležité. 95% uživatelů těch zařízení ty báječné funkcionality X proste nepotřebuje a jen to zabírá prostor úložiště i RAM. Potřebují zrychlit odezvy a mít podporu nových akceleraci na SoC ARM zařízeních. V tomto pohledu je X takový velký pomalý mamut.

Vím o čem mluvím, měl jsem 5 roků linuxové PDA N810 a teď mám linuxový mobil N9. Jsou skvělé a kdyby se dal vylepšit jeden brzdicí element, bylo by jen dobře.

Je to o uhlu pohledu. Od velkého kompu výhody Waylandu prostě vidět nejsou ...

Jo docela myslím, že nebudu daleko od pravdy s myšlenkou, že takhle nějak očesali/přepsali původni X v Apple pro jejich iPhony a iPady. Nebo má někdo přesné informace, na čem jim to jede ? Myslím opravdu přesné do hloubky, ne že se to jmenuje jinak. :)
Tu optimalizace SW na HW oni proste umí, to se jim musí nechat ..

Ještě k tomu úhlu pohledu .. připadá mi to úplně stejné jako když přicházely tablety. Lidé, kteří nepřišli na to, k čemu to může být dobré, jenom tvrdili, že to k ničemu není a neujme se to .. no však jim to nikdo nenutí. Svobodná volba, každý si vybere co mu vyhovuje. :)

Jsem rád že Wayland vzniká, dělá alternativu pro specifické druhy zařízení, které neexistovaly v době vývoj X. Podobně asi jako vznikalo QT po boku konzervativního GTK a dnes je v globálním pohledu mnohem dále. Tedy určitě je na mobilních zařízeních, kde GTK už je mimo hru.

PS: tohle není na Yenyu ale na ty jiné rádoby zadupávače nových věcí obecně:

Nechte si svůj konzervativní X server s GTK .. a Wayland s QT nechte jiným, kteří je využijí .. :)

PPS: na stolních kompech asi budu trvat na X, protože tam ty jeho funkce využívám.

> Ano, jedno řešení je zůstat u X, přidat hafo RAM, přidat výkon CPU
> a GPU a přidat trochu úložiště. Zcela běžné na běžném kompu, špatný
> pohled v případě mobilních zařízeni.

Tak tohle je třeba donekonečna opakovaný urban legend (jaksetořekne­česky?). X jsem měl na nokii 810, pomalé to prostě nebylo. Dneska mám mobil několikrát výkonnější z hlediska CPU a RAM, a navíc s HW 3D-akcelerovanou grafikou, což 810 neměla. Můj první počítač s X měl 8 MB RAM a normálně to fungovalo i s window managerem a více aplikacemi (a to xterm měl pro každé okno jeden proces, ne jako dnešní gnome-terminal nebo XFCE Terminal). Můj mobil s androidem má tak půl GB, a zobrazuje v jeden okamžik jednu aplikaci. Overhead X je fakt zanedbatelný. Co narostlo na náročnosti jsou toolkity (taky toho dělají o dost víc než dřív dělalo Xaw). Ale tam si jiným protokolem nepomůžete.

Jako určitě jde udělat o něco úspornější API a protokol, ale ten rozdíl nebude nijak značný. Jediné na čem lze u nepoužití X protokolu dost vydělat je latence - X protokol má na několika místech víc round-tripů tam kde by stačil jeden. Což je asi největší problém, protože i když za posledních 20 let výrazně vzrostla rychlost a kapacita téměř všeho, latence sítě zůstává víceméně stejná, ne-li horší (kvůli bufferbloatu například ve WiFi routerech/AP).

-Yenya, http://www.fi.muni.cz/~kas/blog/

Když i lokálně to musí proběhnout IP stackem, nějaká latence se nasbírá. Kdyby se odstranila, možná by reakce na ovládání byla okamžiká jako u iOS a ne tak gumová jako u Androidu. A o tom to je.

Copak Android pouziva X?

Ale houby. Tak za prvé overhead lokálního IP v Linuxu není nijak velký, za druhé lokální klienti ani nekomunikují přes IP - jedou přes UNIXové sockety, čili žádná IP komunikace tam není a overhead asi takový, jako by člověk čekal od běžného zasílání zpráv mezi lokálními procesy (Wayland to dělá podobně). Za třetí pro přenosy s velkou šířkou pásma jde udělat přímo segment sdílené paměti mezi X serverem a aplikací (například MIT-SHM extenze, která v X existuje a je podporovaná už tak 15 let), no a nakonec Android bohužel vůbec nepoužívá X.

-Yenya, http://www.fi.muni.cz/~kas/blog/

Mimochodem, mně docela na X vadí, že za 25 roků vývoje nebyli schopni tu síťovou transparentnost dotáhnout pořádně. Jak se utrhne spojeni, je to celé v kýblu. Takže používám Nomachine NX. Teprve potom je X přes síť použitelné.
I opičáci v MS pak dokázali síťově roztrhnout GDI ale samozřejmě tam udělali ošetření rozpadu spojeni.
Docela smutný výsledek.

"opičáci v MS" dokázali nejen "síťově roztrhnout GDI". Dokázali to výrazně lépe než X11. Samozřemě s reconnection, ale také s daleko menším datovým tokem, s kompresí a bez hromady zbytečných round tripů, takže se to dá fakt používat po síti. S řešením clipboardu (včetně grafiky a OLE objektů), s přesměrováním zvuku a USB klíčenky, přihlašováním přes čipové karty, s podporou klientů od DOSu přes Wyse terminály až po mobilní telefony, bez nutnosti implementace "stotunového" X11 serveru.

X11 je smutné. Pomalé a náročné na zdroje, s hromadou prehistorie typu font managementu, s tunami mizerně dokumentovaných extensions, s bug-to-bug compatibility.

Opičáci v MS si to především kompletně koupili od Citrixu + museli pár let dodržovat některá omezení (jen plocha a ne aplikace) a proti X tam přidali některá další plynoucí z licenční politiky.

Nevím jestli koupili od Citrixu technologii; určitě koupili patenty. Citrix ale používá i jiný protokol (RDP vs ICA). MS má samozřejmě jinou licenční politiku, ale může si to dovolit, protože má opravdu fungující produkt.

Kdo ? .... Se tě na to ptal ?!?!
Řešíme tu opensource subsystém a podrobnosti o nějaké closed source sračce, která není oficiálním standardem (jako většina věcí od MS) jsou mi úplně u prdele .. :)

NX také možňuje ta rozšíření sdílení a například clipboard mezi X-X tam opravdu funguje vždy 100%, na rozdíl od nativního RDP-RDP. Lépeřečeno oba clipboardy, na linuxu mám dva a oba pěkně pod kontrolou, ne jako ta parodie na win.
Za nekompatibilitu RDP verzí, které se v kortporátních WXP (v té době plně suportovaných) neupdatovaly samy, jsem do Redmontu chtěl poslat pozdrav s mezikontinentální dráhou letu.
Ještě že se mi už povedlo se zcela zbavit jakékoli aktivity s loterijním OS od MS. Ne, děkuji, již opravdu nechci.

Na Linuxu máte sice problém i lokálně vložit přes clipboard data (tedy ne jen text) z jedné aplikace do jiné, pokud nejsou ze stejného balíku, ale přes NX máte vše pod kontrolou :)

RDP je zpětně kompatibilní, takže se z Windows 2008 připojíte na WinXP, ale na naopak. Instalaci nového RDP klienta pro Windows XP můžete udělat na všech počítačích pár kliky přes Group Policy. Tedy pokud umíte základy administrace Windows, o čemž lze mít pochybnosti.

Nechcete? Vždyť vás nikdo nenutí. Klidně se memorujte příkazy, používejte druho- a třetiřadé produkty, a užívejte si to. Zákazníci sami vědí, co je pro ně dobré.

Až na to, že srovnávat RDP a Xka je dost mimo. RDP je obdoba VNC — přenášíte celou plochu se všemi aplikacemi. Xka naopak připojí vzdálenou aplikaci mezi místní, takže kromě jiného nápisu v titulku a zhoršené odezvy nepoznáte, že není místní. Dokonce na vzdáleném serveru vůbec nemusí běžet nějaký grafický server.

RDP přenáší na stranu klienta instrukce potřebné k vykreslení grafiky, v závislosti na tom, co klient umí. VNC používá protokol RFB, tedy pouhý přenos bitmap. Ten první přístup je rychlý a použitelný, zvlášť pokud protokol nemá hromadu zbytečných round tripů (které X11 bohužel má). Přenášení celé plochy je přesně to, co od "HW" grafického terminálu terminálu očekáváte, nicméně už řadu let (od RDP v6) umí RDP pracovat i s okny aplikací. Dříve to sice nebyl technicky problém, ale MS nechtěl lézt Citrixu do zelí.

Srovnejme si features RDP, X11 a VNC:
Přenos instrukcí pro kreslení grafiky - ano/ano/ne
Možnost připojit jen aplikaci, ne celý desktop - ano/ano/ne
Nízká latence a minimalizace round tripů - ano/ne/nevím
Použitelnost na pomalém spojení - ano/ne/ne
Možnost se znovu připojit k session po odpojení - ano/ne/ano
Komprese - ano/ne/ano
Šifrování - ano/ne/nevím
Přenos clipboardu, včetně grafiky a objektů - ano/nevím/nevím
Podpora přihlašování čipovou kartou - ano/ne/ne
Přenos zvuku - ano/ne/ne
Přesměrování tiskárny - ano/ne/ne

Porovnávat velikost API u letitého a nového projektu je docela úlet. Důležitější je funkčnost. Stačí u X nainstalovat jen ty potřebné balíky a zbytek nechat být a člověk se nestačí divit, jak svižný systém s GUI najednou má... Není od věci na ARM zařízeních otestovat ArmArchlinux...