Подойдет ли Gentoo для Web-сервера?

А с кастомной Gentoo - твоя система - это только твоя уникальная система, можешь наткнуться на непонятный баг, которого нет у других.

Непонятные баги исчезают со скиллом.

А сам на работе какой дистр используешь для хостов (во вкусном)?

Генту/дебиан. В зависимости от задач.

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

Значит, я чего-то не знаю про ЛОР и механизм игнора

Всё просто. Все ответы (неигнорирумых пользователей) на сообщение игнорируемого (независимо от размера/глубины дерева) — игнорируются.

В длинных спорах из-за этого бывают страницы, где показываются 0 сообщений из 100 :D При чём сам игнорируемый, породивший ветку, может давно уже уйти из спора, спорят нормальные люди в нормальной манере — но будут в игноре.

Я сам нежно люблю генту, но не считаю ее для каждой дырки затычкой. Как обычно - для каждой задачи свой инструмент.

Вот именно потому я Redmine недавно поднимал в контейнере LXC под Ubuntu :) — Подскажите Ubuntu PPA со свежим Redmine. (комментарий)

Ну и на десктопе, вот, Gentoo на Ubuntu променял в этом году.

надеюсь на твоём вкусносервере не она? А то заказывать хотел вдску

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

Гы, я только сейчас понял, что можно игнорить анонимусов

Это у тебя юмор такой? Или ты и правда веришь что gentoo лучше rhel на сервере?

Юмор? Я и с тем и с тем в production работал.

1) Центос НЕ рхэл.
2) Даже рхэл нахрен не нужен на веб серверах.

Сколько на это уйдет времени в случае Генты, если есть диск с системой и доступ в Инет?

В моем случае - столько же, сколько и на дебиан. То есть 20-40 минут.

Гы, я только сейчас понял, что можно игнорить анонимусов

Угу: Глюк с игнором :)

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

1) Центос НЕ рхэл.

обоснуй

Кто держит Gentoo на серверах, вы на каждой машине постоянно всё конпеляете? Или заморочились настроить binhost? Только честно.

Или заморочились настроить binhost? Только честно.

Что делать, если все машины — разные? :)

обоснуй

Тебе чем именно? :)

CentOS (англ. Community ENTerprise Operating System) — дистрибутив Linux, основанный на коммерческом Red Hat Enterprise Linux компании Red Hat и совместимый с ним.

основанный.

А второе - даже не смотря на кодовую базу, лютый тупняк и глюкало в цементосе встречается постоянно.
[iptables][centos] чудеса с пробросом порта - Это в кач-ве примера, например :)
В ред хате такое не повторяется, проверял.

Кто держит Gentoo на серверах, вы на каждой машине постоянно всё конпеляете? Или заморочились настроить binhost? Только честно.

Если собрать для твоего сервера пару пакетиков проблема - то я советую его выкинуть.

просто в том, баге мне нужен кто-нить кто может сказать как протестить, и проверить, что будет а). без акселераторов, б). с другими.

ну я на неё ответил, заодно поблагодарил фрактала, за информацию, что если дискуссия зайдёт в тупик, то, что не стоит её продолжать. Где оскорбления? Где ненормальная реакция?

тормозные апдейты (в том числе секьюрити) и раздолбаи владельцы - что еще тут обосновывать?

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

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

man nice/renice. И это задается в make.conf из коробки.

тормозные апдейты (в том числе секьюрити) и раздолбаи владельцы - что еще тут обосновывать?

Ну куда ты так поспешил! Я это приберег на конец дискуссии :)

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

в любом случае на это нужны ресурсы, разве что компилировать не на целевом сервере.

можешь показать ему Исчез основатель CentOS :)

Для веб-серверов нормальные люди используют виртуальные окружения.

Про PaaS мсье не слышал?

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

man nice/renice. Для твоего случая. Второе - если у тебя сотни виртуалок, то уже повод задуматься о своем репозитории с уже собранными пакетами.

в любом случае на это нужны ресурсы

Если сервер по процу загружен более, чем на 70% - это уже повод ставить второй.
А потребление ресурсов настроить очень просто, тупо ставишь nice 19 и собираешь в один поток. Это не нагрузка, это фигня.

можешь показать ему Исчез основатель CentOS :)

Да, я тоже про этот случай :)

Если сервер по процу загружен более, чем на 70% - это уже повод ставить второй.

зачем второй, если один справляется со своей задачей?

Если сервер по процу загружен более, чем на 70% - это уже повод ставить второй.

зачем второй, если один справляется со своей задачей?

Повод ставить второй возникает, когда сервер по процессору в среднем загружен процентов на 20. Потому что пиковая загрузка обычно на порядок выше средней.

зачем второй, если один справляется со своей задачей?

Зависит от задачи. Если мы про web, допустим на серваке похапэ, мускуль и нгикс - то мускуль (при нагрузке на сервак 70% и более) стоит уже уносить на другой сервер. Ну, либо смотря что там его грузит.

Балансировка рулит и педалит, а от резкого увеличения нагрузки не застрахован никто, особенно в случае веб-проекта.

Повод ставить второй возникает, когда сервер по процессору в среднем загружен процентов на 20. Потому что пиковая загрузка обычно на порядок выше средней.

не тот случай, тут она равномерно размазана

Не нужно серверы голой попой в инет высовывать, жить будет проще. Вот с раздолбайством согласен.

не тот случай, тут она равномерно размазана

Либо невероятно редкое исключение, либо ты не про Web-сервер.

у меня ещё нету пометки у этого ника, но похоже будет

ну поспешный вывод, с кем не бывает :)

мускуль вообще всегда стоит выносить, если только это не копеечный шаред

Если мы про web

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

ну тут особо нечего обсуждать, это уже оффтоп - так что сворачиваюсь

т.е. там веб-приложения ставятся «их способом», а не через пакеты

Это конечно неправда, см. например http://koji.fedoraproject.org/koji/packageinfo?packageID=4118

А так gentoo даёт ... возможность выбора из множества версий

Для системного серверного софта - это минус, причем критический. А для прикладного - это в том или ином варианте решается везде.

Не нужно серверы голой попой в инет высовывать, жить будет проще.

то есть тебя отсутствие (вернее, запаздывание) апдейтов безопасности не смущает?

специфичный случай, ага.

Сорсы там один и те же, нужно смотреть опции сборки. Прозреваю редкий баг. У нас сейчас несколько тысяч серверов под центосом (с РХ не удалось договориться за вменяемый ценник), полет нормальный.

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

Это конечно неправда, см. например

fedora@c.j.r надеюсь выслушают тебя с радостью и больше не будут рассказывать неправду честным гентушникам, если не ошибаюсь разговор тогда про sugarcrm был.

Для системного серверного софта - это минус, причем критический.

почему?

А для прикладного - это в том или ином варианте решается везде.

ну так все вопросы в том или ином варианте решаются везде.

Запаздывание на два дня - нет. У нас все в dmz, снаружи доступно из тысяч серверов штук 20 суммарно, и то только веб-приложения через nginx. Ко всему остальному доступ параноидально зарезан до одной-двух сетей, и если кто-то получит доступ в эти сети - на серваки будет уже абсолютно пофигу :)

снаружи доступно из тысяч серверов штук 20 суммарно, и то только веб-приложения через nginx.

если эти твои веб приложения трахнут и скомпрометируют, ты не огорчишься?

Именно так, смотреть в первую очередь нужно на свои скрипты.

p.s. как раз субд мы собираем сами

это accepatable риск, и не я его таковым классифицировал :(

p.s. как раз субд мы собираем сами

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

У нас сейчас несколько тысяч серверов под центосом (с РХ не удалось договориться за вменяемый ценник), полет нормальный.

Чем оркеструете?

Для системного серверного софта - это минус, причем критический.

почему?

Я же тебе опять неинтересно отвечу, классически.

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