Планы Red Hat на X.org и Wayland в RHEL 10

ЦГА был прекрасен!

Объясните как он защищает то.

Он не работает. Взломать нерабочую систему невозможно.

Вспоминая восход Alex Deucher… Не, так оно не работает в сообществе. Надо сначала год-другой поволонтёрить, принести косвенно миллионы прибыли, а потом, может быть, если повезёт, то и на зарплату возьмут.

Ещё можно вспомнить Rémi Denis-Courmont, которого после неимоверного вклада в vlc выпихнули из оплачиваемой должности в videolan. Ишь ты, чего вздумал, о правах своих на код заявить. Ну, хотя бы разрешили и дальше безвозмездно волонтёрить.

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

За фанатичную упертость и нежелание добавлять десктопные фичи с разработчиков вялого ответственности никто не снимает. Но каким боком это относится к отсутствию единого вялого композитора на замену иксам? Разрабы вялого под дулом автомата заставляли разрабов DE/WM плодить свои собственные композиторы? Что мешало разрабам кед и гнома собраться вместе и запилить единый композитор с нужными им десктопными расширениями, раз уж разрабы вялого отказались их стандартизировать?

Например разрабы кед же как-то осилили сделать свои собственные расширения Wayland протокола, навроде серверных декораций. Почему они сделали это только для KWin, а не договорились совместно работать с гномосеками? Эх, вот был бы сейчас единый вялый композитор вместо единой реализации иксов, пили бы баварское.

Но wlroots выкатили хрен знает когда, а разработчики вяленного на просьбу добавления десктопных фич сказали: «хрен вам а не фичи».

Первый публичный релиз wlroots 0.3 был в 2019 году. Что мешало разрабам кед и гнома выкинуть свои вялые велосипеды и перейти на wlroots еще четыре года назад?

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

Просто сам аргумент бредовый. «Где твой код». Мой опенсорсный код лежит на гитхабе, а коммерческий - понятно где =)

Прекрасен он был тем, что игры шли в цвете. В остальном - тот ещё отстой, например, русификация через прошивку ПЗУ.

не договорились совместно работать с гномосеками?

Гномосеки сами не захотели делать SSD в своём композиторе.
А протокол для декораций уже давно в wayland-protocols и не прибит к KDE.

А что с нативными портами?

Много ли разработчиков делают нативные порты в 2023 году при живом стимдеке и протоне? В последние годы мне таковые как-то не попадались в стиме. Все чисто под оффтопик и протон.

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

Предположу, что проблемы могут быть в основном со всяким старьем, вышедшим приблизительно в районе 2013-2015 года. Тогда был выход стима под онтопик и всплеск нативных портов, который позже сошел на нет. Вот тамошние игры вполне могут использовать самописные движки, творить всякую дичь напрямую через XLib/XCB и хреново работать через XWayland. Но подобное старье я давно уже прошел под иксами. Как оно сейчас работает под вялым - без понятия.

Как оно сейчас работает под вялым

Оно и не под вялым сейчас не работает. Ругается, например, на libpng12.so.0, или другие зависимости, которые протухли, устарели и заменены новыми проектами.

Что мешало разрабам кед и гнома выкинуть свои вялые велосипеды и перейти на wlroots еще четыре года назад?

А я скажу что: они не заинтересованы в унификации Linux-десктопа. Они заинтересованы в создании окружений, подобных «GNOME OS» и «KDE OS», вот что пишут они сами:

In Plasma we need Wayland support as we are hitting the limitations of X all the time. Wayland will simplify our architecture and allow us to composite the screen in the way we consider as most useful.

https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayland?

Поэтому стандартизировали какой-то общий минимальный протокол и дальше начали развиваться каждый в собственном направлении – GNOME в одну сторону с их странным нежеланием внедрять SSD и idle-протоколы, KDE – в другую.

А вот плохо это или хорошо – время покажет.

нежеланием внедрять SSD

Ну вообще они эту проблему сейчас героически решают с помощью libdecor-gtk и плагина к qt. Но насколько хорошо со стороны разработчиков я не знаю, но я проблем с декорациями в гноме не вижу.

idle-протоколы

idle-inhibit воткнули уже.

Вот-вот, тогда как под Wine всё чётко работает.

Джон Кармак в своё время правильно сказал. Забейте на Linux’овую нативщину, допиливайте лучше Wine. Именно этим путём и пошли VALVe.

Гномосеки сами не захотели делать SSD в своём композиторе.

Догадываюсь, то дальше unstable он и не вылезет никогда. Да и там он оказался ЕМНИП благодаря тому, что Дрю Девольт своим авторитетом его туда продавил (и свалил куда-то в свой астрал).

героически решают с помощью libdecor-gtk и плагина к qt. Но насколько хорошо со стороны разработчиков я не знаю

Конечно это будет вызывать раздражение у разработчиков прикладного ПО. Вместо того чтобы сразу получить ОЖИДАЕМУЮ функциональность, они вынуждены костылять на свою сторону декорации через всякие линковки к libdecor и прочему. Кому это понравится? Кому вообще понравится писать дополнительный код, если раньше просто работало? Отсюда все эти взрывы подобные этим: Эмулятор PCSX2 по умолчанию отключает поддержку Wayland

проблем с декорациями в гноме не вижу.

Вот они:

• https://baat.exlmoto.ru/~exl_lab/screens/GNOME3_wayland_mpv_fuckup.png
• https://baat.exlmoto.ru/~exl_lab/screens/G3_Gish_On_Wayland.png
• https://baat.exlmoto.ru/~exl_lab/screens/G3_Wayland_SDL2_Games.png

https://baat.exlmoto.ru/~exl_lab/screens/G3_Gish_On_Wayland.png

https://baat.exlmoto.ru/~exl_lab/screens/G3_Wayland_SDL2_Games.png

SDL2 умеет в libdecor, libdecor с какой-то версии умеет рендерить рамку окна с gtk декорацией. Остаются только редкие приложения (включая mpv).

Но эт кнш проблема гномеров, что подобные костыли в принципе нужны.

libdecor простой как валенок. Хрена-ли там взрываться-то я не очень понимаю.

Ругается, например, на libpng12.so.0, или другие зависимости, которые протухли, устарели и заменены новыми проектами.

Хм, но разве стим рантаймы не должны решать эту проблему? Например стим таскает с собой набор либ в каталоге ~/.local/share/Steam/ubuntu12_64, среди которых есть и libpng12.so.0. Кроме того, есть еще всякие Steam Linux Runtime - Soldier.

А я скажу что: они не заинтересованы в унификации Linux-десктопа.

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

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

А вот плохо это или хорошо – время покажет.

Думаю, для опенсорса это объективно и неизбежно. Таков путь.

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

libdecor простой как валенок. Хрена-ли там взрываться-то я не очень понимаю.

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

Глянул что у меня запущено после апгрейда Дебиана с 11 на 12 букворм. А там…

$ ps aux | grep -E 'pipe|pulse'
ss          4654  0.0  0.0  65980 24112 ?        S<sl Nov23   0:08 /usr/bin/pipewire
ss          4657  0.0  0.2 172600 141928 ?       S<sl Nov23   1:01 /usr/bin/pipewire-pulse
ss          4933  0.0  0.0 550024 49564 ?        Sl   Nov23   7:09 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libpulseaudio-plugin.so 8 16777230 pulseaudio PulseAudio Plugin Adjust the audio volume of the PulseAudio sound system
sena     1142988  0.0  0.0 280376 14176 ?        Ssl  Nov28   0:00 /usr/bin/pulseaudio --daemonize=no --log-target=journal

Не перебор ли это? И пульсаудио запущен и пайпеваря и ещё что-то среднее пипеваря-пульс. Может что-то уже можно снести?

Очевидно, потому что композитору вообще положить на заголовок. Mutter не вмешивается в рендеринг и ждёт, что клиент даст ему готовый битмап. Как и предполагает изначально wayland.

Проблема SSD ровно в том, что он идёт против логики протокола: композитор не вмешивается в работу клиента. Но в случае SSD композитору необходимо делать что-то ещё, помимо компоновки surface клиентов.

Вот по ссылке более-менее понятно написано что и как.

Разрабы вялого под дулом автомата заставляли разрабов DE/WM плодить свои собственные композиторы? Что мешало разрабам кед и гнома собраться вместе и запилить единый композитор с нужными им десктопными расширениями, раз уж разрабы вялого отказались их стандартизировать?

Разработчики GNOME? Договариваться? Ты серьезно сейчас? Эти чуваки сначала буквально дизайнили Wayland только для GNOME, а ты собрался с ними договариваться. Вот поэтому и пишут каждый свою реализацию хоть это и неблагодарное занятие.

Например разрабы кед же как-то осилили сделать свои собственные расширения Wayland протокола, навроде серверных декораций. Почему они сделали это только для KWin, а не договорились совместно работать с гномосеками?

Потому что разрабы GNOME/Wayland - мудаки. Нужно было не идти у них на поводу и не играть в эту игру, а просто остаться на иксах и всё. Пусть бы GNOME существовал в своей резервации, и фиг с ним.

Первый публичный релиз wlroots 0.3 был в 2019 году. Что мешало разрабам кед и гнома выкинуть свои вялые велосипеды и перейти на wlroots еще четыре года назад?

То есть они должны отказаться от реализации, которую так усердно писали, чтобы перейти на сомнительный wlroots, который пилится хрен знает кем?

Чота никакой прошивки не помню. На ес1840 один бинарник запускал и вторая часть таблицы в кириллицу превращалась.

STL - это вообще лютое позорище. Это хорошо видно, если программировать на Python или даже на Java 8 и выше. Строки - говно. Дата-классов нормальных нет, юзай char* как в сишке. ifstream/ofstream говно. Сокеты тоже не завезли. Qt как был неофициально стандартной библиотекой плюсов, так и остался. Может быть из плюсов полезные фичи - это умные указатели, да и всё.

И пульсаудио запущен и пайпеваря

Традиционная дебиановская свалка

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

Вот по ссылке более-менее понятно написано что и как.

Это всё понятно. Раз им запрещает религия архитектура – значит они должны были добавить линковку к своей libdecor на все крупные проекты: Qt, SDL2, Java (AWT/Swing, SWT, JavaFX), C# (Mono, .NET) и два браузера, а не ждать непонятно чего.

*Introducing the CSD Initiative

Как говорится – инициатива это самое инициатора.

Мне как пользователю/программисту что делать если мои приложения под Wayland рисуются без заголовка, либо же с корявым и убогим заголовоком?

Им недавно вон $1,000,000.00 задонатиили. Могли бы потратить их на подобное дело – наняли бы разработчиков, которые обеспечили бесшовную и адекватную работу это libdecor во всех популярных сегодня графических тулкитах. Но наверняка спустят эти средства на забористую наркоту и шлюх свои любимые LGBT-вечериники.

Wayland тоже половинчатое решение - графический сервер надо внедрить в systemd, вот тогда всё будет правильно, потому что графический интерфейс будет доступен с самого начала загрузки

Qt для гуя неплох, вот только бы ещё из него выкинуть проклятие Qt - зависимость от QString и от их самопальных контейнеров.

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

Чем плох QString и QStringView?

По сравнению с тем адком в строках что накрутили в STL это вполне себе годный и удобный класс.

Qt для гуя неплох, вот только бы ещё из него выкинуть проклятие Qt - зависимость от QString и от их самопальных контейнеров.

Так строки в Qt - это же самое вкусное и QByteArray тоже. Вот нужно тебе будет, скажем, разделить строки на подстроки по зяпятой. Для Qt - это простая операция. str.split(«,») и на выходе получаешь QStringList. А теперь догадайся как сделать тоже самое в STL. Никак, пиши самопал. Такой самопал практически для всего. Даже в СИ есть strtok. На него и приходится делать обёртку для плюсов. А контейнеры чем не устроили? QMap, QVector, QQueue - аналоги тем же контейнерам в STL.

Оно точно называется fisheye? Не могу чет найти.

Вроде в C++20 завезли такое: https://en.cppreference.com/w/cpp/ranges/split_view

#include <iomanip>
#include <iostream>
#include <ranges>
#include <string_view>
 
int main()
{
    using std::operator""sv;
    constexpr auto words{"Hello^_^C++^_^20^_^!"sv};
    constexpr auto delim{"^_^"sv};
 
    for (const auto word : std::views::split(words, delim))
        // with string_view's C++23 range constructor:
        std::cout << std::quoted(std::string_view(word)) << ' ';
    std::cout << '\n';

    // Output: "Hello" "C++" "20" "!"
}

Причем оно никаких массивов не выделяет.

ксоргкапец:roflanwtf:

Systemd допилен и отлично работает. Pulseaudio выкинут и заменен на отличный совместимый с ним Pipewire.

свои любимые LGBT-вечериники

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

STL конечно позорище, но Qt еще хуже, там приятно только делать leftPad для строки, но для этого лучше взять скриптовый язык программирования, а С++ это все же для другого, там готовые обобщенные сокеты и даром не нужны, ну только для утят которые других языков не знают. А то потом понапишут скриптов на С++...

Код с STL просто не читаем. Вот сравни с

int main() {
    const QString originalString = "hello,world,!";
    const QStringList strParts = originalString.split(",");

    for (const auto &str : strParts) {
        qDebug() << str;
    }
}

А ещё я поставил с++20 но всё равно ругается, что std::views нет в clang.

Да. На Qt много чего писал, версии Qt 2, Qt 4, Qt 5, Qt 6, трогал палочкой даже Qt 1 (в котором не было нормальной подедржки Unicode) и Qt 3.

Qt вносит хороший синтаксический сахар в C++ и крестами становится удобно пользоваться для RAD-разработки.

Но есть у этой стороны медали и обратная сторона – понижение уровня вхождения (learning curve) часто порождает программы с различным кривым проектированием по типу программной логики в обработчиках кнопок и т. д.

Looking Glass shows a fisheye lens magnifier.

Мне как пользователю/программисту что делать если мои приложения под Wayland рисуются без заголовка, либо же с корявым и убогим заголовоком?

Использовать тулкит и не выёживаться. GTK/Qt/SDL/EFL/что угодно решают эту проблему прозрачно для программиста.

Если ты автор MPV (образно) и выбрал страдать, то нефиг удивляться и истериковать, что приходится страдать и предусматривать работу без декораций. Проверяешь, есть-ли поддержка протокола -> есть - забивешь болт и пользуешься surface-ом -> нет - получаешь тотже surface с libdecor и работаешь там.

Использовать тулкит и не выёживаться. GTK/Qt/SDL/EFL/что угодно решают эту проблему прозрачно для программиста.

Я может быть это просто слишком рано пробовал. Но когда я пробовал – всё было очень печально. Окнами SDL управлять было нельзя, а Qt вообще глючил как не в себя:

• https://baat.exlmoto.ru/~exl_lab/screens/G3_Qt_Creator_Wayland.png
• https://baat.exlmoto.ru/~exl_lab/screens/G3_Qt_Creator_Glitches.png
• https://baat.exlmoto.ru/~exl_lab/screens/qt5_wayland_gnome3.png

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

Если ты автор реальной программы и выбрал страдать, то нефиг удивляться и истериковать, что приходится страдать, иное дело, если ты автор блокнота на GTK4

Исправил цитату до сути.

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

Согласись, что это уже какбы не проблема типа декораций. И да, согласен QT_QPA_PLATFORM=wayland изначально работало отвратительно. Сейчас, вроде, лучше.

В чём драма с Блокнотом, я пропустил.

И да, согласен QT_QPA_PLATFORM=wayland изначально работало отвратительно. Сейчас, вроде, лучше.

Вот это печалит: Fedora 39

Из неприятных моментов: QGnomePlatform и Adwaita-qt не поставляются по умолчанию из-за стагнации этих проектов. Теперь Qt-приложения в Gnome выглядят как приложения Qt без мимикрии под Gtk/Adwaita.

Сомневаюсь что разработчики Qt будут ковыряться с libadwaita, хотя… у The Qt Company в приоритете именно RHEL всегда был.

Выкинули саму тему, но не декорацию. Под иксами будет не лучше.