Na Phoronixu se blíže podívali na aktivitu okolo X.Org Serveru. Nejbouřlivější vývoj probíhal v roce 2008, kdy do projektu přibylo 2098 commitů. V minulém roce už to bylo pouze 731 commitů. Aktuální sestavení čítá na 715 309 řádků kódu a na projektu se podílí 450 přispěvatelů.
Důvod úbytku změn je nasnadě, distribuce se připravují k přechodu na jiné grafické servery v čele s grafickým serverem Wayland.
(Zdroj: Phoronix)
Ad Funkcionalita je v X taková, jaká je třeba - to máte na mysli tu spoustu round tripů, přenášení bitmap po síti (klienti totiž dávno nepoužívají X11 primitiva, naopak rendrují lokálně a pak jen X11 serveru nacpou bitmapu), díky tomu nepoužitelnost pro vzdálený přístup, pomalost i na lokálu, bažinu různých extensions, a samozřejmě neřešení tisku? Jo, to je fakt terno.
to se tu probíralo naposledy před dvěma týdny.
Koukněte se na Windows nebo MacOS. V obou případech na úrovni API nějakou plochu, po které kreslíte. Ta plocha může být obsah okna, nebo stránka tiskárny. Pokud chcete zobrazit dokument nebo grafiku, necháte svůj kód kreslit do kontextu okna (případně komponenty v tom okně). Pokud chcete tisknout, tím samým kódem kreslíte po tištěné stránce, a nakonec jen řeknete "stránka je hotová".
Minimálně v případě Windows exportují i drivery pro grafickou kartu a tiskárnu stejné funkce. Pokud dané zařízení něco neumí (řekněme grafická karta neumí kreslit křivky), GDI to převede na jiné operace, případně danou věc vyrastruje.
Z hlediska autora aplikace je to super, protože používá ten samý kód pro kreslení do jakéhokoliv kontextu. Z hlediska GDI i autora driveru je to také super, protože se používá velmi podobný driver model pro kreslení po více typech zařízení.
Na Unixech máte standardně na zobrazení X11lib, což je pravěká příšera, kterou měl dávno někdo popravit. Na tisk máte k dispozici leda print spooler, a obsah si musíte vygenerovat sám. A pak se nad tuhle hrůzu lepí věci jako Cairo, které má na jedné straně API se surfaces (obdoba GDI contextu), a na druhé straně různé úplně odlišné back-endy s naprosto odlišnými vlastnostmi, jako je PostScript, Xlib, Xlib s X Render extension a XCB. Pokud chcete tisknout na běžnou PCL tiskárnu, nejspíš v Cairu uděláte výstup PS nebo PDF, a pak to proženete RIPem, aby to celé bylo "čistší a elegantnější". A k tomu se paralelně už od roku 2008 píše Wayland (ať žije rychlost), a teď i samozřejmě Mir, přičemž Cairo neumí ani Wayland ani Mir, a Wayland ani Mir pro jistotu neumí vzdálený přístup po síti. Jistě se shodneme, že je tohle není dobrý design, ale fialový radioaktivní hnus.
Aj.. zase stejná "písnička" - a nedá mi to nenapsat obligátní stejnou reakci:-) GK a tiskárna jsou opravdu hodně rozdílná zařízení. Tiskárny dost často tisknou obyčejné bitmapy a rasterizace se musí udělat v SW. Jestli je rozhraní těchto dost rozdílných zařízení sjednoceno na úrovni rozhraní jádra (a implementováno driverem) nebo knihovny je celkem jedno - funguje to pořád stejně. Jen ta knihovna asi nebude umět shodit jádro...
Co se týče protokolu X11, je fakt, že si s sebou táhne hodně historické funkčnosti. Ne všechna je ovšem tak špatná, jak se na ni plive;-) Zrovna kreslení pomocí geometrických primitiv může být zajímavé pro různá semigrafická a negrafická "zobrazovací" zařízení - napadá mě znakový displej, Brailův terminál apod.
Je také dobré si uvědomit, že okolo X11 existuje ekosystém "ohejbáků", které se snaží řešit problémy protokolu X11 (Winswitch, NX, VirtualGL). Nutno říct, že se jim to daří velmi dobře. Žádný není univerzální kladivo-šroubovák, ale pro své účely fungují stejně dobře nebo lépe, než univerzální řešení, jakým je třeba RDP.
Co se týče vzdáleného tisku, zvuku, routování různých sběrnic, je to opět otázka pohledu na věc. Buďto se vezme to, co často používá průměrný uživatel a spojí se to do jednoho balíku (RDP), nebo se udělají samostatné služby pro jednotlivé účely a spojí se případně ve finální aplikaci (Unix styl). Každé má svoje výhody a nevýhody. Zcela jasného vítěze ale nevidím.
GK a tiskárna jsou opravdu hodně rozdílná zařízení.
To je marný, to je marný, to je marný. Tohle těm pošukům z Redmondu prostě nevysvětlíte. Nejlepší je, když pak někdo pošle výsledný soubor mailem, formátování samozřejmě úplně mimo, ale to nikomu nevysvětlíte, protože přece u něj se to zobrazuje krásně srovnané (podle jeho defaultní tiskárny.)
Ad GK a tiskárna jsou opravdu hodně rozdílná zařízení - grafická karta VGA se svým lineárním frame bufferem a dvě karty nVidia ve SLI jsou také dost odlišné zařízení. Přesto k nim aplikace přistupuje přes stejné API. Úkolem OS je vytvářet abstrakci nad HW. V případě zobrazení a tisku je ta abstrakce logicky velmi podobná.
Ad jestli je rozhraní těchto dost rozdílných zařízení sjednoceno na úrovni rozhraní jádra (a implementováno driverem) nebo knihovny je celkem jedno - tak jak to máte postavené na Unixech to připomíná věž Jenga, a ještě postavenou z nestejných dílů. Už ten "návrh" je úděsný. Původně zcela bez řešení tisku, pro zobrazování hrůza jménem Xlib, pak různé toolkity nad X11 a hromada X11 extensions, CUPS s úplně odlišným interfacem, a pak pokusy o zastřešení toho bordelu něčím použitelným po vzoru Windows a MacOS. Výsledkem je spousta zbytečných (a BTW špatně navržených) interfaců, naprosto odlišné rendrovací cesty, a obrovský overhead. Je to takové Unixové.
http://programmingzen.com/wp-content/uploads/2011/03/jenga.jpg
Ad ta knihovna asi nebude umět shodit jádro - proto se ve Windows 2000 a vyšších používají user-mode drivery tiskáren.
Ad kreslení pomocí geometrických primitiv - to je samozřejmě správná cesta. Jenže jak už jsem psal, dneska klienti vyrastrují bitmapu v něčem jako je Cairo, a tu pak procpou skrz X11. Podpoře znakového displaye ani Brailova terminálu X11 asi nic nového nepřinese :D
Ad vzdáleného tisku, zvuku, routování různých sběrnic - pokud chcete stavět terminálový server, tak je X11 naprosto nepoužitelné. Absence podpory vzdáleného tisku, zvuku apod. pak nehraje roli. Když vůz nemá kola, netrápí vás stěrače :)
Cituji: "Ad vzdáleného tisku, zvuku, routování různých sběrnic - pokud chcete stavět terminálový server, tak je X11 naprosto nepoužitelné."
My tu pouzivame ThinLinc (https://www.cendio.com/products/thinlinc/) od Cendia (vypocetni server s Linuxem a desitky uzivatelu pripojujicich se pres ThinLinc klienty) a nemame s tim problem. Popiste, co se vam nepodarilo zprovoznit, at se na to vyvojari mohou podivat.
Ad X11 naprosto nepoužitelné, pouzivame ThinLinc - ThinLinc uses SSH for transport encryption and authentication, and VNC for graphics, keyboard and mouse. Zjevně nikoliv X11. Co to potom vypovídá o X11?
http://en.wikipedia.org/wiki/ThinLinc#Protocols
X11 protokol se pouziva pro renderovani na serveru, vysledek se pak prenasi pres VNC na klienta. Sitova transparentnost X11 se tu nevyuziva, ale X11 protokol je urcen i pro komunikaci mezi X-serverem a klientem na jednom pocitaci. Z tohoto pohledu je Vas vyrok o nepouzitelnosti X11 nepravdivy. Proto jsem reagoval.
Ocividne s X11 mnoho praktickych zkusenosti nemate. My jsme zde tenke klienty, ktere se pres XDMCP sessions pripojovali k vypocetnimu serveru, pouzivali mnoho let. Na lokalni siti to fungovalo bez problemu, latence byly mnohem mensi nez v pripade VNC, NX, RDP, ... V te dobe ani nebyl velky problem provozovat X pres WAN. Problemy vznikly pozdeji s prichodem antialiasovanych fontu a dalsich vylepseni. Pak se latence prodlouzily natolik, ze X11 protokol se stal pro WAN temer nepouzitelny. V te dobe uz ale byla davno jina reseni (VNC, NX).
Diskuze s Vami je absurdni v tom, ze o resenich, ktera se bezne pouzivala a pouzivaji, tvrdite, ze jsou naprosto nepouzitelna. Mozna presvedcite nejake newbies, kteri o problematice nic nevedi. Ale lide se zkusenostmi okamzite poznaji, ze zde delate propagandu Microsoftu. A nekdy silne lzivou. Doufam jen, ze Vas Microsoft dostatecne plati. Protoze jinak zde predvadite jen projev moralni ubohosti. Kdyz jsem pracoval u Sunu, tak obchodnici pouzivali zasadu: "Vyzdvihujeme vyhody nasich vyrobku, ale konkurenci nespinime." Dobre vedeli, proc to delaji. Mel byste se nad tim zamyslet.
Takže X11 je pro terminálový server tak skvělé, že ho pro komunikaci s terminály nepoužíváte, a místo toho přenášíte bitmapy pomocí VNC, i když to má v porovnání například s RDP velikou režii.
Už někdy před deseti lety jsem měl možnost delší dobu srovnávat na stejném spojení X11 a RDP. Dva stroje stály v serverovně vedle sebe. Výsledek byl jasný: X11 bylo naprosto nepoužitelně pomalé (včetně odezvy na stisk kláves), zatím co s RDP se dalo v pohodě pracovat. Navíc srovnání X11 a RDP dopadá pravidelně stejně. Zkuste si to - nějaký stroj s Windows snad někde najdete :)
Casto kdyz je neco spatne, tak odpoved zni "Je to dano historickym vyvojem".
xlib (xcb) je knihovna nad x11 protokolem. Nic vic nema na starosti - a ani nikdy nemela mit.
Tisknout se da i pres terminal (telnet, ssh). Dokonce i telnet protokol umoznuje prenaset jmeno zvolene tiskarny. Pro Xka existuje Xprint extension, ale nikdy jsem nikoho nevidel to pouzival. Na IRIXu kdysi fungovalo i rozsireni pro generic SCSI. Takze se daly sdilet jak tiskarny tak scanery.
CUPS je SW ktery vyviji Apple a ani se nesnazji nejak ho integrovat do Linux/Unix sveta.
O kreleni pomoci geometrickych primit se pred 15ti lety snazila Java. Neexitovaly zadne pixely, jenom geometricka primitiva s rozmery v milimetrech.
Vysledkem bylo, ze zobrazovani fontu bylo neuveritlene pomaly a hnusny. Zatim nikdo neprisel na to jak popsat obraz vektorove a bitmapove zaroven. Tyhle dva svety jsou proste neslucitelne.
To ze v soucasnem Linuxovem destopu vznika a zanika spousta divokych rozhrani, tak s tim souhlasim. Bohuzel dnesni frikulini nechteji mit s Unixem nic spolecneho a delaji z Linuxu druhy Windows (anebo Mac). Akotat na to namaji cas, penize ani zkusenosti.
Tak to ani nahodou. Ten 10Mbit bez problemu utahl desitky uzivatelu najednou v jedne ucebne.
xlib protokol umoznuje ukladat bitmapy na server a pak se na ne odkazovat pres IDcko.
Navic v te dobe Xserver renderoval bitmapovy a PS fonty na svoji strane (zadny antialiasing) takze velke objemy dat se neprenasely. Dokud si nekdo nespustil Netscape - jakmile zacali lidi vkladat obrazky do stranek tak pomalu 10Mbit prestaval stihat.
Ad Je to dano historickym vyvojem - samozřejmě chápu, že v Unixovém světě roku 1984 nikdo nepřemýšlel nad tiskem grafiky na desktopu, nebo nad vzdáleným přístupem. Jenže dnes jsme o 30 let dále. Tedy ti z nás, kdo nesedí u nějaké odrůdy Unixu :)
Ad tisknout se da i pres terminal - to autorovi aplikace s implementací WYSIWYG tisku moc nepomůže.
Ad existuje Xprint extension - v první verzi té extension uměla vytisknout bitmapu bufferu, což je vzhledem k rozdílu rozlišení obrazovky a tiskárny nepoužitelné. Další verze uměly kreslit po papíru pomocí X11 protokolu, a bylo to tak "praktické", že podporu před pár lety vyhodili z X.org.
Ad kreleni pomoci geometrickych primiv - zrovna fonty jsou už pár let vektorové. Samozřejmě pro nižší rozlišení obrazovky je potřeba nějaký hinting. Jinak většina tiskáren je "na konci" bitmapová. Vektorové jsou snad jen klasické plottery. Když na nich chcete tisknout bitmapu, tak se holt tečkuje.
Ad dnesni frikulini... z Linuxu druhy Windows... Akotat na to namaji cas, penize ani zkusenosti - souhlas
Dovolím si opravit pár nepřesností.
- Cairo Wayland podporuje.
- Cairo není zdaleka jedné vykreslovací API.
- Wayland zná FreeRDP.
- Wayland prakticky funguje a docela dlouho. Navíc to byl nějakou dobu jen hobby projekt Kristiana Høgsberga, takže brát rok 2008 jako starting point není úplně vypovídající.
Ad Cairo Wayland podporuje - kde se dozvím detaily? Tedy nic takového nevidím:
http://cairographics.org/backends/
Ad Wayland zná FreeRDP - super. Až distra (a aplikace) přejdou na Wayland, bude Linux blíž začátku jednadvacátého století.
Ad Wayland prakticky funguje a docela dlouho - stabilní server API bylo ohlášeno teprve minulý rok, a podpora v distrech a aplikacích většinou ve fázi plánování. A aby to bylo zajímavější, je tu Mir od Canonicalu. Ať žije fragmentace platfromy.
http://www.phoronix.com/scan.php?page=news_item&px=MTQwOTg
Ad 1)
Wayland žádné vlastní vykreslovací API nenabízí, protože už jich existuje asi dvě stě padesát. Wayland klienti sdílí obrazové buffery s kompozitorem, který je podle potřeby vykreslí. Zapsat něco do takového bufferu se dá čímkoliv, třeba cairem, ideálně HW akcelerovaným cairo-gl.
Ad 2 a 3)
Fedora 21 s GNOME 3.14 by měla být plně Wayland-enabled. KDE 5 je plánováno na léto, i když tam nejspíš nebude plná podpora Waylandu hned v první verzi, experimentálně už funguje od KWin 4.11. Některé DE jako E17 už Wayland podporují dávno. Podpora v potřebných toolkitech už je hotová, zpětnou kompatibilitu zařídí XWayland (zařazen do X.Org 1.16). Wayland prakticky funguje třeba v Sailfish OS.
Mir byl (podle očekávání) odložen až na Ubuntu 16.04 a kromě Canonicalu jej nepodporuje prakticky nikdo a nic. Pokud se Wayland do doby vydání Ubuntu 16.04 na desktopu prosadí, dá se předpokládát, že Mir skončí jako abandonware a Canonical bude muset tak jako tak začít používat Wayland. Udržovat kód pro podporu Miru alespoň v Qt 5, GTK 3, SDL2 a Mesa by bylo i pro Canonical skoro nemožné.
Ad 1 - v čem tedy spočívá ta podpora Waylandu v Cairu?
Ad 2, 3 - Fedora 21 bude někdy na podzim, KDE 5 bude podle vás v létě, Sailfish je v alpha verzi...
Ad Mir - soudě podle tempa (ne)vývoje Waylandu má Canonical pořád dobrou šanci. A zrychlení vývoje Waylandu bylo přece reakcí na Mir.
Vtip je právě v tom, že pokud umí vykreslovací toolkit kreslit do bufferu s obrazovým formátem, který Wayland zná (ARGB32, XRGB32, ...) nemusí pro podporu Waylandu dělat vůbec nic.
F21 i KDE 5 tu budou rozhodně dřív než Ubuntu 16.04 a to navrch předpokládáme, že se Mir do této verze skutečně dostane. Navíc jsem zatím neviděl, že by se Canonicalu podařilo protlačit do upstreamu jakýkoliv jejich kód. Mír zatím běží na ohackované Mesa a Qt, podpora Miru v GTK3 vypadá zatím dost uboze.
Sailfish ve verzi 1.0.5.19 jako alpha verze fakt nevypadá. Chybí akorát podpora LTE a zažehlit pár posledních bugů.
To je zase rozvířených vášní... Netřeba se tím až zas tak trápit - důvodů, proč jsou konkrétní řešení v něčem dobrá a v něčem špatná tu zazněly už několikrát - a nejen v této diskuzi. Prostě někde je lepší jedno, někde druhé a někdy ani není na výběr... ale my to dohadováním nezměníme:-)
Podobných "výhod" Windows je víc. Vypadají pěkně při marketingových prezentacích, ale v praxi je skoro nikdo nepoužívá. Za posledních několik let jsem na tiskárně tiskl jen formuláře, které jsem musel podepsat. A také několik dokumentů distribuovaných v PDF a fotek; v těchto případech je ale lepší při návrhu dokumentu pracovat s velikostí a rozlišením výstupního média (papíru), než přebírat návrh pro obrazovku. To se hodí snad jen pro screenshoty do dokumentace o Windows.
Co se tiskového systému týče: Začala doba cloudová. V práci tiskneme přes outsourcovaný tiskový systém na multifunkčních kopírkách (tiskárna, kopírka skener), které si RIPují samy. Doma tisknu přes Google cloud print (z Linuxu, OS X, iOS a Androidu). Fakt, že pro tisk na PCL tiskárnách je třeba generovat PDF nebo PS a to pak RIPovat, mě vůbec netrápí. Nepoužívám to.
Unixy a Linux vámi popisované funkce nemají, protože se nikdy nenašel dostatečný počet lidí, kteří by je využívali v praxi. A nová tisková řešení budou na bázi cloudu, kde ke standardizaci ještě nedošlo.
Kolem Windows NT byl udělán velký marketingový humbuk, že podporují POSIX. Některé americké organizace jeho podporu vyžadovaly. Manažeři zkontrolovali kolonku "má POSIX" a Windows NT pořídili. Pak se ukázalo, že POSIX tam sice byl, ale v praxi byl zcela nepoužitelný. Tohle je koncepce Windows: mít něco na papíře, ale že to v praxi nefunguje, nebo to nikdo nepoužívá, se řeší až po nákupu.
Pres Google Cloud Print tiskneme veci stazene z webu (treba recepty na pripravu jidel) nebo sdilene pres cloudove sluzby (treba fotky kocek). Zadne tajnosti, ke kterym by Google jinak nemel pristup, to nejsou. A ze si o tom Google dela statistiku me netrapi. Za ucelem utajeni bych mohl cloudove sluzby nepouzivat, do diskuzi prispivat jen pres anonymizery a po ulici chodit v prestrojeni s nalepenym knirem, aby me nikdo nepoznal. Taky by to slo, ale opravdu nevidim, v cem by mi to zlepsilo zivot. Naopak v tom vidim jen same komplikace.
Takže jinými slovy vy tisknete minimálně, doma typicky přes Google Cloud Print do kterého při tisku uploadujete dokumenty (wow!), a proto je otázka API pro tisk vlastně nesmysl.
Ad je ale lepší při návrhu dokumentu pracovat s velikostí a rozlišením výstupního média - to nic neříká o API. Když navrhujete dokument, děláte to na obrazovce, a aplikace musí ten dokument nějak kreslit. Pro autory aplikace je poměrně zásadní výhodou, když tím samým kódem mohou vykreslit dokument na obrazovku a na tiskárnu. WYWIWYG je pak prakticky automatický.
Ad Unixy a Linux vámi popisované funkce nemají, protože se nikdy nenašel dostatečný počet lidí, kteří by je využívali v praxi - Unixy a Linux nikdy nenašly dostatečný počet desktopových uživatelů, protože popisované funkce nemají.
Ad Windows NT a POSIX - WinNT byly dokonce POSIX certifikované, na rozdíl například od Linuxu. Problém je spíš v tom, že POSIX spoustu věcí nepopisuje.
