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

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

Думаю и три сотни зависимостей нормально, лишь бы работало

Это тонкий вопрос, зависимости могут например быть низкого качества или из мертвых проектов

Так что надо разбирать каждый случай отдельно

Но как показывает практика, качественный софт имеет немного зависимостей

Если это какой-нибудь Debian - то это нормально. Они любят делить сущности на части. Дробить-дробить-дробить. :D Вот и получаются кучки зависимостей.

зависимость != зависимость

зависимость != зависимость.

Всё определяют сами зависимости.

Например, unpaper 6.1(простенькая консольная утилитка) зависит от libav (массивные библиотеки video-audio форматов). Приемлема такая (одна кстати) зависимость? Для меня - нет. Потому что, unpaper 5.1 зависит только от libc6.

Например, gucharmap тянет за собой gir... Расписывать сколько и чего не буду. Приемлемы такие зависимости. Для меня - да. Потому что, для меня не приемлем сам gucharmap - 4метра бесполезного, даром никому не нужного кода.

Так что, зависимость != зависимость.

тс ничего не сообщил о дистре, к примеру в debian можно попробовать так

# apt install --no-install-recommends имя_пакета

манджарка

Вообще дело проясняется

манджарка

значит arch, как в pacman без зависимостей ставить - загляни в man...

Смотря каких зависимостей и смотря как написан софт. Например, если одна программа тянет в зависимостях Qt и GTK, то писал её говнокодер.

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

$ pactree -u xorg-xeyes | wc -l; pacman -Qi xorg-xeyes | grep Size
53
Installed Size  : 23.00 KiB

следующая программа уже не потребует этих зависимостей

зато следующая устанавливаемая тобой программа уже не потребует этих зависимостей.

Так давайте в coreutils все библиотеки и весь софт пропишем.

Нет, подобная концепция в принципе не верна.

Ну запихают гигабайт велосипедов в саму программу, это лучше, чем гиг внешних зависимостей?

В этом смысл существования отдельного каталого для lib в unix. Так намного удобней, когда есть уже библиотека, которая поможет тебе с решением задачи. Если в windows каждая программа может иметь зависимости только в своем рабочем каталоге, то в unix принято использовать уже имеющиеся, так программа занимает меньше места и библиотеку возможно используют с десяток приложений. Это нормально, так же нормально как ты устанавливаешь графическую программу, а она не тянет с собой зависимости например gtk, потому что gtk уже установлена в твоей системе.

полная чушь.
начиная с того, что в винде не нужно носить зависимости с собой, а версий gtk аж три штуки, заканчивая главным моментом — нет никакого смысла в отдельно каталоге lib в *nix и ничего там не «принято»
то, что по твоему «принято» — компромисс между возможность имплиментить эту фичу и ценой, где цена нормальной разработки такого решения внезапно сыграла решающую роль в старые времена.
именно по этому, сейчас после появления неймспейсов и рекламы контейнеров комерчиские компании создают продукты (например NixOS), которые наконец дают возможность использовать разные версии одной и тоже зависимости нормальным способом, а не траханьем мозга.
и потому, что вложили кучу бабок в такие проекты, самый хайповый продукт на данный момент в линуксах — это докер\кубернетис.
так что можешь оставить свои «в unix принято» в 1995 году. никто ничего не принимал, кроме решения «не делать» все эти годы.

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

питоньи придатки

Да, к сожалению, сейчас это нормально.

Концепция использования /lib в качестве отдельного каталога, да и в целом использование репозиториев устарела.

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

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

Если не будет модульности, то линь так и останется на уровне 1-2%.

Концепция использования /lib в качестве отдельного каталога, да и в целом использование репозиториев устарела.

Красиво на словах, но на деле вся эта куча альтернатив типа flatpak-a и прочих так ни к чему и не привела.

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

1-2% это нормально, для остальных ламо есть десяточка.

А весь докер на деле сводится к унылому неподдерживаемому (winbl0ze style, когда в одной директории лежит и куча зависимостей) говну с кучей дыр в продакшене. На чём многие и погорают.

Если этот органайзер тянет за собой сервер базы данных, sqlalchemy, библиотеку парсинга «lxml» и проч., и проч на 900 Мб в общей сложности - нет, не нормально, выберите другой органайзер. А если все эти зависимости весят по 150 Кб каждая - устанавливайте и не нойте.

А ты что не так делаешь? Свою графическую библиотеку используешь, или держишь файлы как firefox в lib/firefox? Или ты старые библиотеки используешь, которые уже давно не поддерживаются? Разумеется есть программы со своим рабочим каталогом, но в основном все зависимости в lib и это не чушь, потому что такова реальность.

если не тебе их все руками конпилять, то всё норм

отдельно каталоге lib в *nix и ничего там не «принято»

то, что по твоему «принято» Есть разница. Ты хоть раз запускал pkg-config --list-all? Когда хочешь узнать какие либы есть для того чтобы подключить, именно эту команду надо использовать. И разумеется она ищет в lib. Потому что если каждая программа будет со своими зависимостями в одном каталоге, то размер программ увеличиться во много раз, хотя смотря как использовать, уже забыл, но можно было использовать определенную версию либы, и тогда использовать ссылкы на функции, тогда размер программы станет меньше.

никто ничего не принимал,

Да откуда тебе знать, ты что разработчик в проекте gnu? Что ты мне тут лапшу на уши вешаешь.

Ну и вот вопрос? Готовая библиотека ускоряет процесс разработки, станешь ли ты устанавливать нужные либы, или будешь писать свои, которые еще нужно будет отлаживать и работать над ними?

Например, если программа тянет в зависимостях Qt или GTK, то писал её говнокодер.

Так справедливей.

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

и потому, что вложили кучу бабок в такие проекты, самый хайповый продукт на данный момент в линуксах — это докер\кубернетис.

Полная чушь.

1. NixOS гораздо старше (2003) всех этих говнодокеров и хайпа с контейнерами (хотя концепция контейнеров еще старше)

2. Докер/кубернетис решают совсем другую задачу - развертывание IaaS с уменьшенным оверхедом при развертывании большого количества инстансов. Они не вносят ничего нового в решение проблемы зависимостей по сравнению с вируталками, известными с 60-х годов

При установке простенького терминального органайзера, мне предложили поставить еще много много всвего, в основном питоньи придатки. Как к этому относиться, всё в порядке?

Да.

В скриптовых языках с своим пакетным менеджером принято дробить функциональность на более мелкие части, в пределе вплоть до юниксвейного одна фича - один пакет (см. leftpad). В частности комбайны-фреймворки редки и если пристуствуют, то сами состоят из кучи отдельных моудлей и/или переиспользуют кучу существующих (В perl например был мегафреймворк Catalyst и из него навыделяли кучу отдельных пакетов, реализующих определенную функциональность без привязки к другим его частям)

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

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

Вообще, иногда складывается впечатление, что NixOS слишком хорош для типичного КРЕСТЬЯНИНА. У него в голове не укладывается, что нечто столь совершенное может существовать в нынешнем мире говнокода. «Что это? Чур, чур, чур, искушение бесовское!» — Испуганно крестится КРЕСТЬЯНИН. Потом берёт с полки новый красивый докер / rkt / ансибл / cloud / salt / puppet / вагрант / terraform / coreos / atomic host / appimage / flatpack / snapper / че там ещё корпорации нахерачили в 2018 году. Оно понятное, привычное, со знакомым привкусом говнеца. «Вот это по-нашему! Эх, вот в деревнях-то было всё!» — Радуется КРЕСТЬЯНИН, смазывая грязным рукавом набежавшие слёзы умиротворения.

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

Декларативное конфигурирование в большей или меньшей степени реализуется всеми пакетными менеджерами, а также средствами вроде puppet и ansible. Тоже ничего нового.

Они не вносят ничего нового в решение проблемы зависимостей по сравнению с вируталками

ох лiл, а виртуалки не вносят ничего нового в решение проблемы зависимостей по сравнению с bare metal. ппц логика.

Нормально ли это? Определённо.

Хорошо ли это? Сомнительно.

Ты просто не понимаешь что такое unix-way.