Pull to refresh

Comments 221

>Без документации ни куда

Закончил читать
Учту, хоть и не знал об этом.
Когда столько ошибок в тексте, то иногда надо показательно ошибки приводить. Моё имхо. Поэтому добавлю сюда:
Не смотря (пишется слитно) на бодрое начало (пропущена запятая) надо уточнить, что ряд сложностей (запятая) в сравнении с другими (например (пропущена запятая) дебианом и пресловутой убунтой) все же присутствует.
Без документации (неплохо бы тире поставить) никуда. Вам придется не мало (слитно) прочесть (запятая) чтобы хотя бы установить этот дистрибутив. Крайне желательно (запятая) чтобы она была прочитана на английском, т.к. русская версия не всегда имеет актуальную версию
Консоль — наше все. Если у вас консолефобия, вам придется побороть себя. Она у (что У?) тут всегда и везде — установка, обновление, настройка, все это и многое другое.
Если вам срочно понадобиться (ну сколько можно?) переустановить систему, (зачем запятая?) или поставить её на новую машину, то это может занять довольно много времени. Помните об этом (запятая, опять) когда ставите gentoo в продакшн.


Да, я понимаю, что ошибки допускают все. И опечатки бывают всегда, но минимально вычитать текст ведь можно? Это один абзац я взял. Ошибки на этом не закончились.
В технической статье главное информация, а не отсутствие орфографических ошибок. На хабре под половиной статей коменты про тся\ться, а не по теме. Литературный кружок какой-то.
Т.е. техническая информация оправдание безграмотности? Не согласен в корне. Это как рисовать чертежи. Можно, конечно, нарисовать на листочке в клеточку и показать «важное». Но если это будет показываться людям, то рисуют чертёж в соответствии со стандартами.

Тем более, не так уж и сложно писать грамотно, хотя бы орфографию общеупотребительных слов и базовую пунктуацию. И меньше вероятность быть неправильно понятым.
Не оправдание. Но и не повод засорять коментарии нытьем по поводу орфоргафии. Мне, например, обилие таких коментов режет глаза сильнее чем ошибки в тексте.
Если ошибок терпимое количество, то да, согласен, нужно просто отправить в личку. Но в данном тексте было очень много ошибок. Не потому, что автор совершенно не знает русского, а потому, что поленился вычитать текст. Поэтому и считаю, что в таких случаях стоит публично обращать внимание автора на ошибки.
Консоль с нескучными обоями :)
c нескучными цветами и шрифтами!
Насколько я знаю, можно и обои сделать в консоли :) Было бы желание.
ИМХО, генту переоценивают энтузиасты и при этом у тех, кому она действительно нужна, зачастую нет времени её изучить.

Gentoo — вполне себе выбор для десктопа, но это не лучший для всех десктопов дистрибутив и тем более не единственный годный. Но имхо gentoo гораздо интереснее как метадистрибутив, т.е. способ быстро сделать дистрибутив под конкретную — серверную, embedded и т.д. задачу. При этом проблем с переустановкой на сервере нет: вообще, на сервере может не быть компилятора — под него всё соберётся снаружи. То же самое с embedded. Тяжесть portage и время компиляции при этом вообще не имеет значения. Гента — прекрасный способ собрать заточенный дистрибутив за минимальное время и не сойти с ума.
Неистово плюсую :)
Перепробовал за свою линуксовую практику большой спектр дистрибутивов — попробую сравнить с ними генту используя тактильные ощущения: при сборке под конкретный проект(серверный, десктопный, прошивка… и т. д.) в большинстве других дистрах возникают ощущения что мешаешь руками либо кирпичи, либо гальку или солому с ветками и палками — при работе с гентой возникает чувство что работаешь с глиной или алебастром., бывает что с комочками — но шаманство с конфигами portage и само обновление портежей, их очень сильно сглаживает.
Да-да, ей можно придать любую форму небольшими усилиями. Как не до конца засохшая глина.
А еще в генте часто возникают сложности с некоторыми пакетами, ну к примеру qt там всегда немного странно собирают. Приходится для разработки юзать самосбор в хомяке или лучше вообще из состава Qt SDK
Утверждения, что у генту всё документировано, мягко говоря, неправда. Потому что этой документации часто не бывает от используемого приложения, и авторы дистрибутива мало что могут поменять. Для примера можно назвать дебри конфигов в «реестро-подобной» помойке gtk/qt, или тонкости взаимодействия pulseaudio и blueman'а.

В остальном я просто не понимаю, какую задачу решает gentoo в продакшене. Потыкаться самому на тему «научиться» — да, ок. А продакшене?
Под «документировано» имелось в виду — документирована установка системы, ее конфиги, emerge итд… а то, что разработчик приложения не предоставил документации — не вина Gentoo, ключи и параметры приложение все те же, как и в других дистрибутивах. Но видимо и в других нет манов.
У любого приличного дистрибутива документация более чем обширная. И дебиан, у которого помимо system administration guide есть обширнейшее полиси с мотивационной частью, и centos, у которого цельнотянутая документация от RHEL'а с более чем подробными данными, и SUSE, у которой громаднейшие талмуды. Насколько я знаю, у бубунты тоже такие есть.

То есть я не вижу в этом месте особого отличия. Ну да, у генты тоже есть документация к дистрибутиву. И?
И это делает Gentoo «приличным дистрибутивом» :)
Идея автора ведь и была как раз в этом.
Я не уверен, что это достаточный критерий.
… и скорее всего половина этой документации уже устарела.

Не буду утверждать про Gentoo, очень давно ей пользовался. Но не так давно попытался на eeePC поставить Debian. Казалось бы — куча документации, wiki с описанием подробностей для разных моделей нетбуков. А в результате — то там файлы уже в другом месте лежат, то структура конфигов поменялась, то опции…
На этап от минимальной инсталляции до запуска X с видео/звуком/тачпадом/камерой потребовалось неожиданно большое количество времени.
А в продакшене обычно не используются дистрибутивы для админов локалхоста.
У нас, например, были Video encoding сервера, где были специфические флаги для ffmpeg включены. Кроме того в Генте быстрее становятся стабильными последние версии софта (а особенно продакшн софта), что сильно полезно если вы хотите быстро обновить apache, php. Как минимум с PHP в debian не всё так гладко.
В уважающих себя конторах, когда нужно иметь свою сборку апстрима или текущего пакета, но с отличными параметрами сборки, используют CI'и, которые указанные пакеты собирают, кладут в репозитории и т.д.

Заметим, этим решаются все остальные проблемы (типа «нам надо модуль nginx'а, которого нет в апстриме»), заодно к этой штуке довольно за разумное время прикручивается тестирование (то есть собранный бинарник проверяется на работоспособность роботами, и каждый раз).

Не вижу я пользы от генты, кроме усложнения задачи, которую вся остальная индустрия пытается довести до состояния несуществующей — разворачивание ОС. Даже винды сдались и из готового образа ставятся.
Ну вот как-то я не натыкался на «уважающие себя конторы», хотя неоднократно работал и с большими корпорациями. Обычно мне админы отвечали так: «есть среди пакетов — поставим, нету — не поставим и компилять не будем».
Это означает, что у этих контор не было devops и CI. Условно говоря:

* «версии в папочках, выкатываем на сервер копируя по ftp»
* используем гит, выкатываем пакетами
* Используем CI и configuration manager, робот автоматически выкатывает в продакт после прохождения всех тестов.

Стадия 2 лучше, чем стадия 1, но хуже, чем стадия 3. Вы говорите про стадию 2. Но гента не даст «стадию 3», она заменит неудобства проблемами и всё.
Это также означает, что ваш идеальный мир, когда всегда есть devops и CI не соответствует действительности. А поскольку я живу не в идеальном мире, то предпочту, чтобы Gentoo стояла на серверах чаще и я мог попросить обновить софт и мне реже отвечали отмазками.

У Gentoo, кстати, давным давно только Stage-3.
Оставляем в стороне devops и смотрим на обычную жизнь обычного сервера.

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

В дебиане:
aptitude install -t jessie foobar
(не помогло)
aptitude install foobar

Всех делов — 5-10 секунд на установку пакета, плюс время остановки/запуска сервиса.

В gentoo? Как выглядит процесс апгрейда/даунгрейда? И сколько он занимает? Допустим, мы говорим про что-то большое, класса, например, mariadb.
Реальная VPS.
CPU: Westmere E56xx/L56xx/X56xx (Nehalem-C)
RAM: 1Gb

Классический гентушник вас сделает так:
emerge =mariadb-5.2.14 --autounmask-write --autounmask=y
etc-update
emerge mariadb # ~ 18min
(не помогло)
emerge <mariadb-5.2.14 # ~ 18min

Чем просадит производительность продакшена на время компиляции (LA +2.0).

Правильный гентушник сделает так:
emerge =mariadb-5.2.14 --autounmask-write --autounmask=y
etc-update
ionice -c 3 emerge mariadb -b # В idle IO компилируем и ставим, и собираем также пакет. > 20min
(не помогло)
emerge <mariadb-5.2.14 -K # ~25sec. С учётом того что для прода всегда дополнительно собираются бинарные пакеты

А ещё пакет можно собрать на не продакшене заранее.

Ну а пока вы отходите от истерического смеха, замечу, что:
* Мне плевать на время эксперимента, я найду чем заняться по работе, пока идёт сборка
* Как вы видите выше можно подойти с головой и подготовится перед манипуляциями на проде и минимизировать это время
* Генту просто не для вас, и вы видимо, ошибочно решили, что я безосновательно агитирую за поголовный на неё переход. Нет. Я просто говорю, что лично мне удобнее, когда на сервере Gentoo и я знаю как её готовить. Я сегодня с удовольствием узнал, что в Debian тоже можно мир пересобрать. И это тоже прекрасно.
У правильного джентушника в make.conf заданы PORTAGE_NICENESS и PORTAGE_IONICE_COMMAND. =)

Про distcc ещё можно вспомнить.
Ещё можно через cgroup настроить, если необходимая поддержка в ядре включена.
Отлично, то есть пакеты у нас собираются на других машинах. Это правильно, и такие машины называются «билд-сервера». Но зачем собирать то, что собираться не требует? В чём смысл пересборки софта, к дефолтной сборке которого нет претензий?

Как я уже сказал, я понимаю смысл Генты в качестве «learn through fixing». Но её наличие в продакте мне не понятно.

Более того, у меня есть даже более серьёзная претензия: изменение опций компиляции/сборки приводит к изменению поведения ПО, тем самым расширяя спектр типовых и нетиповых проблем.

Этот аргумент я иногда привожу даже в споре «собирать свою версию на CI или нет». Он не критический, но весомый.

У всех работает, у меня нет. Это что-то в системе или просто криво собрали?

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

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

Что хорошего гента даёт на сервере?
Поскольку вы работаете в «уважающих себя конторах», то ничего. Вам и так всё доступно.

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

Ах, да, а против этого что скажете?
Я просто пытаюсь себе представить процесс жизни с генту в средней руки конторе — и не очень понимаю.

По поводу php ничего не скажу, не эксперт.

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

Нет смысла ставить его всем подряд и использовать как некое универсальное решение. Потому что в каждом конкретном случае он довольно сильно затачивается под себя. Gentoo подходит тем, кто сам себе админ. Не в том смысле, что только крутой админ справится с настройкой, а в том, что только сам пользователь хорошо понимает, что ему нужно от инструмента.
Гента — это конструктор. Это примерно похоже на сравнение конвейера, мелкосерийной сборки и ручной.

Конвейер — как вы описали. Но не всем подходят и не всем нужны конвейерные системы в таком количестве. Кроме того, сам конвейер стоит дорого и его настройка стоит дорого, не всем доступно и нужно.

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

Ручная сборка — checkinstall.

Ещё есть «сборка скотчем» — configure/make/make install, даже говорить об этом не хочу.
В чём смысл пересборки софта, к дефолтной сборке которого нет претензий?

В том, что такого рая на земле не бывает :)
Уважаемый amarao, не стоит так явно отрицать Gentoo. Этот дистрибутив во многом похож на FreeBSD. Есть возможность устанавливать готовые пакеты, без компиляции, программ, конфигурация по умолчанию которых устраивает.

Также Gentoo неплохо подходит тогда, когда используется один, два, три, небольшое количество серверов. Standalone-проекты.
Например, в генте можно заморозить несколько пакетов на точно тех версиях, которые хочется (а не которые в ближайшем релизе). Это может помочь, если обновление ломает abi/api, а чинить зависимые от них пакеты по какой-то причине нельзя/долго. hardened gentoo — очередная причина. Гента нужна далеко не везде, но там, где она нужна, на других дистрибутивах решать те же задачи неудобно.
Я статью ещё не прочитал.

Добавлю про скорость, очень-очень давно, когда гента только появилась — я ей увлёкся, и потом на их форуме прочитал историю, о том, как один интузиаст оптимизации решил сделать всё идеально, тестировал по fps с quake, провёл недели, всё оптимизируя, постепенно повышая fps, я цифры не помню, так что просто из головы напишу типа 60, потом 80, потом наконец 92.

А потом неожиданно поставил redhat, который с ходу выдал 96fps, после этого его увлечение оптимизацией gentoo пошло на нет.
На самом деле мой ноут не был способен воспроизводить видео 1080p, по характеристикам железа. Это было порядка 0.3-1FPS.
Ни винда, с ее прямыми драйверами от радиона, ни дистры вроде убунчи и федоры(кстати федора порезвее).
Всякие PuppyRUS я не тестировал, потому что дистр должен быть прежде всего удобен, а потом уже вопспроизводить 1080p.

Дак вот, гента смогла. Я правда поставил ее с 5 раза только, потом пол месяца пытался собрать Gnome 3, и все работало так криво(драйвера, нестабильные пакеты, не обкатаные скрипты), что я потом снес.
Но суть такая, что даже видео с больших количеством базовых кадров, да и вообще любые какие я нашел — летали. Это было возможно только в одном плеере — mplayer, после вырезки много чего, полной перекомпиляции всей системы с некоторыми -O3 флагами, и куча настроек для компиляции mplayer.

Я хочу сказать — генту отстает стабильной веткой на несколько лет, но если ты не испугался, то радосная новость: упершись в то что не подлежит перекомпиляции — твое железо, ты можешь отодвинуть эту планку.
Просто интересно: а насколько хуже результаты показал mplayer под windows?
У меня аналогичная ситуация, правда на windows, проблема решилать так: старый coreplayer — он творит вообще чудеса, но как основной всё же mplayer, так как core не поддерживает один из популярных аудио-кодеков.
Вы же понимаете, что это не специальное тестирование. mplayer(не помню на файлах какого формата) выдвал 1-3FPS, при частичной загрузке процессора. Это было и на висте и на семерке.
Я просто не могу поверить в 1FPS => 30FPS — в 30кратное отставание винды. или в какую-то особенную оптитизацию gentoo, что оно стало играть быстрее в 30 раз. могу конечно только подполагать, но я думаю просто в установкой винды что-то не так было, не особо в этом разбираюсь, но может какой-то кодек подключался не особо подходящий или что-то типа того.
Все таки видео было 25 FPS, но вам придется поверить. Могу предположить что винда надеялась на видеокарту, а та не справлялась, тогда как гента все считала честно на процессоре. Утверждать точно не могу, но то что загрузка была максимальной, и это был «предел» — точно.
Возможно, плейер на винде не смог нормально сесть на gpu для ускорения.
Хахаха, хабр такой хабр.
Я в разговоре уточнил, что случай из моей жизни, упомянутый раньше, не являяется специальным тестированием, и получил минус. Не то что бы меня расстроило, но это так абсурдно и мило!

Будто я должен немедленно поставить генту, и сделать точные замеры. Эх. Молодцы!)
С огромной вероятностью эта сборка mplayer использовала ffmpeg-mt. Прирост на многоядерных системах колоссальный (прямая пропорция, 2 ядра дадут ~x2).
UFO just landed and posted this here
Мой тоже первый, правда попозже, в 2008.
Так что я не знаю насчет порога вхождения, но тем людям, которые хотят разбираться и им нравится — очень вкусная штука. Я очень многое узнал просто устанавливая систему тогда. Еще были огроменные распечатки с доками, которые я печатал на работе родителей. Эх :)
С интернетом в нашем маленьком городке было тогда туго, заказывал дистрибутив на дисках (вроде бы из Самары).
Это было несколько дисков в пластмассовой коробке (ну такая, которая на несколько дисков в пакетике). Про обновления, конечно, не было и речи :)
И да, первая установка прошла криво, пришлось снести, потому что комп просто перезагружался почти сразу после вывода приглашения на логин… Потом только узнал, что причина была в том, что я выбрал неправильную архитектуру процессора…
UFO just landed and posted this here
Сорри, я ошибся, год был 2006…
Но getdelta — да, рулит, сейчас даже в centos presto так же делает.
Ну если гентувод не смог внятно объяснить в чем прелесть системы, то мне уже подавно не понять.
Ок. Постараюсь в 2х-3х словах. Emerge,OpenRC, возможность совмещать стабильную ветку со свежими программами. Попробуйте на debian-stable сказать, что этот пакет нужен самой последней версии. И это должно обновляться и не мешать обновляться всей системе.
В openSUSE, например, смешивать тоже можно.
Emerge,OpenRC
боюсь, это тоже может мало сказать. В чём преимущество OpenRC? Для меня — это просто ещё одна система запуска демонов.
Ну я писал, что это тоже очень субъективно. Мне эта система кажется проще и понятнее. Про хамелеона… Когда-то был моим любимым, но слишком тормознутый yast. Он меня просто убивал. Ушёл на дебиан.
Все что я описал, есть в других дистрибутивах. Но только в Генте это есть одновременно и в нужных мне пропорциях.
Всё же подробности насчёт OpenRC интересуют.
Забейте, я перешёл на OpenRC давно, никаких преимуществ не заметил.
Когда-то хотел поставить Gentoo, но понял, что без предварительного штудирования мануалов, её даже поставить не получится. В общем, не осилил.
Не нужно там никакое предварительное штудирование. Загружаемся с livecd, в шестой консольке links с handbook, в остальных собираем систему.
LiveCD тоже не особо нужен. Я ставил Gentoo, в процессе читая handbook, из вполне рабочей и установленной на жёсткий диск Ubuntu. Если бы теперь надо было ставить на чистую машину, взял бы grml LiveUSB (потому как там консоль — гораздо более привычная мне zsh + есть графика, если надо).
Сегодня я обычно ставлю из PXE-загруженного Parted Magic. И вообще, я же не сказал «с gentoo livecd», с любого livecd можно грузиться :)
Чтобы так сделать, тоже нужно знать. Я пошёл на сайт Gentoo, скачал installation media. Запустил, а что дальше делать — не ясно. Какой вывод? Надо читать handbook. Просто лень стало делать столько, чтобы просто поставить систему. Может сейчас мне это страшным и не показалось бы, но тогда я Linux использовал года 2, наверное. Я ожидал текстовый интерфейс установки по типу ответов y/n.
Попробуйте на debian-stable сказать, что этот пакет нужен самой последней версии.

pin priority? не, не слышал.
что удивительно, обновляться совершенно не мешает.
Да не слышал. И ведь что странно: один и тот же человек не слышал про pin-priority, а вот про ~amd64 знает. А зависимости пакета мне тоже надо прописывать по одной или он сам спросит и пропишет? И без конфликта версий?
pin-priority — дистрибутивоспецифичная штука. как ebuild'ы в gentoo. она позволяет явно указать предпочтительную ветку для одного или группы пакетов и входит в конфигурацию apt'a.

если вы указываете, что вам нужно всё из stable ветки, но какой-нибудь vim из unstable, то разумеется, все зависимости просчитаются автоматически и у пользователя запросят подтверждение, после демонстрации того, что именно должно быть обновлено. Конечно, могут возникнуть некоторые сложности, если будет запрошен какой-нибудь фундаментальный пакет из experimental. Но всё можно разрулить при желании.

Помимо правки конфигов, можно явно указать нужную версию или ветку прямо в командной строке:
aptitude -t experimental install somepackage
aptitude install somepackage=1.1

Ещё можно принудительно запретить обновлять тот или иной пакет. И вообще там много всего можно, если маны покурить.
Спасибо за пояснение, уже читаю. Но вот незнал я про них. И да наверное это даже плюс дебиана. Просто в Генте, если поставил, 90% этих специфичных утилит знаешь. Хотя бы знаешь, что они есть. Да маны великая вещь.
Еще автор забыл упомянуть пару вещей.
Во-первых, на современных ПК сбор пакетов из исходников осуществляется довольно быстро.
Во-вторых, есть distcc — распределенное компилирование, что дает такие возможности: 1) компилить пакеты, используя мощности нескольких машин, 2) помочь слабому нетбуку мощностями сильного ПК (пусть даже в виртуалке) при пересборке всего мира или очень большого пакета, например.
Особенно если настроить компиляцию в ОЗУ.
Ну, тогда, про ccache напомню. Сильно ускоряет пересборку пакетов. Например gcc обновляется редко, но иногда пересобирается.
У меня вопрос к автору: поддерживает ли Gentoo полностью автоматическую установку? В частности, интересует сравнение с Дебиановским pre-seed.
Хоть и не автор, но preseed — это ответы на вопросы при установке. В Gentoo никто вопросы не задает, все руками, но ничто не мешает написать скрипт, если много установок.
Preseed — это не просто «ответы на вопросы при установке». Это, фактически, полное описание процесса установки от формирования разделов диска до установки конкретных компонентов и запуска определённых команд. Без такого механизма дистрибутив в продакшене бесполезен. Конечно же всё можно поставить и руками, но когда разговор идёт хотя бы о десятках серверов — а ведь мы же серьёзные люди, и серверов у нас никак не меньше сотни, правда? — ручная установка занимает неоправданно много времени и сил, да и просто становится опасна. Но как игрушка Gentoo подходит вполне.
Просветите незнающего студента, это зачем нужно иметь столько серверов?
Многие сотни машин — вполне нормальная ситуация. Во многих случаях web проектов идет наращивание хранимых объемов, к примеру.

Да, только ноды в таких проектах разворачиваются из снапшотов, само хранилище подключается сбоку и обычно всей установкрй занимается Chef, а никак не админ.
Каждой машине свои локальные данные. Одно хранилище на много нод не потянет нагрузку.
А как эти ноды настраивать я не говорил, прокомментировал именно «зачем столько серверов».
Проекты, в которых задействованы сотни машин и шеф — это облачные социальные стартапы на амазоне. К серьёзным проектам это не относится.
Вы действительно считаете, что в суровом продакшне с каждой железкой аозятся путем Preseed? У меня для вас плохие новости…
Вот, кстати, несколько offtopic, но на тему deploying на сервера презенташка. На недавнем highload++ выступал товарищ. Готовые сборки с автоматическим тестированием и раскаткой. Правда очень ruby'низировано :)

Ну или Chef, Puppet, и т.п.
Готовую сборку нужно сперва собрать так или иначе, что включает в себя написание какого-то сценария сборки в той или иной форме. Preseed это как раз такой сценарий, позволяющий избежать лишнего шага — непосредственно сборки самого дистрибутива.

Chef, Puppet, Ansible и прочие подобные решения практически бесполезны: всё, что они могут сделать, можно сделать скриптом на баше, которому нужен будет только сам баш и «стандартные» юниксовые компоненты, то есть всё, что и так уже есть в системе. К сожалению, писать скрипты на баше не круто. Круто (в особенности в стартапной субкультурке) использовать бесполезные решения с высоким вау-фактором.
Первый раз понял насколько смешна эта шутка, когда таки смог первый раз довести генту до юзабельного состояния. Без этого — всего лишь длинный и непонятный набор команд.
Если не ошибаюсь, то только самопальным скрипом.
UFO just landed and posted this here
>пресловутой убунтой

Да вы что, серьёзно?
Я так и не понял, чем Gentoo лучше популярных дистрибутивов, чем хуже — знал и раньше.
Генту — дистрибутив для перфекционистов и тех, кому не всё-равно какие внутренние процессы протекают в системе. И они готовы выделить на это дополнительное время. Если вы не относитесь к этим категориям, то генту не для вас.

А недостатки, кстати, легко нивелируются, нужно только читать доки и статьи сообщества.
Мне ровно то же самое доказывали насчёт Slackware :) Да будет святая война!
Никто и не говорил, что Gentoo — один такой дистрибутив.
А как же холивор? Gento vs Slackware?
А зачем? Мир. Труд. Ноябрь.
Все, о чем вы написали, в равной степени применимо и к Arch, например, и при этом там не надо париться с исходниками. И вики у них, кстати, получше гентушной.
там не надо париться с исходниками
Вот что мне нравится, так это то, что можно париться с исходниками если хочешь, но совсем не обязательно. Есть ли какая серьезная причина отсутствия в Gentoo собранных пакетов хотя бы для самых популярных платформ?
Спасибо, посмотрю.
UFO just landed and posted this here
Где-то читал, что прекомпилированные пакеты убрали уже, теперь только из исходников, хотя возможно я ошибаюсь. В любом случае можно же было сделать как в том же Arch — хочешь, компилируешь из исходников через ABS, не нужна оптимизация/опции — ставишь через pacman собранный бинарник с разумным набором опций. Мне опции-то нужны на паре-тройке пакетов, не более, зачем мне все остальные компилировать с нуля с опциями по умолчанию, если я могу их просто скачать?

Честно говоря, мне философия Gentoo немного больше нравится, но отсутствие бинарных пакетов портит картину :(
Никуда их не убрали и не собираются. Вот вам на свежей системе, синк не больше недели назад, три примера:
# emerge -s virtualbox-bin libreoffice-bin firefox-bin
Searching...    
[ Results for search key : virtualbox-bin ]
[ Applications found : 1 ]

*  app-emulation/virtualbox-bin [ Masked ]
      Latest version available: 4.3.2
      Latest version installed: [ Not Installed ]
      Size of files: 98,133 kB
      Homepage:      http://www.virtualbox.org/
      Description:   Family of powerful x86 virtualization products for enterprise as well as home use
      License:       GPL-2 PUEL

Searching...    
[ Results for search key : libreoffice-bin ]
[ Applications found : 2 ]

*  app-office/libreoffice-bin
      Latest version available: 4.1.2.3
      Latest version installed: [ Not Installed ]
      Size of files: 80,572 kB
      Homepage:      http://www.libreoffice.org
      Description:   LibreOffice, a full office productivity suite. Binary package.
      License:       LGPL-3

*  app-office/libreoffice-bin-debug
      Latest version available: 4.1.2.3
      Latest version installed: [ Not Installed ]
      Size of files: 871,042 kB
      Homepage:      http://www.libreoffice.org
      Description:   LibreOffice, a full office productivity suite. Binary package, debug info.
      License:       LGPL-3

Searching...    
[ Results for search key : firefox-bin ]
[ Applications found : 1 ]

*  www-client/firefox-bin
      Latest version available: 17.0.9
      Latest version installed: [ Not Installed ]
      Size of files: 21,151 kB
      Homepage:      http://www.mozilla.com/firefox
      Description:   Firefox Web Browser
      License:       MPL-2.0 GPL-2 LGPL-2.1

Причём, virtualbox-bin замаскирован из-за лицензии PUEL, которая несвободная. Это не OSE редакция, а полная бинарная редакция Oracle с несвободными дополнениями вроде USB2-контроллера и чем-то там ещё.
UFO just landed and posted this here
А зачем они там, собранные? Самому собрать — несколько минут, качаться будет столько же.
Сильно зависит от пакета. Скачать Gnome — дело пяти-десяти минут. Скомпилировать его куда дольше займет, особенно не на топовом железе.
И при этом там в 10 раз больше проблем, потому что bleeding edge, потому чуть что, то сразу abs, которая и рядом не валялась с portage. Арч хотя бы конфиги научился уже сам мерджить?
Ну какбэ тут посылка и была в том, что наличие проблем и граблей, и очевидных способов их решения, стимулирует к ковырянию в конфигах и вдумчивому чтению документации, что способствует лучшему пониманию системы.

А так проще всего поставить дебиан и не париться — все работает из коробки, никакой головной боли с апдейтами (даже на unstable, из личной практики), и при этом можно везде залезть руками, если надо/хочется.

Мерджить конфиги с изменениями pacman не будет, и это, кстати, правильно, учитывая очень свободный формат большинства юниксовых конфигов. Но для любителей есть, например, порт etc-update.
Зашел за комментарием про Арч :)
А еще он точно так же приучает курить мануалы, прививает понимание как, что, откуда и зачем. Только ценой меньшего времени, ппожалуй.
Причина сменить арч на дженту у меня была как раз в том, что арч требовал к себе слишком много внимания и на это уходило время.
Добавлю свои 5 копеек, как человек, давно сидящий на gentoo, начинавший с redhat и прошедший debian.

У gentoo и правда высок «порог вхождения» как мне кажется, и мне приходилось «разруливать» сложные ситуации в debian/ubunto redhat/centos. И сейчас постфактум я могу сказать, gentoo мне представляется как чистый незамутненный взгляд, позволяющий понять как вообще устроена linux-система на тонком уровне.

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

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

И чтобы из всего этого выбрать генту, нужен еще какой-то критерий. Причем ими вполне могут быть и случайности — ну там диск с гентой был под рукой — или даже абсолютно субъективные вещи, вроде «а мне цветной вывод emerge больше нравится». Но надо себе честно в этом признаться :)
Чтобы понять как устроен linux это повозиться с LFS. А так можно понять как устроен gentoo.
Я что-то так и не понял, почему сборка из сорцов гарантирует системе большую стабильность. С чего вдруг?
Оно никак не связано. Сборка из исходников даёт управляемость опциями компилятора и включение/выключение отдельных фич.
Не гарантирует. Есть, описанный мной, момент, когда ты знаешь что фича пакета вызывает сбой, а без нее работает нормально, можно убрать флаг и пересобрать. Стабильность достигается установкой стабильных версий ПО. Тут скорее преимущество системы маскировки перед системой разложения ПО по разным репозиториям. Просто, в дебиане, в стабильной ветке, десктоп удержать очень сложно. А генту проще. Нестабильные версии только если это надо. Плюс нет проблем с установкой разных версий библиотеки.

> Просто, в дебиане, в стабильной ветке, десктоп удержать очень сложно. А генту проще

Да почему проще-то? Что это за уличная магия?
Я дебиан не трогал пару лет. Напомните мне что мне надо сделать, чтобы получить на стабильной ветке последнюю версию пакета А.
Понятия не имею. Я просто пытаюсь понять, каким образом сборка пакета А из исходников вместо скачивания .deb из репозитория делает систему стабильнее.
Ну ответил я вам уже. Никак, кроме редкого, но возможного случая. За стабильность ответственна система установки и исходники совершенно непричём.
Исходники просто дают гибкость в настройках пакета, которая мне нравится, а вам, похоже, не нужна.
Ок. А почему система установки Генту гарантирует большую стабильность, чем дебиан?
Потому, что реально собирается меньше кода. За счёт вырезания кучи хлама юзефлагами. Меньше кода — меньше проблем.
Непонятно. На разных-то системах вырезается разный код. Итого в целом объём кода тот же.
На разных — разный, но на каждой кода остаётся меньше, чем в дебиане. Иногда наоборот включаются модули, которых там нет, но это бывает ощутимо реже.

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

А почему из-за этого дистрибутив становится стабильнее в целом?

Потому что в целом кривого кода меньше, ваш К. О.

Очевидно, если есть какой-то конфликтующий код, то всегда найдётся система, в которой именно этот кусок кода собрался. И вот если у тебя такая система, то понять, где ошибка — гораздо сложнее, потому что она воспроизводится только у тебя.

Наоборот, поскольку у всех нет фичи Х и нет проблемы, у тебя фича Х есть и есть проблема — гораздо проще идентифицировать проблемную фичу Х. Сравните с убунтой: всё у всех одинаковое, а проблема есть не у всех. Поди разбери, что там не так.
Нет, я не троллю. Я пытаюсь таки выяснить, что за уличная магия происходит и почему собранная из сорцов система стабильнее, чем система на бинарниках тех же сорцов.

> Наоборот, поскольку у всех нет фичи Х и нет проблемы, у тебя фича Х есть и есть проблема — гораздо проще идентифицировать проблемную фичу Х.

Не понял логики. Там полная система фичей — у каждого из вагона пакетов есть какие-то фичи. Как определить, что с чем сконфликтовало?
Ну фичи редко конфликтуют. Чаще просто одна какая-то глючит. Ну то есть я на глюки нарывался, на конфликты фич — не помню такого.

По поводу глюков, вызванных сочетанием пакетов — app-emulation/virtualbox[vboxwebsrv]. Версия 4.1.x — не собирается с libxml2 больше какой-то версии, не может сгенерировать wsdl для soap-сервиса, коим является vboxwebsrv, и сборка падает. Причина в некорректном исходнике Virtualbox, а раньше он собирался потому, что проверки libxml2 были менее строгими. В версии 4.2.что-то там это пофиксили.
Как это диагностировать? У вас перед глазами весь лог сборки. Видно, какая команда на каком файле и с какой ошибкой зафейлилась. Найти проблему — ну реально раз плюнуть.
Без vboxwebsrv собирается, т.е. вот вам реальный пример, что пакет не глючит потому, что глючный код не собран и в итоге отсутствует.
Как минимум тем, что собирая пакет, вы можете собрать только то, что вам нужно, вы сами управляете этим процессом. Например вы можете собрать nginx только с официальными модулями, а deb вы скорее всего скачаете и nginx там будет собран с кучей патчей и модулей очень сомнительного качества, и это довольно частая причина разнообразных глюков и падений.

Разумеется deb тут не виноват, но картинка в итоге получается не в пользу многих бинарных дистрибутивов.
Видимо, я тогда что-то не то понимаю под стабильностью.
То, о чем вы пишете — workaround. Если у вас какие-то проблемы, в Генту у вас больше вариантов их решения по причине возможности скомпилировать только нужный функционал. Но «из коробки», т.е. в дефолтной поставке, Генту ну никак не может быть стабильнее Дебиана.
Генту ну никак не может быть стабильнее Дебиана

«А она есть.» Ну вот получается так.
Это не workaround, это смысл gentoo, такое возможно со всеми, в том числе и системными, пакетами.
Взять то же ядро: если по хорошему подойти, можно отключить кучу ненужных модулей и функций, которые никогда не понадобятся.
Понадобились? Не проблема, пересоберем.
Кроме того, можно управлять ключами компилятора при сборке. Если я не ошибаюсь, в бинарных дистрибутивах используется -O2 ключ оптимизации производительности, в Gentoo у меня -O3, глюков не замечено, хотя, если честно, я и не сравнивал производительность, надо бы…
Итого: собрать пакет под свою конкретную систему, под свои нужды без ничего лишнего, более оптимизированный — ведет к ускорению работы всей системы, так как это применяется ко всем пакетам. Да, надо заморачиваться, решать, что тебе надо, а что нет, но это даже интересно. :)
И да, мое мнение — Gentoo для десктопа. Ну или для «серверов», где все плохо с ресурсами, а надо чтобы все шевелилось быстрее.
Я пожил-пожил с -O3, попробовал -O2 — жить легче. Собирается быстрее, работает не медленнее.
Смысл системы — не смысл системы, какая разница.
Я пытаюсь понять, с чего Генту стабильнее Дебиана. Пока ответ «ну вот получается так».
Меньше включаемых возможностей (мы сами определяем, что нам нужно) -> проще софт -> меньше вероятность «падения».
Это я понял. Но дефолтная установка, без доп. конфигурирования, должна быть точно так же стабильна, как и дебиан.
Ну в общем, да.
А вообще там нет «дефолтной установки», всё в консоли.
В процессе этого правятся конфиги, в том числе и параметров сборки пакетов и конфиг ядра (если заморачиваться).
Хотя да, если мы ставим из stage3 (а так рекомендуется делать), то там уже бинарники, но никто не мешает их после установки пересобрать под свои параметры.
Просто ставить Gentoo в «дефолтной установке» особого смысла нет, ну только разве что из-за удобного пакетного мэнеджера.
Разные подходы, вот и все :)
Мне еще интересно, за что минусы, честно искал используемый Gentoo на серверах в интернете — не нашел, но буду рад, если гугл ошибается.
Нет дефолта. Ну то есть, вы не сможете поставить kde, вообще не правя use-флаги. Там между ними есть зависимости, например, чтобы собрать пакет X нужно иметь Y собранным с use-флагом flag; а бывает и так, что чтобы включить, скажем, kde, нужно включить wxwidgets (пакет p7zip такой, например), или так: чтобы включить A нужно включить Б либо С, но одновременно включить их нельзя.
И это повышает стабильность? о_О
Нет, это «нет дефолтной установки, которая так же стабильна, как дебиан». Есть только ручные установки, которые более стабильны, чем дебиан.
Как минимум дефолт в Debian означает антикварный глючный и дырявый софт во многих случаях. Gentoo же не скована необходимостью держать годами систему в консистентности с устаревшими версиями различных библиотек и софта.

В дженту если обнаруживается критический баг в библиотеке — обновляется библиотека и все счастливы. В дебиане сначала кто-то должен забекпортить патч, зачастую это весьма нетривиальная задача и имеет последствия, а иногда и вовсе не выполнимая, так что если баг не слишком серьезный, то его исправлять не будут.
В генте просто нет «дефолтной установки». Вам в любом случае придется выбрать один из профилей (например для amd64):
[1] default/linux/amd64/13.0
[2] default/linux/amd64/13.0/selinux
[3] default/linux/amd64/13.0/desktop
[4] default/linux/amd64/13.0/desktop/gnome
[5] default/linux/amd64/13.0/desktop/gnome/systemd
[6] default/linux/amd64/13.0/desktop/kde *
[7] default/linux/amd64/13.0/desktop/kde/systemd
[8] default/linux/amd64/13.0/developer
[9] default/linux/amd64/13.0/no-multilib
[10] default/linux/amd64/13.0/x32
[11] hardened/linux/amd64
[12] hardened/linux/amd64/selinux
[13] hardened/linux/amd64/no-multilib
[14] hardened/linux/amd64/no-multilib/selinux
[15] hardened/linux/amd64/x32
[16] hardened/linux/uclibc/amd64

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

Так что «дефолтная установка генту» понятие просто не определенное.
Для меня Gentoo — это дистрибутив как для человека, который не хочет тратить много времени на настройки, обновления и вообще возиться с системой, а эффективнее использовать время для работы. Во всех ранее опробованных дистрибутивах (в основном deb-based) постоянно возникали одни и те же проблемы, что-то ломалось после очередного крупного обновления, возникало много возни, когда нужна была более свежая версия какого-то пакета или библиотеки, иначе собранного, да и вообще регулярно что-то приходилось подкручивать, вытачивать напильником.

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

Если вы разработчик — то это ваш дистрибутив. А любимым девушке и бабушке можно убунту поставить.
В свою бытность гентушником (это, правда, было шесть лет назад), она ломалась на обновлениях куда как чаще, чем дебиан.
Да, было такое. Сейчас такого почти нет. Хотя проблемы если вы долго не апдейтились — остались.
Вот недавно обновил мир после долгой лени (обновление на >900 пакетов). Проблем было две — Qt (когда уже сделают нормально сделают) и один пакет был реструктуризован и переименован, что привело к блокировке. После этого почти все пакеты успешно обновились (пара -9999 падает на сборке, вменяемые версии этих пакетов нормально собираются). А на секундочку — у меня не stable а суровый bleeding edge, любые попытки поддерживать в таком обновлённом состоянии дебиан приводили к удалению дебиана (хотя на серваках я держу деб, ибо там виртуалка а я жмот xD ).
Поэтому если у вас свербит, хочется самые свежие версии пакетов и чтобы работало при этом — гента отличный выбор.
Ни холивора ради, но что не так с QT? Ни разу не сталкивался, так чтоб знать чего бояться. Правда я по мере возможности на stable.
если вы хотите изучить детально и досконально linux, то gentoo это то, что надо
Это очень давно неправда, gentoo можно поставить по хэндбуку и пользоваться без включения мозга.
в свое время я ставил gentoo с dial-up win-модемом, когда об инсталляторе только шли разговоры
gentoo по сути тот же LFS, но в рамках portage, для сборки очень специфических пакетов используются свои ebuilds и overlays
есть базовый «порог вхождения» — stage3, а дальше можно усложнять
Яростно плюсую, причем ставить надо, начиная со Stage 1, желательно имея 3G модем в качестве средства доступа к инету и, соответственно, тарболам. И постараться довести поставленную таким образом систему до вполне — десктоп-юзабельной системы, с балеринами и преферансом.
Мегапрофит в виде 80+ лвл к знанию потрохов системы, железа и пониманию что как пашет — обеспечен.
«The Gentoo Handbook only describes a Gentoo installation using a stage3 tarball. However, Gentoo still provides stage1 and stage2 tarballs. This is for development purposes (the Release Engineering team starts from a stage1 tarball to obtain a stage3) but shouldn't be used by users: a stage3 tarball can very well be used to bootstrap the system. You do need a working Internet connection.»

Сначала нужно поставить Stage3, и потом уже, если показалось мало, то понижать цифру.
Пользовался gentoo несколько месяцев, но это больше был challenge такой. Потратил несколько недель, чтобы более-менее прилично настроить энергосбережение на ноуте, в итоге работало чуть дольше, чем в винде (под ubuntu обычно время работы процентов на 20 меньше с базовыми твиками). В итоге поигрался и оставил это дело. Emerge до сих пор вспоминаю, очень удобный менеджер пакетов.
Прелесть генты в том, что ей можно занять кучу свободного времени, получив в итоге почти такую же удобную систему, как убунта из коробки.
Меня последнее время больше привлекают путешествия, программирование, бизнес, общение с симпатичными девчонками.
Поэтому с генту как-то не складывается :D
А когда был школьником — да, ебилды конпелировал в поисках священного грааля :D
Rolling-релизы делают обновление более безболезненным.

Мне плохо, вызовите врача.

Я к тому, что как раз обновление-то gentoo — это головная боль практически всегда.

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

Делать редко — если прошло больше полугода, в половине случаев пару раз обновляется какой-нибудь удев и ещё пару раз — ядро, да так, что новое ядро не поставишь со старым удевом, а новый удев не встаёт на новое ядро. В это кольцо зависимостей обычно включается openrc, ещё какой-нибудь kmod (по вкусу). В результате, обновить систему и иметь возможность работать в процессе крайне сложно. Через жопу и с помощью такой-то матери, конечно, удаётся:

Сначала обновляем portage. По возможности, если удаётся (обычно удаётся) ядро. Перезагружаемся.
Система стоит на LVM-томе, делаем его снэпшот, монтируем в /mnt/gentoo, туда /dev /boot/ proc /sys (как при установке), чрутимся, там как-то обновляем мир (с парой падений сборки в процессе — это я на стабильной ветке, если ветка нестабильная — перезапускать emerge -abvuDN world вы будете раз двадцать). Заметили ключик -b? Это мы собираем пакеты. Готово — мержим конфиги, выполняем предписания pre- и post-install, читаем и разбираемся с новостями, собираем поломаные зависимости (раньше был revdep-rebuild, сейчас проще). И это готово?
Настраиваем в загрузчике вторую запись на новую систему (на снэпшот). Загружаемся, пару дней тестим. Всё нормально? Таким же образом монтируем в снэпшот-системе оригинал, накатываем туда пакеты, повторяем изменения в конфигах. Перенастраиваем загрузчик, перезагружаемся, удаляем снэпшот.
Всё.

Просто? Не особо. Зато, если что-то сломалось в процессе обновления, пользователь даже не заметит. У него всё работает. Если что-то сломалось просто в новых версиях, это желательно выяснить за пару дней тестов, если хреново — ну так это был снэпшот, оригинал (старая система) у нас всё ещё жива.

Делать это каждую неделю — убьёшься. Каждый месяц — тоже. Особенно, если систем больше, чем одна, и они десктопы. А раз в полгода — сложность процесса возрастает :(
Для гентушников-комментаторов: я прямо сейчас этим занимаюсь. Система полугодовой давности. Вот всё по самому неудачному сценарию: куча взаимных блокировок между критичными системными пакетами, которые автоматом не разрешаются.
Да, да. Это архитектурная проблема. Хотябы 1 раз в месяц или два лучше апдейтится, чтобы в случае проблемы легко её разрулить.

А вообще поддерживать чужой десктоп с Генту — это неправильный подход изначально.
Ну, один на работе, один дома, ноут… все мои :)
Делать его часто — умучаешься конфиги сливать и вообще воздух греть процессором. Это муторный процесс, не особо интеллектуальный, но противный.
Греть воздух вы не умучаетесь. Главное, не смотреть на процесс компиляции.

А насчёт слияния конфигов: у меня этим занимается mercurial. Конечно, потребовалось написать скрипт, но оно того стоило: 99% времени слияние — просто ./update-script --all (он перемещает все изменения в клон /etc, содержащий только неизменённые версии конфигов в ветке default, применяет их там без каких‐либо вопросов, делает commit, затем запускает pull и merge в ветку user в /etc). Зачем делать merge самостоятельно, если есть VCS, которая умеет этим заниматься?

Для падений сборки есть emerge --keep-going: можно собрать всё, что собирается, а затем разбираться с проблемами. Ещё есть emerge --resume[ --skipfirst] для возобновления сборки, но я этим не пользуюсь.
Греть воздух вы не умучаетесь. Главное, не смотреть на процесс компиляции.

за электричество-то плачу я
(понимаю, странно звучит, «тогда используй не source-based». Неудобные они)

Для падений сборки есть emerge --keep-going: можно собрать всё, что собирается, а затем разбираться с проблемами.

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

Зачем делать merge самостоятельно, если есть VCS, которая умеет этим заниматься?

Вас не смущает, что это до сих пор не встроили в систему, хотя могли? Ваши предположения, почему?
Вас не смущает, что это до сих пор не встроили в систему, хотя могли? Ваши предположения, почему?
При первичной настройке VCS вы потратите очень много времени на то, чтобы определить, что нужно, а что не нужно игнорировать. В случае встраивания такого варианта в дистрибутив надо напрягать maintainer’ов каждого пакета, пишущего что‐либо в /etc. Так что, если идея не пришла людям в голову при создании дистрибутива, то через несколько лет существования maintainer’ам неохота напрягаться. Хотя напрягаться надо будет гораздо меньше, если объявить, что по‐умолчанию всё в /etc будет под контролем VCS, а указывать надо только исключения, но тогда под контролем окажется много мусора.

Также, чтобы избежать holywar’а, нужна поддержка любой VCS. Или, по крайней мере, любой VCS, имеющей нормальные ветки с простым merge.

Ещё, возможно, никому просто не пришло в голову, что это надо встроить в систему. Я не раз подумывал написать о моём скрипте сюда (на habrahabr), но ни разу — пойти на bugs.gentoo.org и предложить что‐то подобное там. Хотя с поддержкой со стороны portage было несколько
проще: мне не нужно было бы убеждаться, что все мои изменения зафиксированы перед использованием скрипта. Поддержка portage нужна только, чтобы отделять мои изменения от не моих, mercurial всё равно не даст сделать слияние при наличии незафиксированных изменений. Можно, правда, делать слияние в третьем месте, а в /etc делать pull+update, тогда незафиксированные изменения будут слиты (но останутся незафиксированными). Но конфликты придётся разрешать в том третьем месте.

Merge также не всегда корректен. Просмотр изменений после слияния — это задача администратора, но могло оказаться и так, что запрос был, но кто‐то решил, что администраторы не будут делать review и потому данная возможность опасна.
Ну, справедливости ради, etc-update — как раз и есть ручное разрешение конфликтов. А то, что можно сделать автоматически, он и так делает автоматически. Я не пойму — вы хотите сказать, что больше можно сделать автоматически? Я не согласен. Не могу припомнить случай, чтобы я сливал что-то руками и это было тривиально до автоматизации. То дефолт поменяют, то ещё что-то.
*whisper*: dispatch-conf же!
Больше, чем etc-update — легко. Тривиальными изменениями он меня доставал постоянно (т.е. постоянно требовал изменения шрифта и раскладки в консоли (/etc/conf.d/consolefont и /etc/conf.d/keymaps)). Он не умеет делать merge, там в опциях только взять то, взять это, слить вручную, показать ещё раз diff и сохранить то как пример. После изменения конфига от вас после каждой пересборки пакета, к которому этот конфиг относится, etc-update будет требовать решения. Или мы говорим о разных etc-update.

Есть dispatch-conf, у которого, как говорят, дело с этим лучше. В частности, в его справке я нашёл упоминание об использовании RCS (это одна из древних VCS) или «каталога архивов» (т.е. версионировании без VCS) при наличии соответствующих настроек. То есть, говоря о том, что схожий вариант не интегрировали в Gentoo, вы, вероятно, не правы. Немного жалко, что я не стал разбираться: возможно, можно было бы допилить dispatch-conf для использования mercurial.
Так оно нередко и бывает.
Не поймите меня неправильно, но всё же бывает оно ну ооочень редко.
Не знаю, как в Gentoo, но в другом известном дистрибутиве есть такая штука как etckeeper.
Её смысл — как раз хранение конфигов и изменений в них. Запускается по триггеру обновлений.
В бэкэнде лежит VCS (можно выбрать, какую именно хочется использовать. Тот же меркуриал, к примеру)
Удивили. На своём ноуте запускаю layman -S && emerge --sync и затем emerge -uD world каждый день перед обедом. Реально обновления появляются максимум пару раз в неделю и в большинстве случаев (если это не какой-нибудь KDE, Firefox, gcc или LibreOffice обновился) сборка заканчивается до того, как я заканчиваю трапезу. Обновлять конфиги приходится и того реже, может быть в среднем пару файлов за месяц, и то это сводится к замене старого на новый, т.е. нажать пару кнопок. Так чтобы реально мерджить — случается раз в полгода. Когда последний раз что-то ломалось — не помню, в этом году точно ни разу.
Как я уже не раз писал, поддерживаю больше десятка хостов с гентой. Собираю все на одной ферме, потом через бинхост раздаю. Использую openrc+eudev(mdev на vds)+(gentoo|hardened)-sources. Никаких серьезных проблем с обновлениями, кроме как с dracut пару раз, не припомню. Но dracut он на то и в ~. Обновляю десктопы раз в неделю, сервера и хосты типа медиаплеера по нужде (nginx\vlc обновился). Даже глобальная миграция grub-legacy->grub2 произошла без шума и пыли. Это у меня карма такая?
например дебианом и пресловутой убунтой


Не понимаю, почему Вы навязываете мнение и собственно почему убунту пресловута рядом с дебианом? В чем различия от дебиана, которые делают ее пресловутой? У них разница только в том, что убунту использует пакеты из sid Debian и выпускает релизы раз в пол года. Это делает ее пресловутой?
у Вас, имхо, неправильное понимание слова «пресловутый». Это не ругательство и не обзывательство. Это указание на помешанность на предмете большого числа людей.
Это, как выяснилось, не совсем так:
Значение слова Пресловутый по Ефремовой:
1. устар. Известный, знаменитый, славный.
2. перен. Получивший отрицательную или сомнительную известность, славу (обычно с оттенком иронии).
А так же имеет свой магазин и кучу ненужных предустановленных пакетов.
Если нет желания ковыряться, кому-нибудь поставить и чтобы работало — да, сойдет.
Если хочется чего-нибудь конкретно под свои нужды, ни больше, ни меньше, то один из вариантов — Gentoo.
Кстати, автор забыл упомянуть про наличие вполне себе почти полноценной убунты на базе генты (вместо дебиана), Sabayon называется.
Извините, не хочу ругаться на хабре и доказывать, почему Calculate — далеко не то.
Но да, он есть. Более того, именно благодаря ему в основной генте eix заговорил по-русски а-ля: «совпаденье», «чтенье», «улучшенье», «сравненье», «обновленье».
Вот честно, текстом невозможно передать того, какие чувства были по отношению к автору.
OH WOW!
Аж захотелось русскую локаль поставить.
Кто это такой эрудированный-то в команде калькулятора, по ком дубина плачет?
Да, так-то, при следующем «обновленьи» вылечили. Но осадок остался. А вообще, поговаривают, у них там в команде трансляторов — девочка-филолог™, которой нужно упражняться, вот она гентушные маны и утилиты переводит. Правда, я сомневаюсь, что она причастна к мягким знакам. Тем не менее, откуда появились мягкие знаки Lautre не признаётся :)
Сейчас действительно много Елениного перевода попало в гентушную локализацию, но это не касается того перевода eix, о котором Вы тут пишите. Так что не надо наезжать на людей не зная причин. Девушка работы сделала столько, сколько Вам и не снилось.
Предлагаю дочитать комментарий, на который ты ответил, до конца, прежде, чем наезжать. Либо, если он прочитан до конца, попытаться сопоставить логическую цепочку предложения:

она гентушные маны и утилиты переводит.

Правда, я сомневаюсь, что она причастна к мягким знакам.

откуда появились мягкие знаки Lautre не признаётся :)
к слову,
Девушка работы сделала столько, сколько Вам и не снилось.

и есть
Так что не надо наезжать на людей не зная причин.


Я не хочу выпячиваться, но я работы сделал как минимум не меньше. Пусть и не вся она была для переводов (хотя и по ним я тоже делал). Так что не надо такого пафоса, пожалуйста. Она контрибьютит — молодец, хорошая девочка. Но вот видеть красную тряпку в каждом комментарии, где рядом упомянут негатив относительно ЧЬЕЙ-то (с явным указанием на неизвестность автора) неправильной работы и ВСКОЛЬЗЬ упомянута она — попахивает, знаете ли, ем-то нездоровым.
А по-моему весело :)
Я был бы не против, например, на 1 апреля такое в терминале увидеть, а ВНЕЗАПНОЕ первое апреля в обычный день — это же вдвойне здорово! :)
UFO just landed and posted this here
советовать сборку дистрибутива (calculate), который не контрибьют в апстрим (gentoo) ничего, в отличии от более удачных вариантов (sabayon) и наследников (funtoo) минимум не хорошо.

Перевод текстов и манов не в счет, для этого не нужно жить отдельной жизнью.
С фантой жизнь не сталкивала, а вот с sabayon от моих кривых культяпок глючил сильно. Поэтому его советовать язык не поворачивается.
Как по мне — сборка из исходников на проде сродни хождению по граблям. Никто не гарантирует, что сборка с -O3 и своим набором флагов не поломает что-то в логике приложения или банально не нарвется на баг самого компилятора.
Если же брать уже собранный бинарник, то именно его уже проверили (и продолжают тестить) огромное количество народа в весьма разных окружениях.
Побаловаться на десктопе (ура! программа грузится на 0.2сек быстрее!) или собрать узкоспециализированный дистриб под конкретные железки еще, может, и имеет смысл.
нарвавшись на баг самого компилятора можно неплохо помочь всему linux-сообществу, сборка из исходников позволяет протестировать тот или иной пакет на множестве конфигураций в самых разных окружениях, что сделает систему еще более стабильной
Пользуюсь Gentoo больше 7 лет, пользовался SuSE, Debian, Slackware, Arch( продолжая пользоваться).
Плюсы Gentoo для десктопа:
1) Возможность почти безболезненно держать git-версии пакетов(болезненность проистекает только от того, что в git одного пакета поломали api и git другого с ним не собирается). Лично для меня это принципиально, в ситеме всегда 3-4 git пакета.
2) Возможность вырезать напрочь все лишнее из пакетов. Вроде semantic desktop, akonadi в KDE. Последнее время использую крайне минималистичные среды или минимальную версию KDE.
3) Возможность играючи править параметры сборки пакетов( configure опции через use flags, опции сборки)
4) Возможность выкинуть initrd(не люблю я его, большую часть собираю в ядро, вырезая все лишнее + 3-5 модулей).
5) Etc-update, позволяющий легко и быстро разруливать обновления конфигов.
6) Возможность использовать любую файловую систему под /.
Для продакшена:
1) Gentoo — meta дистрибутив, можно легко и без правки правил сборки собрать образ без всего лишнего, заточенный под конкретное железо(модули ядра, архитектура процессора) и раскатать по паре десятков машин(В институте (где я учился и сейчас преподаю) в компьютерных классах так и сделано. Машинки не самые новые, но позволяют комфортно работать.
2) Субъективно ebuild'ы намного легче читать и писать, чем аналогичные описания сборки SuSE и Debian + не нужно в них лезть, в большинстве случаев есть нужные use flags.
3) distcc практически из коробки. Пересборка образа на всем парке машин, где он будет использоваться, пока эти машины не польностью загружены почти мгновенная.
4) Удобное управление пакетами, установленными в разные слоты параллельно. Выбор версии(Python, PHP, postgresql), выбор реализации (jre/jdk, opengl...) — eselect

Крайне субъективные плюсы:
1) Понимание, какие пакеты есть в системе и что они делают.
2) Знание что написано в конфигах.
3) Почти полная свобода править всё что угодно.
4) Возможность полностью самому собирать систему, вплоть до сборки системы с busybox и uclibc. + Довольно удобная кросскомпиляция.

Недостатки:
1) Сборка мира с тяжелыми пакетами вроде libreoffice, firefox(chromium) и т.п. все же довольно продолжительна и требует много оперативной памяти.
2) Высокий порог вхождения и время, которое нужно потратить на первую установку.
3) Можно легко убить SSD частыми обновлениями ^_^

В данный момент на декстопе стоит Gentoo, на нетбуке Arch(в порядке эксперимента).
Пробовал ставить Arch на десктоп, но поддерживать git версии пакетов оказалось слишком сложно + грабли с обновлением возникали чаще и лечились в среднем более муторно, как правило с привлечением live-USB.
Кстати, про недостатки:
1) Есть бинаные версии прямо в дереве. Есть бинарные пакеты. В конце концов, есть Sabayon, который сам бинарный, но позволяет без плясок с бубном, как в дебиане, поставить через emerge пакеты с нужными именно тебе юз-флагами (у его пакетного менеджера портаж как бекенд, так что они вполне совместимы).

2) Как по мне — это достоинство с точки зрения коэффициента интеллекта всего Gentoo-сообщества в целом. Не очень умные люди отсеиваются в первые пару месяцев.

3) Знаю людей, которые активно используют SSD (да и сам планирую в ноут когда-нибудь засунуть толпу SSD вместо WD Blue) у которых «брат жив».
Насчет SSD зря волнуетесь — у самого Gentoo на SSD и раз в неделю обновляю мир. За месяц, вместе с повседневным использованием, записано 300ГБ данных. Такими темпами 500гб диска на 3000 перезаписей хватит на 416 лет. Проще убить его чрезмерной работой со swap'ом или ещё чем-то, чем сборкой пакетов.

Пользуюсь гентой, как основной ОС с 2007 года, запостил им около 70 багов, связанных с зависимостями между пакетами, большинство из них сейчас исправлены.
По поводу версии Python: для разработчиков очень удобна возможность поставить какой‐то пакет сразу для всех версий Python, присутствующих в системе. Просто укажите в /etc/portage/make.conf нужные вам PYTHON_TARGETS (и USE_PYTHON для старых пакетов). Это удобно, если вы занимаетесь тестированием своих проектов на Python в разных окружениях.

Это относится не к eselect, а к пакетам, использующим python[-r1].eclass.
Кстати, есть ещё один очень яркий и полезный пример Gentoo-системы: SystemRescueCD.
Ну и, на самом деле, есть ещё DrWeb'овские рескью-образы, там тоже гента (по крайней мере, раньше была)
есть ещё DrWeb'овские рескью-образы, там тоже гента (по крайней мере, раньше была)


Она там все еще. В течение последнего месяца спасал один ноут с помощью него.
А я люблю Gentoo за то, что пакеты можно ставить прям из git,svn,hg… К примеру всё что относится к radeon драйверам у меня из git (mesa, xf86-video-ait, llvm...).
Так же пакеты реально быстро обновляются… и в этом нету никаких проблем, в других дистрибутивах конечно можно и самим собирать но это геомор… особенно если требует ещё 10 библиотек из зависимостей подтянут.
Потом в Gentoo всё последовательно! В ubuntu к примеру если что то не предусмотрели или что то сломалось, вас попросят открыть консоль и там будет ад (так как конфиги и остальное там не для ручной правки)! В Gentoo всё будет последовательно и очевидно. MacOSX то же этим славится, шаг в сторону и сразу либо плати бабки или лазай в терминале с ужасными командами.

Некоторые ебилды можно не ждать :) вышел новый wine если это минорная версия, то просто скопировали ебилд и поменяли в названии версию, потом сделали digest и можно ставить. Ну и писать ebuild одно удовольствие, в отличии от deb и тем более rpm.
Опять прорекламирую openSUSE. Есть openSUSE Build Service, который позволяет брать исходники из git'а, собирать как захочется, и построить пакет в репозитории с учётом всех зависимостей. Аналогично, часто можно просто скопировать существующий пакет, заменить исходники, поменять версию в .spec файле, и готов rpm пакет. Или даже .deb.
Его надо настраивать отдельно, а в генте это из коробки.
Такое есть и не в SUSE, вопрос в степени интеграции.
Конечно, собрать пакет можно в любой системе. Особенность OBS в том, что создаётся общедоступный репозиторий, сборка происходит не на локальной машине, ну и управление всем этим как системой контроля версий.
1) В генте самый гибкий и удобный пакетный менеджер из всех мейнстримных дистрибутивов (лучше только Nix, но он пока не мейнстрим).
Юзер-френдли управление опциями сборки всех программ это действительно киллер-фича.
Многие реальные задачи требуют поддержки опций, которые отключены в бинарных пакетах бинарных дистров, и приходится самому пересобирать пакеты с включенными опциями и поддерживать их.
А в генте переключение опций сборки это штатная фича, и очень удобная.
2) Простота создания ебилдов привела к тому, что практически весь существующий софт уже запакетирован.
3) Дерево портежей одно на весь дистрибутив, не нужно подключать левые репозитории и управлять ими.

Но.
1) Нет бинарных обновлений.
2) Нет релизов и поддержки обратной совместимости внутри релиза в течении нескольких лет.
3) Коммерческий и промышленный софт ориентируется на бинарные дистрибутивы (в частности, виртуализация).

Поэтому Centos.
Пока другие люди работают и решают реальные задачи — гентушники трахаются со своей системой.
Этот дистр — для энтузиастов в плохом смысле слова. Может быть, его создатели не этого хотели, но так сложилось.
Дорогие гентушники, поставьте на пробу на свои изученные/истестированные/измученные машины какую-нить слаку или archlinux и вы увидите, как может летать компьютер. Но, это вам недоступно в вашей любимой системе, собранной со всеми этими -O3 и -mcpu :)
Знаете, я пользуюсь арчем (и centos на продакшене) и переодически слышу такие же нападки.

Как-то, ради эксперимента, поставил на работу на новую рабочую станцию fedora. Времени на её поддержание и восстановление после регулярных падений тратилось существенно больше, чем на заглядывание в rss ленту арча (чтобы увидеть изменения, которые требуют ручного вмешательства) и обновление конфигов.

Снёс через месяц. Конечно, начальная установка и настройка арча или генту занимает больше времени. У меня это 1-2 рабочих дня, чтобы получить то, на чем дальше приятно работать. Но в результате получается удобная, стабильная система с возможностью использования edge-пакетов. Мне очень импонируют pkgbuild'ы и ebuild'ы: просто пишутся, удобно собираются, легко модифицируются. В отличии от, например, rpm с необходимостью создания rpmbuild-окружения, местами неочевидными spec'ами.

Плюс archwiki и gentoowiki являются очень полезными ресурсами. В том числе, при использовании fedora, centos, debian, ubuntu.
Мне ещё нравилься тот факт, что сборка стороннего софта из исходников с целью «просто попробовать» не доставляет столько попоболи. Хочется собрать свежайший емакс? Скачивай и собирай. С вероятностью 0.99 все нужные заголовочные файлы уже установлены и сборка пройдёт гладко.
В убунте придётся запускать ./configure до посинения, выясняя, какие ещё -dev версии библиотек нужно установить.

Из всех линуксов, которые я использовал (mandriva, ubuntu, arch, centos, suse, fedora, etc.) самые приятные ощущения у меня от Gentoo, которой пользовался около года. Всё логично и последовательно. Очень многому можно научиться, изучая систему. Всё логично и удобно. Например, eselect нравился гораздо больше, чем update-alternatives.
Случайно убил систему пересборкой мира, а переустанавливать всё было лень :(
До сих посещают мысли вернуться.
Грамотное сообщество и толковые доки для гиков — вот, в чём хорошая черта Gentoo!
Причём это достижение доступно пользователям всех дистрибутивов, а не только тематического.
Доки в Ubuntu/Debian это как правило руководства для конечных пользователей; из разряда «что нажать на клавиатуре в Libre Office, чтобы шрифт стал курсивным». А вот как только вылезает где-нибудь более серьёзная проблема — и всё. «Гуру» дебиана и убунты на форумах лаконично предложат отправить багрепорт разработчикам. А найдя правильный ответ в гугле и пройдя по ссылке, в подавляющем большинстве обнаружится, что нужная информация оказалась найденной в сообществе Gentoo.
Последние коды гугление по поводу какого-нить проблемного железа почти всегда в итоге приводит в wiki archlinux.
Для меня, например, эти две вики (арч и генту) являлись хорошим подспорьем не только для арча (который у меня на рабочих станциях), но и для ubuntu, mint, fedora, т. к. ресурсы последних оставляют желать лучшего, как только проблема оказывается чуток нетривиальной.
Gentoo хороша, но после очередной пересборки мира начинаешь ценить время. Пользовался ей несколько лет, но всё таки поменял на бинарный дистрибутив. Мой товарищ, который и заразил меня Gentoo, пересидев меня на несколько лет, тоже сменил дистрибутив.
А можно было просто научиться пользоваться ею так, как не каждый пользователь бинарных дистров сможет. Да и опять же, судя по тому, что у Вам пересборки мира доставляли дискомфорт, Вы не умели «их готовить». Есть BINHOST\PKGDIR\ccache, которые очень облегчают и упрощают этот процесс. Да и за три с лишним года полноценного использование генты, мне полностью мир приходилось пересобирать раза два вероятно. Остальные разы я это делал по собственному желанию в удобное мне время и без ущерба для полезной работы (например ночью после обновления gcc-4.6->gcc-4.7).
Я раньше заморачивался, два раза пересобирал тулчейн, потом мир. Сейчас ну его.

P.S. Всё же не всё так просто с обновлениями, как вы тут некоторые пытаются сказать. Сборка с -abkvuDN --keep-going собрала 400 пакетов из 545 и обрушилась (не знаю, почему). Перезапуск — ещё 42 пакета, 3 не собрались. В цепочке был glu, поставился вроде бы успешно, в процессе установки была коллизия файлов (хз откуда взялась, систему никто не загаживал). Ну, none of packages claim..., оно смержилось. А в итоге libreoffice, kipi-plugins и ещё что-то не собралось (даже не сконфигурировалось) — не понравилось libGLU. Смотрю — а либы-то действительно нет, один битый симлинк торчит. Смотрю в бинарный пакет который собрался за четыре часа до этого — там либы есть. Разворачиваю этот пакет емержем — либы на месте. Куда они делись при сборке цепочки? Хрен их знает. Сейчас этот самый либреофис собирается, посмотрим.

Не так всё тривиально там с обновлениями. Хотя конечно предыдущий оратор странно о времени рассуждает. Пересборка мира времени уж точно не отнимает — висит себе в фоне с найсом 19 и ладно.
Сборка с -abkvuDN --keep-going собрала 400 пакетов из 545 и обрушилась (не знаю, почему).


Ну вот тут и проблема. Как это не знаете почему? Логи на что?

Перезапуск — ещё 42 пакета, 3 не собрались.


Зачем перезапуск? Есть же emerge -r. Почему не собрались 3 пакета?

В цепочке был glu, поставился вроде бы успешно, в процессе установки была коллизия файлов (хз откуда взялась, систему никто не загаживал). Ну, none of packages claim..., оно смержилось. А в итоге libreoffice, kipi-plugins и ещё что-то не собралось (даже не сконфигурировалось) — не понравилось libGLU. Смотрю — а либы-то действительно нет, один битый симлинк торчит. Смотрю в бинарный пакет который собрался за четыре часа до этого — там либы есть. Разворачиваю этот пакет емержем — либы на месте. Куда они делись при сборке цепочки? Хрен их знает.


Вы какую-то полную жесть описали. И на этой системе Вы работать собираетесь? Очень похоже на проблемы с хардом\ФС. У меня недавно было нечто подобное после серии стресс-тестов файловой системы. Вылечилось полным разворачиванием системы из PKGDIR.
Никаких проблем с хардом и ФС, я гарантирую это. Это просто штатное обновление системы, которая пол-года не обновлялась, а когда ставилась — use-флаги подбирались тщательно и аккуратно.

Не надо искать проблемы там, где их нет. Старина Оккам решает. Причина проблем тут в том, что джента — rolling, она рассчитана на непрерывное обновление, а не раз в пол-года. А я не хочу обновляться постоянно.

Ну вот тут и проблема. Как это не знаете почему? Логи на что?

В логах — пусто. Не, ну то есть видно, как он пытался собрать openoffice и не смог, стал собирать дальше, и в какой-то момент всё остановилось. С точки зрения емержа, корректно остановилось — он как обычно в конце выдал интересные сообщения от пакетов, возникшие при сборке, а также свои мысли по поводу обновленных конфигов и новостей.

Зачем перезапуск? Есть же emerge -r. Почему не собрались 3 пакета?

emerge --resume = перезапуск, ваш К. О. Хотя, вообще не вижу разницы, можно было и снова emerge -… world, результат был бы абсолютно такой же.

Три пакета не собрались из-за libGLU — из-за того, что libGLU.so был в виде битого симлинка, а место, куда он вёл, сама либа, отсутствовала. Сам glu собрался за несколько часов до этого и собрался нормально, вот смержился криво. Скорее всего глюканула проверка на коллизии. Опять же, это не тот случай, когда мне хочется выяснять, что это было.
Ну во-первых --keep-going не сразу появился, а во-вторых обновления ядра — надо отвечать на вопросы конфигуратора, в которых надо разбираться, а для этого нужно время. И я не про новые драйвера для новых устройств. А оставлять всё «по умолчанию» — ну это уже не gentoo-way, не так-ли?
Ядро однажды сконфигурировано, изменений не так много и вопросов после oldconfig тоже немного.
Sign up to leave a comment.

Articles

Change theme settings