Исправление bormant, (текущая версия) :
Что я выиграю/потеряю, если буду использовать дефолтную поставку с лило и мбр в режиме легаси, вместо граба или елило и гпт?
Тут с какой стороны посмотреть.
1) Если система не единственная, может захотеться не морочиться с расширенными разделами, а основных в MBR только 4. В GPT все основные, да и ограничение на как на их число так и на размер поширше ;-)
2) Если рядом есть Windows, то наверное захочется сохранить возможность перезагрузки в туда. Windows в этом отношении капризна, умеет либо MBR+Legacy, либо GPT+(U)EFI, причем определяется сие на момент ея установки.
3) Для Linux возможно и GPT+Legacy, если вдруг зачем-то захочется.
Как у лило дела с dm-crypt?
https://mirror.yandex.ru/slackware/slackware-14.2/README_CRYPT.TXT
Потребуется отдельный раздел под /boot, если шифровать и корень.
Распространяют слухи, что скоро релиз 15 версии.
Еще даже бету не объявляли, не то что кандидатов на выпуск, коих бывает 3 и больше.
Если я поставлю 14.2 насколько много придется возиться, чтобы обновиться до 15-ой?
Обычно это выглядит так:
https://mirror.yandex.ru/slackware/slackware-14.2/UPGRADE.TXT
https://mirror.yandex.ru/slackware/slackware-14.2/CHANGES_AND_HINTS.TXT
или даже так (изменив предварительно зеркало в /etc/slackpkg/mirrors)
# telinit 3
# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system
Чем это грозит для системы?
После этого что-то из стороннего софта наверняка потребует пересборки.
В 15.0 точно будут изменены пути /var/log/{,removed_}{packages,scripts}, но для совместимости останутся симлинки по старым путям.
Как правильно поддерживать ядро, отличающееся от дефолтного? Например, я хочу использовать последнее lts ядро, я его собираю. Гарантий, что оно заведется нет, т.к. могут быть нужны зависимости свежее тех, что в системе. Как это организовано у слакварщиков?
Текущее ядро пока от glibc не настолько убежало, чтобы не собираться в 14.2 ;-)
Обычно достаточно в /etc/lilo.conf оставить загрузку дистрибутивного kernel-huge или вовсе пользоваться загрузочным носителем для ремонта. Можно его (носитель) и вовсе в загрузчик пристегнуть, чтоб не искать при случае ;) :
http://docs.slackware.com/howtos:slackware_admin:booting_install_from_hdd
Каким образом проще переносить собранные пакеты на другие машины? Есть для этого готовые решения или все костыляешь сам?
slackpkg отлично работает с простым каталогом как с источником пакетов, NFS и другие способы монтирования по сети, а равно и флешки тоже никто не отменял, плагин slackpkg+ дает возможность использовать более одного источника.
Если хочется организовать именно хранилище «по-взрослому» (PACKAGES.TXT и прочие спецфайлы), то у Эрика есть готовые сценарии для этого. Можно и зависимости для slapt-get прописать ;-) и даже автоматически ;-)
Как обстоят дела с качеством пакетов, например, со slackbilds.org? Можно им доверять?
Как правило да. Но все-все тамошние пакеты я не ставил ;-)
Но отношение к проекту у ведущих его довольно серьезное.
Как в целом система с т.з. безопасности (дырявости софта)? Понятно, что исключив systemd и pam много 0-day отпадают сами собой, но старый софт намекает на то, что там может быть много дыр, которые уже нашли.
Выпуски поддерживаются обновлениями безопасности:
https://mirror.yandex.ru/slackware/slackware-14.2/ChangeLog.txt
# slackpkg update; slackpkg install-new; slackpkg upgrade-all
По шкале от 1 до 10 оцените трудность обслуживания одной системы, если ей начинает заниматься, скажем, продвинутый юзер линукс (умеет в терминал, читать доки на английском, гуглить и имеет 1-2 часа времени в день)
1 ^)
Совет: не стесняйтесь спрашивать — часто дистроспецифичные привычки из «прошлой жизни» могут немножко вредить. В остальном — линукс как линукс, общие знания вполне применимы (правда общая область в последнее время несколько сузилась за счёт «нового и передового» в других дистрибутивах).
Исправление bormant, :
Что я выиграю/потеряю, если буду использовать дефолтную поставку с лило и мбр в режиме легаси, вместо граба или елило и гпт?
Тут с какой стороны посмотреть.
1) Если система не единственная, может захотеться не морочиться с расширенными разделами, а основных в MBR только 4. В GPT все основные, да и ограничение на как на их число так и на размер поширше ;-)
2) Если рядом есть Windows, то наверное захочется сохранить возможность перезагрузки в туда. Windows в этом отношении капризна, умеет либо MBR+Legacy, либо GPT+(U)EFI, причем определяется сие на момент ея установки.
3) Для Linux возможно и GPT+Legacy, если вдруг зачем-то захочется.
Как у лило дела с dm-crypt?
https://mirror.yandex.ru/slackware/slackware-14.2/README_CRYPT.TXT
Потребуется отдельный раздел под /boot.
Распространяют слухи, что скоро релиз 15 версии.
Еще даже бету не объявляли, не то что кандидатов на выпуск, коих бывает 3 и больше.
Если я поставлю 14.2 насколько много придется возиться, чтобы обновиться до 15-ой?
Обычно это выглядит так:
https://mirror.yandex.ru/slackware/slackware-14.2/UPGRADE.TXT
https://mirror.yandex.ru/slackware/slackware-14.2/CHANGES_AND_HINTS.TXT
или даже так (изменив предварительно зеркало в /etc/slackpkg/mirrors)
# telinit 3
# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system
Чем это грозит для системы?
После этого что-то из стороннего софта наверняка потребует пересборки.
В 15.0 точно будут изменены пути /var/log/{,removed_}{packages,scripts}, но для совместимости останутся симлинки по старым путям.
Как правильно поддерживать ядро, отличающееся от дефолтного? Например, я хочу использовать последнее lts ядро, я его собираю. Гарантий, что оно заведется нет, т.к. могут быть нужны зависимости свежее тех, что в системе. Как это организовано у слакварщиков?
Текущее ядро пока от glibc не настолько убежало, чтобы не собираться в 14.2 ;-)
Обычно достаточно в /etc/lilo.conf оставить загрузку дистрибутивного kernel-huge или вовсе пользоваться загрузочным носителем для ремонта. Можно его (носитель) и вовсе в загрузчик пристегнуть, чтоб не искать при случае ;) :
http://docs.slackware.com/howtos:slackware_admin:booting_install_from_hdd
Каким образом проще переносить собранные пакеты на другие машины? Есть для этого готовые решения или все костыляешь сам?
slackpkg отлично работает с простым каталогом как с источником пакетов, NFS и другие способы монтирования по сети, а равно и флешки тоже никто не отменял, плагин slackpkg+ дает возможность использовать более одного источника.
Если хочется организовать именно хранилище «по-взрослому» (PACKAGES.TXT и прочие спецфайлы), то у Эрика есть готовые сценарии для этого. Можно и зависимости для slapt-get прописать ;-) и даже автоматически ;-)
Как обстоят дела с качеством пакетов, например, со slackbilds.org? Можно им доверять?
Как правило да. Но все-все тамошние пакеты я не ставил ;-)
Но отношение к проекту у ведущих его довольно серьезное.
Как в целом система с т.з. безопасности (дырявости софта)? Понятно, что исключив systemd и pam много 0-day отпадают сами собой, но старый софт намекает на то, что там может быть много дыр, которые уже нашли.
Выпуски поддерживаются обновлениями безопасности:
https://mirror.yandex.ru/slackware/slackware-14.2/ChangeLog.txt
# slackpkg update; slackpkg install-new; slackpkg upgrade-all
По шкале от 1 до 10 оцените трудность обслуживания одной системы, если ей начинает заниматься, скажем, продвинутый юзер линукс (умеет в терминал, читать доки на английском, гуглить и имеет 1-2 часа времени в день)
1 ^)
Совет: не стесняйтесь спрашивать — часто дистроспецифичные привычки из «прошлой жизни» могут немножко вредить. В остальном — линукс как линукс, общие знания вполне применимы (правда общая область в последнее время несколько сузилась за счёт «нового и передового» в других дистрибутивах).
Исходная версия bormant, :
Что я выиграю/потеряю, если буду использовать дефолтную поставку с лило и мбр в режиме легаси, вместо граба или елило и гпт?
Тут с какой стороны посмотреть.
1) Если система не единственная, может захотеться не морочиться с расширенными разделами, а основных в MBR только 4. В GPT все основные, да и ограничение на как на их число так и на размер поширше ;-)
2) Если рядом есть Windows, то наверное захочется сохранить возможность перезагрузки в туда. Windows в этом отношении капризна, умеет либо MBR+Legacy, либо GPT+(U)EFI, причем определяется сие на момент ея установки.
3) Для Linux возможно и GPT+Legacy, если вдруг зачем-то захочется.
Как у лило дела с dm-crypt?
https://mirror.yandex.ru/slackware/slackware-14.2/README_CRYPT.TXT
Потребуется отдельный раздел под /boot.
Распространяют слухи, что скоро релиз 15 версии.
Еще даже бету не объявляли, не то что кандидатов на выпуск, коих бывает 3 и больше.
Если я поставлю 14.2 насколько много придется возиться, чтобы обновиться до 15-ой?
Обычно это выглядит так:
https://mirror.yandex.ru/slackware/slackware-14.2/UPGRADE.TXT
https://mirror.yandex.ru/slackware/slackware-14.2/CHANGES_AND_HINTS.TXT
или даже так (изменив предварительно зеркало в /etc/slackpkg/mirrors)
# telinit 3
# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system
Чем это грозит для системы?
После этого что-то из стороннего софта наверняка потребует пересборки.
В 15.0 точно будут изменены пути /var/log/{,removed_}{packages,scripts}, но для совместимости останутся симлинки по старым путям.
Как правильно поддерживать ядро, отличающееся от дефолтного? Например, я хочу использовать последнее lts ядро, я его собираю. Гарантий, что оно заведется нет, т.к. могут быть нужны зависимости свежее тех, что в системе. Как это организовано у слакварщиков?
Текущее ядро пока от glibc не настолько убежало, чтобы не собираться в 14.2 ;-)
Обычно достаточно в /etc/lilo.conf оставить загрузку дистрибутивного kernel-huge или вовсе пользоваться загрузочным носителем для ремонта. Можно его (носитель) и вовсе в загрузчик пристегнуть, чтоб не искать при случае ;) :
http://docs.slackware.com/howtos:slackware_admin:booting_install_from_hdd
Каким образом проще переносить собранные пакеты на другие машины? Есть для этого готовые решения или все костыляешь сам?
slackpkg отлично работает с простым каталогом как с источником пакетов, NFS и другие способы монтирования по сети, а равно и флешки тоже никто не отменял.
Если хочется организовать именно хранилище «по-взрослому» (PACKAGES.TXT и прочие спецфайлы), то у Эрика есть готовые сценарии для этого. Можно и зависимости для slapt-get прописать ;-) и даже автоматически ;-)
Как обстоят дела с качеством пакетов, например, со slackbilds.org? Можно им доверять?
Как правило да. Но все-все тамошние пакеты я не ставил ;-)
Но отношение к проекту у ведущих его довольно серьезное.
Как в целом система с т.з. безопасности (дырявости софта)? Понятно, что исключив systemd и pam много 0-day отпадают сами собой, но старый софт намекает на то, что там может быть много дыр, которые уже нашли.
Выпуски поддерживаются обновлениями безопасности:
https://mirror.yandex.ru/slackware/slackware-14.2/ChangeLog.txt
# slackpkg update; slackpkg install-new; slackpkg upgrade-all
По шкале от 1 до 10 оцените трудность обслуживания одной системы, если ей начинает заниматься, скажем, продвинутый юзер линукс (умеет в терминал, читать доки на английском, гуглить и имеет 1-2 часа времени в день)
1 ^)
Совет: не стесняйтесь спрашивать — часто дистроспецифичные привычки из «прошлой жизни» могут немножко вредить. В остальном — линукс как линукс, общие знания вполне применимы (правда общая область в последнее время несколько сузилась за счёт «нового и передового» в других дистрибутивах).