LINUX.ORG.RU

Linux Mint отказывается от libAdwaita и призывает остальных присоединиться к ним

 , ,


2

4

Разработчики Linux Mint в своем ежемесячном дайджесте новостей рассказали о ходе разработки Linux Mint 22 и, в том числе, поделились своим видением ситуации, связанной с развитием GNOME и приложений, разрабатываемых в рамках него.

В 2016 году разработчиками Linux Mint был запущен проект под названием XApps, направленный на создание универсальных приложений для традиционных настольных сред на базе GTK для замены базовых приложений GNOME. В их числе Xreader (форк Atrill, который, в свою очередь, форк Evince), Xplayer (форк Totem), Xviewer (форк Eye of Gnome) и другие. Более подробно о проекте можно узнать на их сайте.

В дайджесте заявляется, что разработчики планируют расширять список приложений, входящих в проект XApps, и призывают остальных присоединиться к работе над проектом. В первую очередь они обращаются к разработчикам Mate и XFCE, которые заинтересованы в развитии приложений, независимых от проекта GNOME, а также разработчиков дистрибутивов, которые в качестве своей базовой среды их используют. Почему-то упоминается в основном Xubuntu.

Причиной такого заявления, как и причиной создания проекта XApps, является все большее расхождение между разработчиками GNOME и остальными в понимании того, как должен строиться интерфейс пользовательских программ, и использование проектом GNOME библиотеки libAdwaita, которая является основой для построения интерфейсов в большинстве приложений в современном GNOME. По мнению разработчиков Linux Mint, указанная библиотека создавалась только для GNOME, и приложения GNOME все меньше и меньше подходят для работы где-либо еще, кроме самого GNOME.

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

По причинам такой несовместимости в будущем Linux Mint 22 был удален GNOME Font Viewer, а некоторые из программ были понижены до версии на GTK3, в частности:

  • Celluloid;
  • GNOME Calculator;
  • Simple Scan;
  • Baobab;
  • System Monitor;
  • GNOME Calendar;
  • File Roller;
  • Zenity.

От Zenity разработчики вообще планируют отказаться, а остальные развивать в виде форков.

Кроме этого, разработчики Mint считают нецелесообразным идти по пути Ubuntu, которая модифицирует библиотеку libAdwaita под свои темы оформления, потому тема Adwaita будет удалена из списка доступных в Cinnamon 6.2.

Разработчики считают, что проект XApps может решить проблему и заявляют для него в качестве основного принципа независимость от дистрибутива и окружения рабочего стола, будь то Cinnamon, XFCE, Mate или иной другой. XApps, по их мнению, должен быть отдельным проектом со своими репозиториями на GitHub, чатом, веб-сайтом, управлением и т. д.

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

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 3)

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

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

Исправил.

Не, пересобирать особо ничо не надо. У тебя есть версия nixpkgs, внутри неё только одна версия каждый либы, кроме исключений для каких-то особенных пакетов.

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

То есть, если я увижу на моём экране лысеющего жирного задрота лет 40, пускающего слюну…

Ты сейчас описал среднестатистического разработчика, что не так-то? Мем про размер футболок на конференциях помнишь?

https://ibb.co/HBzWgNx

Вот этот? Да, хорошо чуваки качаются. Но я не понимаю, как это к типичному юзеру флатпака относится.

то это как-то поможет мне на него влиять? Странная идея.

Странная идея оценивать профессиональные качества людей по внешности.

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

А если чувак просто мудак и косячит?

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

Всем насрать. Никто не будет писать мейнтейнеру. Вон все знают, что мейнтейнеры рача мудаки и косячат постоянно, их имена есть в публичном доступе. Но рачем все пользуются. А флатпаком – нет.

Подавляющее большинство опенсорсного софта пишется вот ровно так вот: для себя и друзей. А пользователи – они просто так, хорошо если багрепорт напишут.

Всё так. Но если есть угроза того, что Linux для некорпоративных пользователей вот-вот превратится в рак жопы, неужели это не стоит того, чтобы хоть немного пошевелиться? Ну ты ж сам говорил, что Flathub будет хуже Google Play.

В основном эта угроза как раз из-за корпоратов и существует. После того, как GNOME стал разрабатываться в основном Red Hat, этот гнум превратился в полное говно.

У тебя и без всякого Flatpak в системе полно кода, написанного в Red Hat. Спишь-то хоть нормально, кошмары не снятся?

Снятся. Каждую ночь! Про то, как злобный systemd вылезет из под кровати и откусит мне жопу!

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

С таким подходом и флатпак залетит на ура. Не понимаю твоего недовольства.

Моё недовольство флатпаком состоит в том, что в него пакуют в основном через жопу и в пакеты там включается много ненужного. За каким хером, например, вместе с VSCode идёт отдельная копия git? Для чего? Почему нельзя использовать системный git?

А вот с таким — Пропатченный GVFS — придётся пересобрать весь гуёвый юзерленд.

Ну, есть такое. Поменял зависимость, добавив патч – пересобирай всё что от неё зависит. Минусы полной воспроизводимости сборок.

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

Ну а что меня ещё может волновать? Неспособость тулкита работать с 3,8К так, как будто это HD? У меня нет комплексов по поводу наличия пикселей.

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

Ну, есть такое. Поменял зависимость, добавив патч – пересобирай всё что от неё зависит. Минусы полной воспроизводимости сборок.

Это не воспроизводимые сборки, а костыли.

Сборка someshit_app никак не зависит от полного бинарного содержимого libgovno.so.1, максимум – только от списка содержащихся там символов.

Сначала сделайте нормальный тулинг.

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

В общем, я еще не настолько просветлится, чтобы пересобирать фирефокс, хромого, либреоффис и всё kde ради условного патча на нейминг томов.

И 128-ядерного CPU в комплекте с хранилищем на 20 ТБ у меня нет.

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

Ну, есть такое. Поменял зависимость, добавив патч – пересобирай всё что от неё зависит. Минусы полной воспроизводимости сборок.

Это не воспроизводимые сборки, а костыли.

Какой лялекс, такие и сборки :(

Сборка someshit_app никак не зависит от полного бинарного содержимого libgovno.so.1, максимум – только от списка содержащихся там символов.

Да нет, ещё от заголовочных файлов и прочего говна. На самом деле, там вагон нюансов может быть. Чтобы это всё исправить, придётся всю сишную и около экосистему перепердолировать. Иначе никак. Как раз нужна твоя любимая тема с объектной системой вместо сошек, да. И с нормальными протоколами для API вместо заголовочных файлов.

Сначала сделайте нормальный тулинг.

Это уже не к Nix, это к гнутым и прочим чувакам. Nix тут извивается как может, ничего не поделаешь.

В общем, я еще не настолько просветлится, чтобы пересобирать фирефокс, хромого, либреоффис и всё kde ради условного патча на нейминг томов.

лмао…

Ну да, есть такая проблема. Кстати, KDE и Firefox собираются быстро, если вспомнить моё гентушное прошлое. А про libreoffice и хромог – мрак и жуть.

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

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

От хидеров – это само собой.

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

)) Какой лялекс, такие и сборки

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

Дистрибутив только вышел. Мейтейнеры еще не протрезвели. Что ты будешь ставить? Поставь к примеру на свежую убунту VestaCP

И чем мне в этом snap поможет? Мы вроде как deb-пакеты в репозиториях со snap сравнивали.

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

Ну вот установил я kdenlive как «нативно», так и с flathub. Версия одна и та же. Между измерениями выполнялась перезагрузка. Будучи приложением KDE, оно демонстрирует пример большого числа загруженных в память библиотек, включая упомянутые вами из состава Qt. Разница в потреблении памяти — 9%.

Ну отлично, ты доказал мои слова лучше меня. Просто представь что таких приложений будет не 1 а к примеру 50. И умножь разницу в 50 раз.

А сто́ит загрузить в него данные, и доля этих «лишних» библиотек упадёт до района нуля.

Слушай, ну если так рассуждать то объем потребления памяти и приложениями и системой в целом вообще не имеет значения - какая разница потребляет моя система на старте 450 Мб как сейчас или 4,5 Гб, ведь если я загружу в оперативную память 120 Гб данных то разница упадет до как ты выразился «района нуля». Формально ты прав конечно, при таком сценарии использования многократного увеличения конечно не будет.

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

Просто представь что таких приложений будет не 1 а к примеру 50. И умножь разницу в 50 раз.

Внезапно, если для каждого приложения увеличение потребления памяти будет 9%, то суммарное увеличение потребления памяти 50 приложениями будет… 9%.

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

суммарное увеличение потребления памяти 50 приложениями будет… 9%

То есть вместо 36 Гб суммарное потребление будет уже почти все 40 Гб. На ровном месте 4 Гб памяти теряется.

В 4 Гб целая небольшая электронная билиотека поместиться может. Или 2-3 полнометражных фильма в качестве Full HD.

sanyodesu
()
Последнее исправление: sanyodesu (всего исправлений: 3)
Ответ на: комментарий от Rootlexx

Внезапно, если для каждого приложения увеличение потребления памяти будет 9%, то суммарное увеличение потребления памяти 50 приложениями будет… 9%.

Нет, не будет. Потому что выше ты сам предлагал измерять «разницу потребления оперативной памяти системой». Т.е. операционной системой в целом а не отдельным приложением, правильно? Или ты отдельные приложения системой начал называть? Чтобы освежить тебе память привожу дословно:

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

Если по твоим же словам разница потребления памяти системой после установки одного приложения составила 9% то с увеличением числа приложений установленных из flatpack как она может остаться неизменной?

Ну или постарайся точнее объяснить что именно и как ты измерял.

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

То есть вместо 36 Гб суммарное потребление будет уже почти все 40 Гб. На ровном месте 4 Гб памяти теряется.

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

По факту же имеем запуск приложений без загруженных данных на 36 ГБ ОЗУ — если эти лишние 4 ГБ будут иметь сколь-нибудь заметное значение для вашей системы, то это будет означать, что у вас даже близко не достаточно ОЗУ для реальной работы в данных приложениях (даже установленных с помощью «родного» менеджера пакетов!), ибо рост потребления памяти после загрузки рабочих данных многократно превысит эти 9%/4 ГБ.

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

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

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

Т.е. операционной системой в целом а не отдельным приложением, правильно?

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

Если по твоим же словам разница потребления памяти системой после установки одного приложения составила 9% то с увеличением числа приложений установленных из flatpack как она может остаться неизменной?

Разница потребления всей системой нужна, чтобы получить оценку потребления памяти приложением; 9% относилось уже к потреблению приложением, а не всей системой, т.е.:

(flatpak_after - flatpak_before) / (native_after - native_before) ~= 1,09

Ну и ещё раз повторю, что 9% — это аж целый kdenlive, загружающий прорву библиотек KDE, и запущенный при этом в KDE, как экстремальный пример. Если же приложение имеет меньше зависимостей, то и увеличение потребления будет меньше. А если тот же kdenlive запустить в каком-нибудь Xfce, где весь этот ворох библиотек KDE будет загружен с нуля что в случае «родных» пакетов, что в случае flatpak, то и разница будет вообще исчезающе мала.

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

Т.е. операционной системой в целом а не отдельным приложением, правильно?

Да

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

А если тот же kdenlive запустить в каком-нибудь Xfce, где весь этот ворох библиотек KDE будет загружен с нуля что в случае «родных» пакетов, что в случае flatpak, то и разница будет вообще исчезающе мала

Ты не перестаешь меня удивлять. Простой факт что библиотеки KDE после установки традиционным способом из репозитория будут разделяемыми и каждое последующее приложение устанавливаемое таким способом просто будет их использовать не увеличивая потребления памяти так труден для твоего понимания? В отличие от snap где каждое последующее приложение будет увеличивать этот объем на те же условные 9%, неужели это может быть непонятно? А теперь представь что таких приложений 50. Ну что не так то, ну? Понятно что их может и не быть 50, ну так и увеличения тогда не будет. Потому что нет snap - нет перерасхода памяти, что и требовалось доказать. С чем ты пытаешься спорить мне непонятно.

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

На этом дискуссию можно закончить

Не надо, многие только за ними на ЛОР и заходят.

Могу накинуть для продолжения: libadwaita - продукт скам-конторы purism.

t3n3t
()
Последнее исправление: t3n3t (всего исправлений: 1)

Разработчики Linux Mint в своем ежемесячном дайджесте новостей рассказали о ходе разработки Linux Mint 22 и, в том числе, поделились своим видением ситуации, связанной с развитием GNOME и приложений, разрабатываемых в рамках него.

Они, как всегда, брешут. Помниться, когда-то они писали, что отделились от гнома и теперь не зависят. Продолжая паразитировать при этом.

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

Я считаю, что они пытаются въехать на чужом горбу, потому как сами они не потянут свои хаппсы. Они уже опкакались на гтк4, хотя казалось бы.

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

я не понимаю что дальше обсуждать и что именно ты еще пытаешься доказать.

Это заметно, что вы не понимаете.

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

Конечно! Настолько труден, что я как раз выбрал такой принцип измерения потребления памяти приложением, чтобы учесть это разделение библиотек. /s

В отличие от snap где каждое последующее приложение будет увеличивать этот объем на те же условные 9%, неужели это может быть непонятно?

При чём здесь вообще snap? Прекращайте вольно жонглировать темами.

Речь шла, вообще-то, о flatpak. У которого, внезапно, есть runtime. И я уже об этом писал:

(Не говоря уже о том, что в случае того же flatpak значительная часть программ из того же KDE будет использовать один и тот же runtime от KDE, с одними и теми же библиотеками.)

Rootlexx ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)