[не мое]Мысли вслух о протоколе X

а черт, опередил xDD

Что-то я не вижу восторженных эпитетов вэйлэнду в треде

> Какая мегатонна софта вообще использует иксы напрямую? Нормальный софт давно пишется с использованием тулкитов

А тулкиты, наверное, работают через астрал. Почитай по ссылке о переходе на XCB, потом попробуй представить себе, насколько сложнее перейти на новый протокол.

и нормально работает даже на винде.

Такой молодой, а такой толстый.

>Что-то я не вижу восторженных эпитетов вэйлэнду в треде

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

> 4. ????

5. ПРОФИТ!

Ну, тогда я добавлю еще одну стандартную фразу - слив защитан.

>А тулкиты, наверное, работают через астрал.

Сейчас будет утверждение, что у нас мегатонна популярных тулкитов?

XCB это просто новая библиотека под старый протокол. Который дерьмо.

Кстати синхронность Xlib это тоже очень плохо для хвалёной сетевой прозрачности. Если по 30 мегабитовой wireless lan файрфокс работает очень жутко и тормознуто, то что с этим же самым файрфоксом станет при средней хреновости ADSL мне страшно представить.

>2. Написать под новый протокол слой совместимости для древнего legacy стаффа. Под макось же иксы есть.

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

>> А тулкиты, наверное, работают через астрал.

Сейчас будет утверждение, что у нас мегатонна популярных тулкитов?

Нет. Сейчас будет утверждение, что ты не читал о внедрении XCB, или, если читал, не понял ее. И еще будет утверждение, что серверную сторону ты не рассматриваешь совсем.

Это неотвратимо. Если этого не сделают авторы новых реализаций, то это обязательно сделает кто-то ещё. Да и будет очевидна разница между программами, окна которых даже ресайзятся с тормозами, и которые работают плавно как на Mac OS X.

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

если ты утверждаешь, что «ВСЕМ_ПОХУЙ» - это серьезная проблема внедрению нового протокола, то соглашусь. Хотя XCB - обертка над устаревшим Х11, и, если она такая прекрасная - почему бы не на ее основе запиливать Х12?

А сама идея то вот в чем. Три пути

1) продолжать пользовать Х11

2) Ждать Х12

3) смотреть в сторону альтернатив.

Среди разработчиков Х'ов нету подвижек к созданию нового протокола. Остается либо ждать и верить,что очередной хак обертки над каким нибудь костылем X11 не повалит все к чертовой матери, либо все таки тыкать палочкой в новичков, например в Wayland.

Я очень рад, что вопрос о качестве сетевой прозрачности в Х'ах ты игнорируешь.

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

А вот Quasar на заметку. Вдруг он Ъ и не знает почему никто не хочет

использовать X11 напрямую, без промежуточных и тормозных тулкитов.

>Это неотвратимо. Если этого не сделают авторы новых реализаций, то это обязательно сделает кто-то ещё.

Если сделает ктото еще - будет падать и сегфолтится, по крайней мере на раннем этапе. Разница станет еще более очевидной)

> если ты утверждаешь, что «ВСЕМ_ПОХУЙ» - это серьезная проблема

Ага. Но на самом деле есть и более серьезная проблема: новое поколение просто не врубается, что такое X Window System, и считает ее чем-то вроде GDI.

внедрению нового протокола

Даже зачистке старого.

Хотя XCB - обертка над устаревшим Х11, и, если она такая прекрасная - почему бы не на ее основе запиливать Х12?

Да можно начать пилить, наверное. Но сколько сил потребует перевод Gtk и/или Qt на XCB, каков будет профит и кому будет нужен результат?

Три пути

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

Я слышу разговоры «X sucks» уже лет 5 как минимум, но пока никто не начал делать замену, хотя эволюционных путей можно придумать как минимум парочку.

Я очень рад, что вопрос о качестве сетевой прозрачности в Х'ах ты игнорируешь.

Я использую X-приложения по сети каждый день, и не замечаю особой разницы с локальным случаем.

> Я использую X-приложения по сети каждый день, и не замечаю особой разницы с локальным случаем.

Интересно увидеть список приложений и узнать ширину канала.

>Я использую X-приложения по сети каждый день, и не замечаю особой разницы с локальным случаем.

Вопрос не о сравнении с локальным случаем, а о сравнении с другими способами сетевой прозрачности. Потому что если есть ктото лучше - значит эту лишнюю сущность можно и прибить?

// хм, мысль. наверное, если в протоколе навести порядок, трафик поменьше станет. Тогда да, тогда все таки очень нужно.

Да можно начать пилить, наверное. Но сколько сил потребует перевод Gtk и/или Qt на XCB, каков будет профит и кому будет нужен результат?

На XCB - никому. Оно хреново документировано, и тащемта проблему не решает. Ради небольшой отсрочки все переписывать - разумно отказатся.

Но сколько сил потребует перевод Gtk и/или Qt на XCB, каков будет профит и кому будет нужен результат?

Не на XCB, а на новый протокол(его реализацию). Разница есть, и существенная.

Но на самом деле есть и более серьезная проблема: новое поколение просто не врубается, что такое X Window System, и считает ее чем-то вроде GDI.

Мои года - мое богатсво, ага. Допустим врубаюсь. А теперь объясни мне, чем же понятие X Window System мешает развитию и эволюции? в X.W.S запрещено выбрасывать устаревшее дерьмо? и причем тут GDI?

>> Я использую X-приложения по сети каждый день, и не замечаю особой разницы с локальным случаем.

Интересно увидеть список приложений и узнать ширину канала.

Eclipse и несколько самописанных на PyGtk, сеть 100мбит/с. Не скажу, что отрисовка Eclipse реактивна, но она и в локальном случае такая.

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

Я вижу одно — X Windows System работает. Скулеж это все.

>X Windows System работает. Скулеж это все.

Железобетонный аргумент. Сравнивать то не с чем.

// поглядываем на qt-wayland

NX и RDP (второе решение win only) нормально работают на 256 kbit CDMA или ADSL.

>>Я использую X-приложения по сети каждый день, и не замечаю особой разницы с локальным случаем.

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

Какими «другими» - NX? VNC? RDP? Насчет RDP сказано в той же ветке на хабре: «Я загрузку своего цел 1300 туалатин доводил до 80%, гоняя мышку по экрану ;)», думаю, с VNC всё еще хуже. Насчет NX было бы интересно, да.

Как раз по дизайну протокол X довольно экономный по трафику (хотя NeWS круче), хотя ради eye-candy тулкиты гоняют по сети битмапы.

Но на самом деле есть и более серьезная проблема: новое поколение просто не врубается, что такое X Window System, и считает ее чем-то вроде GDI.

Мои года - мое богатсво, ага.

Опыт.

Но сколько сил потребует перевод Gtk и/или Qt на XCB, каков будет профит и кому будет нужен результат?

Не на XCB, а на новый протокол(его реализацию). Разница есть, и существенная.

Разницы никакой - XCB не дает профита для разработчиков тулкита, и X12 не даст. Максимум, чего можно ожидать от X12 - это чистый минимальный протокол, дающий доступ ко всем современным возможностям X-сервера. Но поблема в том, что тулкитчики уже имеют к ним доступ, а на протокол им пофиг %)

Допустим врубаюсь.

Ты? Не думаю, но речь была не о тебе: «Вольфганг указывает, что X является сете-ориентированным протоколом, а D-Bus — нет. Следовательно, использование D-Bus спецификацией Status Notifier для передачи событий системного трея является плохой идеей: запуск графического приложения с компьютера А на компьютере В обновит трей на неправильном хосте!», и далее по тексту сабжевой статьи.

> NX и RDP (второе решение win only) нормально работают на 256 kbit CDMA или ADSL.

Как минимум насчет RDP ты или лжешь, или наши определения «нормальности» сильно различаются.

Изложи конкретные, предметные претензии к протоколу. Вот пока я вижу статью, где нет конкретных претензий, а просто фразы типа «все глючит и тормозит». А я пока не вижу, что можно удалить или переделать в core X11, чтобы значительно изменить ситуацию. Да и какую такую ситуацию? Вот глянь спецификацию протокола http://www.x.org/docs/XProtocol/proto.pdf. Где-то со 120-й страницы идет бинарная спецификация запрос-ответ.

У меня есть некоторые претензии, но в сегодня мои претензии в меньшинтсве будут.

Если все претензии будут изложены в виде «да тут вообще всю систему менять надо», то тогда разговор беспредметный. Я не готов участвовать в сломе наработанной и живой инфраструктуры. И смысла не вижу.

>и далее по тексту сабжевой статьи.

вопрос был про запрет на развитие и эволюцию. Думаю, выпусти разрабы Х'ов вычищенный протокол - из тулкитов пропало бы много «ололо страшного говнокода из-за которого тормозят иксы абырабыр», от которого так срет кирпичами Quasar. То есть если тормоза отрисовки - в тулкитном говнокоде - то новый протокол улучшит ситуацию, нет?

Но поблема в том, что тулкитчики уже имеют к ним доступ, а на протокол им пофиг %)

но иксы то хреново отрисовывают. Кто тут виноват тогда? есть версия, что тулкитчики.

думаю, с VNC всё еще хуже.

ковыряюсь в трех удаленных виртуалках периодически, ничего тяжелого не происходит.

Как раз по дизайну протокол X довольно экономный по трафику

почему тогда на практике далеко не экономный? дизайн не соответствует действительности?

> Какими «другими» - NX? VNC? RDP? Насчет RDP сказано в той же ветке на хабре: «Я загрузку своего цел 1300 туалатин доводил до 80%, гоняя мышку по экрану ;)», думаю, с VNC всё еще хуже. Насчет NX было бы интересно, да.

Вот эту строку надо прокомментировать.

NX экономит траффик и увеличивает скорость за счёт jpg сжатия картинок (в зависимости от ширины канала), png сжатия текста (не проверял, но есть подозрение, что с GTK и Qt он шлёт текст в plain виде, идеологически правильно с точки зрения иксов) и более умного механизма кеширования битмапов, которого невозможного добиться дефолтными средствами иксов.

Про RDP и мышку вообще странное утверждение. Я в иксах на локалхосте двигая мышкой смог добиться 60% на обоих ядрах кор2дуо. Но иксы являются дерьмом по иным причинам.

VNC не сильно проигрывает X11 форвардингу в плане скорости и потребления траффика. Внс сервера, которые берут картинку с уже запущенных иксов — довольно тормозная штука, но если vnc сервер совмещён с X11, то решение не проигрывает по скорости X11@tcp.

Учитывая синхронность Xlib, VNC зачастую быстрее работает, хотя и шлёт просто пиксели.

Ещё NX и RDP позволяют удалённо подключать принтеры и аудио. Не относится к теме разговора, но так же увеличивает их пригодность в качестве терминального решения относительно голого X11.

Повторюсь, недостатки протокола X11 видны уже на 20 мбит канале, а есть случаи, когда канал бывает ещё медленнее.

Только вы все забыли что на нормальных десктопных осях (Windows) графическая подсистема работает на повышенных привилегиях и ещё в ядре.

Если повысить процессу «Xorg» приоритет до "-15" до всё начинает летать.

Клоуны, ну попробуйте хоть разок. А то развели тут демогогию о тормознутости иксов.

Так же заметил что отрисовка интерфейса GTK тормозится в 2 раза при использовании темы QtCurve. И вообще любая не стандартная тема тормозит, они все не оптимизированы.

На даче был вендокомп с доступом по рдп, подключённый по CDMA к интернету. RDP работал не спеша (была видна прорисовка каждого нового окна по виджетам где-то около половины секунды), но терпимее ssh -X на ADSL.

для начала в самой статье

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

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

http://www.std.org/~msm/common/protocol.pdf

> Только вы все забыли что на нормальных десктопных осях (Windows) графическая подсистема работает на повышенных привилегиях и ещё в ядре.

Пруф про графику в ядре.

поди имелось ввиду ядро граф. карточки

Ну тогда это такая же графика в ядре, как и KMS с фреймбуфферами.

Чуть более половины графической подсистемы в винде выполняется в кёрнелспейсе.

>>и далее по тексту сабжевой статьи.

вопрос был про запрет на развитие и эволюцию.

Нет. Прочитай внимательно - там описываются, как увеличивается количество костылей: разрабы (КДЕ в данном случае) не понимают, как функционируют иксы, и добавляют левый костыль (D-Bus).

То есть если тормоза отрисовки - в тулкитном говнокоде - то новый протокол улучшит ситуацию, нет?

Если тулкиты перейдут на этот новый протокол - да, наверное. Но сейчас нет ни анализа тормозов, ни нового протокола, ни сервера с новым протоколом.

но иксы то хреново отрисовывают.

Критерии хреновости не очень понятны. Медленно?

есть версия, что тулкитчики.

Еще есть версия, что драйверы.

Как раз по дизайну протокол X довольно экономный по трафику

почему тогда на практике далеко не экономный?

Цифры, цифры где?

дизайн не соответствует действительности?

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

А в линуксе разве не так? В lsmod штук пять модулей, так или иначе связанных с выводом картинки на экран.

> Пруф про графику в ядре.

Бгг.

> Отчасти да - тулкитчики привыкли решать свои проблемы сами, а у них для этого один способ - послать по сети битмап.

И тут мы приходим к причине соплей в этом топике. Если бы Х11 не имел недостатков, то решать проблемы тулкитопостроителей таким образом не пришлось бы.

win32k.sys же. //Да, на винфак.

Ключегое слово модулей. Алсо, xorg таки к ядру отношения не имеет.

>Цифры, цифры где?

Выше приводили сравнения, я ими оперирую. Или есть повод им не доверять?

Критерии хреновости не очень понятны. Медленно?

Ну почему если сейчас открыть настройки какой нибудь проги - я некоторое время буду пялится на прямоугольник фонового цвета. Это так задумывается?

Еще есть версия, что драйверы.

Наблюдаю и под intel и под nvidia, и под nouveau. Все виноваты?)

Алсо засовывание иксов в ядро делу помочь не может. Ring 0 и <какой там ринг используется в костыльной x86 для юзерспейса> работают с одинаковой скоростью.

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

Это полный бред, что они бесполезны. Во-первых, их используют все программы, которые написаны на несколько иных тулкитах, чем Gtk и Qt. И у меня такие программы есть. А новые тулкиты вообще пользуются client-side fonts. То есть, убрав из реализации сервера server-side fonts, ты надеешься повысить производительность Gtk и Qt, которые этим просто не пользуются? Не аргумент. Зато другие пользутся. У меня Emacs на lesstif, и я server-side fonts задействованы.

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

Опять же, какие серьезные проблемы вообще могут быть решены выкидыванием редкоиспользуемого функционала, кроме того, что реализация X-server станет тоньше?

>У меня Emacs на lesstif, и я server-side fonts задействованы.

То есть на Xaw3d, а не на lesstif. Думал про одно, написал другое.

главная проблема гуя в линаксе - это отсутствие ЕДИНОГО тулкита. это значит, что ПО на других тулкиитах не будет поддерживать глобальное меню. а в макоси такой проблемы нет. лучше сделать ОДИН хороший тулкит вместо сотни лисапедов.

жаль, но верно.

Там пдфка была, от умных дядечек, которые интересные вещи написали. Уже претензии не к старости, а race condition и тормозам. Вот она поинтереснее.

реализация X-server станет тоньше?

это очень даже неплохо. а вот наличие

XFixes

какбы намекает, что если выходит расширение, которое не расширяет а исправляет - то наверное чтото не так.

> Выше приводили сравнения, я ими оперирую. Или есть повод им не доверять?

Органолептика от PolarFox? У меня нет никаких причин доверять ей.

если сейчас открыть настройки какой нибудь проги - я некоторое время буду пялится на прямоугольник фонового цвета. Это так задумывается?

Не думаю. Но кто сказал, что это вина X, а не тулкита?

Еще есть версия, что драйверы.

Наблюдаю и под intel и под nvidia, и под nouveau. Все виноваты?)

Вполне возможно (IIRC, внутренности X до сих пор колбасит от переходов XAA, EXA и прочего).

Таки вы не знаете, чем отличается userspace от kernelspace?

Приставкой к слову space? Или к тому что userspace виснет по одному процессу, а kernelspace весь и намертво?

> Органолептика от PolarFox? У меня нет никаких причин доверять ей.

Давайте напишем письмо в фороникс, они проведут тесты. Я тоже могу провести их, например искусственно ограничив пропускную способность доступных мне в данный момент каналов, но опять же ни у кого не будет причин доверять моим результатам.

И еще по теме server-side vs client-side. Неиспользование server-side идет только от того, что одна из реализаций не особо развивает эту возможность. Но это совсем не значит, что другая реализация сервера не может этот момент развить. В своей время Sun такое начала делать: http://stsf.sourceforge.net/about.html

P.S. Я не против client-side.