Например, программист
23,6
рейтинг
12 июня 2010 в 16:18

Администрирование → Мысли вслух о протоколе X перевод

Два года назад, работая над Awesome, я присоединился к разработке XCB, который является частью инициативы Freedesktop. Мне пришлось изучить тайны протокола X11 и весь древний и таинственный мир, окружающий его.

За последние несколько месяцев я наконец-то смыл с себя всю эту грязь, и теперь чувствую необходимость поделиться своими размышлениями относительно всего этого беспорядка, длящегося десятилетиями.



Когда меня ещё не было на свете...



… группа Toto выпустила их знаменитую песню «Africa», а несколько умных парней работали над оконной системой — X Window System (это полное имя), у которой тоже (слишком) длинная история. Окончательная версия протокола (11-я) была разработана в 80-х. Вы можете узнать подробности истории в статье на Википедии.

В 2010 году мы по-прежнему слушаем диско, и всё так же используем различные протоколы, разработанные в 80-х (и даже раньше, чем X). Музыка эволюционирует, протоколы меняются, и X11 не стоит на месте.

Проблема в том, что X11 не эволюционирует правильно. Парни из MIT-и-всяких-других-мест-с-умниками создали первую версию X в 1984 и вносили изменения вплоть до 11-й версии протокола. Он был выпущен в 1987 году, и мы используем его по нынешний день. Одиннадцать версий было выпущено за 3 года в полном соответствии с моделью «ранний выпуск, частые обновления». Не знаю почему, но этот подход перестали применять в течение следующих 23 лет (хотя разработчики добавляли (и убирали) множество расширений протокола).

Я не знаю, какие изменения были внесены за первые 11 главных версий протокола X, но я более чем уверен, что за прошедшие 20+ лет назрела большая необходимость внести серьёзные изменения в него.

По моему скромному мнению, X11 не проектировался с расчётом на то, что он будет жить 23 года. Правда, я никого не обвиняю: я был 4-летним ребёнком и играл в Lego , когда была выпущена последняя версия протокола X, так что у меня было очень мало шансов сделать что-то лучшее.

Мы не будем исправлять. Мы будем приспосабливаться



Это, возможно, главный лозунг протокола X последних лет. Только не поймите меня превратно: я не собираюсь устраивать порку.

Протокол X11 старел с годами, и разработчики стали добавлять к нему расширения. За годы были добавлены тонны расширений. В точном соответствии с одним из изначальных принципов X:
Важно чётко определить, чем система является, и чем она не является. Не надо стараться услужить потребностям всего мира; вместо этого следует сделать систему расширяемой так, чтобы дополнительные потребности могли быть удовлетворены подходящим способом.

Все они без исключения были добавлены потому, что (увы и ах) протокол X11 не предусматривал всех появившихся за последние 23 года вещей вроде видео, OpenGL, нескольких мониторов или удовольствия от рисования овальных окошек. Какие-то из этих расширений используются до сих пор, а какие-то уже канули в Лету.

Расширения протокола — это не есть что-то плохое, но попытки исправить протокол расширениями типа XFixes кажутся мне плохой идеей, несмотря на все добрые намерения, которыми мог руководствоваться Keith Packard.

На самом деле всё ещё хуже, чем вы думаете



Протокол X11 (без расширений) определяет около 120 типов запросов: создание окна, передвижение окна, и так далее.

В наши дни как минимум 25% из них совершенно бесполезны: использование шрифтов на стороне сервера или рисование квадратов и полигонов не используются ни одним современным приложением или тулкитом. Все они переопределены в запросах из расширений, таких как, например, XRender.

Работа с несколькими мониторами совершенно запутана. X11 разрабатывался для работы в режиме Zaphod (независимые мониторы). Но Xinerama, а в наши дни и XRandR полностью вытеснили его — последние версии сервера X (примерно с 2007 года) больше не поддерживают режим Zaphod, несмотря даже на то, что он является частью ядра протокола X11.

Даже хуже: многие запросы содержат ограничения или изъяны дизайна, например те, что описаны в документе исследователей из DEC: Почему X не наша идеальная оконная система.

Мы навалим сверху ещё больше сломанных стандартов



Следуя своим изначальным принципам, X не определяет политики, а только предоставляет механизмы, что выглядит правильным.

Вследствие этого, разработчики собрались и начали сочинять спецификации, чтобы определить набор правил и догм: ICCCM. Это было 22 года назад, в 1988 году. Бесполезно добавлять, что многие пункты этой спецификации уже безнадёжно устарели, потому что не учли множество современных технологий.

Я не единственный, кто так считает. Авторы проектов, которые стали двумя главными окружениями рабочего стола, KDE и GNOME, увидели это уже в 90-е, когда я только учился считать. И они написали EWMH, ещё один стандарт, который взгромоздился поверх ICCCM, дополнив его рядом приятных фич (максимизация, полноэкранный режим и прочие).

Проблема заключается в том, что этот стандарт также был написан не особо дальновидными людьми, которые одновременно работали над своими окружениями (GNOME, KDE и, может быть, ещё какие-то). Эти окружения рабочего стола имели тогда и имеют до сих пор целый ряд сильных концепций, определяющих, как должен работать десктоп: «он должен иметь рабочие места (workspaces)», «окно может существовать только на одном рабочем месте», «мы можем видеть только одно рабочее место в один момент времени», «у нас нет нескольких экранов», и так далее.

Чувак, не парься: у нас есть тулкиты!



Представление о том, как должен работать десктоп, в наше время высечено в мраморе для каждого приложения или библиотеки, реализующей EWMH, в том числе GTK+ и Qt.

В итоге, сейчас все просто позабыли про стандарты. Тулкиты реализуют их самостоятельно, обходя ограничения и изъяны протокола X11, и никто не хочет оглянуться назад.

И с этими тулкитами люди обращаются так же небрежно, как и со стандартами. Это порой приводит к неприятным сайд-эффектам. Например, Openoffice в качестве переключателя рабочих мест.

Мы не хотим оглядываться? Хуже, мы забыли, откуда пришли!



Рабочий стол со всеми этими плохо спроектированными стандартами продолжает эволюционировать более десятилетия. В него продолжают добавлять новые стандарты, самые последние из которых базируются на D-Bus, например, Desktop Notification Specification или свежий Status Notifier Specification, разработанный в KDE.

Status Notifier — это новая реализация старого доброго системного трея, основанного на XEmbed, но теперь использующая механизмы D-Bus вместо X11, и добавляющая возможность показывать в системном трее что-то большее, чем просто иконки.

Черновик спецификации содержит серьёзный изъян дизайна, на который обратил внимание Wolfgang Draxfinger в своём обращении в список рассылки XDG. Вольфганг указывает, что X является сете-ориентированным протоколом, а D-Bus — нет. Следовательно, использование D-Bus спецификацией Status Notifier для передачи событий системного трея является плохой идеей: запуск графического приложения с компьютера А на компьютере В обновит трей на неправильном хосте!

Из чтения переписки очевидно, что это не пугает некоторых разработчиков KDE:
Разумеется, не стоит сильно беспокоиться об этом причудливом частном случае. По крайней мере, вы будете считать его таковым до тех пор, пока сами не столкнётесь с ним (просто тестируя что-нибудь или настраивая какой-нибудь изощрённый киоск)."

То, что Освальд описывает как частный случай, для многих из нас является самой типичной ситуацией. В общем, кому как повезёт.

На мой взгляд, это шаг назад в неправильном направлении. Но мы можем также сделать вывод, что сетевая часть X стала бесполезна, по крайней мере, для KDE.

Я предпочитаю верить в XCB



Когда я присоединился к Freedestop, мне пришлось поработать над библиотекой XCB, X C Binding. XCB обладает приятным, чистым, основанным на технологиях 21 века API для работы с протоколом X11. Его код генерируется автоматически на основе XML-файла с описанием протокола.

Для сравнения, Xlib состоит из мутного кода 80-х кодов, практически не комментированного и полного жёстко закодированных вещей. Лишь немногие способны понять некоторые его закоулки, вроде интернационализации или реализации XKB. И весь его код синхронный.

Поясню для тех, кто ещё не в курсе: X — это сетевой протокол, в котором вы должны послать запрос (как GET в HTTP), чтобы затем получить ответ. Xlib заставляет приложение ждать ответа на запрос, поэтому приложение блокируется до тех пор, пока сервер X не пришлёт ответ. XCB же не блокирует приложение, что позволяет послать серию запросов, сделать что-то полезное за время ожидания, а затем получить ответы.

Представьте, что ваш браузер посылает на веб-сервер по одному запросу за раз и заставляет Вас ждать показа страницы до тех пор, пока не закачает самую последнюю картинку.

В случае, когда X и все его клиенты расположены на одном компьютере, задержка невелика и незаметна, поэтому выгода от асинхронности XCB мала. Однако на медленной сети прирост производительности может быть огромен, что и доказал Peter Harris, переписав xlsclients на XCB.

Одна из долговременных целей разработчиков XCB — окончательно избавиться от Xlib, чтобы увеличить скорость и уменьшить время отклика приложений X11. Для этого необходимо портировать множество библиотек, потому что почти ни одна из них (за исключением Cairo) не поддерживает XCB.

С моей точки зрения, сейчас это довольно бесполезный труд. Десктопный мир доверен проектам GNOME и KDE, то есть, GTK+ и Qt. При этом похоже, что ни один из этих тулкитов не заинтересован в работе ни над XCB, ни над протоколом X. Они скорее прилагают большие усилия, чтобы обойти существующие ограничения и изъяны X, и по прежнему сидят на вершине кургана из костылей и реализаций порочных-по-дизайну-стандартов. Мне кажется, что никто не хочет оглянуться назад на все эти уровни и посмотреть, как их можно улучшить.

Они залезли слишком высоко, чтобы взглянуть вниз и увидеть, какой может быть отдача.

Enlightenment со своим EFL был первым тулкитом, который имел XCB-бэкенд (благодаря работе Vincent Torri). К сожалению, этот бэкенд уже не поддерживается, и никто о нём не заботится. В последний раз, когда я за него брался, он даже не компилировался.

X12?



В вики Freedesktop есть страничка под названием X12, на которой перечислены все вещи, которые должны быть исправлены. К сожалению, этот список только растёт, а о работе над X12 никто не заикается.

С другой стороны, есть несколько людей, которые в свободное время работают над XKB2, второй версией «давайте-снова-попробуем-исправить-клавиатурную-часть-протокола-написанного-23-года-назад» расширения.

В общем, не похоже, что X12 появится в ближайшее десятилетие.

Альтернативы?



Есть ли у нас альтернатива X? Есть Wayland, но он пока что довольно бесполезен. Также есть DirectFB, но он плохо портируем. На мой взгляд, пока что нет кандидатов на замену X.

В любом случае, ни один из главных тулкитов не поддерживает подобной альтернативы. GTK+ когда-то поддерживал DirectFB, но, насколько я знаю, сейчас уже ничего не работает (как отмечает Josselin Mouette). Именно поэтому последние версии установщика Debian переехали на использование X в графической части (благодаря работе Cyril Brulebois).

Заключение



XCB существует более пяти лет, но заинтересовались им совсем немногие. Насколько я могу наблюдать, никто не заинтересован использовать протокол X, все просто стараются инкапсулировать его каким-нибудь высокоуровневым API, чтобы как можно быстрее перестать его видеть. Это приводит к появлению плохо написанных приложений и тулкитов, набитых уродливыми хаками.

Всё это также значит, что написание новых приложений и тулкитов на базе XCB должно быть очень интересным проектом, однако для этого придётся потратить чересчур много времени, чтобы понять, как обходить изъяны протокола X, внесённые за многие годы предшественниками, в том числе Qt и GTK+.

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

В мире X слишком мало рабочей силы. Нехватка мэйнтейнеров X в Debian — простое следствие этой ситуации. Конечно, существуют очень компетентные и квалифицированные разработчики X, в чём легко можно убедиться, читая блоги на Planet Freedesktop (я не в счёт). К сожалению, их количества недостаточно для того, чтобы покрыть всю сферу деятельности X: устройства ввода, графические устройства, спецификации новых расширений протокола и так далее. Сервер X — достаточно поздняя разработка, и большинству разработчиков интереснее работать над ним, а не над самим протоколом. Это можно понять.

Мне интересно, куда мы придём со всем этим через несколько лет. К нынешнему времени я варюсь в котле под названием X уже 3 года, и чувствую, что рано или поздно все альтернативы KDE и GNOME вымрут. Время, когда Вы могли выбирать между дюжиной «современных» оконных менеджеров, прошло.

В конце концов, может быть, это простой дарвинизм в применении к компьютерному софту.

Примечание переводчика: автор этой статьи — французский программист Julien Danjou, разработчик оконного менеджера Awesome. Оригинал статьи расположен здесь. Это мой пер Я давно не практиковался в переводах, поэтому буду благодарен за исправления и уточнения.
Перевод: Julien Danjou
Андрей Хитрин @zloddey
карма
112,0
рейтинг 23,6
Например, программист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (144)

  • +4
    интересная статья, спасибо.
  • +6
    Qt прекрасно поддерживает directFB и в общем то может быть портирован на любую оконную систему. А у Иксов проблема, что там слишком много всего, что-то отмирает, что-то опять нарождается. Вот новая спецификация трея в принципе хороша, но она потеряла сетевую прозрачность. Хотя наверное добавить в DBUS сетевую прозрачность вполне выполнимая задача.
    • –1
      > сетевую прозрачность

      а оно реально нужно? что-то я давненько не слышал о реальных применениях этой штуки.
      • 0
        видимо нормального ответа, кроме минусования, не дождусь. сдается мне, никто и не знает зачем нужна сетевая прозрачность :)
        • +2
          Насколько я знаю (не очень хорошо, немножко только) x11 разрабатывался именно как сетевой протокол. Стоит у вас сервер и показывает окошечки, а клиент (сами программы, которые что-то там делают) — где-то далеко. Сейчас и то и другое обычно стоят на одном компьютере и про то, что это сетевой протокол, все начали забывать.
          А ведь удобно же было бы иногда — запустить удаленно программу и наблюдать ее работу у себя на экране.

          Ну так вот DBus — он работает на клиенте и про сервер ничего не знает, наверное, вот и вся проблема.

          Если говорю неправильно — поправьте, пожалуйста :)
          • +8
            я знаю про клиент-серверную архитектуру иксов. но, во всех популярных дистрибутивах линукса X запускается с ключиком -nolisten tcp, а коммуникация между сервером и клиентом происходит через сокеты. более того, в 99.9% случаев это и не нужно. ради 0.01% тащить значительный overhead?
            а запускать удаленно программу можно (и нужно) через ssh X forwarding.
            DBus практически никаким боком к X и не пристегивается, это совсем другая штука, предназначенная для коммуникации между приложениями.
            • +3
              я не очень в теме, а ssh x forwarding — это не то же самое, только через ssh?
              а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?
              • +2
                > а ssh x forwarding — это не то же самое, только через ssh?

                нет, X forwarding — это запуск приложеня чрез ssh туннель. а та штука которую мы обсуждаем, нужна для организации удаленной X сессии.

                > а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?

                нет, там хотят сделать отдельный протокол для трея.
                см. standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html
                • 0
                  буду знать, спасибо за пояснения
                • +1
                  как будто ssh X forwading форвардит UNIX сокеты, а не tcp пакеты
                  • –1
                    там совсем другой механизм работы, для него совсем не нужна вышеописанная прослойка.
                    • +3
                      И какой? Такие же сокеты просто проброшенны через ssh.с Сетевая прозрачность нужна, другое дело что не нужна половина классического X11 давно уже не нужна т.к. используются расширения вроде xft и xrender.
                      • –1
                        > Сетевая прозрачность нужна

                        нужна в очень редких случаях. почему-бы не сделат её хотя-бы отключаемым модулем?
                        • +1
                          А мешает? Пакеты так или иначе нужно сериализовать/десериализовать, не важно через что отправляя, через сокеты или через shared memory.
                          • –1
                            лишнее время/ресурсы гонять данные через сокеты.
                      • –1
                        мне кажется, сетевая прозрачность для Х уже не так актуальна. На деле Х форвардинг работает криво и тормознуто. Приходится искать альтернативы в виде NX
                  • –1
                    со стороны клиента — tcp, со стороны сервера — локальный сокет.
              • 0
                > а насчет dbus — разве его как раз не хотят сейчас пристегнуть боком к иксам?

                хотя, возможно, что-то такое в DBus и делают, но это уже не на уровне иксов, а выше, DE/WM.
            • 0
              В технологии X сервером называется клиентский терминал. А клиенты в терминологии X — это приложения, которые запущены на удаленных машинах (множественное число, обратите внимание). То есть ваш терминал (то бишь X-сервер) может отображать окна приложений исполняющихся на разных машинах находящихся в разных концах земного шара.

              Что по-вашему в этом случае должен отображать системный трей? Или каждая удаленная машина должна вам в рисовать свой собственный системный трей?

              На каждой из этих машин ведь может быть запущен свой dbus. Про сеть dbus ничего не знает, не говоря уже о том, как передать сообщение в ваше приложение в соседнем окне, которое исполняется на другой машине… Надеюсь так понятней должна быть проблема…
          • 0
            да, забыл добавить. клиент-серверная архитектура разрабатывалась когда в моде были большие мейнфреймы и терминалы.
            • +9
              Так сейчас облака и тонкие клиенты снова становятся модными.
              Так что клиент-серверная организация — это тру.
              Если все происходит в одной сети организации, то ssh будет лишней тратой ресурсов.
              В декстоп-ориентированных дистрибутивах, действительно, имеет смысл по умолчанию отключать сетевое взаимодействие. Однако лет 5 назад, на семинарах по информатике, я очень любил коннектиться с учебного компа на свои домашние иксы и работать на них. Свои настройки, удобно.
              • 0
                оно нужно в очень редких случаях. зачем тащить на десктоп клиент-серверную архитектуру иксов если она фактически не используется как задумано но таки вносит свой overhead? а для облаков и прочих тонких клиентов есть более эффективные решения.
                • 0
                  Если создавать новые несовместимые протоколы, то будет полный зоопарк графических оболочек. Гном под иксы, гном под DBUS; Кеды под гном и под DBUS и т.д. А потом кто-нибудь придумает еще что-нибудь, и нужно будет создавать новую ветку оконных менеджеров. При этом фичи из одной ветки в другую будут попадать не сразу, и прочие радости от кучи стандартов. Да, а еще разработчикам программ, наверное, тоже надо будет писать кучу лишнего кода для каждой из версий. Плюс в подарок потеря совместимости.
                  Нафиг-нафиг.
                  С моей точки зрения вполне логично просто на десктопах отключать сеть, как это происходит сейчас.

                  К тому же, тут еще вопрос, кто важнее: 1000 юзеров десктопов убунты, или меньшее количество пользователей компании с 1000 компами, которые используют эту фичу в своей работе.
          • +3
            Много там проблем. В какой-то момент отказались от задания шрифтов в X-сервере. Теперь при работе по сети на сервер летят картинки с отрисоваными буковками вместо команды «написано ААА шрифтом БББ». Требования к сети кардинально возросли.
      • +2
        Мне нужна, регулярно иксы по сети использую.
      • +1
        а на самом деле в энтепрайзе vnc и запуск иксовых приложений сквозь сеть распространены повсеместно.
        • 0
          vnc кидает картинку экрана. с сервера на клиента.
          это совсем не то, что команды отрисовки.
          • +1
            вот только на текущий момент почемуто проброс, например, браузера, через инет работает в разы медленнее чем просмотр растровой картинки через vnc :(
            • 0
              А текстовые интерфейсы через ssh работают ещё быстрее. ;)

              Это вина тулкитов. Сравните kpdf и xpdf через сеть.
      • 0
        терминал серверы.
        ltsp.
        eubuntu.

    • 0
      там и без того с сетью уже не так все хорошо. недавно пробовал krusader запустить и он крашился непонятно почему. старый трюк с export DISPLAY= уже недостаточен.
  • –1
    спасибо за статью)
    • +10
      Спасибо за комментарий!
  • –13
    помнится, запускал я на маке какой-то софт, работающий из-под иксов.
    (Х11 в макоси сразу есть)
    это такой страх и ужас и нереальный тормоз, что мозгой двинуться можно…
    • НЛО прилетело и опубликовало эту надпись здесь
      • –2
        Согласен. Все Х программы выглядят как-то совершенно инородно, и работают с тормозами и глюками.
  • +2
    Как всё страшно… Блин, а это даже не Windows с его костылями в WinAPI…
    • –1
      Можете привести пример костыля WinAPI?
  • +3
    Спасибо. Я и не думал что всё так страшно.
    • +2
      Я тоже.
    • +7
      все еще страшнее. man xorg.conf:

      VIDEOADAPTOR SECTION
      Nobody wants to say how this works. Maybe nobody knows…

  • +7
    Пробовал писать на XCB оконный Hello World с часиками: это же ужас какой-то! Во-первых, объем кода больше, чем тот же случай на Xlib, раза в два-три. Более того, вменяемой документации по XCB нет. Даже официальный мануал написан очень и очень поверхностно.
    Остается качать исходники и заглядывать, анализировать… И после этого обвинять тулкиты в несоответствии стандартам уже как-то не особо и хочется — во имя результата все средства хороши, особенно если они преподносят его на блюдечке. Уж на тот же Qt я по части документации ругаться точно не буду… Не говоря уже о всяких прелестях вроде QtCreator и т.п.
    • +1
      Согласен, именно внимания к деталям, не хватает многим хорошим проектам. Qt одной только качественной документацией способна прельстить программиста, уставшего от ковыряния разрозненной информации в сети. И пока у XCB не будет более дружественного лица, не появится и мощного сообщества. А жаль…
      • 0
        А в чем проблема насильно портировать Qt и GTK+ на XCB, убрав поддержку Xlib, помимо лени? Ведь подавляющее большинство программ пользуются лишь возможностями тулкитов.
        Но что GNOME, что KDE, скорее всего, придется переписывать чуть ли не с нуля.
        • +1
          Проблема в том, что это лишь мнение одного человека — автора awesome. Вот пришел он, сказал, условно, что Xlib — какашка, а XCB — это очень круто. Придет другой человек, скажет, что Xlib — нормальная, культурно написанная, поддерживаемая и документированная библиотека, а XCB — поделка двух с половиной студентов с неудачным API, плохо документированная и вообще глючащая через раз. И кому верить?

          Поставьте себя на место разработчика GTK/Qt. Например, XCB есть сильно не везде. В дистрибутивы оно массово начало вливаться в 2005-2006. Кое-где его до сих пор нет. Сейчас можно достать какой-нибудь дистрибутив с иксами 1998-2000 года выпуска и там будут работать все современные KDE-Qt-GTK-GNOME-приложения. Менять шило на мыло (о чем, кстати, и говорит автор awesome) с приобретениям какого-то количество явных минусов и небольшого количества эфемерных плюсов, видимо, далеко не все хотят.
          • +2
            > можно достать какой-нибудь дистрибутив с иксами 1998-2000 года выпуска и там будут работать все современные KDE-Qt-GTK-GNOME-приложения
            Не заработают :)
            Новый Qt/GTK+ требует новый glibc, новый glibc требует новое ядро и далее по списку.
            • +1
              правда? а почему же последний Qt собирается до сих пор с древними gcc?
              или мы путаем своместимость бинарную и на уровне исходников?
            • +1
              Только вот вчера собрал Qt 4.5.2 c gcc 2.95 на ядре 2.4.22
              • 0
                Осталось пропатчить KDE… ©
                • 0
                  шутка помоему про FreeBSD была, а не про Linux :)
          • +2
            Xlib объективно проигрывает по скорости XCB за счет своей модели запросов. Сверх того, в XCB вся соль в наличии у многих действий, единиц идентификаторов — многопоточный код наворачивать гооораздо безопасней.
  • 0
    Поправьте «Накие-то»
    • 0
      Исправил. Спасибо!
  • 0
    Мне кажется, что слово pager, в баге ООо, в русском переводе должно звучать не совсем пейджер, но, черт возьми, не видно для него другого перевода, как и для еще нескольких слов:(
    • +2
      Я прошёлся по паре ссылок и нашёл определение слова pager в стандарте EWMH:
      A pager offers a different UI for window management tasks. It shows a miniature view of the desktop(s) representing managed windows by small rectangles and allows the user to initiate various window manager actions by manipulating these representations.


      То есть, это область, в которой рисуются миниатюры окон с рабочих столов (в виде прямоугольников). В XFCE и GNOME эта область назывется "Переключатель рабочих мест". Пожалуй, так и переименую. Надо было проверить это ещё при переводе. My fault :)
      • 0
        Тогда уж «рабочих столов»
    • +1
      Страничник :)
    • 0
      а что за пейджер такой?
      • 0
        Было «OpenOffice в качестве пейджера», с ссылкой на другой пост того же автора.
  • +1
    Можно заметить, что Х — не единственный неидеальный протокол. Все знают семиуровневую модель OSI, но вот статья о самой OSI:
    en.wikipedia.org/wiki/Open_Systems_Interconnection — English
    ru.wikipedia.org/wiki/Open_Systems_Interconnection — Русский
    OSI дал плоды в теории и совсем новых протоколах, но была у них и попытка заменить неидеальный TCP/IP чем-то новым более гибким, а для замены совсем тупого SMTP предлагался монстрик X.400. Иксам по сложности ещё очень далеко до какого-нибудь HTML/CSS, так что путь эволюции ещё по-видимому не исчерпан. Хотя конечно, революции бывают.
    • +1
      Если покопаться, можно найти очень древнее решение, определяющее сегодняшний IT. Ну, все знают по ускоритель шатла и двух римских лошадей.
      • +1
        я не знаю о0"
        • +6
          «Конструкторы многоразового космического корабля „Кеннеди“ не могут увеличить мощность его ускорителей, потому что их диаметр (1,524 м) определяется… шириной лошадиного крупа».… Каждый из двух твёрдотопливных ускорителей американского «Шаттла» имеет длину 45,7 м и диаметр 3,7 м (в районе топливных сегментов двигателя). Наружный топливный бак, который содержит криогенное топливо для питания маршевых двигателей «Шаттла», имеет диаметр 8,4 м. Дело в том, что двигатели эти доставлялись по железной дороге, которая проходит по узкому туннелю. Расстояние между рельсами стандартное: 4 фута 8,5 дюйма (1,435 м), поэтому конструкторы могли сделать двигатели только шириной 5 футов. Вопрос: почему расстояние между рельсами 4' 8,5"? Откуда взялась эта цифра? Оказывается, железную дорогу в Штатах строили такую же, как и в Англии, где, в свою очередь, железнодорожные вагоны делали такими же, что и трамвайные, а первые трамваи производились по образу и подобию конки. А длина оси конки составляла как раз 4' 8,5".

          Но почему? Потому что конки делали с таким расчётом, чтобы их оси попадали в колею на английских дорогах – благодаря этому колёса меньше изнашивались, – а расстояние между колеями в Англии как раз 4' 8,5"! Отчего так? Да просто дороги в Великобритании стали делать римляне, подводя их под размер своих боевых колесниц, длина же оси стандартной римской колесницы равнялась… Правильно, 4' 8,5"!

          Первые колейные дороги Древней Греции и Древнего Рима, представлявшие собой углубления до 50 мм в каменном основании, имели ширину 1,5–1,6 м. Это соответствовало ширине уличных экипажей.

          Ну вот, теперь мы поняли, откуда взялся этот размер. Но всё же, почему римлянам вздумалось делать свои колесницы с осями именно такой длины? А вот почему: в колесницу запрягали обычно двух лошадей.
          А 4' 8,5" – как раз размер двух лошадиных задниц! Делать ось колесницы длиннее было неудобно, так как это нарушало бы её равновесие. Суммарная ширина крупов двух лошадей намного больше длины оси колесницы.
          отсюда
          • 0
            жуть х))) спасибо
        • 0
    • +7
      У HTML/CSS вообще баг by design. Они описывают статический контент, а от них хотят динамического.
      • +7
        Если бы в шестидесятых годах прошлого века разработчики SGML из ну очень важной компашки IBM только знали… Если бы только знали… :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Не распарсил про directFB… Сейчас эта штука в общем то к линуксу гвоздями прибита, там есть серьезные проблемы с I/O драйверами, точнее приходится много плясать, иксы в этом плане хорошую абстракцию дают. Код XInput хорошо бы оставить в любом случае. Вообще по хорошему можно весь рендеринг клиентский на openGL перевести, а его инструкции по отрисовке по сети гонять. Скоро уже все свободные драйвера точно будут уметь openGL аппаратно. Что-то такое как раз в Wayland'е предлагают.
      • 0
        триста раз сказано — X-протокол это не только графика, но и управление (окна, кнопочки, иконки, трей,… ШРИФТЫ наконец, про которые уже все давно забыли и гонят битмап), клавиатура, буфер,…
    • 0
      >В итоге опять кучу времени тратим над настройку над Х
      Кто тратит? Уже давно всё в тулкитах есть, старые API протокола никто не использует, просто болтается исторически.
      >Лучше уже занятся Wayland
      Идея хорошая, согласен. Особенно если оставить в нём слой совместимости с X для сетевых приложений. Но скорее всего так и останется прототипом :(
      >Или уж directFB, там не плохая портированость, а не желания производителей видеокарт под него делать свои драйвера и карты.И есть не адекватная поведение и эффект зеленного экрана.
      Так сейчас все опенсорсные драйвера в ядро переезжают, правда я не знаю юзает ли directfb dri. Кстати, разве directfb не linux-only?
      >Еще можно рабочее окружение и т.д в полном opengl,openal и opencl отриосвать и сделать, ресурсы позволяют для современных ПК, так извращатся, даже рабоать именно только через них и sdk
      Да, EGL/OpenGL/OpenVG было бы круто. Но всё равно помимо EGL ещё нужен слой для управления окнами и воодом.
      • +1
        > Идея хорошая, согласен. Особенно если оставить в нём слой совместимости с X для сетевых приложений. Но скорее всего так и останется прототипом :(
        Если над ним будет работать один Кристиан — то да. Если же люди, которых этот перевод должен был мотивировать заняться X12, вместо этого помог разработке Wayland — всем, я полагаю, будет лучше. Поправьте меня, если я ошибаюсь.
  • 0
    Из этой статьи я не уяснил для себя одного — почему же у графического интерфейса X11 такая низкая производительность. Интерфейс Windows XP с его убогим GDI уделывает юникс приложения в пух и прах (и это заметьте без всяких там композит манагеров).
    • +2
      Выходит, что не таким уж и убогим.
      • 0
        У GDI другая убогость… Хотя он да, быстрый ибо таки в ядре.
        • +3
          «Убогий набор инструкций процессора RISC» :D
          • –2
            Убогий он потому, что в ядро вбит. Очевидно же)))
    • 0
      при использовании всевозможных расширений типа EXA ни сколечки не уделывает по производительности, но вот разработчики проприетарных драйверов как-то через жопу эти расширения юзают.
    • +1
      Зато виндовый ремоут десктоп это фейл.
      Я в подробностях реализации не разбираюсь, но за счёт его синхронности и, видимо, за счёт упомянутой вшитости в ядро он может любой мощности сервер затормозить капитально когда ремоутная сессия по медленному каналу идёт (а если это веб сервер под нагрузкой то канал полюбому занят будет).

      Тоесть сервер всегда ждёт пока у клиента всё прорисуеться, и при этом ожидании тормозятся всякие вещи, которые по идее должны были бы быть совершенно независимы. Ясно, что при загруженном канале тормоза начинаются неслабые, и ремоутный сервер начинает нездорово тупить. А ведь через консоль винды и виндогуйные проги особо не поадминистрируешь.

      Я как мог описал это в своём блоге (на английском) + пруф видео какое-никакое состряпал — mvmn.wordpress.com/2010/02/11/microsoft-rdp-protocol-a-failure/ — но опять же я в технических деталях не разбираюсь, потому особой информативности не обещаю.
      • 0
        А для Vista/Win 7 подобная проблема характерна?
        • 0
          Не знаю, я пробовал 2003-й сервер, но тот кто рассказал мне эб этой проблеме испольщовал 2007-й сервер насколько я помню, так что подозреваю что и Виста и 7-ка работают так же.
      • +3
        ничего что msts едва ли не единственная реализация со вменяемой работой с сессиями, да и сам рдп гораздо гораздее на тормозных аплинках чем ваши иксы, внц и тому подобный «свободный» шлак.

        при желании все няшки винды и ад вполне на ок крутятся из консольных утилит. другое дело что sshd в коробку не положили, это да, печально. а насчет каналов, я уж не знаю какие у вас каналы там, но вот кстате особенно заметна разница между рдп и всем остальным именно на узких каналах. вы бы попробовали в mstsc или в вашем любимом rdesktop'е выкрутить гайки цвета и настройки оформления со стороны сервера в минимум. даже на 256 килобитах с ~1-2 секундной задержкой msts отрабатывает вполне сносно. вот уж чего не скажешь о vnc и прости господи лядского X11.
        • 0
          > ничего что msts едва ли не единственная реализация со вменяемой работой с сессиями,
          > да и сам рдп гораздо гораздее на тормозных аплинках чем ваши иксы
          Не знаю так ли это, не имел много возможностей проверить, но по части сесий у RDP уже коммерческая проблема, ибо за сессии приходиться платить, а для не серверных версий так вообще нельзя иметь больше одной сесии — на моих виндах нельзя сидеть за компом одновременно прямо и ремоутно, хотя и версия профешнал а не хоум.

          Про тормозные аплинки тоже както не уверен. По крайней мере под Х-ами это не заставит тупить сам сервер, вот и радости. Ну и ясно что главное преимущество линухов и т.п. — возможность более чем адекватного администрированя через терминал. Под виндами же без GUI никуда. Может сами они и ок с консольными утилитами (что тоже не правда), всёравно из сторонних вендоров никто не пишет апликух под винды способных адекватно работать через консоль.
          Я даже не знаю можно ли адекватно IIS админить через консоль — подозреваю что нельзя.

          Насёт каналов, я уже упоминал что сам канал может быть вполне адекватным, но т.к. сервер то в продакшне и под нагрузкой то скорость сети может быть достаточно низкой.
          • 0
            не надо подозревать, надо открыть и прочитать. IIS можно управлять через его вебморду http(s), так же в IIS 7.0 есть powershell с плагинами для его управления, а еще есть appcmd.exe, — тулза для управления IIS'ом из консоли. вот так-то! альтернатива для msts есть. :)

            не представляю каким образом ожидание телодвижений со стороны mstsc заставит «тупить» рабочие задачи. или у вас рабочие задачии в фореграунде в пользовательской сессии? ну тогда msts тут не причем. к слову о рабочих задачах в сессиях, по сей день единственным вариантом тюнинга 1С для работы с большим количеством клиентов по-прежнему является работа через msts (да, еще использования *SQL бакенда, ну да это не суть важно).

            у микрасофта в серверных приложениях есть несколько интерфейсов взаимодействия, нынче гуи, павершелл, вебморда и какая консольная тулза. возможно не у всех приложений есть полный набор, но альтернатива есть в любом случае. насчет сторонних программ ничего не скажу, не особо ими пользовался, может быть тут вы правы.
          • 0
            не кормите тролля :)
  • +1
    Хорошая статья. А главное, это ведь основа, без которых немыслима работа с UNIX на desktop'е. Надеюсь кто-нибудь найдет в себе силы и перепишет всё как следует.
    • +8
      Ну да. Именно такие мысли и сподвигли меня сесть и потратить пару вечеров на перевод. Статья-мотиватор.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Дело в том, что X11 это не только сокеты, он также умеет работать и через shared memory, dbus же на сокеты завязан. К примеру в android там тоже весь управляющий трафик по их IPC гоняется (сраный binder), но буферу куда изображения рендерятся лежат в shared memory (кстати у них на это тоже свой велосипед).
  • +2
    Спасибо за перевод! Читал статью в оригинале ещё давно, понял что X11 — самая ужасная и уродливая часть современного Linux-десктопа. Хотел сам написать такую статью, но руки не доходили.
    X11 must die.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        В идеале что-то вроде Wayland. Весь рендеринг окна client-side, напрямую в графические буферы, а графический сервер занимается только смешиванием всех буферов в окончательную картинку. Жаль, что Wayland пока не особо шевелится.
        • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Шевелится. Пару месяцев назад Кристиан сменил OpenGL на OpenGL ES. К Qt помаленьку прикручивается поддержка Wayland: cgit.freedesktop.org/~jbarnes/qt-wayland/?h=4.7
          • 0
            Интересно. А как вы это нашли? Есть какие-то ссылки на записи в блогах, или что-то такое? (я про branch Qt для Wayland)
            • 0
              Не помню точно. Кажется, на форуме Фороникса эта ссылка была в обсуждении одной из новостей, посвящённой Wayland.
      • 0
        Но это не значит, что иксы не должны сдохнуть в муках.
    • –3
      Уродливей разве что OOo :D
    • 0
      Да чтоб тебя. А заменять чем будем, когда умрет?
    • 0
      Die то не надо, а то будем тогда в черных терминалях сидеть, потому-что адекватных замен нет. Другое дело что надо, перерабатывать то что есть. Нужно пересматривать протоколы, переделывать библиотеки и API. Подстраиваться под сегодняшние реалии, добавлять нужное и что важнее избавляться от ненужного, даже если это иногда плохо сказывается на обратную совместимость.
  • +2
    «Кроме того, я думаю, что X11 должен быть разрушен.»
  • 0
    То-то у меня при любом движении мышкой использование CPU подпрыгивает резко… На процесс X уходит… А альтернатив то нету! (
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      блин, на самом деле. Думал, только в ХР так.
    • 0
      ну, включите аппаратную мышку, чтоли…
      • 0
        Расскажите плз поподробней, что за зверь?
        • 0
          Option «HWCursor» в разделе «Device»
  • 0
    Тем кто реально толкает линуксы в массы (большие корпорации, да?) иксы не нужны, так бы уж давно собрались, договорились и написали.
    • +1
      А так и получается, все, кому всерьез нужен графический интерфейс поверх UNIX-OS (не берем серверные применения) рисуют что-то свое, отличное от X-Window System. Как пример — MacOS X и Android.
    • 0
      никакие большие корпорации линуксы в массы не толкают, а толкают они на рынки серверов, где GUI то и не особо нужен
      • 0
        спасибо капитан
  • –2
    Есть мнение, что это так и не сдвинется с мертвой точки до тех пор, пока это не будет нужно кому-нибудь типа Google для чего-нибудь типа GoogleOS.
    • +2
      Гуглы взяли обычный xlib
      • +1
        А что мешает им на каком-то этапе развития своей ОС это изменить?
        • 0
          Ничего
          • +1
            Имхо дрова.
            • –1
              Зря по вашему делают KMS+DRI2? Они как раз позволяют от иксов отвязаться
  • 0
    Напомнили про ICCCM. В нём содержится небольшая и игнорируемая «современными» DE (альтернативы которым умрут по мнению автора) заметка. Сервер имеет право отказать в изменении размера окна, и клиент должен рисоваться в той клиентской области, которую ему дадут. Программки вроде XMMS и половины модулей Gnome и KDE это игнорируют, чем создают большие проблемы при использовании фреймовых WM'ов. Сейчас в GSoC вроде появился проект по добавлению фреймового режима в kwin, может и клиенты начнут чинить.
  • –4
    Месье Жульен, видимо, не знает об Икс-Сервере Попова
    • 0
      Вы серьёзно считаете своё выссказывание смешным или остроумным?
      • +1
        конечно (я думал, это очевидно)
  • 0
    Качественный и интересный перевод. Спасибо. /*грустно вздыхает*/ Побольше-бы такого контента на хабр.
  • 0
    а как-же QWS как альтернатива? Конечно сейчас это достаточно примитивно — но как минимум KDE на QWS можно запустить, а он в свою очередь может работать и над иксами и над DirectFB и напрямую с видеодрайвером. Очень универсально. Я думаю в таком направлении нужно двигаться.
    • –1
      И получить пляски с устройствами ввода, это основная трабла фреймбуфера.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      а можно ссылку на вьювер? PPA для lucid есть? ))
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          ppa — это репозитарий с программой для убунту на ланчпаде.
          • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    это чтоже…
    «системный трэй» не работает для удалённых клиентов по сети?

    неправда, однако.

    под кубунтой-9.10 kde-4.3 ltsp-5
    на терминалах регулярно (из-за сброса настроек) всплывают уведомления типа
    «аудиокарточка %название_аудио_насервере% не работает, переключаюсь на pulsaudio»
    тоесть уведомление с сервера отрисовывается на терминале, подключённому по tcp.

    что я делаю не так?
    • 0
      Отрисоваться-то он отрисуется — его же иксы рискуют (само сообщение). Вопрос в том, на каких рабочих столах и у каких пользователей :)
      • 0
        ну, с двумя сессиями от одного пользователя даже локально нифига не работает.

        а насчёт десктопов вроде всё нормально.

        но надо бы проверить.
        есть какой-нибудь стандартный способ создать уведомление в kde?
      • 0
        kdialog --passivepopup отрабатывает на правильном, терминальном десктопе.
      • 0
        другой эксперимент:
        флэшка вставляется на сервере и на терминале (пользователи разные),
        оповещения о ней появляются вполне корректно.

        чисто по опыту, без ртфмства:
        либо информация о dbus не верна/устарела,
        либо на практике в ltsp используются какие-то хитрости.
  • +1
    И снова попытки делать супер-пупер универсальный велосипед…
    Какие-то намёки на OpenGL для удаленных клиентов…
    Что за дикость делить систему по библиотекам а не по функционалу?
    ЧТо мешает выделить три уровня — аппаратный (отрисовка). Есть не плохой пример — модель DirectX. Сделать тоже самое на OpenGL (собственно уже есть) + аналог DirectInput.
    Поверх прикрутить менеджер рабочий столов.
    А уже по верх прикрутить удалённый рабочий стол.
    Зачем парить мозги попытками передать OpenGL по сети? Это не тот уровень и не та задача. Гнать нужно уже уровень окон.
    И будет замечательная структурированная быстрая и логичная система.
    А проблема, кстати, характерна для большинства Linux — софта. Софт разрастает, никто не хочет править старое и никто не хочет документировать — все хотят писать новое. Расширения плодятся. И стоит заикнуться о том что код превратился в болото, что нет не то что документации, а даже способа её получить, так как разработчики ушли, и никто кроме них в недокументированных фичах и настройках не разбирался, что структура проекта утеряна на прочь и он полон взаимопротиворечиых расширений, как поднимается вонь до небес! Начинаются вопли о совместимости столетного оборудованния и софта (и что, из за того, что кто-то где-то использует старьё, весь остальной мир должен довольствоваться тормозами и глюками.
    Начинаются истерики по поводу портирования 1% расширений, которые использует 1% пользователей. И им насрать, что есть более новые и логичные расширения — не переписывать же им свой 1% кода?! Нет. Пусть все остальные тянут с собой это болото.
    А уж какие крики о неподъёмной трудоёмкости… Видите ли нужно обязательно тянуть с собой всё болото и тестировать ена вековом оборудовании.
    А большая же часть аргументов сводится к тому, что «работает, ну и ладно — на наш век хватит, а там разберутся».
    Одно ядро достаточно взять… Вместо того, чтобы разработать/переработать/документировать стандарт на модули драйверов видеокарт все с крим ура лезут голой жопой на кактус и ратуют за их включение непосредственно ядро. Получается чёрный ящик в чёрном ящике. И никто не думает о том, кто и какими силами потом будет тянуть всё это болото по мере увеличения разнообразия видеокарт.
    Короче, говоря — иногда демократия это плохо. И для мира *nix наступает именно такой момент. Корпорации и производители закрытого софта могут волевым решением сменить архитектуру, выкинуть лишнее, изменить идеологию, заставить пользователей обновить железо. Да, каждый раз вопли, слёзы и сопли, но тем не менее это избавляет от мёртвого кода и не нужно совместимости.
    В общем, я лично категорически не понимаю, какой будет выход у сообщества открытого софта.
    • 0
      фразой «гнать уровень окон» вы имеете ввиду передавать по сети уже отрендерёные картинки целых окон?
      • 0
        3D ваще очень капризная и требовательная штука и для хорошей работы количество слоев больше чем ядро-дрова-OpenGL неприемлемо впринципе. Попытки наложить сложную графику на клиент-сервеную архитектуру — так вообще срамота на костылях. И вместо того, чтобы переработать и все оптимизировать по человечески, все придумыывают новые костыли пверх сущестующих, а поверх этих еще одни, и еще и еще.

        Я считаю что графическую систему(иксы в данном случае) надо делать одним цельным куском без разбиения на клиента и сервера.
        • 0
          к иксам цельным куском придётся приделывать костыли для терминал-серверных решений.
          • 0
            Но тогда это будет костыли-опция, а не костыли-по-умолчанию, которые тебе не нужны, но они есть и от этого все работает не так хорошо как мого бы.
            • 0
              ну в принципе, да.
              так логичнее.
  • 0
    Спасибо автору.
    Ситуация из последнего абзаца показательна не только для X-ов, но и для большинства продуктов с долгой историей.
  • 0
    Я подумываю присоединиться к разработке «иксов», там народ ничего особо менять не хочет. Да и не представляю себе как мне себя заставить изучить весь код иксов.
  • 0
    Благодарю за труд, статья из разряда очень интересных.
  • +1
    Дык это, давайте популяризировать проблему, писать на ЛОРах о ней, на Опеннетах, в уютненьких жж-шечках, итд. И все это с лозунгами мол набираем девелоперов. И потом к получившемуся шуму можно за нос притянуть тех же девелоперов X11 и KDE и Gnome. Ну, это в теории.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.