Открылся репозиторий Red Hat Software Collections который можно использовать в Centos

[@Kudja]

А в чем отличие от использования epel / remi

[@opium]

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

[@postdig]

Вопрос можно перефразировать на epel + atrpms как основные, ибо достаточно стабильные и неконфликтные.

[@opium]

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

[@vsespb]

Кхм. Это же не просто репозиторий. А именно SCL dev.centos.org/centos/6/SCL/docs/#sect-Installation_and_Usage-Use — новый механизм переключения между версиями софта. Тогда причём тут epel/remi?

[@baltazorbest]

а если epel + centalt + данный репозиторий, конфликтов не будет?

[@opium]

Что вам мешает подключить и посмотреть.
По идее по названиям софта должно все работать.

[@baltazorbest]

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

[@l0rda]

centalt умер

[@opium]

Слава богу nginx появился много где ещё, в свое время особых альтернатив не было.

[@Aecktann]

а чем nginx от nginx.org вас не устраивает?

[@opium]

Тем что на nginx.org были только сырцы. Да и сейчас особого смысла от него нет, в убунту он есть в дефолтном, в центосе в епеле.

[@Aecktann]

внезапно nginx.org/ru/linux_packages.html#stable.
не скажу, что в центоси, но в убунте его собирают с левыми модулями, что нередко портит всю малину.

[@opium]

Ахахаха, ну расскажите мне где в 2007 году были там сборочки и почему все дружно собирали nginx из сырцов.

[@Aecktann]

У вас нджинкс 2007 года? А сайт не подскажете?
/me расчехлил свою коробку с эксплойтами.

[@opium]

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

[@TIEugene]

Однако там только 64 bit :-(
Пересобирать самому, что ли?

[@opium]

Уже наверно лет 6 я не использую x86 8)
А мелких виртуалок у меня и нет, где бы они пригодились.

[@lolmaus]

Я и на мелких использую 64-битный дистр.

[@opium]

на совсем мелких потери по памяти существенные для x64

[@lolmaus]

Минусующим поясню.

Потери по памяти небольшие. Цитирую отсюда: переход на 64 бита не удваивает расход памяти. Объем некоторого кода удвоится (как в памяти, так и на диске), некоторые данные увеличатся в объеме из-за увеличения размера указателей и минимального размера единиц данных. Но основная масса данных в оперативке не станет заметно больше.

У медали есть и обратная сторона.

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

Во-вторых, использование 64-битного дистра позволяет мгновенно сменить тариф, при необходимости подняв объем памяти до 8 или, если надо, 16 гигов. Полгода назад братишка попросил поднять MInecraft-сервер, а он до оперативки очень охоч. Я не стал создавать новую VPS, а просто повысил тариф на VPS'ке, которую прежде использовал для хранения бэкапов и в качестве песочницы.

Slicehost, к примеру, отказался от 32-разрядных дистров еще в прошлом десятилетии. Он был поглащен Rackspace, но и те 32-битных дистров не предлагают.

[@opium]

Увы есть существенный перерасход памяти в некотором софте, думаю не сложно найти на том же хабре статьи про это, к примеру апачи жрет существенно больше памяти чуть ли не 2х.
Когда есть ресурсы проще забить, у меня скажем с 2007 года сервера от 8-12 гигов оперативы были только, а виртуалки мелкие только на начальном этапе с зароком на рост, а тут проще сразу х64 чем переставить потом.
Но есть денег не густо как и ресурсов то есть смысл задуматься х86, так как зачем платить больше?

[@IlyaEvseev]

переход на 64 бита не удваивает расход памяти.

Когда как. Вот, например: siava.ru/forum/post587057.html#587057

С помощью siege погонял под нагрузкой рабочий сайт и при одинаковых настройках в 64-битном контейнере apache2 съедал по 250Мб памяти на процесс, тогда как в 32-битном не более 50Мб

[@opium]

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

[@lolmaus]

Как удвоение минимального размера ячеек данных может вызвать пятикратное увеличение расхода памяти?

[@opium]

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

[@Bambr]

Везет людям.
Я года 3 назад в сердцах сказал нашему сисадмину, мол, на прежней работе мы не выпендривались и ставили федору — хоть и не так стабильно, но со свежестью софта вопрос никогда не стоял, а этот ваш центос 5… На что он гоготнул и ответил, что у нас тоже есть кой-где федора. Вторая.

[@opium]

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

[@Bambr]

Ну я ж говорю, 3 года назад дело было, потому много серверов еще было под 5кой. А что до федоры, то это конечно никак не руководство к действию, вы совершенно правы. Нам повезло — никаких отрицательных эффектов во время апгрейда мы не ловили, а сам апгрейд проходил очень легко и быстро благодаря шаблонам виртуозы. Но и проект был несложным. Сейчас бы я запарился только зависимости пересобирать…

[@RicoX]

Сегодня накатывал на 1 проект PHP 5.1.6 (cli) (built: Jul 12 2013 16:52:22), а есть живые проекты с 4 и 3 версией, хорошо что их еще можно найти.

[@siomi]

Ruby 1.9.3

<sarcasm>Ах да, забыл, что это CentOS.</sarcasm>
Ладно, если серьезно, то 2.0 — это уже давно стандарт, переход с 1.9.х для того и старались делать максимально безболезненным, чтобы все перешли на вторую ветку быстро и без проблем. Это давно не bleeding edge, а стабильная рабочая лошадка.

[@opium]

Где стандарт то? В продакшене вижу только 1.9
Миграция большой системы на руби очень не простая вещь.

[@TITnet]

The current stable version is 2.0.0-p247

[@TITnet]

А что вы подразумеваете под стандартом? Можно ссылочку?

[@StamPit]

Притом хорошо, если не 2.6.

[@opium]

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

[@borisko]

Жалко, что devtoolset нет :(
Мог бы быть gcc-4.7, что очень полезно при разработке на c++11.

[@opium]

Этот репо совсем про другое, да и центос он не для дева дистр.

[@borisko]

Почему про другое?
А разве то, что «надевили», не нужно собирать под CentOS?

[@opium]

Тут про разные версии скриптовых языков и бд. Каким боком тут с++ не понятно.
В центосе вроде и так есть gcc 4.7 и dev too set
superuser.com/questions/381160/install-gcc-4-7-on-centos
lists.centos.org/pipermail/centos-devel/2013-September/009210.html

[@NetBear]

Есть несколько сотен серверов на CentOS 6.4. Все они соответственно заряжены Python 2.6.6
Допустим, я используя этот репозиторий, устанавливаю Python 2.7 (проверил, сработало как часы), но по умолчанию на всех машинах по прежнему торчит старый, на него завязан Yum итд.
Существует ли какой-нибудь надёжный и по возможности простой способ переключиться на Python 2.7, не угробив при этом установку CentOS?
Заранее премного.

[@opium]

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

[@NetBear]

Замена симлинков убивает Yum и портит жизнь ещё массе модулей системы. Такой брутфорс я уже попробовал, не работает.