Представлен XWayland — Xorg-сервер, работающий поверх Wayland

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

Даже колорадские жуки не стремятся есть эти ягоды, а как их употребляют анонимусы?

К костылям же.

Так костыли примотаны скотчем к туловищу, толку туда ещё и крылья лепить. Тут скорее как у Сектора Газа:

Из-за леса, из-за гор,
Показал мужик топор.
Но не просто показал,
Его к @#$$ привязал.

Вбивал linux.org.ru в адресную строку браузера с надеждой, что сегодня я увижу на главной новость, которая покажет мне всю мощь, красоту и стройность Линукса. Новость после которой я волевым решением снесу оффтопик, даже с недопройдённой Алисой, и поставлю великую ОС себе на компьютер.

Пойду забьюсь под стол и тихо поплачу...

Вы жжоте. Я лично DeadSpace 2 явно не под W* прошёл. wine вполне прилично работает. Значит и Alice потянет.

Кстати, как гуру, поделитесь как вы судите о стройности GNU/Linux по данной новости? Тут есть чему поучиться.

>Оно работает? можно howto?

А чему там не работать? Надо скачать неофициальный stage3 (официальный протух и там не работает portage из-за смены EAPI) и с ним делать всё то же, что и с обычными стейджами. Но это, если собирать новую систему. Устанавливать uclibc в уже существующую я не пробовал, потому что надо будет собирать кросс-тулчейн для сборки нативного тулчейна для uclibc.

Но реально что-то работающее у меня не получилось, т.к. glib не собирается с uclibc. Есть патч, исправляющий это, но тогда не собирается dbus-glib. Поэтому интересно, собирается ли wayland с uclibc и не зависит ли он от этих glib'ов.

>Значит и Alice потянет.

Unreal Engine 3 и под оффтопиком не очень хорошо работает, так что у меня большие сомнения на этот счёт. Да и в любом случае - GFWL под Wine ещё не допилили, так что если не от Алисы, то от того же BlazBlue придётся отказаться. И от первого старкрафта тоже, если вспомнить про криво реализованный DirectDraw (причём не понятно где - то ли в Вайне, то ли в Винде).

как вы судите о стройности GNU/Linux по данной новости

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

Очень заинтересовало:

Если - ядро и окружение, то самым прямым образом.

Ну и конечно то что ОС состоит не только из ядра вы узнали на прошлой неделе, что с такой радостью нам это сообщаете?

Какое-то время людям надо будет запускать как-то свои ветхие GTK2 и Qt3 приложения. Как-то не много у них вариантов: или сабж юзать, или от Wayland отказаться, и оставаться с чистым X.Org

Wayland не нужен как прибитое костылями к линуксу уг.

>Ну и конечно то что ОС состоит не только из ядра вы узнали на прошлой неделе, что с такой радостью нам это сообщаете?

Я вам сообщаю? Где?

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

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

Графическое API венды - это такая штука уровня Xlib?

Зачем вы обманываете общественность? WinAPI каждую версию W* переделывают как бог черепаху, она родных не узнаёт. Всё сплошь deprecated.

под графическим апи винды я понимаю функции работающие с HWND (например CreateWindow), функции GDI32. Что там позволяет ваш Xlib я не в курсях.

> Что там позволяет ваш Xlib я не в курсях.

А, то есть ты просто некомпетентен... понятно.

>как обстоят дела на гномофронте насчёт поддержки wayland?

gtk3 поддерживает wayland. Нужно только компилить с нужным ключом.

1) WinAPI постоянно переделывают и там сейчас 100500 костылей для обратной совместимости

2) Внезапно - тулкиты уже переписали. что gtk3, что Qt уже работают под wayland. Видимо это было достаточно просто.

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

вот это годная новость а то я пропустил выход Алисы...

Вобще это радует. Недавно в Parted от всякой мути избавились теперь Wayland заменит X. Unix-way во всей красе ! Ну а прослойка будет подключаться только для работы со старыми приложениями. А новые, не gtk+3,qt4-шные так или иначе перепишутся(может даже в течение года после выхода W), так что ни о какой низкой скорости в повсдевности речи идти не может.

>Недостаток X-ёв не в том, что они устарели,

Начал за здравие,

а в том, что большая часть функционала не нужна и не используется на десктопе.

а кончил за упокой.

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

Xlib appeared around 1985, and is currently used in GUIs for many Unix-like operating systems.

под графическим апи винды я понимаю функции работающие с HWND (например CreateWindow), функции GDI32. Что там позволяет ваш Xlib я не в курсях.

http://en.wikipedia.org/wiki/Xlib#Example

>>Недостаток X-ёв не в том, что они устарели,

Начал за здравие,

написал

Xlib appeared around 1985

и поделил на ноль.

Вообще пинципы построения Х умиляют:

Добавляй новую функциональность только в том случае, если без неё >нельзя завершить какое-то реальное приложение.

ну это еще ладно - не мешай машине ехать

Если проблема не понята до конца, возможно, лучше не решать её вовсе.

тормозит ? давай подождем - скорей всего через пару лет само отсохнет.

> Смысл? Wayland делают оттого, что X-ы устарели и тормозят.

Чтобы обеспечить пользователю постепенный переход с X на Wayland. Никому не интересно сидеть под системой половиной работающих программ.

Когда Wayland выйдет на десктопы, то первое время приложений под него будет мало - пользователь будет работать в X-приложениях через X-server и прослойку. Дальше перенесут kwin, kdm, gdm и им подобные и автоматом куча приложений под KDE, gnome начнут работать под Wayland.

Неужели сия прокладка будет работать лучше (быстрее) оригинального Xorg?

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

> не собирается dbus-glib

А что если выпилить ненавистный dbus?

> скриншот

Бе, какое убожество..

Отличная новость. Теперь переход на вейленд не требует обязательнои кастрации

...XWayland — Xorg-сервер, работающий поверх Wayland

Ох, нагородил-то... Наверное, не «Xorg-сервер», а «X-сервер»? Ничего не перепутал?

Нет, всё правильно.

Апстрим: http://cgit.freedesktop.org/xorg/xserver/refs/tags. Там он называется xorg-server.

Если ты внимательно читал новость, то поймёшь, что это он же (xorg-server = xserver из xorg), но с некоторым набором изменений сверху.

Если бы это была независимая реализация — то назвал бы просто X-сервер. А так по заголовку новости сразу понятно, что это модифицированный X-сервер из состава Xorg.

>Надо скачать неофициальный stage3

Под ARM есть?

>>Добавляй новую функциональность только в том случае, если без неё >>нельзя завершить какое-то реальное приложение.

ну это еще ладно - не мешай машине ехать

Если проблема не понята до конца, возможно, лучше не решать её вовсе.

тормозит ? давай подождем - скорей всего через пару лет само отсохнет.

У тебя очень сильная аргументация и очень правильная интерпретация этих правил. Мне даже и комментировать тут нечего. Поэтому признаю свой провал — иксы старые, как говно мамонта, они тормозят и глючат. Скорее бы уже запилили Wayland.

Жалко что Х 12 так и не начали вовремя пилить.

Вы позволите вас цитировать? :)

>сия прокладка может работать медленнее - ее задача обеспечить бесшовный, по возможности, переход с X.

Windows-way: всем программам работающим на другой графической подсистеме мы организуем искусственные глюки чтобы пользователи и программисты ощутили мощь и полезность нашего костыля.

У тебя очень сильная аргументация и очень правильная интерпретация этих правил.

У тебя еще сильней - «я сказал».

Поэтому признаю свой провал — иксы старые, как говно мамонта

Мне честно говоря все равно - никаких одолжений не нужно :-)

What is wrong with X?

The problem with X is that... it's X. When you're an X server there's a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. For example, core fonts; this is the original font model that was how your got text on the screen for the many first years of X11. This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!) Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extension such as XRandR, XRender and COMPOSITE and to some extent phase out less useful extension. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to a optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if don't plan for it.

Можете дальше до опупения доказывать что все это модерн.

> The problem with X is that... it's X…

«Проблемы с автомобилем в том, что это … автомобиль. Чтобы называться автомобилем, необходимо реализовать чертову уйму всяких инженерных вещей, многие из которых нам не нужны. Например: запасное колесо и домкрат. Многие годы автомобили автомобили возят с собой запаску и домкрат. Конечно, автомобили не стоят на месте, к ним добавляют ремни безопасности, ксенон, модифицируют подвеску, даже удаляют неиспользуемые элементы, типа хвостовых плавников. Но мы не можем избавиться от запасного колеса, домкрата, знака аварийной остановки и огнетушителя, которые никогда не используются в повседневной эксплуатации автомобиля. С нашей новой Самобеглой Тележкой мы сможем сделать устаревшие принадлежности необязательными. Мы заменим их на велосипедный навес, осталось решить, какого цвета!»

>Мы заменим их на велосипедный навес, осталось решить, какого цвета!

В маил-листе Wayland время от времени тоже больные отмечаются - их там кроме FAQ отправляют почитать про отличия архитектур

http://wayland.freedesktop.org/architecture.html

> http://wayland.freedesktop.org/architecture.html

Это сверхупрощенная мурзилка, которая почти никак не отражает такие возможности иксов, как DRI или XVideo, например.

Кстати, wayland принципиально не может реализовать Xv, XvMC, XvBA или VDPAU. Нет в нем таких механизмов.

>Кстати, wayland принципиально не может реализовать Xv, XvMC, XvBA или VDPAU.

Чем принципиально отличается запись данных в видеобуфер в цветорзностном формате или как либо еще закодированных от данных в rgb ? Ты хоть раз имел с этим дело ? похоже нет.

Нет в нем таких механизмов.

Нет или ты не нашел/не знаешь ?

X-сервер, работающий поверх другой системы.... MacOS нынче явно в моде. И мне это не нравится.

>не может реализовать Xv, XvMC, XvBA или VDPAU.

Кстати я тебе больше скажу - когда у меня аналогичная задача была - передать данные напряму в YUV в пиксельный процессор, я не стал заморачиваться этой уетой с Xv а написал плагин для плеера, иначе бы мне пришлось писать Xv совместимый драйвер.

>не может реализовать Xv, XvMC, XvBA или VDPAU. Нет в нем таких механизмов.

И еще я тебе больше скажу - с Wayland мой плагин заработает без всяких переделок, достаточно передать выходной буфер в rgb композитору а не писать его в оверлей видеоконтроллера к тому же у меня использовался v4l2 драйвер а там можно переслать буфер через mem2mem.

>А что если выпилить ненавистный dbus?

От него bluez зависит, который предполагалось использовать.

>Под ARM есть?

Я брал под x86 отсюда: http://judepereira.com/blog/gentoo-linux-uclibc-stage3-2010-for-embedded/

Там под ARM нет. Может, есть где-то в другом месте, но нагуглились только за 2004 и 2005 год.

>Там под ARM нет. Может, есть где-то в другом месте, но нагуглились только за 2004 и 2005 год.

Все это собирается прекрасно с uclibc под ARM - glib и dbus-glib.
http://git.buildroot.net/buildroot/tree/package/dbus-glib
не знаю что с вашими гентами но на Ubuntu c кросскомпиляцией у меня никаких проблем :-)

>Все это собирается прекрасно с uclibc под ARM - glib и dbus-glib.

Странно. Я хотел собирать под x86, увидел, что glib замаскирован, прогуглил, нашёл, что он не собирается, нашёл патчи, чтобы собирался, но там же прочитал, что не собирается dbus-glib. Значит, погуглю ещё, вдруг что-то получится.

>Странно. Я хотел собирать под x86, увидел, что glib замаскирован,

Только что собрал под ARM но с eglibc, посмотрел - нет там никаких ограничений на uclibc так что должно собираться. Вообще мне не ясен смысл использования uclibc - по сравнению с eglibc разница в мегабайт но смотрите дальше - у вас вся остальная система будет минимум на порядок больше занимать, к тому же:

1 в uclibc нет нормальной поддержки NPTL
2 несмотря на размер работают они медленней
3 в uclibc ядро с -RT питчами не работает корректно
4 между разными версиями нет бинарной совместимости, или по крайней мере она не всегда гарантируется
5 Нет нормальной поддержки NLS

>В девичестве проект был известен под именем «hosted»

А сейчас проект типа уже того, не девочка?

А Wayland поверх Xorg ещё не придумали?

>>В девичестве проект был известен под именем «hosted»

А сейчас проект типа уже того, не девочка?

Ну, раз в девичестве была одна фамилия, а сейчас — другая, то получается, что замужем.

А замужем — обычно не девочка, да.

Логика.