В Fedora 15 может появиться поддержка Wayland

ой кошмар. каждое приложение (_каждое_) будет таскать код для отрисовки. для декорирования... брр. И шрифты тоже .... тоесть автор вейленда не освоил не только X но и векторные шрифты?

> а как же kms, dri/drm, xrandr, gallium3d?

нагромождение костылей. Эта история с разными DRI чего только стоит. Зато kms и gallium — разумное примение IoC, только половинчатое какое-то.

man динамическая линковка.

> да и тут толпы орут, мол, X устарели с 87 года и всё такое — получается, они и в 87 году не тормозили.

тормозили. В то время, когда другие системы спокойно работали с менее 8 Мб, иксы были Eight Megabytes And Constantly Swapping..

В то время были и более годные, и менее ресурсоёмкие оконные системы. NeWS http://en.wikipedia.org/wiki/NeWS (ничего так идея, только Display Postscript там не к месту), MGR (Manager) http://en.wikipedia.org/wiki/ManaGeR http://www.hack.org/mc/mgr/ , тот же QNX Photon MicroGui: http://www.eu.edu.ua/e_lib/os/qnx/photon.html http://www.swd.de/documents/manuals/neutrino/photon_en.html http://www.qnx.org/developers/docs/6.3.2/neutrino/sys_arch/photon.html

X никогда собсно не был быстрой оконной системой, и вся эта суета вокруг ой-вейланда — лишнее тому подтверждение.

а вообще этот вейландовский композитор напоминает картинку с «The Photon event space», только недоделанную.
Картинку слямзили, а суть упустили.
Хотя там вроде патенты какие-то были в фотоне.

> XXKB сломают

неет. только не её

> В то время, когда другие системы спокойно работали с менее 8 Мб, иксы были Eight Megabytes And Constantly Swapping..

Ты перепутал иксы с EMACS.

>NeWS included several libraries of user interface elements (widgets), themselves written in NeWS. These widgets ran all of their behaviour in the NeWS interpreter, and only required communications to an outside program (or more NeWS code) when the widget demanded it. For example, a toggle button's display routine can query the button's state (pressed or not) and change its display accordingly. The button's PostScript code can also react to mouse clicks by changing its state from «pressed» to «not pressed» and vice versa. All this can happen in the windowing server without interaction with the client program, and only when the mouse is released on the button will an event be sent off for handling.

аааа... через пару лет кто-нибудь додумается скрестить QML из Qt, gallium3d и встроит это в Wayland, и это выдадут как модную супер-пупер технологию, а не изобретение велосипедов.

ЗЫ. PostScript убил NeWS, да. Надо было сразу на JavaScript писать, глядишь QML и не понадобился бы.

This was more sophisticated than the X Window System server model, which can only report «mouse was pushed down here», «mouse is now here», «mouse was released here» events to a client, which then has to figure out if the event is in the button, switch the state, and finally instruct the server to display the new state. If client and server are not on the same machine, these interactions must travel over the network, which results in a delay in responding.

не надо, я его юзал на 486dx2/66 с 8мб по модему, конпеляя в фоне MPI программу на фортране с tcl/tk гуём.. это именно оно самое и было.

> не надо, я его юзал на 486dx2/66 с 8мб по модему, конпеляя в фоне MPI программу на фортране с tcl/tk гуём..

Что «его»?

это именно оно самое и было.

Посмотри на аббревиатуру этой фразы.

>Я сталкивался ровно с одним случаем 24bpp: драйвер vga-cirrus в QEMU-KVM, и тогда на 24bpp падает OpenBox. :)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545031 http://bugzilla.icculus.org/show_bug.cgi?id=4363

Нет, в этих багах речь идет о проблемах работы с глубиной цвета 24bpp, а не глубиной *фреймбуфера*. Это разные вещи! При 24-битной глубине цвета, фреймбуфер может быть как 24bpp, так и 32bpp. Режим фреймбуфера 24bpp выбирается специальной опцией DefaultFbBpp 24, а по умолчанию он 32bpp. А у openbox проблема именно в color depth, которая может быть выбрана опцией DefaultDepth.

Позаимствует ли он такие полезные возможности, как сетевая прозрачность, вот в чём вопрос.

>Хотя там вроде патенты какие-то были в фотоне.

патентов штук 10, и один из них ссылался на

http://www.google.com/patents?id=4T0oAAAAEBAJ&printsec=abstract&zoom=4&source...

давайте вейланд затроллим.

да знаю я.. как раз емакс поначалу и запускал, ужаснулся, и писал далее по старинке, в ed...

Лично меня новость радует, хотя бы в плане того что в связи с событиями вокруг Wayland появляеться реальная возможность что кроме иксов будет кое-что ещё. Безотносительно вопроса «что лучше?» (ибо сам вопрос от лукавого). Альтернатива это _всегда_ плюс, а заинтерисованность Каноникал и проекта Федора вдыхает надежду на то что результат всётаки будет! И чудненько ;)

>>Хотя там вроде патенты какие-то были в фотоне.

http://www.google.com/patents/about?id=bN0LAAAAEBAJ&dq=QNX+events+region — интересное чтиво, но ставит крест на идее полного открытия исходников фотона

Ну так я писал про QEMU'вский vga-cirrus, у которого нет 32bpp-фреймбуффера. Соответственно, глубина цвета не может быть 32-битовая (которую OpenBox, естественно, поддерживает), а только 24-бит и ниже. Но на 24-битовой глубине цвета OpenBox падает, соответственно для него приходится выставлять DefaultDepth 16.

>> Сначала всё тоже самое говорилось про фреймбуфер, теперь он уже не кошерный

Ну, справдливости ради, в вяленд приложения сами рендерят свои картинки, т.е. они могут пользоваться для этого железом напрямую.

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

> X-протокол — это то, что вайленд хочет уничтожить.

а что взамен?

> Альтернатива это _всегда_ плюс

правда? по-моему, это разбазаривание людских ресурсов. у линукса есть проблемы и посерьёзнее...

> правда? по-моему, это разбазаривание людских ресурсов. у линукса есть проблемы и посерьёзнее...

Большинство опенсорса не знает такого понятия как «людской ресурс». Если хакер (в правильном значении этого слова) пилит вейленд, то это отнюдь не значит, что он мог пилить бы те же Х11, просто потому что ему не интересно.

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

> telnet, батенька, telnet рулит.

вои стену: telnet towel.blinkenlights.nl

новый 3d эпизод через IPv6!!!!11111

> Разработчики D-Bus создали нечто, чем нельзя воспользоваться без их же инструментов, стандартными средствами операционной системы. Чтобы воспользоваться D-Bus, нужен D-Bus-клиент и библиотека D-Bus.

что, нельзя было сделать сервером, как в Plan 9 сделали /dev/window, /dev/console, /dev/mouse? Или VFS настолько кривой, что через FUSE только костыли получаются?

>тогда о чем думали разрабы?

О рисовании прямоугольников, о палитрах, о кривых буферах обмена и переключалках… :)

> это наслоение костылей и подпорок

По-твоему НЕ костыль — это только то, что написано один раз в момент создания программы? И программы естественным образов развиваться не могут?

> а чего ему не хватает? на мой взгляд все, что нужно - есть.

компактности и эффективности. Ну чего он одно и тоже событие гоняет по нескольку раз, между своими потрохами, гуи тулкитом и так далее?

> Но... насколько я понимаю, запущенное на сервере приложение в принципе не может использовать GPU на клиенте.

в vmWare есть vGPU, виртуальный GPU, вызовы которого транслируют в родные OpenGL. Если как-то вот так извратиться...

> Итак, сценарий: я запускаю нечто графически интенсивное на удаленной машине и направляю вывод на свою машину; в моей машине - навороченный GPU; программа, работающая на сервере может его использовать. С вялендом это не прокатывает.

должно прокатывать в VmWare с его vGPU. В OS внутри VM используется через драйвер vGPU виртуальная затычка, переводящая вызовы виртуального GPU в родные вызовы OpenGL и реального локального GPU.
зы. при чём тут вяленд?

> Ну почитайте как происходит резайз окон.

О да, такая важная операция, просто критическая по производительности!

>что, нельзя было сделать сервером, как в Plan 9 сделали /dev/window, /dev/console, /dev/mouse?
Смысл не в этом. 9P в X-клиентах нужен не больше, чем dbus. Что бы ни говорили фанаты wmii.

если б он пилит, то было бы хорошо. но сейчас убунта и федора этот ещё недопиленный вайланд начинают проталкивать.

получается что самые юзабельные у меня дрова (нвидиа/интел) и гном/кеды кривые :)

Эх, на сей раз и 500 каментов не наберётся.:(

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

Прямо какое то стадо антилоп ГНУ в период миграции. Бубунта, ФЕдора, Помпиз. Посмотрим что из этого выйдет

Одно другого не отменяет. HTTP - это текстовый протокол TCP, для него не требуется специальный клиент, можно хоть telnet'ом подключиться и вводить команды и получать результат.

Ну хорошо, а к протоколу X ты можешь получить доступ «стандартными средствами»? При чём тут вообще стандартные средства? Есть задача - есть протокол, есть приложения, его реализующие. X - своя задача, HTTP - своя задача, DBus - своя. Вносить функциональность DBus в X - грубая ошибка, нарушение основных принципов Unix, о чём я тебе уже сказал.

Моя фраза:

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

это прямая аналогия:

Хотя опять же: там, где нет иксов, обычно нет необходимости изобретать один глобальный и надёжный протокол обмена информацией между всеми программами

Где здесь нелогично? Не унифицировать - так не унифицировать.

В реальном мире господства ipv4 «сетевая прозрачность» X11 работает только в локальных сетях или через костыли типа ssh -X. X-сервер может находится за десятком nat'ов и, естественно, X-клиенты к нему подсоединиться не смогут. Кстати оно еще и тормозит страшно по сравнению с тем же RDP.

Если подумать над событиями последнего времени именно с точки зрения оправдания перед спонсорами криворуких разработчиков ДЕ, то всё садиться на своё место.

Разработчики КДЕ недавно продемонстрировали невероятную вещь - решили для подчищения кода КДЕ и выпиливания дублирующих участков кода всё КДЕ запихнуть в Qt. Но ведь очевидно же, что подчищение кода есть задача только разработчиков проекта, которую они обязанны выполнять. Работа хоть скучная, но необходимая. И нежелание заниматься необходимой работой и спихнуть её на своих спонсоров очень показательно с точки зрения зрелости и ответственности разрабов КДЕ.

Но гномеры в чём то даже хуже разрабов КДЕ, хотя они такой работой и занимаются регулярно, используя процесс для общего упрощения. Но разрабы гнома были первыми, открыто наплевавшими на традиции юних - создавать среду, удобную для работы творческих людей. Они открыто послали их далеко, и сказали, что будут создавать дистрибутив для людей, которые имеют средние запросы. С грехом пополам они решили эту часть задачи, но цену которую они заплатили за это нельзя назвать приемлемой - они порвали с традициями создавать окружение удобное для работы творческих людей, т.е порвали с традициями среды. В результате в архитектуре гнома и в его инструментах нет ни чего, что можно было бы приспособить для нестандартных ситуаций, и из самого гнома повыпиливалось всё, что можно предельно его упростив, и в конце выпилив из гнома все сетевые возможности, лежащие в его архитектуре, под предлогом стандартизации dbus-м и сложности использования

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

> В Wayland я наслышан будет совместимость с X11 (видимо типа как в макоси).

В целом, да. Wayland - это вторая макось. Забудьте про свои компизы и kwin-ы, забудьте про тайлинг, вейланд - X-сервер и оконный менеджер в одном флаконе. И все.

Совместимость там будет - если запустить под ним Х-сервер. Но выглядеть это будет убожески. Wayland-программы не будут управляться оконным менеджером, работающим в этих Х-ах. В самом лучшем случае это будет выглядеть как интеграция рабочего стола в VirtualBox - половина окон одни, половина другие.

А реально все будет еще хуже. Потому что декоратор тоже перекладывается на тулкит. Поэтому у Qt-программ будет одно оформление окон, у GTK - другое. TCL/Tk либо останутся без декорации, либо вообще не будут запускаться в Wayland.

Да, в wayland не будут работать xterm ни rxvt, но они нам не нужны! Нам не нужны оконные менеджеры! Фтопку стандарты XDG! Выкинуть устаревшие xine, xsane, wine и tvtime! Пусть умрет gitk! Нам не нужны mesa и SDL! Нам не нужны альтернативы. Мы - за будущее! За один оконный менеджер! За один «современный» протокол! Мы - за один дистрибутив! Мы - за win...ой...

Подумываю о возврате к FreeBSD. Если достанут и там, переквалифицируюсь в слакварщики.

Юникс умер, переходи на Plan 9.

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

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

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

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

С этого места, пожалуйста, поподробнее.

> локально сетевая прозрачность не используется

Да что вы заладили про эту сетевую прозрачность? В X-ах для обмена между клиентом и сервером используются unix-сокеты. В wayland для обмена между клиентом и сервером используются ... unix-сокеты. Найдите 10 отличий?

«Сетевая прозрачность» в Х-ах - это просто специальная оптимизация протокола, которая позволяет для отрисовки окон передавать минимум данных. А wayland всегда гоняет текстуры целиком. Вот и вся прозрачность.

X12 мне больше нравится, чем это, будем надеяться, что без поддержки нвидии оно загнется

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

С этого места, пожалуйста, поподробнее.

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

В wayland нет примитивов. Единственный вариант - нарисовать все окно. Там, похоже, нет даже возможности перерисовать часть окна из-за двойной буферизации. Для того, чтобы нарисовать даже простой прямоугольник, надо сгенерить текстуру размером с этот прямоугольник и всю ее залить серверу.

Судя по коду, кажется, там даже тройная буферизация используется. Один буфер, в который сейчас рисует клиент, еще один, из которого сервер сейчас рисует на экран, и еще один, который передается от клиента серверу в очередном сообщении.

>В X11 можно рисовать окно не только из готовой текстуры размером на все окно, но и из примитивов, передав несколько маленьких сообщений нарисовать и закрасить цветом окно любого размера. Всего-то надо отрисовать несколько линий и прямоугольников.

Можно. Но пользуется ли кто-то этим?

>> Аргумент «я не смогу использовать GPU на клиенте» ты просто проигнорирвал.

Я же согласился, что да, не могу. ... Но зато можно использовать локальный, и этот GPU - ближе (а отнедавна вообще на кристалле). А вот в иксах можно использовать локальный?

В Х-ах программа-клиент может использовать и собственный GPU, если будет использовать вызовы локальной библиотеки, и серверный GPU, если будет отдавать команды на рисование через X11. А Wayland-клиент может использовать ТОЛЬКО клиентский GPU, а потом заливать готовую картинку на сервер. Вы же хотели простого протокола? Получите.

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

>> В X11 можно рисовать окно и из примитивов

Можно. Но пользуется ли кто-то этим?

Да, практически, все.

Если быть более точным - этим пользуются все любители icewm/*box и других небольших оконных менеджеров. GNOME и KDE использует этот механизм для легковесных тем.

Именно поэтому простая смена темы в KDE4 снижает потребление памяти. Тяжелые темы с тенями и градиентами, рисуются через pixmap-текстуры, так получается быстрее, но pixmap-ы занимают кучу памяти. А легкие однотонные темы быстрее рисовать через примитивы, и памяти они не занимают.

>иксы слишком тяжёлые для нетбуков

неужели??

вот зачем на нетбуке сетевой протокол?

вот зачем в слове «нетбук» слог «нет»?

>Эй, ну и где ругань и срач?

пару дней назад все желающие просрались уже.

Вот так всегда, как убунту - так бездари, а как редхет - так молодцы.

лень же. в прошлом тред корм был обилен.