LINUX.ORG.RU

Ситуация с Wayland: факты о X и Wayland.

 ,


32

7

Это вольный перевод статьи, намедни размещённой на phoronix. Оринальная статья — обзор недостатков, их исправлений и преимуществ между X и Wayland. Её написал Eric Griffith, при участии Daniel Stone, специально для ресурса phoronix. Работа собрана по кусочкам из презентаций Keith Packard, David Airlie, Kristian Høgsberg, из страниц про X11, X12, Wayland в вики и на freedesktop.org, из прямых интервью с разработчиками.

Оригинал выпущен под Creative Commons версия 3, с указанием авторства; перевод доступен на тех же условиях (с указанием на авторов оригинала, как мне кажется).

Недостатки X

Прежде всего автор думает, что преимущества Wayland лучше всего понятны через перспективу недостатков X11. Итак, начнём...

  1. Мы потратили последние десять лет на «исправление» X с помощью оборачивания его расширениями и плагинами. Однако, X имеет минимальную поддержку версионирования расширений.
    • Версионирование ведётся для одного клиента, а не для одного соединения с API расширения; если ваше приложение поддерживает одну версию расширения, а библиотеки — другую, вы не можете предсказать, какая версия расширения будет получена в итоге.
    • Мысленный эксперимент: Rekonq поддерживает Xinput 2.2, библиотеки KDE — Xinput 2.0, а плагин Flash — только базовый X11. Все они будут определять, какая версия подсистемы ввода поддерживается браузером Rekonq, и в результате будет отдана одна версия для работы со всем вводом... И это может быть не та версия, которая имеет всё необходимое.
    • Если вы счастливчик, вы получите минимальную поддерживаемую версию и приложение будет работать хорошо. Если вы не очень удачливый, вы получите максимальную версию и будете посылать бесполезные сообщения между клиентом и X.
  2. X имеет четыре подсистемы ввода: базовый протокол X11, Xinput 1.0, Xinput 2.0, Xinput 2.2. Xinput 1.0 канул в Лету, но оставшиеся три остаются взаимосвязанными. Daniel Stone описал это так: «Есть всего три человека, которые действительно понимают, как подсистемы ввода уживаются вместе... И я бы хотел не быть одним из них».
  3. Много лет назад у кого-то появилась идея «механизм, а не алгоритм». Фраза является отсылкой к тому, что X имеет свой уникальный API для рисования и собственную библиотеку вроде GTK+ или Qt. X определяет низкоуровневые понятия, такие как прямая линия, толстая прямая линия, дуга, окружность, неполноценные шрифты и другие элементы конструктора, бесполезные по отдельности. Примечание от Daniel: «Внешний вид толстых линий должен точно соответствовать спецификации, которая обязывает их выглядеть уродливо».
  4. X большой и тупой. Прежде чем мы (сообщество) начали выкидывать его компоненты и использовать обходные пути, X имел внутри почти полную ОС, включая свой сервер печати и свой бинарный транслятор для ELF, COFF и a.out.
  5. Композитинг и синхронизация окон. Разработчики научили X композитингу с помощью Composite Extension. Композитинг хорош для простых случаев, как то: рабочий стол, OpenGL. Но если вы захотите использовать hardware overlays (т.е видео), может случиться катастрофа. В том же браузере содержимое вкладки и окно flash-плагина обрабатываются отдельно и не синхронизируются, так что остаётся лишь скрестить пальцы в надежде. что разница во времени обработки не будет слишком большой. В результате при прокрутке страницы с играющим видео иногда возникают разрывы и артефакты.
  6. Шрифты. Разработчики пытались перенести шрифты под управление X-сервера с помощью расширения STSF, и предоставить клиентам достаточную информацию, чтобы те могли правильно определить расположение шрифтов на экране. Но количество информации, достаточной для выполнения данной задачи, превышало размер самих шрифтов. В итоге было решено предоставить клиентам полную свободу действий, избавившись от шрифтов на сервере.
  7. Протокол без состояний. Иными словами, X ничего не запоминает.
    • «Пожалуйста, создайте мне X.conf. Пожалуйста, используйте его для настройки.» Зачем?! Со временем это было исправлено: файл конфигурации используется для перезаписи параметров по умолчанию, а сами параметры по умолчанию подчищены и могут теперь определяться автоматически.
    • Многие имели проблемы с многомониторными конфигурациями в Linux, ну или хотя бы перенастраивали X после перезагрузки. Недостаток X в том, что он помнит эти конфигурации только после создания /etc/X11/xorg.conf.d/50-monitors.conf, который скорее всего придётся писать вручную.
    • Мы надеемся, что это было исправлено созданием libkscreen, обёртки над xrandr, которая наконец-то стала запоминать параметры мониторов, используя их уникальный EDID.
    • В течение длительного периода (а может быть и до сих пор) при подключении дополнительного монитора в Linux основной монитор имел композитинг, а дополнительный — нет. Это, возможно, исправлено в RandR1.4, но его автор не может найти убедительных доказательств.
  8. Бесполезная иерархия окон. В X каждое поле ввода и текстовая надпись имеют своё окно со своим родителем. Никто не знает, какую же функцию выполняет эта иерархия. Реальные библиотеки (т.е не основанные на компонентах протокола X11) уже давно выбросили весь этот мусор в окно.
  9. Отчасти придирка, отчасти разумное беспокойство... В X11 каждая из координат— 2-байтное число со знаком. То есть, на всех ваших дисплеях должно быть не более 32,768 пикселей. При 100dpi это даёт вам 8,3-метровый дисплей. Замечательно... Но вот факты для сравнения: Windows XP имеет 96 DPI, а мой телефон — 320+. Добавьте сюда растущие разрешения и несколько мониторов, и вы увидите, что проблема приближается очень даже быстро.
  10. Для X всё является окном, и разных типов окон с его точки зрения нет.
    • Скринсейвер — это окно, которое просит X расположить его поверх всех окон, сделать полноэкранным и отдать весь ввод.
    • Всплывающее окно просит X расположить его в заданной точке и отдать весь ввод.
    • Они конфликтуют: скринсейвер не будет активирован, пока показано всплывающее окно.
    • Наверняка ваши скринсейвер и скринлокер не прокинули хуки во все необходимые библиотеки, распознающие клавиши для управления медиа... Представьте, что вы слушали музыку, работая на ноутбуке, а затем закрыли крышку. Ноутбук уснул, скринсейвер стал активным окном. Как только вы откроете крышку, ноутбук проснётся и музыка загромыхает снова, так что снова закрыть крышку окажется проще, чем вбить проль, затем открыть плеер и поставить его на паузу либо выключить звук.
    • Разработчики пытались исправить проблему и сделали спецификацию нового расширения, которое в теории работало. Но когда его попытались реализовать, оказалось, что оно серьёзно ломает модель работы X-сервера. Так что проблема существовала 26 лет и продолжает существовать. Расслабьтесь и получайте удовольствие.
  11. «Но Eric, если X11 настолько плох, то почему бы не сделать X12 вместо нового протокола?». Ну, формально, это уже сделано. При сохранении его под знаменем X возникает практический недостаток: все, кто беспокоится о X, будут иметь право голоса в разработке следующей версии. С помощью названия «Wayland» этой проблемы можно избежать. Никого ничто не волнует. Это не связанный с X проект, разработчики могут творить с будущим дисплейным сервером всё, что душа пожелает, ну а те, кто беспокоится о X, могут пойти разрабатывать X12.

Лекарство от Wayland (пронумерованы попарно с недостатками X).

  1. Весь протокол версионирован. Каждый слушатель получает именно ту версию, которую он поддерживает, и ничего поверх этого. Никаких случайностей.
  2. Подсистема ввода в Wayland очень похожа на Xinput 2.2, за вычетом всего старья и отношения Master/Slave между источниками ввода. Слушатель получит одну виртуальную клавиатуру, одну виртуальную мышь и один невиртуальный сенсорный ввод. Кошмар под названием «мультитач» в конце концов упорядочен. Примечание от Daniel: как один из авторов мультитача в X, я считаю себя достаточно компетентным, чтобы назвать его кошмарным.
  3. У Wayland нет API для рисования, в обход которого можно было бы работать. Wayland ожидает заполнения клиентом буфера рисования, и его не волнует способ заполнения, если не считать контроля за попытками задеть чужие буфера.
  4. Wayland минималистичен, он не хранит внутри себя псевдо-ОС ради контроля вывода графики. Клиенты принимают на себя этот удар, что хорошо — им не придётся заботиться о сверхдолгом сопровождении обратной совместимости. Qt5 избавилось от модуля qt3support. X всё ещё сопровождает то, что было написано 26 лет назад. Примечание от Daniel: кроме того, вызовы к вейланду — не блокирующие, рисование всего рабочего стола не остановится из-за зависания или очень дорогой операции на стороне одного из клиентов: остановится только этот клиент.
  5. В вейланде — принудительный композитинг. Это не означает, что везде должны быть 3D-эффекты или изгибающиеся окна. Под композитингом мы подразумеваем отсутствие разрывов, необновлённых кусков и проблесков. Лозунг вейланда — «каждый кадр будет идеальным». Каждый пиксель прорисован как должно и расположен где должно, и появляется, когда клиент того потребует.
  6. Шрифты отданы клиентам.
  7. Многомониторные конфигурации и гибридная графика (Optimus) отданы клиентам, вейланду нужен только буфер с пикселями и информация о том, где его расположить.
  8. В вейланде есть два вида окон: окна верхнего уровня и подповерхности (в основном для проигрывания видео). Причём, в отличие от X, они синхронизируются. При прокрутке страницы с видео в браузере у вас не будет ни разрывов, ни артефактов.
  9. С точки зрения клиентов, вейланд не оперирует глобальными координатами, предпочитая систему отсчёта поверхности для рисования. Счётчик координат 31-битный, то есть каждая поверхность может иметь 2,147,483,648 пикселей как в ширину, так и в высоту.
  10. Для обеспечения дополнительной безопасности, ваш скринсейвер и скринлокер являются частью композитора. Кроме того, композитор распознает клавиши управления медиа, так что даже при заблокированном экране можно выключить звук.

Некоторые заблуждения в плане X и Wayland.

  1. «X — это юниксвейно». X обрабатывает печать, управление буферами для рисования, имел свой тулкит, обрабатывал шрифты, имел бинарный транслятор — и всё это помимо других задач.
  2. «В X есть сетевая прозрачность» — её нет. Базовый протокол X и DRI-1 имели сетевую прозрачность, но никто не использует ни то, ни другое. Shared-memory, DRI2 и DRI-3000 не имеют сетевой прозрачности и не работают по сети. В наше время X превратился в синхронный, плохо сделанный VNC. Если бы он был плохо сделанным асинхронным VNC, то может быть мы бы и заставили его работать. Но он не такой: XLib синхронная, а переход на XCB медленный, что делает передачу по сети настоящим кошмаром.
  3. «Разработчики Wayland наступают на те же грабли, что и X11, потому что не знают его» — неверно, потому что большинство разработчиков Wayland являются бывшими разработчиками X11.
  4. «Вейланд требует 3D.» — неверно, он требует только композитинга, так что есть даже бекенд на pixman для программной отрисовки.
  5. «Вейланд не умеет в удалённый доступ» — умеет, и должен справиться с этой задачей лучше чем X, отчасти из-за асинхронности протокола. Скорее всего Wayland станет высокопроизводительной версией VNC, и прототип уже есть. Причём мы ещё ни разу не давали идей по его улучшению, и скорее всего сможем сделать его лучше, если приложим усилия.
  6. «Вейланд нарушает обратную совместимость» — с тех пор как XWayland закончен и принят в основную ветку, у нас должна появиться почти совершенная обратная совместимость, потому что каждое приложение, использующее X, получает маленький X-сервер для дальнейшей работы с ним. Нам известно одно препятствие — трансформации окна, ведь приложение думает, что оно расположено в верхнем правом углу экрана, оттого, что клиентский X-сервер приведён к размерам клиентского окна.

Парочка характерных преимуществ Wayland

  1. «Каждый кадр будет идеальным». Каждый кадр будет представлен в правильном порядке (возможен сброс лишних кадров, но вы не получите кадр 199, затем 205, а затем 200 оттого, что сервер извлёк их в произвольном порядке. Каждый кадр имеет свой timestamp.)
  2. Минималистичный! Мы способствуем славному будущему Wayland путём уменьшения пространства для возможных ошибок.
  3. Бекенды, специфичные для оборудования. Думается, некоторые люди заметили появление бекенда Wayland, предназначенного для Rasberry Pi — он позволяет использовать все особенности этой платформы. Такой подход используется не везде, многие вещи не потребуют бекенда для конкретного оборудования, но неплохо бы иметь возможность сделать доработку, когда потребуется.

P.S. От переводчика: заметно, что в статье мало технических деталей или же ссылок, а лозунги я наоборот вырезал. К слову, о минималистичности: для вейланда уже есть композитор, способный отображать окна в 3d-пространстве на манер quake, но что-то я сомневаюсь в правильной обработке звука в таком 3d. Для игр есть OpenAL, который имеет 3d-координаты, соответствующие координатам OpenGL (синхронизация позиций источников звука и слушателя с позициями объектов и камеры производится программистом). Для вейланда нет ничего подобного OpenAL.

Если же кто-то имеет вопросы к авторам статьи — он может задать их на Phoronix.

>>> Подробности

★★★★

Проверено: maxcom ()
Последнее исправление: Aceler (всего исправлений: 16)

Ответ на: комментарий от anonymous

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

mrdeath ★★★★★
()
Ответ на: комментарий от namezys

здесь рассказывается, как под wayland написали бэкэнд, использующий возможности аппаратного масштабирования, доступные в чипе Raspberry Pi

kravich ★★★★
()
Ответ на: комментарий от ZenitharChampion

И какая сетевая прозрачность есть у иксов? Рисовать окошки на другой машине умеет и RDP. Та сетевая прозрачность что подразумевалась изначально больше не работает, тулкиты больше не рисуют через иксы примитивами, теперь они гоняют пиксели, часто крайне не эффективно. Сетевая прозрачность в иксах сейчас ничуть не лучше чем в вяленом. А то и хуже учитываю что в вяленом уже есть реализация RDP и VNC. В иксах для этого нужны криво работающие костыли.

FFSinit ★★
()
Ответ на: комментарий от Aceler

Ой-йо. А поиграй мне 4k видео примитивами :D Ну ладно, хотя бы FullHD :)))

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

ssvb
()

Linux - это ядро, все остальное - от лукавого.... Иксы - зло, а их реинкарнации - зло в бесконечной степени...

beos ★★
()
Ответ на: комментарий от carasin

Nvidia вроде как собиралась выпустить драйвер с EGL, так что Wayland'у этого должно хватить. Туманнее же перспективы у блоба AMD.

Блоб AMD поддерживает OpenGL ES 2.0 и EGL уже пять лет (cast x0r) а так же на годы обогнал блоб nVidia в отношении поддержки гибридной графики и XrandR 1.2, но на ЛОРе всё ещё уверены в превосходстве блоба nVidia...

RussianNeuroMancer ★★★★★
()

Глядя на то, с какой регулярностью разработчики Wayland-а пишут о нем статьи типа «Почему X-ы - г...но, за wayland-ом будущее» у меня складывается стойкое ощущение навязчивой рекламы коммивояжера,насильно впаривающего новое не совсем отлаженное ПО вместо старого вполне рабочего продукта. Очень похоже на «10 причин по которым вам стоит переходить на Windows 8»

junkie
()

Беспокоит одно: а с FVWM что будет?

...пойду допиливать консольные приложения, а то вдруг, придецца переползать в tty.

Spoofing ★★★★★
()
Ответ на: комментарий от junkie

Иксы скоро в любом случае придется выкинуть, и лучше сделать это пораньше, потому что уже никто не понимает как они работают.

FFSinit ★★
()
Ответ на: комментарий от ZenitharChampion

напомнить для каких компьютеров проектировались X?

Вот и сиди под иксами на этих компьютерах и не мешай нормальным людям.

anonymous
()
Ответ на: комментарий от beos

Угу, ты еще Л. Торвальдсу это скажи..

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

Napilnik ★★★★★
()
Ответ на: комментарий от quiet_readonly

Рисовать примитивами — это GDI, самый тормозной API для отрисовки графики из всех доступных в винде.

Лол. Рисовать примитивами — это OGL и D3D. Тел ми моар.

geekless ★★
()
Ответ на: комментарий от PolarFox

Так приложение и будет использовать видеокарту (если ему нужно).

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

namezys ★★★★
()
Ответ на: комментарий от note173

Не всегда перенос рисования на видеокарту лучше программного построения картинки на процессоре.

Мне кажется, что задача опредления, кто лучше рисует, не задача приложения.

namezys ★★★★
()
Ответ на: комментарий от kravich

здесь рассказывается, как под wayland написали бэкэнд, использующий возможности аппаратного масштабирования, доступные в чипе Raspberry Pi

Спасибо, я почитаю, но днем. Но масштабирвоание - это верхушка айсберга.

namezys ★★★★
()
Ответ на: комментарий от Aceler

Почему «теперь»? Давно уже стали. Gnome Shell — CM, Compiz — CM, Kwin — CM, даже Metacity умеет CM. Собственно, идея Wayland родилась из понимания того, что все мажорные WM уже давно CM.

CM и WM - это отдельные задачи. С какого перепугу они должны быть прибиты гвоздями друг к другу?

geekless ★★
()
Ответ на: комментарий от Aceler

просто если это всё выкинуть, linux останется без графики

fxd

geekless ★★
()
Последнее исправление: geekless (всего исправлений: 1)
Ответ на: комментарий от legolegs

Иксорг уродлив и ненадёжен, вейланд убог. БЕЗNСХОДНОСТ,

Воистину.

geekless ★★
()
Ответ на: комментарий от anonymous

Сколько тебя читаю, постоянный баттхерт. То по поводу systemd, то по поводу Wayland

Может это потому, что я, в отличие от тебя, сижу в линуксе а не в винде, и соответственно пользуюсь его возможностями, в т.ч. «отсутствующей» сетевой прозрачностью иксов, и огребаю проблемы от ошибок и багов в новомодных веяниях типа systemd?

no-dashi ★★★★★
()
Ответ на: комментарий от anonymous

Так что RDP на порядок изящнее «сетевой прозрачности» с > 20 летним стажем, увы.

Так это говорит о том, что надо пилить свободный аналог RDP, а не вот это убожество для телефонов.

geekless ★★
()
Ответ на: комментарий от namezys

может ли приложение «отрисовать» примитив, скормив параметры «движку», который либо отправит это на устройство, если это имеет смысл, либо будет использовать программный рендеринг

Это называется OpenGL.

PolarFox ★★★★★
()
Ответ на: комментарий от no-dashi

пользуюсь его возможностями, в т.ч. «отсутствующей» сетевой прозрачностью иксов

Пользуйся дальше. Кто у тебя иксы забирает, истеричка?

fragmentor
()
Ответ на: комментарий от fragmentor

Wayland разрабатывается в качестве аналога RDP?

Wayland разрабатывается в качестве косого аналога андроидовского композитора. Т.е. не нужен, потому что андроид уже существует.

geekless ★★
()
Ответ на: комментарий от Aceler

Флеш мне видео когда посередь браузера показывает — он тоже примитивами рисует?

Если он рисует - да, он рисует примитивами. А видео, внезапно - это не рисование, а декодирование битмапов.

tailgunner ★★★★★
()
Ответ на: комментарий от Reset

Изначальная идея — гонять по сети команды отрисовки не работает.

И с чего это она перестала работать? Может все таки от того, что этот механизм искусственно поломали?

fat_angel ★★★★★
()
Ответ на: комментарий от PolarFox

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

Но если говорить о том, что любое приложение содержит «буфер», в которой оно рисует, а потом буфер отображается на реальное устройство, то эта концепция получается несоместимой.

namezys ★★★★
()
Ответ на: комментарий от FFSinit

Рисовать окошки на другой машине умеет и RDP

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

no-dashi ★★★★★
()

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

Mir этому вашему Wayland'y

Deleted
()
Ответ на: комментарий от geekless

Wayland разрабатывается в качестве косого аналога андроидовского композитора

Пруф?

fragmentor
()
Ответ на: комментарий от geekless

Так что RDP на порядок изящнее «сетевой прозрачности» с > 20 летним стажем, увы.

Так это говорит о том, что надо пилить свободный аналог RDP

RDP - это и есть X12 :)

tailgunner ★★★★★
()

Сетевая прозрачность не нужна.

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

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

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

Конечно, сисадмины компаний, использующие в работе клиенты, подключающиеся к удалённым рабочим столам, без сетевой прозрачности будут, как без рук, но это не наши проблемы. На данном этапе развития разработчики десктопного Линукса должны думать о пользователях. Компании смогут позаботиться о себе сами. Их потребности могут быть удовлетворены на все сто некоторым плагином, который бы устанавливался на оба компьютера (клиента и сервера), устанавливал TCP-соединение и эмулировал команды клиента на удалённом рабочем столе, по аналогии с RDP в Windows. И для этого не нужно городить сеть в самой графической системе.

Я очень надеюсь, что разработчики Mir этой поймут и выкинут рудимент под названием «сетевая прозрачность» на помойку истории.

r5ha
()
Ответ на: Сетевая прозрачность не нужна. от r5ha

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

Да никто у сисадминов иксы не отбирает.

fragmentor
()
Ответ на: комментарий от geekless

RDP - это и есть X12 :)

Бессмысленная фраза.

Ты просто не увидел очевидного смысла «RDP - это протокол, построенный на тех же принципах, что X, но сделанный с учетом ошибок X (на 10 лет позже), костыли в котором незаметны за счет того, что у компании-производителя дофига денег».

tailgunner ★★★★★
()
Ответ на: комментарий от fragmentor

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

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

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от fragmentor

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

Evgueni ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

Я не разбираюсь в компьютерах. И боже упаси меня стать одним из вас, лол.

fragmentor
()
Ответ на: Сетевая прозрачность не нужна. от r5ha

Ну то, что людям, которые используют компьютеры для работы, а не для потребления контента хуже не будет — это точно. Просто они уйдут или запилят свой удобный дистрибутив, а вот ubuntа, если её разработчики сделают глупость, целиком соорентировавшись на игровой аудитории, то останутся один на один с истинными потребителями, так сказать с «жадными детьми» и мне их в этом случае заранее жаль. В смысле жаль разработчиков, естественно. Своебразный тупик.

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.