Comments 46
А в чем отличие от использования epel / remi
реми довольно конфликтный репо, а епеле их нет.
в целом надеюсь этот репо даст хорошую совместимость с другими.
в целом надеюсь этот репо даст хорошую совместимость с другими.
Вопрос можно перефразировать на epel + atrpms как основные, ибо достаточно стабильные и неконфликтные.
Кхм. Это же не просто репозиторий. А именно SCL dev.centos.org/centos/6/SCL/docs/#sect-Installation_and_Usage-Use — новый механизм переключения между версиями софта. Тогда причём тут epel/remi?
а если epel + centalt + данный репозиторий, конфликтов не будет?
Что вам мешает подключить и посмотреть.
По идее по названиям софта должно все работать.
По идее по названиям софта должно все работать.
centalt умер
Слава богу nginx появился много где ещё, в свое время особых альтернатив не было.
а чем nginx от nginx.org вас не устраивает?
Тем что на nginx.org были только сырцы. Да и сейчас особого смысла от него нет, в убунту он есть в дефолтном, в центосе в епеле.
внезапно nginx.org/ru/linux_packages.html#stable.
не скажу, что в центоси, но в убунте его собирают с левыми модулями, что нередко портит всю малину.
не скажу, что в центоси, но в убунте его собирают с левыми модулями, что нередко портит всю малину.
Однако там только 64 bit :-(
Пересобирать самому, что ли?
Пересобирать самому, что ли?
Уже наверно лет 6 я не использую x86 8)
А мелких виртуалок у меня и нет, где бы они пригодились.
А мелких виртуалок у меня и нет, где бы они пригодились.
Я и на мелких использую 64-битный дистр.
на совсем мелких потери по памяти существенные для x64
Минусующим поясню.
Потери по памяти небольшие. Цитирую отсюда: переход на 64 бита не удваивает расход памяти. Объем некоторого кода удвоится (как в памяти, так и на диске), некоторые данные увеличатся в объеме из-за увеличения размера указателей и минимального размера единиц данных. Но основная масса данных в оперативке не станет заметно больше.
У медали есть и обратная сторона.
Во-первых, небольшой убыток памяти компенсируется столь же небольшим приростом производительности благодаря использованию 64-разрядных регистров процессора. Кроме того, виртуалка в любом случае работает на 64-разрядной хост-машине, которой не придется все время переключать контекст (пруф по той же ссылке).
Во-вторых, использование 64-битного дистра позволяет мгновенно сменить тариф, при необходимости подняв объем памяти до 8 или, если надо, 16 гигов. Полгода назад братишка попросил поднять MInecraft-сервер, а он до оперативки очень охоч. Я не стал создавать новую VPS, а просто повысил тариф на VPS'ке, которую прежде использовал для хранения бэкапов и в качестве песочницы.
Slicehost, к примеру, отказался от 32-разрядных дистров еще в прошлом десятилетии. Он был поглащен Rackspace, но и те 32-битных дистров не предлагают.
Потери по памяти небольшие. Цитирую отсюда: переход на 64 бита не удваивает расход памяти. Объем некоторого кода удвоится (как в памяти, так и на диске), некоторые данные увеличатся в объеме из-за увеличения размера указателей и минимального размера единиц данных. Но основная масса данных в оперативке не станет заметно больше.
У медали есть и обратная сторона.
Во-первых, небольшой убыток памяти компенсируется столь же небольшим приростом производительности благодаря использованию 64-разрядных регистров процессора. Кроме того, виртуалка в любом случае работает на 64-разрядной хост-машине, которой не придется все время переключать контекст (пруф по той же ссылке).
Во-вторых, использование 64-битного дистра позволяет мгновенно сменить тариф, при необходимости подняв объем памяти до 8 или, если надо, 16 гигов. Полгода назад братишка попросил поднять MInecraft-сервер, а он до оперативки очень охоч. Я не стал создавать новую VPS, а просто повысил тариф на VPS'ке, которую прежде использовал для хранения бэкапов и в качестве песочницы.
Slicehost, к примеру, отказался от 32-разрядных дистров еще в прошлом десятилетии. Он был поглащен Rackspace, но и те 32-битных дистров не предлагают.
Увы есть существенный перерасход памяти в некотором софте, думаю не сложно найти на том же хабре статьи про это, к примеру апачи жрет существенно больше памяти чуть ли не 2х.
Когда есть ресурсы проще забить, у меня скажем с 2007 года сервера от 8-12 гигов оперативы были только, а виртуалки мелкие только на начальном этапе с зароком на рост, а тут проще сразу х64 чем переставить потом.
Но есть денег не густо как и ресурсов то есть смысл задуматься х86, так как зачем платить больше?
Когда есть ресурсы проще забить, у меня скажем с 2007 года сервера от 8-12 гигов оперативы были только, а виртуалки мелкие только на начальном этапе с зароком на рост, а тут проще сразу х64 чем переставить потом.
Но есть денег не густо как и ресурсов то есть смысл задуматься х86, так как зачем платить больше?
переход на 64 бита не удваивает расход памяти.
Когда как. Вот, например: siava.ru/forum/post587057.html#587057
С помощью siege погонял под нагрузкой рабочий сайт и при одинаковых настройках в 64-битном контейнере apache2 съедал по 250Мб памяти на процесс, тогда как в 32-битном не более 50Мб
Везет людям.
Я года 3 назад в сердцах сказал нашему сисадмину, мол, на прежней работе мы не выпендривались и ставили федору — хоть и не так стабильно, но со свежестью софта вопрос никогда не стоял, а этот ваш центос 5… На что он гоготнул и ответил, что у нас тоже есть кой-где федора. Вторая.
Я года 3 назад в сердцах сказал нашему сисадмину, мол, на прежней работе мы не выпендривались и ставили федору — хоть и не так стабильно, но со свежестью софта вопрос никогда не стоял, а этот ваш центос 5… На что он гоготнул и ответил, что у нас тоже есть кой-где федора. Вторая.
Вообще то он центос 6.
Как то на продакшене федору не особо понаставишь, ибо чуть ли не раз в полгода новая, а когда у тебя сервис бабло приносит и тебе надо два раза в год делать мажорный апдейт дистрибутива, который может все сломать, а изменения в версиях федоры есть очень глобальные. То как то либо голову отсечет финдир, либо сам повешаешься.
Как то на продакшене федору не особо понаставишь, ибо чуть ли не раз в полгода новая, а когда у тебя сервис бабло приносит и тебе надо два раза в год делать мажорный апдейт дистрибутива, который может все сломать, а изменения в версиях федоры есть очень глобальные. То как то либо голову отсечет финдир, либо сам повешаешься.
Ну я ж говорю, 3 года назад дело было, потому много серверов еще было под 5кой. А что до федоры, то это конечно никак не руководство к действию, вы совершенно правы. Нам повезло — никаких отрицательных эффектов во время апгрейда мы не ловили, а сам апгрейд проходил очень легко и быстро благодаря шаблонам виртуозы. Но и проект был несложным. Сейчас бы я запарился только зависимости пересобирать…
UFO just landed and posted this here
Ruby 1.9.3
<sarcasm>Ах да, забыл, что это CentOS.</sarcasm>Ладно, если серьезно, то 2.0 — это уже давно стандарт, переход с 1.9.х для того и старались делать максимально безболезненным, чтобы все перешли на вторую ветку быстро и без проблем. Это давно не bleeding edge, а стабильная рабочая лошадка.
Жалко, что devtoolset нет :(
Мог бы быть gcc-4.7, что очень полезно при разработке на c++11.
Мог бы быть gcc-4.7, что очень полезно при разработке на c++11.
Этот репо совсем про другое, да и центос он не для дева дистр.
Почему про другое?
А разве то, что «надевили», не нужно собирать под CentOS?
А разве то, что «надевили», не нужно собирать под CentOS?
Тут про разные версии скриптовых языков и бд. Каким боком тут с++ не понятно.
В центосе вроде и так есть 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
В центосе вроде и так есть 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
Есть несколько сотен серверов на CentOS 6.4. Все они соответственно заряжены Python 2.6.6
Допустим, я используя этот репозиторий, устанавливаю Python 2.7 (проверил, сработало как часы), но по умолчанию на всех машинах по прежнему торчит старый, на него завязан Yum итд.
Существует ли какой-нибудь надёжный и по возможности простой способ переключиться на Python 2.7, не угробив при этом установку CentOS?
Заранее премного.
Допустим, я используя этот репозиторий, устанавливаю Python 2.7 (проверил, сработало как часы), но по умолчанию на всех машинах по прежнему торчит старый, на него завязан Yum итд.
Существует ли какой-нибудь надёжный и по возможности простой способ переключиться на Python 2.7, не угробив при этом установку CentOS?
Заранее премного.
Sign up to leave a comment.
Открылся репозиторий Red Hat Software Collections который можно использовать в Centos