Читаем Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013 полностью

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

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

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

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

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

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

<p><emphasis><strong>Снова aptitude: режим командной строки</strong></emphasis></p>

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) пакеты.

Перейти на страницу:

Похожие книги