LINUX.ORG.RU

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

 , ,


2

3

Разработчики 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)
Ответ на: комментарий от torch

Я говорю только про Snap, Flatpak и, возможно, Appimage. Ты говоришь так, как будто собеседуемых будут тысячи.

Не очень понимаю, почему ты смешал Snap+Flatpak и Appimage в одну кучу. У Appimage нет репозитария, это просто исполняемые файлики.

И, опять же, не понимаю, в чём принципиальное различие между Flatpak/Snap и репозитарием какого-нибудь популярного дистра типа Arch. В Arch не бывает мудаков-мейнтейнеров? Ещё как бывают, я лично в этом убеждался.

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

Нуууу… тогда зачем мне кого-то собеседовать, если сделать я всё равно ничего не могу? Тем более по видеосвязи-то!

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

Не очень понимаю, почему ты смешал Snap+Flatpak и Appimage в одну кучу. У Appimage нет репозитария, это просто исполняемые файлики.

Это популярный формат, есть Appimagehub, хз, мне показалось, что логично его тоже учитывать.

Нуууу… тогда зачем мне кого-то собеседовать, если сделать я всё равно ничего не могу?

Собеседовать, если это слово тут вообще уместно, можно того, кто сам тебе написал из этических соображений и спросил, не против ли ты, если твой софт будет собран и выложен на таких-то площадках. Очевидно, если кто-то без спроса выкладывает твой софт, и не собирается с тобой коммуницировать, всё что ты можешь сделать, не меняя лицензию, это предупредить об этом пользователя. ИМХО, это лучше, чем ничего. Выше по треду я приводил пример с Chrome, у которого в Flathub висит предупреждение, что это не оригинальный пакет от Google.

Тем более по видеосвязи-то!

Я объяснял, почему считаю, что нужна именно видеосвязь. На второй круг не пойду.

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

И, опять же, не понимаю, в чём принципиальное различие между Flatpak/Snap и репозитарием какого-нибудь популярного дистра типа Arch. В Arch не бывает мудаков-мейнтейнеров? Ещё как бывают, я лично в этом убеждался.

Собранный пакет под Арч, работает только на Арче. Хочешь под Деб пакет. Пакуй под деб. Но учти, что дебов есть пару десятков, если хочешь максимальный охват. Но не забудь, еще есть РПМ. Там тоже пару десятков пакетов создай под разные дистрибутивы и версии их. Ну еще можешь выложить исходный код. Но и тут не просто. Надо будет учитывать разные версии компиляторов и системных либ. И это не всё, если начать писать все геморойные нюансы, размера поля комментария не хватит.

А можешь создать три пакета Снап, Флатпак, Аппимадж. И охватить сразу 90% дистрибутивов.

А еще ты уберешь посредника злоумышленика.

Но это слишком не очевидно же.

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

Собранный пакет под Арч, работает только на Арче. Хочешь под Деб пакет. Пакуй под деб. Но учти, что дебов есть пару десятков, если хочешь максимальный охват. Но не забудь, еще есть РПМ. Там тоже пару десятков пакетов создай под разные дистрибутивы и версии их.

А можешь создать три пакета Снап, Флатпак, Аппимадж. И охватить сразу 90% дистрибутивов.

Так то да, но объем занимаемой памяти на дисках и оперативной увеличится многократно. Все зависимости же потянутся в этих твоих снапах и флатпаках. Другими словами одно из немногих преимуществ линукса исчезает, что дает взамен… что именно? Можешь назвать хотя бы одну причину зачем это нужно вот лично мне например? То что пакеты собираются под 115 дистрибутивов мне вообще без разницы, не я же их собираю и не я за это плачу.

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

Собранный пакет под Арч, работает только на Арче. Хочешь под Деб пакет. Пакуй под деб.

А зачем пакет, разве .tar.gz недостаточно? У меня так 25% софта стоит, мелкие утилиты типа dmde, realesrgan-ncnn-vulkan, soundwire и тд

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

Так то да, но объем занимаемой памяти на дисках и оперативной увеличится многократно.

Так то да. Места занимает больше, согласен. Но в эпоху, когда 1ТБ диск стоит копейки, этот минус можно игнорировать.

Все зависимости же потянутся в этих твоих снапах и флатпаках. Другими словами одно из немногих преимуществ линукса исчезает, чтобы дает взамен что именно?

Это преимущество Линукса было преимуществом в 90-х. Сейчас это уже минус. Так как понятие библиотечный ад, не просто так родился. А еще с годами появилась проблема, что старый софт не работает на новых дистрибутивах, так как нет зависимостей в живых. Софт сам по себе то совместим, только библиотеку нужную найди и поставь. Но ее нет уже. Или если ее поставить, то система поломается. А чтобы не поломалась, тебе нужно выполнить инструкцию с гугла, портянку на две страницы.

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

Можешь назвать хотя бы одну причину зачем это нужно вот лично мне например?

Обратная совместимость и совместимость с другими дистрибутивами. Этого мало? Ты ни разу не сталкивался с проблемами, что твой любимый софт работает на одном дистрибутиве, а на другом его нет? Или когда есть пакет под старую версию дистрибутива. Но под новый нет. Ты ни разу не сталкивался с проблемой, что после обновления дистрибутива, у тебя с пару месяцев нет родных пакетов. А некоторый софт умирает и больше никогда не возвращается?

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

То что пакеты собираются под 115 дистрибутивов мне вообще без разницы, не я же их собираю и не я за это плачу.

А вот и зря. Если про деньги, я согласен. Пофигу, что там и сколько тратит. Но, вот что мне не пофиг, так это безопасность. В текущих реалиях, что рпм с дебами, что снапы и флатпаки, часто собирают левые люди. (разрабам лень) И уже было не раз, что зловред попадался в репах. Причем, даже в официальных. Я бы хотел, чтобы посредник между софтом и магазином/репой умер как класс. Чтобы разработчик собирал свой пакет сам.

НО! Когда надо собрать 115 пакетов, я прекрасно понимаю, что редкий разраб это может себе позволить. Поэтому посредники будут. А вот если надо собрать 3/2/1 пакет(а), то уже можно ожидать, что этим займется лично разраб. Так как считаю, что это в первую очередь выгодно самому разрабу.

А учитывая, что еще помимо безопасности, мы получаем совместимость с обратной совместимостью, то тут больше плюсов, чем минусов.

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

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

И расплачиваться за это адским ужором ресурсов и тормозами? Ну сам себе злобный буратин.

То что это удобно для корпораций где надо тупо поставить 1-2 приложения каждому хомячку на тонкого клиента и более ничего не надо - то тут не поспоришь. Но зачем для этого узкоспециального кейса весь *nix уродовать?

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

объем занимаемой памяти на дисках и оперативной увеличится многократно

Што? Если про диски вопрос ещё можно считать дискуссионным, то каким образом объём занимаемой оперативной памяти увеличится аж многократно? Если что, размер кода самих библиотек, разные версии которых будут в памяти, ничтожно мал в сравнении с тем, что среднестатистическая программа выделяет в куче.

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

И расплачиваться за это адским ужором ресурсов и тормозами? Ну сам себе злобный буратин.

Игнорирование плюсов и оправдываемся мелкими неудобствами. А то и враньем. Про тормоза это вранье. А вот правда. Есть некоторый софт, который работает чуть хуже. Но эти проблемы решаются и будут решены.

А про адский ужор ресурсов, это просто смех. Обнови комп наконецто. Это просто уже стыдно писать. Даже на древних компах с 8ГБ памяти и с 1ТБ диском, этот ужор будет незаметен, чуть больше, чем полностью. Но если у тебя диск 4ГБ, а памяти 64МБ, то конечно, тут спору нет. Тебе лучше из исходников собирать ахаха

То что это удобно для корпораций где надо тупо поставить 1-2 приложения каждому хомячку на тонкого клиента и более ничего не надо - то тут не поспоришь. Но зачем для этого узкоспециального кейса весь *nix уродовать?

Ну то что большинство линуксятников оторваны от реальности, я всегда знал. Ты меня не удивил. Это удобно корпорациям, ставить софт легко и просто. Ахахахаха Правильно, правильному пользователю не удобно легко и просто ставить софт, он хочет собирать всё из исходников! Ждать месяцами нужные релизы. Это мечта прям)))

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

Не могу согласиться, если каждая утилита или приложение будет тянуть с собой например свою версию Qt то объем занимаемой памяти вполне может увеличиться многократно.

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

Не могу согласиться, если каждая утилита или приложение будет тянуть с собой например свою версию Qt то объем занимаемой памяти вполне может увеличиться многократно.

Хотелось бы увидеть подтверждение этого вне спецслучаев, поскольку механизм аж кратного роста потребления памяти в общем случае непонятен.

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

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

Не могу согласиться, если каждая утилита или приложение будет тянуть с собой например свою версию Qt то объем занимаемой памяти вполне может увеличиться многократно.

Насколько? На 10% на 20% Или может столько же, сколько и у обычной софтины из сырцом? Но ты кстати поднял хорошую тему и проблему реальную. такие вещи как Кюте или другие мейнстримовые библиотеки могли бы идти в пакетах отдельно. Чтобы ими пользовались другие программы. Это бы не полностью решило проблему, но уменьшило негатив.

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

совместимость с другими дистрибутивами

А зачем? Ну предположим deb-пакет из репозитория моего дистрибутива несовместим с другими дистрибутивами, и что? Мне лично зачем чтобы он был совместим с другими дистрибутивами? А тебе зачем?

Я бы хотел, чтобы посредник между софтом и магазином/репой умер как класс. Чтобы разработчик собирал свой пакет сам.

Как ты узнаешь что разработчик сам собирал snap который ты скачиваешь в snapstore? Добавить в store значок «мамой клянусь»? И применительно к реальным приложениям, там же разработчиков десятки и сотни. Кто из них должен собирать, им на спичках тянуть?

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

собирать всё из исходников! Ждать месяцами нужные релизы.

вы уж батенька определитесь - или кретик снимите или трусы оденьте. Собирать все из исходников или таки ждать месяцами нужные релизы?

Даже на древних компах с 8ГБ памяти

8Гб это не древние компы а дохрена производимых ныне ноутов. В том числе и для корпоративного сектора. на моем конторском как раз те самые 8 гиг а ссд 128Гб - 1Тб это для корпоративного ноута излишний жыр.

Ужор будет заметен если у тебя открыто дохрена этих флэтпаков говенных с разными версиями библиотек. Пока ты накатил на убунту один флатпак а все остальное поставлено по людски - ужора не будет.А вот как только каждая говноутилитка будет тянуть за собой собствнный дистр библиотек - вот тут то никаких гигабайт не хватит.

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

А зачем? Ну предположим deb-пакет из репозитория моего дистрибутива несовместим с другими дистрибутивами, и что? Мне лично зачем чтобы он был совместим с другими дистрибутивами? А тебе зачем?

Выбор? Сегодня я дома ставлю Убунта, а после завтра на работе Федору. Разве это плохо иметь возможность ставить софт не оглядываясь на дистрибутив? Просто ситуация смешная выходит. Вроде Линукс везде один. Ядро одно. Библиотеки практически одни. и тп. Но каждый дистрибутив это отдельный мир, который оооооочень слабо пересекается с другими дистрибутивами. У винды даже с этим лучше. Софт под винду 7, отлично работает на 11. И также всё в обратную сторону. КАК ТАК? Получается, на винде есть выбор, а на линуксе нет?

Как ты узнаешь что разработчик сам собирал snap который ты скачиваешь в snapstore?

Верифицированный аккаунт в магазине? Ссылка на сайте на официальную страницу в магазине с верифицированным аккаунтом? Мне бы этого хватило. Мейнтейнера нет и слава богу. Все довольны. Разраб сделал программу и распространил везде. Слава богу и хвала Торвальдсу)

Кто из них должен собирать, им на спичках тянуть?

Вопрос вообще не понимаю. Есть команда разработчиков, которая разрабатывает софт. Вот один из тех, кто самый компетентный и собирает. Главное, чтобы это было официальное лицо. Чтобы когда будет факап с его стороны, можно было когото наказать. Даже в опенсорсе есть человек, который отвечает за сшивание веток разработок в гите. В чем проблема собрать пакет? Кстати собирание пакета можно автоматизировать, легко и просто. Это может сделать любой член команды.

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

Вопрос вообще не понимаю. Есть команда разработчиков, которая разрабатывает софт. Вот один из тех, кто самый компетентный и собирает. Главное, чтобы это было официальное лицо.

Ахахахахахахах! Господи, ты похоже вообще не в теме.

Нет никаких команд разработчиков. Просто нету. У GNOME, например, активных разработчиков меньше десятка (с хотя бы десятком коммитов), а это один из самых жирных проектов, когда речь идёт о юзерспейсе и софте с гуем. Подавляющее большинство проектов – один, максимум два чувака, плюс небольшое сообщество вокруг них, из которого иногда приходят отдельные патчи.

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

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

Сегодня я дома ставлю Убунта, а после завтра на работе Федору. Разве это плохо иметь возможность ставить софт не оглядываясь на дистрибутив?

Ты не поверишь! Представь, оно сейчас так и есть! Не надо никуда оглядываться, открываешь в Ubuntu AppCenter (или как там его, я то Kubuntu использую) и просто ставишь любое приложение. И в Fedora точно так же открываешь и ставишь, и тоже никуда не нужно оглядываться. И так в любом дистрибутиве. Не благодари, рад был помочь.

Верифицированный аккаунт в магазине? Ссылка на сайте на официальную страницу в магазине с верифицированным аккаунтом? Мне бы этого хватило. Мейнтейнера нет и слава богу.

Гениально! И главное мейнтейнер без работы не останется, он будет верифицировать аакаунты. Шило на мыло, но зато все модно и молодежно))

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

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

Нет никаких причин использовать один и тот же runtime, если это требование не накладывает дистрибутив ОС.

А на прикладников, пакетирующих под дистрибутивы, именно дистрибутив это ограничение и накладывает.

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

Разве это плохо иметь возможность ставить софт не оглядываясь на дистрибутив?

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

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

На любом дистре можно развернуть пакет другого дистра. Но вопрос зачем это надо если все основное есть внутри самого дистра?

У винды даже с этим лучше. Софт под винду 7, отлично работает на 11

Потому что венда и ее СДК это продукт компании микрософт.А линукс - это сборная солянка из вагона разных источников. С разными наборами библиотек, системами инициализации, дисплейным сервером.

Софт под винду 7, отлично работает на 11. И также всё в обратную сторону.

А вот врать нехорошо. В обратную сторону работает не все. Да и в прямую не все. Хотя то что совместимость на порядок лучше бесспорно.

Верифицированный аккаунт в магазине? Ссылка на сайте на официальную страницу в магазине с верифицированным аккаунтом? Мне бы этого хватило

Ну с тобой все ясно. Хакеры, налетайте - лошку достаточно верифицированного васянского аккауна в васянском снап-флатпак-сторе. Венда - это микрософт, адроид - гугл, эппл сам себе эппл. Компании с мировым именем и уровнем доверия. А тут нам главное флатпак - похрен от кого на любой дистр.

Вот один из тех, кто самый компетентный и собирает. Главное, чтобы это было официальное лицо. Чтобы когда будет факап с его стороны, можно было когото наказать.

Тебе кто-то чтото за беспатно должен а ты еще и наказывать собрался? Наказывалка то выросла? Да еще и самый компетентный вместо того чтобы рулить разработкой должен для дурачка не осилившего инсталляцю пакетов флатпаки собирать под угрозой наказания? Вот сдался ты им. Иди венду юзай. И попробуй накажи Билли когда очередной апдейт окирпичит тебе комп.

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

Хотелось бы увидеть подтверждение этого вне спецслучаев, поскольку механизм аж кратного роста потребления памяти в общем случае непонятен.

Где мне взять такое подтверждение если возможность дистрибуции софта исключительно через snap мы обсуждаем как отдаленную и маловероятную перспективу, или даже как гипотетическую возможность? Что касается механизма то посмотри как это происходит в винде, неужели не встречал случаев когда каждая сравнительно небольшая игра или приложение требует своей версии библиотек и тянет сотни мегабайтов?

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

Ты не поверишь! Представь, оно сейчас так и есть! Не надо никуда оглядываться, открываешь в Ubuntu AppCenter (или как там его, я то Kubuntu использую) и просто ставишь любое приложение. И в Fedora точно так же открываешь и ставишь, и тоже никуда не нужно оглядываться. И так в любом дистрибутиве. Не благодари, рад был помочь.

Не поверю и не поблагодарю. Ибо ты соврал только что. Проверяется просто. Количество софта там и там разное. Упс А еще это весело наблюдать, как выходит новый дистрибутив и половина софта упс не ставится. Зачем ты пытаешься так низко соврать? Ведь это известная всем проблема. И она волнует всех крупных разрабов. Мелкие пофигисты, это база.

Гениально! И главное мейнтейнер без работы не останется, он будет верифицировать аакаунты. Шило на мыло, но зато все модно и молодежно)) Он будет без работы. Так как его работу возьмет тот кто за софт отвечает, а не какойто ноунейм.

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

Где мне взять такое подтверждение

Ну то есть ты нафантазировал. Поняли.

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

А еще это весело наблюдать, как выходит новый дистрибутив и половина софта упс не ставится

Как он может не ставится если собран и протестирован именно для него? Не встречал такого. Ну вышла ubuntu 24.04, какие приложения из репозиториев не ставятся?

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

Нет - флатпак и снап - это не возможность ставить софт.

Что ты такое несешь? Snap — это система развёртывания программного обеспечения и управления пакетами.

Почему ты врешь?

На любом дистре можно развернуть пакет другого дистра. Но вопрос зачем это надо если все основное есть внутри самого дистра?

Нет, нельзя. Есть отдельные случаи, когда можно какойто пакет установить в другом дистрибутиве. Во первых, это исключение, второе тянет за собой кучу проблем и третье, это геморой, в четвертых может убить ОС.

Опять ты врешь. Зачем?

Потому что венда и ее СДК это продукт компании микрософт.А линукс - это сборная солянка из вагона разных источников. С разными наборами библиотек, системами инициализации, дисплейным сервером.

И любая попытка систематизировать это говно, вызывает лютый хейт из манямирка. Ахахаха

А вот врать нехорошо. В обратную сторону работает не все. Да и в прямую не все. Хотя то что совместимость на порядок лучше бесспорно.

ТЫ ВРЕШЬ, НО НЕ ВРЕШЬ! Ахахахаха Вот это ты красавчик.

Ну с тобой все ясно. Хакеры, налетайте - лошку достаточно верифицированного васянского аккауна в васянском снап-флатпак-сторе. Венда - это микрософт, адроид - гугл, эппл сам себе эппл. Компании с мировым именем и уровнем доверия. А тут нам главное флатпак - похрен от кого на любой дистр.

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

И снап стор от Убунты это не васянский стор. А вполне официальный магазин от Каноникала. Так что ты обосрался, просыпайся уже.

Тебе кто-то чтото за беспатно должен а ты еще и наказывать собрался?

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

Но я прекрасно понимаю, что ты не знаком с словом ОТВЕТСТВЕННОСТЬ!

Иди венду юзай. И попробуй накажи Билли когда очередной апдейт окирпичит тебе комп.

Прикинь я и винду юзаю. А еще андроид. А еще линукс. У меня с этим проблем нет васян.

И кстати насчет винды. Если в продукт МС просочится вирус васяна, то васян узнает что такое ответственность.

Ну и напоследок. Есть такое выражение - я буду насиловать, пока в соседнем селе насилуют. Это про тебя.

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

Как он может не ставится если собран и протестирован именно для него? Не встречал такого. Ну вышла ubuntu 24.04, какие приложения из репозиториев не ставятся?

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

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

О, выдергиватель слов из контекста приперся. Один раз уже слился, решил еще раз опозорится. До обсера 3…2…1 Меня просили показать софт, который нельзя поставить в современном дистрибутиве. А не что есть в снапе, но нет в репах. Иди вытирайся.

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

Нет никаких причин использовать один и тот же runtime, если это требование не накладывает дистрибутив ОС.

Как раз-таки причин использовать свой отдельный runtime очень мало, да и его обычно наследуют от какого-то готового. А вот причина использовать готовый очень проста и очевидна: зачем выполнять работу, создавая и поддерживая собственный runtime, когда есть уже готовое?

И если посмотреть на тот же FlatHub, то приложения вовсю используют runtime freedesktop.org, соотв. runtime GNOME и KDE, и т.д., а если кому-то нужна своя, особая сборка какой-то библиотеки, то её просто включают в состав дистрибутива приложения «поверх» той, что в runtime.

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

Речь, очевидно, идёт не о принципиально разных рантаймах, а о маркировочно разных рантаймах, то бишь разных их версиях.

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

Если в продукт МС просочится вирус васяна, то васян узнает

МС ловит вирусы только в путь. И где показательные судилища над вирусписателями, клоун?

Snap — это система развёртывания программного обеспечения и управления пакетами.

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

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

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

И любая попытка систематизировать это говно, вызывает лютый хейт из манямирка.

Систематизировать путем линковки всех либ внутрь пакета? За это в приличных домах канделябром бьют. В том числе и твоем любимом MS

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

Это твои воспаленные фантазии пупа земли которому все должны. Нет батенька - все лицензии свободные имеют пункт отказа от ответственности - прога содана as-is и ты волен ее использовать безвозмездно то есть задаром но автор ответственности за твои проблемы с этой прогой не несет. ВСЁ. Ответственность автора засунувшего зловред - ну в терминах Джона Уика он становится экскомьюникадо в определенных кругах и патчи от него не примут и софт его не возьмут. И да - если действия этого «зловреда» совершат некоторое противозаконное деяние - то возможно будет уголовка но опять же надо будет доказать что именно автор злонамеренно туда это засунул. В общем если тебя так поимеют - успехов в судах и следствиях.

Прикинь я и винду юзаю.

Кто бы сомневался.

А еще линукс. У меня с этим проблем нет васян.

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

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

Где мне взять такое подтверждение

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

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

Что касается механизма то посмотри как это происходит в винде, неужели не встречал случаев когда каждая сравнительно небольшая игра или приложение требует своей версии библиотек и тянет сотни мегабайтов?

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

Однако в случае игр основная часть, занимающая место, это обычно ассеты, а не исполняемый код. А приложение, тянущее аж сотни МБ библиотек, уже при этом присутствующих в системе, — хотелось бы на это посмотреть. Не подскажете такое приложение? — возможно, я даже расчехлю под это виртуалку.

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

А если приложений из flatpak значительно больше одного, то вырастет и доля совместно используемых ими ресурсов, а значит, вклад каждого приложения упадёт ещё сильнее.

С чего бы.

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

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

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

Очевидно, что чем больше приложений из flatpak запущено, тем выше точечная вероятностная оценка числа библиотек, используемых совместно хотя бы двумя из этих приложений. Как следствие, поскольку данные библиотеки будут загружены в память лишь один раз, то вклад каждого отдельного приложения в увеличение потребления памяти разделяемыми библиотеками уменьшается, тем сильнее чем больше таких совместно используемых библиотек.

Rootlexx ★★★★★
()
Ответ на: комментарий от 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)
Ответ на: комментарий от mbivanyuk

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

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

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

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

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

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

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

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

Rootlexx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.