LINUX.ORG.RU

Slackware 14.2 stable

 


6

14

После долгих 26 месяцев разработки вышла долгожданная Slackware 14.2.

Основные нововведения:

  • ядро Linux версии 4.4.14;
  • glibc 2.23;
  • gcc 5.3.0;
  • KDE 4.14.x;
  • добавлена поддержка PulseAudio;
  • udev заменён на eudev, а Consolekit — на Consolekit2 (чтобы избежать перехода на systemd в этом цикле разработки).

>>> Официальный анонс

>>> Ссылки для скачивания

★★★★★

Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 5)

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

ну вот возьмём дебиан, дистрибутив в топе, значит хорошая поддержка. А по факту имеем гно мамонта, где программы просто замораживаются, а не обновляются как в слаке. К тому же, эта т.н. «поддержка» чаще означает «заморозку на 5 лет, с постепенным выкидыванием работающего софта», а не поддержку приложений ~7 лет как в слаке.

Debian - хороший дистр, года 4 назад вроде как бы его репозиторий считался самым большим и поддержка хорошая. То что ты называешь «говном мамонта» - это такая фича, «стабильность» называется. Но моему внутреннему перфектционисту Дебиан сейчас не нравится вовсе не из-за этого. Слишком много костылей и мейнтейнерской отсебятины там где без них можно было обойтись.

любой мануал годен для слаки, если знаешь слаку.

У тебя не собирается слакбилд, сервис нужно поднять за несколько часов, где будешь искать подержку?

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

У тебя не собирается слакбилд, сервис нужно поднять за несколько часов, где будешь искать подержку?

Подержку ищи в мануалах и форумах! Надеюсь без «сервиса» ты ведь можешь хотя бы выйти в интернет, да?

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

У тебя не собирается слакбилд, сервис нужно поднять за несколько часов,

Из серии «раз в 100 лет и валенок стреляет».

где будешь искать подержку?

На ЛОРе, ясен пень.

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

Что с ним стало, что не собирается?
Где собранные ранее пакеты?
Это очередная иллюстрация к вопросу, зачем заново с нуля воспроизводить руками ранее отработанные проверенные решения.

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

поддержка хорошая. То что ты называешь «говном мамонта» - это такая фича, «стабильность» называется.

Знаешь что такое «поддержка хорошая»? Вот:

patches/packages/xscreensaver-5.34-i486-1_slack14.1.txz:  Upgraded.
  I promised jwz that I'd keep this updated in -stable when I removed (against
  his wishes) the nag screen that complains if a year has passed since that
  version was released.  So, here's the latest one.

А «хорошая поддержка» у дебиана — берём версию, и забиваем её обновлять 4-5 лет. Стабильные баги — стабильность по дебиановски.

У тебя не собирается слакбилд, сервис нужно поднять за несколько часов, где будешь искать подержку?

ты нарочно такую мелочь придумал?) Ну ладно, на такой вопрос есть специальный тред на LQ. Пойду туда, и спрошу ;)

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

Про «несколько часов» — вы уверены, что правильно поняли стоимость контрактов у RH, HP, иных вендоров с поддержкой в течение «нескольких часов»?
Что помешает собрать софт по spec или по deb.src (или по PKGBUILD или ebuild)?

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от sunny1983

У тебя не собирается слакбилд

Хм. Давно не видел такого.

сервис нужно поднять за несколько часов

Так если это новый сервис (откуда вы взяли это лядское виндовое сервис?) с которым вы ранее не сталкивались, рядли на любом другом дистре «за несколько часов» это получиться.
Если же это уже известные вам демоны, то никаких проблем на слаке не будет (исключение бинарно заточенные под конкретный дистр).
Имхо вы хэйтите просто ради хэйта. Без основательно.

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

А «хорошая поддержка» у дебиана — берём версию, и забиваем её обновлять 4-5 лет. Стабильные баги — стабильность по дебиановски.

Не только у деба. Уже много раз я здесь приводил примеры про проблемы ipv6 которые у слаки давно работают, а в этих «стабильных», «удобных» или руками код правь или так же из сурсов собирай новую версию (привет вашим зависимостям).

anc ★★★★★
()

Про «несколько часов» — вы уверены, что правильно поняли стоимость контрактов у RH, HP, иных вендоров с поддержкой в течение «нескольких часов»?

Я никогда не работал в фирме, у которой бы был контракт на поддержку RHEL, всё ещё впереди. А что плохого в том, чтобы вместо того чтобы ломать себе мозг просто повторить действия за сотрудником поддержки?

откуда вы взяли это лядское виндовое сервис?

А каким общим словом вы назовёте: Apache, KVM и Asterisk? Дистрибутив нужен не для того, чтобы дрочить на его «идеальность», а чтобы запускать под ним сервисы.

На ЛОРе, ясен пень.

Ну да, и я даже скажу кто скорее всего ответит: bormant и drBatty, а ещё есть куча материалов в Интернете. Но это касается программ, входящих в саму слаку, которые умещаются на одном DVD и которые надо ставить через «full install», иначе самому себе дороже. А вот как быть со всеми остальными программами, которые берутся у Алена или собираются из слакбилдов? Допустим не собирается слакбилд или собранная программа глючит. Мне вот так и не удалось нормально собрать ни одну систему виртуализации, и обратиться абсолютно некуда кроме рассылки на lists.slackbuilds.org.

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

Имхо вы хэйтите просто ради хэйта. Без основательно.

Я вообще никакой дистрибутив не ругаю, я принимаю плюсы и минусы дистров такими как они есть. Любой дистриб - это концепция. Концепция Debian - стабильность, концепция Slackware - не городить лишнее и собирать пакеты «укрупнёнными», концепция Fedora - внедрять новинки, концепция RHEL - Enterprice. Но идеального дистра нет ни одного.

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

концепция Fedora - внедрять новинки

Вы несколько позитивно смотрите на деятельность компании RedHat. В реальности всё не так. Концепция Fedora - тестировать работу нового ПО, которое потом попадёт в энтерпрайзные дистры. В своей деятельности RedHat не ставит задачу усовершенствования экосистемы Linux.

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

Мне вот так и не удалось нормально собрать ни одну систему виртуализации, и обратиться абсолютно некуда кроме рассылки на lists.slackbuilds.org.

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

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

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

Мне вот так и не удалось нормально собрать ни одну систему виртуализации

Эммм, это надо постараться. Усе есть на SB и собирается без ошибок у меня как минимум с 13.37 (может и раньше, не помню, но эта точно) А уж если вспомнить vb то надо оооочень постараться что бы не осилить его установку.

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

Вот тут было Slackware и системы виртуализации
Кстати непонятна логика концепции - запускать слакбилды под рутом. В большинстве дистрибов сборка пакетов происходит НЕ под рутом.

sunny1983 ★★★★★
()
Последнее исправление: sunny1983 (всего исправлений: 1)
Ответ на: комментарий от sunny1983

Кстати непонятна логика концепции - запускать слакбилды под рутом. В большинстве дистрибов сборка пакетов происходит НЕ под рутом.

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

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

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

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

Наркоман штоле? Устанавливать глобально — да. Но сборка *должна* производиться без привилегий всегда, когда возможно.

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

Вот тут было Slackware и системы виртуализации

Там же вам несколько человек написало, берите с оф сайта (а так же намекнули про старую тему насчет разделения vb на две версии). Вот как раз такая упертость и порождает мифы что в слаке все сложно.
Как выше написал анон похоже слака вас не любит :)

Кстати непонятна логика концепции - запускать слакбилды под рутом. В большинстве дистрибов сборка пакетов происходит НЕ под рутом.

Ага но инсталировать мы все-таки будет под рутом, так что не один фиг ли? Кстати я хз для всего ли требуется root. Хотя кажется что-то было что требовало юзвера обязательно, но могу и гнать.
ЗЫ Насчет рута, бсдэшный port вспомнился ведь таже фигня.

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

Но сборка *должна* производиться без привилегий всегда, когда возможно.

Выше я уже написал. Вы это bsd port расскажите.

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

Выше я уже написал. Вы это bsd port расскажите.

В OpenBSD порты отлично собираются обычным пользователем.

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

Но сборка *должна* производиться без привилегий всегда, когда возможно.

А если серьезно, то вот вопрос что вы подразумеваете под словом «сборка»? ./configure && make ? Так это выполниться (почти всегда) и из под пользователя. А вот например если при сборке пакета из уже скомпилированных бинарников нужно права поменять на собранные файлики тогда вас пошлют.

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

В OpenBSD порты отлично собираются обычным пользователем.

Ага, ага, port install какой-нибудь-апач.... верю сразу.

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

Документацию прочти, нуб звездатый. Это только в шлаке не слыхали про fakeroot, и хреначат слакбилды под рутом ради правильно выставленных прав на файлы.

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

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

Только в слаке пошлют, туда fakeroot не завезли.

anonymous
()

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

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

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

Только в слаке пошлют,

И правильно сделают.

туда fakeroot не завезли.

Лишняя сущность, поэтому она ненужна.

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

Зашибись. Мы собираем пакет в котором права таки надо поменять, и который потом установить из под рута. Ахренеть пакетик соберем с fakeroot.

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

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

Это да. Тоже и в других системах будет. Тут холивар: сборка->под пользователем, установка-из-под-рута vs все-из-под-рута :)

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

Зашибись. Мы собираем пакет в котором права таки надо поменять, и который потом установить из под рута. Ахренеть пакетик соберем с fakeroot.

Собирая пакет, ты запускаешь скрипты, которые что-то пишут в систему, скрипты твои собственные, ты их отлаживаешь, правишь по нескольку раз - ты совершаешь потенциально-опасные действия. Неужели ты хочешь сказать, что машину мейнтейнера защищать не нужно? Файлы с поменянными правами всё равно должны в пакет упаковываться, на диске менять им права не обязательно, fakeroot как раз решает.

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

На оффоруме Slackware на LQ периодически всплывают обсуждения сборки пакетов не от root, можно поискать, копий там было сломано на этот счет немало.
Приемлемые решения там тоже есть, вполне можно использовать, если подобный «пунктик» не оставляет в покое.
Если правильно путаю, есть случаи, когда сборка не от root-а ломается (например, в части X11).

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

Если правильно путаю, есть случаи, когда сборка не от root-а ломается (например, в части X11).

Почему-то в других дистрибутивах не ломается.

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

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

С чего бы это?

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

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

Файлы с поменянными правами всё равно должны в пакет упаковываться, на диске менять им права не обязательно, fakeroot как раз решает.

Нет не решает. Попробуйте сами fakeroot tar.... и потом посмотрите что будет.

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

Почему-то в других дистрибутивах не ломается.

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

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

Да честно говоря, понятно о чем речь идет. Я вот все жду правильного ответа, который реально на поверхности. Но вот хэйтеры оппоненты его почему-то не видят. А не видят его имхо по той же причине, «не собирают пакеты» они никогда. А ставят из реп бинарными.

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

Без RedHat не было бы того, что сейчас называется общим словом Linux. Так бы и топтались на месте вместе с Debian и подобными, в котором политика дистрибутива такая, что некоторые пакеты не обновляются годами (привет eclipse 3.8 июнь 2012 года и etc). Вы можете сказать, что сравнивать коммерческую организацию с некоммерческой неправильно, тогда сравним с Canonical. Каков ее вклад в развитие ядра, gtk и всего того, на чем базируется ее поделка Ubuntu? Я уже не говорю про пустые поделки типа Manjaro и подобные...

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

Никто не унимает заслуг редхат в разработке ядра и компонент СПО. Даже если бы её вклад был больше или равен вкладу энтузиастов. И так сойдёт. Аноним вроде говорил о целях.

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

Без RedHat не было бы того, что сейчас называется общим словом Linux.

Да особо и не поспоришь, так же как и с нехилым вкладом ябла. Но вот сама шапка нравиться (именно нравиться) перестала уже на уровне 8-ой версии. Пользовать-то можно все, да и приходиться, но есть варианты что нравиться, что нет, мне лично слака более симпатична. А в связи с сабжем еще больше, но все меняется и возможно и мои «симпатии» еще раз изменяться :)

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

А если бы не товарищ Сталин, то Линукса вообще бы не было.

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

Ну вот не надо на Manjaro гнать - вполне всё в ней тру и установщик для людей, а не красноглазиков. Для тех, кто хочет познакомиться с репами арча (читай свежим софтом) - самое оно поставить манжару.

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

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

Ну да, сборка делается в окружении fakeroot. Немыслимые усилия! :))

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

Попробуйте сами fakeroot tar.... и потом посмотрите что будет.

 /tmp % mkdir test
 /tmp % fakeroot tar cf test.tar test 
 /tmp % tar tvf test.tar 
drwxr-xr-x root/root         0 2016-07-20 07:12 test/

А теперь просто высший пилотаж, надеюсь хватит мозгов понять:

 /tmp % fakeroot sh -c 'chgrp adm test; tar cf test.tar test'
 /tmp % tar tvf test.tar
drwxr-xr-x root/adm          0 2016-07-20 07:12 test/

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

Хорошо, первое что приходит на ум.
Распаковали исходники ядра в /tmp, там же собрали. В чем подвох? Казалось бы, простейший случай, но требует знать про особенность и обработать ее вручную.

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

Если же вам не нужно ничего собирать, то вы промахнулись, слакбилды — это именно про сборку.

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

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от anonymous

Без RedHat не было бы того, что сейчас называется общим словом Linux.

Да нет, Linux та бы был, только вместо RedHat была бы другая какая-нибудь компания, типа FuckHard. Или, вы хотите тут нам сказать, что без RedHat не было бы ядра? А может говоря всё это вы показываете нам, что у вас рабский менталитет?

Так бы и топтались на месте вместе с Debian и подобными, в котором политика дистрибутива такая, что некоторые пакеты не обновляются годами (привет eclipse 3.8 июнь 2012 года и etc).

Интересно почему Дебиан должен топтатся на месте? Разве не Дебиан придумал формат deb, который появился даже раньше RPM.

У Дебиан сложная ситема тестирования пакетов. Там целая иерархия. В sid и experimental пакеты свежее. Не хочешь говно мамонта? Тогда бери пакеты например, из unstable.

Вы можете сказать, что сравнивать коммерческую организацию с некоммерческой неправильно,

Почему? Сравнивать то можно, только вы неспособны объективно анализировать.

тогда сравним с Canonical. Каков ее вклад в развитие ядра, gtk и всего того, на чем базируется ее поделка Ubuntu?

Давай сравним. Canonical нужен бизнесмену по имени Марк Шаттлворт, Canonical мне не нужен. Canonical запилил Unity для того чтобы он отслеживал действия пользователей. Canonical целенаправленно запилил Mir в ответ на появление Wayland, Марк хотел перехватить инициативу для того чтобы разработка нового графического протокола сосредоточилась в «стенах» Canonical. Когда появился Убунту все его воспринимали как высер Дебиана. Но когда этот «высер» старается что-то из-себя изоброжать, это право смешно и глупо.

Я уже не говорю про пустые поделки типа Manjaro и подобные...

Дебианщик то же самое может подумать об Убунту.

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

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

Не надо юлить.

fakeroot ./debian/rules

Без разницы, какое говно ты собираешь, оно соберётся. В Debian нет ни одного пакета, который не соберётся без рута. Для этого они написали fakeroot, и больше ничего не требуется.

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

Не надо юлить и сползать с темы, здесь обсуждаем не Debian.
http://slackware.osuosl.org/slackware-14.2/source/x/x11/

И что там про костыли и подпорки ради обеспечения возможности с сборки fakeroot? Только не надо здесь прятать голову в песок и кричать, что их нет :-)

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

И что там про костыли и подпорки ради обеспечения возможности с сборки fakeroot? Только не надо здесь прятать голову в песок и кричать, что их нет :-)

Их нет. Исходный код сам посмотришь? Это не сложно.

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

Что мы купим за эту цену

Защиту машины майнтейнера от потенциально-опасных действий

Имелось в виду оговорка «при сборке пакета», так?
Получим ли мы такую защиту при попытке установить собранный пакет? (Аргумент о том, что майнтейнеру тестировать установку пакета не нужно, мы считаем смешным и отклоняем без всяческих колебаний, так?)
Насколько актуальна частичная защита?

Не спорю, и намерение благое, и сама идея благая. Возможно, с тем объемом софта, что опакечивается в Debian-е, и тем количеством сопровождающих это даже разумно. Серебряная пуля? Безусловно нет. Случай с лишним пробелом в установочном сценарии шмеля (rm -rf /usr /lib/nvidia-current/xorg/xorg), надеюсь, еще не совсем забыт?

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

Защиту машины майнтейнера от потенциально-опасных действий

Весьма хитрое утверждение. Я тоже могу приблизительно так сказать: «Программные инсталяторы дистрибутивов должны устанавливать пакеты только обычному пользователю, ибо установка пакетов от суперпользователя потенционально-опасна».

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

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