Как там слака поживает?

Живёт. Осваиваю вот.

Что можешь сказать о свежести «пакетов», удобстве и т.д.?

В общем, впечатления какие?

Удобство? Это не про слаку, всё руками делается. Для понимания устройства UNIX-подобной системы сойдёт. На счёт свежести сказать не могу. Пока только с апачем и php разобрался, всё работает:)

Жива. А пакеты, по и прочее это уже от тебя зависит.

Норм, даже пакетный менеджер накатить можно. Гугл в помощь.

Доброе утро!
21:07:24

Хм, ОК.

Сижу на 14.2, до этого был current, но тут решил на релизе посидеть для разнообразия.

Тут gcc 5.3, когда в current 7.2; другие версии обычно и не замечаю.

Из неудобств, наверное, только выпиливание пшшшш-аудио, но то несколько пакетов пересобрать.

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

Окей, спасибо, начинает вырисовываться какая-то картина.

А применяешь для десктопа или как?

По поводу ПО:

• при полной установке ставится достаточно приличное количество пакетов, чтобы получить рабочую десктопную систему
• от текущих релизов отстает (сижу на 14.2), но к каждому пакету в репозитории приложен скрипт сборки, благодаря которому можно создать практически любую версию программы (в том числе и актуальную) при наличии соответсвующих исходников
• slackbuilds.org содержит огромное количество таких скриптов, которые соберут на полной установке то, чего не хватает
• для «толстяков» вроде KDE5 и Mate DE есть отдельные репы

Что не нравится: процесс разработки дистрибутива закрыт. Нет открытого багтрекера, нет открытого списка рассылки для разработчиков.

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

При этом надо самому разрулить зависимости и зависимости этих зависимостей да еще с учетом новых версий.

Есть какой-то конкретный пример?

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

Слакваръ это тоталитарная секта. Регулярно юзать этот артефакт не вижу практического смысла, ну а потыкать в ознакомительных целях можно и пожалуй даже нужно.

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

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

saahriktu недавно говорил, что планируется выход Slackware 15.0.

Для десктопа, на ноутбуке особых проблем тоже не было (что-то с драйверами для wifi возился, но это вроде везде так). Хотя при переходе в сон батарея разряжалась почему-то, как будто что-то оставалось работать, но я не разбирался, может дело в ядре.

Базовая часть в current'е редко отстаёт от свежих релизов. На slackbuilds.org многое тоже довольно оперативно обновляется.

Хотелось бы от тех, кто сидит на последних версиях узнать, что там в слаке с ПО, отстаёт/не отстаёт от текущих релизов

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

а по твоему вопросу - сижу на current с ktown от Alien Bob (к сведению - самый последний релиз кед, ну тот который frameworks-5.41/plasma-5.11.4/applications-17.12.0)

остальные стоковые пакеты по свежести впереди планеты всей, системдЭ нет(и хорошо!!!), всё остальное, в смысле прикладного софта «по хотелкам» как всегда всё ручками, про sbopkg тут уже сказали, облегчает жизнь, но мозг требуется как required, да.

В общем всё как всегда.

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

Я, например, этого бреда не говорил.

Я так и не увидел конкретного примера. Обсуждать какую-то дичь я не буду.

4.14.12 нвида работает, нормально все.

О, круто. А сами слакбилды, я о них только слышал. Это вообще что? Просто скрипты конфигурирования и сборки?

А вафля какого производителя?

А что в таком случае со «стабильностью»?

Broadcom

current, конечно, менее стабилен чем стабильная ветка, но и его некоторые юзают. В любом случае стабильнее чем всякие Арчи.

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

остальные стоковые пакеты по свежести впереди планеты всей, системдЭ нет(и хорошо!!!),

А что за инит?

Да, с броадкомом у меня что-то было проблемное и в дебе, вплоть до сборки дров руками когда-то. Сейчас Atheros, вроде как тут проблем нет.

Есть какие-то репо со всякими non-free штуками, чтобы дрова для nvidia поставить, всякое такое?

Тем более, что выборочно обновить отдельные пакеты до версий из current'а никто не запрещает.

От такого же даже apt поломаться может с зависимостями, там это как решают? Не получится систему засрать и сношаться потом, чистя и даунгрейдя ПО?

И официальный репозиторий и sbopkg не выделяют free/non-free (но есть отдельная free-версия слаки с libre-ядром). В sbopkg вижу nvidia.

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

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

Да, такой скрипт на выходе дает обычный пакет. К слову, у пакетов очень straight-forward структура и написать слакбилд (с пониманием в голове, разумеется) обычно нетрудно, учитывая, что можно делать тупо по аналогии с тем, что уже есть.

Понятно. Надо будет посмотреть.

Так в Слаке же нет зависимостей.

Не надоело повторять эту брехню?

Если пакет собрался в конкретной системе, то и работать он в ней будет идеально.

Да ну? Постоянно сталкиваюсь на Слаке с тем, что софт собирается, но не работает. Навскидку - musescore, wineasio.

Что не нравится: процесс разработки дистрибутива закрыт.

Неправильное утверждение.

Нет открытого багтрекера, нет открытого списка рассылки для разработчиков.

Закрытого багтрекера тоже нет. А есть форум linuxquestions.org там в разделе Slackware описываешь свою проблему на аглицком наречии. Там есть чувак с ником volkerdi можешь его поприветствовать.

Если что-то неработает или неадекватно себя ведёт. Думаешь...
1. Если это дистроспецифичная вещь пишешь письмо Патрику, где просто описываешь суть самой проблемы. О твоей проблеме он скорей всего не будет знать. В случае чего, если возможно, можешь присовокупить в письму логи. Не надо ему, тупо, писать в стиле: «Помоги вот это не работает». Сам понимаешь ведь, это глупо. Он не ответит.
2. Если это недистроспесифичная вещь, то связываешся с авторами программы. А Патрика просто проинформируй.

Да ну? Постоянно сталкиваюсь на Слаке с тем, что софт собирается, но не работает. Навскидку - musescore, wineasio.

Неудовлетворённая библиотека времени выполнения. Проги надо правильно собирать.

Именно по этому новичкам советуют делать полную установку дистрибутива. Потому как выяснять, какой он именно недоустановил пакет, дело неблагодарное и трудоёмкое.

Всегда ставил полную систему, кроме КДЕ и локалей к нему, а также некоторых убогих прикладных приложений из XAP.

У Вас какой-то специфичный, и, по ходу, поломанный из коробки софт.

что там в слаке с ПО, отстаёт/не отстаёт от текущих релизов

Ответ на этот вопрос в части дистрибутивного набора легко получить в табличке с версиями ПО на Distrowatch:
https://distrowatch.com/table.php?distribution=slackware

В части ПО, доступного для сборки по проверенным рецептам тоже несложно:
http://slackbuilds.org/
https://git.slackbuilds.org/slackbuilds/

В части ПО, собранного сообществом — посмотреть на зеркалах и проектах.
http://slackware.uk/
http://slackonly.com/
http:/slacky.eu/
http://slakfinder.org/
...

что нравится

Достаточно просто устроена, не пытается быть умнее администратора, позволяет сделать с системой что угодно (да, сломать тоже).

что не нравится

«Собственно Slackware» в дистрибутиве не так и много, ну что там может не понравиться? ^) Только что-то собирается начать не нравиться, смотришь, ан нет, не Slackware, апстрим ^)

с чего начинать

С чтения.
Почитать слакбук, почитывать http://docs.slackware.com, http://slackware.ru, http://slackware.su/

чего не делать

Зависит от того, что хотите в итоге не получить.

Slackware очень дружелюбная система. И к выбору друзей относится тоже ответственно.

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

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

на такой случай всегда есть
slackpkg clean-system

Так в Слаке же нет зависимостей.

Не надоело повторять эту брехню?

Если внимательно посмотреть, на что именно дан ответ, увидим:

выборочно обновить отдельные пакеты до версий из current'а никто не запрещает.

От такого же даже apt поломаться может с зависимостями, там это как решают?

Так в Слаке же нет зависимостей.

Речь о пакетном менеджере. Штатный пакетный менеджер Slackware (pkgtools, slackpkg) не отслеживает зависимостей, его подобные действия не могут поломать — в данном случае нечему ломаться.

Наличие зависимостей у бинарных (и не бинарных,-- например, сценарии) файлов на пакетном менеджере не отражается никак. Безусловно, зависимости нужны, чтобы работал зависящий бинарник/сценарий, с этим никто не спорит. Но достигается это, опять-таки, штатными действиями ПМ, а не его починкой.

Наличие на диске файлов с неудовлетворенными зависимостями не является какой-то из ряда вон выходящей ситуацией, суперцели избегать подобной ситуации никто не ставил. Из-за того, что в пакете nmap также лежит сценарий на питоне и X-овая обвязка никто не потребует от меня поставить дополнительно питон и иксы. Но если мне потребуется использовать одно или другое тем или иным образом, питон или libX сотоварищи придется обеспечить, никто не спорит... Просто в отличие от Debian 1) нет нарезки полученного из одного тарбола исходников бинарников на лапшу из отдельных пакетов, 2) нет правила, что поставленный пакет должен самонастроиться и запуститься. Установка отдельно, конфигурирование и запуск отдельно (интерфейс конфигурирования пакеты предоставлять могут, но не обязаны).

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

Напомнило:
 — Доктор, когда я делаю так (со всей дури бьется головой в стену), у меня потом целый день голова болит.
 — А вы так не делайте.
(q) бородатый анекдот

А также:
https://www.youtube.com/watch?v=GODlHKTItg0
(Ъ: разруха не в клозетах, а в головах; каждому нужно заниматься своим делом надлежащим образом).

# ( cd /var/log/packages/; ls wget-* )
wget-1.19.2-x86_64-1_slack14.2         # одна версия

# slackpkg upgrade wget
# ( cd /var/log/packages/; ls wget-* )
wget-1.19.3-x86_64-1_slack14.2         # снова одна версия

# ( cd /var/log/packages/; ls slack-* )
slack-2.9.0-x86_64-1_SBo               # одна версия

# sbopkg -i slack
# ( cd /var/log/packages/; ls slack-* )
slack-3.0.2-x86_64-1_SBo               # снова одна версия

# upgradepkg пакет-другая_версия-x86_64-1.txz
# ( cd /var/log/packages/; ls пакет-* )
пакет-другая_версия-x86_64-1           # полагаю, идея понятна хотя бы в общих чертах ^)

Пока Патрику слака интересна - слаке быть. Не будет интересно - слака помрет.

Ну а как иначе-то? Конечно помрет. Уверены, что никому не потянуть форк?

Спасибо за обилие ссылок, теперь понятно, с чего начинать хотя бы.

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

О, вот это интересно. То есть, я все же могу на уровне штатной установки пакета натыкать, какой же функциональности я хочу, избавившись, возможно, от линковки с нежеланными библиотеками, как во фряхе или генте?

Какие ещё неразбериха и хаос? Максимум - ряд бинарников не могут найти некоторые библиотеки. Это спокойно решается пересборкой пакетов, к которым они относятся.

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

Речь была о другом конфигурировании — например, timeconfig, netconfig, ... их можно увидеть, запустив pkgtool и выбрав Setup. Это те же сценарии, что вызываются установщиком на шаге CONFIGURE.

Но «натыкать» тоже никто не запретит, исходники, из которых собраны бинарные пакеты, лежат на зеркале в дереве дистрибутива:
в /patches/source — для выпущенных после релиза обновлений
в /source — для собственно релиза
Внутри каталога с именем пакета тарбол исходников, патчи, если применялись, и SlackBuld, который можно исправить как хочется и затем выполнить для пересборки пакета, потом upgradepkg --reinstall собранному пакету и вуаля. Что-то вроде:
http://www.slackware.ru/wiki/BugFix/13.1/su
http://www.slackware.ru/wiki/Пересборка_пакета

Система очень просто устроена, но, к счастью, не проще, чем необходимо.

Всегда ставил полную систему, кроме КДЕ и локалей к нему, а также некоторых убогих прикладных приложений из XAP.

Если вдруг собираешь пакет не содержащийся в репозитории например, из SlackBuilds.org, возьмём MuseScore. Там написано: «This requires: jack2, portaudio, lame, qt5-webkit», то есть перед сборкой MuseScore сначала собираешь и устанавливаешь эти 4 пакета. В свою очередь qt5-webkit требует пакета qt5, так что перед сборкой qt5-webkit сначала собираешь и устанавливашь qt5. А qt5 требует libxkbcommon, libinput. Перед сборкой qt5 предварительно собираешь и устанавливаешь пакеты libxkbcommon и libinput.

Но этот ад зависимостей можно отрегулировать конфигурацией собираемых пакетов, в самом SlackBuild это строка начинающаяся с < ./configure \ " >

Но перед тем как конфигурировать пакет тебе придётся распаковать source файл и глянуть на опции конфигурирования конкретного пакета.

Можно и «схитрить». Пакет «А» зависит от пакета «Б», в свою очередь пакет «Б» зависит от пакета «В». Если пакет «Б» собирается и даёт пакету «А» необходимые библиотеки времени исполнения, то пакет «В» собирать необязательно. Но тогда в этом случает пакет «Б» нормально работать не будет. Но ведь нам сам пакет «Б» не нужен, нам ведь нужен пакет «А», не так ли?

Если вдруг собираешь пакет не содержащийся в репозитории например, из SlackBuilds.org, возьмём MuseScore. Там написано: «This requires: jack2, portaudio, lame, qt5-webkit», то есть перед сборкой MuseScore сначала собираешь и устанавливаешь эти 4 пакета. В свою очередь qt5-webkit требует пакета qt5, так что перед сборкой qt5-webkit сначала собираешь и устанавливашь qt5. А qt5 требует libxkbcommon, libinput. Перед сборкой qt5 предварительно собираешь и устанавливаешь пакеты libxkbcommon и libinput.

Если собранное другими не устраивает, и обязательно нужно собрать самому (qt5 тут далеко не подарок), то все давно украдено за нас:

# sqg -p MuseScore
# sbopkg -i MuseScore.sqf

# slackpkg install libxkbcommon libinput qt5
# sbopkg -ki MuseScore.sqf