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)

5. Патрику впадлу отслеживать зависимости и писать нормальный пакетный менеджер.

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

Серьёзно? Я вот сидел на слакк во времена 10.2 - 12. Проблемы - это суть слаквари.

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

Чего? Он наоборот упростил себе жизнь собрав свой лфс много лет назад. Это его песочница, не более. Всерьёз это воспринимать смешно.

IPR ★★★★★
()

Это эзотерический дистрибутив.

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

5. Патрику впадлу отслеживать зависимости

собирая дистрибутив, это ему приходится делать в обязательном порядке, ничто не вечно под луной, и набор зависимостей — не исключение.

и писать нормальный пакетный менеджер

... отслеживающий зависимости. С этим можно согласиться. Тем более он той или иной степени нормальности есть — slapt-get, поддержка зависимостей репозиторием добавляется несложно, достаточно в PACKAGES.TXT добавить в описание пакетов строки REQUIRES (Стефано Стабеллини делал для 13.1, но потом бросил это занятие). Скорее, не писать менеджер, а поддерживать в актуальном состоянии базу зависимостей для него, которая по определению будет крива и коса из-за использования крупных пакетов (см.выше).

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

Да и пакеты тут кагбэ не совсем пакеты.

Почему, чего не хватает для «совсем пакета»?
Нужно понимать, что пакеты Slackware не совсем обычные пожатые тарболы (tar+gz|bz2|lz|xz), они дополнительно содержат служебную информацию в ./install/: slack-desc — описание пакета, doints.sh — установочный скрипт, иногда slack-required — список зависимостей (slacky.eu практикует подобный подход).

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

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

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

сарказм

Скажем, в силу некоторой неосведомлённости, исходное сообщение следовало читать как «пакеты в Slackware — это обычные тарболы, поэтому не совсем пакеты»?
Ок, в таком виде понятно.

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

Да ладно вам. Я убежденный пользователь слакваре, не тролль, а сказал это потому, что иногда вижу, как некоторые называют пакеты слаквари недопакетами. Тащемта мне пофиг.

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

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

Сразу оговорюсь, не сочтите за провокацию, просто очень интересно услышать ваше мнение.
На одном форуме, относительно давно, завязался спор по поводу Slackware; самый интерес представляет спор между gvy и Hottab. В качестве защитника выступает некто Hottab, а в качестве обвинителя некто gvy; в свою очередь gvy выдаёт массу вполне конструктивной и осмысленной критики в адрес Slackware.
Вот ссылка на тред.
Скажите, bormant, что вы об этом думаете?

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

Всеобъемлюще универсальных решений не бывает в принципе, у каждой реализации есть свои сильные и слабые стороны, при чём эти «сильность» и «слабость» целиком и полностью зависят от ситуации и требований, то есть любая из объективных характеристик может быть с разных точек зрения как плюсом, так и минусом (велосипед можно носить на руках, но укатать им асфальт вряд ли получится и наоборот, но это не значит, что не нужны велосипеды или катки).
У Slackware вполне определённые цели и задачи — оставаться максимально просто устроенной системой, но не проще необходимого. Это и достоинство, и недостаток, смотря с какой колокольни смотреть. Пытаться обвинять дистрибутив в том, что он не решает задач, которые перед ним никогда не ставились, или ведёт себя не так, как ожидалось по опыту с другими дистрибутивами или по незнанию — по крайней мере странно.
Slackware — это по сути тонкий слой икры из установщика, настроечных сценариев и собственно проделанной работы по обеспечению сборки и взаимной непротиворечивости версий ПО и их объединению в дистрибутив на толстом бутерброде из ванильных исходников.
С тем, что Slackware портит молодых и перспективных ковырянием в сборке, согласиться трудно; даже самым нехитрым инструментом — молотком — можно с равным успехом бить по гвоздям, шурупам и пальцам, но не молоток обычно виноват в получаемом результате. Речь-то изначально не о сборке, а о достаточном наборе софта с документацией на сам набор, пакеты, входящие в состав, документированными текстовыми конфигами. Читай, учись, строй, придёт понимание, как оно устроено изнутри, почему и как взаимосвязано, появится возможность диагностики той или иной ситуации. Отсюда та фраза про знание одного дистрибутива или Linux в целом, от проделанной работы по приобретению знаний, а не от самого факта установки Slackware. Да, подобное может быть как абсолютно необходимым, так и излишним: может быть, что водитель ездит, а сервис чинит и обслуживает, но может быть и не так, смотря кого готовили, водителя-механика или водителя автомобиля категории «B» с автоматической коробкой передач.
А умение видеть за деревьями лес, его не в дистрибутиве искать нужно.

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

Если под приобретением плохих привычек от использования Slackware имелось в виду внесение недокументированных точечных изменений в отдельную установку, пресловутое голое
# ./configure; make && make install
так и практически в любом другом дистрибутиве никто не мешает поставить инструменты сборки и делать ровно то же самое, но при чём тут Slackware как система?
Самодисциплина в документировании/версионности изменения настроек и сценариев сборки (как правило в журналах и VCS), опакечивании вносимых изменений в ПО, в использовании централизованного репозитория при разработке решений, если правильно путаю, слабо зависит от используемого дистрибутива.

Не могу исключать, что речь шла о чём-то другом.

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

Вам надо срочно худеть. Жир так и капает.

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

Я просто чуствую, что перестаю контролировать свою систему и это меня сильно нервирует.

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

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

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

«не всякий контроль заслуживает усилий на него потраченных.»

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

Другое дело, что в последнее время я замечаю, что мой компьютер «дичает». Например, сейчас я сижу без рутовского доступа на СВОЕМ ЖЕ СОБСТВЕННОМ КОМПЬЮТЕРЕ. И все это произошло после неудачной попытки восстановить систему из резервной копии. Я вообще-то мог бы загрузиться с LiveCD и восстановить свои права доступа, но пока мне просто лень, благо и без рутовских прав у меня все работает. Но сам факт, что данная ситуация возникла.

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

Не могу исключать, что речь шла о чём-то другом.

А вы прочитали весь тред?

Как понял я тамошнюю дискуссию: речь шла о том, насколько актуален и конкурентоспособен на сегодняшний день Slackware; о том, что Slackware, по части пакетов и ПМ, так и остался на уровне 96-го года. Причём часто используемый аргумент в защиту ПМ: «У Slackware вполне определённые цели и задачи — оставаться максимально просто устроенной системой, но не проще необходимого.» является ложным.
Приведу цитату из того треда:
Он и в школе, наверное, дальше умножения в столбик не осилил, если в отличие от людей с работающей головой не понимает слов «инкапсуляция», «изоляция», «API», «уровень рассмотрения», «предметная область»... Правда, надеюсь, что ты слегка приврал, а я слегка сгустил, но это вполне конкретный наезд. Нет, я тоже предпочитаю простое безумно сложному, вот только считаю, что «просто» — это когда есть обозримое поле характеристик объекта, о котором речь. apt-get install apache — это просто. А вот лезть в потроха apt (или, думаю, swaret) — никак не хочу.

Если же последовательно применять подход Патрика, то gcc, GNU make и autotools надо выкинуть нафиг, потому что это именно безумно сложные инструменты, особенно если их не раскладывать на слои абстракции. А если он их воспринимает как «вещь в себе», то аргумент против такого же /простого/ инструмента rpm или dpkg — липовый.
(c) gvy Ссылка на сообщение.

Читай, учись, строй, придёт понимание, как оно устроено изнутри, почему и как взаимосвязано, появится возможность диагностики той или иной ситуации. Отсюда та фраза про знание одного дистрибутива или Linux в целом, от проделанной работы по приобретению знаний, а не от самого факта установки Slackware.

Вы про высказывание: «Если вы знаете Red Hat, то всё, что вы знаете, — это Red Hat, если вы знаете Slackware — вы знаете Linux.»?
Да, во времена Red Hat, может, скорее всего, так оно и было. Но сейчас...
Приведу ещё одну цитату (уже не из того треда):
И вот тут выясняется следующий неприятный момент: времена, когда сконфигурировать в линуксе что угодно можно было, прочитав соответствующий HOW-TO, прошли. Совсем. Во-первых, линукс бурно эволюционирует, во-вторых, разные дистрибутивы эволюционируют в разных направлениях и разными темпами — так что, если программной совместимости тут не было и раньше, то теперь уже остаётся всё меньше совместимости хотя бы по методам настройки. То есть, описания конкретных методов настройки чего-либо оказываются разными как для разных дистрибутивов, так и для разных версий дистрибутив. Во-вторых, ориентация на десктопного пользователя приводит к тому, что в некоторых руководствах вообще не уделяется никакого внимания тому факту, что в линуксе и командная строка ещё есть. (c) Олег Артамонов Ссылка на сообщение.

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

Нет, там имелась в виду другая плохая привычка:
Вы идеально иллюстрируете мой тезис, что слакваристы склонны принимать примитивность за простоту. Это разные вещи. Простота достаточна, а примитивность — нет. (c) gvy Ссылка на сообщение.

так и практически в любом другом дистрибутиве никто не мешает поставить инструменты сборки и делать ровно то же самое, но при чём тут Slackware как система? Самодисциплина в документировании/версионности изменения настроек и сценариев сборки (как правило в журналах и VCS), опакечивании вносимых изменений в ПО, в использовании централизованного репозитория при разработке решений, если правильно путаю, слабо зависит от используемого дистрибутива.

Вы посмотрите на современные линуксы другими глазами. В них просто планка, на которой можно держать в голове «примерно столько же», позволяет делать гораздо больше или то же — гораздо быстрее. И при этом ничто(!) не мешает опуститься до уровня рассмотрения слаквари, хоть игнорировать зависимости, хоть переписать инитскрипты под себя (повторюсь — я говорю по опыту, это всё — давно пройденный этап). Просто при этом часть цивилизации может поотваливаться. (c) gvy Ссылка на сообщение.

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

Скажите, на ваш взгляд, на сегодняшний день, в каких сферах, и для решения каких задач можно использовать Slackware?
Опять же оговорюсь, не сочтите за провокацию; мне действительно хочется разобраться, кто в той дискуссии прав.
Где применяли/применяете Slackware лично вы?

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