Алексей Федорчук - Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013

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

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

Вопрос: Я поставил Ubuntu только для того, чтобы отказаться от ворованного программного обеспечения. Как мне объяснить это моим друзьям? (смех и аплодисменты)

Ответ: Я не думаю, что нужно убеждать пользователей Windows перейти на Linux, но я ищу те самые моменты, которые покажут преимущества свободного софта.

Вопрос: Планируются ли добавления в Launchpad специально для переводчиков?

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

Вопрос: Полетели бы Вы в космос на корабле, все бортовые компьютеры которого работают под Ubuntu?

Ответ: Нет (смех и бурные аплодисменты).

Знаете, какая система работает на Союзе? Восьмибитный компьютер 70-х годов, с программами непосредственно в машинных кодах, с прямым программированием памяти, в котором нечему ломаться (бурные аплодисменты).

В качестве завершающего штриха встречи планировалось, что Марк даст расширенное интервью для журнала LinuxFormat. Однако на большинство мыслимых вопросов ответы были получены или из выступления, или в ходе последующего обсуждения, и заставлять Марка повторять это в очередной раз было бы антигуманно. И потому все интервью свелось к обсуждению двух вопросов, показавшимся, во-первых, наиболее важными, а во-вторых, не прозвучавшим в основной части. В качестве интервьюера выступал ваш покорный слуга (хотя в итоге получилось совсем не интервью), роль переводчика исполнял Павел Фролов – генеральный директор компании Linuxcenter.

Сначала я поинтересовался мнением Марка на счет того, с какого конца следует подходить к пропаганде 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) пакеты.