Ubuntu LTS или CentOS 7 для веб-сервера?

у Полтавченко беру,пл. Растрелли 1 адрес, тебя так устроит?

лучше захлебнись им сразу.

какой ты дерзкий и тебе не хворать

ну конечно, давайте ради убунточки всё на разные виртуалки,базы отдельно,битрикс отдельно, rvm отдельно, а вместо шустрой файловой системы купить ssd.

Нет, мы свалим всё в одну кучу и пойдём к проктологу залечивать геморрой.

В Ubuntu будущих версий тоже будет systemd. Так что система инициализации - это не аргумент. Смотреть нужно на доступность необходимого ПО, на его версии, на возможность скачать необходимые пакеты более новых версий и т.п. В частности, у Centos есть такие замечательные, проверенные временем репы как atomic и epel. У бубунты есть только PPA, которые поддерживаются не сообществом, а никому не известными товарищами. Кроме того, некоторые пакеты(тот же Apache) запросто собираются и опакечиваются под RH-based, а с опакечиванием под Deb-based не всё так просто. С другой стороны Centos и RH однозначно нужно использовать только в том случае, когда у вас нет выбора(нужно установить проприетарное ПО заточенное только под RH-based). В других случаях особой разницы между данными дистрибутивами Вы не ощутите. Так что нет смысла затевать переход.

В убунте ж вроде apache2.conf.

Это как раз один из примеров того, о чем я пытался сказать — в центоси пакет с апачем называется httpd, в убунту пакет с тем же апачем называется apache2 (или как-то так); в центоси /etc/httpd/conf/httpd.conf и /etc/httpd/conf.d/*.conf, в убунту — /etc/apache2/apache2.conf, /etc/apache2/modules.d/, /etc/apache2/sites.d/ (за точность путей не ручаюсь — пишу по памяти), в убунту есть a2ensite и прочие, которых нет в центоси. Одним словом, я имел в виду вот что — если сложились определенные привычки в отношении апача на убунте, то при переходе на центось весьма вероятен «культурный шок», и наоборот.

rpm vs deb, в остальном более менее, я еще бы попробовал debian 8 в виртуалке

Был у меня культурный шок при переходе с CentOS на Ubuntu год назад)

У бубунты есть только PPA, которые поддерживаются не сообществом, а никому не известными товарищами.

Сообщество - это и есть люди. Да и собирает там автоматом. Тем более есть официальные ppa, прямо от разработчиков или активных коммитеров.

Был у меня культурный шок при переходе с CentOS на Ubuntu год назад)

OK, просто из заглавного сообщения это никак не следовало, вот я и пытался предостеречь (у самого был культурный шок на дебиане после центоси).

В Ubuntu структура конфигов для LAMP более логична и вылизана. И есть PPA на все случаи жизни. CentOS приходится использовать по работе, уже не первый год — каждый раз матерюсь. Говно говном, всё кривое, неудобное, непонятно как собранное и часто древнее. Даже с Remi и прочими...

если сложились определенные привычки в отношении апача на убунте, то при переходе на центось весьма вероятен «культурный шок», и наоборот

Там дело даже не в привычках. Вот нахрена в CentOS один /etc/php.ini на все PHP сразу (cli/apache2/cgi/fpm)? Как конфигурировать индивидуально?

Там дело даже не в привычках. Вот нахрена в CentOS один /etc/php.ini на все PHP сразу (cli/apache2/cgi/fpm)? Как конфигурировать индивидуально?

Всегда считал что это наоборот удобно. Зачем вообще нужны разные конфиги для cli/apache2/cgi/fpm? У тебя PHP в разных режимах на одном серваке работает?

Зачем вообще нужны разные конфиги для cli/apache2/cgi/fpm?

Например, чтобы для cli снять лимиты на время исполнения, или добавить модули, которые не нужны в fpm, или поднять лимиты на память для legacy apache и т.п.

У тебя PHP в разных режимах на одном серваке работает?

Именно так. Даже fpm и mod_apache обычно требуют разных настроек, а уж смешивать их с cli — совсем глупость.

Например, чтобы для cli снять лимиты на время исполнения

У CLI неограниченное время выполнения.

У CLI неограниченное время выполнения

Упс. Интересно, когда этот параметр захардкодили, раньше задавался через .ini как обычно. Видимо, из-за таких, вот, CentOS'ов и пришлось хардкодить :)

Но это не отменяет прочие параметры конфигурирования — лимиты на память, наборы модулей, лимиты mysql-соединений, возможность работы с url из файловых функций и т.п.

Но это не отменяет прочие параметры конфигурирования — лимиты на память, наборы модулей, лимиты mysql-соединений, возможность работы с url из файловых функций и т.п.

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

А вот мне часто приходится с таким сталкиваться :-/ Спасает только то, что CentOS стоит на машинах, «крайне однозадачных» — т.е. фактически сервер, выделенный под конкретную часть проекта. Так что конфигурирование нужно, как правило, под один компонент и тут всё нормально. А вот на других серверах, где сидит зоопарк различных решений, я б с CentOS просто застрелился. А вот со структурой конфигов Gentoo или Ubuntu — полный порядок :)

ppa от разработчиков иногда пользуюсь. Сообщество - это группа людей. В которой члены сообщества имеют определённую репутацию, да и возможность приглядывать на работой товарищей. Однако большую часть PPA пилят одиночки. Которые могут собрать нужную версию ПО после того, как накатят на неё какой-нибудь патч. Я бы не рискнул устанавливать пакеты, собранные непонятно кем.

Всегда можно проверить, если не веришь. Практически у всех популярных программ есть либо около официальное ppa, или в ppa от известных сайтов вроде webupd8, noobslab. Грубо говоря практически для любого софта, который может понадобится уже есть ppa.

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

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