Comments 49
Возможно для обратной совместимости.
А статья очень понравилась, побольше бы таких.
А статья очень понравилась, побольше бы таких.
Статья супер!
«Чёрт возьми, поддерживать протокол тридцатилетней давности без поломок и перестраивать его архитектуру, — это отличная работа с их стороны.» — вот только зачем его поддерживать?
«Чёрт возьми, поддерживать протокол тридцатилетней давности без поломок и перестраивать его архитектуру, — это отличная работа с их стороны.» — вот только зачем его поддерживать?
Задам встречный вопрос по аналогии с вашим: «Зачем поддерживать софт для win95 в win7?».
Причина в экосистеме вокруг протокола. Чем больше объём экосистемы — тем сложнее менять протокол и тем больше сил приходится бросать на тестирование его совместимости. Теория надёжности информационных систем :)
Причина в экосистеме вокруг протокола. Чем больше объём экосистемы — тем сложнее менять протокол и тем больше сил приходится бросать на тестирование его совместимости. Теория надёжности информационных систем :)
Между win95 и win7 не 30 лет, и не все там поддерживается. Танцы же вокруг X11 смахивают на полноценную поддержку DOS 1.0 в Win8. Unix community банально не хватает яиц в органиме, чтобы произнести obsolete/deprecated, при чем не только в графической подсистеме.
Не совсем так.
Windows-коммьюнити исторически строилось вокруг Microsoft и подчинялось законам игры этой фирмы. Все внутренние решения принимались Microsoft единолично, но даже в таком случае реально революционные решения принимались считанные разы — даже в условиях корпорации координация огромных массивов разработчиков давалась нелегко.
Unix/Linux-коммьюнити исторически строились вокруг кучи вендоров и управлялись полуотраслевыми стандартами типа Posix, ISO или вот этого протокола, X11.
В мире до сих пор существуют системы, которые работают с тех самых восьмидесятых годов. И к ним был написан софт, который гоняется на современных системах и не требует переписывания только из-за незыблемости «клея из стандартов».
У linux-комьюнити яиц хватает (чего стоят истории с udev-evdev, kms и прочими pulseaudio). Просто всё компьютерном мире смена стандартов и поколений должна проходить эволюционно. Скажем так — параллельно со сменой поколений разработчиков.
Windows-коммьюнити исторически строилось вокруг Microsoft и подчинялось законам игры этой фирмы. Все внутренние решения принимались Microsoft единолично, но даже в таком случае реально революционные решения принимались считанные разы — даже в условиях корпорации координация огромных массивов разработчиков давалась нелегко.
Unix/Linux-коммьюнити исторически строились вокруг кучи вендоров и управлялись полуотраслевыми стандартами типа Posix, ISO или вот этого протокола, X11.
В мире до сих пор существуют системы, которые работают с тех самых восьмидесятых годов. И к ним был написан софт, который гоняется на современных системах и не требует переписывания только из-за незыблемости «клея из стандартов».
У linux-комьюнити яиц хватает (чего стоят истории с udev-evdev, kms и прочими pulseaudio). Просто всё компьютерном мире смена стандартов и поколений должна проходить эволюционно. Скажем так — параллельно со сменой поколений разработчиков.
Возможно, но IMHO как-то слишком затянуто все это происходит.
Windows-коммьюнити исторически строилось вокруг Microsoft и подчинялось законам игры этой фирмы
Потому что есть старая военная мудрость — одна голова хорошо, а две еще хуже.
В мире до сих пор существуют системы, которые работают с тех самых восьмидесятых годов. И к ним был написан софт, который гоняется на современных системах
Мне не очень понятно, зачем запускать этот софт на современных системах. Старой рыбе старый аквариум.
Unix/Linux-коммьюнити исторически строились вокруг кучи вендоров и управлялись полуотраслевыми стандартами типа Posix, ISO или вот этого протокола, X11.
Послать бы часть этих затхлых вендоров куда подальше — в этом и есть суть obsolete/deprecated. Вместо этого неотрубленные гниющие конечности продолжают пускать метастазы.
Windows-коммьюнити исторически строилось вокруг Microsoft и подчинялось законам игры этой фирмы
Потому что есть старая военная мудрость — одна голова хорошо, а две еще хуже.
В мире до сих пор существуют системы, которые работают с тех самых восьмидесятых годов. И к ним был написан софт, который гоняется на современных системах
Мне не очень понятно, зачем запускать этот софт на современных системах. Старой рыбе старый аквариум.
Unix/Linux-коммьюнити исторически строились вокруг кучи вендоров и управлялись полуотраслевыми стандартами типа Posix, ISO или вот этого протокола, X11.
Послать бы часть этих затхлых вендоров куда подальше — в этом и есть суть obsolete/deprecated. Вместо этого неотрубленные гниющие конечности продолжают пускать метастазы.
Мне не очень понятно, зачем запускать этот софт на современных системах. Старой рыбе старый аквариум.
Представьте себе конверсию мейнфрейма с процессингом большой фирмы на западе. Софт был написан в восьмидесятые, с тех пор допиливался и обрастал функциональностью. Стоимость его — эквивалент десятков тысяч человекочасов. А железо мейнфреймов не выпускают и этот софт мигрирует на современные *nix-платформы вместе со всей инфраструктурой.
И такого софта много.
Естественно затянуто. На реально больших и живых системах, которые, на самом-то деле, питают индустрию (надеюсь, вы понимаете, что серьёзную индустрию двигают не домашние персональные компьютеры) — там революционная миграция между разными технологическими системами невозможна.
Представьте себе конверсию мейнфрейма с процессингом большой фирмы на западе. Софт был написан в восьмидесятые, с тех пор допиливался и обрастал функциональностью. Стоимость его — эквивалент десятков тысяч человекочасов. А железо мейнфреймов не выпускают и этот софт мигрирует на современные *nix-платформы вместе со всей инфраструктурой.
И такого софта много.
Естественно затянуто. На реально больших и живых системах, которые, на самом-то деле, питают индустрию (надеюсь, вы понимаете, что серьёзную индустрию двигают не домашние персональные компьютеры) — там революционная миграция между разными технологическими системами невозможна.
А он его и не тянет. Это сопутствующие расходы для mesa. Тут всё расписано с шикарнейшей диаграммкой:
Спасибо. Очень интересная статья. Сам бы никогда не осмелился все это копать.
За статью спасибо! Побольше бы таких!
Однако когда я слышу утверждения вида «С другой стороны, в наше время колоссальная гибкость сетевого протокола становится ненужной, ведь львиная доля функциональность иксов уже раскидана по другим службам — например, DBus.», у лично меня почему-то возникает непреодолимое желание взять и у****ь разработчиков Wayland бейсбольной битой! А потом эту бейсбольную биту вставить им в анус, да еще и пожелать чтобы их черти драли в аду! Гибкость и возможность работы по сети это и есть реально сильные стороны X-протокола! А то, что они предлагают — это отказаться от реально сильных сторон зато навешать на юзера килотонну свистоперделок!
P.S.: Предвижу вопросы, и сразу на них отвечаю. Да, я действительно использую сильную сторону как возможность работы X-протокола по сети (в виде ssh X11 forwarding). И да, всякие «свистоперделки» вроде 3d desktopов вызывают у меня рвотный рефлекс.
Однако когда я слышу утверждения вида «С другой стороны, в наше время колоссальная гибкость сетевого протокола становится ненужной, ведь львиная доля функциональность иксов уже раскидана по другим службам — например, DBus.», у лично меня почему-то возникает непреодолимое желание взять и у****ь разработчиков Wayland бейсбольной битой! А потом эту бейсбольную биту вставить им в анус, да еще и пожелать чтобы их черти драли в аду! Гибкость и возможность работы по сети это и есть реально сильные стороны X-протокола! А то, что они предлагают — это отказаться от реально сильных сторон зато навешать на юзера килотонну свистоперделок!
P.S.: Предвижу вопросы, и сразу на них отвечаю. Да, я действительно использую сильную сторону как возможность работы X-протокола по сети (в виде ssh X11 forwarding). И да, всякие «свистоперделки» вроде 3d desktopов вызывают у меня рвотный рефлекс.
Я тоже использую проброс X11 :)
Вэйлэнд — это решение оконных проблем для десктопов — онли.
Иксы — это решение оконных проблем для сетевых инфраструктур.
Думаю, что они это понимают и будут развивать концепцию оконных окружений соответствующим образом.
Терминалу терминалово, игрушкам — игрушково.
Вэйлэнд — это решение оконных проблем для десктопов — онли.
Иксы — это решение оконных проблем для сетевых инфраструктур.
Думаю, что они это понимают и будут развивать концепцию оконных окружений соответствующим образом.
Терминалу терминалово, игрушкам — игрушково.
Я думаю что со времен изобретения X-Window ситуация поменялось, и вместо X-Window все таки будут быстрые локальные графические подсистемы, основанные на OpenGL и без всякой сетевой штуки, и web приложения для сетевого взаимодействия.
Когда-нибудь, лет через пятнадцать, — обязательно. И WebGL, и Javascript во все поля, и кризис HTTP и REST-моделей. Когда-нибудь — обязательно.
«Сеть» это не только реальный ethernet или модемный шнурок, но также сокетовая абстракция для IPC между двумя адресными пространствами. К примеру, у меня линукс, на котором я запускаю мои x-клиенты, находится в виртуалке, тогда как x-сервер — на хосте под виндой.
Поэтому, думаю, что X11 ещё лет 50 не умрёт, т.к., в отличие от веб, у него есть бинарная упаковка данных, т.е. ориентированные в конечном результате на десктоп приложения будут работать через X11-сокеты (а потом, скорее всего, разработают специальный протокол и инфраструктуру для работы индивидуальных клиентов).
Поэтому, думаю, что X11 ещё лет 50 не умрёт, т.к., в отличие от веб, у него есть бинарная упаковка данных, т.е. ориентированные в конечном результате на десктоп приложения будут работать через X11-сокеты (а потом, скорее всего, разработают специальный протокол и инфраструктуру для работы индивидуальных клиентов).
Сетевая прозрачность реализуется при помощи VNC и аналогов, причём успешно (для Wayland вроде уже даже есть).
А X11 сам по себе и впрямь не скоро умрёт так как приложения будет работать внутри Wayland да и уже работают причём быстрее чем напрямую. :) Но ИМХО после начала массовой миграции за год 80% мейнстрима будет уже нативно работать на wayland.
А X11 сам по себе и впрямь не скоро умрёт так как приложения будет работать внутри Wayland да и уже работают причём быстрее чем напрямую. :) Но ИМХО после начала массовой миграции за год 80% мейнстрима будет уже нативно работать на wayland.
Пфффф. Сетевая прозрачность, говорите? Запустите на удалённом сервере браузер поверх X11 поверх SSH. И его же в VNC, к которому подключитесь поверх того же же SSH. А теперь попробуйте посерфить. Возможно, вы сильно удивитесь, но второй вариант работает на порядки быстрее.
Трудно не согласиться.
Тоже любил форвардить иксы, пока у нас не образовалась удаленная площадка с серверами,
до которой канал не шибко быстрый.
VNC в этом случае единственное спасение, ибо приложение которое приехало к тебе
через проброс, отвечает по несколько секунд на нажатия например.
И очень бесят двойные нажатия и прочие неприятности фризов.
Тоже любил форвардить иксы, пока у нас не образовалась удаленная площадка с серверами,
до которой канал не шибко быстрый.
VNC в этом случае единственное спасение, ибо приложение которое приехало к тебе
через проброс, отвечает по несколько секунд на нажатия например.
И очень бесят двойные нажатия и прочие неприятности фризов.
Насколько я успел заметить по своему опыту — скорость канала не так важна. Для X11 важен быстрый пинг. Заторможенность при пробросе X11 у меня была прямо пропорциональна моей удаленности от сервера, скорость же канала практически не имела никакого значения.
Такое возможно в случае, если протокол сделан очень прямолинейно, по принципу: посылаем одну команду — ожидаем ответ.
Такое возможно в случае, если протокол сделан очень прямолинейно, по принципу: посылаем одну команду — ожидаем ответ.
Большое спасибо. Было интересно читать, узнал много нового.
Спасибо. Таких обзорных статей по компонентам сильно не хватает.
Присоединюсь к благодарящим. Ради таких статей(информативных и с не попсовым содержимым) и захожу на хабр. Жаль они не так часто встречаются.
Получил удовольствие от прочтения. Хочу ещё.
Это героический поступок перевести это! Я сам начинал, но так и не осилил объем, спасибо вам
Мне вот пока пару моментов интересны: можно ли сделать рисование декораций окон сторонней программой(ну блин, это ерудна какая-то, разные декорации, в разных тулкитах) и где брать информацию об активных окнах(я хочу написать панель, мне в ней рассматривать все существующие «композиторы» которые могут предоставить такую возможность)?
Вы про Wayland?
Да, как я понял в протоколе этот механизм не оговорен. В рассылке у них было написано, что получение списка окон и их декораций, все на совести композитора. И в таком случае получается может и не оказаться унификации интерфейса. Ровно как и возможности принудительного отключения декораций у окон. Возможно каждый тулкит реализует это по-своему. Хотя я может(наверняка) еще плохо разобрался в протоколе Wayland
Примерно так и будет. В идеологию Wayland вообще не закладывались декорации, как таковые. Впрочем, как и окна. Там, скорее, идёт разговор о неких “areas” — этот термин, думаю, лучше отражает сущность «окон» из протокола Wayland. В отличие от X11, в котором идеология, как и в майкрософтовском оконном подходе, обязывает синхронизировать все оконные примитивы с сервером. В Wayland серверу наплевать на богатый внутренний мир того, что крутится за area приложения.
Соответственно, если я правильно понял, то на каждый сеанс будет по композитору, и, желательно, чтобы этот композитор использовал libwayland — там реализован стандартный механизм перечисления окон.
Рисование всего, что на окнах, отходит на второй план — либо к клиенту Wayland, либо к нативному тулкиту, либо к самому приложению-owner'у этой area.
В этом плане Wayland очень по подходу к связке mutter/clutter, что, в общем-то, и не удивительно.
Соответственно, если я правильно понял, то на каждый сеанс будет по композитору, и, желательно, чтобы этот композитор использовал libwayland — там реализован стандартный механизм перечисления окон.
Рисование всего, что на окнах, отходит на второй план — либо к клиенту Wayland, либо к нативному тулкиту, либо к самому приложению-owner'у этой area.
В этом плане Wayland очень по подходу к связке mutter/clutter, что, в общем-то, и не удивительно.
Спасибо, статья великолепна и содержит хорошую попытку систематизации этого бардака с графикой. Однозначно в закладки!
Вы супер!
Спасибо! Выражаю надежду, что автор продолжит писать статьи по этой тематике, а автор перевода будет их публиковать на Хабре! Спасибо еще раз.
Жаль только, что автор немного направление на GTK держит. О Qt упомянуто вскольз… аж 2 раза. Но что поделать, работя обязывает.
Да тут и GTK упомянуто очень вскользь.
Если говорить про KDE/Qt, то у этой связки «свяо атмосфреа». Рисует она с помощью своей собственной, архитектурно закрытой композиции (в силу особенностей тулкита) и не лезет на те уровни, на которых работает связка mutter/clutter. Поэтому, по большому счёту, ему пофиг на низкоуровневые нюансы. А всё остальное у них точно такое же, как и в GNOME/GTK.
С иксами сложно работать как-то иначе :)
Если говорить про KDE/Qt, то у этой связки «свяо атмосфреа». Рисует она с помощью своей собственной, архитектурно закрытой композиции (в силу особенностей тулкита) и не лезет на те уровни, на которых работает связка mutter/clutter. Поэтому, по большому счёту, ему пофиг на низкоуровневые нюансы. А всё остальное у них точно такое же, как и в GNOME/GTK.
С иксами сложно работать как-то иначе :)
Прошло 9 лет. Что нить изменилось?
Sign up to leave a comment.
Графический стек Linux