Úvahy o X

15.8.2005 23:29 | Přečteno: 1201× | Rouhání největší

X Window System je s námi již několik desetiletí. Je standardem pro komunikaci s uživatelem na mnohých systémech, GNU/Linux nevyjímaje. Přes své nesporné výhody má také řadu velmi nepěkných vlastností, což mě občas vede k úvahám, zda by ho na desktopu nebylo lepší eliminovat.

V době svého vzniku byl X Window System doslova revolucí v UI. Koncept WIMP nebyl předtím uspokojivě realizován, proto tento systém, navíc velice robustně navržený, byl přijat ryze pozitivně.

Postupem času, jak vznikaly nové požadavky na to, co by měl počítač umět (zejména v oblasti multimédií), a s tím, jak rostly možnosti hardwaru, se do X začleňovala různá rozšíření, zajišťující tu či onu schopnost. Proto se původně poměrně jednoduchý systém proměnil v pěkného bumbrlíčka.

X Window System má celou řadu příjemných vlastností, např. tyto:

• oddělení vykreslování a komunikace s uživatelem od aplikací
• síťová transparence
• správa oken oddělená od kreslení (s tím, že správce může běžet kdekoli)
• velká modularita
• široká konfigurovatelnost

Ale jsou tu i stinné stránky:

• vysoká režie, a tedy zbytečná zátěž systému
• bezpečnostní rizika (X server běží obvykle s právy roota)
• neefektivní komunikační protokol
• relativní nevhodnost pro multimédia

S ohledem na výše uvedené jsem poněkud na pochybách, zda je klasický X pro běžný desktop to pravé ořechové. Systém byl navržen tak, aby úlohy běžely na výkonném stroji, zatímco uživatelé budou sedět u jednoúčelových grafických terminálů - pro toto nasazení má X svůj význam. Ale na PC mi přijde poněkud jako kanón na vrabce.

Problém je v tom, že (kromě aplikací běžících na speciálních knihovnách, třeba Qt) je X zažitým a široce používaným řešením, proto ho není možné jen tak zahodit a nahradit něčím jiným. Navíc to "jiné řešení" musí splňovat i řadu jiných podmínek (např. licenčních), což není tak úplně jednoduché.

Proto mi jako jedna z možných cest připadá vytvoření "odlehčeného" X serveru, který by neběžel jako samostatný proces, nýbrž by většina operací probíhala synchronně v rámci aplikačních procesů. Operace, které by takto řešit nešly, by se mohly provádět ve workqueues prostřednictvím procesů jádra.

Nevím zatím o žádném projektu, který by se tímto zabýval. Možná je to myšlenka nepatřičná, která se může ukázat cestou do pekel, ale jsem toho názoru, že stojí za to je jí vážně zabývat. Mohla by to být cesta, jak pomoct GNU/Linuxu k lepším výsledkům v desktopovém použití.

       

Komentáře

[Michal Kubeček]

Nezdá se mi to jako příliš dobrý nápad. Síla X je právě v té univerzalitě a bylo by IMHO chybou pro specifické případy vymýšlet specifické náhražky. Takové pokusy už tu byly, např. svgalib, a ztroskotaly IMHO právě na tom, že ačkoli byly v určitých situacích efektivnější než řešení přes X server (dodnes si pamatuji na výrazný rozdíl mezi sdoom a xdoom), nikomu se příliš nechtělo psát všechny aplikace dvojmo, zvlášť když by ta svgalib verze měla (oproti X11) jen velmi omezenou přenositelnost.

Samozřejmě že za tuto univerzalitu se vždy platí, obecné řešení bývá méně efektivní než speciální. Ale stejně jako používáme operační systém místo toho, aby každá aplikace komunikovala s perifériemi samostatně, stojí IMHO za to používat abstraktní vrstvu místo specifických řešení komunikace s grafickými adaptéry. Tam, kde je maximální efektivita klíčová (přehrávání videa, 3D hry apod.), existují nadstavby (DRI, OpenGL), které umožňují takové specifické úlohy řešit efektivněji. Nemyslím si totiž také, že by samotný X server byl tím, co způsobuje pomalost dnešních grafických uživatelských rozhraních. Když mi mohly grafické aplikace docela svižně běhat na 386DX-40 s 8 MB paměti, nevidím důvod, proč by to nemohlo jít na dnešních strojích (i těch (z dnešního pohledu) podprůměrných). Problém vidím spíš v neefektivních desktopových prostředích, tady je IMHO největší rezerva pro zlepšení.

[Yin]

X je možno univerzálne, ale aj význam univerzality sa časom mení. Dne sje X ma !@#$%^&*()*&^%$#@!, viem to, lebo som s ním pracoval (písal som wm, guilib, a nejaké utility).

[Luk]

To, co jsem navrhoval (jako "zlatou střední cestu"), by právě znamenalo, že by se aplikace přepisovat nemusely. Rozdíl by byl jen v tom, že knihovny Xlib atd. by nekomunikovaly se "stand-alone" X serverem, nýbrž by přímo volaly funkce jádra, které by prováděly příslušné operace (kreslení apod.). Asynchronní události by aplikace dostávaly úplně stejně jako teď.

Takže by se musely upravit jen knihovny, a samozřejmě vytvořit (resp. upravit) ten back-end.

Kolik výkonu by se získalo, těžko říct. Ale nějaký rozdíl by tam určitě byl.

[Michal Kubeček]

Nejsem si příliš jistý, že kdyby grafická knihovna musela volat syscall na každé grafické primitivum, snížila by se tím režie celého grafického subsystému. Ale necítím se být takovým odborníkem na jádro, abych to posoudil.

[VícNežNic]

Stojí pár ušetřených cyklů za tolik zbytečné práce? Důsledná optimalizace věcí jako GTK+ a podobně mi přijde jako lepší cesta.

[Yin]

To isto nestoji. ľudia stratili svoju tvorivosť, ktorú mávali za čias prvých letov na mesiac a nevidia, čo sa naozaj dá dosiahnúť.

Ja by som napísal niečo podobné ako userspace framebuffer. Ten framebuffer by bol len driver podobne ako vo FUSE filesystem. Existovať by mohol démon - bridge k X aplikáciam. Výhadou by bolo, že by renderovanie virtuálnej konzoly prevzal userspaceframebuffer a nemuseli by sme trpieť keď prepíname z X do konzoly; virtuálne plochy ako virtuálne konzoly, všetko by riadilo jadro, ale nevedelo by o tom.

[Michal Kubeček]

Nebylo by jednodušší váš problém vyřešit speciální verzí xtermu, která by běžela jako fullscreen (bez rámečků) a s vhodně zvolenými fonty? Pak by to mohlo vypadat jako framebuffer textový terminál a neztratil byste výhody grafického prostředí. Připadalo by mi to podstatně elegantnější než to, co navrhujete. Koneckonců, existují grafické terminály, kde nic takovéo jako "textové konzole" neexistuje, a také se s nimi dá pracovat. Jinak pomalost přepínání mezi grafickým prostředím a textovými virtuálními terminály je dána především pomalostí přepínání grafického módu na monitoru.

[VícNežNic]

Nemusí být nic speciálního, Terminal z Xfce projektu má fullscreen na dvě stisknutí myši Jenom je, pravda, o trochu pomalejší.

[Yin]

To nieje riešenie. Nepochopili ste ma. Nič by ste nestratili, len sevér by bol o trošičku tenší. Tie "zakázané techniky", ktoré X robia, by robilo jadro. Napr. X číta z terminálu, čím vyradí jadro na danej konzele a to je nebezpečné. Neexistoval by rozdiel medzi rozlíšením X a konzoly. X by boli o trošku viac unixový program ako doteraz.

[Michal Kubeček]

A vy jste opravdu přesvědčen, že stojí za to "ztenčovat" právě a zrovna X server? Zkuste se podívat, kolik paměti zabírá X server, pokud běží sám o sobě (bez window manageru). Zkuste se podívat, jak svižně běhá celé grafické prostředí pod takovým twm. Snažím se vám celou dobu vysvětlit, že pokud by někde prospěla odtučňovací kůra, jsou to daleko spíše desktopová prostředí. I kdyby se vám podařilo výrazně urychlit a zmenšit X server, nezískáte tím pozorovatelný efekt. Řádově účinnější úspory by byly možné na úrovni desktopových prostředí, tam je váš problém, ne v X serveru.

[Luk]

U mě má X server alokovaných cca 96 MB, z čehož je ale 64 MB grafická RAM. Z toho zbytku je skoro všechno ve fyzické paměti, sdílí se asi 4 MB. Tedy asi 28 MB samotný server. U prostředí KDE nároky těžko zjistím (těch procesů je moc a počítat se mi to nechce), ale takových 60-80 MB to určitě bude.

To ale nic nemění na tom, že jsou úvahy o jiných cestách zcela legitimní.

[Michal Kubeček]

Bavíme se oba o tomtéž, tedy o samotném X serveru bez běžících klientů, tj. po tom, co běží, když v runlevel bez grafického prostředí spustíte pouhopouhé 'X'?

[Yin]

Moje X zaberajú 5-12% z 320Mb RAM. Môj EvliWM mi zabera 40Kb RAM. Jadro môjho desktopu napísaného v Shelli, Perle, C, Emacs Lispu, Vim skripte a JavaSkripte (ff, tb) mi zabera cca 750Kb na disku.

Mojím cieľom nieje stenčovať X, ale zlepšiť GUI. Ide mi len o to, aby môj systém vyzeral a správal sa koherentne a nie, akoby ho nejaký šialenec rozreza motorovou pílou napoly a potom zlepil lepiacou páskou a nazval ho Desktopom.

[Michal Kubeček]

Ale unixové systémy byly navrženy tak, aby byly modulární a modularita s sebou přináší heterogenitu (chcete-li, nejednotnost). To je základní princip a pokud do unixových systémů začnete implementovat něco, co tuto modularitu popírá, dostanete paskvil. Pokud vaší filosofii více vyhovuje monolit, kde je všechno pevně spojeno dohromady tak, že nejsou vidět žádné švy, pak doporučuji ohlédnout se po jiném systému (o jednom bych věděl). Každý z těch přístupů má své výhody a nevýhody, ale bylo by IMHO chybou vzít systém, který je založen na jednom přístupu, a snažit se ho předělat podle toho druhého.

[Luk]

Moje úvahy jsou vedené ve stejné rovině, jako se vedou úvahy monolitické jádro vs. microkernel. Použiji-li tuto analogii, tak X Window System odpovídá architektuře mikrojádra, zatímco moje úvahy jsou blízké monolitickému jádru.

Jen připomenu - Linux býval kdysi monolitický, dnes už to dávno není pravda, s každou další větví kernelu vždy přibývají specializované jaderné procesy.

[Luk]

Ne. To, co jsem udával já, je stav X serveru po startu KDE. Ještě upřesním - je to na nVidii s proprietárním ovladačem (který má svou část v X serveru a část v jádře - obě dost objemné).

[Yin]

To isto nestoji. ľudia stratili svoju tvorivosť, ktorú mávali za čias prvých letov na mesiac a nevidia, čo sa naozaj dá dosiahnúť.

Ja by som napísal niečo podobné ako userspace framebuffer. Ten framebuffer by bol len driver podobne ako vo FUSE filesystem. Existovať by mohol démon - bridge k X aplikáciam. Výhadou by bolo, že by renderovanie virtuálnej konzoly prevzal userspaceframebuffer a nemuseli by sme trpieť keď prepíname z X do konzoly; virtuálne plochy ako virtuálne konzoly, všetko by riadilo jadro, ale nevedelo by o tom.

[Yin]

To isto nestoji. ľudia stratili svoju tvorivosť, ktorú mávali za čias prvých letov na mesiac a nevidia, čo sa naozaj dá dosiahnúť.

Ja by som napísal niečo podobné ako userspace framebuffer. Ten framebuffer by bol len driver podobne ako vo FUSE filesystem. Existovať by mohol démon - bridge k X aplikáciam. Výhadou by bolo, že by renderovanie virtuálnej konzoly prevzal userspaceframebuffer a nemuseli by sme trpieť keď prepíname z X do konzoly; virtuálne plochy ako virtuálne konzoly, všetko by riadilo jadro, ale nevedelo by o tom.

[Michal Kubeček]

Fuj, samozřejmě tam má být: "grafických uživatelských rozhraní"

[Yin]

V zápise do blogu neseparujme X a konzolu som ja vyjadril podobne. Projekt Y-Windows zomrel len kôli tomu, že neexistuje skupina ľudí, ktorá by GNU/Linux a zvyšok unixového neba tlačili tým správnym smerom.

[kavol]

Y-Windows je mrtev? a já furt čekal, kdy zplodí něco použitelného

ale vážně, různé nové distribuce nám rostou jak houby po dešti, sourceforge registruje hafo nových projektů na věci, které už tu dávno jsou, to by se mezi těmi spoustami nudících se počítačníků nedala utvořit skupinka, která by na tom dělala? - což takhle místo blogování zkusit něco zorganisovat?

[Martin Lebeda]

Já si naopak myslím, že použití *nixu na běžném desktopu brání úplně jiné věci než je nedostatečný výkon X. Běžnému uživateli to je naprosto fuk. Věci, které potřebují vyšší grafický výkon používají SDL apod.

Použitelnost desktopu je v tom, že mi umožní dělat věci jako pořizování dokumentu, práci s poštou. Tady se nedá dnes nic vytknout. Při brouzdání internetem to už je horší (např. banky a podobné aplikace). A samozřejmě je třeba aby byl zpřístupněn podnikový IS a tady je *nixový desktop většinou vedle. Ovšem, že to není chyba samotného *nixového desktopu, že firma xy neudělá verzi pro *nix xz, ale nic to nemení na výsledku.

[vladimir]

mam dojem ze jsi uplne nepochopil problem. Neni tu rec o nedodrzovani standardu bankami ani tvurci IS, otazka zni zda X Window system je nebo neni zbytecny moloch.

[Abraxis]

Je to moloch, ale nikomu to uz dneska nevadi, protoze zatez HW je minimalni a napsat nejakou nahradu je natolik narocne, ze se to "nevyplati". Jedine, co se mi na Xkach nelibi, je citlivost na network-latenci (Xka jsou celkem rozumna v pouzivani bandwith, ale pracovat se vzdalenou aplikaci s "pingem" kolem 300 ms je docela utrpeni).

[Michal Kubeček]

X server vůbec není moloch, pokud by se něco dalo nazvat molochem, jsou to desktopová prostředí nad tím X serverem, zejména kolosy typu KDE nebo Gnome. Bohužel uživatel neznalý problematiky (a zejména uživatel zvyklý z Windows, že je to všechno integrováno dohromady, pokud možno ještě s operačním systémem na jedné straně, webovým prohlížečem na druhé a za pár let třeba i s mailovým klientem, groupware klientem, textovým procesorem a spreadsheetem) není zvyklý takové věci rozlišovat.

[Michal Kubeček]

Roundtrip na úrovni 300 ms je zabiják pro jakoukoli interaktivní komunikaci včetně SSH. Kde jsou ty časy, kdy jsem se připojoval z Trieste do Prahy telnetem (!) s roundtripem okolo 5 sekund (ano, sekund) a místo abych nadával, jak je to pomalé, liboval jsem si, že to funguje. Dokonce jsem tenkrát zkoušel spustit v Praze Mathematicu tak, aby kreslila na sluníčko v Trieste (a dokonce jsem se dožil toho, že něco zobrazila :-) ). Dneska při roundtripu 300 ms telefonuji providerovi, ať s tím něco udělá…

[Ondřej Čečák]

I na SSH v2 po GPRS s odezvou cca 900 ms se da v nouzi zvyknout :)

[Michal Kubeček]

Člověk si zvykne i na šibenici… :-) Nedávno jsem třeba potřeboval provést urgentní servisní zásah na serveru zákazníka, který v tu chvíli měl roundtrip někde okolo dvou sekund. Vřele doporučuji každému, kdo tvrdí, že editor vi je přežitek. Rozdíl mezi "stisknu f<" a "chvíli podržím šipku doprava a pak budu pár vteřin čekat, kam jsem se vlastně trefil" je poměrně značný… :-)

[Martin Lebeda]

:-/ V takové chvíli je i vi nepoužitelný. Obvykle v takové situaci skřípu zuby, nastavuji lokální echo a začínám používat ed (ex).

[Michal Kubeček]

Editor vi se používat dá, jen je potřeba potlačit některé návyky, zejména (v této situaci) smrtící zvyk využívat šipky s autorepeatem.

[Martin Lebeda]

Autor končil svůj příspěvek úvahou nad tím, že vytvořením jednodužších X dojdeme k lepší použitelnosti Linuxu na desktopu. Je to špatná úvaha. Vůbec nic se nezmění, použitelnost desktopu je v něčem jiném.

Naopak se připravíme o jednu ze zásadních výhod X - nezávislost na jádru systému a síťová transparentnost. NE - X Window není zbytečný moloch, naopak, je to jedna z nejdomyšlenějších koncepcí v IT.

[Luk]

Tak znovu - je to čistě filosofická úvaha. Pokud si takové otázky nebudeme klást, nemůžeme jít kupředu.

X server s dnešní škálou rozšíření rozhodně není nezávislý na jádře. Aby např. fungovala HW akcelerace na kartách nVidia, musí být v jádře (proprietární) modul o velikosti přes 2 MB. Pokud oželíme speciality nabízené různými kartami (které se samozřejmě dost liší), získáme samozřejmě relativní nezávislost.

[unchallenger]

Aby např. fungovala HW akcelerace na kartách nVidia, musí být v jádře (proprietární) modul o velikosti přes 2 MB.

To je sice smutné, ale to, co navrhuješ, není zlepšení tohoto stavu.

[vladimir]

rozhrani aplikace<->hardware ma byt a bude vzdy zalezitosti jadra. Aplikace nemuzou komunikovat s HW jinak nez pres jadro. Nevidim duvod proc by X server mel byt vyjimkou.

[Michal Karas]

X Window není zbytečný moloch, naopak, je to jedna z nejdomyšlenějších koncepcí v IT.

Nedavno jsem docetl Umeni programovani v Unixu a Eric Raymond se v teto, alespon pro me, zajimave knize parkrat zminuje (1, 2) o NeWS od Sunu. Tento system, ac udajne lepsi, byl X-ky v 80. letech porazen "jen" z licencnich duvodu a kvuli tomu, ze nebyl k dispozici zdrojovy kod.