Почему вы выбрали slackware

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

Со слакой проще ставить из исходников. А ещё есть слакбилды.

А на slackware возможна жизнь без python ?

Мне кажется, что ничего системного на нём не написано. Так что должно быть возможно.

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

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

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

Мне такое не было нужно.

Ок. Я не от балды интересовался, у меня для этого есть причины. Если я не ошибаюсь, portage написан на python, поэтому все дистрибутивы которые используют portage, для меня автоматически отпадают.

Мне такое не было нужно.

Как не нужно? Ты поставил слаку и вообще не обновлял? Или у тебя нет необходимости в софте, которого в оф. репах нет?

Я думал речь о каком-то синхронизированном обновлении множества систем. А так мне хватает slackpkg+ + sbopkg. Во втором есть зависимости при желании (называются «queues»). Но есть и другие менеджеры пакетов, аналоги apt-get, в аналогичных темах про Slackware это уже расписывали.

Наверное за счет системы управления пакетами. Ну и выбор, насколько помню, он был, как протест против наездов на Патрика, который лет 15 назад был конкретным. Не помню из-за чего, но на лоре его склоняли, как билла гейтса, сопоставимо. Вот так, ЛОР таки оказывает влияние, зачастую противоположное.

ЗЫ. Все это отсылка в прошлое, больше 10 лет тому, как там слака в наши дни не знаю. Сейчас выбор был не дистрибутива, а дистрибутива с KDE. Поэтому KDE Neon.

Ставь, не боись. Один из лучших, чистых, стабильных (включая current), реально шустрых дистров. Есть некие неудобства в начале использования, которые со временем исчезают. Идём за инфой на wiki или форум. Потом перелезть на какой-нибудь деб или рпм дистр просто не реально, т.к. кругом одни глюкодромы.

Интересуюсь в первую очередь потому, что есть желание себе поставить на десктоп.

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

Относительно установки софта с зависимостями: во время устаноки нужно ставить всю систему с диска. В качестве исключения можно некоторые пакеты не ставить. Я, например, не ставлю akonadi, php, метапакет kde, метапакет xap...
Для ручной установки используются утилиты pkgtool, для установки с репозитория и обновления - slackpkg. Если нужно больше софта (в официальном репозитории мало пакетов), можно собирать со слакбилдов: slackbuilds.org. Там в описаниях пакетов можно найти зависимости. Для автоматизации можно использовать sbopkg и с его помощью собирать пакеты с учетом зависимотей, предварительно подготовив queue файл. Иногда, если много зависимостей, это может напрягать. Из неофициальных, я пользуюсь репозиторием alienbob'a (тоже в описаниях пакетов можно найти зависимости, если есть), подключив его через slackpkg+.
Что касается стабильной ветки, она может сильно долго быть стабильной, как сейчас 14.2. В таком случаи я переключаюсь на current ветку и обновляюсь аккуратнее.

обновление с пересборкой сразу везде

Забавная формулировка ;-)
Если правильно понял, о чем речь, то мухи отдельно, котлеты отдельно.
Сборка из исходников в бинарные пакеты.
Установка на машины бинарных пакетов.
Доставка пакетов любой надстройкой над pkgtools: slackpkg/slackpkg+, slapt-get, есть еще несколько новомодных, но на память не назову. Соответственно источником может быть или общий каталог с пакетами или свое хранилище (репозиторий), сценарий для построения/обновления его метаинформации есть готовый.

Про зависимости был бы смысл говорить, если в наличии реально большое количество индивидуальных наборов софта. Тем не менее никто и для этого случая не отменял
# slackpkg install-template
В реальности почти всем машинам нужен примерно одинаковый софт, если где-то поставить лишнего — обычно невелика беда, цена места на носителях ниже, чем усилия по художественному выпиливанию индивидуальных профилей ;-)
А если установка списком вот совсем-совсем не подходит, slapt-get все еще есть и поддерживается.

Есть смысл поставить Slackware и начать пользоваться, возможно тогда вопросы станут прагматичнее.

Потому, что current свеж и стабилен, и свой софт собрать довольно просто, и это надо любить, знать систему. Не поддерживаю идею ставить всё с установочного dvd/cd, рекомендую поставить мин систему и уже наращивать по потребностям. Но, имхо, для десктопа всё же лучше Mint/Ubuntu/Arch - проще и быстрее установка софта, никаких заморочек, в слаке же нужно понимать что делаешь и зачем.

Почему вы выбрали slackware

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

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

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

Потому что мы русские физики.

☑️ Не использую Slackware (99.8% проголосовавших)

Русский физик же.

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

Ну дык в то время начала 90-х ядра 1.0 что ещё можно было выбрать? Ягдрасил? Да ну нафиг.

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

Долгие годы сидел на слаке, но так и не дождавшись 15 версии свалил на дебиан.

Ничосе, никогда бы не подумал. Вообще правильный выбор, Debian гораздо более предсказуем и bus factor там не проблема.

1. Выбрал сто лет назад потому, что скрипты в /etc/init.d были раз в 10 проще и короче, чем в rh или suse. Возможно, будь тогда systemd, слаку бы не рассматривал.
2. В дистрибутиве slackware нет пакетов с зависимостями, но пакетный менеджер может и умеет. Есть проект-близнец Salix с зависимостями.
3. Пересборкой не занимаюсь, апдейчу с репозитария Salix.

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

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

Установил Slackware первой системой (в 2000 году, давно это было). Простая и понятная. Потом стал замечать, что вся жизнь проходит в /usr/local, так что перешел на Debian, так там и остался.

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

• В ней на мой взгляд самая правильная стабильность в мире Linux.
• Простой формат пакетов, простые слакбилды, можно всегда легко что то подправить, написать свое. В Debian же все куда сложнее, в арче pkgbuild'ы простые, но это не стабильный дистрибутив, а желания перекомпилировать что то постоянно у меня нет.
• Гибкость! Без напряжения меняю системные либы на те что мне нужно и не «борюсь с системой» %) В других же дистрах что то будет мешать постоянно, например зависимости поломаются.
• slackbuilds.org - это прекрасно, и качество сборочных скриптов выше чем у arch'a (все не смотрел, но для программ что я использую - да).
• В интернете куча информации, и на все вопросы мне всегда отвечали.

Ну и чисто почему я выбрал:

• В 14.2 отлично собран Xfce, могу точно сказать что лучше сейчас нигде просто нет. Ну может только в Xubuntu, но это если любить gtk3.
• В Slackware практически все работает без багов и каких то поломок у меня, с другими же дистрами беда.

Потому что KISS — это поцелуй мозгу от архитектора.

Патрег бох!

Ты, видимо, путаешь slackware и gentoo. Portage - это из gentoo.

В дистрибутиве slackware нет пакетов с зависимостями

Что, правда? KDE работает без QT, а XFCE — без gtk? Бегу ставить!

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

Что, правда? KDE работает без QT, а XFCE — без gtk? Бегу ставить!

Насчёт работает - не обязательно, но зато установка чего-либо не притаскивает в систему прибитые гвоздями, но совершенно не обязательные зависимости. Например установка okular не притащит в систему аконади с mysql, wallet и phonon, при этом okular вполне будет работать.

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

Ну да, конечно: скажем, ставя wpa_supplicant, получаешь еще и wpa_gui. И плевать, что этот gui тебе 100 лет не сдался.

Нет, не путаю. И portage не только в gentoo. Я просто хочу попробовать slackware и интересуюсь, нет ли там системных, прибитых гвоздями зависимостей от python. Вроде бы довольно понятно пояснил, что мне нужно и ни у кого, кроме тебя не возникло вопросов. Забыл сказать , еще мне не нужно pulseaudio, и нужен всегда свежий IceWM.

Ну да, конечно: скажем, ставя wpa_supplicant, получаешь еще и wpa_gui. И плевать, что этот gui тебе 100 лет не сдался.

Ну так оно же Qt с иксами не притаскивает.

Ну так оно же Qt с иксами не притаскивает.

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

wpa_gui - часть wpa_supplicant, вообще-то. В слаке нет традиции делать из одного сырца 100500 мелких пакетов. Кому это не нравится - использует другие дистры и всё. А я, например, нахожу такой подход достаточно удобным. Не понравилось что-то - можно пересобрать и потом просто обновить один единственный пакет, а не тонну.

wpa_gui - часть wpa_supplicant, вообще-то

Нет. Хотя дерево исходников одно, supplicant работает без gui:

└► pgrep wpa_supplicant ; which wpa_gui
1000
/usr/bin/which: no wpa_gui in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/dexpl/bin)

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

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

Нет. Хотя дерево исходников одно, supplicant работает без gui:

wpa_supplicant и есть дерево исходников. Почему в сооствествующем пакете не должно быть wpa_gui?

Оукей, а как быть с тем, что нужные зависимости не подтягиваются?

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

Почему в сооствествующем пакете не должно быть wpa_gui?

Встречный вопрос: зачем тянуть wpa_gui туда, где он не нужен?

Нужные кому?

Всякому, кто захочет-таки запустить wpa_gui и у кого до сего момента не было QT-зависимого софта.

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

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

Встречный вопрос: зачем тянуть wpa_gui туда, где он не нужен?

Затем, что он в пакете wpa_supplicant.

Всякому, кто захочет-таки запустить wpa_gui и у кого до сего момента не было QT-зависимого софта.

Зачем кому-то запускать wpa_gui на машине без иксов, например?

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

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

Что? Ещё недавно ты мог поставить KDE без qt, и материться, что qt не поставилось. Потом материться, что libjpeg не поставилось. Потом - ffmpeg... Потом плюнуть и подключить репу с зависимостями.

еще мне не нужно pulseaudio

С этим было именно так по 14.1 включительно, в нынешнем current (будущем 15.0) есть выбор, использовать PA или нет.
А вот в 14.2 для полного избавления от PA придется немного поработать руками, изкоробочного варианта без PA не предоставлено.

ставя wpa_supplicant, получаешь еще и wpa_gui. И плевать, что этот gui тебе 100 лет не сдался

Авторы wpa_supplicant почему-то посчитали, что стоит распространять исходники wpa_supplicant и wpa_gui в одном тарболе.

Тем не менее, речь всего лишь про

# ls -lh $(which wpa_gui)
-rwxr-xr-x 1 root root 666K Oct 17  2017 /usr/bin/wpa_gui

# rm /usr/bin/wpa_gui

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

Одна из самых приятных новостей за неделю.

Тогда current конечно. А есть какой-нибудь минимал изо, чтоб можно было по сети устанавливать, иди такого в slackware не практикуется ? Я просто не в теме, потому и спрашиваю. 4 года на раче и все привычки тамошние.

Обращайся еще, если тебе так мало для счастья надо.

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

Если считать Slackware только то, что релизит Патрик, то нет ;-)
Но поскольку установочный носитель — это отдельно дерево пакетов и отдельно собственно установщик в initrd.img, который умеет брать пакеты не только с установочного носителя, но и в том числе по сети, то его не может не быть (собрать носитель без дерева пакетов даже проще, чем с) ;-)

Для стабильных (номерных) выпусков:
http://www.slackware.com/~alien/slackboot/mini/

Для current:
http://bear.alienbase.nl/mirrors/slackware/slackware64-current-iso/ slackware64-current-mini-install.iso
http://bear.alienbase.nl/mirrors/slackware/slackware-current-iso/ slackware-current-mini-install.iso

Есть смысл сразу поставить целиком как минимум наборы A (базовая система), AP (консольные приложения, на самом деле отсюда минимально желателен ap/slackpkg, но не заниматься же попакетным выбором только ради его одного ;-)), L (библиотеки), N (сеть), X (иксы). Попакетным выпиливанием/добавлением заняться уже изнутри установленной системы. Это самый простой и необременительный путь.

Зачем кому-то запускать wpa_gui на машине без иксов, например?

Не «без иксов», а «без qt, хотя и с иксами». Представь себе, такие бывают.

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

Если по-твоему ручное разрешение зависимостей — не пердолинг, то что такое пердолинг?

// Я когда-то узнал, что KDE3 для работы требуют libart_lgpl и без него не запускаются. Живи теперь с этим оч-чень нужным знанием и ты.

Тогда current конечно.

Тут есть маленько нюансов.
1) это ветка в разработке — суть почти роллинг — это значит, что частенько меняются версии библиотек, что в ChangeLog.txt отражается как «so-version bump». Следовательно, если есть самосборный софт, зависящей от такой библиотеки, то
а) повременить с обновлением,
б) пересобрать такой софт, или
в) воспользоваться грязным хаком, сделав симлинк новой библиотеки со старым именем (если изменения в интерфейсе библиотеки не столь существенны).
2) slackbuilds.org рассчитан только на стабильные версии, для current Ponce на github-е ведет отдельную ветку, sbopkg про нее в курсе, нужно не забыть выбрать ее в качестве основной.
3) какое-то время может быть сломана, куда уж без этого. Правда не вспомню, когда это было в последний раз. Но когда-нибудь снова будет, это абсолютно точно.

То есть такого беззаботного варианта как со Slackware stable — поставил и дальше накатывай только обновления безопасности — увы, не выйдет.

Что?

То самое, что несмотря на то, что, скажем, KDE требуют qt, слаквоеды из флейма в флейм заявляют, что в слакве, мол, нет зависимостей. Нет бы так и сказать: зависимости есть, только убогий менеджер пакетов слаквы о них ничего не знает, но нам это в кайф, а остальные могут смотреть рис. 1.

Потом плюнуть и

…выкинуть слакву.

Авторы wpa_supplicant почему-то посчитали, что стоит распространять исходники wpa_supplicant и wpa_gui в одном тарболе.

Из этого как-то вытекает необходимость совместного распространения соответствующих бинарников? Вопрос риторический.

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

Уверяю, что это не единственный пример «прибитых гвоздями, но совершенно не обязательных зависимостей».