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

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

Так, давайте посчитаем. Допустим, один человек раздаёт некий файл размером 1 гигабайт через BitTorrent. 10 человек его скачали. Может ли у всех десяти быть рейтинг 1 или больше? 10 человек скачало в сумме 10 гигабайт, но раздавали эти 10 гигабайт 11 человек! в результате средний рейтинг среди скачавших файл будет меньше 9/10, поскольку минимум 1 гигабайт раздал релизер. Единственное условие, при котором у всех десяти будет положительный рейтинг — если на раздачу придут новые люди. Совсем как в АО «МММ», где новые «не халявщики, а партнёры» позволяли получить доход старым.

Вы можете сказать «Ха! Пусть эти 10 человек тоже что-нибудь выложат!». Ну. во-первых, это наивное предложение. Один и тот же контент может быть выложен всего один раз, а пользователей у трекеров тысячи и даже миллионы. Во-вторых, рейтинг изначально придумывался вовсе не для того, чтобы шантажировать пользователей.

Но самое смешное — ни torrents.ru, ни free-torrents.org, ни nnm-club.ru не требуют обязательно поддерживать рейтинг выше единицы (хотя и настоятельно рекомендуют). А это — именно те трекеры, которые держатся на том контенте, который выкладывают сами пользователи. С другой стороны, некоторые частные трекеры, принадлежащие релиз-группам, переводящим сериалы, требуют обязательного высокого рейтинга — что просто невозможно, поскольку весь контент на них выкладывается самими владельцами трекера!

Конечно же, понятно, зачем они это делают. Как и в любой бесплатной ММО, в мире BitTorrent есть микротранзакции. На большинстве трекеров можно покупать рейтинг за смски или WebMoney, на чём они с разной степенью наглости и пытаются заработать.

Напомню ещё раз, что весь смысл рейтинга — это всего лишь мотивировать сидеров не уходить с раздачи. Но если вы досиделись до того, что ваш рейтинг превысил 1, то вы наоборот, наносите своими действиями вред — потому как новым людям, скачавшим контент, становится тяжело набрать такой же рейтинг, когда сидеров становится в несколько раз больше, чем личеров. Надо ли объяснять, что чем более драконовские правила у трекера, тем чаще бывает ситуация, когда на сотню раздающих приходится один качающий? И чем это лучше, чем если бы количество раздающих было всего в 10 раз больше? В 5 раз больше? Да ничем! Качающие всё равно наверняка качают на пределе своей скорости.

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

Ну, во-первых, никто не отменял старую добрую покупку рейтинга. Впрочем, некоторые трекеры демонстративно от такой практики отказываются. А почему, кстати? Помогающие рублём для существования трекера не менее полезны, чем сидеры.

Многие трекеры дают бонус к количеству отданного, если вы — единственный сидер на раздаче. Но совсем немногие дают бонус в том случае, если на двух сидеров приходится сотня качающих. А потому — правила раздачи бонусного аплоада должны быть расширены так, чтобы всегда поощрять сидеров, когда их меньше, чем личеров. Т.е. если количество отданного трафика умножаем на отношение количества личеров к количеству сидеров, но не более, чем на 2 (и не менее, чем на 1), к примеру.

Идея варьировать бонус, кстати, уже реализована на nnm-club.ru — там бонус равен 100%, 25%, 11%, 6% и 4% для одного, двух и т.д. до 5 сидеров. Коэффициенты очень похоже, что взяты с потолка :)

Это помогает нам с ситуацией «мало сидеров». Но мы также выяснили, что есть и противополжная ситуация — «мало личеров». Здесь делаем с точностью до наоборот — если сидеров становится гораздо больше личеров, то мы не засчитываем личерам скачанное. С учётом того, что у многих скорость отдачи гораздо ниже скорости скачивания, то коэффициенты тут должны быть другие: скажем, до тех пор, пока сидеров не становится в два раза больше, чем личеров, считаем весь трафик, а полностью перестаём его учитывать только тогда, когда сидеров становится в 4 раза больше.

К слову, идея «бесплатных» раздач, на которых учитывается только отдача, тоже реализована на многих трекерах. Вот только «бесплатными» почему-то становятся раздачи, выбранные по принципу «от фонаря». А всего-то навсего, стоит делать бесплатными те раздачи, где очень много сидеров. У них ведь сидеров всё равно много! (duh)

Таким образом, мы ещё больше мотивировали сидеров оставаться на тех раздачах, где очень много качающих, а личеров не стали слишком наказывать за скачивание контента, на котором трудно поднять рейтинг. И все счастливы, кроме группы в полосатых купальниках пользователей ADSL, которые всегда ругаются на p2p. Но так уж получается, что их участие отражается негативно на любой p2p-сети, и рейтинг тут совсем не при чём.

В прочем, остаётся ещё проблема с тем, как именно ведётся учёт рейтинга трекерами, но это уже совсем другая история :)

Итак, что такое EAPI? EAPI — это стандарт пакетного менеджера Gentoo, или же с другой стороны — стандарт написания ebuild’ов. В то время, как существовал всего один пакетный менеджер, необходимости в таком стандарте не было. Но когда одновременное существование Portage, Paludis, pkgcore, да ещё и Entropy игнорировать стало невозможно, да к тому же развитие некоторых из них обогнало Portage, то текущий статус-кво на тот момент был зафиксирован в виде стандарта, который назвали EAPI 0, и начали работать над его новыми версиями

EAPI 1 имеет немного отличий от EAPI 0. На пример, именно после реализации поддержки EAPI 1 стало возможным писать emerge kde-meta:3 или emerge kde-meta:4.

Весной появился новый EAPI, поддержка которого была реализована только в Paludis. Собственно, в этом EAPI были зафиксированы некоторые дополнительные возможности, которые уже были реализованные в Paludis, и которые хотели использовать разработчики оверлея genkdesvn. В упомянутом оверлее этот EAPI, получивший название kdebuild-1, и используется (с EAPI 2 он несовместим).

С появлением проекта Exherbo появился и новый EAPI под названием exheres-0. Это — рабочая версия EAPI Exherbo. Когда разработчики Exherbo примут решение, что этот EAPI их устраивает, то он будет зафиксирован в виде exheres-1, а exheres-0 так и останется постоянно изменяемым EAPI. Следующие «стабильные» EAPI будут называться exheres-2, exheres-3 и т.д. Фиксирование exheres-1 планируется сделать перед самым выходом первой публичной версии дистрибутива. Единственным пакетным менеджером, который используется в Exherbo является Paludis. Подробнее об exheres можно почитать здесь

Наконец, наш сегодняшний герой дня EAPI 2 был официально принят на заседании Gentoo Council 25 сентября, о чём объявлено в недавнем GMN, и некоторые оверлеи уже начали переходить на его использование. Paludis в полной мере поддерживает EAPI 2 с версии 0.30.1, а Portage — с версии 2.2_rc11. Поскольку ветка Portage 2.2 всё ещё является нестабильной, официальное дерево портежей по-прежнему является царством EAPI 1.

Итак, что же интересного подготовил нам EAPI 2? Собственно, изменения я пересказываю по серии записей в блоге разработчика Paludis’а, отсюда и внимание к взаимному влиянию EAPI друг на друга.

Пожалуй, самой долго ожидаемой фичей являются USE-зависимости. Очень долго ожидаемой.

До сегодняшнего дня если для компиляции одного пакета требовалось, чтобы другой пакет был установлен с определённым набором флагов, то это условие проверялось только перед самой компиляцией. То есть узнать о необходимости переустановить некоторый пакет вы могли не сразу после просчёта зависимостей, а через только часик-другой, когда Portage вылетит с ошибкой на 38-м пакете из 163. А если на 32-м пакете вы ушли спать, то утро будет омрачено. При чём вы не застрахованы от того, что подобная ошибка повторится ещё и на 65-м, 74-м, 109-м и 133-м пакетах. Неудивительно, что команда genkdesvn первой плюнула и отказалась от пакетного менеджера без USE-зависимостей перед тем, как сделать доступными разделённые ебилды для KDE 4: пакетов там много, и USE-зависимости играют важную роль.

USE-зависимости были включены и в kdebuild-1, и в exheres-0, но синтаксис их указания в EAPI 2 отличается:

[opt]

Флаг должен быть включён

[opt=]

Если флаг включён у устанавливаемого пакета, то он же должен быть включён у пакета, установленого по зависимости, выключен в противном случае

[!opt=]

Если флаг включён у устанавливаемого пакета, то он должен быть выключен у пакета, установленого по зависимости, включен в противном случае

[opt?]

Если флаг включён у устанавливаемого пакета, то он же должен быть включён у пакета, установленого по зависимости

[!opt?]

Если флаг включён у устанавливаемого пакета, то он должен быть выключён у пакета, установленого по зависимости

[-opt]

Флаг должен быть выключен

Примеры указания USE-зависимостей:

foo/bar[!baz]
foo/bar[baz,monkey?]
foo/bar:1[baz]
>=foo/bar-2.1:2[baz]

Важно: пакетный менеджер не должен предлагать «автомагически» переустанавливать пакет foo/bar с нужным набором USE-флагов. Вы сами должны решить, хотите ли вы изменить конфигурацию этого пакета в make.conf или /etc/portage/package.use (или use.conf в случае Paludis’а).

Следующим пунктом нашей программы являются так называемые SRC_URI Arrows. По сути это возможность обойти некорректные названия тарболлов с исходниками. Если upstream-автор некоторого пакета не включает в название файла с тарболлом уникальное название пакета и номер версии, то при загрузке архива из сети может возникнуть конфликт из-за того, что distfiles является «плоским» каталогом, и название загружаемого файла может совпадать с названием какого-либо файла, уже присутствующего в этом каталоге. Чтобы это обойти, вы можете указать в ебилде, как необходимо переименовать загружаемый файл. Примерно так:

SRC_URI="http://example.com/dir/1.23/stupid.tar.bz2 -> stupid-1.23.tar.bz2"

Или даже так:

SRC_URI="http://example.com/dir/${PV}/${PN}.tar.bz2 -> ${P}.tar.bz2"

Интересный момент: на сайте разработчика архив будет лежать под именем stupid.tar.bz2, а на distfiles.gentoo.org — под именем stupid-1.23.tar.bz2, и у Portage даже не слетит крыша по этому поводу :) Между делом решается и проблема загрузки архивов из gitweb, который имеет привычку дописывать ;sf=tbz2 или ;sf=tgz в конце ссылок. Эта возможность с самого начала входила и в kdebuild-1, и в exheres-0.

Ещё одним нововведением являются !!-блокировки. Их появление связано с тем, что в последнее время в Portage пытаются реализовать некоторое автоматическое разрешение блокировок, когда блокирующий пакет удаляется из системы после этапа компиляции. В некоторых случаях это ведёт к неприятным последствиям, поэтому и ввели дополнительный синтаксис для «да, я действительно это имею в виду»-блокировки.

Таким образом: - при !-блокировке Portage может попытаться автоматически удалить блокирующий пакет; - при !!-блокировке Portage отправит вас самостоятельно разбираться с конфликтующими сторонами, то есть пакетами.

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

Следующий ряд изменений немного упрощает написание ебилдов: фаза src_unpack разделяется на src_unpack и src_prepare, а фаза src_compile — на src_configure и src_compile. Это даёт возможность более гибко управлять процессом сборки, и при этом более полно использовать дефолтные реализации фаз (до этого во многих случаях автору ебилда приходилось копи-пастить половину дефолтной реализации, чтобы внести необходимые изменения).

Фаза src_prepare вызывается после src_unpack, и её следует использовать для применения патчей. Таким образом, больше нет необходимости копи-пастить дефолтное определение src_unpack ради необходимости наложить определённые патчи.

Фаза src_configure вызывается перед src_compile. Кроме того, в EAPI 2 изменена дефолтная реализация src_compile.

И к слову о копи-пасте — были также добавлены функции default_<название фазы> для каждой фазы, а кроме того теперь можно в любой фазе вызвать функцию default.

Этот блок изменений пришёл в EAPI 2 прямиком из exheres-0 (за исключением некоторых деталей реализации). Для kdebuild-1 подобные нововведения рассматривались, но не были добавлены, поскольку их эффективному использованию мешала необходимость адаптировать eclass’ы, а оверлей должен был использовать eclass’ы из официального дерева.

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

doman foo.1 foo.en.1 foo.en_GB.1 foo.es.1 foo.fr.1

…и соответствующие установленным в системе локалям man-страницы будут установлены «автомагически».

Данное изменение первыми реализовали разработчики Gentoo (см. соответствующий запрос в Багзилле), а разработчики Exherbo не преминули его позаимствовать.

Добавка: ещё одно нововведение в Portage 2.2 — наборы. См. мой обзор здесь

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

Самое смешное — это как потребление Хромом памяти сравнивают с Огнелисом. «Я открываю N вкладок в Огнелисе, и он занимает 100 мегабайт памяти. Я открываю такие же вкладки в Хроме, и он занимает 110 мегабайт памяти. Хм! Google нас обманывает!». Представьте себе, модель «каждой вкладке по процессу» действительно увеличивает накладные расходы. Но идея была не в том, чтобы использовать меньше памяти, а в том, что уменьшить её фрагментирование. Поработайте с Файрфоксом и, не перезапуская его несколько суток, и после этого сравните его потребление памяти с Хромом ещё раз!

И да, у меня не самый быстрый компьютер, и различия в скорости ренденрига JavaScript-движка я вижу сразу. И я замечаю, что вообще-то Опера работает быстрее, но на Google Reader комфортнее пользоваться Огнелисом. Хотя есть AJAX-сайты, где Опера как раз шустрее. Но Google Chrome явно быстрее обоих. Хотя есть ещё один забавный факт: на Linux у меня браузеры работают чуть-чуть медленнее, хоть и вполне терпимо. Особенно отличается линуксовая Опера, когда ей приходится иметь дело с флешем и Java.

Разделение процессов отдельных вкладок действительно помогает. У кого-то, говорят, Хром всё время сыпался весь. Не знаю, у меня один раз подвисла одна вкладка. И я, естественно, прибил её из диспетчера задач Хрома. Я также имел удовольствие наблюдать. как в Огнелисе запускается тяжёленький Java-апплет. Огнелис, ясное дело, посылал меня на это время перекурить. В Хроме я спокойно браузил в других вкладках, ничего не замечая.

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

Тут недавно Сергей Петренко нашёл на лайфхакере статью о том, как добавить лучшие фичи Хрома в Файрфокс. На самом деле, конечно, переделать архитектуру Файрфокса с помощью расширений никак не получится (а в этом — одна из главных особенностей Хрома), а новый JavaScript-движок, конечно, появится в 3.1, но когда это будет — ещё неизвестно (альфа-версии не предлагать). Так что то, что выдаётся в этой статье за «лучшие фичи» вызывает смех.

Режим инкогнито? Если вам так интересно — да, я смотрю порно. Всё, режим инкогнито для меня потерял смысл, вы уже всё знаете. Отображение загрузок на статусбаре? Give me a break, мне по большому счёту пофигу, как там браузер отображает загрузки. Быстрый набор? Ну ребята, это было в Опере сто лет назад, а отсутвие необходимости выбирать эти девять сайтов вручную как раз и оказалось на удивление удобной модификацией (кстати, возможность перетаскивать табы между окнами браузера тоже есть в Опере, но этого многие не знают).

Подсвечивание домена в адресной строке. Мда. Есть чуть ли не десяток причин, по которым адресная строка Хрома — это одна из лучших его инноваций. А они там говорят о подсвечивании домена. Из той же серии — что автоматическое запоминание поисковиков не является таким уж большим нововведением. Ну нет, это действительно удобное нововведение, что мне не нужно для всех своих поисковиков делать лишние клики (хотя возможности Оперы создавать поисковик из любого текстового поля, конечно, не хватает), и совершенно не обязательно прописывать шорткаты.

Так что единственный пункт, который в этом списке к месту — это упоминание Prism.

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

Подготовка

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

После этого вы также наверняка захотите добавить строчку PORTAGE_ECLASS_WARNING_ENABLE="0" в make.conf, иначе Portage будет постоянно ругаться о переопределённом eclass’е.

Также советую установить в переменной ESCM_LOGDIR путь к каталогу, в котором будут сохраняться короткие лог-файлы, из которых вы потом сможете узнать, какая ревизия какого пакета у вас установлена. Логично будет, если это будет один из подкаталогов в /var/log/portage.

Следующий шаг: размаскирование пакетов и установка USE-флагов. Я всегда рекомендую а) не искользовать ~arch в make.conf и б) использовать каталоги в /etc/portage.

Чтобы разкейвордить нужные пакеты, достаточно выполнить команду

cp /usr/portage/local/layman/kde/Documentation/package.keywords.example.live /etc/portage/package.keywords/kde-svn

(ещё раз обращаю внимание: я предполагаю, что ваш /etc/portage/package.keywords — это каталог)

В прочем, это утверждение несколько оптимистично, пару-тройку пакетов вам в этот список ещё придётся добавить. Лично я добавил следующие строчки:

kde-base/qimageblitz **
media-sound/moodbar
=app-crypt/qca-1.0-r3

Также вам придётся размаскировать qca:2. Скопируйте эти строчки в файл /etc/portage/package.unmask/kde-svn:

app-crypt/qca:2
app-crypt/qca-cyrus:2
app-crypt/qca-gnupg:2
app-crypt/qca-logger:2
app-crypt/qca-ossl:2
app-crypt/qca-pkcs11:2

(любопытствующие могут почитать обсуждение Gentoo Bug 129536 «app-crypt/qca slotting and bumping»)

Далее необходимо установить правильные USE-флаги согласно указаниям в файле /usr/portage/local/layman/kde/DONOTREADME (список начинается после строчки KDE 4 SVN ebuilds use flags).

На самом деле флаг debug не является обязательным, но если вы собираетесь репортить баги на KDE Bugzilla, то лучше его всё-таки включить. Кстати, этот список не полон, у меня установка несколько раз прерывалась с сообщениями вроде:

This package requires ‘x11-libs/qt:4′ to be built with the following USE flags: ‘accessibility* dbus gif jpeg opengl png qt3support ssl zlib’

This package requires ‘net-dns/avahi’ to be built with the following USE flags: ‘mdnsresponder-compat

This package requires ‘media-libs/xine-lib’ to be built with the following USE flags: ‘xcb’

Так что обновляйте make.conf и/или package.keywords соответственно.

Ещё один совет: используйте опцию --buildpkg. Изменения в SVN вносятся постоянно, и не все могут вам понравиться, так что иногда вы захотите иметь возможность откатиться на более старую версию, а с бинарными пакетами это сделать проще и быстрее всего. Естественно, это значит, что при каждой установке нужно сохранять пакеты в отдельном каталоге (для этого достаточно переопределить переменную PKGDIR). Можно использовать вот этот скрипт (назовём его emerge-live):

#/bin/bash
DATE=`date +"%m%d"`
export PKGDIR="/root/packages/$DATE"
mkdir -p $PKGDIR
emerge --buildpkg $*

Сохраните его где-нибудь в $PATH.

Теперь можно и запустить emerge-live kde, и надеяться на успех. У меня первая попытка довольно быстро кончилась неудачей, ибо в тот день кто-то из разработчиков напортачил с конфигурационными файлами CMake, и ни у кого, кто обновился в этот день, kdelibs не компилировались. Такова уж природа SVN-пакетов. На следующий день ошибка была исправлена, и я всё-таки начал ставить нужные пакеты (на самом деле эту проблему можно обойти, устанавливая не самую последнюю последнюю ревизию SVN-пакета, как объяснено ниже)

Использование

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

Конфигурация KDE и всех входящих в него программ хранится в каталоге ~/.kde. Точнее, ~/.kde — это симлинк на ~/.kde3.5, ~/.kde4 или ~/.kdesvn, который создаётся при запуске оболочки. Возможно, вы захотите скопировать каталог ~/.kde3.5 в каталог ~/.kdesvn — официально это не рекомендуется, но я ещё не слышал, чтобы у кого-то что-то сломалось из-за этого. В любом случае: никогда не пытайтесь одновременно запустить оболочки KDE 3.5 и KDE4, и никогда не допускайте того, чтобы KDE4-программы пытались изменить настройки в ~/.kde3.5.

В остальном всё как обычно, после установки вы сможете запускать сессию KDE 3.5 или KDESVN. Для запуска KDE4-программ из KDE 3.5 вы можете воспользоваться этим советом

Обновление

Изменения в SVN вносятся постоянно, однако, с точки зрения пакетного менеджера версия пакета остаётся прежней. Поэтому обновлением SVN-пакетов необходимо управлять отдельно. Я использую для этого скрипт updatesvn. По ссылке вы найдёте два файла: updatesvn необходимо положить куда-нибудь в $PATH, а updatesvn.conf в /etc/updatesvn/. Откройте updatesvn.conf и в переменной EMCMD пропишите emerge-live. Теперь чтобы обновить все «живые» пакеты, в которых произошли изменения со времени последней установки, запустите updatesvn all (на самом деле поддерживаются также пакеты, обновляемые по git, cvs и т. д.).

В updatesvn.conf можно также определить наборы приложений: на пример, в переменную KDE занести список всех KDE-пакетов, тогда updatesvn KDE обновит не все пакеты, а только указанный набор. Я для себя определил этот список вот так:

KDE="kdelibs kdepimlibs kdegames kdegraphics \
    kdebase kdeartwork kdepim kdetoys kdenetwork kdeedu kdeadmin  \
    kdeutils kdemultimedia amarok"

Обратите внимание: если вы удалили какое-либо приложение, то вам также необходимо удалить соответствующий каталог в /usr/portage/distfiles/svn-src (или git-src, cvs-src), иначе updatesvn all будет пытаться установить его опять.

Установка необходимой ревизии

Если вы не хотите устанавливать текущую сборку, но точно знаете, какая ревизия вам нужна, то перед запуском emerge установите в значении переменной окружения ESVN_REVISION нужный номер ревизии. Также вы можете задать любое значение переменной ESVN_OFFLINE, если при перекомпилировании пакета не хотите синхронизироватсья с SVN-репозиторием разработчиков.

Дополнительные оверлеи

Вот в этом оверлее вы найдёте несколько приложений, которые по различным причинам отсутствуют в genkdesvn. А в этом собрано несколько дополнительных интересных виджетов для Plasma.

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

Источник ПО

Помнится, когда-то я натолкнулся на интересную фразу из FAQ по популярному ICQ-клиенту под Windows: При закрытом исходном коде, не появятся лже версии QIP cо зловредным кодом. Действительно, при закрытом исходном коде так трудно заразить QIP вирусом и начать распространять то, что получилось. Зато уж если открыть исходники, то сразу же обязательно набежит толпа желающих распространять непонятно что под названием QIP. Странно только, почему я ни об одном подобном случае с открытым ПО не слышал? Вообще-то ничего странного в этом как раз нет.

Как мы знаем, Windows-софт в большинстве своём приходит на компьютеры пользователей или с дисков, купленных на углу (вы все верите надписи «100% без вирусов?»), или с какого-нибудь фриварного, а то и варезного сайта. То есть — откуда угодно. Конечно, иногда его ставят и с лицензионных дисков (или скачивают с официального сайта программы). Но что для Windows-пользователя удобнее — скачать тот же QIP, Opera, X-Chat и ещё десяток бесплатных (а то и не очень бесплатных) программ в одном месте, или же бегать по десяти сайтам? Поэтому листсофты и софтлисты процветают. А между тем никто не гарантирует, что QIP, скачанный с очередного софтлиста — это тот самый QIP, который распространяется.

Что же мы видим в Linux? В Linux тоже есть и freshmeat, и парочка менее знаменитых аналогов, только практически никто ими уже давно не пользуется. Все современные дистрибутивы имеют развитые менеджеры пакетов (aptitude, yum, emerge) которые сами скачают нужный пакет из соответствующего дистрибутиву репозитория. Создатели дистрибутива гарантируют, что предоставленные ими копии программ не содержат стороннего кода, соответствуют названию и описанию, и что самое главное — действительно будут нормально работать в этом дистрибутиве (не то чтобы совсем не бывает казусов, особенно если вы разрешили своему менеджеру пакетов устанавливать более новое, «нестабильное» ПО).

Патчи

Надо сказать, не всегда распространяемый в вашем дистрибутиве пакет будет тем же самым пакетом, что и распространямый автором. Даже тот самый Linux From Scratch — это не только книга о том, как собрать всё операционную систему из исходников, но и набор патчей, без которого получить систему из разрозненного набора пакетов не получится — одни просто не скомпилируются, другие не смогут друг с другом нормально взаимодействовать. Майнтейнеры (то есть те, кто отвечает за включение пакета в дистрибутив) тестируют различные пакеты на нормальное функционирование, взаимную совместимость, а также частво добавляют собственные усовершенствования или не успевшие войти в официальную сборку патчи.

Главная задача майнтейнера — заботиться о пользователе дистрибутива. И если в «мэйнстримный» пакет не включено исправление какой-либо ошибки или дырки в безопасности, майнтейнер не ждёт, а выкладывает в свой репозиторий соответствующее исправление. То же касается любого возможного усовершенствования. После этого специфичные для дистрибутива патчи переносятся в другие дистрибутивы, добавляются в основной пакет (или не добавляются, если автор так решит) — это неотъемлемая часть жизни OpenSource-программ.

Надо сказать, разные разработчики по-разному относятся к этому процессу. Иногда разработчикам не нравятся, что они теряют контроль над тем, что именно распространяется под их именем. На самом деле создатели дистрибутивов заботятся только об удобстве своих пользователей и порой делают работу за самих разработчиков — но иногда сами разработчики не хотят включения какой-нибудь возможности в свою программу. Бывают совсем странные случаи, вроде разработчика оконного менеджера ion3, который выступал против распространения патча для поддержки сглаживания шрифтов; или разработчиков FireFox, которые были против того, чтобы в российском дистрибутиве AltLinux поисковиком по умолчанию был Яндекс.

Иногда такие конфликты заканчиваются тем, что создателям дистрибутивов это всё надоедает, и они начинают распространять те же самые пакеты под другим именем. Так, тот же FireFox теперь так же известен, как IceWeasel, что только путает пользователей. А всё из-за нескольких патчей, без некоторых из которых FireFox даже не мог быть скомпилирован в debian’овском окружении!

Продукт

Чем хорош Ubuntu? На одном CD собран небольшой, необходимый и достаточный набор приложений. От офисного пакета до средств настройки — всё на расстоянии двух кликов сразу после установки. Минимальный тесно интегрированный набор компонентов. Кроме того, если другие дистрибутивы включают в себя Gnome с настройками по умолчанию, то в Ubuntu его настроили по-своёму для большего удобства пользователей. Уникальный визуальный стиль и продуманная организация рабочего пользовательского интерфейса.

Всё это может сделать любой пользователь Linux в любом дистрибутиве. Но Ubuntu — это уже готовое, протестированное, слаженное решение. Именно это я понимаю под словом «продукт».

От Ubuntu в первую очередь требуется не гибкость и широкие возможности настройки (хотя это в определённой степени тоже есть), а корректная работа тщательно подобранных компонентов. У разработчиков Gentoo задача противоположная — сделать такой конструктор, из которого можно собрать любую комбинацию компонентов с любым, минимальным или максимальным набором фич. Gentoo не навязывает готовых решений, а предлагает пользователю самому потратить кучу времени на поиск подходящей для него комбинации «кубиков».

У обоих подходов есть преимущества и недостатки, и порой неожиданные сторонние эффекты, вроде выхода KDE4 на Kubuntu раньше, чем на Gentoo. (к слову, отношение разработчиков к Kubuntu и Xubuntu далеко не такое, как к Ubuntu). Не откажусь от удовольствия процитировать самого себя:

Со стороны может казаться, что поддерживать source-based дистрибутив легко: не надо заниматься сборкой бинарных пакетов, написал сценарий сборки — ebuild — и готово. На практике это означает, что если создателям бинарных дистрибутивов достаточно протестировать одну бинарную сборку, мэинтейнерам Gentoo нужно убедиться в корректной работе и компиляции пакета в любой комбинации USE-флагов, версий и опций компилятора и опциональных зависимостей. Получается, разработчикам Gentoo приходится тратить больше времени на сборку пакетов, чем разработчикам какой-нибудь Ubuntu — при том, что бинарники они не распространяют!

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

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

Общая идея

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

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

Это напоминает друидов в World of Warcraft. В зависимости от распределения талантов, игроку-друиду доступны различные формы, причем он может переходить из одной формы в другую во время боя. Идея — все играют только друидами, но количество различных форм делаем большим.

По ходу прокачки на каждом уровне игрок может прикупить ещё одного нанобота (или талант), других возможностей развивать персонажа не предусматривается

Идея вторая состоит в том, чтобы взять Вангеров и превратить их в «Vendetta Online в спанже». Vendetta Online — космическая MMORPG, главным отличием которой является ориентированность на PvP. У неё есть множество отличий от наиболее известных игр жанра, которые пригодились бы при превращении Вангеров в (MMO)RPG:

• «twitch-based combat» вместо привычного «point-and-click». Если в WoW или EVE используется вид от третьего лица, а для прицеливания достаточно кликнуть по врагу (как это делается в играх вроде Diablo), то в VO управление осуществляется так же, как в FPS или космических симуляторах. И если в WoW шанс «увернуться» зависит от уровня игроков и используемого ими оружия/брони, то в VO от любого оружия можно увернуться за счет управления своим кораблём (а в нашей гипотетической игре — своим мехосом). Никакого бросания кубиков!
• сбалансированность вооружения. Исход поединка в дуэли в первую очередь зависит не от «уровня» игроков, а от их личных навыков (это конечно, не касается ситуации, когда у одного из игроков «нулевой» уровень)
• игра ориентирована не на долгое развитие персонажа и PvE, а на постоянное PvP. Полностью безопасных зон нет, если только игрок не находится внутри станции (или эскейва). Снаряжение, с которым можно успешно побеждать других игроков в сражениях, становится доступно через несколько часов игры, далее он получает не более сильное вооружение, а скорее более разнообразный арсенал

Что мы получаем? Получаем (MMO)RPG или даже FPS с элементами RPG, в которой я попытался объединить необычную ролевую систему, нанотрансформации, интересный PvP и, конечно же, Психосферную вселенную (хотя последнее уже не по моей части)

Определение ролей

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

Если же игрок предпочитает участвовать в сражениях напрямую, то ему необходимо выбрать тактику ведения боя. Захочет ли он использовать тяжёлый бомбардировщик или легкий истребитель? Предпочтёт ли он самонаводящиеся ракеты или рэилган?

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

1. Состав вооружения: разные мехосы могут иметь одно или несколько видов вооружения на борту — ракеты простые и самонаводящиеся, пулеметы, лазерное вооружение различного вида (скорострельные, как у егеря или же снайперские рэйлганы)
   • обычные ракеты взрываются на небольшом расстоянии от цели, наиболее опасны на средних дистанциях против не очень быстрых целей. Не могут активироваться сразу после выстрела, а потому бесполезны на близкой дистанции
   • самонаводящиеся ракеты взрываются при контакте, в большинстве случаев опытный игрок должен уворачиваться от них, за исключением тех случаев, когда обстрел производится на маленькой дистанции, цель малоподвижна или игрок был пойман врасплох
   • пулеметы наиболее эффективны на малом расстоянии из-за разброса пуль
   • обычные лазеры (как у периметровских егерей) эффективны на близких и средних дистанциях,
   • «снайперский» лазер или рэйлган в противоположность самонаводящимся ракетам требуют хорошей меткости от стреляющего, но и жертве от них увернуться очень сложно
   На самом деле вместо лазеров возможно стоит использовать «плазменное» или «нейтронное» оружие — то есть такое, у которого скорость снарядов гораздо меньше скорости света, что даст возможность чаще уворачиваться от выстрелов.
2. Наземный или воздушный: по всей видимости, на летающих мехосах невозможно установить большое количество тяжелого вооружения, его преимущество в маневренности (зато наземные меньше рискуют врезаться в землю)
3. Количество брони: медленные мехосы компесируют свою уязвимость большим количеством брони
4. Скорость передвижения

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

Мехосы

Итак, я составил список из 9 мехосов — в настоящей игре их, конечно, будет больше, и они будут более разнообразны. Как и в Периметре, используется 3 вида нанороботов, при этом я предпологал, что игрок может приобрести максимум 16 нанороботов. Чтобы удобнее видеть, какие комбинации мехосов доступны при том или другом варианте распределения этих нанороботов, я разбил мехосы на 3 группы

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

Егерь (рецепт 5/0/0) — вооружён лазерами, летает, средняя манёвренность, слабая броня
Вайпер (0/5/0) — вооружен пулемётом, летает, быстрый, слабая броня
Залп-проектор (0/0/5) — вооружён обычными ракетами, наземный, средняя манёвренность, средняя броня

Вторая группа: мехосы с рецептом вида 6+4, более универсальные за счёт комбинирования двух видов вооружения (по отдельности оружие одного вида более слабое, чем оружие такого же вида у мехосов из первой или третьей группы — к примеру, можно условно считать, что у егеря 2 лазерные пушки, а у осы одна лазерная и пулемёт) Оса (4/6/0) — вооружён пулемётом и лазерами, летает несколько медленнее, чем вайпер, слабая броня
Валькирия (0/4/6) — вооружён лазером и ракетами, летает несколько медленнее, чем егерь, средняя броня
Скорпион (6/0/4) — вооружён обычными ракетами и рэйлганом, наземный, средняя манёвренность и броня

Третья группа: мехосы со сложным рецептом (10+4+2), имеющие в определённой ситуации или большое преимущество (за счёт наличия наиболее сильного вооружения определённого вида) или большой недостаток. Игрок, решившийся на использование одного из этих мехосов, довольно сильно ограничивает себя в возможности использовать разные виды вооружения

Гиперболоид Гарина (10/2/4) — вооружён рэйлганом, наземный, средняя скорость, средняя броня
Фиолентовый Дорминатор (4/10/2) — вооружён ракетами, скорость ниже средней, средняя броня
Последний Могиканин (2/4/10) — вооружён самонаводящимися ракетами, наземный, медленный, сильно бронирован

При таком наборе мехосов игрок может распределить наноботы так, чтобы иметь выбор из а) трёх мехосов из первой группы и одного из второй;
б) двух мехосов из первой группы и двух из второй;
в) по одному мехосу из всех групп.

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

Развитие

Набор из 9 боевых мехосов можно дополнить, разнообразив возможные комбинации вооружения. Кроме того можно добавить мехосы со специальными возможностями, не имеющими отношения к бою в дуэли. Можно также добавить мехосов с совсем простым рецептом (1-3 нанобота) для начинающих персонажей и мазо… то есть любителей раффа

Также я не рассмотрел такие важные вопросы, как пенальти от смерти и возможность изменить состав наноботов. Но эти вопросы уже во многом зависят от сценария игры.

Итог

Я постарался сформулировать некоторые идеи, и продемонстрировать в общих чертах, каким образом эти идеи можно реализовать в (массовой онлайновой?) action-rpg во вселенной Психосферы, и какой подход к PvP-балансу хотел бы я видеть при разработке такой игры. Надеюсь, эти идеи покажутся интересными компетентному Жюри, а может быть и дадут толчок к развитию игростроения в Психосферной (а может, и какой-либо другой) вселенной

Официальная предысторя как бы написана представителем нации Itani, в этом же варианте в качестве летописца выступает представитель UIT. Соответственно, акценты расставлены немного по-другому; к тому же освещены многие вопросы, которые слабо упоминались в официальной предыстории, и информацию о которых приходилось собирать по крупицам и вытягивать из разработчиков (ибо официальное изложение недостающей части предыстории, как всегда, work in progress). Ну и главное — этот вариант гораздо веселее! (Творческого порыва продолжить перевод у меня пока что не возникало)

Итак…

Изначально все мы произошли с Земли. Старушка Земля, Терра Фирма, Третья Планета, ну и всё такое прочее. Конечно, потом мы открыли МакДональдсы по всей Солнечной Системе и построили города вокруг этих МакДональдсов; так что у нас были мужчины и женщины с Меркурия, и мужчины и женщины с лун Юпитера, и мужчины и женщины с Марса (что опровергло весь тот бред про мужчин с одной планеты и женщин с другой).

Но… как же всё это было СКУЧНО.

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

Это было не только скучно. Это было ужасно! Несмотря на сберегающие технологии и повторную обработку, в нашей звёздной системе оставалось всё меньше и меньше ресурсов, на пляжах Венеры заканчивался песок, а Пояс Астероидов превращался в пыль. Добавьте к этому ту подлянку, что сделал нам Эйнштейн несколько веков назад, с невозможностью путешествовать быстрее скорости света, а значит и достигать других звёздных систем, и вы поймёте, что люди Земли начали отчаиваться…

Потом, к счастью, учёные сделали открытие.

— А знаете что? — спросили они.

— Чё? — апатично отозвались остальные. Ну, вы понимаете, это же — УЧЁНЫЕ, чудики, для которых весело провести время — это целую ночь играть в D&D, и которые столько всего наобещали про жизнь в космосе и доминирование во Вселенной — и что мы имели? В общем, поэтому мы так на них и отреагировали. Ну а они возьми да и скажи:

— А мы вот гиперпространственный туннель (в оригинале — wormhole) открыли.

— И чё? — спросили мы.

А они:

— Ну, по нему мы можем попасть к далёким звёздам, и посмотреть, что там!

А мы:

— Не может быть!

А они:

— Может-может!

А мы:

— Да не может быть!!!

А они:

— Да ещё как может!!!

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

Учёные оказались правы (кто бы мог подумать?): они таки действительно открыли этот-как-его туннель, и эта штука таки действительно вела к другой звёздной системе. Мы, конечно, были рады и убежать с этой маленькой вонючей системы, и возможности начать борьбу за новые ресурсы с самого начала (никто об этом вслух не говорил, но все, конечно же, только об этом и думали). Так что люди Земли и колоний праздновали и закатывали большие вечеринки (учёных, конечно, ни на одну не пригласили — из-за того, что они такие чудики и всё такое).

Терраформинг Земли-2 (надо отдать должное за оригинальность) был сложной задачей, сложнее чем даже работа на Марсе. Миллионы тонн материалов сливалось в систему Солнца-2 (да-да, снова та самая оригинальность), как и миллионы людей всех мастей: учёные, терраформинг-инженеры, врачи, космические пилоты, геологи, медсёстры, рабочие, метеорологи, ботаники, экологи, дельцы, сутенёры, контрабандисты, политики, и так далее… От высших общества до бомжей — все стекались на новую планету и пытались изменять её по своему разумению. Когда чудики — извините, учёные наконец-то доработали портативный гравитационный двигатель и мы могли переправляться толпами, а не по одному, то дело пошло быстрее, и нашлось больше времени на веселье. Всё шло замечательно, и терраформинг планеты должен был закончиться в течении века. Мы также нашли ещё несколько туннелей, но ни один не вёл на такую же многообещающую систему, как Солнце-2.

Но, конечно, учёные любят изобрести что-нибудь, а потом изобрести что-то другое, что испортит первое открытие, и с туннелями не было никакого исключения. Какой-то чудик начал утверждать, что туннели не вечны (как, на пример, бриллианты), и что на самом деле, туннель Солнце-Солнце-2 должен вот-вот остановиться. Этого кайфолома, конечно же, быстро нашли и заткнули. И, конечно же, всё, что он предсказал, сбылось.

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

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

И таки как же мы встряли! Зондирование, тестирование, и нытьё показало не только то, что туннель действительно закрылся, но также что он не откроется в ближайшие несколько тысячелетий. Тысячелетий! Даже «Симпсоны» перестанут выходить к тому времени. Не говоря уж о том, что мы застряли с этой стороны туннеля без всякой поддержки Старушки Земли, а Земля-2 была всё ещё не не совсем подготовлена. Да уж, мы были в жопе.

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

В своё время я написал две статьи для Linux.com с советами для пользователей Gentoo (Gentoo Portage secrets и Tips for new Gentoo users), при чём вторая оказалась такой удачной, что не только попала в топ digg’а, но и была в тот же день переведена на русский язык!

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

Если вы только собираетесь начать работу с Gentoo

Приготовьтесь читать много документации, особенно поначалу. Собственно, вы и установить Gentoo не сможете, не изучив Gentoo Handbook.

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

Handbook освещает установку и основы работы с Gentoo. Когда придёт время настраивать иксы и ALSA, переходите к Gentoo Documentation Resources. Если вы не нашли информации по интересующей вас теме и там, то она скорее всего есть в Gentoo wiki.

Найти что-либо, что не описано в Gentoo wiki довольно сложно, так что не забывайте туда заглянуть, прежде чем посетить официальный форум и IRC-каналы.

Выше я приводил ссылки на англоязычные источники, как и в оригинале статьи. Если у вас нет проблем с английским языком, то лучше их и придерживаться, когда вы что-либо ищите — англоязычная документация практически всегда более актуальная и более полная. Но и документации на русском есть немало: и Handbook, и официальный перевод прочей документации, русскоязычный раздел Gentoo Wiki. Большой русскоязычный форум о Gentoo вы можете найти на Gentoo.ru (там же вы найдёте ссылки на IRC-каналы), ну и крупнейший русскоязычный форум о Linux — LinuxForum.

Основы Portage

Шутка. Тут этот раздел вообще не нужен. Вы ведь прочли Handbook, как это было сказано в предыдущем разделе? Хотя в оригинальную статью этот раздел по настоятельной просьбе редакторов пришлось всё-таки включить.

Настройка Portage

Первое правило Gentoo — внимательно следите за вашими USE-флагами. Множество глупых вопросов снимается, если вы перепроверите свои USE-флаги. Почему Midnight Commander тянет за собой в зависимостях X.org? Потому что у вас установлен флаг X. Почему вместе с KDE не установился KPDF? Потому что вы забыли про флаг pdf. (Почему же всё-таки был установлен KGhostScript? Понятия не имею, да и вообще — KDE4 на носу)

Для того, чтобы увидеть, с какими флагами будет установлен новый пакет, запускайте emerge с параметрами –ask и –verbose (-av) (–ask лучше –pretend тем, что зависимости не пересчитываются лишний раз). Обязательно установите пакет gentoolkit — среди прочих полезностей, он содержит утилиту euse, которая облегчает управление USE-флагами. Запустите euse -i flag, чтобы увидеть описание флага, и узнать, актвирован ли он. Прочитайте man euse, чтобы узнать о всех возможностях этой команды (нет, правда, прочитайте — там немного).

Чтобы установить какую-либо программу с другими USE-флагами, иногда советуют запустить USE="some flags" emerge moo, но ни в коем случае так не делайте: при следующем обновлении пакет будет перекомпилирован со старым набором флагов. Для настройки USE-флагов для отдельных пакетов используйте /etc/portage/package.use (это или файл, или каталог с файлами, см. ниже). То есть если вы хотите установить пакет moo категории category с флагами some flags, то наберите echo "category/moo some flags" >> /etc/portage/package.use перед установкой.

То же самое относится и к ACCEPT_KEYWORD — используйте /etc/portage/package.keywords. Начиная с версии Portage 2.1, вы можете хранить такие настройки не в одном большом файле package.keywords, а создать несколько небольших файлов, и положить их в каталог /etc/portage/package.keywords. Это относится ко всем файлам в /etc/portage.

Когда нужно использовать оверлеи

Иногда бывает нужно установить пакет (или версию пакета), которого ещё (или уже) нет в Portage. На пример, вы можете найти ebuild, который уже был удалён из официального дерева в CVS-репозитории. Или же вы нашли ebuild для нового пакета в Gentoo Bugzilla. А может быть, вас чем-то не устраивает официальный ebuild, и вы решили внести в него свои изменения.

В таком случае, вы должны создать собственный локальный оверлей, и положить свои ebuild’ы туда. Оверлей — это набор ebuild’ов, которые вы хотите «подмешать» к основной базе Portage. Ни в коем случае не храните свои ebuild’ы в /usr/portage — при первой же синхронизации они будут удалены. Создайте каталог для своего оверлея, и создайте в нём структуру каталогов, подобную /usr/portage. Расположите ваши ebuild’ы соответственно. Затем откройте /etc/make.conf, и добавьте строчку PORTDIR_OVERLAY="/path/to/local/overlay".

Обычное место для оверлеев — /usr/local/overlays, так что свой оверлей вы можете сделать в /usr/local/overlays/local. Что ещё может оказаться в /usr/local/overlays?

Есть множество неофициальных оверлеев, с которыми можно синхронизироваться. Для любого из них можно создать оверлей в /usr/local/overlays, и синхронизировать их (по тому же принципу, как вы синхронизируете официальное дерево Portage, когда запускаете emerge --sync). Разные неофициальные оверлеи используют для синхронизации утилиты rsync, svn или git, что оговаривается в описании оверлея.

В прочем, большинство из этих оверлеев вы можете использовать при помощи утилиты layman. В таком случае вам не нужно самомостоятельно создавать каталог для оверлея и запускать rsync/svn/git для получения обновлений — вы просто вводите layman -a название-оверлея, чтобы «подключиться» к оверлею — то есть, чтобы layman сам создал каталог, скачал туда нужные файлы и добавил путь в файл настройки; а затем запускаете layman -S, чтобы обновить все оверлеи.

Подробнее об управлении оверлеями, об установке layman и о том, какие вообще есть полезные оверлеи, можно узнать на Gentoo wiki. Оверлеи, как правило, обсуждаются в разделе Unsupported software официальных форумов Gentoo.

Как часто нужно обновляться?

Не стоит запускать emerge --sync и layman -S чаще раза в сутки. Да и этого, как правило, более чем достаточно. Вы можете отслеживать появление интересующих вас пакетов на сайтах http://packages.gentoo.org/ или http://gentoo-portage.com/ (или же подписавшись на соответствующие RSS-ленты), и, таким образом, синхронизировать дерево Portage и обновлять пакеты только тогда, когда в официальном дереве появятся новые версии используемого вами ПО.

Чтобы не пропускать важные обновления безопасности, используйте утилиту glsa-check из пакета gentoolkit. В настоящее время эта функциональность ещё дорабатывается, но в будущем glsa-check станет частью Portage. Чтобы узнать, есть ли уязвимости среди установленных пакетов, запустите glsa-check -l affected. Выполнив glsa-check -d <код уязвимости>, вы увидите подробную информацию по определённой уязвимости (вы можете также сразу запустить glsa-check -d affected)

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

Не забывайте читать Gentoo Monthly Newsletter, практически все важные вопросы связанные с нетривиальными обновлениями, там всегда освещаются. Да и вообще подписаться на RSS-ленту новостей с gentoo.org (или хотя бы gentoo.ru) — это очень хорошая идея.

Этот скрипт с простым названием update упрощает процедуру обновления:

• на экран не выводятся сообщения от компилятора — только сообщения от emerge;
• если какой-то пакет не удаётся установить, то выполнение обновления не прерывается: скрипт в конце работы пытается ещё раз установить этот пакет, затем выводит список всех пакетов, которые так и не удалось установить;
• в некоторых случаях автоматически разрешаются блокировки пакетов (пакет А версии ниже X блокируют установку пакета B версии Y: обычно emerge не сможет продолжить работу, пока вы сами не обновите пакет A, а update это делает сам)

Держите «мир» в чистоте

Каждый раз, когда вы устанавливаете какой-либо пакет, его название записывается в /var/lib/portage/world. Когда вы обновляете ваши пакеты, вы запускаете что-то вроде emerge --update --deep world — именно тогда этот список и используется. Старайтесь, чтобы он был как можно короче; только программы, которые вы используете напрямую, должны туда попадать. Если какой-либо пакет установлен как зависимость другого, то он скорее всего не должен попадать в world.

Например, когда вы устанавливаете пакет, использующий библиотеку wxWidgets, то она автоматически устанавливается среди прочих зависимостей этого пакета, но не добавляется в world. Если вы удалите все пакеты, которые зависят от wxWidgets, то она перестанет обновляться при emerge --update (...) world; и будет удалена из системы, если вы запустите emerge --depclean. Только если вы сами разрабатываете программы с использованием wxWidgets, вы захотите, чтобы она входила в world.

Утилита udept может помочь вам удалить лишние пакеты из списка world:

emerge udept
dep -aw

Чтобы установить или обновить пакет напрямую, но без добавления его в этот список, используйте опцию –oneshot (-1). Это может быть полезно, на пример, для временной установки какого-либо пакета.

Об удалении пакетов.

Не забывайте, что emerge --unmerge не проверяет, используется ли удаляемый пакет другими пакетами. Также будьте осторожны с emerge --depclean, так как иногда она может удалить пакеты, которые вам нужны.

Иногда при обновлении одного пакета, перестаёт работать другой, который, хоть и не требует для установки первый пакет, но включает его в свои необязательные зависимости. В таких случаях необходимо просто переустановить второй пакет, чтобы он скомпилировался без связей с первым. Чтобы выявить все такие пакеты, вы можете использовать утилиту revdep-rebuild из пакета gentoolkit.

Логи Portage

Все ваши действия с emerge отражаются в /var/log/emerge.log. К примеру, чтобы узнать, какой пакет сейчас компилируется, запустите tail /var/log/emerge.log. Преобразовать временные отметки в читаемый формат поможет простой python-скрипт (с его использованием необходимо запустить tail /var/log/emerge.log | formatlog).

Утилита genlop (emerge genlop) позволяет извлечь статистическую информацию из этого лог-файла. На пример, genlop -c скажет, какой пакет сейчас компилируется и как долго, и оценит количество оставшегося до конца установки времени.

Дополнительно стоит также включить так называемые elog. При установке многих пакетов показываются важные уведомления, которые вы можете пропустить, если не следите за выполнением emerge. Добавьте в make.conf следующие строки:

# This sets what to log
PORTAGE_ELOG_CLASSES="warn error log"
# And this is how to do it
PORTAGE_ELOG_SYSTEM="save"

и создайте каталог /var/log/portage/elog. Теперь уведомления для каждого пакета будут сохраняться в отдельном файле в созданном каталоге. Если вы хотите узнать больше о настройке elog, то изучите файл /etc/make.conf.example. Существуют также графические утилиты для просмотра этих логов.

Удаление временных файлов

Если установка программы прервана ошибкой, в /var/tmp/portage остаётся временный каталог. Он будет автоматически удалён только после успешной установки этой программы, или же вы можете очистить этот каталог сами.

Также через некоторое время довольно много файлов может оказаться в /usr/portage/distfiles. Используйте утилиту eclean из пакета gentoolkit, чтобы удалить дистрибутивы, которые вам больше не нужны. Эта утилита также удаляет старые бинарные пакеты, если вы их создавали (запускайте как eclean-dist и eclean-pkg соответственно). В странице руководства рассказывается о дополнительных параметрах.

Быстрый поиск пакетов

Чтобы найти нужный пакет в локальном дереве Portage (и/или оверлеях), вы можете использовать emerge --search или emerge --searchdesc, но этот способ очень медленный. Поэтому лучше использовать eix. Eix индексирует список пакетов после каждой синхронизации (для этого необходимо набрать update-eix), а затем очень быстро выполняет поиск по пакетам (к примеру, eix moo выдаст список всех пакетов, которые содержат moo в названии). К тому же, вывод eix более информативен, чем вывод emerge.

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

Уменьшение использования трафика

Обновление системы может быть связано с тратой большого количества сетевого трафика. Но есть способы уменьшить аппетиты Portage. Наиболее эффективно в этом преуспеет знаменитая утилита Deltup, которая позволяет загружать не весь архив с исходными кодами, а только разность между новой и старой версией. Такой подход экономит до 90% размера загрузок. Установка Deltup описана в Gentoo Wiki.

У Deltup, конечно, есть свои недостатки. Эта утилита не поддерживает докачку, а кроме того, вы зависите от загруженности сервера, генерирующего новые патчи (помнится, были плохие времена у deltup, когда дождаться очереди на генерацию было практически невозможно. Потом стало лучше, а после этого я уже давно deltup не пользуюсь — как там сейчас, не знаю). Также иногда Deltup «путается» в версиях некотрых пакетов, если у них запутанная система нумерации версий. Ну и конечно, пересоздание нового пакета требует процессорного времени. Однако же, никаких катастрофических последствий использование deltup иметь не может, так что если вы нуждаетесь в экономии трафика — обязательно её попробуйте.

Похожий подход, но для синхронизации дерева Portage использует утилита emerge-delta-webrsync: она загружает ежедневные патчи для обновления вашей локальной копии дерева, что гораздо экономнее, чем emerge --sync (особенно если у вас уже есть архив с копией дерева портежей — вроде того, который вы исполоьзовали при установке). Просто запустите emerge emerge-delta-webrsync, а затем emerge-delta-webrsync для синхронизации дерева портежей (мне всё ещё надо напоминать, что подробности — в man’е?).

На Gentoo wiki есть специальный раздел с советами для пользователей с плохим интернет-соединением.

Ещё одна возможность не уменьшит использование трафика, но позволит уменьшить время загрузки пакетов: добавьте parallel-fetch в переменную FEATURES в /etc/make.conf, чтобы emerge скачивал дистрибутив следующего пакета, устанавливая предыдущие в очереди. Это уменьшит время установки, если вы запускаете emerge для установки сразу нескольких пакетов.

Ускорение компиляции

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

На пример, Distcc позволяет распределить задачи по компиляции на несколько компьютеров в сети. Даже компьютеры с Windows сгодятся для этого!

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

Упомянутые здесь утилиты можно использовать не только с emerge, но и вообще при любых компиляциях. Подробнее читайте в документации Distcc и Ccache.

Обновление конфигурационных файлов

После установки новых версий пакетов иногда необходимо обновить их конфигурационные файлы. В Handbook описана эта процедура с использованием утилиты etc-update, но существует более удобная и продвинутая утилита — dispatch-conf. Эта утилита имеет возможность автоматически обновлять конфигурационные файлы, в которых произошли простые изменения (на пример, изменились только комментарии), вы также можете указать ей автоматически обновлять конфигурационные файлы, в которые не вносились изменения пользователем. При этом конфигурационное файлы помещаются в контроль системой контроля версий, чтобы вы с лёгкостью могли откатить все изменения.

Ну и цитата из bash.org’а напоследок:

<@insomnia> it only takes three commands to install Gentoo
<@insomnia> cfdisk /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update && . /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.sample /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6
<@insomnia> that’s the first one