Что вы так предесь от идеи «все зависимости в одном большо пакете»?

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

Ой, а куда это двести мегабайт ушло? Ай-ой.

А теперь представь парочку программ с кутями, которые каждый свою либу тащит. Ой, а куда это двести мегабайт ушло? Ай-ой.

Можно пример программы, в которой qt на двести мегабайт? (Хотя уже лучше, у пациента выше на 1.5 ГБ)

это всё потому, что вам нельзя балунинг. ведь патентъ.

Не-не-не, ты не понял.

Каждая прога, которая в виде бандла тащит с собой свои 30-40-50 МБ кутей (разные версии и наборы модулей)

И каждый этот набор загружается в оперативную память. А при использовании системных - набор загрузится один раз, заняв свои 30-40-50 мегабайт там и не чухаясь. Понял?

А при использовании системных - набор загрузится один раз

Эээ, разве?

Ты дурак? Как ты в веб без него вообще ходишь!?

UKSM во все поля. Без него я бы умирал на ноуте с 4 ГБ памяти.

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

(на самом деле не потому, но это в деле тоже роль играет)

Да, нашёл

https://unix.stackexchange.com/questions/116327/loading-of-shared-libraries-a...

Хотя что-то у меня сомнения про сложный софт со всякими песочницами

я эту фигню на себе буду тестить когда на лоре хоть одна история узбека появится. пока только читал что неочень. 16ГБ, мне норм пока.

Хром/Фокс От трети до половины жора убирает.

Без UKSM я больше 30 вкладок вообще не могу открыть (да-да, гельбура, ну и что!)

С UKSM спокойно 100-130 на той же гельбуре. Жор фокса около двух гигов выходит, и у меня даже либра умудряется жить рядом и не падать.

(правда фокс продолжает подтекать и его приходится рано или поздно убивать)

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

[root@netbook ~]# cat /sys/kernel/mm/uksm/pages_sharing 
258877

266445× 4 ÷ 1024 = 1040.8 MB

Минусы - немного сжирает шину памяти, немного больше жрет энергии.

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

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

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

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

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

Сравниваешь несравнимое же.

Даже nixos нормально входит на SSD за $50, о чем ты?

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

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

Ты врёшь. Там динамическая линковка всегда была.

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

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

Фейсбук - очень плохой пример. Это одна из тех контор, которые убили целую отрасль.

Непрерывный цикл школоты - потому, что дёшево, а на качество насрать. За такое карать надо.

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

Система зависимостей - это хорошо и нужно. Просто некоторую прикладуху лучше паковать бандлами.

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

Я думаю, что тут бо́льшая проблема не в создании пакетов, а в невозможность в разумное время протолкнуть его в апстрим, из-за фатальной бюрократии в дистрибутивах. А свой репозиторий нужно поддерживать, и все такое.

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

В общем история такая же как и с docker'ом ― инструмент для склеивания скотчем костылей, а на пользователя наплевать.

Почему стремятся к dll hell?

Шиндузятники, сэр.

Анализ кода, подключенные библиотеки, используемые фукции, выдергивание фукций из библиотек в одну библиотеку данной программы, сборка библиотеки программы и самой программы (с расставлением нумерации или точек входа).

Даже nixos нормально входит на SSD за $50

Хммм. На SSD за 50$.. И сколько же центов занимает, к примеру chromium? Он занимает столько на любом накопителе, вне зависимости от его скорости/производителя/интерфейса подключения/физического размера? Или всё-таки лучше измерять объём накопителей в {Кило,Мега,Гига,Тера,Пета}байтах?

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

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

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

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

Вы, простите, из какого танка вылезли? Т.н. проблема dll-hell решена использованием winsxs уже лет пятнадцать.

Всё правильно. А если будет необходимо удалить ненужную / устаревшую функцию, то создаётся функция-отбойник в самом начале с нулевым номером, которая будет возвращать -1:

int noFunction()
{
   return -1;
}

Ну как бы есть http://refspecs.linuxfoundation.org/lsb.shtml

Есть ещё такая штука как AppImage, Docker и прочие глобальные надёжные.

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

Самому, помню, понадобилось распространять проект с QtCore и QtNetworking. Для удобства пользователя решил собрать статически (проект опенсурцный был).таки поставлял libQt5Core и libQt5Networking в архиве.

Долго ковырялся, и в итоге чтобы всё работало на старых дебианах, пришлось установить CERN Linux на виртуалку и собирать прогу вместе с Qt на ней. Потому что чуваки из CERN таки разобрались в вопросе глобально и надёжно — добавили в дистр бинарные пакеты с gcc бородатой версии и всеми нужными зависимостями.

В итоге собранный бинарь работал на дистрах двухгодичной давности в 2016 году. И до сих пор работает.

Я это к тому, что всё что нужно для ынтерпрайзного метода распространения софта есть. И сравнивать с подходом microsoft можно только от безысходности — там тоже всё ни капельки не сладко, просто все давно приспособились и всем норм. Только почему-то один и тот же бинарь собранный mingw у меня работал нормально на 7ке и 10ке, но не хотел работать на windows server 8 или 10, не помню... В итоге пришлось распространять три варианта — linux i686, mingw i686 и msvc, лучше я не буду писать про то, что было дальше

Ну бабла то они заработали с лихвой.

Я — нет, я не прусь.

Я предпочитаю отдавать весь контроль за зависимостями на плечи пакетного менеджера. Было бы хорошо даже убрать OVER9000 реализаций зависимостей плагинов в пользовательском софте, и переложить это на плечи пакетного менеджера. В крайнем случае, обучить пакетный менеджер работать ещё и в пользовательском режиме, как, например, systemd --user управляет сервисами только для конкретного пользователя.

сам qt не белее 15 метров, вбокс с собой гостевые аддоны тащит.

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

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

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

весь контроль за зависимостями на плечи пакетного менеджера

с held пакетами предлагающими удолить 90% системы.

_пока что_ две-три на систему

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

Интересно, KES 10 будет в виде snap пакета или по старинке?

Что-то мне подсказывает...

Да ясное дело!
Когда сам Гном надо упрятывать в один большой пакет, в /opt/, мега светлые разумы упаковывают калькулятор от Гнома!!!

Это успех! в 2к18 коту и никак иначе!

И сколько же центов занимает, к примеру chromium?

Хз, 50?

Он занимает столько на любом накопителе, вне зависимости от его скорости/производителя/интерфейса подключения/физического размера?

Ясен пень нет, шланг.

Или всё-таки лучше измерять объём накопителей в {Кило,Мега,Гига,Тера,Пета}байтах?

В контексте дискуссии, почему твой chromium до сих пор не на SSD - нет, не лучше.

man dynamic linking

Вопрос на миллион: а как надо?

Бандлинг — говно. Проталкивать свой софт в 100500 дистрибутивов и возиться с особенностями национальных пакетных менеджеров — говно не меньшее.

зачем 100500, достаточно топ3-5 самых популярных, пользователи остальных пусть сами пердолятся

Почему же? Вполне потому. Иначе тебе придётся для каждого отображения делать релокации, то есть копировать страницы.

топ3-5 — это уже 100500.

Кое-что и без этого могло бы разделяться (без ASLR, ес-нно), например основные системные либы. Но это уже костыль.