Маттиас Класен (Matthias Clasen), разработчик GNOME из компании Red Hat, представил (https://mail.gnome.org/archives/release-team/2013-March/msg0...) план реализации поддержки Wayland в GNOME. В соответствии с планом (https://live.gnome.org/Wayland), начальная поддержка Wayland появился уже в GNOME 3.10, выход которого намечен на осень этого года, а полнофункциональная работа GNOME поверх Wayland ожидается в релизе 3.12, который выйдет весной 2014 года.
В GNOME 3.10 по умолчанию по прежнему будет использоваться X-сервер, но будет добавлена опциональная возможность (https://live.gnome.org/Wayland/GnomeShell) запуска оболочки GNOME Shell в качестве композитного сервера Wayland, для чего будет обеспечена поддержка базовых интерфейсов, идентичных с эталонным композитным сервером Weston. Одновременно будет доведён (https://live.gnome.org/Wayland/GTK%2B) до готовности к ежедневному использованию бэкенд Wayland в GTK+. Поддержка Wayland в GNOME 3.10 будет позиционироваться как экспериментальная возможность, готовая для начального ознакомления, но не охватывающая все компоненты GNOME (например, ещё не будут доступны средства конфигурации дисплея, стек для обеспечения работы людей с ограниченными возможностями и поддержка планшетов Wacom).
Из механизмов GNOME и GTK+, требующих отдельной доработки для функционирования в Wayland, отмечаются (https://live.gnome.org/Wayland/Gaps): работа с буфером обмена, настройка параметров экрана, Drag-and-Drop, методы ввода и управление раскладками клавиатуры, всплывающие окна, расширенные средства декорирования окон. Что касается приложений, то в настоящее время из 68 базовых программ (https://live.gnome.org/Wayland/Applications) поддержка Wayland присутствует в 35 приложениях, 26 программ требуют дополнительного портирования, 7 программ ещё не проверены. Для запуска обычных приложений, не поддерживающих работу поверх Wayland, будет задействован компонент XWayland (http://www.opennet.me/opennews/art.shtml?num=34118), позволяющий обеспечить запуск обычных X11-приложений поверх Wayland.Версия GNOME 3.12 ознаменует собой создание полноценного порта GNOME на базе Wayland. Все базовые приложения (https://live.gnome.org/Wayland/Applications) будут поддерживать прямую работу с Wayland. Поддержка работы поверх X11 для большинства компонентов GNOME будет сохранена, но некоторые смогут работать только с Wayland, так как в них достаточно трудно одновременно сохранить поддержку работы поверх X и Wayland.
В анонсе отмечается, что намерение компании Canonical развивать собственный дисплейный сервер Mir (http://www.opennet.me/opennews/art.shtml?num=36293) поставил разработчиков перед выбором, на стороне какой технологии будет выступать проект GNOME. В итоге, разработчики решили сосредоточить свои усилия на помощи в реализации всего потенциала Wayland, сохранив своё мнение, что данный проект подходит на роль будущей дисплейной системы в Linux.
Примечательно, что анонс проекта Mir и вспыхнувшие вокруг него обсуждения (http://www.opennet.me/opennews/art.shtml?num=36347) заметно форсировали (http://lists.freedesktop.org/archives/wayland-devel/2013-March/) развитие Waayland и подтолкнули разработчиков различных открытых проектов к его поддержке. Например, на днях обеспечена (http://smspillaz.wordpress.com/2013/02/27/hello-from-xbmc-on.../) экспериментальная возможность работы медиацентра XBMC поверх Wayland, для работы с Wayland портирован (http://lists.freedesktop.org/archives/wayland-devel/2013-Mar...) видеопроигрыватель Totem. Разработчики KDE укрепились в своём решении обеспечить поддержку Wayland. За последние несколько ненель для Wayland/Weston разработан (http://lists.freedesktop.org/archives/wayland-devel/2013-Mar...) аналог XRandR для управления видеорежиамми, создан (http://lists.freedesktop.org/archives/wayland-devel/2013-Mar...) протокол для минимизации и раскрытия окон, подготовлен (http://lists.freedesktop.org/archives/wayland-devel/2013-Mar...) композитный бэкенд на базе FreeRDP для работы удалённых клиентов, добавлена (http://lists.freedesktop.org/archives/wayland-devel/2013-Feb...) поддержка технологий PRIME/DMA_BUF для горячего переключения вывода с одного драйвера на другой и использования средств выноса операций DRI-рендеринга на другие GPU.
В настоящее время Wayland достаточно хорошо работает с открытыми драйверами Intel, Radeon и Nouveau, в том числе с Gallium-драйверами из состава Mesa. Через использование прослойки libhybris могут быть задействованы драйверы для платформы Android. Проблему составляют проприетартные драйверы AMD и NVIDIA, с которыми не может работать Wayland, но и в этой области наблюдается прогресс - компания Canonical договорилась с AMD и NVIDIA о реализации нового интерфейса на базе EGL для проекта Mir, который может (https://plus.google.com/113883146362955330174/posts/QwMqCgC7c9G) быть задействован и в Wayland.URL: https://mail.gnome.org/archives/release-team/2013-March/msg0...
Новость: http://www.opennet.me/opennews/art.shtml?num=36381
> подготовлен композитный бэкенд на базе FreeRDP для работы удалённых клиентовАй-ай-ай, что делается.
Mir - хитрый план Марка?
покрыто мраком
> покрыто маркомfixed
да да... тоже сразу подумалось, что Марк решил дать под зад ускоряющего пня вялено-разрабам
А в конечном итоге марк так или иначе до цели долетит. При том я не думаю что ему так уж принципиально на чьей именно ракете. На той которая будет раньше готова. High-profile trolling...
в контексте вашего ответа интересно на какой ракете^W^H^Hм ините долетит марк// я не фанат системд, но мне он больше нравится чем апстарт
> // я не фанат системд, но мне он больше нравится чем апстартА обрисуете его плюсы относительно апстарта? Раз уж вы оба пробовали и видимо достаточно плотно? Апстарт понравился простотой и логичным подходом. Написать джоб-файл очень просто, занимает мизер времени и там можно сразу задать юзера, приоритеты, минимальный мониторинг того процесс не сдох и прочие типовые нужности для сервиса.
Ну ладно, с cgroups - лихо закручено, согласен. Скоро в лине будет что-то типа openvz вообще сразу из коробки.
lxc на cgroups [https://ru.wikipedia.org/wiki/LXC]? умертвившая openvz...
> lxc [...] умертвившая openvz...Брр, это разные вещи. Хотя на 2.6.32-ovz изрядно потряхивало, сейчас УМВР (а вот у хорошего знакомого крупные проблемы, но на другом дистрибутиве и с другими задачами).
> Брр, это разные вещи.Почти. Смысл openvz - умный chroot. Смысл контейнеров в том же, только реализовали это не кучей патчей а с использованием новеньких cgroups. Соответственно openvz с кучей патчей так и не успел попасть в ядро, а теперь не имеет смысла, т.к. есть более совершенная замена.
OpenVZ конечно будут использовать еще долго, хотя мигрировать виртуальные машины довольно легкая задача.
P.S. Если я не прав где то напишите пожалуйста. Честно говоря опыт работы с openvz у меня минимальный.
> Смысл openvz - умный chroot.Скорее попил ресурсов, см. /proc/user_beancounters ;)
> Смысл контейнеров в том же, только реализовали это не кучей патчей,
> а с использованием новеньких cgroups. Соответственно
> openvz с кучей патчей так и не успел попасть в ядро,
> а теперь не имеет смысла, т.к. есть более совершенная замена.Полностью неверно.
http://www.opennet.me/openforum/vsluhforumID3/77225.html#55
> OpenVZ, конечно, будут использовать еще долго, хотя мигрировать виртуальные машины -
> довольно легкая задача.Это не виртуальные машины, а виртуальные окружения.
> P.S. Если я не прав где, то напишите, пожалуйста. Честно говоря, опыт
> работы с openvz у меня минимальный.У меня минимальный с lxc, а вот с ovz уже некоторый есть...
> Скорее попил ресурсов,Попил ресурсов + контейнеры. За первое нынче отвечают cgroups. За второе - lxc. Собственно опенвза на них вроде как и базируется нынче. Ну да, для больших окружений опенвз явно удобнее. Тем не менее, по состоянию на данный момент похоже уже можно лепить упрощенный аналог на чисто LXC + cgroups. И да, есть важный плюс: все это в дефолтном ядре есть, дистрибутивном или ванильном. Без каких либо посторонних патчей и ядер, которые весьма на любителя. ИМХО, намного лучше когда функционал в системе сразу, а не после танцев с бубном.
>> а теперь не имеет смысла, т.к. есть более совершенная замена.
> Полностью неверно.Абсолютно, openvz скорее надстройка над всем этим.
> Это не виртуальные машины, а виртуальные окружения.
Но с точки зрения управления - можно и как виртуальной машиной в принципе рулить.
> У меня минимальный с lxc, а вот с ovz уже некоторый есть...
Ну вот при всей ругани на поттерингоподелия, они судя по всему позволят более менее удобно поднимать LXC контейнеры и пилить ресурсы cgroups'ами. И вот как раз то что у вас "минимальный [опыт] с lxc" - как раз прозрачно намекает что были определенные сложности с инструментарием. Поттерингоподелие при всех спорных моментах похоже нацелилось частично исправить это упущение.
> Брр, это разные вещи.Вообще, по логике вещей, cgroups + lxc == "почти openvz".
>> Брр, это разные вещи.
> Вообще, по логике вещей, cgroups + lxc == "почти openvz".Не-а. Ни в ядерной части, ни в юзерспейсной.
> Не-а. Ни в ядерной части, ни в юзерспейсной.Я с функциональной точки зрения. По сути LXC+cgroups позволяют нынче слепить нечто наподобие опенвзшных контейнеров с фэйковыми юзерами и полисовкой ресурсов уже и сами по себе. Ну а опенвз с ядерной точки зрения все больше и больше базируется на данных подсистемах. Что логично, хорошо и правильно. Все больше становясь не столько серией отдельно стоящих костылей, сколько надстройкой над штатными подсистемами ядра. Подобный вектор развития и сами представители параллелсов не скрывают особо. По логике вещей им так тоже проще будет.
Другое дело что в вопросах управления и функционала опенвз в большом отрыве. Но, собственно, столько счастья может быть надо не всем и не везде. А поттеринговые поползновения позволят некий простой рулеж упомянутыми подсистемами какими-нибудь более-менее штатными системными средствами. С чем пока как раз несколько не фонтан. Ну то-есть в теории можно самому все это докостылить - но тогда придется написать заметный кусок того что уже есть в systemd. А нормальный админ как известно должен быть ленив...
> По сути LXC+cgroups позволяют нынче слепить нечто наподобие опенвзшных контейнеровБез UBC -- о-очень сильно наподобие.
> Ну а опенвз с ядерной точки зрения все больше и больше базируется на данных
> подсистемах. Что логично, хорошо и правильно. Все больше становясь не столько
> серией отдельно стоящих костылей, сколько надстройкой над штатными подсистемами ядра.
> Подобный вектор развития и сами представители параллелсов не скрывают особо.Для не ходящих по ссылкам на предыдущие серии влинкую статиком: эти штатные подсистемы во многом и растут из более ранних наработок по ovz. Естественно, в процессе upstream merge видоизменяются с учётом других интересантов, что приводит к необходимости портирования ещё не вошедшего кода на уже mainline.
> А нормальный админ как известно должен быть ленив...
Так всё и работает. :)
> Без UBC -- о-очень сильно наподобие.давайте не буду говорить куда UBC лучше засунуть?
hint - что хорошо подходит для полностью изолированных контрейнеров - что очень плохо подходит для окружения корые могут частично обменитьсяhint2 - посмотрите по changelog - когда они наконец пофисили все баги в cpu шедулере.
hint3 - iolimit в openvz - может стоить вам deadlock с журналом.
> Для не ходящих по ссылкам на предыдущие серии влинкую статиком: эти штатные подсистемы во многом и растут из более ранних наработок по ovz.Которые в нарушение GPL они не стремились открывать. Да и сейчас при передаче им патчей требуют и передачи прав на код.
Засим откланиваюсь.
> давайте не буду говоритьДавайте.
> когда они наконец пофисили все баги
"Я нашёл последний баг!" (ц) начинающий разработчик
> hint3 - iolimit в openvz - может стоить вам deadlock с журналом.
Вот тут спасибо, но AFAIK не налетал.
> давайте не буду говорить куда UBC лучше засунуть?Разве что вам в глотку, для улучшения культуры общения. А то толпень хостеров пользуется опенвзой и в ус не дует. И только у гражданина с характерным ником - проблемы, оказывается. Очень характерно. Вот только у индивида перфекционизм какой-то очень уж избирательный. Почему-то требуется только от линя. А от остальных - не обязательно уже. Это называется словом "лицемерие".
> hint - что хорошо подходит для полностью изолированных контрейнеров - что очень
> плохо подходит для окружения корые могут частично обменитьсяКакой-то высосанный из пальца тезис на песке. А откуда этот бред следует?
> hint2 - посмотрите по changelog - когда они наконец пофисили все баги в cpu шедулере.
А 20 лет назад я вообще MS-DOS'ом пользовался и мечтать о таких наворотах не смел. И?
> hint3 - iolimit в openvz - может стоить вам deadlock с журналом.
Баги есть в любом софте. Если вы не хотите сталкиваться с багами - вариантом является разве что забыть про компьютеры и вернуться в пещеры.
>> во многом и растут из более ранних наработок по ovz.
> Которые в нарушение GPL они не стремились открывать. Да и сейчас
> при передаче им патчей требуют и передачи прав на код."Кто старое помянет - тому глаз вон. А кто забудет - тому оба!"
> Засим откланиваюсь.
Встретимся в аду.
> Без UBC -- о-очень сильно наподобие.ИМХО вы утрируете. Основной функционал, т.е. попиловка на контейнеры и полисовка ресурсов - уже есть. Да, оно менее наворочено чем в openvz и с управляторами у openvz явно лучше. Но openvz все-таки мигрирует в сторону становления надстройкой над этими механизмами. Поэтому в простых и нетребовательных случаях (типа изоляции программ на юзеровском писюке или распиловка сервака на части без жестких "хостерских" требований) - LXC+cgroups уже и сами в общем то и сами подойдут. Иногда это может быть полезно.
>> Подобный вектор развития и сами представители параллелсов не скрывают особо.
> Для не ходящих по ссылкам на предыдущие серии влинкую статиком: эти штатные
> подсистемы во многом и растут из более ранних наработок по ovz.Ну спасибо вам, Капитан. Я стараюсь мониторить состояние дел в линуксном ядре, кто, что и почему. Поэтому вы прокапитанили почем зря :). Я кстати вполне положительно отношусь и к openvz и к их инициативам. Просто я констатирую что у любого подхода есть свои сильные и слабые стороны. У openvz есть свои грабли. Некоторые из них в некоторых ситуациях мне не симпатичны. Это нормально.
> Естественно, в процессе upstream merge видоизменяются с учётом других интересантов,
> что приводит к необходимости портирования ещё не вошедшего кода на уже mainline.Все так. Однако парочка мыслей:
1) И все-таки, мне было бы удобно когда нужный функционал в системе есть сразу в ее родном ядре, а не в каких-то побочных ядрах черти-каких версий.
2) Если уж функционал есть, хорошо бы и инструментарий для управления оным поблизости.>> А нормальный админ как известно должен быть ленив...
> Так всё и работает. :)Так никто и не спорит. Опенвз годами вкалывает у хостеров. Неплохо вкалывает. И вообще хорошая штука в своей нише. Просто в ряде случаев openvz не очень удобен. Например пилить им 1-2 сервака или даже домашнюю машину на контейнеры такой штукой не больно как удобно. Хотя-бы потому что при прочих равных я предпочитаю максимально свежее ядро. А вот с openvz в этом плане обычно грабельки. Все-таки нужда в каком-то побочном допатченном кастомном ядре - это недостаток при прочих равных. При масштабных применениях с большими требованиями, типа хостингов - это ничего. Но при менее масштабных и более простых применениях это уже неудобно.
>> Без UBC -- о-очень сильно наподобие.
> ИМХО вы утрируете.Нет, всего лишь сравниваю с практической точки зрения.
> Просто в ряде случаев openvz не очень удобен. Например пилить им 1-2 сервака
...позволяет раскладывать по ним задачи на отдельные зоны ответственности/обновления/пролома (как и LXC в меньшей мере, т.е. это плюс контейнеризации как таковой -- но конкретно ovz вовсю годится для в т.ч. и конкретно такого применения).
Кстати, минимум двое знакомых и на рабочей станции его держат.
> lxc на cgroups [https://ru.wikipedia.org/wiki/LXC]? умертвившая openvz...Я же скаал что на это не кивать. Ну да, это они довольно удачно придумали. Правда до умерщвления опенвз им пока как пехом до Пекина, особенно учитывая что он над ними теперь и базируется.
> lxc на cgroups [https://ru.wikipedia.org/wiki/LXC]? умертвившая openvz…а я и у тебя спрошу: какой смысл давать https-ссылку? в чём её преимуществно *в данном случае*? недостаток я вижу: тормозит. а вот преимуществ найти не могу.
> преимуществ найти не могу.Му....цким ISP, которые в последнее время конкретно так буеют
1) Сложнее логгить посещаемые урлы.
2) Сложнее классифицировать и полисовать траффик.
3) Сложнее несанкционированно модифицировать траффик. Для такой борзости как врезка рекламы, например (да, и такое нынче тоже бывает).
> 1) Сложнее логгить посещаемые урлы.ничего, IP-шники никуда не делись. и ребята, подобные trustwave, которые спокойно продают поддельные сертификаты, завереные root authority.
> 2) Сложнее классифицировать и полисовать траффик.
https? в даун его. вот и все сложности.
> 3) Сложнее несанкционированно модифицировать траффик. Для такой борзости как врезка рекламы,
> например (да, и такое нынче тоже бывает).а за это можно и глаз на задницу натянуть.
Они его создали чтобы Wayland начали пилить быстрее. План оказался настолько хитрым...
Ну да, хитрый план. Он создаёт свои стандарты, не совместимые с другими дистрибутивами(про другие ОС я вообще молчу). Внедряет их в самый популярный дистрибутив. Этим осуществляет привязку пользователя к Ubuntu-специфичным сервисам, инфраструктуре и приложениям. А потом они не смогут соскочить на что-то другое. Потому, что привыкли уже к приложениям, работающим только в его дистре. Этот трюк в своё время провернули парни из Microsoft, а затем(гораздо в более жёсткой форме) парни из Apple. Я сейчас юзаю Ubuntu, так как вечно бэкапить свой арчик(иногда там всё ломается, и нужно восстанавливаться из бэкапа, а потом разбираться) мне надоело. Но юзаю Ubuntu с Gnome. Если приложения для Ubuntu будут юзать Mir, и не будут работать в Wayland - я перейду на Debian, благо я на нём вполне комфортно себя чувствовал(или на Fedora, если захочется свежих пакетов).
>Он создаёт свои стандартыЧего?
>про другие ОС я вообще молчуСам то понял что сказал?
Дальше читать бессмысленно…
С какого бодуна Марк должен становиться подстилкой для поттерингов, редхатов и прочего болота, "задающего стандарты"? Космонавт делает так, чтоб работало. Разве не в этом прелесть СПО - возможность выбирать?
Если это правда - тянет на троллинг года.
> нерабочий кал без десктопа мигрирует на нерабочий кал без драйверов.Слоупоки такие слоупоки. Если вы не заметили, последние несколько лет графическая система в Linux окончательно оформилась в более-менее стройную и логичную штуку.
На низком уровне есть ядро делающее совсем базовые операции с GPU (в том числе модули драйверов для соотв. GPU знающие как с ним работать на самом низком уровне). Ну там управление частотами и вольтажами, работа с памятью, переключение режимов, ...
Далее, есть библы вывешивающие все эти сервисы (libkms, libdrm) юзермоду. Есть довески-плагины к таковым либам, являющиеся user-mode выносками. Там может быть всякая продвинутость, обучающая либу ускоренно работать с конкретным GPU.
Все остальное так или иначе является клиентом данной подсистемы. Пофиг иксы ли, вяленый или там кто еще. В конечном итоге сейчас базовый функицонал реализует вот эта вот подсистемка. Все идет к тому что она возможно станет "фреймбуфер 2.0 и прочая". В смысле, уже идут разговоры чтобы прибить fbdev совсем и оставить только это. Поскольку через это делается и примитивный вывод графики а-ля тупой фреймбуфер, и навороченный, с 3D и прочими покемонами. Поэтому блеяния про "без драйверов" смотрятся очень забавно. Де факто, к самим по себе иксам прибит аж целый DDX драйвер. Являющийся особенностью самих иксов и их концепций. Остальные могут так или иначе акселерированно рисовать через libdrm и ее довески. Xorg+DDX драйвер == очередной клиент этой же подсистемы.
> Слоупоки такие слоупоки. Если вы не заметили, последние несколько лет графическая система
> в Linux окончательно оформилась в более-менее стройную и логичную штуку.Если вы не заметили, это всё на низком уровне. А ближе к пользователю - треш и угар. Причём чем дальше, тем больше.
> Если вы не заметили, это всё на низком уровне. А ближе к
> пользователю - треш и угар. Причём чем дальше, тем больше.Почему же, я заметил что иксы могут жрать больше проца чем тот кто через них рендерит. Это - треш и угар. Поэтому я склонен приветствовать выкидывание столь жирной и тормозной прослойки по пути между подсистемой direct rendering manager'а и пользовательской программой.
p.s. но все это было сказано в основном про наличие драйверов. В иксах живет только очень небольшая часть драйверов, нужная исключительно самим иксам.
> Почему же, я заметил что иксы могут жрать больше проца чем тот
> кто через них рендерит.Никто не спорит, что Х нужно менять. Именно потому, что в них треш и угар. Но, понимаете, невозможно заменить грузовик на мопед. Поэтому мы так и останемся с нашим любимым "студебеккером". :-)
Эта "жирная и тормозная прослойка" делает массу неочевидных вещей, которые нужно делать, и про которые забывают авторы очередной SVGAlib. Да, её нужно делать менее тормозной и менее жирной, она должна быть многопоточной и т.д., но от неё никуда не деться, если хочется получить полноценную оконную систему.
> Никто не спорит, что Х нужно менять. Именно потому, что в них
> треш и угар. Но, понимаете, невозможно заменить грузовик на мопед.Невозможно. При условии что вам надо было именно грузовик. Особенно учитывая что он делался под все мыслимые применения - вплоть до доставки 10 тонн песка из карьера за раз. Ну вот вы знаете, не очень удобно на тормозном неуклюжем самосвале катить в магазин за хлебушком. Мопед или легковушка с этим справится лучше. И это как-то намного чаще требуется. Поэтому популярность легковушек - во, а у самосвалов - во.
> Поэтому мы так и останемся с нашим любимым "студебеккером". :-)
Так я не против, я понимаю что задачи бывают разными. Но мне вот с моими задачами не очень удобно на карьерном самосвале в магазин за хлебушком ехать. Поэтому я при налиции опций выберу более разумное для задач средство. Я при этом признаю что кому-то натурально надо 10 тонн песка, из карьера, за раз. Просто это не означает что надо всем сватать лишь неповоротливые десятитонные самосвалы. По логике вещей легкие и небольшие персональные средства будут намного популярнее.
> Эта "жирная и тормозная прослойка" делает массу неочевидных вещей, которые нужно делать,
Понимаете ли, ваши понимания о том что "нужно делать" могут не стыковываться с моими пониманиями о том что нужно делать. Вот вам надо 10 тонн из карьера за раз. А мне - нет. Зачем тогда сватать мне неповоротливый самосвал? Ну нет у меня задач возить по 10 тонн за раз.
> и про которые забывают авторы очередной SVGAlib.
Должен быть какой-то разумный баланс между тупым фреймбуфером где программа сама вообще ВСЕ делает и тормозными переростками типа иксов. С учетом того что современные тулкиты сами все рендерят - баланс имхо должен подвинуться в сторону "современный svgalib". То-бишь поближе к уровню рендеринг менеджера. С дорожкой в оный как можно короче.
> Да, её нужно делать менее тормозной и менее жирной, она должна быть многопоточной
> и т.д., но от неё никуда не деться, если хочется получить полноценную оконную систему.Понятия о том что такое полноценная оконная система у всех опять же разные. Кому-то надо 10 тонн песка за один присест. А кому-то нет. С моей колокольни желание иметь карманный складной самосвал, который при желании надувается или раскладывается и все-таки в состоянии перевезти желаемые 10 тонн - это замечательно. Но у меня есть одно нехорошее подозрение, состоящее в том что такой набор требований сильно усложнит конструирование такой штуки в целом. Из-за ряда довольно противоречивых требований на самом старте.
> Невозможно. При условии что вам надо было именно грузовик.Да. Нужен именно грузовик, т.к. задачи десктопов и получившихся из них ноутов за 30 лет качественно не поменялись.
Кстати, мопед - SVGAlib и DirectFB уже есть. Это хорошие мопеды, хотя и слегка устаревшие.
> Так я не против, я понимаю что задачи бывают разными. Но мне
> вот с моими задачами не очень удобно на карьерном самосвале в
> магазин за хлебушком ехать.Езжайте на мопеде - DirectFB http://directfb.org
> Ну нет у меня задач возить по 10 тонн за раз.
DirectFB в помощь. Wayland в режиме работы с одним локальным окном, развёрнутым на полный экран тоже сгодится. Он, кстати, похоже под это и проектировался.
> Должен быть какой-то разумный баланс между тупым фреймбуфером где программа сама вообще
> ВСЕ делает и тормозными переростками типа иксов.Нет этого баланса - все современные оконные среды построены на архитектуре посылки сообщений и содержат ряд стандартов для общения программ и окон. Вы можете построить однооконную однопрограммную среду типа DirectFB, она будет изящна и быстра, но не пригодна для замены Х/Win32/Aqua.
> Понятия о том что такое полноценная оконная система у всех опять же
> разные.30 лет прошло, можно и определиться. У вас перед глазами 3 оконных системы - Aqua, Win32, X. Они более-менее похожи, у каждой есть сильные и слабые стороны. Но их отличия от Wayland'а/DirectFB/SVGAlib значительно выше, чем между собой.
> Да. Нужен именно грузовик, т.к. задачи десктопов и получившихся из них ноутов
> за 30 лет качественно не поменялись.Ну, вам нужен. А мне - нет. Вроде бы все просто. Поэтому я буду пользоваться тем что нужно мне. А вы - тем что нужно вам. Вроде бы логично. А разработчики будут разрабатывать то что им нужно/хочется/удобнее/проще/... - тоже вроде логично.
> Кстати, мопед - SVGAlib и DirectFB уже есть. Это хорошие мопеды, хотя и слегка устаревшие.
Современный GPU - прежде всего могучая числокрушилка. С массой возможностей по ускорению графических (и не только) операций. Пытаться представить это как фреймбуфер или какое-то там svga - не релевантно наблюдаемым реалиям.
> Езжайте на мопеде - DirectFB http://directfb.org
Оно в принципе даже смотрелось интересно одно время. Но насколько я понял, их разработчики не особо парятся по поводу более-менее прямой и логичной стыковки с подсистемами KMS/DRM и больше ориентируется на тупые фреймбуферы, которые imho в линуксе в перспективе обречены околеть. В пользу более универсальных подсистем типа KMS+DRM. Ну и интеграция с тулкитами, etc. И какой-никакой менеджмент окон должен быть. В directfb когда я его видел это было на уровне совсем уж какого-то PoC'а практически. У вэйланда есть шансы сделать то что другим оказалось не под силу.
>> Ну нет у меня задач возить по 10 тонн за раз.
> DirectFB в помощь.Кривоватый мопед сваренный из старых водопроводных труб - это, конечно, замечательно, но я все-таки предпочту более симпатичные экспонаты. На мое мнение wayland получается куда более похожим на то что мне хотелось бы видеть.
> Wayland в режиме работы с одним локальным окном, развёрнутым
> на полный экран тоже сгодится. Он, кстати, похоже под это и проектировался.Не вижу что помешает вэйланду работать с более чем одним окном. Более того - IIRC, у иксов имеется свой фирменный дебилизм по данной теме. IIRC, они вообще не хранят отрендеренные состояния окон нигде и никак. И потому их скорость работы с перекрывающимися окнами без подстановки всяких костылей - не рулит. Потому что программы должны каждый раз перерендеривать затертое содержимое окна. Нет, это было нормальным вариантом. В эпоху когда оперативки было мизер, оно душило систему сильнее чем нехватка проца, т.к. своп - тормозно. Но в эпоху когда гиг памяти паяют в карманный смартфон - это уже просто ничем не оправданный маразм. По нормальному дисплейная система должна кешировать зарендеренные окна и не дергать апликухи на каждый пук с требованием "ой, перерисуй себя, ой перерисуй себя, ой, ну перерисуй же себя вот здесь".
>> ВСЕ делает и тормозными переростками типа иксов.
> Нет этого баланса - все современные оконные среды построены на архитектуре посылки
> сообщений и содержат ряд стандартов для общения программ и окон.Сама по себе локальная рассылка сообщений тормозить не обязана. А чему там тормозить, если делать с умом? А вот парсинг всяких задрюченных протоколов при вдувании таким манером огромных битмапов и прочие бестолковости уже могут основательно все тормознуть и пригрузить проц. А какой-нибудь GDI по жизни делает тяжелые операции типа сплевывания больших битмапов через системные вызовы. Сообщениями по шине они не летают и никто не парсит там замороченные протоколы. И да, по этому поводу GDI у этих редмондовских фруктов в новых виндах уже перестал быть таким слоупоком как раньше. На уровне дизайна там тормозить особо нечему. Тяжелые вещи обычно делаются лобовыми сисколами, с передачей жирных сущностей таковым. То-есть, шины сообщений дополняют сисколы. Ну, с таким же успехом можно прицепить к вэйланду какой-нибудь дбас, если есть уверенность что это сильно надо.
> Вы можете построить однооконную однопрограммную среду типа DirectFB, она будет изящна и
> быстра, но не пригодна для замены Х/Win32/Aqua.Ну вы знаете, я когда-то немного программил под win32 и поэтому имею честь заметить что у вас какие-то очень уж сферические и идеализированные представления о GDI.
> 30 лет прошло, можно и определиться. У вас перед глазами 3 оконных
> системы - Aqua, Win32, X.У меня перед глазами намного больше чем это. Ну и пока-что я думаю что нечто типа вэйланда мне было бы в самый раз.
> Они более-менее похожи,
Не более чем карьерный самосвал на болид F1. Конечно, они оба автомобили, у обоих есть руль, колеса и двигатель. На этом сходство и заканчивается.
> у каждой есть сильные и слабые стороны. Но их отличия от Wayland'а/DirectFB/SVGAlib
> значительно выше, чем между собой.Ну как бы ставить вэйланд в один ряд с svgalib - это тоже знаете ли, сравнение ежа с ужом.
> Ну, вам нужен. А мне - нет. Вроде бы все просто. Поэтому
> я буду пользоваться тем что нужно мне.Я вам для вашего осциллографа так и рекомендую - пользуйтесь Wayland в режиме одно окно на весь экран (там не надо кнопок максимизации/минимизации, да и заголовок рисовать не нужно) или уже допиленным DirectFB или SVGAlib - что лучше подходит для вашей задачи.
Но не забывайте, что многооконная система, рассчитанная на десктоп - это не SVGAlib. Это более сложная система. Это Х, Win32, Aqua. И вопросы производительности у неё стоят ПОСЛЕ вопросов удобства. В частности, оконной системой невозможно пользоваться, если у неё нет кнопки максимизации/минимизации, но можно пользоваться, если видео в ней ВООБЩЕ не показывается.
> У вэйланда есть
> шансы сделать то что другим оказалось не под силу.Заметь-те, не в плане замены Х, а в плане замены DirectFB.
> На мое мнение wayland получается
> куда более похожим на то что мне хотелось бы видеть.Вам нужен осциллограф, вы думаете, что W лучше DirectFB - пользуйтесь W.
>> Wayland в режиме работы с одним локальным окном, развёрнутым
>> на полный экран тоже сгодится. Он, кстати, похоже под это и проектировался.
> Не вижу что помешает вэйланду работать с более чем одним окном.Непродуманность работы W с несколькими окнами.
> И потому их скорость работы с перекрывающимися окнами без подстановки
> всяких костылей - не рулит.И что? Да, на тормозящей оконной системе можно работать, а на оконной системе, в которой нет элементарных удобств - нет.
> Я вам для вашего осциллографа так и рекомендую - пользуйтесь Wayland в
> режиме одно окно на весь экран (там не надо кнопок максимизации/минимизации,
> да и заголовок рисовать не нужно) или уже допиленным DirectFB или
> SVGAlib - что лучше подходит для вашей задачи.Как мне еще понятнее обяснить что я хочу чтобы такие програмки работали параллельно с остальным софтом, поделив с ним экран(ы) и вычислительные мощности? Ни directfb ни svgalib меня не устроят для повседневного использования моего компьютера. А вот нечто wayland-образное - почему бы и нет? И да, я хочу чтобы дамп отсчетов на экран, с частотой монитора и по произвольной площади - не тормозил. В обычной программе. Чтобы я мог мотать немеряную OSMную карту без того что X-овый процесс жрет в три раза больше проца чем прога которая это рендерит, чтобы в браузере не тормозили трансформации и анимации, показ видео и что там еще.
... а потом такие люди еще и удивляются: ой, а чего-это все пихают OpenGL в каждую дырку? А то что в него выплюнуть битмап как текстуру и то быстрее оказывается чем через слоупочные иксы толкать. Вот и начинают процветать такие странноватые извращения.
> Но не забывайте, что многооконная система, рассчитанная на десктоп - это не
> SVGAlib. Это более сложная система. Это Х, Win32, Aqua. И вопросы
> производительности у неё стоят ПОСЛЕ вопросов удобства.Для меня вопрос производительности == вопрос моего удобства при использовании системы. Как еще понятнее это объснить? Штука типа wayland для лично меня не будет чем-то "более неудобна" чем иксы. Потому что я буду один фиг пользоваться функционалом который и там и там - есть. Стало быть я ничего не потеряю и неудобств не испытаю. А вот слоупочная скорость вывода графики создает мне вполне ощутимое неудобство при повседневном использовании компьютера там и тут.
> В частности, оконной системой невозможно пользоваться, если у неё нет кнопки
> максимизации/минимизации,Как вы могли заметить - у wayland есть ряд детских проблем, но стараниями Шатлворта сейчас кажется разработчики выполнят пятилетку за пару месяцев :)
> но можно пользоваться, если видео в ней ВООБЩЕ не показывается.
Вам - можно. А я таким пользоваться в 2013 году вообще не буду при наличии хоть каких-то иных альтернатив. Прикиньте? Для разных людей разные фичи могут иметь разный приоритет. Вон в той же Win32 работа с отдельными окнами по сети - вообще толком не предусмотрена. А 90% юзерей на это как-то глубоко до балды оказалось.
>> У вэйланда есть шансы сделать то что другим оказалось не под силу.
> Заметь-те, не в плане замены Х, а в плане замены DirectFB."В плане замены графической подсистемы на моем десктопе". Мне не так уж принципиально кто именно там будет, если он сможет обслуживать мои пожелания к графической подсистеме. Нетворкинг и прочие навороты лично мне не требуются. Мне элементарно негде и незачем это применять (особенно учитывя что по медленным каналам оно без костылей вообще не жилец). А вот тормозная локальная графика меня достаточно заметно анноит.
>> На мое мнение wayland получается куда более похожим на то что мне хотелось бы видеть.
> Вам нужен осциллограф, вы думаете, что W лучше DirectFB - пользуйтесь W.Мне нужен не осциллограф. Мне нужен универсальный компьютер, который сможет до кучи быть "еще и осциллографом". А также редактором карт OSM. Браузером интернета. Графическим редактором. Печатной машинкой. CADом. И чем там блин еще. И некие из этих задач могут, имеют право, подразумевать способность быстро вываливать графику на экран. А вот их програмеры не сильно хотят напрягаться на кастом-костылинг для конкретно иксов, при том что используемый тулкит поддерживает еще десяток ОС и каждой из них столько внимания уделать - рехнуться можно.
>> Не вижу что помешает вэйланду работать с более чем одним окном.
> Непродуманность работы W с несколькими окнами.Это частично есть, но как видите они вон бросились допиливать. Сейчас они кажется благодаря Шатлворту вспашут это рекордными темпами :)
> И что? Да, на тормозящей оконной системе можно работать, а на оконной
> системе, в которой нет элементарных удобств - нет.Понятия об удобстве у разных индивидов отличаются. И мне имхо виднее как мне будет удобно. На данный момент у меня есть основания полагать что в wayland мне скорее всего будет удобнее когда его допилят. Он, конечно, обрастет при этом костылями. Но в основе его дизайна чисто физически нечему так тупить как в иксах. Ну, как в титановом шарике как-то нечему ломаться :)
> Как мне еще понятнее обяснить что я хочу чтобы такие програмки работали
> параллельно с остальным софтом, поделив с ним экран(ы) и вычислительные мощности?
> Ни directfb ни svgalib меня не устроят для повседневного использования моего
> компьютера.я тебя ещё раз настоятельно прошу сходить на сайт DirectFB.
> Ну вы знаете, я когда-то немного программил под win32 и поэтому имею
> честь заметить что у вас какие-то очень уж сферические и идеализированные
> представления о GDI.Я упомянул Win32 лишь в одном месте, никак не охарактеризовав. А вы уже и диагноз мне написали. Перестаньте.
> Я упомянул Win32 лишь в одном месте, никак не охарактеризовав. А вы
> уже и диагноз мне написали. Перестаньте.Просто win32 вами явно идеализирован и приукрашен. Он конечно об работе с окнами, но как раз только локальной. И на уровне дизайна там явно меньше поводов тормозить чем у иксов. В новых виндах насколько я знаю скорость работы оного изрядно подтянули.
> Просто win32 вами явно идеализирован и приукрашен.Вы телепат? Я с win32 в своё время так трахался, что ни в сказке сказать, ни пером описать.
Но и win32, и X, и Aqua по сравнению с SVGAlib для пользователя представляют примерно одно и то же. Это, как бы они не были костыльны, многооконные среды, позволяющие делать то, к чему привык пользователь. Перевести его обратно в MS DOS, где одна задача занимает десктоп целиком, не удастся. А именно такое поведение характерно для SVGAlib№Х.
>[оверквотинг удален]
> из карьера
> за раз
> 10 тонн
> из карьера
> за раз
> 10 тонн
> за раз.
> 10 тонн
> песка
> 10 тоннЗаметьте, не переставлено ни буковки, только убраны промежуточные для иллюстративности.
Эта выжимка поразила настолько, что решил пропустить 2538 символов (4548 байт) исходного текста в UTF-8 через gzip -- получилось 904 символа (1693 байта).
Точно читали про компрессию, а не декомпрессию? :)
> текста в UTF-8 через gzip -- получилось 904 символа (1693 байта).Вполне нормальная степень сжатия для текста для LZ+Huffman, btw. И, кстати, мне очень интересно: что такое "получилось 904 символа". Символа ... чего? Уникода? А что, гзиповский компрессор смог сгенерировать валидную последовательность UTF8? Мне это кажется "крайне маловероятным" событием.
> Точно читали про компрессию, а не декомпрессию? :)
Наверное это про 904 сферических символа в вакууме :)
> что такое "получилось 904 символа". Символа ... чего? Уникода?Эээ... да, это кое-кто перестарался с wc -m. %) Глупость ляпнул, а сорок тонн оценили, надеюсь.
> а сорок тонн оценили, надеюсь.Их LZ из gzip'а оценил, имхо :)
И кто тут говорил, что mir не нужен и бесполезен?
Рыбак рыбака видит издалека.
Два сапога - пара.
Ворон ворону глаз не выклюет :)
Слово не воробей, в лес не убежит.
не плюй в колодец, вылетит, не поймаешь
wayland птица гордая, пока не пнешь-не взлетит :)
> Слово не воробей, в лес не убежит.Рожденный ползать - на голову не нагадит!
Не понятно из новости: Гномеры Mutter адаптируют под Wayland, или будут использовать Weston для gnome shell?
Да!
Старый mutter уже адаптирован под старый wayland. Это нужно только привести в чувство.
https://git.gnome.org/browse/mutter/log/?h=wip/wayland-stacking
>разработчик GNOME из компании Red Hatвот так совпадение!
только хотел сказать. Ну сначала мы создадим свое детище - а потом всех туда перепихнем и будем контролировать..несколько новостей назад в этом обвиняли Убунту.. а тут такая уважаемая контора как RedHat позволяет себе сделать vendor lockin... ведь не может же ?
> только хотел сказать. Ну сначала мы создадим свое детище - а потом
> всех туда перепихнем и будем контролировать..Я пока вижу рост конкуренции и рубку за место под солнцем. Для кого-то зло. А для кого-то благо, ибо теперь проекты втопят в развитии и будут пытаться "быстрее, выше, сильнее". Ну а выиграют в итоге все.
>Ну а выиграют в итоге все.Кроме тех, кому нужна стабильность.
> Кроме тех, кому нужна стабильность.Спасибо, я уже вижу к чему приводит дебиановская стабильность. Вот смотри, баг в usb 3.0 стеке донимавший меня в некоторых местах починили в 3.9 RC1. А в каком году это будет в самых стабильных? И насколько мне такая стабильность нужна?
У меня вообще USB 3.0 под линуксом не работает :( Просто хаб втыкаешь - вообще без устройств - получаешь кучу ошибок, таймауты, стектрейсы от ядра..
Втыкаешь тот же (3.0) хаб в 2.0 порт - все работает..
> У меня вообще USB 3.0 под линуксом не работает :(Ну вот у меня он нормально и без глюков заработал в 3.9-rc1 и далее. До этого - нет, он тоже работал, но встречались какие-то весьма странные закидоны.
Например, если воткнуть в USB 3.0 (super speed) хаб 2.0 (hi-speed) устройство, ядро как-то очень странно понимало такое супер-комбо и заявляло что девайсу ... не хватит бандвиза.
Ну да, конечно, 3.0 хаб никак не прокачает данные для 2.0 девайса, лол. В 3.9 этот забавный тупняк пропал :). Нет, конечно, втыкать 2.0 девайс в 3.0 хаб не совсем оптимально, но fallback и обратная совместиомть то по изначальной идее - есть!
кто девушку ужинает, тот её и танцует.
никто никого не заставляет пользоваться чем-то. а уж если не можешь сам, то и не гони волну на того, кто умеет и делает как ему удобно
> кто девушку ужинает, тот её и танцует.
> никто никого не заставляет пользоваться чем-то. а уж если не можешь сам,
> то и не гони волну на того, кто умеет и делает
> как ему удобноВсе умеют и все делают. Просто одна конторка захотела поиметь всех потём полного контроля над базовыми компонентами.
Ну, гном - базовый компонент весьма условно, да и форки никто не отменял. Вон, когда припекло - тот же libreoffice отлично форкнули. А здесь - хорошая рубка, может и выйдет из неё что-то.
>Ну, гном - базовый компонент весьма условно, да и форки никто не отменял. Вон, когда припекло - тот же libreoffice отлично форкнули. А здесь - хорошая рубка, может и выйдет из неё что-то.Для начала придётся форкнуть все "стандарты", которые он порождает.
"но некоторые равнее"(с)
> ведь не может же?Здрасьте. За что и "любим".
Нате вам еще, для будущих поисков
http://fedoraproject.org/wiki/RedHatContributions
что ни день, то новый вброс)
Ну прекрасно
Лучше бы X12 пилили. Хотя, конечно, интересно, что из всего этого выйдет.
Объяснили тысячу раз уже. Сами разрабы иксов говорили, что невозможно запилить X12, не поломав совместимости с X11. За три десятка лет графические возможности компьютеров изменились до полной нестыковки. А раз совместимость всё равно ломать, то нет никакого смысла перелопачивать исходники иксов. Легче всё написать с нуля. Это был основной аргумент в поддержку создания Wayland.
Проблема в том, что пишут в валёном далеко не всё. А то, что написать не могут, сразу объявляют ненужными и устаревшими возможностями.
Рассылку почитай, потом говори
> Объяснили тысячу раз уже. Сами разрабы иксов говорили, что невозможно запилить X12,
> не поломав совместимости с X11. За три десятка лет графические возможности
> компьютеров изменились до полной нестыковки. А раз совместимость всё равно ломать,
> то нет никакого смысла перелопачивать исходники иксов. Легче всё написать с
> нуля. Это был основной аргумент в поддержку создания Wayland.Да, я знаю про несовместимость. Знаю также, что X12 попросту не хочет никто разрабатывать потому что это трудоёмко и просто скучно (подозреваю, что у тех избранных, которые знакомы с внутренностями Xorg по-настоящему, случаются приступы тошноты от одной мысли о копании в этих самых внутренностях). Но в то же время Wayland почему-то не вызывает у меня бурной радости. Дело даже не в пресловутой сетевой прозрачности, а в таких, странных, как мне кажется, вещах, как декорации на стороне клиента (как теперь оконный менеджер сможет понять, что окно не реагирует на кнопку закрытия?).
> Знаю также, что X12 попросту не хочет
> никто разрабатывать потому что это трудоёмко и просто скучноСамое главное, что тут надо думать. А думать человеческий мозг упорно не желает, подавать команды на мотонейроны ему значительно легче и приятнее.
> Самое главное, что тут надо думать. А думать человеческий мозг упорно не
> желает, подавать команды на мотонейроны ему значительно легче и приятнее.А вот у академиков - наоборот. Ну то-есть они любят указывать другим как надо делать. Но сами впрягаться в это ни за что не хотят. Наверное подозревают что потом мотонейронам придется очень много напрягаться а мозгу потом придется очень много вертеться пытаясь подогнать сферически-вакуумные концепции к реальному миру с реальными задачами, так что в результате вместо красивого концепта получится жутчайший клубок костылей и подпорок, гигантский, страшенный в майнтенансе, уродливый и просто переусложненный.
> А вот у академиков - наоборот. Ну то-есть они любят указывать другим
> как надо делать. Но сами впрягаться в это ни за что
> не хотят.Да, в этом и есть трагедия графической системы в UNIX. Кто может - тому лениво, кто не может, тот пилит.
> Наверное подозревают что потом мотонейронам придется очень много напрягаться
Нет. Академики, ровно также, как и простые смертные не любят шевелить мозгом, а тоже любят играть мотонейронами. :-) Не думаете же вы, что у академиков продумывание грамотной архитектуры (грамотнее, чем в прошлый раз) не потребует мозговых усилий?
а что мешает композитному серверу заниматься декорацией окон?!
> а что мешает композитному серверу заниматься декорацией окон?!http://stackoverflow.com/questions/5059798/cant-a-wayland-co...
Можно надеяться, что будет какая-то возможность у приложения (окна) спросить композитор, умеет ли он декорации, и если умеет — отключить свои собственные, реализуемые тулкитом, рамочки.
UPD: http://blog.martin-graesslin.com/blog/2013/02/client-side-wi.../
> Nothing in Wayland requires them
> QtWayland allows Clients to turn them off
> KWin as a Wayland compositor will use server side decorationsТо есть у некоторой части разработчиков всё относительно хорошо.
> Сами разрабы иксов говорили, что невозможно запилить X12,
> не поломав совместимости с X11.И что? Как будто Wayland не ломает совместимости с Х11.
Это отмазка. Реальная причина в том, что они просто не тянут. Наваять SVGAlib v4 могут, а вот сделать хорошую оконную систему - нет.
> Это отмазка. Реальная причина в том, что они просто не тянут. Наваять
> SVGAlib v4 могут, а вот сделать хорошую оконную систему - нет.Что значит хорошую оконную систему? Реальность такова, что все тулкиты сами рисуют все, что им нужно и остается только показать это на экране, ну декорацию нарисовать. Зачем городить X12 или что-то подобное?!
> Что значит хорошую оконную систему?Хотя бы такую, которая будет учитывать то, что пользователю не нужен зоопарк декораций, нужны минимизация/максимизация, желательна полная сетевая прозрачность (это значит, что шрифты, цвета и т.д. у приложений с разных машин одинаковы, что можно обеспечить лишь отрисовкой на сервере).
До кучи: http://lwn.net/Articles/536484/ (см. последний абзац статьи).
> До кучи: http://lwn.net/Articles/536484/ (см. последний абзац статьи).После 15-ти лет разработки Х до них стало что-то доходить.
Основная проблема, по-видимому, в том, что народ не может окинуть взором систему и её предназначения целиком. Берёт какой-то узкий участок, скажем, вывод видео или наложение окон с alpha-каналами, дальше абсолютно справедливо говорит - тут Х работают плохо. Но то, что помимо этого узкого участка есть ещё масса других вещей, неизменных со времён царя Гороха - не осознают.
Пытаются писать своё - получается очередная SVGAlib, в каком-то узкой задаче типа полноэкранного видео или прорисовки кнопок одной полноэкранной программы уделывающая по производительности Х раза в 2-3-4 на текущем железе, но из-за "закона Мура" обречённая на гибель лет через 5, когда производительность железа подрастёт до нужного уровня.
> После 15-ти лет разработки Х до них стало что-то доходить.Да, две вещи до них точно дошло.
1) Кульный протоколец иксов - тормоз и жрет ресурсы, так что графическая подсистема не соответствует ожиданиям большинства пользователей. В 2013 году ожидается что быстрый вывод графики на экран - это не опция. Не расширение. И не костыль. Это обязано быть дефолтным состоянием вещей. В каждой первой программе. Без каких либо оговорок и условий.2) Ну да, на третий день Зоркий Глаз заметил что у DRI2 оказывается были недостатки и можно сделать даже еще лучше. Особенно после того как DMA-BUF сделали.
...но все это - вообще не об иксах, а о том уровне про который я говорил выше.
> Основная проблема, по-видимому, в том, что народ не может окинуть взором систему
> и её предназначения целиком.Это стандартное состоение дел в больших проектах. Это нормально. Например, очень врядли что вы сможете вгрузить в ваш мозг архитектуру обычного писюка целиком и полностью. На уровне разработчика. Просто потому что это такой навороченный комплекс, что это примерно то же самое как требовать от архитектора вгрузить себе в мозг план всего города с миллионами жителей, с точностью до планировки квартир в каждом доме. Это нереально. Поэтому архитектор будет работать с своим закоулком.
> ещё масса других вещей, неизменных со времён царя Гороха - не осознают.
Это опять же нормально. Сначала надо решать базовые инфраструктурные задачи. А уже потом поверх нормально работающей структуры можно навороты строить. А когда все работает через пень колоду, но зато с кучей крутых концептуальных наворотов - это выглядит уныло.
> Пытаются писать своё - получается очередная SVGAlib,
Просто современные видеокарты отличаются от SVGA адаптера настолько же, насколько боинг отличается от этажерки братьев Райт. Этажерка братьев Райт была неважной штукой для перевозки пассажиров и грузов. А вот боинг - вполне себе ничего.
> "закона Мура" обречённая на гибель лет через 5, когда производительность железа
> подрастёт до нужного уровня.Где-то я это уже слышал. При том по мере роста закона Мура растут и запросы пользователей насчет качества графики, разрешений экранов и прочая. И в случае разрешения экрана зависимость аж квадратичная. Спокойно заткнет любой закон Мура за пояс. И вот чего-чего, а производительность оперативной памяти растет медленно. А при таких разрешениях экрана там летают натурально гигабайты данных. И парочка лишних копирований и парсинг протокола может быть весьма серьезным факапом. Ну понятно что в математических программах этого обычно нет. И то - достаточно возжелать выплюнуть реалтаймную картинку осциллограммы сигнала на экран - и вот вам уже немеряные потоки данных на экран. А почему, собственно, написание какой-то простейшей рендерилки входных данных в график должно требовать от програмера каких-то особых спецзнаний по использованию костылей для ускорения вывода графики? Вроде бы было так логично - читаешь отсчеты со входа - рисуешь график на экран. А тут тебе и говорят: хрен тебе, золотая рыбка. Изволь сперва изогнуться буквой зю и задетектить пяток опциональных расширений. А если их нету - придумай что будешь делать в этом случае. Во зашибись. Простая задача превратилась в некислое костылестроение и постройку чуть ли не целого спейсшаттла. С системой катапультирования и прочими прибамбасами.
> 1) Кульный протоколец иксов - тормоз и жрет ресурсы, так что графическая
> подсистема не соответствует ожиданиям большинства пользователей.Извините, но главный тормоз - это XRender. Если пользоваться изначальными примитивами Х, в которых нет alpha-канала (его надо было по-человечески добавить в 1996-м году), не тормозит ничего.
> 2) Ну да, на третий день Зоркий Глаз заметил что у DRI2
> оказывается были недостатки и можно сделать даже еще лучше. Особенно после
> того как DMA-BUF сделали.Ну вот пока Зоркий Глаз будет думать ИСКЛЮЧИТЕЛЬНО в терминах - как ускорить вывод графики ещё 1.5 раза, дела не будет. Ибо основная задача Х - это не вывод 4К видео, а построение скелета графического интерфейса пользователя. А 4К видео - это важная, безусловно, часть, но несколько второстепенная.
И, заметьте, прогресс железа может костыльным образом исправить тормознутость Х, но вот отсутствие минимизации/максимизации в Wayland никакими мега видеокартами и ЦП не исправить.
>[оверквотинг удален]
> Это стандартное состоение дел в больших проектах. Это нормально. Например, очень врядли
> что вы сможете вгрузить в ваш мозг архитектуру обычного писюка целиком
> и полностью. На уровне разработчика. Просто потому что это такой навороченный
> комплекс, что это примерно то же самое как требовать от архитектора
> вгрузить себе в мозг план всего города с миллионами жителей, с
> точностью до планировки квартир в каждом доме. Это нереально. Поэтому архитектор
> будет работать с своим закоулком.
>> ещё масса других вещей, неизменных со времён царя Гороха - не осознают.
> Это опять же нормально. Сначала надо решать базовые инфраструктурные задачи. А уже
> потом поверх нормально работающей структуры можно навороты строить.Нет, это не нормально. Большие системы в таких случаях бьют на малые системы, проводят анализ на языке этих малых систем, не вдаваясь в подробности - на это человеческого мозга хватает. Но обязательно наряду с рассматриванием закоулков нужно иметь хороший взгляд с птичьего полёта.
А поверх строить нельзя - W пилится уже 5 лет, а до сих пор на нём нормально KDE не взгромоздить. Пусть даже тормознуто.
> Просто современные видеокарты отличаются от SVGA адаптера настолько же, насколько боинг
> отличается от этажерки братьев Райт.А пользовательские задачи не отличаются практически никак - те же мышь, условное световое перо, клавиатура, несколько экранов, несколько машин под управлением одного пользователя. Это условия Х, соответственно, для построения инфраструктуры, заменяющей Х нужна система, учитывающая всё это. Но не очередная SVGAlib.
>> "закона Мура" обречённая на гибель лет через 5, когда производительность железа
>> подрастёт до нужного уровня.
> Где-то я это уже слышал.Даже могли видеть, наблюдая за SVGAlib и DirectFB - в своё время они здорово помогали выводить видео с нужной скоростью. Но мощности подросли и Х стали тянуть и видео.
> При том по мере роста закона Мура
> растут и запросы пользователей насчет качества графики, разрешений экранов и прочая.Разрешения экранов не растут - я тут с трудом добыл себе QXGA, 8-ми летней давности. Сейчас такие не выпускаются.
> И в случае разрешения экрана зависимость аж квадратичная. Спокойно заткнет любой
> закон Мура за пояс.Закон Мура экспоненциальный, друг мой. Собственно, всё у вас так - гонетесь за 2-х кратным ускорением в одном узком месте, убирая реально нужнейшие вещи.
> И вот чего-чего, а производительность оперативной памяти
> растет медленно. А при таких разрешениях экрана там летают натурально гигабайты
> данных.И что? Раньше летали мегабайты и это тоже поражало. Не переживайте, мощность растёт.
> И парочка лишних копирований и парсинг протокола может быть весьма
> серьезным факапом.Ну не смешите, парочка лишних копирований - это всего лишь 2 раза. Задача высокопараллельная, поэтому достаточно вставить 2 видяхи и всё, дело сделано.
> Ну понятно что в математических программах этого обычно нет.
В математических программах, ради 2-х раз никто не руки не марает. Только особо упоротые, т.к. смена алгоритма приводит к ускорению минимум на порядок, а то и несколько. Вам не хватает 4-х Гб памяти или 2-х ядер процессора? Поверьте, докупить ещё столько же много дешевле, чем править код.
> И то - достаточно возжелать выплюнуть реалтаймную картинку осциллограммы сигнала на
> экран - и вот вам уже немеряные потоки данных на экран.И? Смысл оптимизировать вручную есть тогда, когда либо это highload и стоимость всех серваков, где гоняется программа, запредельна, либо когда выигрыш - порядок, а не жалкие 2 раза.
> Вроде бы было так логично - читаешь отсчеты со входа - рисуешь график на экран.
> А тут тебе и говорят: хрен тебе, золотая рыбка. Изволь сперва изогнуться буквой зю и
> задетектить пяток опциональных расширений. А если их нету - придумай что
> будешь делать в этом случае.У вас не 2 раза провал по производительности, а больше. Ну возьмите DirectFB и SVGAlib, сделайте свою частную программу под них и не используйте Х там, где она не пашет. Кстати, в осциллографе linux вообще использовать не стоит, т.к. не ОС реального времени. А уж Х - тем более.
> Если пользоваться изначальными примитивами Х, в которых нет alpha-канала (его надо было по-человечески добавить в 1996-м году), не тормозит ничего.Посмотрите на окно браузера в котором вы пишете и попытайтесь мысленно отрисовать его изначальными примитивами Х, в которых нет alpha-канала. Удачи.
> Посмотрите на окно браузера в котором вы пишете и попытайтесь мысленно отрисовать
> его изначальными примитивами Х, в которых нет alpha-канала. Удачи.Дык я же и написал, что надо было добавить alpha-канал в 96-м году, дорогой quux. А не вставлять XRender, тогда бы не тормозило. Кстати, расширения Х, вставляющие alpha-канал были, но по какой-то причине не включены в X.org.
Альфа-канал тут вообще не при чем.
Проблема в том что для отрисовки приложения понадобится столько примитивов, что быстрее будет отрендерить все в пиксмап на стороне клиента и отдать этот пиксмап иксам. К чему собственно тулкиты и пришли.
> Альфа-канал тут вообще не при чем.При том, что XRender внесли для поддержки прозрачности.
> Проблема в том что для отрисовки приложения понадобится столько примитивов, что быстрее
> будет отрендерить все в пиксмап на стороне клиента и отдать этот
> пиксмап иксам. К чему собственно тулкиты и пришли.Ну так надо XRender (у которого примитивы - трапеции) выкинуть и сделать примитивы ближе к примитивам тулкитов. Посмотри не картинку в статье http://habrahabr.ru/post/148954/ где показано, на сколько трапеций бьётся элементарный бублик.
> в осциллографе linux вообще использовать не стоит, т.к. не ОС реального времениMainline ядро, если быть точным. А так, всё же, есть Monta Vista, Wind River и пару проектов попроще.
> А уж Х - тем более.
Имхо, если зачем-то захотелось Х в embedded, то это не очень embedded :)
> что быстрый вывод графики на экран — это не опция. Не
> расширение. И не костыль. Это обязано быть дефолтным состоянием вещей. В
> каждой первой программе. Без каких либо оговорок и условий.с ужасом думаю о том, как же плохо живётся миднайту без Офигенно Быстрой Графики. а gcc — так вообще просто загибается без неё!
> Лучше бы X12 пилили.Запиливайте, я разрешаю.
Пусть сначала безопасное извлечение USB носителей починят. Ни в одном современном (OpenSuse 12.3, Ubuntu 12.10 и 13.04, Fedora 18) дистрибутиве с гномом не останавливается шпиндель USB-HDD и не гасится питание USB-flash (https://launchpad.net/bugs/1067876). Тоже видите эту ошибку - плюсуйте!А то столько новых и новых планов, уже всё что можно было сломать практически сломали, инноваторы! Наутилус стал простой как для дебилов но с быстрым поиском...
> Наутилус стал простой как для дебилов но с быстрым поиском...Да там сейчас весь гном такой стал. Я и раньше слышал, что пункт меню "Log Out" выпилили, но увидеть это лично… это шок :)
А log in пока оставили или в планах тож выпиливать? :)
> А log in пока оставили или в планах тож выпиливать? :)Думаю, однажды их посетит мысль, что многопользовательских планшетов всё равно не бывает, так что можно обойтись автологином. Сразу рутом, дабы не множить сущности.
> Думаю, однажды их посетит мысль, что многопользовательских планшетов всё равно не бывает,Бывают, бывают. Это даже до гугли дошло...
Если я всё правильно понимаю, то пункт "Log Out" появляется только если в системе больше одного пользователя. В остальных случаях достаточно простой блокировки экрана (Alt+Ctrl+L).
> Если я всё правильно понимаю, то пункт "Log Out" появляется только если
> в системе больше одного пользователя. В остальных случаях достаточно простой блокировки
> экрана (Alt+Ctrl+L).Оригинальненькая логика. Видимо, варианты с необходимостью релогина после изменения членства в группах и/или переменных пользовательской сессии эти мудрые люди не рассматривают. Ну а чё, всегда можно перезагрузиться же, блин.
Видимо считается, что те, кто будет заниматься такими вещами, и так смогут гном перезапустить. Да и еще вопрос, а надо ли вообще делать релог в таких случаях в гноме?..
> Видимо считается, что те, кто будет заниматься такими вещами, и так смогут
> гном перезапустить.Ну, я перезапускал методом Ctrl+Alt+BackSpace. Может, есть менее топорный способ, но искать нужный метод DBus мне как бы недосуг, а перезапуск только шелла (Alt+F2, r, Return) нужного эффекта не даст :)
> Да и еще вопрос, а надо ли вообще делать
> релог в таких случаях в гноме?..Не представляю, как без этого. Если обновить переменные окружения теоретически можно, попросив об этом процесс, на котором держится сессия, после чего презапустить все приложения (и чем это отличается от релогина?), то с группами ситуация даже несколько хуже, поскольку процесс не может вступить в новую группу (или выйти из) без перезапуска самого себя, насколько мне известно.
>> Видимо считается, что те, кто будет заниматься такими вещами, и так смогут
>> гном перезапустить.
> Ну, я перезапускал методом Ctrl+Alt+BackSpace. Может, есть менее топорный способ, но искать
> нужный метод DBus мне как бы недосуг, а перезапуск только шелла
> (Alt+F2, r, Return) нужного эффекта не даст :)Люди пишут, что шорткат для Log Out - это якобы Ctrl+Alt+Del.
>> Да и еще вопрос, а надо ли вообще делать
>> релог в таких случаях в гноме?..
> Не представляю, как без этого. Если обновить переменные окружения теоретически можно, попросив
> об этом процесс, на котором держится сессия, после чего презапустить все
> приложения (и чем это отличается от релогина?), то с группами
> ситуация даже несколько хуже, поскольку процесс не может вступить в новую
> группу (или выйти из) без перезапуска самого себя, насколько мне известно.Тут спорить не буду. Как-то не задавался этим вопросом.
> пункт меню "Log Out" выпилили, но увидеть это лично…"Gnome3 - как самолет: тошнит, а выйти некуда". // на манер известной шутки.
>launchpad.netТолько вот разработчики гнома обитают на bugzilla.gnome.org (но некоторые ещё и на bugzilla.redhat.com)
Все багтрекеры увязаны между собой (в RedHad адрес такой https://bugzilla.redhat.com/show_bug.cgi?id=919194). Гномеры пока молчат. Видать шум пока не поднялся.
В Gnome адрес такой https://bugzilla.gnome.org/show_bug.cgi?id=693946.
>Все багтрекеры увязаны между собойПосмотрел. Да, launchpad умеет вытягивать инфу с других багтрекеров, а вот у гномовцев просто оставлена ссылка.
>Гномеры пока молчат. Видать шум пока не поднялся.
Уже исправлено в gnome 3.8 :)
>>Все багтрекеры увязаны между собой
> Посмотрел. Да, launchpad умеет вытягивать инфу с других багтрекеров, а вот у
> гномовцев просто оставлена ссылка.
>>Гномеры пока молчат. Видать шум пока не поднялся.
> Уже исправлено в gnome 3.8 :)А ссылка есть, что исправлено? Gnome Disks они починили, это я видел.
В udisks добавили выключение:
http://cgit.freedesktop.org/udisks/commit/?id=81dcb6eeaeceb6...Что-то подшаманили в gvfs:
https://git.gnome.org/browse/gvfs/commit/monitor/udisks2/gvf...Дальше разбираться лень, извините
Ааааа. Это я видел!
> Уже исправлено в gnome 3.8 :)Глядишь эдак версий через 5 научат и DPI монитора выставлять более-менее юзерфрендельными методами. Ведь вернуть диалог с парой крыжиков в настройках системы, который уже был много лет назад - это же так сложно! Пусть лучше юзерье ломает глаза, ну конечно (всемирный заговор врачей-окулистов? :D). Или конфиги колупает (а зачем тогда эта гламурная дрянь с JS нужна?).
> Глядишь эдак версий через 5 научат и DPI монитора выставлять более-менее юзерфрендельными методами.А есть ли надежда на то, что они когда-нибудь научатся брать DPI из Х? :-)
> А есть ли надежда на то, что они когда-нибудь научатся брать DPI из Х? :-)Понятия не имею, меня это не интересует.
1) Я не считаю иксы единственно возможным для меня бэкэндом. Ну и гномеры судя по всему тоже. Более того - мне не нравятся иксы. Это слишком жирная и тормозная прослойка между рендеринг менеджером и программами.2) В любом случае в DE должен быть графический конфигуратор этого самого. Хотя-бы потому что в совеременных системах по умолчанию у иксов конфига вообще нет. Плагнплей и все такое. А что и насколько корректное вернет монитор по DDC - вот это большой вопрос. Тем паче что DDC есть не везде. У LCD-панели в небольшом устройстве прицепленной напрямую по параллельной RGB или LVDS шине DDC в общем от отсутствует как класс. Так что возможность задать это по любому должна быть. В DE, а не где-то там в иксах и конфигах.
> Понятия не имею, меня это не интересует.
> 1) Я не считаю иксы единственно возможным для меня бэкэндом. Ну и
> гномеры судя по всему тоже. Более того - мне не нравятся
> иксы. Это слишком жирная и тормозная прослойка между рендеринг менеджером и
> программами.Блин, вы бы подписывались, что-ли. Если вы - аноним с осциллографом (без стрелки :-), то вам лучше бы взять не Х, а что-то проще, типа DirectFB.
> 2) В любом случае в DE должен быть графический конфигуратор этого самого.
Ну да, желательно, но скорее не DPI, а коэффициент масштабирования интерфейса. Но по-умолчанию там должен быть DPI, выдаваемый Х, как наиболее разумный.
> Хотя-бы потому что в совеременных системах по умолчанию у иксов конфига
> вообще нет.Я пробовал - можно подправить, если Х некорректно определили. Писал уже об этом.
> Ну да, желательно, но скорее не DPI, а коэффициент масштабирования интерфейса.В e17 ровно так и сделано.
> Но по-умолчанию там должен быть DPI, выдаваемый Х, как наиболее разумный.
DE-то какое дело до DPI, если не мухлевать им масштабирование? Должен быть честный и точка.
>> Ну да, желательно, но скорее не DPI, а коэффициент масштабирования интерфейса.
> В e17 ровно так и сделано.В Е17 многое разумно сделано.
> Блин, вы бы подписывались, что-ли. Если вы - аноним с осциллографом (без
> стрелки :-), то вам лучше бы взять не Х, а что-то проще, типа DirectFB.Вы знаете, у меня нет планов превращать 8-ядерный компьютер с большим монитором в однозадачный "осциллограф" :). Нечто подобное логично смотрелось бы отдельной прожкой в отдельном окошке, где-то сбоку, до кучи. Желательно с нормальными контролами и прочая. Вы что, никогда подобный софт не видели?
Иксы будут тормозить рисовать мало-мальски крупную битмаповую картинку в состоянии по дефолту. С точки зрения написания программы меня не улыбает что я должен что-то там знать о иксах и как их изогнуть чтобы вывод через них перестал тормозить. Особенно если хочется хотя-бы какой-то портабельности программы, например.
В результате такая простая задачка по простому оказываетс не решается. Я или должен для получения нормальной скорости юзать нечто типа SDL, получив таки нечто типа "кроссплатформенного фреймбуфера" (писать заведомо непортабельные программы без веской причины - нехорошо!). Но тогда я окажусь без нативных виджетов из тулкитов и их теминга. Или я могу юзать графический тулкит, но без расстановки кастомных костылей лично иксам - оно на *никсах будет волшебно тормозить. А ставить костыли конкретно иксам - это дополнительная работа и к тому же не портабельно. Программа получится коллекцией костылей. Ну, в тулкитах конечно есть поползновения все больше и больше добра перетянуть на OpenGL, он кроссплатформенный и не тормозит сразу, "по умолчанию". Но для столь простой задачки это пальба из базуки по мухам.
>> 2) В любом случае в DE должен быть графический конфигуратор этого самого.
> Ну да, желательно, но скорее не DPI, а коэффициент масштабирования интерфейса.Так DPI по сути и является этим коэффициентом. Как по мне - проще всего крутить именно его, особенно если совпадение с точностью до микронов картинки на мониторе с реальными физическими размерами не волнует. А учитывая что матрицы мониторов пекут без особой оглядки на такие вещи (вплоть до не совсем квадратных пикселей, например, с разным соотношением сторон) - оно чаще всего как раз так и есть.
> Но по-умолчанию там должен быть DPI, выдаваемый Х, как наиболее разумный.
Если уж вы про фреймбуферы и вга вспоминаете - я вас огрею вашим же оружием. Вот есть железка. У нее туповатый фреймбуфероподобный видеоконтроллер. Он рисует по принципу "какую битмапу положили в мою память, такую я и вываливаю на экран". К нему по тупой RGB или LVDS шине цепляется не менее тупая RGB панель. Контроллер формирует ей тайминги для каждого кадра. Панель рисует. О том какой там DPI контроллер вообще понятия может не иметь. К нему вообще разные панели подключать можно. Контроллер интересует только число пикселей, не более.
Вопрос на засыпку: откуда при этом X или кто либо еще вообще DPI узнает? А поскольку DE все-таки должен работать в разных конфигурациях - он вообще не должен уповать на то что ему иксы что-то там вернут. Может быть. Если они вообще есть. И если это значение имеет какой-то смысл, а не просто какой-то левый дефолт с потолка. А вот когда у вас в DE контролы и текст такие что их с лупой смотреть надо и не дали удобную рукоятку для оверрайда, так что десятый кегль смахивает на седьмой - вот это уже печальненько получается.
>> Хотя-бы потому что в совеременных системах по умолчанию у иксов конфига вообще нет.
> Я пробовал - можно подправить, если Х некорректно определили. Писал уже об этом.Можно. Но мне кажется что если некто вкорячивает в систему здоровый переросток с немеряными браузерными движками, JS и прочая - наверное будет логично, если вся эта переросточная хренота с рюшечками и бантиками будет позволять сделать указанную операцию. Иначе на кой хрен она место на винте занимает, если юзеру надо вручную какие-то конфиги колупать?
а ты бы, всё-таки, на DirectFB посмотрел — прежде чем про «однозадачность» вещать.
> Вы знаете, у меня нет планов превращать 8-ядерный компьютер с большим монитором
> в однозадачный "осциллограф" :). Нечто подобное логично смотрелось бы отдельной прожкой
> в отдельном окошке, где-то сбоку, до кучи. Желательно с нормальными контролами
> и прочая. Вы что, никогда подобный софт не видели?В многозадачной не realtime среде этого не выйдет. Х, как и другая оконная система, не realtime. Поэтому либо эпизодические лаги, либо берёте DirectFB.
> С точки зрения написания программы меня не улыбает что я должен
> что-то там знать о иксах и как их изогнуть чтобы вывод
> через них перестал тормозить. Особенно если хочется хотя-бы какой-то портабельности программы,
> например.А гвозди вы тоже всё время забиваете микроскопом? И усиленно ищете наиболее твёрдое место на этом микроскопе?
> В результате такая простая задачка по простому оказываетс не решается.
Она не простая, она требует realtime OS и realtime графику. То, что вы пытаетесь скрестить ужа с ежом и получаете 3 метра ржавой колючей проволоки - ваши проблемы.
> Или я могу юзать графический
> тулкит, но без расстановки кастомных костылей лично иксам - оно на
> *никсах будет волшебно тормозить.Ваш осциллограф ВЕЗДЕ, и в Windows, и в MacOSX, и в XWS будет волшебно работать через жопу. Потому, что эти системы не рассчитаны на вывод realtime графики. То, что они более-менее работают - в некотором смысле чудо.
> Так DPI по сути и является этим коэффициентом.
Он не является коэффициентом. Вы прикладываете распечатанный лист бумаги к монитору с 150 Dpi и видите, что pdf'ник нарисован точно также. Такая концепция есть - WYSIWYG, для неё правильный DPI жизненно необходим. А масштабировать для комфортного чтения можно отдельно, как в Acroread - 300%, 200%, в зависимости от того, насколько далеко вы отодвинули монитор.
> Как по мне -
Поздравляю. Но большинству народа нужен честный WYSIWYG с возможностью масштабирования.
>> Но по-умолчанию там должен быть DPI, выдаваемый Х, как наиболее разумный.
> Если уж вы про фреймбуферы и вга вспоминаете - я вас огрею
> вашим же оружием. Вот есть железка. У нее туповатый фреймбуфероподобный видеоконтроллер.И на ней работает Gnome? Крутые они ребята, эти Гномовцы.
>>> 2) В любом случае в DE должен быть графический конфигуратор этого самого.
>> Ну да, желательно, но скорее не DPI, а коэффициент масштабирования интерфейса.
> Так DPI по сути и является этим коэффициентом.Ни разу, это метрика разрешения (dots per inch).
> Как по мне - проще всего крутить именно его
Проще, чем регулерятор с 0.8X--1X--1.5X?
> особенно если совпадение с точностью до микронов картинки на мониторе с реальными
> физическими размерами не волнует.Так если угробить данные по реальному DPI, то речь уже не о микронах -- вообще о совпадении не идёт.
> А учитывая что матрицы мониторов пекут без особой оглядки на такие вещи
> (вплоть до не совсем квадратных пикселей, например, с разным соотношением сторон)
> - оно чаще всего как раз так и есть.У меня обычно приличные и 1:1, но вообще-то в X есть DPI отдельно по каждой стороне.
> Вопрос на засыпку: откуда при этом X или кто либо еще вообще DPI узнает?
grep EDID /var/log/Xorg.*.log
Как же ты надоел в со своим dpi. Что у тебя там за экраны такие или речь о диоптриях в твоих очках?Вместо того, чтобы предоставлять глупые "крыжики", которые не на всем срабатывают. Решаются другие проблемы в этой связи: https://live.gnome.org/GTK+/RI
А вообще с учетом базового перехода на wayland через год часть проблем решится, затем после обильного тестирования RI-патчей они войдут в gtk, но только после естественной (или насильственной) смерти gtk-2 можно будет заикаться о том, что gnome-shell как новый композитор держит в своих руках режимы монитора и dpi рендеринга.
Но ты же тролль, и еще и упоротый. Тебе не нужно это понимать, тебе "крыжик" не дали, вот и ноешь как девочка в каждой теме про gnome 3.
> Как же ты надоел в со своим dpi. Что у тебя там
> за экраны такие или речь о диоптриях в твоих очках?Dpi в современных ноутах прыгает от 80-ти до 220-ти, Тузя.
> Dpi в современных ноутах прыгает от 80-ти до 220-ти, Тузя.Я к тому, что цель: http://en.wikipedia.org/wiki/Resolution_independence
А не в ручной замене dpi.
> Я к тому, что цель: http://en.wikipedia.org/wiki/Resolution_independence
> А не в ручной замене dpi.Увы, пока разрешение низкое - не дотягивает хотя бы до 150 dpi, приходится жить на ручной тяге - всевозможных antialiasing, hinting и тому подобных страшных словах.
> Dpi в современных ноутах прыгает от 80-ти до 220-ти, Тузя.Он не только там прыгает. И что еще веселее - иксов может и не быть. А даже если они и есть, никто не гарантирует что они вернут в качестве DPI именно реальное физическое свойство экрана, а не какой-то сферический дефолт в вакууме.
> никто не гарантирует что они вернут в качестве DPI именно реальное физическое свойство
> экрана, а не какой-то сферический дефолт в вакууме.Если определят что-то неправильно, то можно подправить в xorg.conf, секция Display (только не надо говорить, что xorg.conf отсутствует - его можно создать самостоятельно, и он подцепится). Я это уже раз 10-й пишу.
Есть мнение, что Марк "припугнул народ Миром" дабы ускорить процесс развития Вяленого :)
а то народ думал "поддерживать / не поддерживать",
а сейчас все СРАЗУ взяли и поддержали Вяленого на фоне померещившегося на горизонте Мира.
поживем увидем, с "Юнити " он не шутил
может это на него так Челябенский астероид повлиял
Или выкатил Mir, чтобы потом одним ударом снести бошки трём кроликам: вялому, кде и гному. Ну зачем Unity эти конкуренты?
>но и в этой области наблюдается прогресс - компания Canonical пытается договориться с AMD и NVIDIA о реализации для проекта Mir нового интерфейса на базе EGL, который может быть задействован и в Wayland.мое мнение, Марк понял что все ложили на его мир и надо медленно втеснятся, сначала Mir + совместимость с Wayland, а потом будет настоящий Mir.
ну это мое IMHO> Ну зачем Unity эти конкуренты?
это СПО, в данном случае, как космонавт сказал, так и делать будут
> а сейчас все СРАЗУ взяли и поддержали Вяленогоне все. я не поддерживал, не поддерживаю и не собираюсь, например. ни вяленого, ни мир.
> не все. я не поддерживал, не поддерживаю и не собираюсь, например. ни
> вяленого, ни мир.Учитывая что ты как-то и не релизишь с помпой свои программы - это всем кроме тебя глубоко похрену. Ну, если у меня нет твоих программ - я и остаться без них не смогу, при всем желании. В этом месте Кэп сам себя поймал в забавную логическую ловушку :)
ни разу не поймал. а вот корреспондента на передёргивании — ещё как.
Разработчики Мира конечно шуму наделали, но и без этого GNOME и Wayland два сапога пара - оба на чистых сях и гордятся этим ("так быстрее"). Просто они чуть быстрее озвучили уже принятое задолго до Мира решение.
Это да, тошно смотреть на этот закат солнца вручную. Ну взяли бы плюсы как "C с классами", оно бы хоть читабельно было.
> плюсы как "C с классами", оно бы хоть читабельно было.Спасибо, видел я плюсатый код в таких вещах. Не, фиг вам, на си системные штуки лучше получаются. Плюсы там вообще ужас наводят.
Марк - молодчина! Одним набросом разбудил столько спящих мух.
По сути все будет решать NVIDIA. Чью поддержку они в свой блоб впаяют, тот и победит. Потому как без нее все эти поделки к практическому использованию непригодны.
> Проблему составляют проприетартные драйверы AMD и NVIDIA, с которыми не может работать Wayland, но и в этой области наблюдается прогресс - компания Canonical договорилась с AMD и NVIDIA о реализации для проекта Mir нового интерфейса на базе EGL, который может быть задействован и в Wayland.Вот ведь, всем будет польза.
> Примечательно, что анонс проекта Mir и вспыхнувшие вокруг него обсуждения заметно форсировали развитие Wayland и подтолкнули разработчиков различных открытых проектов к его поддержке.Уж если за вяленого взялись гномовцы...
Ждем дистров с гномом в качестве зависимостей при установке Wayland.
А чё, нормальный такой маркетоидный ход.
> Уж если за вяленого взялись гномовцы...Что, ему тоже порежут функциональность?
> Что, ему тоже порежут функциональность?Как раз "добавят" за счет гномолибов и гномошела, тем более, что всем заправляет RedHat.
Все дело идет вполне справедливо к тому что gtk закопают вместе с гномом, а марк будет в белом и чистом с qt и миром
> Все дело идет вполне справедливо к тому что gtk закoпают вместе с
> гномом, а марк будет в белом и чистом с qt и миромМарк сказочно затроллил целую толпу народа, которые теперь бросятся вкалывать как черти. И Марк неизбежно долетит куда хотел. На своей ракете, или на чужой, в общем какую быстрее и лучше соберут - на той и полетит. Беспроигрышный вариант! :)
> Марк сказочно затроллил целую толпу народа, которые теперь бросятся вкалывать как черти.
> И Марк неизбежно долетит куда хотел. На своей ракете, или на
> чужой, в общем какую быстрее и лучше соберут - на той
> и полетит. Беспроигрышный вариант! :)Может и так :-) Но с нвидией он бы не стал договариваться на понтах, и юнити вообще то тоже некоторое подтверждение, что он таки будет делать мир
> Может и так :-) Но с нвидией он бы не стал договариваться на понтах,Вы знаете, а EGL кажется пригодится всем. Желающих заменить GLX на EGL нынче стало хоть отбавляй. Так что в стане "противников" Марка подобные инициативы в целом как правило приветствуются радостными воплями, а отнюдь не громкими чертыханиями.
> Марк сказочно затроллил целую толпу народа, которые теперь бросятся вкалывать как черти.Они могуть вкалывать сколько угодно, толку-то. Чтобы построить замену Х нужно ведь думать, а не яростно копать от забора до ужина.
> Они могуть вкалывать сколько угодно, толку-то. Чтобы построить замену Х нужно ведь
> думать, а не яростно копать от забора до ужина.Никто не собирается делать "замену иксов". Лично мне например нужна минимальная прослойка между рендеринг менеджером и апликухами. Чем шустрее и меньше мешающаяся под ногами - тем лучше.
> Лично мне например нужна минимальная прослойка
> между рендеринг менеджером и апликухами. Чем шустрее и меньше мешающаяся под
> ногами - тем лучше.Между рендеринг менеджером, как вы говорите, и аппликухами сейчас прослойки по-сути нет - всё рендерится в примитивы XRender'а на стороне аппликух. Примитивы это крайне неудачные, но ввели их текущие разработчики Х.org. Поэтому надежды на их снос нет.
> Между рендеринг менеджером, как вы говорите, и аппликухами сейчас прослойки по-сути нетА чего же это иксы тогда столько проца жрут при выводе графики программами, если они не прослойка? :)
> - всё рендерится в примитивы XRender'а на стороне аппликух.
Если бы все было только так и только так, у иксов не было бы повода грузить CPU в тех объемах в которых они это делают. Какие-то апликухи жрали бы проц, но при этом вывод графики "в системе вообще" не упирался бы в 1 ядро проца выжранное xorg'ом, ну и вообще, ресурсы жрала бы только сама прога и претензии были бы только к ней и/или используемым оной либам. Это было бы намного проще как раз.
ты сам нагуглишь адрес пакарда и говнописателей говнотулкитов, или помочь?у меня отчего-то иксы никуда не «упираются», кстати. таки поясни же, что я не так делаю.
>> Между рендеринг менеджером, как вы говорите, и аппликухами сейчас прослойки по-сути нет
> А чего же это иксы тогда столько проца жрут при выводе графики
> программами, если они не прослойка? :)Потому что эти сраные трапеции на стороне Х тоже, как не удивительно, нужно прорисовывать. Их, увы, нельзя засунуть в /dev/null.
> Лично мне например нужна минимальная прослойка
> между рендеринг менеджером и апликухами.Это, кстати, иллюзия. Минимальной прослойки хватит, только если у вас светлая мечта - жить под MS DOS. Для нормального десктопа нужен аналог Х.
Похоже Марк спецом свой эфимерный Mir придумал, что-бы разрабы вяленого зачесались=))
профит стопроцентный
> эфимерный MirКод на launchpad (https://launchpad.net/mir) выглядит настоящим. Неужто подделка? о_О
Открыл первый кликнувшийся http://bazaar.launchpad.net/~kdub/mir/hacking-android-readme...
Пыль в глаза. Взяли какой-то готовый код, наняли студентов сыграть свои роли,....,профит - вяленый готов =)
Кранты, особая опеннетная логикаШатлворт икнул.
Хор нефанатов: Очуметь! Вы видели Как он восхитительно и гениально построил тарнсатлантический подводный тоннель, руками своих конкуретов - международного концерна! Если бы он не чихнул - хрен бы там что сдвинулось ! Хвала великому!
Обычная текущая работа гномеров, спокойно доделали свои теущие дела, решили в план включить еще и вяленного. Я это читал месяц назад задолго до последних публичных визгов Шатлворта, в рассылке федоровцев, кто-то сказал мол неплохо бы в rawhide запилить gtk с опцией компиляции вяленого, многие поддержали, никаких сенсаций.
Вяленый уже второй год икает, только толку чуть.
То есть что бы ни происходило, в этом заслуга Марка. Что и требовалось доказать. Кстати, если бы не Марк, реки давно бы пересохли, но вот он вчера пообедал - и реки теперь пересыхать не будут ровно 22 года.Детсадовский прикол, если видишь что человек идет к двери - крикни в последний момент "Жучка, открыть дверь". Всем вокруг ясно что ты этим человеком командуешь - ведь он дверь таки открыл и вышел. Ведь Wayland "теперь, наконец таки" пилят!!1!!!!!
Позитивно!Случилось то, что и ожидалось. Появление конкурента (Mir) пнуло разрабов Wayland. Пошевелятся и будет позитивная система отображения графики.
PS было бы позитивно, если бы через сессию Waylanв можно было прокидывать USB-порты, локальные принтеры и звук.
Redhat = Gnome + Wayland
Canonical = Unity + QTИдёт раздел технологий между 2-мя компаниями, которые дрейфуют в сторону создания своих ОСей.
Дележка имущества
У кого больше ... денег, размер
> Идёт раздел технологий между 2-мя компаниями,... но не совсем понятно вот чего: редхат вообще с десктопов нифига не имеет. Они вообще не делают какой-то особый бизнес на именно десктопах. Ну и накукуй оно им?
Это не значит, что им этот сектор совсем не интересен. Вполне возможно, они хотят и на этом делать деньги.
Марк - это Лелуш ! Он гений ! Ну может кончит иначе. Объявит 1 Апреля, что все это было розыгрышем.