LINUX.ORG.RU
ФорумTalks

Slackware и отсуствие зависимостей. В чем фишка?

 , ,


0

1

Почему в этом дистрибутиве был сделан такой ход?

Меня в первую очередь интересует мнение самих пользователей Slackware среди здешней публики. Slackware-ненавистников любезно прошу не вмешиваться.

Лично у меня есть несколько гипотез.

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

2.Если отдать пакеты на откуп автомату, то это приводит к потере контроля, ибо человек фактически взваливает продумывание состава программ в своей системе(пусть и не полностью) на майентейнеров пакетов и пакетный менеджер. А принцип KISS для того и создан, чтобы обеспечивать повышенный контроль над системой, пусть даже в некий ущерб удобству и простоте использования. Должен сказать, что я уже по своему опыту знаю каково это, когда ненужный пакет прибит гвоздями в системе. (Как насильно удалить один пакет, не удаляя зависимый от него?)

3.Использование пакетного менеджера с управлением зависимостями приводит к тому, что новые релизы такой системы начинают все больше и больше пухнуть, у дистрибутива развивается «ожирение», ибо майентейнеры не могут устоять перед соблазном того, чтобы не запихнуть в зависимости как можно больше пакетов. Да и сами разработчки начинают устанавливать триллионы пакетов в установку с дефолтными настройками. Типа «все равно эту кашу из зависимостей будет расхлебывать автомат». Ну а человек даже не подозревает, что у него стоит куча ненужного барахла, которое можно безболезнено удалить. Например, я хотел переустановить дистрибутив Trisquel, ибо ему стало мало 12 гигабайт на разделе. Каково же было мое изумление, когда я выяснил, что я могу иметь вполне удовлетворяющую меня систему, которая будет размером всего в 2,5 гигабайта!! Мне в принципе не жалко места на диске, просто это говорит об том, что в механизме моей системы было чертова куча абсолютно лишних шестеренок.

4.Возможно управление зависимостями делает систему более user-friendly, но вот если вдруг возникнет сбой, то это может привести к лютому 3,14зд*цу, который запаришься устранять. То есть, user-friendly был принесен в жертву ради того, чтобы систему можно было легче чинить в случае поломки.

Deleted

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

Может в то время когда Патрик создал слаку, пакетные менеджеры с зависимостями в общем-то и не применялись/не существовали?

PolarFox ★★★★★
()

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

realloc ★★★★
()

Почему в этом дистрибутиве был сделан такой ход?

Ошибочная постановка вопроса.

Gotf ★★★
()

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

GreenTea ★★
()

Ах, да, slackpkg написан на Bash, а там не так просто реализовать разруливание зависимостей, но всё необходимое есть и работает бесперебойно :)

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

Кстати, я добавил еще и четвертый пункт.

«Все три пункта вполне логичны и с ними можно согласиться»

Вот именно. Мне интересно, согласятся ли с моими рассуждениями пользователи Slackware. И какие еще у них есть мысли по этому поводу.

Deleted
()

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

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

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

GreenTea ★★
()

Почему в этом дистрибутиве был сделан такой ход?

Принцип ванильного софта, как правило один тарбол с исходниками даёт один бинарный пакет, а следовательно, «крупные» пакеты при относительно небольшом их количестве.
Если начать нарезать пакеты под минимизацию зависимостей (отдельно каждая софтинка, по каждой из которых отдельно бинарники с настройками, отдельно библиотеки для сборки, отдельно документация, отдельно ...) зависимости между пакетами ослабевают, но резко увеличивается количество пакетов, настолько, что в одиночку уже не уследить (да и неохота заниматься отдельной фичей, пользы от которой ноль, а трудозатрат — вагон).

В качестве иллюстрации когда-то приводил пакет nmap в Slackware: http://forum.posix.ru/viewtopic.php?pid=36590#p36590

И ещё на ту же тему: Арчешкольник о Slackware на ночь глядя (комментарий)

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 2)

Автомат vs механика. Плюсы и минусы давно известны и обсосаны

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

«Попользуйся слакварью недельку и всё сам поймёшь.» Я наверное так и сделаю. Только вот думаю, что мне для адаптации все-таки потребуется гораздо больше времени.

Благо Убунту и производные от него подобны очкам. В том плане, что если их долго носить, то зрение может ухудшится. Так и тут. Я Линуксом пользуюсь уже четыре года, но когда у меня возникают неполадки в системе, начинаю чуствовать себя распоследним ламером. Я просто чуствую, что перестаю контролировать свою систему и это меня сильно нервирует.

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

./configure & make & make install наше всио

Для Slackware это не так, хотя и не запрещено (равно как и в любом другом дистрибутиве).

bormant ★★★★★
()
Ответ на: комментарий от druganddrop-2

«Ахренеть как удобно так масштаба KDE собирать будет. »

Не знаю как Вам, а мне KDE не нужен. Мне вполне хватало комбинации Иксы + Ratpoison. Ну может быть еще conky было бы неплохо прикрутить, но у меня руки еще не доходили.

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

Очень интересно, не могли бы привести парочку примеров для пущей наглядности?

Ну можно, например, сравнить что тянут метапакеты «система сборки» (типа build-essentials) против того, что лежит в группе пакетов d/. Или метапакеты с kde/xfce против соответствующих каталогов.

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

Я понимаю, что рискую вывести Вас из терпения, но не могли бы Вы быть столь любезны и привести соответствующие списки?

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

слакбилды позволяют тоже самое, что и use флаги генты

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

bormant ★★★★★
()
Ответ на: комментарий от druganddrop-2

«пульс и системд»

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

Deleted
()
Ответ на: комментарий от druganddrop-2

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

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

зачем же во все? лишь в те, в которых кастомные сборки реально нужны, а остальное можно и из бинарных пакетов поставить

beerman
()

Очевидно же - сначала было не нужно, потом стало лень+kiss, а потом это стало фичей.

Dispetcher14 ★★★★★
()

А вообще, интересная получается ситуация. Другие дистрибутивы как осинновые листы дрожат над зависимости, а в Slackware сломанные зависимости являются НОРМОЙ.

«И это между прочим, не просто хорошо, а очень-очень»(с)

Весь прикол в том, чтобы надо уметь правильно их ломать =)

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

лишь в те, в которых кастомные сборки реально нужны

Тогда достаточно поправить по месту и пересобрать.
use флаги для этого излишни ;-) Они средство универсальности: «использовать/не использовать pulseaudio», «использовать/не использовать что-то ещё», затем пересобрать мир. Они нацелены на готовность ко _всем_ возможным сочетаниям.
А там, где «реально нужно» там, как правило, просто один «реально нужный» вариант, и никакая универсальность не требуется ;-)

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

согласен, просто минимальная пакетная база linux может устроить практически всех... да и кде тоже, зачем её пересобирать?

beerman
()

Почему в этом дистрибутиве был сделан такой ход?

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

Quasar ★★★★★
()

Патрег руководствуется двумя подходами:

  1. Система должна быть абсолютно прозрачной. Пользователь должен получить абсолютный контроль над системой. Если он посчитает, что какой-то пакет ему не нужен, то он волен его не ставить.
  2. Одна программа == один пакет. Разбивать пакеты не рекомендуется. Поэтому реально в слаке устанавливать пакетов приходится намного меньше, чем в любом другом дистре.
eugeno ★★★★★
()

Почему в этом дистрибутиве был сделан такой ход?

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

В чем фишка?

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

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

ну типа build essentials це мелкое подмножество develов всё-таки, там надо devel vs devel сравнивать.

dn2010 ★★★★★
()

РФВS

Не берите в голову - в enterpriZe мире нищебродские задротские поделия типа шлака, гентуууу, арча и прочие даже не рассматриваются.

И на LPIC спросят только GNU/Debian и шляпу.

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

«в enterpriZe мире» Вполне может быть.

Но что русскому хорошо, то немцу смерть.

У меня обычный домашний компьютер. И если я буду использовать Slackware, то только для него. А на то, какой дистрибутив лучше подходит для серверов, суперкомпьютеров и т.д. мне до лампочки.

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

" давным-давно, в период рождения слаки зависимостей, как таковых, не было"

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

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

Но раз зависимости так и не были введены, то это говорит об том, что имело место сознательное нежелание их вводить

Вообще бесспорно.
Почему? Только Патрик и ответит. Я склонен к тому, что Патрику просто показался не {оптимальным,перспективным} данный вариант. Или он просто не хотел придумывать свои пакеты, писать свой пакетный менеджер. etc. Это на самом деле не важно.

comp00 ★★★★
()

Если отдать пакеты на откуп автомату, то это приводит к потере контроля, ибо человек фактически взваливает продумывание состава программ в своей системе(пусть и не полностью) на майентейнеров пакетов и пакетный менеджер. А принцип KISS для того и создан, чтобы обеспечивать повышенный контроль над системой, пусть даже в некий ущерб удобству и простоте использования

Мне интересно посмотреть на человека, который будет вручную контролировать как минимум пару сотен (тысяч) пакетов. Это ж работать нельзя, только сиди и контролируй!

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

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

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

«Мне интересно посмотреть на человека, который будет вручную контролировать как минимум пару сотен (тысяч) пакетов.»

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

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