Читать онлайн «Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013». Страница 25

Сначала я поинтересовался мнением Марка на счет того, с какого конца следует подходить к пропаганде Open Source – снизу, со стороны ли пользователей-индивидуалов, в том числе домашних, или же сверху, от корпоративных потребителей IT. Иными словами, куда Linux придет раньше и с большим успехом, в дома, или в офисы? Ответ был достаточно дипломатичным – что не следует пренебрегать ни теми, ни другими; но в свете отмеченной ранее, во время ответов на вопросы, ориентации на «квалифицированное меньшинство», у меня сложилось впечатление, что Марк отдает предпочтение решениям корпоративным.

Второй же вопрос касался финансовой стороны открытых проектов: должны ли они стремиться к коммерческой самоокупаемости и прибыльности, или, подобно науке, образованию, искусству, в той или иной форме дотироваться обществом? На что Марк неожиданно ответил вопросом: – А Вы как думаете?

Будучи, некоторым образом, представителем науки, я, разумеется, ответил, что финансирование разработок Open Source должно осуществляться по тем же моделям, что и финансирование фундаментальной науки – то есть дотационными. На что Марк сказал: предположим, Вы написали программу чисто научного назначения. И Вам присылают к ней патч, никакого отношения к науке не имеющий, но делающей эту программу пригодной для коммерческого использования. Включите Вы его в свою программу, или нет?

Вопрос поставил меня несколько в тупик. Чуть подумав, я ответил – почему бы и нет? Ведь в сущности, наука для того и существует, чтобы ее результаты использовались. В том числе и в интересах бизнеса. Важно только, чтобы наука сама не становилась при этом бизнесом. На чем примерно и был достигнут консенсус.

Вот такое странное интервью получилось...

В заключение отмечу, что встреча прошла, как говорится, в тёплой и дружественной, я бы сказал – неформальной, обстановке. Не обошлась она без «раздачи слонов» – наклеек Ubuntu и последнего номера журнала Linuxformat. А лично меня она навела на некоторые мысли, которыми я надеюсь поделиться с читателями в самое ближайшее время.

LinuxFormat #83 (сентябрь 2006)

Одна из отличительная особенностей дистрибутивов семейства Debian – разнообразие средств управления пакетами. Однако в последнее время в качестве такового рекомендуется aptitude – надстройка над apt, работающая в текстовом режиме. Она предполагает два метода использования – интерактивный и командный. Первый был подробно описан Тихоном Тарнавским (LinuxFormat, #5(79), 2006). Поэтому я остановлюсь только на командном методе, затронутом им лишь вкратце.

Командный метод использования aptitude будет непривычен тому, кто знаком с утилитами apt-get и apt-cache: конструкция ее директив предполагает наличие оператора и, для некоторых из последних, также аргумента – имени пакета или ключевого слова.

Особенности aptitude в сравнении с утилитами apt проще всего рассмотреть на примере конкретных командных директив.

Резонные люди обычно начинают работу с пакетами поиском нужного для установки. В случае с aptitude это делается так:

$ aptitude search keyword

ответом на что будет список всех пакетов, в названии или описании которых имеется указанное ключевое слово, с краткой характеристикой. Почти как в apt, но вывод aptitude содержит информацию о текущем состоянии пакета. Например:

$ aptitude search term

даст примерно такой список.

Пакеты, маркированные литерой i (от installed), уже установлены в системе, а помеченные литерой p (от purge) – не установлены или удалены «вчистую» (как – будет говориться далее). Кроме того, в этой колонке могут присутствовать марки c (от clean), которой отмечены пакеты удаленные, следы которых (в виде конфигурационных файлов), однако, сохранились, и v (от virtual), чем обозначаются так называемые виртуальные пакеты, представляющие собой просто списки пакетов реальных.

Для инсталлированных пакетов возможна еще и дополнительная маркировка – литерой A (от automatic); таким образом помечаются пакеты, установленные автоматически в качестве зависимостей других пакетов.

Следующий этап – получение информации о тех пакетах, которые можно заподозрить в полезности. Этой цели служит оператор show, требующий аргумента в виде имени пакета, например:

$ aptitude show mlterm

выведет весьма подробные сведения о пакете mlterm (рис. 2):

   • имя и версия;

   • статус – установлен ли пакет, и если установлен – то как: собственноручно или автоматически, в качестве зависимости;

   • приоритет пакета и раздел репозитория, к которому он приписан;

   • имя и e-mail майнтайнера;

   • размер пакета в распакованном виде;

   • зависимости пакета, предложения по дополнительным компонентам и конфликтующие пакеты;

   • назначение и функциональность.

В aptitude, в отличие от apt, в число зависимостей включаются не только обязательные (depends), но также и рекомендуемые (recommends) пакеты.

Очевидно, что все операторы команды aptitude, служащие получению информации о пакетах, могут выполняться от лица обычного пользователя. Следующие же операторы требуют уже привилегий администратора – в дистрибутивах семейства Ubuntu они получаются посредством команды sudo.

Установка выбранных пакетов осуществляется посредством оператора install, требующем в качестве аргумента имени пакета:

$ sudo aptitude install pkg_name

Оператор install команды aptitude, в отличие от одноименного из apt-get, устанавливает не только «строгие» зависимости пакета (собственно depends), но и часть «мягких» (recommends), то есть все, что перечислено в качестве зависимостей в выводе оператора show. На усмотрение пользователя остается только установка «мягких» зависимостей из категории suggest (то есть «предложений» оператора show). Хотя, как мы увидим далее, такое положение можно изменить.

Установка версий пакетов осуществляется в соответствие с локальным их кешем. Каковой время от времени (а также после подключения дополнительных репозиториев) нуждается в обновлении. Это осуществляется посредством оператора update, в аргументах не нуждающегося.

Пакет, «испорченный» по какой-либо причине (например, неаккуратным вмешательством в конфигурационные файлы) можно «починить». Команда

$ sudo aptitude reinstall pkg_name

вернет его в первозданное состояние.

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

$ sudo aptitude remove pkg_name

удалит указанный в качестве аргумента пакет с сохранением его конфигурационных файлов. Именно такая ситуация и маркируется литерой c в выводе команды aptitude search. Полная же очистка системы от всех следов пакета достигается оператором purge:

$ sudo aptitude purge pkg_name

В этом случае пакет в выводе команды aptitude search маркируется литерой p.

Важно, что оба оператора удаления – и remove, и purge, – денисталлируют не только пакет, указанный в качестве аргумента, но и все те, которые были установлены автоматически в качестве его зависимостей – разумеется, только в том случае, если в системе не осталось других программ, которые от них зависят. Уже одно это является веским аргументом в пользу предпочтения aptitude перед классическими инструментами apt.

aptitude позволяет выполнить и тотальное обновление системы – этой цели служат операторы upgrade и dist-upgrade. Как и в apt-get, первый обновит все установленные пакеты в том случае, если это не влечет за собой новых, противоречащих наличным, зависимостей. Оператор же dist-upgrade выполнит принудительное обновление системы. В обоих случаях удалению подвергнутся также автоматически установленные пакеты, от которых больше ничего не зависит.

Позволяет aptitude избавиться и от промежуточных продуктов собственной жизнедеятельности – скачанных из Сети deb-архивов; для этого предназначены операторы clean и autoclean.

И, наконец, еще пара операторов, не имеющих аналогов в инструментарии apt: markauto и unmarkauto. Первый помечает пакет или их группу как установленные автоматически в качестве зависимостей. Так, командой

$ sudo aptitude markauto ’~slibs’

в качестве автоматически установленных будут помечены все пакеты с компонентом libs в имени – то есть практически все библиотеки. Следствием чего явится автоматическое удаление неиспользуемых библиотек после деинсталляции последнего зависимого от них пакета.

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

$ sudo aptitude unmarkauto pkg_name

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

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

$ man 8 aptitude

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