Арчешкольник о Slackware на ночь глядя

Чесслово, возьми отдельный винт (или ноут) и запили туда AlpineLinux. Ничего лишнего нет и быть не может. Быстро отучает всякую хрень вместо софта ставить.

арч я не обновлял с сентября, - сейчас знал, что если обновлю, он все-равно сломается

Как арч может сломаться? :O

Я не знаю. Наверно, кому-то это нужно.

Я не знаю. Наверно, кому-то это нужно.

Сказки об элитарности поделия передаются из уст в уста.

K (ядра)

Точнее, исходные коды ядра.

На самом деле, это далеко не минимальная установка. Минимальную смотреть там:
http://wiki.linuxquestions.org/wiki/Slackware-Minimal_Install
http://slackwiki.com/Minimal_System
и в гугле.

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

не сразу нашел в каком пакете лежит netconfig

$ bzgrep «Package\|/netconfig$» /mnt/cdrom/slackware*/MANIFEST.bz2 | grep -B1 /netconfig$

или при установленном slackpkg:
# slackpkg file-search netconfig

Не надо выкидывать пакеты *-solibs-* и осторожнее относиться к пакетам серии L — и ваши волосы будут нежными и шелковистыми.

Сейчас задам глупый вопрос.

С серией «L» всё ясно, а вот пакеты *-solibs-*... как их позиционировать? Приведите пример такого пакета.

пакеты *-solibs-*... как их позиционировать?

Для уменьшения перекрестных зависимостей основные общие библиотеки (shared objects, .so) из крупных пакетов собраны в отдельные *-solibs-* (да, они дублируют содержимое пакетов-родителей). Например, glibc-solibs содержит библиотеки из glibc, сам пакет glibc вам не потребуется, пока не соберетесь что-то покомпилировать.
Допустим, вам не нужен SeaMonkey, но его библиотеки нужны много кому как из имеющегося в дистрибутиве ПО, так и из стороннего (собственно его библиотеками и объясняется наличие SeaMonkey в дистрибутиве).

Приведите пример такого пакета.

$ ls -1 /mnt/cdrom/slackware*/*/*-solibs-*t?z

Зачем?!?!?!??!?

Арчешкольник

Тяга к героическому преодолению собственноручно созданных препятствий не прошла же еще :)

Обычный™ пользователь Линукса юзает $DISTRIBUTIONNAME и для каждой его проблемы в гугле есть куча решений с описанием для имбецилов. :)

Пофиксено же

Зачем тогда новый DE/WM? :) Или это в параллельном мире происходит?

пакеты *-solibs-*

Вдогонку. Квинтэссенцией указаного подхода является aaa_elflibs, содержащий большинство основных *.so дистрибутива:

$ grep -c \\.so /var/log/packages/aaa_elflibs-* 
63

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

$ grep \\.so /var/log/packages/aaa_elflibs-* | \
while read f; do grep -Rl $f /var/log/packages; done | \
sort -u | grep -v aaa_elflibs | cat -n
     1	/var/log/packages/acl-2.2.51-x86_64-1
     2	/var/log/packages/alsa-lib-1.0.26-x86_64-1
     3	/var/log/packages/attr-2.4.46-x86_64-1
     4	/var/log/packages/bzip2-1.0.6-x86_64-1
     5	/var/log/packages/cups-1.5.4-x86_64-2
     6	/var/log/packages/curl-7.27.0-x86_64-2
     7	/var/log/packages/db42-4.2.52-x86_64-3
     8	/var/log/packages/db44-4.4.20-x86_64-3
     9	/var/log/packages/dmapi-2.2.10-x86_64-1
    10	/var/log/packages/expat-2.0.1-x86_64-2
    11	/var/log/packages/freetype-2.4.10-x86_64-1
    12	/var/log/packages/fuse-2.8.5-x86_64-1
    13	/var/log/packages/gcc-4.7.1-x86_64-1
    14	/var/log/packages/gdbm-1.8.3-x86_64-4
    15	/var/log/packages/glib2-2.32.4-x86_64-1
    16	/var/log/packages/gmp-5.0.5-x86_64-1
    17	/var/log/packages/gpm-1.20.1-x86_64-5
    18	/var/log/packages/libcap-2.22-x86_64-1
    19	/var/log/packages/libelf-0.8.13-x86_64-2
    20	/var/log/packages/libidn-1.25-x86_64-2
    21	/var/log/packages/libjpeg-v8a-x86_64-1
    22	/var/log/packages/libpng-1.4.12-x86_64-1
    23	/var/log/packages/libtermcap-1.2.3-x86_64-7
    24	/var/log/packages/libtiff-3.9.6-x86_64-1
    25	/var/log/packages/libtool-2.4.2-x86_64-1
    26	/var/log/packages/libusb-1.0.9-x86_64-1
    27	/var/log/packages/libusb-compat-0.1.4-x86_64-1
    28	/var/log/packages/lvm2-2.02.96-x86_64-4
    29	/var/log/packages/mm-1.4.2-x86_64-2
    30	/var/log/packages/ncurses-5.9-x86_64-1
    31	/var/log/packages/openldap-client-2.4.31-x86_64-2
    32	/var/log/packages/pcre-8.12-x86_64-1
    33	/var/log/packages/popt-1.7-x86_64-3
    34	/var/log/packages/readline-5.2-x86_64-4
    35	/var/log/packages/slang1-1.4.9-x86_64-1
    36	/var/log/packages/slang-2.2.3-x86_64-1
    37	/var/log/packages/svgalib-1.9.25-x86_64-2
    38	/var/log/packages/sysfsutils-2.1.0-x86_64-1
    39	/var/log/packages/xz-5.0.4-x86_64-1
    40	/var/log/packages/zlib-1.2.6-x86_64-1

А почему слаку называют системой-конструктором, из которой можно собрать то, что тебе надо? Когда я слышу «конструктор» мне предствляеться система, состоящая из некоторых готовых блоков, которые мне надо «собрать». Причем блоки унифицированы и хорошо подходят друг к другу. Необходимо один раз понять, как соединить и разъединить блоки, и дальше все пойдет само собой, ибо все блоки идентичны. По типу Lego, там блоки уже готовы и все, что требуется от пользователя - выбрать нужные. А если в дистрибутиве нет (де-факто) пакетного менеджера (ибо пакеты есть блоки), то какой же это конструктор? Это такой же конструктор, как Lego со множеством бесформенных кусков пластика, которые надо склеивать клеем, потом разделять долотом.

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

Пакетный менеджер есть, свою работу install/remove/upgrade выполняет прекрасно. Что сказали, то и поставит/удалит/проапгрейдит, в отличии от... Но зависимости автоматически не отслеживает. Если бы отслеживал, это вошло бы в непосредственное противоречие с вышесказанным. Помните примеры, когда после невинного «apt-get remove нечто» в никуда уходит полсистемы? В слаквари такого не бывает.

Другая сторона вопроса — крупные пакеты. Посмотрите, например, на пакет nmap. В его состав входит zenmap:

$ file $(which zenmap)
/usr/bin/zenmap: Python script, ASCII text executable

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

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

Пакетный менеджер есть, свою работу install/remove/upgrade выполняет прекрасно.

Вы про вот это? http://packages.slackware.com/ Мне довелось поиграть со слакой около года назад, надо было поставить postgresql, qemu, libvirt и никаких пакетов найдено не было. Пришлось ставить из сходников. Может подскажете, что я делал не так?

Помните примеры, когда после невинного «apt-get remove нечто» в никуда уходит полсистемы?

У меня за пять два года с ubuntu, и три с arch такого не было. Есть пруфы? И, кстати, надо быть весьма невнимательным, что бы согласиться на удаление огромного количества пакетов (в случае, если есть баг в пакетном менеджере).

Вы про вот это? http://packages.slackware.com/

Нет. Штатный пакетный менеджер Slackware называется pkgtools, в его состав входят installpkg, removepkg, upgradepkg, pkgtool, makepkg, explodepkg. Работает с файлами пакетов (кроме removepkg, который оперирует именами пакетов).

надо было поставить postgresql, qemu, libvirt и никаких пакетов найдено не было.

А их и нет в дистибутиве. Бывает. Пишем слакбилд (по образу дистрибутивных в /source/, или берем готовый, например, на slackbuilds.org), собираем в пакет, если поддерживаем несколько машин на Slackware, кладем в свой репозиторий, ставим пакет.

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

Причина не в баге ПМ, а в существующих зависимостях. Согласиться/не согласиться — это ваше решение, а решение ПМ — снести предложенное. Да, можно потребовать «забить» на автоматическое разрешение зависимостей при подобной операции ;-) но так и до полного их игнорирования недалеко.

Пруфы будут на подобное поведение? Ввиду багов ли или «существующих зависимостей»?

А их и нет в дистибутиве. Бывает.

Хорош конструктор, где блоки надо выпиливать самим. И ради чего? Что бы потом получить такой же пакет как в rpm/deb/pkg, но без зависимостей..

Пруфы будут на подобное поведение?

Собственных примеров сейчас не вспомню уже, а вот что-то подобное http://unixforum.org/index.php?showtopic=133584 частенько на глаза попадается.

Хорош конструктор, где блоки надо выпиливать самим. И ради чего?

Кому поп, кому попадья, а кому свиной хрящик.

Скоро еще попробую Gentoo

Правильный выбор. Слака не актуальна, Arch - хватит это терпеть

Помните примеры, когда после невинного «apt-get remove нечто» в никуда уходит полсистемы?

Нет, не помню. Хотя убунтой пользовался с 7.04, а дебианом с 3.0. В любом случае, apt-get сначала спрашивает.

В слаквари такого не бывает

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

поставьте nmap — пакетный менеджер не доставит вам в нагрузку питон с иксами

Но он поставит _нерабочий_ zenmap. Меня мало колышет процессорное время - оно стоит копейки. Меня мало трогает несколько «лишних» пакетов, которые занимают гроши на копеечном харде. Но когда проблемы неработающих программ решать вместо пакетного менеджера предлагается мне, чьё время в сотни раз дороже, тогда я начинаю смотреть на фанатов слаквари с плохо скрываемым презрением.

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

Как будто это что-то плохое.

Кроме того, такую тучу пакетов поддерживать в одиночку или небольшой командой не так уж и просто

Что говорит о перманентной смерти слаки.

а вот что-то подобное http://unixforum.org/index.php?showtopic=133584 частенько на глаза попадается

Вся суть проблемы одним постом ТС:

Признаю свою ошибку rolleyes.gif Нужно быть внимательнее

Вендоюзер?

Но он поставит _нерабочий_ zenmap.

Мне не нужен был zenmap, в остальном мы с вами схожи, питоновы сорцы zenmap-а

занимают гроши на копеечном харде

и это меня тоже совсем не беспокоит.

когда проблемы неработающих программ решать вместо пакетного менеджера предлагается мне, чьё время в сотни раз дороже, тогда я начинаю смотреть на фанатов слаквари с плохо скрываемым презрением

Да, ваш, ваш лось, дайте только седло сниму.
Кто ж вас заставляет-то? А жели вас не заставляют, чем оно вам помешало, позволите полюбопытствовать?

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

Как будто это что-то плохое.

Заметьте, не я про плохое говорил... По сути, не хорошее и не плохое, но так оно есть, в каждом дистрибутиве по-своему. Просто констатация факта.

говорит о перманентной смерти слаки

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

У вас спелчекер хромает. Он, почему-то, кучу ошибок в фразе «Взрослый юзер» не подчеркнул.

уж 20 лет будет от первого выпуска

А я недавно встречал до сих пор работающий экземпляр советского клона PDP-11.

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

И, ладно бы, пусть каждый делает то, что хочет, но все эта идеалогия противоречит логие - масса юзеров занимаются одним и тем же, вместо того, что бы автоматизировать процесс. И что, это сложная автоматизация? red had и ubuntu как примеры решений уровня предприятия справляются с этой задачей (и делают это очень хорошо), так что называть её нерешаемой нельзя. А юзеры слаки продолжают настаивать на выполнении этой работы опять и опять и, более того, гордятся этим.

А юзеры слаки продолжают настаивать на выполнении этой работы опять и опять

Расскажите это пользователям gentoo :-)

проблема

-- теоретический или практический вопрос, требующий разрешения, задача, подлежащая исследованию. (q) Толковый словарь Ушакова
Пожалуй, проблемы тут как раз никакой и нет.

это сложная автоматизация?

В математическом смысле понятия «сложная» — да, местами весьма, если вести речь о всех возможных вариантах сочетаний ./configure.

red had и ubuntu как примеры

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

гордятся этим

Если только наслушавшиеся о невероятной сложности установки Slackware и впервые сумевшие поставить.

$ ls -1 /mnt/cdrom/slackware*/*/*-solibs-*t?z

Вот что выдал:

slackware/a/glibc-solibs-2.15-i486-7.txz slackware/a/openssl-solibs-1.0.1c-i486-3.txz slackware/l/seamonkey-solibs-2.12.1-i486-1.txz

То есть я могу смело выкидывать ненужные мне пакеты из серий ap, x, xap и n? Верится с трудом. Я как-то удалил Akonadi, в результате поломался виджет lancelot.

Вы про вот это? http://packages.slackware.com/ Мне довелось поиграть со слакой около года назад, надо было поставить postgresql, qemu, libvirt и никаких пакетов найдено не было. Пришлось ставить из сходников. Может подскажете, что я делал не так?

Очень даже подскажу. В Арче ума хватает пользоваться AUR-ом? Что тогда мешает так же пользоваться SBo и подобными в Слаке?

Насколько понимаю, Akonadi нужен ему для отображения сведений о письмах KMail. Судя по
http://code.woboq.org/kde/kdeplasma-addons/libs/lancelot-datamodels/MessagesK...
Lancelot теоретически может быть собран без Akonadi. Дело за пересборкой пакета kdeplazma-addons, в который входит Lancelot.
Исходники и сценарии сборки дистрибутивного KDE на диске/зеркалах, например, http://slackware.osuosl.org/slackware64-14.0/source/kde/, KDE от AlienBOB — у него в source/. Слакбилд поддерживает сборку отдельных пакетов, см. комментарии внутри.

Расскажите это пользователям gentoo :-)

У них тоже нет автоматического разрешения зависимостей?

В математическом смысле понятия «сложная» — да, местами весьма, если вести речь о всех возможных вариантах сочетаний ./configure.

Только не надо дедукции, давайте продукцию :) На практике задача решается успешно.

если всё так здорово, как говорите, зачем так много, достаточно оставить один, правильно рассуждаю?

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

Очень даже подскажу. В Арче ума хватает пользоваться AUR-ом? Что тогда мешает так же пользоваться SBo и подобными в Слаке?

Хватает пользоваться только в исключительных случаях. Ибо из-за aur-а как раз и идут сказки про «поломалась система после апдейта!», «оно не обновляетсья из-за невозможности разрешить зависимости».

Читаем из wiki:

If a package becomes popular enough — provided it has a compatible license and good packaging technique — it may be entered into the [community] repository (directly accessible by pacman or abs).

Так что «поставь из aur-а» imo надо приравнять к «пользуйся testing». И когда все ломается, тут уж вини только себя.

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

Ага, особенно когда в убунте ищешь: -«Хде же этот терминал, пилять?!». Из всех тыканных мной дистрибутивов, арч единственный, который в одном конфиге вобрал все[почти], что нужно для настройки системы. Вот это KISS, вот это юзер-френд.

Ага, особенно когда в убунте ищешь: -«Хде же этот терминал, пилять?!»

а его искать не нужно, просто нажми alt+f2 и забей в появившемся окне «term»

все[почти], что нужно для настройки системы

огласите пожалуйста весь список

То есть я могу смело выкидывать ненужные мне пакеты из серий ap, x, xap и n? Верится с трудом. Я как-то удалил Akonadi

Akonadi не входит в ap, x, xap, n. А в остальном — кто ж вам запретит? Возможность смело выкидывать и смело возвращать есть — ПМ и выкинет и вернёт.
Правда смелость не освобождает от необходимости понимать, что делаете, поскольку и сами решения, и их последствия целиком на вас. Считайте, что у вас в руках пистолет, можете выстрелить в мишень, можете в ногу — дело ваше, но от того, куда будете направлять ствол, сама механика выстрела практически не зависит.
Например, критерий «ненужные мне» — он в чём заключается? Если «не нравится имя пакета» или «я это приложение ни разу не запускал», то это несколько ошибочное понимание ненужности. Возвращаясь к примеру с Lancelot-ом и Akonadi:
$ ldd /usr/bin/lancelot | grep akonadi
libakonadi-kde.so.4 => /usr/lib64/libakonadi-kde.so.4 (0x00007fbf7ad3f000)
libakonadiprotocolinternals.so.1 => /usr/lib64/libakonadiprotocolinternals.so.1 (0x00007fbf74783000)
Не будет на месте этой пары .so-шек, до выполнения кода lancelot-а дело даже не дойдёт. А дальше варианты: или разработчики предусмотрели возможность отвязать от (отключением при сборке или отложенной загрузкой с анализом результата), или кому-то до вас пришла подобная идея и была реализована (осталось только применить), или добро пожаловать в разработчики (по сути процесса внесения изменений).

вспоминай, что ставил-удалял

$ ls -t /var/log/packages | less
$ ls -t /var/log/removed_packages | less

Хм, хотя вряд ли кто в talks будет искать полезные советы :-)

Сразу говорю - комменты не читал. В защиту slackware просто хочу высказаться. Про то что slackware нельзя установить по принципу minimal cd - я не знаю откуда ты вообще такое взял. Я именно так несколько раз slackware и устанавливал - просто вручную выбирая какие пакеты ставить.

Речь шла о виндузятском подходе с разделами (зайди на диск дэ (/win_c, /mnt/win_c), потом в документы, …).

Когда они, кстати, уже нумерацию дисков сделают с «A», а то флоппики то уже вымерли и незаслуженно занимают первые 2 буквы алфавита? А если кто их и использует, пускай монтируются буквами с конца алфавита.

а то флоппики то уже вымерли

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

и незаслуженно занимают первые 2 буквы алфавита?

А как же куча легаси софта?
И эмуляторы дисководов очень даже часто цепляют на A, B.

А как же куча легаси софта?

Что это за софт такой, которому это так важно? В линуксах уже что только не меняли, подсистему аппаратуры раза три уже успели поменять (devfs, hal, udev, dbus).

1. Речь не о линуксах, а диках A и B
2. Нормальный софт, писаный профессионалами для того что-бы работал. И работает. Не переписывается с нуля раз в год. Так только мелкие баги бизнес логики исправляются(не чаще 2 раза в год наверное), вводятся микрофичи(тоже не чаще).

«Помните примеры, когда после невинного «apt-get remove нечто» в никуда уходит полсистемы? »

Еще как помню! Я конечно не разрешал удаления, но меня это всегда жутко бесило. «Ну почему, чтобы удалить эту дебильную программу я должен снести половину системы?!»

Меня еще поражает, когда дуалбутщики монтируют свои диски от винды /win_c, /win_d. У 75% такие директории есть)

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

да это вообще первоапрельский пост, как хочешь, так и понимай.

да это вообще первоапрельский пост, как хочешь, так и понимай.

-

04.01.2013 0:34:25

Чувак, это вообще то четвертоянварский пост)

ах черт, ну почему эти даты везде в рахных форматах? путаюсь :D

но тем более, да

убунту нужна

Fixed
Почему такая ненависть к бубну? Ну пилит космонавт, ну хочешь повые**ваться перед RedHat и Novell
А на нее нападают - как мухи на говно
Мне дистр нравиться) Гнум допиленный... и т.д
А арч, слака, суся - ну нето это фсио

~3h на сборку моей базовой ос(elinks,htop,mc,byobu,консольный шлак, xorg, firefox-bin, roxterm, libreoffice-bin, fluxbox, terminus fonts - console, liberation+djvu - GUI)
Сборка Кед по минимуму 3часа
Без семантики и всякой социальщины типа LXDE, токо красивыыыый - то ~2h(буст долго собираеться - а отсальное за 30 минут)
Interl Pentium Dual-Core E5700
Rootfs Ext4
HDD SATA
4gb RAM(последний раз собирал на 2 - 2месяца спустся снес генту, поставил вин8 и добавил 2гб оперы)
1mbps Wired network to router
Установка базовой ос с рапаковкой stage, portage и настройкой - 1h)
|=> все собирается за ~5-6h - а еще и всякий мелкий софт - wireshark, filezilla, thunderbird, vlc, skype - 30m)
Уж слишком быстро, не - причем оптимизация -O3 - с -O2 все собираеться за ~4h
Все гут!
Wine собирается за ~30m )

Короче, если учесть всё в целом, то выйдет часов 7-8, это как 1 стандартный рабочий день. И это ради того чтобы установить систему, которая будет выглядеть изначально ужасающе. Чтобы сделать ее красивой потребуется еще половина этого времени, если не больше. На установку Mint KDE у меня уходило минут 20 на ноуте 2012 года с целероном и двумя гигами оперативы, при том что выглядело это всё уже достаточно хорошо. Заметь, когда говорил про генту я учитывал идеальный случай, в котором не возникнет ни единой ошибки, ни единого ступора, а вообще всё как лом через говнораскаленным ножом по маслу.

Помните примеры, когда после невинного «apt-get remove нечто» в никуда уходит полсистемы?

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

поставьте nmap — пакетный менеджер не доставит вам в нагрузку питон с иксами.

 apt-cache depends nmap                                                                                                                                                                                :)
nmap
  Depends: libc6
  Depends: libgcc1
  Depends: liblinear1
  Depends: liblua5.2-0
  Depends: libpcap0.8
  Depends: libpcre3
  Depends: libssl1.0.0
  Depends: libstdc++6
  Depends: python

а где иксы?