Назад | Перейти на главную страницу

Дистрибутивы на основе исходного кода и дистрибутивы на основе готовых пакетов

Интересно, каково общее предпочтение и откуда оно взялось. Активно использовав FreeBSD в течение нескольких лет, я склоняюсь к Gentoo, но у меня был неприятный опыт, когда я тратил драгоценное время, потому что Gentoo был установлен на действительно старую машину с необычным временем сборки.

Если бы это был какой-то заранее созданный пакет, потрачено меньше времени. (Я знаю, что у FreeBSD есть бинарные пакеты, но проблема в том, что они, по-видимому, не поддерживаются после выпуска версии, и единственный способ получить свежий материал - это скомпилировать его самостоятельно. На самом деле я не знаю о Gentoo).

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

РЕДАКТИРОВАТЬ: думаю, я должен прояснить этот недавний «мой опыт»

История такая. Изменив работу, мне пришлось поддерживать довольно старую машину, на которой размещен LDAP (OpenLDAP) с данными для входа в офисные пользователи. Пришло ко мне перезагрузить зверя (8 месяцев не перезагружался). После перезагрузки OpenLDAP не подключился. Похоже, что slapd и некоторые другие двоичные файлы каким-то образом были удалены во время работы системы. После сборки пакета ldap в первый раз я задумался, почему у меня нет двоичного файла slapd (заняло 15 минут). Некоторое время спустя я отследил проблему до «минимального» флага, включенного по умолчанию, который строит только библиотеки, а не серверные двоичные файлы. Конечный результат - ~ 1 час снижения производительности офиса и коллег, оправдывающихся: «Я не сделал этого, потому что наш главный сервер вышел из строя».

-

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

Я обслуживаю более чем изрядное количество машин Gentoo.

Не потому, что мы заботимся о детской настройке скорости петель. Мы заботимся о гибкости установки именно того, что мы хотим, а не каждый функция пакета и зависимости, которые, по мнению участника, мы мощь однажды хочу. Нам совершенно комфортно, как работают Linux, компиляция и библиотеки. Мы не хотим, чтобы все было отвлечено от нас в черный ящик.

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

  • На современном оборудовании время сборки относительно невелико. Тем более, если ваши машины имеют резервирование N + 1.

  • Вы можете придирчиво относиться к поведению portage, например к размещению MAKEOPTS="-l 1.0" в вашем make.conf, чтобы гарантировать, что новые сборки откладываются, когда средняя нагрузка становится слишком высокой.

  • При желании вы можете использовать бинарные пакеты из Portage. Зеркала предоставляют ряд общих пакетов, или вы можете свернуть свои собственные с --buildpkgonly.

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

  • Последние стабильные версии Portage, которые сейчас используются, вряд ли оставят вас в покое при выполнении обновлений. Сказки о конфликтах и ​​блокировках в значительной степени ушли в прошлое.

  • Если вы заботитесь о таком большом количестве машин, что обновление становится болезненным, вам все равно стоит взглянуть на Puppet / BCFG / cfengine;)

Обновление в ответ на редактирование вопроса:

Хотя я с пониманием отношусь к ситуации, которую вы описываете, это не то, что является симптомом для дистрибутивов на основе исходного кода или действительно предотвращается с помощью дистрибутива на основе пакетов. Это результат:

  1. Ваша собственная природная непригодность к родству и
  2. Плохая внутренняя документация вашего предшественника

По правде говоря, я уже довольно давно не использовал широко какие-либо другие дистрибутивы Linux. По этой причине, если вы поместите машину Debian (например) мне на колени и скажете мне, что OpenLDAP не работает после перезагрузки, я тоже мог бы потратить 15 минут или час на решение проблемы. Не потому, что я плохо разбираюсь в Linux или что Debian не является хорошей ОС, а в первую очередь потому, что я не помню подробных деталей сценариев Debian RC или системы пакетов. Вот почему внутренняя документация важна в организации. Он должен послужить толчком для незнакомого и заполнить пробелы у всех остальных. Даже если они все знают.

Небольшая заметка о Gentoo. USE-флаги Portage невероятно полезны, и я часто использую «минимальный». Я, например, не хочу, чтобы двоичные файлы сервера пакета были установлены на машине, которая будет клиентом только в течение ее срока службы. Их излишнее присутствие может увеличить сложность или даже стать проблемой для безопасности. Это никогда не проблема места. Вы можете увидеть, какие USE-флаги и зависимости пакет будет принимать (а какие нет), прежде чем он начнет компилировать, используя -av аргументы. Так что сюрпризов не должно быть.

GNUix> Простите, хватка!

Я не буду комментировать, следует ли вам использовать Gentoo или нет - или сборка из исходников «того стоит»

Я скажу, что использую Gentoo и Ubuntu. Раньше я использовал Gentoo на всех своих машинах GNU / Linux, но решил, что Ubuntu на моих рабочих столах легче управлять. Я на стороне администраторов, которые считают, что использование Gentoo в качестве сервера - отличная идея, и использую его почти для всех своих личных серверов.

Помимо всего этого, что мне нравится больше, чем создание чего-либо из исходников или настройка CFLAGS, так это Portage. Portage - это просто лучший инструмент для управления пакетами и системой, который я когда-либо использовал для GNU / Linux. Я могу создать точную среду только с тем, что мне нужно, и ни с чем другим, и я могу сделать это, не выходя за рамки моей системы управления пакетами. Мне не нужно устанавливать postfix просто потому, что какой-то чувак-упаковщик решил, что это «необходимо». Мне не нужно устанавливать моно, потому что я хочу запустить Gnome, я просто не устанавливаю Tomboy. Быстрый просмотр установленных пакетов на этом рабочем столе Ubuntu показывает, что привязка установлена? Зачем? Это бесполезно, я не использую DNS-сервер на этом компьютере, и мне определенно не нужна документация по нему, но она здесь.

Обратная сторона ... время. На сборку пакетов уходит не только время, но и на поддержание системы в рабочем состоянии. Я действительно могу быть уверен, что смогу запустить sudo aptitude update {upgrade} и не беспокоиться об этом ... С другой стороны, вы должны быть очень осторожны с мелкими деталями при обновлении машины Gentoo и убедиться, что что вам нужно (и вы готовы) к тому, что он хочет делать. `` Солома, которая сломала верблюдов '' на слова о том, почему я переключился на Ubuntu для своих настольных компьютеров, была обновлением udev, которое нарушило мою настройку - вместо того, чтобы пытаться исправить это, я хотел получить работу, которую я пытался сделать сделано. Итак, я решил, что мне действительно все равно, занимает ли связующая документация место на моем рабочем столе, потому что у меня есть место.

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

Жизнь слишком коротка для дистрибутивов на основе исходного кода. У меня есть дела поважнее. Как на компьютере.

Вы всегда можете использовать комбинацию обоих методов - использовать предварительно скомпилированный дистрибутив в качестве основы и иметь преимущества хорошей рабочей интегрированной среды и быстрых безболезненных обновлений при использовании самокомпилированного программного обеспечения там, где нужно быть на переднем крае разработки этого программного обеспечения. Либо проявив некоторую самодисциплину (используя configure с параметром prefix), либо упаковав исходный код самостоятельно. Вы всегда можете "повторно использовать" инструкции по сборке (например, файл спецификации rpm или подкаталог debian).

Я бы не стал использовать механизм сборки напрямую на производственных серверах. Со времен Gentoo я знаю, что есть возможность иметь хост сборки и создавать пакеты, необходимые на этом хосте, чтобы вы могли записывать циклы процессора на выделенном хосте с подходящими для ваших нужд флагами компиляции.

В целом нет особой разницы, почти все наши серверы работают под Debian, но в итоге у нас все равно был узел сборки. Нам потребовалось несколько программных пакетов, которые не были доступны в качестве отладочных, поэтому мы настроили репрезентацию и buildhost для наших нужд, buildhost практически не обслуживается (с точки зрения «работает ли он»), потому что повторное развертывание - это всего лишь вопрос несколько минут, так как мы можем загрузить его по сети, и он автоматически развернется заново.

Независимо от того, переносится ли BSD / Gentoo / Debian, не имеет значения, что реальная прибыль приходит от использования системы (например, при сборе сервисов на разных хостах, которые обеспечивают бизнес-ценность), которая минимизирует потери ресурсов и обслуживается. Мы выбрали Debian, потому что обновления безопасности не представляют сложности, и они предварительно скомпилированы, так что нам не нужно «тратить» время на восстановление пакетов всякий раз, когда выходит обновление безопасности. Это единственный недостаток, который я могу придумать для дистрибутивов на основе исходного кода и на основе двоичного кода.

Я был заядлым пользователем Gentoo для моей машины MythTV, но недавно перешел на Debian из-за времени, необходимого для обновления машины Gentoo. Хорошо, вам нужно действительно обновляться каждые 6 месяцев или около того, но, как вы упомянули, время компиляции может быть слишком большим.

Лучшим из обоих миров будет ArchLinux, который имеет двоичные дистрибутивы, но простую систему сборки, позволяющую создавать пакеты почти в стиле Gentoo. Вы можете выбрать то, что хотите скомпилировать вручную.

Что касается производственной системы, лично я бы держался подальше от исходных дистрибутивов и придерживался чего-то стабильного и, возможно, поддерживаемого (в зависимости от вашего технического персонала), Debian или RHEL.

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

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

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

Файлы конфигурации никогда не обновляются, копии с префиксом ._cfg000 помещаются в / etc, и отображается сообщение, предлагающее вам переместить новые файлы конфигурации вместо существующих.

Я считаю, что с небольшими усилиями gentoo может сделать даже сложные вещи очень простыми.

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

Мы используем Debian на всех действующих серверах, потому что:

  1. Установка не вызывает затруднений.
  2. Обновления безопасности - это просто.
  3. Установить новое программное обеспечение не составляет труда.
  4. Команда Debian очень усердно работает, чтобы держать вещи в курсе последних событий.
  5. По разным причинам мы используем один сервер Gentoo. И мы больше никогда не будем его обновлять, потому что в последний раз я пытался сделать обновление безопасности для чего-то важный в систему (подумайте: критические системные библиотеки), ПЛОХИЕ ВЕЩИ получилось. Мы не можем позволить себе иметь небольшие простои с этим сервером, потому что он очень критически важен, и клиенты действительно замечают это, к тому же серверы Asterisk и сопутствующие PRI очень сложно и дорого сделать избыточными по схеме N + 1. Размер нашей клиентской базы (небольшой) также не гарантирует и не оплачивает ее. Мы скорее столкнемся с (возможно, небольшой) возможностью нарушения безопасности из-за ошибки операционной системы, чем с неизбежным отказом нашей системы, потому что она болезненна и предназначена для людей, которые любят возиться и играть с вещами.

Простота системного администрирования - номер 1 в наших книгах. Простая система в руках эксперта - это высокая надежность и доступность.

Я не использовал Gentoo несколько лет, но мой ограниченный опыт работы с ним привел меня к выводу, что (едва заметное) увеличение скорости, полученное при компиляции пакетов, было намного перевешено недостатком времени, затраченного на сборку системы. С тех пор я всегда использовал предварительно скомпилированные системы на основе пакетов. Я знаю, что лично я не хотел бы тратить так много времени на компиляцию исходников на серверах, особенно когда нужно со временем обновлять пакеты.

Что ж, много лет назад оптимизации компилятора и тому подобное могли выжать дополнительную часть производительности на вашем конкретном оборудовании. Сегодняшнее оборудование настолько мощное, что больше не имеет никакого значения.

Сейчас я использую Debian из-за простоты обновления серверов. Обновление большого количества пакетов с минимальным временем простоя по сравнению с FreeBSD занимает 2 минуты. Я до сих пор использую FreeBSD для некоторых конкретных приложений (например, MySQL и BIND), но это только из-за личных предпочтений (и история этих двух приложений, очень быстрых и стабильных на FreeBSD).

Мой совет всем, кто интересуется какой ОС: используйте то, что вам удобно.

Для вашей конкретной ситуации я бы порекомендовал OpenBSD:

  • Порты поддерживаются в хорошем состоянии и доступны как в исходной, так и в двоичной форме. Если вы компилируете свой собственный порт, он превращается в двоичный пакет, подходящий для использования на других машинах с той же архитектурой.
  • OpenBSD хорошо работает на старом оборудовании.
  • Это также BSD, поэтому многое в вашей работе с FreeBSD будет похоже в OpenBSD.
  • В дополнение к исходным / двоичным пакетам вы можете настроить при необходимости, а затем создать свой собственный релиз, что означает, что вы можете выполнить компиляцию на оборудовании для быстрой сборки, а затем развернуть на более медленном оборудовании.

В обычных ситуациях вы захотите полностью использовать двоичный код. Он постоянно обновляется, и это то же самое, что и вы, если бы построили его сами. Единственное исключение - когда вам нужно что-то скомпилированное со специальными параметрами, недоступными в двоичной форме. Но на самом деле, зачем выбирать, если ваша платформа может дать вам лучшее из обоих миров?

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

Если вы устанавливаете обновление на 100 машин, вы действительно хотите, чтобы оно было скомпилировано в 100 местах? Конечно, компиляторы ДОЛЖНЫ быть последовательными и ДОЛЖНЫ генерировать похожие двоичные файлы, но в принципе нет никакой гарантии.

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

Используйте двоичный файл, и вы будете увереннее, что он будет вести себя одинаково во всей инфраструктуре; у вас больше шансов, что протестированный код будет таким же, как и развернутый. У вас также есть больше шансов, что код будет стабильно работать в ваших производственных системах (даже если он может быть не настолько оптимизирован, как код с оптимизацией для конкретного процессора).