История изменений

Все основные разработчики иксов, которые были вовлечены в этот проект, перекатились на вяленд

Но это и есть самый очевидный конфликт интересов: когда разработчики текущего решения одновременно являются архитекторами конкурирующего подхода, их мотивация дропнуть X11 перестаёт быть объективной — она становится стратегической, идеологической и самоусиливающейся. Это как если бы разработчики VHS объявили, что Betamax «уже не нужен», потому что «поддерживать его трудно» — в момент, когда они одновременно разрабатывают VHS. Это не аргумент, это позиция. И к ней надо относиться критически, а не как к догме.

«Устали от костылей» — не технический довод, это эмоциональный аргумент, а не инженерный.

Здесь имеется в виду «накопился большой технический долг и оверхед на сопровождение»

Хорошо. Но тогда возникает встречный вопрос: а почему бы не начать с его погашения? Вместо того чтобы радикально отказаться от зрелой платформы с широчайшей совместимостью, можно было ограничиться реструктуризацией, перейти, например, на чисто XCB-based сервер или переосмыслить клиентский протокол, сохранив базовые свойства X11 как архитектуры: нейтральность, универсальность, toolkit-agnostic функциональность. То есть, сделать X12, Xng, X-Wayland-InsideOut, наконец.

Смотри: в случае с GDI в Windows тоже был «технический долг». Но никто не выкинул его на помойку, а сделали совместимость поверх GDI+, Direct2D, DWM. Microsoft вложилась в interop, а не в разрушение экосистемы. Именно поэтому в Windows до сих пор живы и WinForms, и MFC, и даже Win32/WinAPI — и все они работают.

Всем маленьким WM предлагается использовать wlroots

Да, но проблема в том, что wlroots не даёт ничего из коробки. Это — лишь концепция, стек протоколов низкоуровневой библиотекой, которую каждый WM должен интегрировать, дописывая обвязку вручную. В X11 ты мог сделать полноценный оконный менеджер, написав 500 строк C на Xlib. В wlroots ты получаешь API, с которым нужно реализовать чуть ли не собственный GDM, Mutter и KWin одновременно, если ты хочешь больше, чем «открывать окна».

А теперь представим себе класс проектов: AwesomeWM, FVWM, IceWM, etc. Это всё — небольшие, минималистичные, зрелые проекты, написанные силами 1-2 человек. Как они должны поддерживать бесконечно меняющийся API протоколов, описанных как «идея», а не «реализация»? В X11 таких проблем нет: ты либо compliant, либо нет. Протокол ясен, реализация — универсальна.

На практике сейчас нет единого, нейтрального GUI API под Wayland. В X11 любой тулкит, даже самописный, имел равный доступ к дисплейному серверу. Это и есть модель GDI+ в Windows: интерфейс для отрисовки, унифицированный для всех. Wayland, в отличие от X11, не предоставляет оконной модели вообще, а отсылает к «протоколам поверх протоколов» — причём часть из них приватные или DE-специфичные (xdg-shell, zwlr-layer-shell и прочие). Это не экосистема, это зоопарк стеков, где каждый вынужден реализовывать недостающие фрагменты архитектуры с нуля.

Я думаю, что к моменту, когда иксы решат закопать окончательно, все юзкейсы будут закрыты

А что если нет? Что если не закроют? Значит, у нас будет ситуация, когда софт — реальный, нужный — будет искусственно ограничиваться, деградировать в UX, или полностью выпадать из пользовательского опыта. Не потому что он плохой, а потому что «архитекторы решили» выкинуть API, которым он пользовался десятилетиями.

Но поддержку иксов еще не дропнули

См. Fedora, GNOME, KDE, — они все по умолчанию уже на Wayland. Поддержка X11 переехала в XWayland (уже не полноценный X-сервер, а подобие эмулятора, прослойки), причём отстаёт по поддержке инпутов, GPU, и имеет свой event loop. Это уже не «поддержка X11», это — режим совместимости с проблемами.

В итоге что происходит:

• Wayland — протокол;
• wlroots — базовая библиотека;
• Weston — референсная имплементация (которая не предназначена для реального использования);

А все остальные обязаны строить архитектуру на 10+ слоях API, которые либо не устоялись, либо не задокументированы. Это приводит к эффекту: все делают чуть-чуть своего, но никто не делает общего. Wayland не унифицирует стек, а его разрывает. В этом отличие от X11 и GDI.

Реальная альтернатива есть уже сейчас: развивать wine/proton-протоколы. Реализация GDI+ поверх Wine/DRM/DirectFB — возможный путь к новой GUI-архитектуре, без деградации по функциональности. Именно подобная реализация GDI+ может стать основой нового унифицированного протокола:

• она API-first, а не protocol-first;
• она стабильно работает с тысячами legacy-программ;
• её можно обвязать DRM/KMS и GPU acceleration;
• она имеет логическую совместимость с Win32 и .NET GUI-приложениями.

Wine и Proton на десктопе показывают, как можно развивать, не ломая. А Wayland на десктопе — как можно ломать, не развивая. Я не призываю закапывать Wayland. Он уже нашёл свою нишу. Его продолжат корпы развивать в нужном для себя ключе. Я лишь напоминаю, что сообщество снова совершает ошибку, полагаясь на заведомо слабое сиюминутное решение. Возможно, более критическую, чем в прошлый раз. Я буду рад, если всё пойдёт по оптимистическому сценарию, но выглядит это довольно печально. Скорее всего, Valve не будет развивать десктоп (о чём уже есть намёки с её стороны). Потому что её интересуют игры, игровые приставки, в целом несколько иные вещи. У неё свои корпоративные интересы.

Все основные разработчики иксов, которые были вовлечены в этот проект, перекатились на вяленд

Но это и есть самый очевидный конфликт интересов: когда разработчики текущего решения одновременно являются архитекторами конкурирующего подхода, их мотивация дропнуть X11 перестаёт быть объективной — она становится стратегической, идеологической и самоусиливающейся. Это как если бы разработчики VHS объявили, что Betamax «уже не нужен», потому что «поддерживать его трудно» — в момент, когда они одновременно разрабатывают VHS. Это не аргумент, это позиция. И к ней надо относиться критически, а не как к догме.

«Устали от костылей» — не технический довод, это эмоциональный аргумент, а не инженерный.

Здесь имеется в виду «накопился большой технический долг и оверхед на сопровождение»

Хорошо. Но тогда возникает встречный вопрос: а почему бы не начать с его погашения? Вместо того чтобы радикально отказаться от зрелой платформы с широчайшей совместимостью, можно было ограничиться реструктуризацией, перейти, например, на чисто XCB-based сервер или переосмыслить клиентский протокол, сохранив базовые свойства X11 как архитектуры: нейтральность, универсальность, toolkit-agnostic функциональность. То есть, сделать X12, Xng, X-Wayland-InsideOut, наконец.

Смотри: в случае с GDI в Windows тоже был «технический долг». Но никто не выкинул его на помойку, а сделали совместимость поверх GDI+, Direct2D, DWM. Microsoft вложилась в interop, а не в разрушение экосистемы. Именно поэтому в Windows до сих пор живы и WinForms, и MFC, и даже Win32/WinAPI — и все они работают.

Всем маленьким WM предлагается использовать wlroots

Да, но проблема в том, что wlroots не даёт ничего из коробки. Это — низкоуровневая библиотека, которую каждый WM должен интегрировать, дописывая обвязку вручную. В X11 ты мог сделать полноценный оконный менеджер, написав 500 строк C на Xlib. В wlroots ты получаешь API, с которым нужно реализовать чуть ли не собственный GDM, Mutter и KWin одновременно, если ты хочешь больше, чем «открывать окна».

А теперь представим себе класс проектов: AwesomeWM, FVWM, IceWM, etc. Это всё — небольшие, минималистичные, зрелые проекты, написанные силами 1-2 человек. Как они должны поддерживать бесконечно меняющийся API протоколов, описанных как «идея», а не «реализация»? В X11 таких проблем нет: ты либо compliant, либо нет. Протокол ясен, реализация — универсальна.

На практике сейчас нет единого, нейтрального GUI API под Wayland. В X11 любой тулкит, даже самописный, имел равный доступ к дисплейному серверу. Это и есть модель GDI+ в Windows: интерфейс для отрисовки, унифицированный для всех. Wayland, в отличие от X11, не предоставляет оконной модели вообще, а отсылает к «протоколам поверх протоколов» — причём часть из них приватные или DE-специфичные (xdg-shell, zwlr-layer-shell и прочие). Это не экосистема, это зоопарк стеков, где каждый вынужден реализовывать недостающие фрагменты архитектуры с нуля.

Я думаю, что к моменту, когда иксы решат закопать окончательно, все юзкейсы будут закрыты

А что если нет? Что если не закроют? Значит, у нас будет ситуация, когда софт — реальный, нужный — будет искусственно ограничиваться, деградировать в UX, или полностью выпадать из пользовательского опыта. Не потому что он плохой, а потому что «архитекторы решили» выкинуть API, которым он пользовался десятилетиями.

Но поддержку иксов еще не дропнули

См. Fedora, GNOME, KDE, — они все по умолчанию уже на Wayland. Поддержка X11 переехала в XWayland (уже не полноценный X-сервер, а подобие эмулятора, прослойки), причём отстаёт по поддержке инпутов, GPU, и имеет свой event loop. Это уже не «поддержка X11», это — режим совместимости с проблемами.

В итоге что происходит:

• Wayland — протокол;
• wlroots — базовая библиотека;
• Weston — референсная имплементация (которая не предназначена для реального использования);

А все остальные обязаны строить архитектуру на 10+ слоях API, которые либо не устоялись, либо не задокументированы. Это приводит к эффекту: все делают чуть-чуть своего, но никто не делает общего. Wayland не унифицирует стек, а его разрывает. В этом отличие от X11 и GDI.

Реальная альтернатива есть уже сейчас: развивать wine/proton-протоколы. Реализация GDI+ поверх Wine/DRM/DirectFB — возможный путь к новой GUI-архитектуре, без деградации по функциональности. Именно подобная реализация GDI+ может стать основой нового унифицированного протокола:

• она API-first, а не protocol-first;
• она стабильно работает с тысячами legacy-программ;
• её можно обвязать DRM/KMS и GPU acceleration;
• она имеет логическую совместимость с Win32 и .NET GUI-приложениями.

Wine и Proton на десктопе показывают, как можно развивать, не ломая. А Wayland на десктопе — как можно ломать, не развивая. Я не призываю закапывать Wayland. Он уже нашёл свою нишу. Его продолжат корпы развивать в нужном для себя ключе. Я лишь напоминаю, что сообщество снова совершает ошибку, полагаясь на заведомо слабое сиюминутное решение. Возможно, более критическую, чем в прошлый раз. Я буду рад, если всё пойдёт по оптимистическому сценарию, но выглядит это довольно печально. Скорее всего, Valve не будет развивать десктоп (о чём уже есть намёки с её стороны). Потому что её интересуют игры, игровые приставки, в целом несколько иные вещи. У неё свои корпоративные интересы.

Все основные разработчики иксов, которые были вовлечены в этот проект, перекатились на вяленд

Но это и есть самый очевидный конфликт интересов: когда разработчики текущего решения одновременно являются архитекторами конкурирующего подхода, их мотивация дропнуть X11 перестаёт быть объективной — она становится стратегической, идеологической и самоусиливающейся. Это как если бы разработчики VHS объявили, что Betamax «уже не нужен», потому что «поддерживать его трудно» — в момент, когда они одновременно разрабатывают VHS. Это не аргумент, это позиция. И к ней надо относиться критически, а не как к догме.

«Устали от костылей» — не технический довод, это эмоциональный аргумент, а не инженерный.

Здесь имеется в виду «накопился большой технический долг и оверхед на сопровождение»

Хорошо. Но тогда возникает встречный вопрос: а почему бы не начать с его погашения? Вместо того чтобы радикально отказаться от зрелой платформы с широчайшей совместимостью, можно было ограничиться реструктуризацией, перейти, например, на чисто XCB-based сервер или переосмыслить клиентский протокол, сохранив базовые свойства X11 как архитектуры: нейтральность, универсальность, toolkit-agnostic функциональность. То есть, сделать X12, Xng, X-Wayland-InsideOut, наконец.

Смотри: в случае с GDI и GDI+ в Windows тоже был «технический долг». Но никто не выкинул его на помойку, а сделали совместимость поверх Direct2D, DWM и UWP. Microsoft вложилась в interop, а не в разрушение экосистемы. Именно поэтому в Windows до сих пор живы и WinForms, и MFC, и даже Win32 — и все они работают.

Всем маленьким WM предлагается использовать wlroots

Да, но проблема в том, что wlroots не даёт ничего из коробки. Это — низкоуровневая библиотека, которую каждый WM должен интегрировать, дописывая обвязку вручную. В X11 ты мог сделать полноценный оконный менеджер, написав 500 строк C на Xlib. В wlroots ты получаешь API, с которым нужно реализовать чуть ли не собственный GDM, Mutter и KWin одновременно, если ты хочешь больше, чем «открывать окна».

А теперь представим себе класс проектов: AwesomeWM, FVWM, IceWM, etc. Это всё — небольшие, минималистичные, зрелые проекты, написанные силами 1-2 человек. Как они должны поддерживать бесконечно меняющийся API протоколов, описанных как «идея», а не «реализация»? В X11 таких проблем нет: ты либо compliant, либо нет. Протокол ясен, реализация — универсальна.

На практике сейчас нет единого, нейтрального GUI API под Wayland. В X11 любой тулкит, даже самописный, имел равный доступ к дисплейному серверу. Это и есть модель GDI+ в Windows: интерфейс для отрисовки, унифицированный для всех. Wayland, в отличие от X11, не предоставляет оконной модели вообще, а отсылает к «протоколам поверх протоколов» — причём часть из них приватные или DE-специфичные (xdg-shell, zwlr-layer-shell и прочие). Это не экосистема, это зоопарк стеков, где каждый вынужден реализовывать недостающие фрагменты архитектуры с нуля.

Я думаю, что к моменту, когда иксы решат закопать окончательно, все юзкейсы будут закрыты

А что если нет? Что если не закроют? Значит, у нас будет ситуация, когда софт — реальный, нужный — будет искусственно ограничиваться, деградировать в UX, или полностью выпадать из пользовательского опыта. Не потому что он плохой, а потому что «архитекторы решили» выкинуть API, которым он пользовался десятилетиями.

Но поддержку иксов еще не дропнули

См. Fedora, GNOME, KDE, — они все по умолчанию уже на Wayland. Поддержка X11 переехала в XWayland (уже не полноценный X-сервер, а подобие эмулятора, прослойки), причём отстаёт по поддержке инпутов, GPU, и имеет свой event loop. Это уже не «поддержка X11», это — режим совместимости с проблемами.

В итоге что происходит:

• Wayland — протокол;
• wlroots — базовая библиотека;
• Weston — референсная имплементация (которая не предназначена для реального использования);

А все остальные обязаны строить архитектуру на 10+ слоях API, которые либо не устоялись, либо не задокументированы. Это приводит к эффекту: все делают чуть-чуть своего, но никто не делает общего. Wayland не унифицирует стек, а его разрывает. В этом отличие от X11 и GDI.

Реальная альтернатива есть уже сейчас: развивать wine/proton-протоколы. Реализация GDI+ поверх Wine/DRM/DirectFB — возможный путь к новой GUI-архитектуре, без деградации по функциональности. Именно подобная реализация GDI+ может стать основой нового унифицированного протокола:

• она API-first, а не protocol-first;
• она стабильно работает с тысячами legacy-программ;
• её можно обвязать DRM/KMS и GPU acceleration;
• она имеет логическую совместимость с Win32 и .NET GUI-приложениями.

Wine и Proton на десктопе показывают, как можно развивать, не ломая. А Wayland на десктопе — как можно ломать, не развивая. Я не призываю закапывать Wayland. Он уже нашёл свою нишу. Его продолжат корпы развивать в нужном для себя ключе. Я лишь напоминаю, что сообщество снова совершает ошибку, полагаясь на заведомо слабое сиюминутное решение. Возможно, более критическую, чем в прошлый раз. Я буду рад, если всё пойдёт по оптимистическому сценарию, но выглядит это довольно печально. Скорее всего, Valve не будет развивать десктоп (о чём уже есть намёки с её стороны). Потому что её интересуют игры, игровые приставки, в целом несколько иные вещи. У неё свои корпоративные интересы.

Все основные разработчики иксов, которые были вовлечены в этот проект, перекатились на вяленд

Но это и есть самый очевидный конфликт интересов: когда разработчики текущего решения одновременно являются архитекторами конкурирующего подхода, их мотивация дропнуть X11 перестаёт быть объективной — она становится стратегической, идеологической и самоусиливающейся. Это как если бы разработчики VHS объявили, что Betamax ««уже не нужен», потому что «поддерживать его трудно» — в момент, когда они одновременно разрабатывают VHS. Это не аргумент, это позиция. И к ней надо относиться критически, а не как к догме.

«Устали от костылей» — не технический довод, это эмоциональный аргумент, а не инженерный.

Здесь имеется в виду «накопился большой технический долг и оверхед на сопровождение»

Хорошо. Но тогда возникает встречный вопрос: а почему бы не начать с его погашения? Вместо того чтобы радикально отказаться от зрелой платформы с широчайшей совместимостью, можно было ограничиться реструктуризацией, перейти, например, на чисто XCB-based сервер или переосмыслить клиентский протокол, сохранив базовые свойства X11 как архитектуры: нейтральность, универсальность, toolkit-agnostic функциональность. То есть, сделать X12, Xng, X-Wayland-InsideOut, наконец.

Смотри: в случае с GDI и GDI+ в Windows тоже был «технический долг». Но никто не выкинул его на помойку, а сделали совместимость поверх Direct2D, DWM и UWP. Microsoft вложилась в interop, а не в разрушение экосистемы. Именно поэтому в Windows до сих пор живы и WinForms, и MFC, и даже Win32 — и все они работают.

Всем маленьким WM предлагается использовать wlroots

Да, но проблема в том, что wlroots не даёт ничего из коробки. Это — низкоуровневая библиотека, которую каждый WM должен интегрировать, дописывая обвязку вручную. В X11 ты мог сделать полноценный оконный менеджер, написав 500 строк C на Xlib. В wlroots ты получаешь API, с которым нужно реализовать чуть ли не собственный GDM, Mutter и KWin одновременно, если ты хочешь больше, чем «открывать окна».

А теперь представим себе класс проектов: AwesomeWM, FVWM, IceWM, etc. Это всё — небольшие, минималистичные, зрелые проекты, написанные силами 1-2 человек. Как они должны поддерживать бесконечно меняющийся API протоколов, описанных как «идея», а не «реализация»? В X11 таких проблем нет: ты либо compliant, либо нет. Протокол ясен, реализация — универсальна.

На практике сейчас нет единого, нейтрального GUI API под Wayland. В X11 любой тулкит, даже самописный, имел равный доступ к дисплейному серверу. Это и есть модель GDI+ в Windows: интерфейс для отрисовки, унифицированный для всех. Wayland, в отличие от X11, не предоставляет оконной модели вообще, а отсылает к «протоколам поверх протоколов» — причём часть из них приватные или DE-специфичные (xdg-shell, zwlr-layer-shell и прочие). Это не экосистема, это зоопарк стеков, где каждый вынужден реализовывать недостающие фрагменты архитектуры с нуля.

Я думаю, что к моменту, когда иксы решат закопать окончательно, все юзкейсы будут закрыты

А что если нет? Что если не закроют? Значит, у нас будет ситуация, когда софт — реальный, нужный — будет искусственно ограничиваться, деградировать в UX, или полностью выпадать из пользовательского опыта. Не потому что он плохой, а потому что «архитекторы решили» выкинуть API, которым он пользовался десятилетиями.

Но поддержку иксов еще не дропнули

См. Fedora, GNOME, KDE, — они все по умолчанию уже на Wayland. Поддержка X11 переехала в XWayland (уже не полноценный X-сервер, а подобие эмулятора, прослойки), причём отстаёт по поддержке инпутов, GPU, и имеет свой event loop. Это уже не «поддержка X11», это — режим совместимости с проблемами.

В итоге что происходит:

• Wayland — протокол;
• wlroots — базовая библиотека;
• Weston — референсная имплементация (которая не предназначена для реального использования);

А все остальные обязаны строить архитектуру на 10+ слоях API, которые либо не устоялись, либо не задокументированы. Это приводит к эффекту: все делают чуть-чуть своего, но никто не делает общего. Wayland не унифицирует стек, а его разрывает. В этом отличие от X11 и GDI.

Реальная альтернатива есть уже сейчас: развивать wine/proton-протоколы. Реализация GDI+ поверх Wine/DRM/DirectFB — возможный путь к новой GUI-архитектуре, без деградации по функциональности. Именно подобная реализация GDI+ может стать основой нового унифицированного протокола:

• она API-first, а не protocol-first;
• она стабильно работает с тысячами legacy-программ;
• её можно обвязать DRM/KMS и GPU acceleration;
• она имеет логическую совместимость с Win32 и .NET GUI-приложениями.

Wine и Proton на десктопе показывают, как можно развивать, не ломая. А Wayland на десктопе — как можно ломать, не развивая. Я не призываю закапывать Wayland. Он уже нашёл свою нишу. Его продолжат корпы развивать в нужном для себя ключе. Я лишь напоминаю, что сообщество снова совершает ошибку, полагаясь на заведомо слабое сиюминутное решение. Возможно, более критическую, чем в прошлый раз. Я буду рад, если всё пойдёт по оптимистическому сценарию, но выглядит это довольно печально. Скорее всего, Valve не будет развивать десктоп (о чём уже есть намёки с её стороны). Потому что её интересуют игры, игровые приставки, в целом несколько иные вещи. У неё свои корпоративные интересы.

Все основные разработчики иксов, которые были вовлечены в этот проект, перекатились на вяленд

Но это и есть самый очевидный конфликт интересов: когда разработчики текущего решения одновременно являются архитекторами конкурирующего подхода, их мотивация дропнуть X11 перестаёт быть объективной — она становится стратегической, идеологической и самоусиливающейся. Это как если бы разработчики VHS объявили, что Betamax ««уже не нужен», потому что «поддерживать его трудно» — в момент, когда они одновременно разрабатывают VHS. Это не аргумент, это позиция. И к ней надо относиться критически, а не как к догме.

«Устали от костылей» — не технический довод, это эмоциональный аргумент, а не инженерный.

Здесь имеется в виду «накопился большой технический долг и оверхед на сопровождение»

Хорошо. Но тогда возникает встречный вопрос: а почему бы не начать с его погашения? Вместо того чтобы радикально отказаться от зрелой платформы с широчайшей совместимостью, можно было ограничиться реструктуризацией, перейти, например, на чисто XCB-based сервер или переосмыслить клиентский протокол, сохранив базовые свойства X11 как архитектуры: нейтральность, универсальность, toolkit-agnostic функциональность. То есть, сделать X12, Xng, X-Wayland-InsideOut, наконец.

Смотри: в случае с GDI и GDI+ в Windows тоже был «технический долг». Но никто не выкинул его на помойку, а сделали совместимость поверх Direct2D, DWM и UWP. Microsoft вложилась в interop, а не в разрушение экосистемы. Именно поэтому в Windows до сих пор живы и WinForms, и MFC, и даже Win32 — и все они работают.

Всем маленьким WM предлагается использовать wlroots

Да, но проблема в том, что wlroots не даёт ничего из коробки. Это — низкоуровневая библиотека, которую каждый WM должен интегрировать, дописывая обвязку вручную. В X11 ты мог сделать полноценный оконный менеджер, написав 500 строк C на Xlib. В wlroots ты получаешь API, с которым нужно реализовать чуть ли не собственный GDM, Mutter и KWin одновременно, если ты хочешь больше, чем «открывать окна».

А теперь представим себе класс проектов: AwesomeWM, i3, DWM, Openbox, Fluxbox, IceWM. Это всё — небольшие, минималистичные, зрелые проекты, написанные силами 1-2 человек. Как они должны поддерживать бесконечно меняющийся API протоколов, описанных как «идея», а не «реализация»? В X11 таких проблем нет: ты либо compliant, либо нет. Протокол ясен, реализация — универсальна.

На практике сейчас нет единого, нейтрального GUI API под Wayland. В X11 любой тулкит, даже самописный, имел равный доступ к дисплейному серверу. Это и есть модель GDI+ в Windows: интерфейс для отрисовки, унифицированный для всех. Wayland, в отличие от X11, не предоставляет оконной модели вообще, а отсылает к «протоколам поверх протоколов» — причём часть из них приватные или DE-специфичные (xdg-shell, zwlr-layer-shell и прочие). Это не экосистема, это зоопарк стеков, где каждый вынужден реализовывать недостающие фрагменты архитектуры с нуля.

Я думаю, что к моменту, когда иксы решат закопать окончательно, все юзкейсы будут закрыты

А что если нет? Что если не закроют? Значит, у нас будет ситуация, когда софт — реальный, нужный — будет искусственно ограничиваться, деградировать в UX, или полностью выпадать из пользовательского опыта. Не потому что он плохой, а потому что «архитекторы решили» выкинуть API, которым он пользовался десятилетиями.

Но поддержку иксов еще не дропнули

См. Fedora, GNOME, KDE, — они все по умолчанию уже на Wayland. Поддержка X11 переехала в XWayland (уже не полноценный X-сервер, а подобие эмулятора, прослойки), причём отстаёт по поддержке инпутов, GPU, и имеет свой event loop. Это уже не «поддержка X11», это — режим совместимости с проблемами.

В итоге что происходит:

• Wayland — протокол;
• wlroots — базовая библиотека;
• Weston — референсная имплементация (которая не предназначена для реального использования);

А все остальные обязаны строить архитектуру на 10+ слоях API, которые либо не устоялись, либо не задокументированы. Это приводит к эффекту: все делают чуть-чуть своего, но никто не делает общего. Wayland не унифицирует стек, а его разрывает. В этом отличие от X11 и GDI.

Реальная альтернатива есть уже сейчас: развивать wine/proton-протоколы. Реализация GDI+ поверх Wine/DRM/DirectFB — возможный путь к новой GUI-архитектуре, без деградации по функциональности. Именно подобная реализация GDI+ может стать основой нового унифицированного протокола:

• она API-first, а не protocol-first;
• она стабильно работает с тысячами legacy-программ;
• её можно обвязать DRM/KMS и GPU acceleration;
• она имеет логическую совместимость с Win32 и .NET GUI-приложениями.

Wine и Proton на десктопе показывают, как можно развивать, не ломая. А Wayland на десктопе — как можно ломать, не развивая. Я не призываю закапывать Wayland. Он уже нашёл свою нишу. Его продолжат корпы развивать в нужном для себя ключе. Я лишь напоминаю, что сообщество снова совершает ошибку, полагаясь на заведомо слабое сиюминутное решение. Возможно, более критическую, чем в прошлый раз. Я буду рад, если всё пойдёт по оптимистическому сценарию, но выглядит это довольно печально. Скорее всего, Valve не будет развивать десктоп (о чём уже есть намёки с её стороны). Потому что её интересуют игры, игровые приставки, в целом несколько иные вещи. У неё свои корпоративные интересы.