LINUX.ORG.RU

Скажите, три десятка зависимостей, это нормально?

 ,


0

2

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

Инетерсует технофилософское осмыслене, разговоры о добре и зле.

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

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

saahriktu ★★★★★
()

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

burato ★★★★★
()

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

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

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

ism ★★★
()

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

Deleted
()

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

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

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

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

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

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

Deleted
()

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

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

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

манджарка

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

amd_amd ★★★★★
()

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

peregrine ★★★★★
()

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

$ pactree -u xorg-xeyes | wc -l; pacman -Qi xorg-xeyes | grep Size
53
Installed Size  : 23.00 KiB
anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

Deleted
()

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

anonymous
()

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

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

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

system-root ★★★★★
()

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

rumgot ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()

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

hedgehog_alex
()
Ответ на: комментарий от system-root

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

u0atgKIRznY5
()

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

Harald ★★★★★
()
Ответ на: комментарий от system-root

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от system-root

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

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

Полная чушь.

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

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

annulen ★★★★★
()

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

Да.

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

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

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

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

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

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

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

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

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

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

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

system-root ★★★★★
()

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

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

Bfgeshka ★★★★★
()

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

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