Хотела бы без дальнейших холиваров, на которых не хватит кармы(так как новенькая), ответить на Ваши вопросы :)
Плюсы CentOS (RHEL):
1. Время поддержки: на тот же PHP ветки 5.1 _всегда_ в течение семи лет будут выпускаться патчи безопасности, при этом то, что ветки ПО старые, это не баг, а фича: делается все для сохранения API, что бы Вам, при поддержке своего web-приложения не пришлось переписывать его радикально.
Да, то что тот же Питон старый, многим не нравится, но, опять же, это фича, и этот питон будет поддерживаться до 2014-го года
2. Стек приложений: CentOS/RHEL платформа это не только система + репозитории, это еще и подход в чем-то похожий на подход MS (и плохо это или хорошо, это отдельный вопрос), например, в этом стеке тот же LVS и Cluster Suite для кластеров. Debian-way все ставить из репозиториев, а RH-way, выбирать правильные инструменты для решения задачи :)
3. Удобство управления, развертывания и автоматизации. Да, тот же Puppet запросто прикручивается и к Debian и к Ubuntu, но тут, в Anaconda kickstart, Cobbler (мы им через интернет ставим серверы клиентам с помощью VirtualMedia), Spacewalk/Sattelite/RHN возникает упорное ощущение того, что для красивого, быстрого и удобного deployment'а делается очень и очень много(в сравнении с другими платформами), если не все
4. Бэкпорты последних фич в стабильные ветки, без слома совместимости: не смотрите на ядро 2.6.18 (кстати, вообще-то уже вышел RHEL 6, так что 5-я ветка уже несколько устарела)
Делается многое, что бы, например, проприетарный драйвер на raid-массив сервера, установленный через rpm, не сломался при обновлении ядра(хотя, на самом деле, все равно бывает)
При всем этом, объем патчей в RHEL-ветке 2.6.18 таков, что сравнивать его с ванильным 2.6.18 совсем не корректно
5. rpm-пакеты, я их очень люблю за то, что собираются проще и удобнее (спек сам по себе вообще сказка), чем deb. Речь не о пакетном менеджере(!) yum vs {apt,aptitude}, а именно о пакетах.
>когда пришлось настраивать CentOS на продакшене, хотя все девелоперы кодили на Ubuntu и тестили на >нем же
Наверное, в этом и было дело: все-таки это _разные_ платформы, и разрабатывать изначально нужно было под ту платформу, под которой и предполагалось работать, согласны? Все-таки неправильно обвинять производителя сервера с корзинами hotswap под 2.5 диски, что он, такой буржуй окаянный, не дает ставить 3,5'' диски, разве не так?
«А компилить и искать по репам» это не RH-way, окажись я на Вашем месте, при таких требованиях ПО, написанного разработчиками, никогда бы не ставила что-то кроме Debian/Ubuntu LTS (из личных предпочтений, скорее, Debian)
> Да и Ubuntu Desktop вполне стабильна. Времена 8.xx, когда apt-get update вырубал нафиг иксы ушли,
Наверное, apt-get upgrade? yum, конечно, немного более опасный инструмент, чем apt, но yum check-update тоже вряд ли у кого-то приводили к катастрофе, да и приоритеты по репозиториям рулят, как и чтение центосной вики :)
Может быть, кому-нибудь полезно будет: под Linux VirtualBOX очень удобно жестко лимитировать с помощью утилиты cpulimit:
============================================
Name: cpulimit Relocations: (not relocatable)
Version: 1.1 Vendor: (none)
Release: 8.fc12 Build Date: Чтв 01 Апр 2010 00:03:20
Install Date: Чтв 01 Апр 2010 00:03:40 Build Host: localhost
Group: Applications/System Source RPM: cpulimit-1.1-8.fc12.src.rpm
Size: 12904 License: GPLv2
Signature: (none)
URL: cpulimit.sourceforge.net
Summary: CPU Usage Limiter for Linux
Description:
cpulimit is a simple program that attempts to limit the cpu
usage of a process (expressed in percentage, not in cpu time).
This is useful to control batch jobs, when you don't want them
to eat too much cpu. It does not act on the nice value or other
scheduling priority stuff, but on the real cpu usage.Also, it is
able to adapt itself to the overall system load, dynamically and quickly.
==========================
Для десктопов-ноутов очень удобно :) Для серверов, конечно, не на столько (тот же KVM лучше использовать с Cgroups, хотя в RHEL/CentOS 5 Cgroups, увы, нет)
Принцип утилиты основан на том, что она часто-часто посылает процессу сигналы sigstop и sigcount
Плюсы CentOS (RHEL):
1. Время поддержки: на тот же PHP ветки 5.1 _всегда_ в течение семи лет будут выпускаться патчи безопасности, при этом то, что ветки ПО старые, это не баг, а фича: делается все для сохранения API, что бы Вам, при поддержке своего web-приложения не пришлось переписывать его радикально.
Да, то что тот же Питон старый, многим не нравится, но, опять же, это фича, и этот питон будет поддерживаться до 2014-го года
2. Стек приложений: CentOS/RHEL платформа это не только система + репозитории, это еще и подход в чем-то похожий на подход MS (и плохо это или хорошо, это отдельный вопрос), например, в этом стеке тот же LVS и Cluster Suite для кластеров. Debian-way все ставить из репозиториев, а RH-way, выбирать правильные инструменты для решения задачи :)
3. Удобство управления, развертывания и автоматизации. Да, тот же Puppet запросто прикручивается и к Debian и к Ubuntu, но тут, в Anaconda kickstart, Cobbler (мы им через интернет ставим серверы клиентам с помощью VirtualMedia), Spacewalk/Sattelite/RHN возникает упорное ощущение того, что для красивого, быстрого и удобного deployment'а делается очень и очень много(в сравнении с другими платформами), если не все
4. Бэкпорты последних фич в стабильные ветки, без слома совместимости: не смотрите на ядро 2.6.18 (кстати, вообще-то уже вышел RHEL 6, так что 5-я ветка уже несколько устарела)
Делается многое, что бы, например, проприетарный драйвер на raid-массив сервера, установленный через rpm, не сломался при обновлении ядра(хотя, на самом деле, все равно бывает)
При всем этом, объем патчей в RHEL-ветке 2.6.18 таков, что сравнивать его с ванильным 2.6.18 совсем не корректно
5. rpm-пакеты, я их очень люблю за то, что собираются проще и удобнее (спек сам по себе вообще сказка), чем deb. Речь не о пакетном менеджере(!) yum vs {apt,aptitude}, а именно о пакетах.
>когда пришлось настраивать CentOS на продакшене, хотя все девелоперы кодили на Ubuntu и тестили на >нем же
Наверное, в этом и было дело: все-таки это _разные_ платформы, и разрабатывать изначально нужно было под ту платформу, под которой и предполагалось работать, согласны? Все-таки неправильно обвинять производителя сервера с корзинами hotswap под 2.5 диски, что он, такой буржуй окаянный, не дает ставить 3,5'' диски, разве не так?
«А компилить и искать по репам» это не RH-way, окажись я на Вашем месте, при таких требованиях ПО, написанного разработчиками, никогда бы не ставила что-то кроме Debian/Ubuntu LTS (из личных предпочтений, скорее, Debian)
> Да и Ubuntu Desktop вполне стабильна. Времена 8.xx, когда apt-get update вырубал нафиг иксы ушли,
Наверное, apt-get upgrade? yum, конечно, немного более опасный инструмент, чем apt, но yum check-update тоже вряд ли у кого-то приводили к катастрофе, да и приоритеты по репозиториям рулят, как и чтение центосной вики :)
Нам еще очень интересны улучшения в KVM, и заявленная поддержка Magny-Cours
============================================
Name: cpulimit Relocations: (not relocatable)
Version: 1.1 Vendor: (none)
Release: 8.fc12 Build Date: Чтв 01 Апр 2010 00:03:20
Install Date: Чтв 01 Апр 2010 00:03:40 Build Host: localhost
Group: Applications/System Source RPM: cpulimit-1.1-8.fc12.src.rpm
Size: 12904 License: GPLv2
Signature: (none)
URL: cpulimit.sourceforge.net
Summary: CPU Usage Limiter for Linux
Description:
cpulimit is a simple program that attempts to limit the cpu
usage of a process (expressed in percentage, not in cpu time).
This is useful to control batch jobs, when you don't want them
to eat too much cpu. It does not act on the nice value or other
scheduling priority stuff, but on the real cpu usage.Also, it is
able to adapt itself to the overall system load, dynamically and quickly.
==========================
Находим нужную нам виртуалку:
ps aux | grep -i freebsd | grep -v grep
500 5199 52.1 8.2 1402904 211488? Sl 20:00 4:22 /usr/lib/virtualbox/VirtualBox --comment FreeBSD --startvm 282d7bd1-5131-4b6b-9e8c-eb704aa5e031
И лимитируем процесс с пидом 5199 на 8 процентов cpu, при завершении процесса (-z) завершаем cpulimit:
sudo cpulimit -p 5199 -l 8 -z &
[1] 5872
[shaggycat@desktop2 ~]$ Process 5199 detected
Для десктопов-ноутов очень удобно :) Для серверов, конечно, не на столько (тот же KVM лучше использовать с Cgroups, хотя в RHEL/CentOS 5 Cgroups, увы, нет)
Принцип утилиты основан на том, что она часто-часто посылает процессу сигналы sigstop и sigcount