GNOME удалось добиться, казалось бы, невозможного: это самая ограниченная по возможностям и раздутая десктопная среда для Linux. Но это не просто случайность. Это результат высокомерия и дилетантства основных разработчиков, превративших архитектурные решения GNOME в шедевр хаоса. Чтобы лучше понять, что происходит, давайте проанализируем некоторые из примеров. Даже если ни один из них не затрагивает непосредственно вас, стоит понять modus operandi ведения проектов GNOME и то, как они вредят сообществу Linux.
Отображение статического текста на экране — одна из самых простых задач в программировании [1], но поскольку код в GNOME обычно сложнее, чем это требуется, что-то может вести себя непредсказуемым образом. Например, приложение Settings иногда не может отобразить версию GNOME. Об этой проблеме сообщали больше года назад, но её до сих пор не устранили [2]:
GNOME — пример плохой производительности. Settings не только медленно открываются, но и требуют долгого ожидания превью нескольких фоновых изображений при первой загрузке (Fedora 39) [см. примечание 1 в конце статьи]:
Сходите заварить себе кофе, пока GNOME загружает это простое диалоговое окно, и не забудьте зарядить ноутбук
Простое открытие папки с 40 изображениями в Files (nautilus) занимает 4,6 секунды на загрузку всех миниатюр, а в thunar (Xfce 4.18) те же миниатюры загружаются за 2,6 секунды. И это опыт просмотра локальных файлов на реальной машине (не VM):
При просмотре локальных файлов складывается ощущение, что работаешь с удалённым сервером
Ещё один пример плохой производительности — это mutter (композитор GNOME). При запуске в X11 каждое нажатие кнопки с другого устройства приводит к зависанию mutter примерно на 100 мс, что вызывает рывки, особенно заметные в требовательных к производительности приложениях наподобие игр. Отчёт о проблеме был отправлен пять лет назад [3], а merge request был принят, но затем его откатили из-за нежелательных побочных эффектов [4], так что issue по-прежнему открыта [см. примечания 2 и 3 в конце статьи].
Если в системе недоступен OpenGL 3.0, то GNOME работает в режиме программного рендеринга, а mutter полностью отключает все оконные анимации, что может быть проблематично, ведь юзабилити GNOME сильно зависит от его анимаций. Почему mutter не может откатиться к OpenGL 2.0 или даже к режиму CPU для обработки этих простых анимаций? Сложно поверить, что их анимации сложнее, чем в Quake 2 или Unreal Tournament — играх, работавших в программном рендеринге на CPU конца 90-х.
В Text Editor, появившемся в GNOME 42, при вводе ключевого слова во всплывающее окно поиска приложение сразу же скроллит вниз к ключевому слову в тексте, но если пользователь нажимает Escape, то приложение без каких-либо обоснованных причин возвращается к началу. Если открыть всплывающее окно поиска снова, то ключевое слово будет введено, но на этот раз для поиска слова в тексте нужно нажать Enter, а при нажатии Escape Text Editor просто закроет всплывающее окно поиска и не выполнит скроллинг. И никого не волнует, что никакой другой текстовый редактор с GUI не ведёт себя так же: GNOME всегда лучше знает, как надо.
Экран языка может не отображать ни одного языка, даже когда система имеет возможность переключаться между английским и множеством других языков. Я знаю об этом, потому что недавно создал для своего дистрибутива очень простое PyGTK-приложение, отображающее все доступные в системе языки, позволяя выбирать нужный пользователю. И оно просто работает. В KDE Plasma тоже есть удобный экран для этого, который тоже работает идеально. Но в той же самой системе экран языков в GNOME может отображать полный бардак:
Допустим, вы открываете Rhythmbox (аудиопроигрыватель GNOME) и хотите настроить громкость. Это ведь очень просто, правда? Увидев ползунок со значком динамика, можно предположить, что именно он вам и нужен, но нет. Этот ползунок используется для перематывания песни назад/вперёд, а не для настройки громкости.
Магазин приложений GNOME Software тоже полон сокровищ. При первом открытии большинство компонентов UI будет отсутствовать. А при попытке поиска вы не получите ни одного результата. Для загрузки UI требуется больше одной минуты даже при Интернет-соединении на 50 Мбит/с.
И подобные признаки дилетантства встречаются повсюду:
- в левом верхнем углу есть область доступа к Dash, находящемуся внизу;
- сессия GNOME начинается в режиме Overview, потому что разработчики решили, что так будет отображаться Dash;
- в десктопном режиме при нажатии горячих клавиш Super+A открывается Applications Overview, но нажатие на Escape не возвращает к десктопному режиму;
- пользователь не может понять, что свёрнуто или закрыто, пока не переключится в режим Overview, но даже в этом случае, если приложение настроено на перемещение в область уведомлений, оно больше не отображается, потому что у GNOME нет области уведомлений для сторонних приложений;
- открыв видеопроигрыватель mpv и нажав правой клавишей на Dash, пользователь увидит Quit 2 windows, хотя окно есть только одно;
- Files не обновляют информацию о размере файла, если операция выполнена сторонним приложением. Эта простейшая функция идеально работает в dolphin (KDE Plasma) и даже в thunar (Xfce) — проекте гораздо меньшего размера;
- так как GNOME не поддерживает протокол xdg-decoration при работе в Wayland [5], у некоторых приложений, например, у видеопроигрывателя mpv, не будет строки заголовка. В KDE такой проблемы нет;
- при работе в Wayland некоторым приложениям не удаётся рендерить простейшие вещи, например, аудиопроигрыватель Audacious не способен отрендерить встроенный 2D-анализатор спектра. В KDE же всё просто работает;
- Applications Overview отображает исключительно до 24 приложений на странице, вне зависимости от разрешения/масштабирования.
На самом деле, Applications Overview представляет собой полный хаос даже в последнем GNOME 45.2. Элементы приложения загадочным образом «сортируются», даже если машина простаивает и в фоновом режиме не работает ни одного приложения, и нельзя выбрать ничего удобного, например, отображения в алфавитном порядке или самых часто используемых.
Разгруппирование приложений на этом экране — одна из самых унылых задач, которые может выполнять пользователь. Но скука в GNOME — это хорошее чувство, потому что обычно пользователь чувствует раздражение: после разгруппирования нескольких приложений появляется стрелка, чтобы пользователь мог перейти к следующей странице, однако для перехода на предыдущую страницу стрелка не отображается. Разумеется, всё может быть и существенно хуже: после разгруппирования последнего элемента весь шелл GNOME обрушивается или им становится невозможно пользоваться:
GNOME сделал хорошую попытку превратить этот экран в апофеоз отстойности
Console была выпущена как официальное терминальное приложение, заменив Terminal в GNOME 42, но во многих популярных дистрибутивах она не используется, потому что не даёт никаких реальных преимуществ. Производительность по-прежнему низкая, а многие функции были удалены. Однако недавно разработчик GNOME решил оптимизировать библиотеку VTE, лежащую в основе этих терминальных приложений, и вместо того, чтобы обновить один из уже существующих терминалов, он создал третий под названием Prompt [6]. Да, теперь производительность рендеринга наконец-то великолепна, но только спустя много лет и ценой создания третьего терминального приложения.
Что-то похожее, но более драматичное произошло с Eye Of GNOME, которое в GNOME 45 было заменено новым приложением Image Viewer (Loupe). Вместо совершенствования существующего приложения разработчики снова решили создать новое с сомнительными улучшениями и множеством регрессий, включая снижение совместимости, забагованное изменение размеров окон, двоичные файлы гораздо большего размера, более чем вдвое увеличившееся потребление ОЗУ (для открытия статичного PNG размером 5 МБ требуется 800 МБ) и множество других проблем, показывающих, что приложение находится на стадии беты. После релиза GNOME 45 основная разработчица заявила, что из-за трений в команде она покидает проект [7]. Позже она передумала и вернулась в проект.
Команда GNOME и не пытается скрывать многократный выпуск ещё сырых проектов в каждом финальном релизе. Например, в GNOME 45 в стадии беты выпущены следующие приложения: Console, Contacts, Logs [8]. В GNOME 43 тоже было три приложения в стадии беты: adwaita-icon-theme, Logs, Orca. А Cheese вообще был выпущен в альфа-версии [9]. И это не какие-то редкие примеры. Во всех основных версиях GNOME присутствовало ПО явно в стадии альфы/беты.
Взаимодействие со сторонними разработчиками — ещё одна глава ужасов экосистемы GNOME. Например, есть требование, чтобы разработчики расширений указывали целевую версию шелла GNOME в metadata.json, в противном случае расширение не будет загружаться, даже если сам код не нужно менять после нового релиза GNOME. А поскольку расширения не интегрированы в менеджеры пакетов, при каждом обновлении GNOME все расширения перестают работать и требуют ручного обновления со стороны пользователя. По крайней мере, это безумие частично обратно совместимо, то есть расширения, обновлённые для работы в GNOME 44 также могут работать в GNOME версии 43 и ниже. Но никого не удивляет, что в 2023 году ситуация ухудшилась: разработчики GNOME решили внести в версию 45 изменение, заставляющее каждое расширение обновлять код и на этот раз обратная совместимость отсутствует [10]. Хуже того: они объявили об этом менее чем за месяц до выпуска GNOME 45.
Похожие примеры можно приводить бесконечно:
- долгие годы Document Viewer (evince) имел в качестве зависимости среды исполнения adwaita-icon-theme и отказывался собираться (!) в случае отсутствия adwaita-icon-theme, хотя идеально работал, если в файле сборки meson удалить эту зависимость;
- GNOME отказывается работать в Wayland, если не может найти папку /tmp/.X11-unix;
- в Files и VTE прописана жёсткая привязка зависимости к папке /usr/local/include, в противном случае они не собираются, даже если дистрибутив использует другую структуру папок и всё остальное собирается нормально;
- начиная с GNOME 45 необходим xdg-deskop-portal-gnome, в противном случае не работает тёмная тема, хотя никаких ошибок или уведомлений не отображается;
- разработчики GNOME продолжают требовать последних версий большинства зависимостей, в противном случае проекты GNOME не собираются, хотя на самом деле эти версии необязательны;
- если побочный проект GNOME xdg-desktop-portal-gtk не запускается во время начальной загрузки, приложения могут работать неправильно [см. примечание 4 в конце статьи].
Кто-то может задаться вопросом: почему бы не перестать жаловаться на эти проблемы, а просто отправить отчёты разработчикам? Дело в том, что чаще всего их это не волнует и они могут очень агрессивно относиться к любого рода критике.
В 2023 году Фелипе Контрерас написал статью о высокомерии разработчиков GNOME [11]. В ней он рассказывает историю пользователя, сообщившего о баге в Terminal [12], на что разработчик GNOME просто ответил «Нет». Контрерас рассказывает и о том, что произошло с ним в 2011 году, когда он отправил отчёт о проблеме, касающейся поведения Alt+Tab: в ответ разработчик GNOME сказал ему, что бага нет, и только спустя почти десять лет они наконец решили устранить проблему.
В другой статье, тоже опубликованной в прошлом году, Контрерас рассказывает ещё более печальную историю об одной конкретной проблеме с VTE, демонстрирующую способ GNOME обращения с кодом и с людьми: этой проблемы не просто не должно было существовать; последующие попытки устранить её задействовали ужасные практики написания кода, которые на самом деле ничего не исправляли. Кульминацией стал отказ использования работающего решения Контрераса и блокировка отчёта о проблеме [13]. В конце статьи он сравнивает отношение разработчиков GNOME и разработчиков ядра Linux, показывая, что, несмотря на гораздо больший размер команды ядра, они гораздо сильнее озабочены воздействием своей работы и достаточно скромны, чтобы откатить любой код, имеющий негативное побочное влияние на сторонние проекты.
Я и сам столкнулся с подобной историей. При выпуске xdg-desktop-portal 1.7.1 в нём появился баг: при запуске любого приложения под рутом не работала тёмная тема в версиях GNOME от 45 и выше. Я сообщил об этой проблеме [14], но разработчиков больше интересовало игнорирование описанного мной сценария использования, чем признание регрессии бага. Как обычно, они закрыли issue, не устранив её, а когда я начал говорить об их странном поведении, они пометили мой комментарий как злоупотребление, чётко дав понять, что хотят закончить обсуждение; поэтому теперь чтобы прочитать его, нужно выполнить вход [см. примечание 5 в конце статьи]:
В GNOME 45 приложение Files было выпущено таким образом, что в режиме рута/админа диалоговое окно свойств файла/папки не открывалось и вместо этого постоянно вызывало вылет всего приложения. Со временем проблему устранили в GNOME 45.1, но когда я сообщил о ней [15], первой реакцией были обычные отписки GNOME:
В GNOME 42 в проекте adwaita-icon-theme удалились все значки сторонних приложений и остались значки только приложений GNOME. Когда пользователь сообщил об этом побочном эффекте, реакция разработчика оказалась вполне предсказуемой [16]:
Приложения должны иметь в комплекте собственные значки.
Но и это ещё не всё: разработчик сразу же закрыл issue, а его сообщение залайкали другие разработчики. Эти ребята, наверно, забыли, что в Linux невозможно установить больше одной темы значков, а поскольку бесконечное количество приложений использовало для отображения значков тему значков, в результате снова получился полный хаос [17].
Двадцатилетний баг в Archive Manager (file-roller) позволяет ему хранить временные файлы в папке ~/.cache неограниченно [18]. Пользователи писали отчёты, что общий размер может превзойти 100 ГБ. О проблеме сообщили год назад, но её так и не устранили. О ней говорил Броди Робертсон, стоит посмотреть видео и почитать некоторые из комментариев [19]:
Из всех этих примеров можно понять, что GNOME не хватает правильных автоматизированных тестов и что его разработчики слишком высокомерны, чтобы заботиться о базовых функциях, прежде чем выпускать новый релиз. Если прочитать вместе все changelog GNOME 45.x [20], то слово «crash» встречается там 32 раза, и это только то, что они озаботились исправить. Но щупальца GNOME могут простираться ещё дальше.
Когда они выпустили libxml 2.12.2, она была настолько поломана, что всё зависящее от неё не собиралось из-за отсутствующих заголовков. В том числе и больше четырёхсот приложений, не имеющих никакой связи с десктопным окружением GNOME, такие как Chromium, FFmpeg, VLC, Wayland, Xfce [23]. Неделю спустя была выпущена новая версия, устраняющая баг [22].
Пять лет назад была открыта issue о том, что mutter в Wayland не позволяет приложениям отключить скринсейвер, из-за чего, например, смотреть фильм становилось невозможно [23]. В исправлении была реализована поддержка популярного протокола Wayland, которая на то время уже была реализована в KDE и Sway.Только четыре месяца спустя GNOME наконец решил проблему, но не без постыдных обсуждений, в которых разработчики GNOME пытались искажать логику:
Похоже, большинство людей или не смотрит на десктопах длинные фильмы, или им не мешает баг.
В одном из обсуждений этой проблемы на Reddit разработчик Sway и многих протоколов Wayland Дрю Деволт опубликовал сильные выражения, направленные против GNOME [24]:
В марте прошлого года GNOME выпустил Glib 2.76, добавив проблему, повлиявшую на множество сторонних приложений, которые даже не должны были запускаться в GNOME [25]. Последствия были настолько серьёзными, что в Glib 2.76.1, выпущенной две недели спустя, разработчикам пришлось откатить изменения [26]. Однако всё было не так просто: они пообещали, что это изменение вернётся в Glib 2.78, и спустя полгода так и произошло.
Проблема создаёт потенциально бесконечные записи в лог из-за нового уведомления среды исполнения GFileInfo. В результате этот пришлось патчить GTK+3 и множество других сторонних приложений, использовавших GFileInfo, например, thunar (Xfce). Ошибка повлияла и на GTK+2, но отвечающая за него команда GNOME заявила, что не будет тратить две минуты на её устранение, потому что срок поддержки после завершения срока службы GTK+2 уже истёк.
Я решил написать патчи самостоятельно, выложив их на страницу с issue Gitlab разработчиков [27], но они не захотели возиться и мерджить их в репозиторий, снова показав равнодушие ко всему, не относящемся к их сценариям использования. Они думают, что им виднее, но на этот раз они поломали одно из самых популярных приложений — GIMP, который до сих пор использует GTK+2. Я предложил свои патчи разработчикам GIMP, не требуя указания авторства, и, к счастью, они их приняли [28].
И таких примеров бесчисленное множество: пользователь сообщает, что в GTK 4 по сравнению с GTK+3 шрифты более размытые, и публикует скриншоты, чётко демонстрирующие проблему, но разработчик закрывает issue, заявив, что это не регрессия, хотя большинство людей говорит обратное [29]; пользователь сообщает, что Archive Manager при работе в Wayland не позволяет выполнять перетаскивание в Files, но разработчик блокирует issue, которая спустя пять лет по-прежнему не устранена [30]; пользователь открывает запрос опережающего поиска с клавиатуры, чтобы заменить безумный рекурсивный поиск в Files, и хотя большинство пользователей согласно с запросом, его закрывают, и спустя пять лет проблему так и не решили [31]:
В мире Linux GNOME занимает огромное место, и его код в основном пишется не волонтёрами, как думают многие, а оплачиваемыми сотрудниками из других компаний, особенно из Red Hat. GNOME Foundation — это компания, имеющая ежегодный бюджет (недавно она получила 1 миллион евро), у неё есть директора, менеджеры, дедлайны и так далее [32]. За ней стоят крупные игроки, такие как Red Hat, Canonical, IBM и даже Google.
Это стандартная десктопная среда во многих популярных дистрибутивах и даже если вы не используете её, вероятнее всего, в вашей системе всё равно есть проекты GNOME. И это самый пугающий аспект GNOME: это не просто десктопная среда, но и целая экосистема, части которой разбросаны по всем дистрибутивам Linux.
Я уверен, что в GNOME работают и хорошие люди, и что не стоит ожидать от каждого человека в этом проекте идеальности. Проблема здесь в масштабе, в объёме власти в руках нескольких высокомерных дилетантов, работающих в порочной организации, которая в целом мотивирует не к диалогу, а к авторитарным плохим решениям, приводящим к очень неполноценному ПО.
Нет ничего удивительного в том, что у дистрибутива Linux Mint есть собственный форк десктопной среды GNOME под названием Cinnamon. MATE — это тоже форк GNOME. Можно также вспомнить Unity — ещё один форк GNOME, созданный Canonical. Много лет назад десктопная среда LXDE отказалась от GTK и мигрировала на Qt, породив LXQt. Дистрибутив Pop!_OS заменяет GNOME собственной десктопной средой COSMIC. Разработчики десктопной среды Budgie заявили, что отказываются от GTK в пользу ещё не названного тулкита из-за сильного разочарования в GNOME [33]. Даже Valve решила выбрать KDE Plasma вместо GNOME при выпуске SteamOS 3.0 для своей портативной консоли Steam Deck.
Есть множество признаков того, что наиболее разумно будет максимально избегать проектов GNOME, особенно десктопную среду. Так что не используйте её и не рекомендуйте. К счастью, есть много гораздо лучших альтернатив, например, Xfce, LXQt и, если вам нужно что-то более изысканное, KDE или даже Cinnamon. И я действительно считаю, что они лучше в абсолютно всех смыслах.
[1] Стоит отметить, что до недавнего времени Settings всегда открывались в той части экрана, где вы оставили их в прошлый раз, и лишь потом переключались на запрошенную. Это многое говорит о качестве кода GNOME.
[2] Wayland совершенно точно будет преобладать над X11, но пока его общая производительность по-прежнему несравнима с X11, особенно при работе с картами Nvidia, не говоря уже о бесчисленных проблемах и неудобствах. Поэтому не следует ожидать, что Wayland будет работать во всех ситуациях (https://www.phoronix.com/review/wayland-nv-amd-2023/).
[3] Производительность mutter и шелла GNOME может настолько раздражать, что в дистрибутиве Arch есть скрипты сборки, применяющие патчи, не одобренные upstream (https://aur.archlinux.org/packages/mutter-performance) (https://aur.archlinux.org/packages/gnome-shell-performance).
[4] Например, пользователь выполняет первоначальную загрузку без установленного xdg-desktop-portal-gtk, открывает любой браузер, устанавливает xdg-desktop-portal-gtk и открывает flatpak-версию Boxes (виртуальной машины GNOME). Если затем пользователь пытается создать новую виртуальную машину из ISO, диалоговое окно выбора файла не отображается, требуя завершения процесса xdg-desktop-portal (без gtk!). Это энтропия чистой воды.
[5] По моему сообщению можно понять, что я вёл себя очень уважительно.
Скриншот
Скидки, итоги розыгрышей и новости о спутнике RUVDS — в нашем Telegram-канале 🚀
