Комментарии 22
Gentoo в продакшене, тем не менее звучит гораздо убедительнее чем любой бинарный дистрибутив. Особенно, если это касается серверных инсталляций. В этом случае количество зависимостей сводится к минимуму. И риск напороться на серьезную проблему при update системы сильно уменьшается. К тому же любой ленивый админ легко организует кэш бинарных сборок на NFS и автоматизирует ежедневное-еженедельное обновление gentoo (разумеется после тестирования на карантином сервере, и да возможно раз в пол года автоматическая сборка не сработает) или воспользуется готовым решением.
В случае бинарных дистрибутивов велик риск привести систему в убитое состояние. Временной период существования известных, не закрытых проблем безопасности, существенно выше.
> количество зависимостей сводится к минимуму
Не все умеют правильно настроить USE-флаги.
> напороться на серьезную проблему при update системы сильно уменьшается
Что есть «серьёзная проблема»?
> организует кэш бинарных сборок на NFS и автоматизирует ежедневное-еженедельное обновление gentoo
Ага, а кто потом этот кэш обслуживать будет? Ну и потом — чем сценарий с кешем отличается от бинарного дистрибутива тогда? Тем, что «минимум зависимостей»? Сомнительное преимущество.
> В случае бинарных дистрибутивов велик риск привести систему в убитое состояние
Это с чего вдруг?
> Временной период существования известных, не закрытых проблем безопасности, существенно выше.
В теории — да. На практике — Дебиан/РедХат на второй-третий день выпускают обновление, yum upgrade/apt-get dist-upgrade — и всё в шоколаде. В случае более-менее большого деплоя Генту (5+ машин) у одного человека те же два-три дня займёт обновить этот зоопарк.
Ну и стоимость для бизнеса не забываем. Клиентам обычно неважно, на чём крутится их интернет-магазин, главное чтобы было стабильно. Плюс лично мне как админу приятней ковыряться с чем-то новым, или улучшать существующее, а не проводить часы с емержем в зубах. Гента — не для бизнеса, бессысленно это.
Не все умеют правильно настроить USE-флаги.
> напороться на серьезную проблему при update системы сильно уменьшается
Что есть «серьёзная проблема»?
> организует кэш бинарных сборок на NFS и автоматизирует ежедневное-еженедельное обновление gentoo
Ага, а кто потом этот кэш обслуживать будет? Ну и потом — чем сценарий с кешем отличается от бинарного дистрибутива тогда? Тем, что «минимум зависимостей»? Сомнительное преимущество.
> В случае бинарных дистрибутивов велик риск привести систему в убитое состояние
Это с чего вдруг?
> Временной период существования известных, не закрытых проблем безопасности, существенно выше.
В теории — да. На практике — Дебиан/РедХат на второй-третий день выпускают обновление, yum upgrade/apt-get dist-upgrade — и всё в шоколаде. В случае более-менее большого деплоя Генту (5+ машин) у одного человека те же два-три дня займёт обновить этот зоопарк.
Ну и стоимость для бизнеса не забываем. Клиентам обычно неважно, на чём крутится их интернет-магазин, главное чтобы было стабильно. Плюс лично мне как админу приятней ковыряться с чем-то новым, или улучшать существующее, а не проводить часы с емержем в зубах. Гента — не для бизнеса, бессысленно это.
Не скажу про редхат, но в той же убунте вроде намного быстрее происходит ввод новых версий пакетов.
Ubuntu != Debian, который приведет в примере
Неправильно выразился.
Я не в курсе про редхат, но в убунте новые версии пакетов обычно появляются раньше чем в дебиан.
Я не в курсе про редхат, но в убунте новые версии пакетов обычно появляются раньше чем в дебиан.
Да, все верно. В Debian'е быстро появляются только security-патчи.
Только тогда я не совсем понимаю этот коммент.
Быстро появляются — хорошо? или плохо?))
Только тогда я не совсем понимаю этот коммент.
Быстро появляются — хорошо? или плохо?))
Плохо.
Убунту использовать на сервере это большая глупость.
Во первых постоянно что-то отваливается изза плохого тестирования.
Во вторых оно давно стало BLOATWARE, как и большинство бинарных дистрибутивов.
В третьих systemd невозможно выпилить а это тянет за собой кучу проблем.
В RedHat/CentOS 7 тоже systemd. Полет нормальный, проблем не испытываем. Что с ним не так?
> В третьих systemd невозможно выпилить а это тянет за собой кучу проблем.
Зачем его выпиливать? Его просто готовить нужно научиться, всего делов. Мне SysV init в CentOS 3 после фряшных rc-скриптов тоже непонятен был — ничо, разобрался.
Зачем его выпиливать? Его просто готовить нужно научиться, всего делов. Мне SysV init в CentOS 3 после фряшных rc-скриптов тоже непонятен был — ничо, разобрался.
Что есть «серьёзная проблема»?
- Полностью убитые зависимости из-за ошибок в пакетах.
- Невозможность обновления из-за отсутствия поддержки слотов для библиотек.
- Крах сервисов при обновлении glibc
> Полностью убитые зависимости из-за ошибок в пакетах.
За 12 лет сталкивался с таким ровно один раз на Ubuntu 6.06. Возможно в Debian sid, или Fedora rawhide такое до сих пор есть — не в курсе, не пользуюсь bleeding edge версиями.
> Невозможность обновления из-за отсутствия поддержки слотов для библиотек.
Слоты в Генту конечно сила, этого не отнять. Но реальные юзкейсы слотов в других дистрах уже пару лет как покрыты — version pinning в Дебиан, Software Collections в Федоре/ЦентОС, плюс механизм alternatives что там, что там. Это если говорить про Python 2/3 например, или подобное. Зачем мне слотировать glibc (или любую другую библиотеку, от которой всё равно пол-системы зависит) — ума не приложу.
> Крах сервисов при обновлении glibc
Инфа из начала двухтысячных? Ни разу на моей практике yum update glibc не приводил к «краху сервисов».
За 12 лет сталкивался с таким ровно один раз на Ubuntu 6.06. Возможно в Debian sid, или Fedora rawhide такое до сих пор есть — не в курсе, не пользуюсь bleeding edge версиями.
> Невозможность обновления из-за отсутствия поддержки слотов для библиотек.
Слоты в Генту конечно сила, этого не отнять. Но реальные юзкейсы слотов в других дистрах уже пару лет как покрыты — version pinning в Дебиан, Software Collections в Федоре/ЦентОС, плюс механизм alternatives что там, что там. Это если говорить про Python 2/3 например, или подобное. Зачем мне слотировать glibc (или любую другую библиотеку, от которой всё равно пол-системы зависит) — ума не приложу.
> Крах сервисов при обновлении glibc
Инфа из начала двухтысячных? Ни разу на моей практике yum update glibc не приводил к «краху сервисов».
Вы уж извините, но вы просто не осилили работу с генту на проде. Как и предидущий админ. f1inx все верно сказал.
Тот треш который вы описали можно вычистить и выровнять на генте. А на убунте/дебиане/центос пришлось бы переставлять на всех железках ОС.
Как я понимаю вы уговорили начальство на полный переезд на новую ОС? и куда?
PS. Помните пословицу про «два перезда» = «один пожар». На серверах такая же фигня.
Тот треш который вы описали можно вычистить и выровнять на генте. А на убунте/дебиане/центос пришлось бы переставлять на всех железках ОС.
Как я понимаю вы уговорили начальство на полный переезд на новую ОС? и куда?
PS. Помните пословицу про «два перезда» = «один пожар». На серверах такая же фигня.
> Вы уж извините, но вы просто не осилили работу с генту на проде
Опыт с Gentoo — около пяти лет, так что скорее не захотел. Есть более интересные и полезные задачи. Для прода никогда не буду никому советовать source-based дистр, и сам не буду использовать — в 99% случаев это принесёт скорее вред, чем пользу, и сузит количество людей, способных поддерживать это окружение после меня.
Опыт с Gentoo — около пяти лет, так что скорее не захотел. Есть более интересные и полезные задачи. Для прода никогда не буду никому советовать source-based дистр, и сам не буду использовать — в 99% случаев это принесёт скорее вред, чем пользу, и сузит количество людей, способных поддерживать это окружение после меня.
5 лет с генту? И для вас стало сложностью перейти от сорцов к общим для всех серверов бинарникам? Это же азы генту в проде.
Эти бинарники нужно будет самому поддерживать и компилировать, но только один раз. И уже потом разливать по тестовым серверам.
Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам. Но любой проект через какое-то время хочет использовать то, чего в них нет. Будь то pagespeed — гугловый модуль для nginx. Или устаревшая версия glasterfs т.к. обновить ее сразу и везде нет возможности. Ну или вы параноик и не доверяете сторонним репозиториям.
Вам придется создать свой и поддерживать его дальше. Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие. Например если у сброка nginx в репе использует не ту версию openssl чем та что прилетела вам с офф апдейтом.
В генгу же вы все эти проблемы даже не увидите т.к. она знает что у вас зависит от openssl и сама все пересоберет с актуальной версией зависимостей.
Эти бинарники нужно будет самому поддерживать и компилировать, но только один раз. И уже потом разливать по тестовым серверам.
Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам. Но любой проект через какое-то время хочет использовать то, чего в них нет. Будь то pagespeed — гугловый модуль для nginx. Или устаревшая версия glasterfs т.к. обновить ее сразу и везде нет возможности. Ну или вы параноик и не доверяете сторонним репозиториям.
Вам придется создать свой и поддерживать его дальше. Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие. Например если у сброка nginx в репе использует не ту версию openssl чем та что прилетела вам с офф апдейтом.
В генгу же вы все эти проблемы даже не увидите т.к. она знает что у вас зависит от openssl и сама все пересоберет с актуальной версией зависимостей.
> И для вас стало сложностью перейти от сорцов к общим для всех серверов бинарникам?
Да. Ибо ленив я, неохота мне даже один раз пересобирать систему с целью обновления, ненужная трата времени это.
> Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам.
Ну вот я и решил для себя — в тех проектах, в которых я учавствую/учавствовал это не нужно.
> Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие.
Про Дебиан не знаю, для CentOS — не вижу проблем вообще. Пример с Nginx + openssl к слову показательный (хотя и надуманый ИМХО, ни разу не приходилось так извращаться). Решается выкладыванием своей сборки openssl рядом с Nginx, с кастомными путями (привет, слоты Генту), и пишем правильный spec для Nginx (чтоб линковался не с системным openssl, а с тем, что нужно).
Да. Ибо ленив я, неохота мне даже один раз пересобирать систему с целью обновления, ненужная трата времени это.
> Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам.
Ну вот я и решил для себя — в тех проектах, в которых я учавствую/учавствовал это не нужно.
> Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие.
Про Дебиан не знаю, для CentOS — не вижу проблем вообще. Пример с Nginx + openssl к слову показательный (хотя и надуманый ИМХО, ни разу не приходилось так извращаться). Решается выкладыванием своей сборки openssl рядом с Nginx, с кастомными путями (привет, слоты Генту), и пишем правильный spec для Nginx (чтоб линковался не с системным openssl, а с тем, что нужно).
Зато как приятно смотреть, как пересобирается мир :)
отсыпь чутка…
В этом случае количество зависимостей сводится к минимуму.
Вы можете только одним способом свести количество зависимостей к минимуму: не использовать их в своем коде или писать свои велосипеды, чтобы они были частью основного кода. Дистрибутив на это никак не влияет уж точно.
К тому же любой ленивый админ легко организует кэш бинарных сборок на NFS
Ленивый админ избежит ненужных действий своими руками, когда есть специальные механизмы, отточенные огромным сообществом умных людей на миллионах случаев разных практик. В бинарном дистрибутиве вообще ничего делать не надо для этого.
А ссылочку на первую часть можно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Страх и ненависть в отдельно взятом стартапе. Часть 2 — Ненависть