Мысли вслух о протоколе X | автор: Luca | 1 июля 2010
Категория: GNU/Linux
Прочитано 7832 раз и оставлено 1084 комментариев.
Два года назад, работая над Awesome, я присоединился к разработке XCB, который является частью инициативы Freedesktop. Мне пришлось изучить тайны протокола X11 и весь древний и таинственный мир, окружающий его.
За последние несколько месяцев я наконец-то смыл с себя всю эту грязь, и теперь чувствую необходимость поделиться своими размышлениями относительно всего этого беспорядка, длящегося десятилетиями.
Когда меня ещё не было на свете...
… группа Toto выпустила их знаменитую песню «Africa», а несколько умных парней работали над оконной системой — X Window System (это полное имя), у которой тоже (слишком) длинная история. Окончательная версия протокола (11-я) была разработана в 80-х. Вы можете узнать подробности истории в статье на Википедии.
В 2010 году мы по-прежнему слушаем диско, и всё так же используем различные протоколы, разработанные в 80-х (и даже раньше, чем X). Музыка эволюционирует, протоколы меняются, и X11 не стоит на месте.
Проблема в том, что X11 не эволюционирует правильно. Парни из MIT-и-всяких-других-мест-с-умниками создали первую версию X в 1984 и вносили изменения вплоть до 11-й версии протокола. Он был выпущен в 1987 году, и мы используем его по нынешний день. Одиннадцать версий было выпущено за 3 года в полном соответствии с моделью «ранний выпуск, частые обновления». Не знаю почему, но этот подход перестали применять в течение следующих 23 лет (хотя разработчики добавляли (и убирали) множество расширений протокола).
Я не знаю, какие изменения были внесены за первые 11 главных версий протокола X, но я более чем уверен, что за прошедшие 20+ лет назрела большая необходимость внести серьёзные изменения в него.
По моему скромному мнению, X11 не проектировался с расчётом на то, что он будет жить 23 года. Правда, я никого не обвиняю: я был 4-летним ребёнком и играл в Lego ®, когда была выпущена последняя версия протокола X, так что у меня было очень мало шансов сделать что-то лучшее.
Мы не будем исправлять. Мы будем приспосабливаться
Это, возможно, главный лозунг протокола X последних лет. Только не поймите меня превратно: я не собираюсь устраивать порку.
Протокол X11 старел с годами, и разработчики стали добавлять к нему расширения. За годы были добавлены тонны расширений. В точном соответствии с одним из изначальных принципов X:
Все они без исключения были добавлены потому, что (увы и ах) протокол X11 не предусматривал всех появившихся за последние 23 года вещей вроде видео, OpenGL, нескольких мониторов или удовольствия от рисования овальных окошек. Какие-то из этих расширений используются до сих пор, а какие-то уже канули в Лету.
Расширения протокола — это не есть что-то плохое, но попытки исправить протокол расширениями типа XFixes кажутся мне плохой идеей, несмотря на все добрые намерения, которыми мог руководствоваться Keith Packard.
На самом деле всё ещё хуже, чем вы думаете
Протокол X11 (без расширений) определяет около 120 типов запросов: создание окна, передвижение окна, и так далее.
В наши дни как минимум 25% из них совершенно бесполезны: использование шрифтов на стороне сервера или рисование квадратов и полигонов не используются ни одним современным приложением или тулкитом. Все они переопределены в запросах из расширений, таких как, например, XRender.
Работа с несколькими мониторами совершенно зап.тана. X11 разрабатывался для работы в режиме Zaphod (независимые мониторы). Но Xinerama, а в наши дни и XRandR полностью вытеснили его — последние версии сервера X (примерно с 2007 года) больше не поддерживают режим Zaphod, несмотря даже на то, что он является частью ядра протокола X11.
Даже хуже: многие запросы содержат ограничения или изъяны дизайна, например те, что описаны в документе исследователей из DEC: Почему X не наша идеальная оконная система.
Мы навалим сверху ещё больше сломанных стандартов
Следуя своим изначальным принципам, X не определяет политики, а только предоставляет механизмы, что выглядит правильным.
Вследствие этого, разработчики собрались и начали сочинять спецификации, чтобы определить набор правил и догм: ICCCM. Это было 22 года назад, в 1988 году. Бесполезно добавлять, что многие пункты этой спецификации уже безнадёжно устарели, потому что не учли множество современных технологий.
Я не единственный, кто так считает. Авторы проектов, которые стали двумя главными окружениями рабочего стола, KDE и GNOME, увидели это уже в 90-е, когда я только учился считать. И они написали EWMH, ещё один стандарт, который взгромоздился поверх ICCCM, дополнив его рядом приятных фич (максимизация, полноэкранный режим и прочие).
Проблема заключается в том, что этот стандарт также был написан не особо дальновидными людьми, которые одновременно работали над своими окружениями (GNOME, KDE и, может быть, ещё какие-то). Эти окружения рабочего стола имели тогда и имеют до сих пор целый ряд сильных концепций, определяющих, как должен работать десктоп: «он должен иметь рабочие места (workspaces)», «окно может существовать только на одном рабочем месте», «мы можем видеть только одно рабочее место в один момент времени», «у нас нет нескольких экранов», и так далее.
Чувак, не парься: у нас есть тулкиты!
Представление о том, как должен работать десктоп, в наше время высечено в мраморе для каждого приложения или библиотеки, реализующей EWMH, в том числе GTK+ и Qt.
В итоге, сейчас все просто позабыли про стандарты. Тулкиты реализуют их самостоятельно, обходя ограничения и изъяны протокола X11, и никто не хочет оглянуться назад.
И с этими тулкитами люди обращаются так же небрежно, как и со стандартами. Это порой приводит к неприятным сайд-эффектам. Например, Openoffice в качестве переключателя рабочих мест.
Мы не хотим оглядываться? Хуже, мы забыли, откуда пришли!
Рабочий стол со всеми этими плохо спроектированными стандартами продолжает эволюционировать более десятилетия. В него продолжают добавлять новые стандарты, самые последние из которых базируются на D-Bus, например, Desktop Notification Specification или свежий [irl=http://www.notmart.org/misc/statusnotifieritem/index.html]Status Notifier Specification[/url], разработанный в KDE.
Status Notifier — это новая реализация старого доброго системного трея, основанного на XEmbed, но теперь использующая механизмы D-Bus вместо X11, и добавляющая возможность показывать в системном трее что-то большее, чем просто иконки.
Черновик спецификации содержит серьёзный изъян дизайна, на который обратил внимание Wolfgang Draxfinger в своём обращении в список рассылки XDG. Вольфганг указывает, что X является сете-ориентированным протоколом, а D-Bus — нет. Следовательно, использование D-Bus спецификацией Status Notifier для передачи событий системного трея является плохой идеей: запуск графического приложения с компьютера А на компьютере В обновит трей на неправильном хосте!
Из чтения переписки очевидно, что это не пугает некоторых разработчиков KDE:
То, что Освальд описывает как частный случай, для многих из нас является самой типичной ситуацией. В общем, кому как повезёт.
На мой взгляд, это шаг назад в неправильном направлении. Но мы можем также сделать вывод, что сетевая часть X стала бесполезна, по крайней мере, для KDE.
Я предпочитаю верить в XCB
Когда я присоединился к Freedestop, мне пришлось поработать над библиотекой XCB, X C Binding. XCB обладает приятным, чистым, основанным на технологиях 21 века API для работы с протоколом X11. Его код генерируется автоматически на основе XML-файла с описанием протокола.
Для сравнения, Xlib состоит из мутного кода 80-х кодов, практически не комментированного и полного жёстко закодированных вещей. Лишь немногие способны понять некоторые его закоулки, вроде интернационализации или реализации XKB. И весь его код синхронный.
Поясню для тех, кто ещё не в курсе: X — это сетевой протокол, в котором вы должны послать запрос (как GET в HTTP), чтобы затем получить ответ. Xlib заставляет приложение ждать ответа на запрос, поэтому приложение блокируется до тех пор, пока сервер X не пришлёт ответ. XCB же не блокирует приложение, что позволяет послать серию запросов, сделать что-то полезное за время ожидания, а затем получить ответы.
Представьте, что ваш браузер посылает на веб-сервер по одному запросу за раз и заставляет Вас ждать показа страницы до тех пор, пока не закачает самую последнюю картинку.
В случае, когда X и все его клиенты расположены на одном компьютере, задержка невелика и незаметна, поэтому выгода от асинхронности XCB мала. Однако на медленной сети прирост производительности может быть огромен, что и доказал Peter Harris, переписав xlsclients на XCB.
Одна из долговременных целей разработчиков XCB — окончательно избавиться от Xlib, чтобы увеличить скорость и уменьшить время отклика приложений X11. Для этого необходимо портировать множество библиотек, потому что почти ни одна из них (за исключением Cairo) не поддерживает XCB.
С моей точки зрения, сейчас это довольно бесполезный труд. Десктопный мир доверен проектам GNOME и KDE, то есть, GTK+ и Qt. При этом похоже, что ни один из этих тулкитов не заинтересован в работе ни над XCB, ни над протоколом X. Они скорее прилагают большие усилия, чтобы обойти существующие ограничения и изъяны X, и по прежнему сидят на вершине кургана из костылей и реализаций порочных-по-дизайну-стандартов. Мне кажется, что никто не хочет оглянуться назад на все эти уровни и посмотреть, как их можно улучшить.
Они залезли слишком высоко, чтобы взглянуть вниз и увидеть, какой может быть отдача.
Enlightenment со своим EFL был первым тулкитом, который имел XCB-бэкенд (благодаря работе Vincent Torri). К сожалению, этот бэкенд уже не поддерживается, и никто о нём не заботится. В последний раз, когда я за него брался, он даже не компилировался.
X12?
В вики Freedesktop есть страничка под названием X12, на которой перечислены все вещи, которые должны быть исправлены. К сожалению, этот список только растёт, а о работе над X12 никто не заикается.
С другой стороны, есть несколько людей, которые в свободное время работают над XKB2, второй версией «давайте-снова-попробуем-исправить-клавиатурную-часть-протокола-написанного-23-года-назад» расширения.
В общем, не похоже, что X12 появится в ближайшее десятилетие.
Альтернативы?
Есть ли у нас альтернатива X? Есть Wayland, но он пока что довольно бесполезен. Также есть DirectFB, но он плохо портируем. На мой взгляд, пока что нет кандидатов на замену X.
В любом случае, ни один из главных тулкитов не поддерживает подобной альтернативы. GTK+ когда-то поддерживал DirectFB, но, насколько я знаю, сейчас уже ничего не работает (как отмечает Josselin Mouette). Именно поэтому последние версии установщика Debian переехали на использование X в графической части (благодаря работе Cyril Brulebois).
Заключение
XCB существует более пяти лет, но заинтересовались им совсем немногие. Насколько я могу наблюдать, никто не заинтересован использовать протокол X, все просто стараются инкапсулировать его каким-нибудь высокоуровневым API, чтобы как можно быстрее перестать его видеть. Это приводит к появлению плохо написанных приложений и тулкитов, набитых уродливыми хаками.
Всё это также значит, что написание новых приложений и тулкитов на базе XCB должно быть очень интересным проектом, однако для этого придётся потратить чересчур много времени, чтобы понять, как обходить изъяны протокола X, внесённые за многие годы предшественниками, в том числе Qt и GTK+.
Главные тулкиты практически ничего не делают, чтобы выиграть за счёт возвращения к тёмным водам X. Думаю, большинство их разработчиков предпочитают работать над прелестными 3D эффектами, опирающихся на геолокацию, чем над переопределением лучшей основы для каждого.
В мире X слишком мало рабочей силы. Нехватка мэйнтейнеров X в Debian — простое следствие этой ситуации. Конечно, существуют очень компетентные и квалифицированные разработчики X, в чём легко можно убедиться, читая блоги на Planet Freedesktop (я не в счёт). К сожалению, их количества недостаточно для того, чтобы покрыть всю сферу деятельности X: устройства ввода, графические устройства, спецификации новых расширений протокола и так далее. Сервер X — достаточно поздняя разработка, и большинству разработчиков интереснее работать над ним, а не над самим протоколом. Это можно понять.
Мне интересно, куда мы придём со всем этим через несколько лет. К нынешнему времени я варюсь в котле под названием X уже 3 года, и чувствую, что рано или поздно все альтернативы KDE и GNOME вымрут. Время, когда Вы могли выбирать между дюжиной «современных» оконных менеджеров, прошло.
В конце концов, может быть, это простой дарвинизм в применении к компьютерному софту.
Примечание переводчика: автор этой статьи — французский программист Julien Danjou, разработчик оконного менеджера Awesome. Оригинал статьи расположен здесь.
источник
За последние несколько месяцев я наконец-то смыл с себя всю эту грязь, и теперь чувствую необходимость поделиться своими размышлениями относительно всего этого беспорядка, длящегося десятилетиями.
Когда меня ещё не было на свете...
… группа Toto выпустила их знаменитую песню «Africa», а несколько умных парней работали над оконной системой — X Window System (это полное имя), у которой тоже (слишком) длинная история. Окончательная версия протокола (11-я) была разработана в 80-х. Вы можете узнать подробности истории в статье на Википедии.
В 2010 году мы по-прежнему слушаем диско, и всё так же используем различные протоколы, разработанные в 80-х (и даже раньше, чем X). Музыка эволюционирует, протоколы меняются, и X11 не стоит на месте.
Проблема в том, что X11 не эволюционирует правильно. Парни из MIT-и-всяких-других-мест-с-умниками создали первую версию X в 1984 и вносили изменения вплоть до 11-й версии протокола. Он был выпущен в 1987 году, и мы используем его по нынешний день. Одиннадцать версий было выпущено за 3 года в полном соответствии с моделью «ранний выпуск, частые обновления». Не знаю почему, но этот подход перестали применять в течение следующих 23 лет (хотя разработчики добавляли (и убирали) множество расширений протокола).
Я не знаю, какие изменения были внесены за первые 11 главных версий протокола X, но я более чем уверен, что за прошедшие 20+ лет назрела большая необходимость внести серьёзные изменения в него.
По моему скромному мнению, X11 не проектировался с расчётом на то, что он будет жить 23 года. Правда, я никого не обвиняю: я был 4-летним ребёнком и играл в Lego ®, когда была выпущена последняя версия протокола X, так что у меня было очень мало шансов сделать что-то лучшее.
Мы не будем исправлять. Мы будем приспосабливаться
Это, возможно, главный лозунг протокола X последних лет. Только не поймите меня превратно: я не собираюсь устраивать порку.
Протокол X11 старел с годами, и разработчики стали добавлять к нему расширения. За годы были добавлены тонны расширений. В точном соответствии с одним из изначальных принципов X:
Цитата:
Важно чётко определить, чем система является, и чем она не является. Не надо стараться услужить потребностям всего мира; вместо этого следует сделать систему расширяемой так, чтобы дополнительные потребности могли быть удовлетворены подходящим способом.
Все они без исключения были добавлены потому, что (увы и ах) протокол X11 не предусматривал всех появившихся за последние 23 года вещей вроде видео, OpenGL, нескольких мониторов или удовольствия от рисования овальных окошек. Какие-то из этих расширений используются до сих пор, а какие-то уже канули в Лету.
Расширения протокола — это не есть что-то плохое, но попытки исправить протокол расширениями типа XFixes кажутся мне плохой идеей, несмотря на все добрые намерения, которыми мог руководствоваться Keith Packard.
На самом деле всё ещё хуже, чем вы думаете
Протокол X11 (без расширений) определяет около 120 типов запросов: создание окна, передвижение окна, и так далее.
В наши дни как минимум 25% из них совершенно бесполезны: использование шрифтов на стороне сервера или рисование квадратов и полигонов не используются ни одним современным приложением или тулкитом. Все они переопределены в запросах из расширений, таких как, например, XRender.
Работа с несколькими мониторами совершенно зап.тана. X11 разрабатывался для работы в режиме Zaphod (независимые мониторы). Но Xinerama, а в наши дни и XRandR полностью вытеснили его — последние версии сервера X (примерно с 2007 года) больше не поддерживают режим Zaphod, несмотря даже на то, что он является частью ядра протокола X11.
Даже хуже: многие запросы содержат ограничения или изъяны дизайна, например те, что описаны в документе исследователей из DEC: Почему X не наша идеальная оконная система.
Мы навалим сверху ещё больше сломанных стандартов
Следуя своим изначальным принципам, X не определяет политики, а только предоставляет механизмы, что выглядит правильным.
Вследствие этого, разработчики собрались и начали сочинять спецификации, чтобы определить набор правил и догм: ICCCM. Это было 22 года назад, в 1988 году. Бесполезно добавлять, что многие пункты этой спецификации уже безнадёжно устарели, потому что не учли множество современных технологий.
Я не единственный, кто так считает. Авторы проектов, которые стали двумя главными окружениями рабочего стола, KDE и GNOME, увидели это уже в 90-е, когда я только учился считать. И они написали EWMH, ещё один стандарт, который взгромоздился поверх ICCCM, дополнив его рядом приятных фич (максимизация, полноэкранный режим и прочие).
Проблема заключается в том, что этот стандарт также был написан не особо дальновидными людьми, которые одновременно работали над своими окружениями (GNOME, KDE и, может быть, ещё какие-то). Эти окружения рабочего стола имели тогда и имеют до сих пор целый ряд сильных концепций, определяющих, как должен работать десктоп: «он должен иметь рабочие места (workspaces)», «окно может существовать только на одном рабочем месте», «мы можем видеть только одно рабочее место в один момент времени», «у нас нет нескольких экранов», и так далее.
Чувак, не парься: у нас есть тулкиты!
Представление о том, как должен работать десктоп, в наше время высечено в мраморе для каждого приложения или библиотеки, реализующей EWMH, в том числе GTK+ и Qt.
В итоге, сейчас все просто позабыли про стандарты. Тулкиты реализуют их самостоятельно, обходя ограничения и изъяны протокола X11, и никто не хочет оглянуться назад.
И с этими тулкитами люди обращаются так же небрежно, как и со стандартами. Это порой приводит к неприятным сайд-эффектам. Например, Openoffice в качестве переключателя рабочих мест.
Мы не хотим оглядываться? Хуже, мы забыли, откуда пришли!
Рабочий стол со всеми этими плохо спроектированными стандартами продолжает эволюционировать более десятилетия. В него продолжают добавлять новые стандарты, самые последние из которых базируются на D-Bus, например, Desktop Notification Specification или свежий [irl=http://www.notmart.org/misc/statusnotifieritem/index.html]Status Notifier Specification[/url], разработанный в KDE.
Status Notifier — это новая реализация старого доброго системного трея, основанного на XEmbed, но теперь использующая механизмы D-Bus вместо X11, и добавляющая возможность показывать в системном трее что-то большее, чем просто иконки.
Черновик спецификации содержит серьёзный изъян дизайна, на который обратил внимание Wolfgang Draxfinger в своём обращении в список рассылки XDG. Вольфганг указывает, что X является сете-ориентированным протоколом, а D-Bus — нет. Следовательно, использование D-Bus спецификацией Status Notifier для передачи событий системного трея является плохой идеей: запуск графического приложения с компьютера А на компьютере В обновит трей на неправильном хосте!
Из чтения переписки очевидно, что это не пугает некоторых разработчиков KDE:
Цитата:
Разумеется, не стоит сильно беспокоиться об этом причудливом частном случае. По крайней мере, вы будете считать его таковым до тех пор, пока сами не столкнётесь с ним (просто тестируя что-нибудь или настраивая какой-нибудь изощрённый киоск)."
То, что Освальд описывает как частный случай, для многих из нас является самой типичной ситуацией. В общем, кому как повезёт.
На мой взгляд, это шаг назад в неправильном направлении. Но мы можем также сделать вывод, что сетевая часть X стала бесполезна, по крайней мере, для KDE.
Я предпочитаю верить в XCB
Когда я присоединился к Freedestop, мне пришлось поработать над библиотекой XCB, X C Binding. XCB обладает приятным, чистым, основанным на технологиях 21 века API для работы с протоколом X11. Его код генерируется автоматически на основе XML-файла с описанием протокола.
Для сравнения, Xlib состоит из мутного кода 80-х кодов, практически не комментированного и полного жёстко закодированных вещей. Лишь немногие способны понять некоторые его закоулки, вроде интернационализации или реализации XKB. И весь его код синхронный.
Поясню для тех, кто ещё не в курсе: X — это сетевой протокол, в котором вы должны послать запрос (как GET в HTTP), чтобы затем получить ответ. Xlib заставляет приложение ждать ответа на запрос, поэтому приложение блокируется до тех пор, пока сервер X не пришлёт ответ. XCB же не блокирует приложение, что позволяет послать серию запросов, сделать что-то полезное за время ожидания, а затем получить ответы.
Представьте, что ваш браузер посылает на веб-сервер по одному запросу за раз и заставляет Вас ждать показа страницы до тех пор, пока не закачает самую последнюю картинку.
В случае, когда X и все его клиенты расположены на одном компьютере, задержка невелика и незаметна, поэтому выгода от асинхронности XCB мала. Однако на медленной сети прирост производительности может быть огромен, что и доказал Peter Harris, переписав xlsclients на XCB.
Одна из долговременных целей разработчиков XCB — окончательно избавиться от Xlib, чтобы увеличить скорость и уменьшить время отклика приложений X11. Для этого необходимо портировать множество библиотек, потому что почти ни одна из них (за исключением Cairo) не поддерживает XCB.
С моей точки зрения, сейчас это довольно бесполезный труд. Десктопный мир доверен проектам GNOME и KDE, то есть, GTK+ и Qt. При этом похоже, что ни один из этих тулкитов не заинтересован в работе ни над XCB, ни над протоколом X. Они скорее прилагают большие усилия, чтобы обойти существующие ограничения и изъяны X, и по прежнему сидят на вершине кургана из костылей и реализаций порочных-по-дизайну-стандартов. Мне кажется, что никто не хочет оглянуться назад на все эти уровни и посмотреть, как их можно улучшить.
Они залезли слишком высоко, чтобы взглянуть вниз и увидеть, какой может быть отдача.
Enlightenment со своим EFL был первым тулкитом, который имел XCB-бэкенд (благодаря работе Vincent Torri). К сожалению, этот бэкенд уже не поддерживается, и никто о нём не заботится. В последний раз, когда я за него брался, он даже не компилировался.
X12?
В вики Freedesktop есть страничка под названием X12, на которой перечислены все вещи, которые должны быть исправлены. К сожалению, этот список только растёт, а о работе над X12 никто не заикается.
С другой стороны, есть несколько людей, которые в свободное время работают над XKB2, второй версией «давайте-снова-попробуем-исправить-клавиатурную-часть-протокола-написанного-23-года-назад» расширения.
В общем, не похоже, что X12 появится в ближайшее десятилетие.
Альтернативы?
Есть ли у нас альтернатива X? Есть Wayland, но он пока что довольно бесполезен. Также есть DirectFB, но он плохо портируем. На мой взгляд, пока что нет кандидатов на замену X.
В любом случае, ни один из главных тулкитов не поддерживает подобной альтернативы. GTK+ когда-то поддерживал DirectFB, но, насколько я знаю, сейчас уже ничего не работает (как отмечает Josselin Mouette). Именно поэтому последние версии установщика Debian переехали на использование X в графической части (благодаря работе Cyril Brulebois).
Заключение
XCB существует более пяти лет, но заинтересовались им совсем немногие. Насколько я могу наблюдать, никто не заинтересован использовать протокол X, все просто стараются инкапсулировать его каким-нибудь высокоуровневым API, чтобы как можно быстрее перестать его видеть. Это приводит к появлению плохо написанных приложений и тулкитов, набитых уродливыми хаками.
Всё это также значит, что написание новых приложений и тулкитов на базе XCB должно быть очень интересным проектом, однако для этого придётся потратить чересчур много времени, чтобы понять, как обходить изъяны протокола X, внесённые за многие годы предшественниками, в том числе Qt и GTK+.
Главные тулкиты практически ничего не делают, чтобы выиграть за счёт возвращения к тёмным водам X. Думаю, большинство их разработчиков предпочитают работать над прелестными 3D эффектами, опирающихся на геолокацию, чем над переопределением лучшей основы для каждого.
В мире X слишком мало рабочей силы. Нехватка мэйнтейнеров X в Debian — простое следствие этой ситуации. Конечно, существуют очень компетентные и квалифицированные разработчики X, в чём легко можно убедиться, читая блоги на Planet Freedesktop (я не в счёт). К сожалению, их количества недостаточно для того, чтобы покрыть всю сферу деятельности X: устройства ввода, графические устройства, спецификации новых расширений протокола и так далее. Сервер X — достаточно поздняя разработка, и большинству разработчиков интереснее работать над ним, а не над самим протоколом. Это можно понять.
Мне интересно, куда мы придём со всем этим через несколько лет. К нынешнему времени я варюсь в котле под названием X уже 3 года, и чувствую, что рано или поздно все альтернативы KDE и GNOME вымрут. Время, когда Вы могли выбирать между дюжиной «современных» оконных менеджеров, прошло.
В конце концов, может быть, это простой дарвинизм в применении к компьютерному софту.
Примечание переводчика: автор этой статьи — французский программист Julien Danjou, разработчик оконного менеджера Awesome. Оригинал статьи расположен здесь.
источник
ВНИМАНИЕ !
Возможно что-то уже неактуально. Обращайте внимание на даты !
Эта статья опубликована 1 июля 2010-го года !
Прочитано 7832 раз и оставлено 1084 комментариев.
А на счет судьбы я не жалуюсь, по крайней мере покушать всегда есть чего в отличие питушни мазолеедной 
#1.