Интернет магазин китайских планшетных компьютеров



Компьютеры - X Window System - Ограничения и критика X

11 мая 2011


Оглавление:
1. X Window System
2. Клиент-серверная модель и сетевая прозрачность
3. Принципы построения X
4. Интерфейсы пользователя
5. Реализации
6. Расширения
7. Ограничения и критика X
8. Конкуренты X
9. История
10. Дальнейшие разработки
11. Наименование



В книге «The UNIX-HATERS Handbook» целая глава посвящена проблемам X в конце 1980-х — начале 1990-х годов. Статья «Why X Is Not Our Ideal Window System» подробно рассматривает проблемы протокола и даёт рекомендации по улучшению.

Видеоаппаратура

Сегодня граница производительности графических компьютерных систем пролегает в области наиболее продвинутых графических функций. Изготовители аппаратного обеспечения, как правило, реализуют эти продвинутые возможности в проприетарных драйверах, причём эти драйверы обычно пишутся в первую очередь для систем Microsoft Windows. Драйверы многих старых графических плат подверглись обратной разработке в рамках проектов XFree86 и X.Org Server. Однако некоторые производители рассматривают свои разработки в области высокопроизводительного видео как коммерческую тайну или же как патентованные изобретения, которые они не хотят раскрывать.

Многие нынешние реализации X управляют видеоаппаратурой напрямую. Неустойчивый X-сервер может сделать дисплей непригодным к использованию даже в тех случаях, когда сама операционная система продолжает нормально функционировать; при этом может потребоваться перезагрузка всей системы. Технология Direct Rendering Infrastructure призвана устранить эту проблему.

Функции интерфейса пользователя

X Window System намеренно не включает в себя спецификации интерфейса пользователя, равно как и большей части межпрограммного взаимодействия. По этой причине возникли очень сильно отличающиеся друг от друга интерфейсы, а также приложения, не всегда правильно работающие друг с другом. Существует спецификация взаимодействия клиентов ICCCM, но она известна как трудная для правильной реализации. Последующие попытки стандартизации — такие как инструментарий Motif и среда CDE — не исправили положения. Всё это мешает как пользователям, так и программистам. В настоящее время разработчики обычно добиваются единого стиля в приложениях, ориентируясь на одну конкретную среду рабочего стола или на конкретный инструментарий. Это также позволяет избежать непосредственной работы с ICCCM.

Протокол X не предоставляет никаких средств для работы со звуком. Поддержка звуковой аппаратуры и воспроизведение звуков возлагается на операционную систему. Поскольку пользователям всё чаще необходим звук, эта ситуация привела к появлению различных несовместимых друг с другом звуковых подсистем. В прошлом многие программисты игнорировали сетевые проблемы и просто использовали локальные звуковые API операционной системы. Первое поколение клиент-серверных звуковых систем включает в себя rplay и Network Audio System. Более современные системы — PulseAudio, esound в GNOME и aRts в KDE. Также начата разработка новой системы — Media Application Server.

До недавнего времени X Window System не включала в себя хорошего решения для печати содержимого дисплеев. Многие X-клиенты печатают в формате PostScript независимо от X-сервера. Механизм Xprint впервые появился в X11R6.3; его клиентская часть работала хорошо, в отличие от многих серверных реализаций. Версии X11R6.8 и выше функционируют нормально и набирают популярность в инструментариях элементов интерфейса.

Сеть

В X Window System нет возможности отключить X-клиент или сеанс от одного сервера и подключить его к другому серверу. Работа над добавлением этой функции в X уже ведётся. Существуют обходные механизмы, которые делают экран текущего X-сервера доступным через VNC. Или можно использовать подключение X-клиента к проксирующему X-серверу.

Пример туннелирования приложения X11 поверх SSH.

Данные, передаваемые по сети между X-сервером и удалёнными X-клиентами, по умолчанию не шифруются. Злоумышленник может при помощи сниффера перехватить и прочитать эти данные. Для предотвращения этого, как правило, X туннелируется поверх SSH. Большинство реализаций SSH поддерживает туннелирование X-приложений, хотя иногда эти функции по умолчанию отключены.

Независимость от аппаратуры и отделение клиентов от серверов влияет на производительность системы. Сетевая прозрачность X требует, чтобы клиенты и сервер работали отдельно друг от друга. В прошлом это существенно снижало производительность отдельно стоящей системы — по сравнению с Microsoft Windows и Mac OS, где оконная подсистема внедрена глубоко в саму операционную систему. Для нормальной работы X Window System рекомендовалось от 4 до 8 Мб оперативной памяти — значительно больше, чем для Windows или Mac OS.

По идеологии X Window System вся отрисовка элементов окон производится X-сервером. Но, на сегодняшний день было создано достаточно много приложений производящие отрисовку элементов на стороне клиента и передающие эти отрисованные элементы уже как рисунок X серверу. При этом к каналам сети предъявляются повышенные требования по пропускной способности.

Текущие версии Windows и Mac OS X имеют внутреннее разделение графической подсистемы, похожее на клиент-серверное разделение в X, и имеют примерно те же требования к ресурсам, что X с KDE или GNOME. Последнее — очень спорное утверждение, например, загрузка ЦП со стороны X сервера значительно превышает нагрузку процессора со стороны графической подсистемы Windows. Потребление памяти также заметно выше. Большая часть накладных расходов в X теперь приходится на задержку при передаче данных по сети между клиентом и сервером. Существует распространённое заблуждение, согласно которому при локальном использовании X Window System её сетевые возможности отрицательно сказываются на производительности. На самом деле современные реализации X используют в таком случае локальные сокеты и общую память, требуя лишь очень незначительных накладных расходов.



Просмотров: 10580


<<< Open Look
X.Org Foundation >>>