Вся правда о пингвинах!

Mandriva/ROSA 2011 - что можно сделать после установки

2011-08-29T16:33:00.002+04:00

Решил вкратце собрать тут ту инфу, что смог собрать, пользуясь свежей Mandriva (которая сегодня зарелизилась) уже месяц. Как всегда, приводимая здесь информация на свой страх и риск. Приведенные советы могут взорвать ваш компьютер, съесть вашего хомяка, начальник лишит вас премии, а лучший друг обидится на вас. Если все это вас не пугает - вперед!

1. Инсталлятор Mandriva, который до сих пор используется, представляет собой старый и почти заброшенный инсталлер доставшийся «по наследству». Новый инсталлятор есть, но оттестировать к релизу его не успели. К чему это я? Во время установки ставится много лишних пакетов (поддержка оборудования, дополнительные локали). Причем, в Mandriva этот список еще больше, чем в Росе. Удалить лишнее из системы можно скриптом, специально предназначенным для таких целей разработчиками:

[root@host13 ~]# remove-unused-packages

2. Удаляем лишнее модули из initrd. В Mandriva/Роса для генерации initd используется dracut. Список запускаемых модулей можно посмотрев, просто запустив его:

[root@host13 ~]# dracut /boot/initrd-$(uname -r)-test.img

Затем открываем в любимом текстовом редакторе файл /etc/dracut.conf и прописываем туда такую строку:

omit_dracutmodules+="network ifcfg btrfs crypt dmsquash-live mdraid fcoe nfs resume aufs-mount"

Список приведен для моей машины, выбирайте «лишние» модули на свой страх и риск. Скажем, удалять из списка модуль mdraid не рекомендуется, если ваша система грузится с софтового raid'а. Если используется btrfs - модуль удалять так же не стоит. Перезапускаем dracut еще раз:

[root@host13 ~]# dracut -f /boot/initrd-$(uname -r)-test.img

Добавляем новый initrd в grub (отдельным пунктом!). Последнее предупреждение: если вы не знаете как это сделать и не понимаете всего, что приведено в этом пункте, этот совет не для вас. Я предупредил!

Если перезагрузка пройдет успешно, то можно убрать из названия образа initrd слово «test» и прописать его в загрузчик насовсем.

3. Владельцы карт Nvidia и ATI должны установить (при желании) свой проприетарный драйвер. Сделать это лучше через Центр Управления Mandriva или (что быстрее) сразу запустить drakx11 (работает и без графики совсем). Попакетная установка драйверов через пакетный менеджер, увы, не сработает. Также нелишним для владельцев Nvidia будет прописать открытый драйвер nouveau в blacklist:

[root@host13 ~]# vim /etc/modprobe.d/blacklist-mdv

В этот файл надо добавить строчку:

blacklist nouveau

4. Далее открываем модуль настройки загружаемых при старте системы сервисов. Из консоли это - drakxservices. Либо через «Настройка Компьютера» - «Система» - «Включение и отключение системных сервисов». Здесь нужно отключить те службы, которые вам не нужны. Если вы не знаете этого - лучше будет закрыть этот модуль сразу. Лично я отключил: abrtd, atd, avahi-daemon, iptables и ip6tables (они нужны при ручной настройке firewall, если используете «родной» firewall от Mandriva - их можно смело выключить), lvm2-monitor и mdadm (если не используете LVM и RAID), netfs (если не монтируете через /etc/fstab сетевые файловые системы), network и network-up (если будете использовать networkmanager), nfs-server, nfs-common и rpcbind (я не использую NFS).

5. Те, кто испытывает мало объяснимое отрицательное отношение к systemd, может заменить его на sysvinit, который по-прежнему есть в репозиториях:

[root@host13 ~]# urpmi sysvinit

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

6. Если кому-то не подходит ядро версии 2.6.38, которое используется в системе, тот может поставить себе более новое «ванильное» ядро версии 3.0.3 от проекта MIB.

[root@host13 ~]# urpmi kernel-linus-latest

7. Доустановить в систему adobe flash player можно командой:

[root@host13 ~]# urpmi flash-player-plugin-preview

Вроде ничего не забыл :) . Удачной работы с Mandriva!

Авторы, отзовитесь!

2011-07-08T20:51:00.001+04:00

Привет всем!

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

Об условиях. Для того чтобы получить право публикации здесь - необходимо написать не менее трех статей. Желательно, чтобы они были грамотными, но это не проблема. Главное - интересное содержание. Три статьи - для того, чтобы я мог убедиться, что автор не иссякнет после написания одной-двух статей. Все присланные статьи будут опубликованы от имени тех авторов, которые пришлют эти статьи и в том виде, в котором они сами пожелают указать себя (или ники или полное имя). Адрес электронной почты приведен в моем профиле.

Дистрибутивы Linux. Часть II

2011-07-05T09:00:00.007+04:00

Хоть Virens частично и раскрыл эту тему в своем последнем посте, пост, приведенный ниже уже был наполовину готов. И я подумал - а не буду я отменять выкладывание этого поста. Что лучше, что хуже пусть судят остальные ;). Вопросы, касающиеся пакетного менеджмента я, в свое время, тоже опишу.

В первой части были рассмотрены основные определения, касающиеся понимания дистрибутива Linux. Теперь, собственно, я попытаюсь собрать это все воедино.

Как получается очередной дистрибутив Linux?

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

Чтобы понять, о чем я тут пишу, достаточно посмотреть на таких ярких личностей, как Патрик Фолькердинг (основатель, архитектор и пожизненный лидер Slackware), Ян Мердок (основатель Debian, хоть он в настоящее время и не имеет отношения к этому проекту, но заложенные им идеи живут по сей день) и Марк Шаттлворт (основатель Canonical и Ubuntu).

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

Дистрибутив, претендующий на независимость:

Берет исходные коды для своих пакетов непосредственно на сайтах разработчиков открытого ПО.
Обладает своей собственной системой пакетного менеджмента (чтоб не зависеть от других). Имеется в виду, конечно же, не совсем и не всегда разработка с нуля. Дистрибутив может использовать, допустим rpm, со своими расширениями, но высокоуровневый пакетный менеджер (такой как yum, zipper или apt) у независимого дистрибутива будет свой. Можно, конечно, взять имеющийся пакетный менеджер, но если вдруг его бросят оригинальные разработчики, то можно огрести кучу проблем. Пример, который сходу приходит на ум, - это ALT Linux со своим apt-rpm, который заброшен оригинальными разработчиками и поддерживается теперь только альтовцами.
Обладает собственным сообществом разработчиков. Это тоже большая проблема, потому что свободные разработчики они на то и свободные, что заставить их сделать что-то невозможно. Если им что-то не понравится - они уйдут в другой проект. И отдельная проблема - это убедить их в том, что новый проект будет нужен другим и к нему действительно стоит прикладывать руки и время.
Обладает критическим числом квалифицированных разработчиков. Я это выделил в отдельный пункт, потому что квалифицированные кадры - это отдельная проблема, ведь их всегда не хватает. Разработчики могут просто упаковывать необходимый софт в пакеты дистрибутива (как это делают в ArchLinux), а могут и сопровождать подконтрольные пакеты, самостоятельно портируя для них необходимые исправления. Первое может делать кто угодно, а вот для второго уже необходимо наличие определенных знаний. Ряд системных пакетов (компилятор, сборочная среда, Х-сервер, ядро) все равно придется сопровождать на уровне, отличном от просто упаковки нужного софта, для чего и нужны такие разработчики.

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

Например, Ubuntu берет бОльшую часть пакетов из репозитория Debian, не модифицируя их, что примерно показано вот здесь. Все свои улучшения вносятся набором дополнительных пакетов, таких как ubuntu-artwork, ubuntu-branding. А Linux Mint, в свою очередь, делает то же самое (но в значительно меньшем объеме) с Ubuntu, потому что является даже не производным дистрибутивом, а надстройкой над Ubuntu.

Итак, дело за третьим этапом - разработка архитектуры дистрибутива (ничего общего с поддержкой архитектур процессоров тут нет). Архитектура - это изначальное проектирование проекта как такового, и это именно то, что делает дистрибутив отличным от других. Это те идеи, цели и критерии, которые закладываются в его существование, и изменить потом что-либо достаточно трудно. Это все то, что формирует дистрибутив и отношение к нему тех, кто пользуется им. Вопрос выбора дистрибутива лежит обычно в сфере личных пристрастий, и именно поэтому на тему «Какой дистрибутив Linux лучший?» на форумах раздуваются жуткие холивары :). Тех кого не забанили на популярных форумах, за вопрос «Что лучше rpm или deb?» вполне могут попробовать испытать терпение модераторов спросив про дистрибутив :).

Ниже приведен примерный список всего того, что делает дистрибутив Linux особенным (и одновременно это набор показателей оценки его качества и серьезности задела):

То, ради чего создается дистрибутив, - его миссия. У Debian - это создание максимально свободной универсальной операционной системы для всех. У Red Hat - примерно то же самое, только для корпоративных заказчиков. У Archlinux и Slackware - это создание дистрибутива на основе принципа KISS (максимально возможная простота), то есть отсутствие (либо минимальное наличие) каких-либо средств конфигурирования дистрибутива и ПО, в него входящего. Сюда же относится лицензионная политика для ПО дистрибутива. Есть ряд дистрибутивов, относимых к максимально свободным, – из них удален весь проприетарный софт, закрытые прошивки для устройств. Какой выбирать по данному критерию – каждый решает самостоятельно. Найти всю интересующую информацию по данному вопросу для конкретного дистрибутива нетрудно. Чтобы узнать ее, достаточно знать английский язык и название официального сайта дистрибутива.
Анонсируемая сфера применения дистрибутива - встроенные системы, десктопы, сервера, облачные вычисления, роутеры или «и то и другое, и можно без хлеба» (c). Сходу сделать самостоятельный проект, рассчитанный на универсальность, вряд ли у кого получится (а если кто обещает это сделать – или дурак, или маркетолог :) ), поэтому многие проекты идут на то, что поддерживают определенную часть репозитория, оставляя сообществу другую часть - например, как в Ubuntu, где есть репозитории main и restricted, поддерживаемые Canonical, и multiverse и universe, поддерживаемые сообществом. Примерно та же схема у Red Hat/Fedora. Fedora - фарм-дистрибутив, в который сообщество собирает пакеты, а Red Hat отбирает из их репозитория то, что подходит для Red Hat Enterprise Linux, чтобы потом поддерживать это все безобразие максимально возможный срок. Плюс во всему часть пакетов Fedora пересобирается сообществом для пользователей RHEL в рамках проекта EPEL.
Список поддерживаемых дистрибутивом архитектур. Обычно это вездесущие x86-совместимые - i386/i686 и x86_64. Сейчас в список широко поддерживаемых архитектур все чаще добавляется ARM. Самый большой список поддерживаемых архитектур – у Debian и Gentoo.
Объем пакетов во всех репозиториях дистрибутива. Большинство проектов позволяют выполнять поиск пакетов через обычный веб-интерфейс без необходимости установки дистрибутива. Таковы Gentoo, Fedora, ArchLinux, openSUSE, Debian, Ubuntu и даже ALT Linux. Это позволяет оценить наличие в дистрибутиве нужного ПО и его версию.
Анонсируемый уровень пользователей дистрибутива. В данном случае под пользователями понимаются все, кто будет эксплуатировать этот дистрибутив, будь то десктопные пользователи или администраторы серверов. Есть дистрибутивы для очень опытных пользователей (например, новичок в мире Linux просто не сможет поставить Gentoo) и для не искушенных пользователей, как, например Ubuntu.
Конечная форма доставки пакетов пользователям - поставляется ли дистрибутив в бинарном виде или, как Gentoo, собирается на локальной машине. Тут могут быть и смешанные варианты. ArchLinux, например, имеет репозиторий бинарных пакетов и свою собственную систему для их сборки – ABS. Если пакета нет в базовых репозиториях, то можно легко найти файл спецификации для сборки пакета PKGBUILD в пользовательском репозитории AUR и собрать его самостоятельно. Та же схема и у Slackware. В этом дистрибутиве есть базовый репозиторий, подерживаемый на основе релизов. Все дополнительное ПО, по каким-то причинам не включенное Патриком в дистрибутив его пользователям предлагается собирать с помощью специальных скриптов SlackBuild.
Политика релизов дистрибутива - выпускаются ли релизы или дистрибутив безрелизный. Обычно анонсируется срок жизни релиза (срок поддержки, за время которого выпускаются обновления) и примерные или точные сроки выхода новых релизов. Например, у Debian релиз выходит по готовности (примерно раз в два-три года), Ubuntu выпускает релизы точно в срок: релизы с долгим временем поддержки – раз в два года, с коротким – раз в полгода.
Немаловажный фактор, отражающий качество сборки пакетов и квалификацию их майнтейнеров, – это стабильность репозитория для выпущенного релиза (и пакетов в нем). К сожалению, это познается только на собственном опыте. В некоторых дистрибутивах есть тенденции, что обновления нет-нет да и ломают что-нибудь. Не так серьезно, конечно, как в дистрибутивах со скользящими релизами, но все равно неприятно.
Для дистрибутивов, выходящих на основе релизов, огромную важность несет скорость выхода обновлений, связанных с безопасностью ПО. Это тоже показывает уровень квалификации разработчиков дистрибутива. Серьезные дистрибутивы выпускают такие обновления оперативно, несерьезные берут исправления у серьезных :).
Уровень модификации пакетов апстрим. Некоторые проекты, типа Archlinux, Gentoo, Slackware используют авторские пакеты без каких-либо серьезных модификаций. Другие проекты, типа Fedora и openSUSE обычно сильно патчат все свои пакеты. Иногда это сказывается на стабильности этих дистрибутивов, иногда нет... Ubuntu, например, также сильно модифицирует все пакеты, связанные с рабочим столом пользователя, потому что компания Canonical оплачивает труд профессиональных дизайнеров, которые и улучшают ее внешний вид. Это причина того, что в одних дистрибутивах интерфейс оконной среды сделан в стиле «разработано профессиональными программистами», а в других – любо-дорого посмотреть.
Системные компоненты, включенные в дистрибутив по умолчанию. Также важна возможность предоставления вариантов этих компонентов и легкость их смены. Кто-то предоставляет эту возможность, кто-то нет. Например, в Fedora, начиная с 15-й версии, система инициализации systemd приколочена к системе намертво, а в openSUSE по-умолчанию используется старый добрый sysvinit, а systemd предоставляется как вариант. Еще один пример - во все дистрибутивы включается ядро Linux :). И во всех дистрибутивах перед разработчиками встают такие вопросы - нужно ли использовать какие-то дополнительные патчи для него, типа bfs, или нет? Нужно ли предоставлять пользователям несколько вариантов «вкуса» (flavours) ядра, как делают openSUSE, Ubuntu и Mandriva или стоит обойтись одним универсальным вариантом? Другие примеры – это возможность выбора различных вариантов сетевых служб, имеющих аналогичный функционал (например, sendmail/postfix), Java-сред по умолчанию, вариантов рабочего стола, офисного пакета (Openoffice.org или Libreoffice), оконной среды - KDE/GNOME/XFCE/Openbox/WindowMaker и т.п.
Принципы построения сообщества вокруг дистрибутива. Обычно это вопросы иерархии тех, кто дистрибутив разрабатывает: кто будет принимать технические решения, кто будет обладать правом арбитра при решении споров и правом вето, как будут приниматься пожелания. Не менее важно - как построена обратная связь с пользователями дистрибутива - только через систему отслеживания ошибок или нечто подобное OpenFATE в openSUSE, brainstorm в Ubuntu и GLEP в Gentoo. Важны вопросы приема в проект новых участников, условия этого вступления. В нормальных и серьезных проектах такие вещи определяются политиками и руководящими документами. Легкость нахождения этих документов и их полнота - отличный показатель серьезности проекта.
Доступность документации для конкретного дистрибутива. Все серьезные проекты имеют не менее серьезные wiki-страницы. По уровню wiki и ее проработанности лидирует, на мой взгляд, wiki.archlinux.org, неплохие страницы документации у Gentoo и Ubuntu. Для администраторов Red Hat кладезь информации - сайт docs.redhat.com.
Еще один показатель качества дистрибутива - это наличие на сайте с документацией правил сборки пакетов для него с обязательными требованиями по качеству их сборки. У дистрибутивов, относящих себя к серьезным проектам, всегда есть в свободном доступе скрипты для выполнения такой проверки (deblint для Debian/Ubuntu, rpmlint в Fedora/openSUSE, sisyphus_check в ALT Linux). Эти скрипты используются в сборочной системе для контроля качества собранного пакета. Уровень серьезности таких проверок варьируется от дистрибутива к дистрибутиву, например, OBS проверяет исходный код на наличие утечек памяти, а в Debian в репозиторий не попадет пакет без man-страницы.
Тяжелый вопрос для каждого из проектов - вопрос инфраструктуры. У серьезного дистрибутива должен быть свой web-сайт, на котором размещаются основные документы, касающиеся дистрибутива, приема новых участников команды, сайт с документацией, формы для приема пожеланий по его развитию, и, конечно же, форум для общения и обмена мнениям. Помимо этого - сборочный сервер, сервер с репозиторием дистрибутива и репозиториями отдельных разработчиков. Инфраструктура никак не может быть виртуальной и требует для своей работы определенного количества денег. Крупным проектам технику обычно дарят, а список дарителей висит на веб-странице проекта в явном виде.

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

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

Выбор дистрибутива можно делать примерно так:

Допустим, нам нужен дистрибутив с красивым десктопом из коробки, обладающий хорошей стабильностью и огромным количеством софта. Скорее всего, это будет Ubuntu LTS.Нужен дистрибутив под базу данных Oracle. Тут выбор маленький, и с вероятностью 95% ими будут Red Hat Enterprise Linux или SUSE.

Нужен дистрибутив под LAMP-сервер – хороший выбор тут Debian или Ubuntu Server.

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

Если вы опытный пользователь, любите экспериментировать с системой, ставить несколько версий одного ПО «на потестить», цените огромную гибкость системы, любите, чтоб все было по-вашему и готовы платить за это своим временем, – однозначный выбор Gentoo.

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

Прощай, Учебный Центр!

2011-07-04T10:00:00.001+04:00

Пришло время сказать "прощай" тому месту, где я провел почти три года. За это время я значительно вырос и как преподаватель, и как Linux-специалист, но все хорошее имеет тенденцию рано или поздно заканчиваться... И тогда приходит время искать новые горизонты.

А тому что ушло - самое время сказать два слова: Прощай и Спасибо за все!

Что касается данного блога - бросать я его не намерен. Буду его вести, по-прежнему, в меру своих сил. И постараюсь не бросать его больше на такой большой срок, как последние полгода :).

Из чего состоят дистрибутивы Linux. Часть I

2011-06-30T09:00:00.005+04:00

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

Представьте себе огромное количество разного ПО от маленьких (но важных) проектов по отдельным библиотекам до огромных типа KDE, GNOME, Libre- и OpenOffice, ядра Linux. Все эти отдельные проекты развиваются каждый сам по себе, иногда с оглядкой на остальные, иногда нет. Конечно, каждый может собрать это все ПО вместе и объявить дистрибутивом Linux, но в случае серьезных дистрибутивов (я к ним отношу те, что занимают первые 10 мест в рейтинге Distrowatch) все обычно гораздо сложнее.

Немного о терминах.
Разработчиками дистрибутива (или майнтейнерами) обычно называют тех, кто берет какое-то ПО и упаковывает его в пакет для конкретного дистрибутива (пакетная система, для чего она нужна и что делает - отдельный большой вопрос).
Место, откуда это ПО берется - называется апстрим (от английского upstream). Адекватного перевода на русский язык я пока не нашел, да и слово апстрим стало уже устоявшимся термином. Для серьезных дистрибутивов апстримом являются конкретные проекты свободного (и не очень) ПО. Для производных дистрибутивов - другие дистрибутивы Linux. Например, для CentOS - апстримом является Red Hat Enterpise Linux, для Ubuntu - Debian, для Debian - оригинальные разработчики ПО. Еще раз - апстрим это или разработчик конкретной программы, или родительский дистрибутив.
Пакетом называется отдельный атом дистрибутива (в смысле неделимости), который несет в себе конкретную программу (или набор программ), библиотеку (или набор библиотек), документацию, темы оформления или что-то еще. Короче говоря, все, что составляет дистрибутив Linux - это меньшее или большее количество пакетов. Пакет - это обычно:

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

Пакетная система - то, что помогает пользователям дистрибутива искать, ставить, обновлять пакеты и автоматически отслеживать зависимости между ними. Пакетные системы в мире Linux делятся на три больших и хорошо очерченных класса:

пакетная система Debian и ее deb-пакеты.
пакетная система rpm, придуманная в свое время Red Hat и теперь имеющая не всегда совместимые между собой пакеты разных rpm-дистрибутивов (Red Hat/Fedora, SUSE, Mandriva и т.п.). Имеется в виду, что, например, пакет для Mandriva может и встанет на SUSE (зависит от положения звезд на небе), но работать скорее всего откажется.
все остальные пакетные системы. В качестве примера сюда можно отнести и пакеты ArchLinux, и Slackware, и отчасти Gentoo.

Важный составляющих элемент пакетной системы - менеджер пакетов. Это программа, позволяющая управлять пакетами на конкретной машине. И обычно она имеет только текстовый интерфейс, но разработчики большинства дистрибутивов, как правило, поставляют графические утилиты, взаимодействующие с пакетным менеджером и таким образом значительно облегчающие жизнь тех, кто еще не познакомился с консолью Linux или не хочет с ней знакомится вовсе.
Вопрос какая пакетная система лучше, какая хуже - относится к сфере личных пристрастий и потому спорный. Желающие могут в этом убедиться, открыв на каком-нибудь Linux-форуме тему «Что лучше rpm или deb?». Если Вас сразу не забанят модераторы форума за провокацию, то флейм по этому поводу займет не один десяток страниц.
Зависимости - это следующая непонятная новичкам штука. Бывают жесткие и мягкие. Жесткая зависимость в общем виде - это все то, без чего содержимое пакета работать не будет. Обычно это какие-то библиотеки, обеспечивающие функционал конкретной программы. Мягкая зависимость - это то, что обеспечивает дополнительный функционал для программы. Такой тип зависимостей есть, по большому счету, только в deb-пакетах.
Следующее непонятное определение - репозиторий пакетов. Это место, откуда пользователи берут ПО для своего дистрибутива. Обычно это некое сетевое (но может быть и локальным) хранилище пакета, в котором помимо собственно пакетов для дистрибутива находится набор метаданных, которые используются пакетным менеджером для управления ПО на машине пользователя. Именно благодаря этим метаданным пользователям достаточно легко найти нужные пакеты в репозитории, а пакетному менеджеру выяснить, какое ПО требует обновлений.
По способу поддержки репозитория можно выделить три типа дистрибутивов:

Дистрибутивы со скользящим релизом (или безрелизные). На английском они обычно называются rolling release. Типичный (и достаточно популярный) тут - Archlinux. В таких дистрибутивах после обычно малого периода тестирования пакеты попадают к пользователям практически сразу после релиза конкретного пакета его разработчиком. Главное преимущество таких дистрибутивов - то, что в репозитории находится очень свежее ПО. Это имеет и обратную сторону (за все в жизни приходится платить) - в этом ПО зачастую имеются ошибки, которые с переменным успехом отлавливаются пользователями такого дистрибутива. По причине того, что большая часть проектов развивается без оглядки друг на друга, иногда встречается какая-либо несовместимость между какими-то пакетами, вызывающая неработоспособность определенной программы. Иногда (при серьезных изменениях) меняется формат конфигурационного файла программы или демона, что требует работы руками. Но те, кто используют такие дистрибутивы, обычно знают, на что идут, и достаточно квалифицированы для того, чтобы решить все возникающие проблемы. Тут из всех дистрибутивов, на мой взгляд, самый выдержанный подход у Gentoo, который представляет собой дистрибутив с rolling release-моделью, но тем не менее все пакеты попадают в его стабильную ветвь после значительного периода тестирования, что обеспечивает достаточно высокую надежность его работы.
Дистрибутивы с релизной моделью. Проблема получения стабильного дистрибутива давно уже решена и используется большинством разработчиков разных дистрибутивов Linux, таких как Debian, Ubuntu, Red Hat, SUSE и проч. У таких дистрибутивов есть обычно тестовая ветвь с rolling release-моделью, на которой обкатываются (и решаются) разные проблемы несовместимости и нестабильной работы конкретного ПО. Периодически эту ветвь замораживают, блокируя попадание туда новых пакетов. Затем в таком репозитории вычищают по максимуму все имеющиеся в нем проблемы и ошибки. Когда ошибок, по мнению разработчиков, уже достаточно малое количество, выпускается очередной релиз, на протяжении жизни которого в нем не будут уже меняться версии имеющегося ПО. Обновления такого дистрибутива включают в себя исправление оставшихся ошибок и устранение возникающих время от времени уязвимостей. Иногда ошибки устраняют и разработчики апстрима. Тогда задача майнтейнера пакета проанализировать исходный код разработчиков ПО (он же открыт) и выделить из него только те изменения, которые отвечают за исправление ошибок. Затем эти изменения накладываются на те программы и библиотеки, которые находятся в стабильном релизе. Благодаря этому получается, что версия ПО в стабильном дистрибутиве старая, но тем не менее в ней исправлено большинство уязвимостей, найденных к этому моменту. Другое дело, что длительная поддержка ПО по такой схеме - вещь трудная. Ведь чем больше проходит времени с момента релиза, тем более высокая квалификация требуется от разработчика, чтобы выделить только то, что исправляет ошибки и ни в коем случае не ломает совместимость с другими программами и библиотеками. Именно по этой причине длительную поддержку релиза могут позволить себе немногие. По сути лишь те, кто имеет большое количество квалифицированных программистов, то есть коммерческие компании Red Hat и Novell. Такие дистрибутивы прекрасно подходят для консервативной корпоративной среды, где редко происходят сильные изменения и поэтому нужна высокая стабильность работы.
Дистрибутивы со смешанным циклом. В таких дистрибутивах стабилизируется (замораживается) только одна часть репозитория. Как правило, это все, что относится к сборочной среде, - компилятор, библиотека C, разные важные библиотеки, ядро Linux. А ПО, относящееся к десктопам (типа Firefox, OpenOffice, разные игры), обновляется регулярно (но обязательно после продолжительного тестирования).

Для таких популярных дистрибутивов как openSUSE и Ubuntu есть выбор - либо использовать стабильную базу конкретного релиза их дистрибутива, или подключить дополнительные репозитории (репозитории OBS для SUSE и ppa для Ubuntu), получая таким образом более свежее ПО для своей системы.
Вроде как все, что хотелось бы сказать по данному поводу. Если что осталось неясно, постараюсь ответить в комментариях на вопросы, касающиеся данной статьи. В меру сил и наличия свободного времени постараюсь внести все необходимые изменения, если потребуется в приведенный текст статьи.

По следам прошедшего Open Source Summit'а

2011-04-13T13:27:00.000+04:00

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

Сначала о выступлениях в торжественной части.

Первым выступал директор Департамента государственной политики в области информационных технологий и координации информатизации Минкомсвязи России с докладом на тему - «Создание национальной программной платформы. Разработка приложений, основанных на использовании СПО» - г-н Милашевский И.А. На доклад, естественно, он вышел с ноутбуком от Apple и презентациями, сделанными в самом популярном офисном приложении (к слову, из всех выступающих только у Марка Шаттлворта были слайды в PDF :) ). Доклад был посвящен основным вопросам, которые необходимо будет решить для создания национальной операционной системы. В частности:

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

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

Марк начал с обращения к присутствующим по-русски, сказав, что немного знает русский язык, но поскольку он его знает не в том объеме, чтобы читать на нем доклад - он продолжит по-английски. Само выступление касалось множества политических и организационных вопросов (я предвижу, что его за это будут «пинать» многие линуксоиды, которые вечно всем недовольны). Доклад начался с того, что на сегодняшний день Linux и все, что его окружает (движение Open Source), становится мейнстримом всей IT-сферы. Все технологические новинки появляются в первую очередь здесь - это виртуализация, новомодные облачные вычисления. Linux неумолимо пробирается на телефоны, встраиваемые устройства, начинает предустанавливаться на новые ноутбуки.

В то же время, если мы хотим ориентироваться на что-то большее, чем серверные решения, - в этом случае необходимо предложить решения «из коробки». Огромный недостаток Linux в том, что пока таких решений мало. И Canonical пытается решить именно эти вопросы. Что нужно большинству людей - чтобы после установки система просто работала, находила все необходимые драйвера для подключаемых устройств (естественно, что для этого необходимо, чтоб они были :) ). В частности, Марк упомянул, что, например, при внедрении Linux в российские школы многие столкнулись с тем, что не со всеми версиями дистрибутива работал драйвер «электронной доски». И именно проблема с недостатком драйверов пока является самой большой и самой «неудобной» для массового внедрения Linux.

Следующее перспективное направление - снижение «фрагментации» Linux-сообщества путем создания глобальной экосистемы. Ни для кого не секрет, что сейчас сообщество сильно разделено. Многие работают над одним и тем же одновременно, распыляя усилия и плодя множество однотипных проектов. Ведь OpenSource, как движение, и создавался для того, чтобы можно было по максимуму использовать уже существующие решения, доводя их до ума, а не изобретать каждый раз велосипед заново. Не поддается сомнению и то, что помимо глобального сообщества, работающего над мейнстримом, необходимо учитывать локальные проблемы. Тут Марк опять упомянул российские проблемы с «электронной доской».

Следующая проблема - это то, что существующая инфраструктура компаний-продавцов «железа» и программного обеспечения построена вокруг проприетарного ПО. Это одно из самых перспективных направлений. И акцент тут нужно делать не на бесплатности Linux, а на предложении пользователям тех возможностей, которых нет у «конкурирующих» систем: гибкость, простота использования, открытые стандарты и т.п.

И, конечно же, самое главное - это не повторить ситуацию 80-х годов и путь Microsoft. Сейчас в мире многое меняется и нельзя замыкаться в рамках каких-то границ (будь-то государственные границы или социальные), интересов. Необходимо сохранить то, чем всегда отличалось движение программ с открытым исходным кодом. - глобальная совместная работа над многими проектами. Соответственно, нужно менять и бизнес-подходы, позволяющие получать прибыль на свободном ПО, не повторяя историю успеха всеми «любимой» корпорации.

Следующим выступлением было «Информационно безопасные технологии на основе свободно распространяемых исходных кодов». Доклад читал первый заместитель начальника Центра ФСБ России Баранов А.П. Его выступление было, скажем так, очень спорным. В основном оно касалось вопросов государственной сертификации операционных систем ФСТЭК и создания на их основе решений для обеспечения безопасности государственной информации. По затратам на сертификацию и последующую доработку ОС под государственные требования нет никаких различий между Windows, Linux и BSD. Более того, докладчик посчитал, что в Linux серьезные проблемы с драйверами устройств, даже P'n'P там работает не так хорошо, как в Windows. Он объяснил это так - все производители «железа» работают прежде всего с Microsoft, поэтому и драйвера для Windows появляются раньше. Еще одна проблема Linux - недостаток прикладного ПО. А все потому, что Microsoft лучше стимулирует и направляет разработчиков своего ПО, поэтому оно у них и лучше и качественнее. Поэтому по прикладному ПО Linux так и будет отставать, потому что курировать разработку некому. В свете программы создания национальной платформы необходимо создать государственную структуру, которая будет курировать разработку такого прикладного ПО, необходимого госкомпаниям.

Следующая проблема для массового внедрения Linux - во многих государственных компаниях есть свое ПО, которое они не хотят переписывать под другую систему.

По возможностям, связанным с обеспечением безопасности данных, г-н Баранов считает, что система, «созданная из кусочков», гораздо менее безопасна, чем целостная и монолитная система от одного производителя. Для госцелей и для Windows и для Linux была создана своя система мандатного доступа. Для Windows она существует в виде отдельного диска, доустанавливающего все после установки базовой системы. Сама компания Microsoft не возражает против такой модификации своей операционной системы (еще бы она возражала - прим. автора.). Докладчик также отметил, что вследствие открытой модели разработки программисты под Linux и BSD-системы менее квалифицированы, чем их коллеги, пишущие программы под сами знаете что. Именно поэтому, затраты на создание мандатной системы доступа для Linux были гораздо больше, чем под Windows.

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

Многие организации хотят участвовать в разработке национальной ОС, поэтому необходимо с самого начала решить проблему координации усилий, для чего необходимо создать регулирующий госорган.
Программирование, как таковое, давно стало отдельной отраслью научного знания.
Производительность труда программистов выросла в несколько раз, благодаря новым языкам программирования, множеству существующих алгоритмов и повторному использованию кода.
Разработка ПО глобализуется, потому что компьютер и программы становятся неотъемлемой частью нашей жизни и потребность в ПО растет.

Последним докладом, на котором я присутствовал, было выступление г-на Петренко А.К., заведующего отделом технологий программирования ИСП РАН на тему «Свободное программное обеспечение, открытые технологии и открытые стандарты». Начал он с того, что из себя представляет свобода ПО в понимании Free Software Foundation и положений GPL. Я не буду это тут писать, потому что, думаю, многие с этим знакомы. Главным преимуществом свободного ПО докладчик считает возможность изучать код, учиться и учить других, зарабатывать на распространении и экономить на лицензиях, строить международные партнерства.

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

Основные риски свободного ПО (по мнению заказчиков) - его низкое качество и технологическое отставание, что не является истиной. На сегодняшний день многие крупные компании, включая Microsoft, курируют проект, связанные с ПО с открытым исходным кодом.

Планируемые результаты, которые планируется получить от использования национальной ОС:

Экономия государственных затрат за счет повторного использования программного обеспечения;
Приоритетная поддержка проектов, занимающихся научными исследованиями в области разработки программного обеспечения. Для этого необходимо разработать новую систему оценки конкурентных заявок по IT-проектам. По мнению докладчика, тут самым главным должна быть открытость полученных результатов, что позволит оценивать результат честно.
Государственная поддержка центров компетенции по ключевым направлениям.

После перерыва я переместился в секцию, где состоялась встреча Марка Шаттлворта с участниками сообщества Ubuntu. Ему задавали множество вопросов. Попробую тут привести некоторые из них по памяти:

Вопрос: Зачем нужна разработка Unity, если есть GNOME/KDE/что-то еще? Какова на сегодняшний день стабильность Unity?

Ответ: Пользователям системы нужно простое и удобное решение «из коробки». Имеющиеся среды не удовлетворяют таким требованиям. Например, если есть прекрасное решение, которое чтобы довести до ума нужно долго настраивать - оно не будет никому нужно. На настоящий момент Unity находится в активной разработке, именно поэтому разработчики Ubuntu до сих пор не решили - стоит ли включать ее в грядущий релиз. При разработке активно используется помощь простых людей «с улицы», которых сажают за систему и просят выполнить какую-то простейшую операцию, например, подключить веб-камеру, сделать с ее помощью снимки и выложить их на Facebook. Если человеку это удалось, значит интерфейс прост и удобен.

В качестве бета-тестеров Unity и Ubuntu участвуют и родители Марка. Он привел такой пример, что у его родителей на протяжении 6 лет стояла Ubuntu и когда он купил им новый ноутбук с Windows 7 - они сказали ему: «Убери эту неудобную гадость и поставь нам Ubuntu».

В: Что думает Марк Шаттлворт о конкуренции с Google Chrome OS? Какие будут его действия, если победит Google?

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

В: Планирует ли компания Canonical выпускать планшеты и наладонники с Ubuntu на борту?

О: Да, если будет такой спрос.

Молодые люди с форума Ubuntu снимали все на камеру и потом обещали выложить видео, так что думаю, желающие смогут найти позже в сети эти записи.

Затем я переместился в секцию, где директор по продажам компании Canonical Пол Хольт и инженер по политике продаж Борис Девоуг делали доклад о корпоративных решениях для закачиков. Небольшой нестыковкой было то, что слайды были переведены на русский язык, поэтому докладчики выступали «вслепую» :). Но свой текст они знали на пять баллов, поэтому не ошиблись ни разу.

С саммита мне пришлось уйти раньше, о чем я сильно сожалею, но надеюсь, что подобное событие произойдет и на будущий год :).

С наступающим!

2010-12-29T20:21:00.000+03:00

Поздравляю всех читателей этого дневника с наступающим Новым Годом! Желаю в наступающем году безглючного железа, безпроблемных пользователей! Также хочется пожелать успехов и в остальных сторонах жизни - материальной, личной, карьерной.

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

Еще раз успехов! И помните, пингвин птица полярная :)

Введение в использование LVM

2010-12-09T13:53:00.003+03:00

LVM - (Logical Volume Manager - менеджер логических дисков) средство гибкого управления дисковым пространством. Позволяет динамически менять размер логических разделов на лету, создавать снимки (снапшоты) и т.д.

Дисклеймер/отмазка

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

Зачем нужен LVM

Установка системы прямо на разделы диска зачастую приводит к следующей проблеме.

Нужно каким-то образом «правильно» разбить жесткий диск. Слово «правильно» стоит в кавычках, потому что «правильного» разбиения диска для всех возможных ситуаций и применений не существует. В сети есть много советов по данному поводу, но они не учитывают потребностей конкретного пользователя (в случае настольной системы) или конкретного администратора (в случае сервера). Обычно рекомендуют разделы /home, /var, /usr, какие-то еще выносить на отдельные разделы диска. Но если разбивающий ошибется в размерах этих разделов, возникает очень не хорошая ситуация - на одних разделах место подходит к концу, в то время как на остальных места еще много. Приехали! Дисковое пространство нужно переразмечать. Для этого есть много способов:

1. Тотальный backup, затем переустановка системы с переразбиением диска.

2. Переразметка с помощью parted с риском потерять данные.

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

Терминология

LVM предусматривает три логических уровня работы с дисковым пространством:

1. Самый нижний - физические тома (physical volumes). Это собственно физические диски. Это могут быть диски целиком (/dev/sda, /dev/sdb и т.д.) или отдельные разделы (/dev/sda1, /dev/sdb5 и т.п.).

2. Группы томов - volume groups. В группы томов объединяются физические тома. Таким образом группы томов представляют собой пул дискового пространства, необходимый для следующего уровня. Группы томов могут иметь человеческие названия, говорящие администратору системы об их предназначении: system, sales, database и т.д.

3. Логические тома (logical volumes) - это аналог разделов физического диска и то, ради чего вообще существуют диски - именно на них хранятся данные. Пользователи (и процессы) системы работают только с логическими томами. Таким образом LVM создает для них всех слой абстракции, скрывая, с какими именно физическими дисками они в данный момент работают. Администратор системы может добавлять физические тома в LVM и удалять их из него (см. ниже), но процессы (и пользователи) об этом знать не будут.

Примечание по названиям утилит LVM

Следует запомнить сразу - названия утилит для работы с разными уровнями LVM совпадают. Различие только в первых двух буквах этого названия. Это:

pv* - для работы с физическими томами;
vg* - для работы с группами томов;
lv* - для работы с логическими томами.

Не стоит также пытаться зазубрить названия этих утилит и их ключи. Действовать стоит так:

1. Думаете, с каким уровнем LVM надо работать - физические тома, группы томов или логические тома.

2. Выбираете в зависимости от этого первые буквы названия: pv, vg или lv, соответственно.

3. Набираете их в консоли и нажимаете два раза TAB. Срабатывает автодополнение, которое показывает команды, начинающиеся с указанных букв.

4. Выбираете команду по ее названию, например, pvcreate для создания физических томов. Если вы ее запустите с ключом --help , она вам покажет все возможные ключи. За более подробной информацией стоит залезть в man конкретной команды.

По мере набора опыта работы с LVM нужда в такой последовательности отпадет. Необходимые команды и их опции запомнятся сами собой.

Создание

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

Первый этап - это создание правильных разделов. Это такие разделы, которые LVM признает за свои и сможет при загрузке их корректно инициализировать. «Родной» тип разделов для LVM - 8E Linux LVM. Все, что будет дальше, не будет работать, если при создании разделов не указать приведенный корректный тип. Итак, создаем несколько разделов типа 8E с помощью любимого средства разбиения диска:

[root@localhost ~]# fdisk -l /dev/sdb

Disk /dev/sdb: 2147 MB, 2147483648 bytes

255 heads, 63 sectors/track, 261 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00000000

Device Boot Start End Blocks Id System

/dev/sdb1 1 61 489951 8e Linux LVM

/dev/sdb2 62 261 1606500 5 Extended

/dev/sdb5 62 122 489951 8e Linux LVM

/dev/sdb6 123 261 1116486 8e Linux LVM

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

Я создал три раздела для работы с LVM. Сколько их создавать и какого размера решает сам администратор. Например, никто не мешает отдать целиком весь диск (/dev/sdb в данном случае) под власть LVM. В том, как это сейчас сделал я, смысла искать не стоит :). Мой пример преследует только цели демонстрации работы с LVM.

ВНИМАНИЕ! Форматировать созданные разделы НЕ надо!

Следующее, что мы должны сделать - это инициализировать созданные разделы как физические тома:

[root@localhost ~]# pvcreate /dev/sdb1

Physical volume "/dev/sdb1" successfully created

[root@localhost ~]# pvcreate /dev/sdb5

Physical volume "/dev/sdb5" successfully created

[root@localhost ~]# pvcreate /dev/sdb6

Physical volume "/dev/sdb6" successfully created

Если нет сообщений об ошибках, можно смело шагать вперед.

Следующий шаг - это создание группы томов. Делается это командой vgcreate (еще раз подчеркиваю похожесть названия утилит для работы с LVM). Самое трудное тут - это придумать имя группы томов, которое будет отражать ее назначение:

[root@localhost ~]# vgcreate fileserver /dev/sdb1 /dev/sdb5

Volume group "fileserver" successfully created

Аргументы vgcreate это название группы томов (fileserver) и те физические тома, которые мы включаем в эту группу. В данном случае я включил в нее только /dev/sdb1 /dev/sdb5, что нам и покажет утилита pvscan:

[root@localhost ~]# pvscan

PV /dev/sdb1 VG fileserver lvm2 [476.00 MiB / 476.00 MiB free]

PV /dev/sdb5 VG fileserver lvm2 [476.00 MiB / 476.00 MiB free]

...

PV /dev/sdb6 lvm2 [1.06 GiB]

...

Здесь мы видим созданные нами физические тома, их размер и к какой группе томов они относятся. Последний физический том (/dev/sdb6) у нас пока сам по себе. Для обнаружения наличия групп томов LVM (это нужно, например, если вы загрузились с Live CD, который не активирует LVM по умолчанию) есть аналогичная команда - vgscan:

[root@localhost ~]# vgscan

Reading all physical volumes. This may take a while...

Found volume group "fileserver" using metadata type lvm2

Активировать неработающий LVM можно командой vgchange -ay:

[root@localhost ~]# vgchange -ay

0 logical volume(s) in volume group "fileserver" now active

Это все для того же примера с LiveCD. Сейчас это делать было не обязательно. Вывод приведенной команды показывает наличие отсутствия логических томов, значит сейчас самое время создать их :). Для создания логических томов испольузется команда lvcreate:

[root@localhost ~]# lvcreate -L 300M -n samba fileserver

Logical volume "samba" created

Вуаля! Вы только что создали свой первый логический том. Синтаксис команды прост до безобразия:

ключ -L указывает размер создаваемого тома. Поддерживаются суффиксы K (килобайты), M (мегабайты), G (гигабайты).
ключ -n указывает название для тома (samba в данном случае)
последний аргумент fileserver указывает группу томов, в которой мы создаем логический том (теоретически, групп может быть несколько).

Что важно - логические тома именуются системой следующим образом:

/dev/имя_группы_томов/имя_тома

В нашем примере это:

[root@localhost ~]# lvscan

ACTIVE '/dev/fileserver/samba' [300.00 MiB] inherit

Одно только это - хороший аргумент для использования LVM. Ведь не надо помнить что находится на /dev/sda3, /dev/sdb5 и т. п. Имена логических томов имеют вполне человеческое название (если их правильно назвать).

Еще несколько замечаний.

В группе томов можно создать столько томов, сколько будет нужно. Но не больше, чем есть дискового пространства в этой группе томов. Посмотреть, сколько его у нас есть (и самое главное сколько его еще осталось) можно командой vgdisplay:

[root@localhost ~]# vgdisplay fileserver

--- Volume group ---

VG Name fileserver

System ID

Format lvm2

Metadata Areas 2

Metadata Sequence No 2

VG Access read/write

VG Status resizable

MAX LV 0

Cur LV 1

Open LV 0

Max PV 0

Cur PV 2

Act PV 2

VG Size 952.00 MB

PE Size 4.00 MB

Total PE 238

Alloc PE / Size 75 / 300.00 MB

Free PE / Size 163 / 652.00 MB

VG UUID SZLgLK-b9V8-RiZV-gH5i-N0pA-2ppf-axLqfO

Сейчас для нас тут самое ценное - это VG Size 952.00 MB (общий размер дискового пространства группы томов), Alloc PE / Size 75 / 300.00 MB (уже выделенное для создания логических томов дисковое пространство), Free PE / Size 163 / 652.00 MB (свободное и еще не распределенное дисковое пространство - наш резерв).

PE тут - это физические экстенты. Они представляют собой нечто вроде кусков дискового пространства, на которые LVM «нарезает» физические тома. Все размеры логических томов всегда содержат целое число этих физических экстентов и всегда кратны их размеру (как видно из приведенных цифр размер экстента - 4Мб).

Теперь созданный том можно отформатировать и примонтировать:

[root@localhost ~]# mkdir /mnt/data

[root@localhost ~]# mkfs.ext4 /dev/fileserver/samba

...

[root@localhost ~]# mount /dev/fileserver/samba /mnt/data/

[root@localhost ~]# df -h

Filesystem Size Used Avail Use% Mounted on

...

/dev/mapper/fileserver-samba

291M 11M 266M 4% /mnt/data

Как мы видим, наш логический том готов к использованию!

Увеличение логических томов

Самая мощная возможность LVM - это то, что размеры логических томов можно менять на лету. Правда, чтобы их уменьшить, «полет» придется прервать (об этом ниже), а вот увеличение размеров томов - это практически безопасная операция.

Предположим, что нам перестало хватать места на нашем логическом томе /dev/fileserver/samba.

Последовательность действий такая:

1. Сначала нужно убедиться в наличии необходимого нам дискового пространства в группе томов. Делается это командой vgdisplay. Допустим, мы хотим добавить к нашему логическому тому еще 300 Мб. Как мы видим (см. вывод команды vgdisplay выше), у нас еще достаточно свободного места в группе.

2. Увеличиваем логический том командой lvextend:

[root@localhost ~]# lvextend -L +200M /dev/fileserver/samba

Extending logical volume samba to 500.00 MB

Logical volume samba successfully resized

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

3. Если мы теперь посмотрим на вывод команды df -h мы увидим, что пока ничего не изменилось:

[root@localhost ~]# df -h

Filesystem Size Used Avail Use% Mounted on

...

/dev/mapper/fileserver-samba

291M 11M 266M 4% /mnt/data

несмотря на то, что lvscan показывает верный размер:

[root@localhost ~]# lvscan

ACTIVE '/dev/fileserver/samba' [500.00 MB] inherit

Это произошло потому, что мы увеличили размер логического тома, но пока «забыли» сказать об этом файловой системе, расположенной «этажом выше». Давайте же изменим размер файловой системы. Делается это командной resize2fs (для ext2/ext3/ext4) или resize_reiserfs для одноименной системы:

[root@localhost ~]# resize2fs /dev/fileserver/samba

resize2fs 1.41.5 (23-Apr-2009)

Filesystem at /dev/fileserver/samba is mounted on /mnt/data; on-line resizing required

old desc_blocks = 2, new_desc_blocks = 2

Performing an on-line resize of /dev/fileserver/samba to 512000 (1k) blocks.

The filesystem on /dev/fileserver/samba is now 512000 blocks long.

Теперь все правильно:

[root@localhost ~]# df -h

Filesystem Size Used Avail Use% Mounted on

...

/dev/mapper/fileserver-samba

485M 11M 450M 3% /mnt/data

Обратите внимание, что все показанное производилось на смонтированной файловой системе. То есть, все операции не требуют остановки серверов, приостановки работы пользователей и т. п.

Уменьшение логических томов

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

ВНИМАНИЕ!

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

Делается это все так:

1. Размонтируем файловую систему: umount /dev/fileserver/samba

2. Уменьшаем размер файловой системы. Для этого сначала сделаем проверку самой файловой системы. Утилита resize2fs не даст изменить размер до выполнения проверки. Конечно, у нее есть ключ -f, который заставит ее это сделать, но лучше перестраховаться и все-таки выполнить проверку:

[root@localhost ~]# fsck.ext4 -f /dev/fileserver/samba

e2fsck 1.41.5 (23-Apr-2009)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/fileserver/samba: 11/127512 files (0.0% non-contiguous), 26603/512000 blocks

[root@localhost ~]# resize2fs /dev/fileserver/samba 300M

resize2fs 1.41.5 (23-Apr-2009)

Resizing the filesystem on /dev/fileserver/samba to 307200 (1k) blocks.

The filesystem on /dev/fileserver/samba is now 307200 blocks long

3. Только после корректного выполнения двух предыдущих шагов уменьшаем размер логического тома:

[root@localhost ~]# lvreduce -L 300M /dev/fileserver/samba

WARNING: Reducing active logical volume to 300.00 MB

THIS MAY DESTROY YOUR DATA (filesystem etc.)

Do you really want to reduce samba? [y/n]: y

Reducing logical volume samba to 300.00 MB

Logical volume samba successfully resized

В качестве размера тома (ключ -L), как и в случае с lvextend можно указывать и абсолютные и относительные единицы. Здесь мы также видим страшное предупреждение о потере данных. Несмотря на это (если вы не используете тестовые версии программ), ваши данные будут в целости и сохранности (скорее всего :) , 100% гарантии вам все равно никто не даст).

После этого монтируем файловую систему и смотрим что поменялось:

[root@localhost ~]# mount /dev/fileserver/samba /mnt/data/

[root@localhost ~]# df -h

Filesystem Size Used Avail Use% Mounted on

...

/dev/mapper/fileserver-samba

291M 11M 266M 4% /mnt/data

Итак, если вы все делаете в указанной последовательности, вашим данным скорее всего ничего не грозит. Но лучше перед уменьшением тома все-таки сделать его резервную копию. Я сам многократно уменьшал физические тома без каких-либо потерь данных, но наличие резервной копии - это наличие резервной копии :).

Увеличение и уменьшение группы томов

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

Давайте вернемся к нашему примеру. Допустим нам перестало хватать места в нашей группе томов и мы ее хотим дополнить новыми физическими томами. Делается это командой vgextend:

[root@localhost ~]# vgextend fileserver /dev/sdb6

Volume group "fileserver" successfully extended

[root@localhost ~]# vgdisplay fileserver

--- Volume group ---

VG Name fileserver

System ID

Format lvm2

Metadata Areas 3

Metadata Sequence No 5

VG Access read/write

VG Status resizable

MAX LV 0

Cur LV 1

Open LV 1

Max PV 0

Cur PV 3

Act PV 3

VG Size 1.99 GB

PE Size 4.00 MB

Total PE 510

Alloc PE / Size 75 / 300.00 MB

Free PE / Size 435 / 1.70 GB

VG UUID SZLgLK-b9V8-RiZV-gH5i-N0pA-2ppf-axLqfO

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

Следующая операция, которую тоже можно делать с LVM - это уменьшение группы томов. Прежде чем вывести физический том из группы - его необходимо освободить от данных. Первое, что тут следует сделать в данном случае - это убедиться, что дискового пространства, которое останется в группе, хватит для размещения этих данных. Разработчики LVM пока не владеют методами размещения данных в астральном пространстве, но работа над этим ведется :). Итак, посмотреть это можно командой pvscan:

[root@localhost ~]# pvscan

PV /dev/sdb1 VG fileserver lvm2 [476.00 MB / 176.00 MB free]

PV /dev/sdb5 VG fileserver lvm2 [476.00 MB / 476.00 MB free]

PV /dev/sdb6 VG fileserver lvm2 [1.06 GB / 1.06 GB free]

Здесь мы видим, что реально сейчас используется только первый физический том - /dev/sdb1. И еще мы тут видим один интересный аспект работы LVM: если какой-то логический том можно разместить на отдельном физическом целиком - LVM выберет именно этот путь.

Кстати, под словом free команда pvscan подразумевает не свободное от данных пространство, а пространство не выделенное в логические тома.

Итак, для освобождения физических томов от данных и размещения их на других физических томах той же группы есть команда pvmove:

[root@localhost ~]# pvmove /dev/sdb1

/dev/sdb1: Moved: 100.0%

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

Вывод команды pvscan теперь выглядит вот так:

[root@localhost ~]# pvscan

PV /dev/sdb1 VG fileserver lvm2 [476.00 MB / 476.00 MB free]

PV /dev/sdb5 VG fileserver lvm2 [476.00 MB / 476.00 MB free]

PV /dev/sdb6 VG fileserver lvm2 [1.06 GB / 788.00 MB free]

Как мы видим, теперь наш логический том «уехал» на другой раздел диска. Причем этот том смонтирован и с ним в этот момент могут работать пользователи.

Убрать освобожденный том из группы можно командой vgreduce:

[root@localhost ~]# vgreduce fileserver /dev/sdb1

Removed "/dev/sdb1" from volume group "fileserver"

[root@localhost ~]# pvscan

PV /dev/sdb5 VG fileserver lvm2 [476.00 MB / 476.00 MB free]

PV /dev/sdb6 VG fileserver lvm2 [1.06 GB / 788.00 MB free]

PV /dev/sdb1 lvm2 [478.47 MB]

Теперь мы видим, что наш физический том /dev/sdb1 «осиротел» и больше не принадлежит ни одной группе.

Снапшоты/Снимки

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

Сферы применения снапшотов могут быть самыми разнообразными. Например, резервное копирование базы данных. Если не использовать LVM - базу данных необходимо останавливать, копировать ее файлы куда-нибудь для последующего резервного копирования, а затем запускать ее заново. То есть делать это придется в нерабочее время. С LVM все проще - следует сделать снимок раздела с файлами базы данных и уже можно начинать делать резервную копию. Остановка базы данных не нужна.

Самая интересная особенность LVM при работе со снимками - это то, что снимок может занимать меньше дискового пространства, чем оригинал. Для этого используется режим Copy-on-Write, при котором реальное использование дискового пространства начинается только при изменении данных на томе-оригинале. То есть при попытке модификации файла на томе-оригинале неизмененный файл сначала сохраняется на томе-снимке, а уж затем модифицируется.

ВНИМАНИЕ! При заполнении тома-снимка до конца, происходит его уничтожение. То есть том продолжает существовать, но ни смонтировать его, ни просмотреть его содержимое (если он был смонтирован до этого) уже не получится. Эту особенность следует обязательно учитывать при задании размера тома-снимка в момент его создания.

Создание снимка делается хорошо известной командой lvcreate:

[root@localhost ~]# lvcreate -s -L 100M -n backup /dev/fileserver/samba

Logical volume "backup" created

Ключ -s указывает, что создаем мы именно снапшот, -n указывает имя создаваемого тома, а /dev/fileserver/samba показывает с какого именно тома мы делаем снимок.

Команда lvscan покажет нам, что мы создали снапшот:

[root@localhost ~]# lvscan

ACTIVE Original '/dev/fileserver/samba' [300.00 MB] inherit

ACTIVE Snapshot '/dev/fileserver/backup' [100.00 MB] inherit

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

Полезные советы для работы с LVM

1. В руководстве по администрированию RHEL встретился один замечательный совет. При использовании LVM не следует стараться распределить все имеющееся дисковое пространство в логические тома. Гораздо лучше другой путь. При распределении дискового пространства следует сделать это по своему опыту, ориентируясь на минимально необходимые потребности пользователей системы или работающих сервисов. Оставшееся в группе пространство будет «горячим» резервом, который администратор сможет добавить при нехватке места. Как было видно выше - добавление дискового простраства (увеличение логических томов) операция легкая и быстрая, в отличие от уменьшения.

Полезные источники (которые было бы неплохо посмотреть):

Сайт Xgu.ru

RHEL6 Logical_Volume_Manager_Administration

Краткое введение в программирование на Bash - часть II

2010-12-02T13:05:00.003+03:00

Выкладываю перевод второй часть статьи про введение в программирование на bash, начатое здесь.

В своей второй статье Гарольд продолжает свое первоклассное введение в программирование на bash. На этот раз он объясняет, как выполнять арифметические операции в скриптах bash, как определить функции в своих программах. Завершается статья введением в такие продвинутые вещи как чтение пользовательского ввода, обработка скриптом аргументов, перехватывание сигналов и обработка кодов завершения программ.

Безусловно, результаты прочтения превзойдут все ожидания! После этой статьи вас уже нельзя будет назвать новичком. Ведь вы на пути к тому, чтоб называться мастером программирования на bash!

Арифметика и bash

bash позволяет выполнять арифметические операции. Как вы уже видели в предыдущей статье, арифметика выполняется с помощью команды expr. Однако, подобно команде true, этот вариант считается медленным. Причина кроется в том, что для использования true и expr оболочка должна предварительно запустить их. Лучше всего использовать встроенную в bash функцию, которая работает быстрее. Аналогично тому, что альтернативой true является команда ":", альтернатива expr - заключение арифметического выражения в конструкцию вида $((...)). Будьте внимательны, она отличается от $(...). Отличие тут в количестве скобок. Так давайте же испробуем это:

#!/bin/bash
x=8 # присваиваем x значение 8
y=4 # присваиваем y значение 4

# результат сложения x и y сохраняем в z:
z=$(($x + $y))
echo «Сумма $x и $y равна $z»

Как обычно, выбор используемого метода вычислений за вами. Если использование expr для вас более комфортно и привычнее, чем $((…)), используйте его.

bash умеет выполнять сложение, вычитание, умножение, целочисленное деление и получение остатка от деления. Каждое арифметическое действие имеет соответствующий ему оператор:

Действие	Оператор
Сложение	+
Вычитание	-
Умножение	*
Целочисленное деление	/
Остаток от деления	%

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

#!/bin/bash
x=5 # устанавливаем x равным 5
y=3 # устанавливаем y равным 3

# сохраняем сумму x и y в переменную add
add=$(($x + $y))

# сохраняем разность x и y в переменную sub

sub=$(($x – $y))

# умножаем x на y и сохраняем результат в переменную mul
mul=$(($x * $y))

# в переменную div сохраняем результат деления x на y

div=$(($x / $y))

# получаем остаток от деления x на y и сохраняем его в переменную mod
mod=$(($x % $y))

# печатаем ответы
echo «Сумма равна: $add»
echo «Разность равна $sub»
echo «Произведение равно $mul»
echo «Результат деления $div»
echo «Остаток от деления $mod»

Код, приведенный выше, можно было бы написать с использованием expr. Например, вместо add=$(($x + $y)) мы могли бы использовать add=$(expr $x + $y) или add=`expr $x + $y`.

Чтение ввода пользователя

А теперь - самое интересное. Мы напишем свой скрипт так, что он будет взаимодействовать с пользователем, а пользователь с ним. Команда для получения данных от пользователя - read. Это встроенная в bash команда, сохраняющая ввод пользователя в указанной переменной:

#!/bin/bash
# спросить у пользователя его имя и поздороваться с ним
echo -n “Введите свое имя: ”
read user_name
echo “Привет $user_name!”

Переменная здесь - это user_name. Конечно, мы могли бы назвать ее как угодно. read прервет выполнение скрипта и будет ждать, пока пользователь введет что-нибудь и нажмет клавишу ENTER. Если клавиша ENTER была нажата без ввода чего-либо, read запустит следующую строку кода. Попробуйте это сделать. Ниже приведен тот же пример, только на этот раз мы

проверяем, вводит ли пользователь что-либо:

#!/bin/bash
# спрашиваем имя пользователя и выводим приветствие
echo -n «Введите имя: »
read user_name

# проверка ввода пользователя
if [ -z «$user_name» ]; then
echo «Вы не сказали мне свое имя!»
exit
fi
echo «Привет $user_name!»

В приведенном примере, если пользователь нажал ENTER и не ввел при этом ничего, наша программа напишет об этом и завершит свою работу. В противном случае она напечатает приветствие. Получение пользовательского ввода полезно для интерактивных программ, которые требуют от пользователя ввести какие-то данные.

Функции

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

#!/bin/bash
# функция hello() печатает сообщение

hello()
{
echo «Вы находитесь в функции hello()»
}

echo «Вызываем функцию hello()…»
hello

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

hello

Когда запускается эта строка, bash ищет скрипт для строки hello(). Он находит его в начале файла и выполняет его содержимое. Функции всегда вызываются по своему имени, что мы и видели выше. При написании функции вы можете обьявить ее, просто указав имя_функции(), как это сделано выше, или если вы хотите сделать ее объявление более явным, можете объявить ее так: function имя_функции(). Ниже представлен альтернативный способ написания функции hello() :

function hello()
{
echo «Вы находитесь в функции hello()»
}

Функции имеют в имени пустые открывающую и закрывающую скобки: "()", за ними следует пара фигурных скобок: «{...}», содержащих тело функции. Другими словами, весь код функции заключен в эти фигурные скобки. Функции всегда должны быть предварительно объявлены до своего вызова. Давайте попробуем в приведенном выше примере вызвать функцию до ее объявления:

#!/bin/bash
echo «Вызов функции hello() …»
hello
# функция hello() просто выводит сообщение
hello()
{
echo «Вы находитесь в функции привет ()»
}

Вот что мы получим, когда попытаемся запустить этот скрипт:

$ ./hello.sh
Вызов функции привет () ...
./hello.sh: hello: command not found

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

#!/bin/bash
# admin.sh – инструмент для администратора

# функция new_user () создает новую учетную запись пользователя
new_user()
{
echo «Подготовка к созданию новых пользователей ...»
sleep 2

# запускаем программу adduser
adduser
}

echo «1. Добавить пользователя»
echo «2. Выход»

echo «Укажите, что вы хотите сделать:"
read choice
case $choice in
1) new_user # вызов функции new_user()
;;
*) exit
;;
esac

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

Перехват сигналов

Вы можете использовать встроенную в bash программу trap для перехвата сигналов в своих программах. Это хороший способ изящно завершать работу программы. Например, если пользователь, когда ваша программа работает, нажмет CTRL-C - программе будет отправлен сигнал interrupt (SIGINT, signal (7)), который завершит ее. trap позволит вам перехватить этот сигнал, что даст возможность либо продолжить выполнение программы, либо сообщить пользователю, что программа завершает работу. Синтаксис этой команды такой:

trap action signal

Здесь:

action - то, что вы хотите делать, когда сигнал получен;

signal - сигнал, на который стоит реагировать.

Список сигналов можно посмотреть с помощью команды trap -l . При указании сигналов в своих скриптах можно опустить первые три буквы названия сигнала, т. е. SIG. Например, сигнал прерывания это - SIGINT. В вашем скрипте, в качестве его имени, можно указать просто INT. Вы также можете использовать номер сигнала, указанный рядом с его именем. Например, числовое значение сигнала SIGINT - 2. Попробуйте написать и запустить приведенный ниже пример:

#!/bin/bash
# использование команды trap

# перехватываем нажатие CTRL-C и запускаем функцию sorry()

trap sorry INT

# function sorry() prints a message
sorry()
{
echo «Извини меня, Дэйв. Я не могу этого сделать»
sleep 3
}

# обратный отсчет от 10 до 1:

echo «Подготовка к уничтожению системы»
for i in 10 9 8 7 6 5 4 3 2 1; do
echo «Осталось $i секунд до уничтожения...»
sleep 1
done
echo «Запуск программы уничтожения!»

Наберите и запустите приведенный пример. Когда программа будет работать и вести обратный отсчет, нажмите CTRL-C. Это действие отправит программе сигнал прерывания - SIGINT. Тем не менее сигнал будет перехвачен командой trap, которая, в свою очередь, выполнит функцию sorry(). Вы можете заставить trap игнорировать сигнал, указав символ кавычек вместо указания действия. Также вы можете отключить ловушку с помощью тире: "-". Например:

# запускать функцию sorry(), если получен сигнал SIGINT
trap sorry INT

# отключение ловушки
trap – INT

# ничего не делать при получении сигнала SIGINT
trap ” INT

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

Логические И и ИЛИ

Вы уже видели, что такое управляющие структуры и как их использовать. Для решения тех же задач есть еще два способа. Это логическое И - "&&" и логическое "ИЛИ" - « || ». Логическое И используется следующим образом:

выражение_1 && выражение_2

Сначала выполняется выражение, стоящее слева, если оно истинно, выполняется выражение, стоящее справа. Если выражение_1 возвращает ЛОЖЬ, то выражение_2 не будет выполнено. Если оба выражения возвращают ИСТИНУ, выполняется следующий набор команд. Если какое-либо из выражений не истинно, приведенное выражение считает ложным в целом. Другими словами, все работает так:

если выражение_1 истинно И выражение_2 истинно, тогда выполнять...

Примечание переводчика: При работе с булевыми переменными ИСТИНА и ЛОЖЬ (True и False), bash ведет себя отлично от других языков программирования. В других языках 0 соответствует False (Ложь), а 1 - True (Истина). В bash все наоборот. Связано это с такой вещью, как коды завершения программ (см. ниже).

Об этом следует всегда помнить при написании своих скриптов!

Пример использования:

#!/bin/bash
x=5
y=10
if [ "$x" -eq 5 ] && [ "$y" -eq 10 ]; then
echo «Оба условия верны»
else
echo «Условия не верны»
fi

Здесь мы находим, что переменные х и у содержат именно те значения, которые мы проверям, поэтому проверяемые условия верны. Если вы измените значение с х = 5 на х = 12, а затем снова запустите программу, она выдаст фразу «Условия не верны».

Логическое ИЛИ используется аналогичным образом. Разница лишь в том, что оно проверяет ошибочность выражения слева. Если это так - оно начинает выполнять следующий оператор:

выражение_1 || выражение_2

Данное выражение в псевдокоде выглядит так:

если выражение_1 истинно ИЛИ выражение_2 истинно, выполняем ...

Таким образом, любой последующий код будет выполняться, если хотя бы одно из выражений истинно:

#!/bin/bash
x=3
y=2
if [ "$x" -eq 5 ] || [ "$y" -eq 2 ]; then
echo «Одно из условий истинно»
else
echo «Ни одно из условий не является истинным»
fi

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

Аналогичная реализация условия с помощью оператора if будет большего размера, чем вариант с использованием логического И и ИЛИ, поскольку потребует дополнительного вложенного if. Ниже приведен код, реализующий тот же функционал, но с использованием оператора if:

#!/bin/bash
x=5
y=10
if [ "$x" -eq 5 ]; then
if [ "$y" -eq 10 ]; then
echo «Оба условия верны»
else
echo «Оба условия неверны»
fi
fi

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

Использование аргументов

Возможно, вы уже заметили, что большинство программ в Linux не интерактивны. Вы должны указать им какие-то параметры, в противном случае вы получите сообщение со списком возможных аргументов. Возьмем, к примеру, команду more. Если вы не укажете имя файла, она выдаст краткую справку по использованию программы. Ну и конечно же возможно сделать так, чтобы ваши скрипты также могли принимать аргументы. Для этого вам нужно знать что такое переменная вида $#. В ней содержится общее количество аргументов, переданных программе. Например, если вы запустите программу следующим образом:

$ что-то параметр

то значение переменной $# будет равно единице, потому что программе передан только один аргумент. Для двух аргументов ее значение будет равно двум и так далее. Также стоит знать о том, что каждый параметр командной строки (включая даже имя скрипта!!!) может также сохраняться в соответствующие переменные. Так, имя нашей программы что-то будет сохранено в переменной $0. Аргумент программы параметр сохранится в переменной $1. Вы можете использовать до 9 переменных, начиная с $0 (обозначающего имя скрипта), а затем $1-$9, обозначающие аргументы програмы. Давайте посмотрим, как это работает:

#!/bin/bash
# скрипт, печатающий свои аргументы
# проверяем, переданы ли скрипту аргументы:

if [ "$#" -ne 1 ]; then
echo «корректный запуск программы: $0 <параметр>»
fi

echo «Переданный параметр - $1»

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

Работа с временными файлами

Довольно часто вам будет необходимо создавать временные файлы. Обычно это файл, в котором хранятся какие-то используемые скриптом данные либо что-то еще. Как только работа скрипта будет завершена, этот файл нужно удалить. При создании такого файла вы должны задать его имя. Проблема тут кроется в том, что файл, создаваемый вами, не должен случайно переписать уже существующий в той же директории, если их имена совпадут. Для того чтобы создать временный файл с гарантированно уникальным именем, вам нужно использовать символ «$$» символ, либо как префикс, либо как суффикс к имени создаваемого файла. Предположим, вы хотите создать временный файл с именем hello. Возможно, что у пользователя, который работает с нашим скриптом, уже есть файл с таким именем. Создавая файл с именем hello.$$ или $$hello, вы создадите файл с уникальным именем. Например:

$ touch hello
$ ls
hello

$ touch hello.$$
$ ls
hello hello.689

Примерно так и будет выглядеть имя вашего временного файла.

Примечание переводчика: В переменной $$ обычно хранится следующий свободный PID. Именно поэтому использование такой переменной гарантирует уникальные имена для вновь создаваемых файлов.

Коды завершения программ

Большинство программ возвращают в операционную систему какое-то число, показывающее, насколько удачно программа завершила свою работу. Например, man-страница grep говорит, что grep вернет 0, если заданный шаблон найден, и 1, если совпадений не найдено. Почему нас так волнуют эти коды завершения? По разным причинам. Допустим, мы хотим проверить - есть ли пользователь с данным именем в системе? Один из способов сделать - использовать команду вида: grep имя_пользователя /etc/passwd . Допустим, имя пользователя - vasya:

$ grep vasya /etc/passwd
$

Ничего не вывелось. Это означает, что grep не обнаружила заданного пользователя. Но для нас было бы значительно лучше получить сообщение об этом. Это как раз тот случай, когда нужно использовать код завершения программы. Он сохраняется в переменной с именем $? . Посмотрим на следующий фрагмент кода:

#!/bin/bash
# ищем пользователя vasya в /etc/passwd,

# весь вывод перенаправляем в /dev/null

grep vasya /etc/passwd > /dev/null 2>&1

# смотрим код завершения и действуем по обстоятельствам:
if [ "$? -eq 0 ]; then
echo «Пользователь vasya найден»
exit
else
echo «Пользователь vasya не найден»
fi

Теперь, когда вы запустите скрипт, он будет перехватывать и анализировать код завершения grep. Если он равен 0, значит пользователь найден и мы выводим соответствующее сообщение об ошибке. В противном случае скрипт напечатает, что пользователя найти не получилось. Это очень простой способ использования получаемого кода завершения программы. По мере практики вы сами будете понимать, для решения какой задачи вам нужно использовать эти коды завершения.

Если вас озадачивает конструкция вида 2>&1, тут все довольно просто. В Linux этими числами обозначаются дескрипторы файлов. 0 - стандартный ввод (по умолчанию, клавиатура), 1 стандартный вывод (по умолчанию, монитор) и 2 - вывод стандартных ошибок (по умолчанию, монитор). Весь вывод команды идет в файл с дескриптором 1, любые ошибки отправляются в файл с дескриптором 2. Если вы не хотите, чтобы сообщения об ошибках появлялись на экране, просто перенаправьте его в /dev/null. Но это не прекратит вывод на экран обычной информации. Например, если у вас нет разрешения на чтение домашнего каталого другого пользователя, вы не сможете просмотреть список его содержимого:

$ ls /root
ls: /root: Permission denied

$ ls /root 2> /dev/null
$

Как видите, во второй раз информация об ошибке не была напечатана. Все то же самое относится к другим программам и дескриптору 1. Если вы не хотите видеть нормальный выход из программы, то есть хотите, чтобы она работала молча, вы можете перенаправить в /dev/null и его. Теперь, если вы не хотите видеть вообще никакого вывода программы - добавьте в нее следующее:

$ ls /root > /dev/null 2>&1

Это означает, что программа будет отправлять свой вывод и ошибки, которые возникают в /dev/null, т. е. будет работать молча, что нам и нужно.

Примечание переводчика: на самом деле все работает так:

Конструкция вида 2>&1 перенаправляет вывод ошибок (дескриптор 2) на стандартный вывод (дескриптор 1). Знак «загогулины» - & - тут нужен для того, чтобы пояснить bash, что вы имеете в виду не файл с именем 1, а именно файл с дескриптором 1, т. е. стандартный вывод. Если вы укажете что-то вроде:

$ команда 2>1

то стандартный вывод ошибок пойдет в файл с именем 1. Конструкцией 2>&1 мы «сцепляем» вывод команды и вывод ошибок вместе. А первым перенаправлением (первым символом > в коментируемой команде) мы отправляем весь вывод команды в /dev/null. Чтобы дополнительно понять, как все работает, можете поэкспериментировать, убрав 2>&1 из команды и перезапустив ее.

А что если вы хотите, чтобы ваш скрипт тоже возвращал какой-нибудь код завершения при выходе? Команда exit может принимать один аргумент - тот самый код завершения. Обычно число 0 используется для обозначения успешного завершения работы. Число, отличное от нуля означает, что произошла какая-то ошибка. Какое число возвращать - решает сам програмист. Посмотрим приведенный пример:

#!/bin/bash
if [ -f "/etc/passwd" ]; then
echo «Файл passwd существует»
exit 0
else
echo «Нет такого файла»
exit 1
fi

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

Переносимость ваших скриптов на bash

При написании ваших собственных скриптов важно делать это так, чтобы они оставались переносимыми. Термин «переносимость» означает, что если ваш скрипт работает под Linux, то он должен работать в другой Unix-системе с малыми изменениями или вообще без них. Чтобы добиться этого, вы должны быть осторожны при вызове внешних программ. Разработчик должен при этом ответить на вопрос: "Будет ли эта программа доступна на другом варианте Unix?" (и что более важно - будет ли она там работать также, как на Linux - прим. перев.). Допустим, вы используете программу foo, которая на Linux работает аналогично echo, поэтому вместо echo вы используете ее. Но если ваш скрипт будет работать на других системах, где нет программы foo, он начнет выдавать сообщения об ошибках. Кроме того, имейте в виду, что разные версии bash могут иметь разные методы для одних и тех же операций. Например, конструкция VAR = $(ps) делает то же самое, что и VAR = `ps`, но на самом деле старые версии оболочек, например Bourne shell (sh), признают только последний синтаксис. Если вы собираетесь распространять свои скрипты, обязательно включайте текстовый файл README, который будет предупреждать пользователя о любых сюрпризах, в том числе и о том, что скрипт проверялся на такой-то версии bash. Желательно также указать, какие программы и библиотеки (и каких версий) будут нужны скрипту.

Примечание переводчика: Для проверки наличия в скрипте команд и функций специфичных для bash в ALT Linux есть пакет checkbashisms, который взят из пакета devscripts Debian.

Заключение

Пришла пора завершить это краткое введение в написание скриптов на bash. Однако ваше обучение этому умению еще не завершено. В тоже время, написанного вполне достаточно, чтобы вы могли модифицировать имеющиеся скрипты и писать собственные. Если вы действительно хотите стать мастером написания скриптов на bash, я рекомендую приобрести книгу «Learning the bash shell» (Изучение оболочки bash), 2-е издание издательства O'Reilly & Associates, Inc.

Скрипты на bash идеально подходят для повседневной работы по администрированию. Но если вы планируете что-то более серьезное, следует использовать гораздо более мощный язык, такой как C или Perl. Удачи!

Ссылка на оригинал

Также опубликована здесь

Краткое введение в программирование на Bash - часть I

2010-10-11T20:35:00.007+04:00

Данное введение в программирование на bash прельстило меня своей краткостью и содержательностью. В то же время я изменил некоторые примеры, потому что они делали слегка не то, что ожидается новичками. Начинающим текст будет полезен как отправная точка для начала написания скриптов. Опытным - как справочник. Удачного чтения!
Выражаю также благодарность Владимиру Черному (начальнику отдела образовательных проектов ALT Linux) за внесенные в текст правки.

Тема программирования на bash из разряда тех, которые могут быть рассмотрены и в пару, и в сотни страниц. Гарольд Родригес (Harold Rodriguez) объясняет эту тему в приведенном ниже руководстве из двух частей. Его прекрасный и яркий стиль позволил ему охватить все существенные черты программирования на bash буквально на нескольких страницах.

Если вы никогда не программировали на bash ранее - сейчас самое время начать. Даже если у вас мало знаний о том, что такое bash, вы вполне можете посмотреть на множество интересных скриптов, разбираемых Гарольдом.

Введение

Подобно остальным оболочкам, доступным в Linux, Bourne Again shell (bash) является не только, собственно, командной оболочкой, но и языком для написания сценариев (скриптов) (слова «сценарий» и «скрипт» обычно являются синонимами - прим. перев.). Скрипты позволяют в полной мере использовать возможности оболочки и автоматизировать множество задач, которые иначе потребуют для своего выполнения ввода множества команд. Многие программы, работающие внутри вашего компьютера с Linux - это скрипты. Если вы захотите узнать, как они работают, или изменить их, важно понимать их синтаксис и семантику. Кроме того, понимая язык bash, вы сможете писать свои собственные программы, чтобы выполнять разные задачи теми способами, которые выберете сами.

Так все-таки программирование (programming) или написание скриптов (scripting)?

Новичков в программировании, как правило, озадачивает разница между, собственно, программированием и языками скриптов. Программы, написанные на каких-то языках программирования, обычно гораздо более мощные по возможностям и работают намного быстрее, чем программы, написанные на языках сценариев. Примеры языков программирования - C, C ++ и Java. Создание программы на каком-либо языке программирования обычно начинается с написания исходного кода (текстовый файл, содержащий инструкции о том, как будет работать окончательная программа), затем его необходимо скомпилировать (собрать) в исполняемый файл. Этот исполняемый файл не так легко переносить между различными операционными системами. Например, если вы напишете на программу на C для Linux, вы не сможете запустить ее в Windows. Чтобы сделать это, вам придется перекомпилировать исходный код под Windows. Написание скрипта также начинается с написания исходного кода, который не компилируется в исполняемый файл. Вместо этого интерпретатор оболочки последовательно читает инструкции в файле исходного кода и выполняет их. К сожалению, поскольку интерпретатор должен читать каждую инструкцию, скорость исполнения скрипта обычно медленнее (намного медленнее - прим. перев.), чем у скомпилированной программы. Основным преимуществом скриптов является то, что вы можете легко переносить исходный файл в любую операционную систему и просто запускать их (естественно при наличии интерпретатора для этой операционной системы - прим. перев.).

Bash - это язык сценариев. Он отлично подходит для написания небольших программ, но если вы планируете делать какие-то мощные приложения, выбор для этого какого-либо языка программирования предпочтительнее для вас. Другие примеры скриптовых языков Perl, Lisp, и Tcl.

Что нужно знать для написания своих скриптов?

Для этого необходимо знание основных команд Linux. Например, вы должны знать, как копировать, перемещать и создавать новые файлы. Обязательно умение использовать какой-либо текстовый редактор. Существуют три основных текстовых редактора в Linux: vi, emacs и pico (автор еще забыл nano, который лучше всего подходит начинающим, если не учитывать еще и mcedit. - Прим. перев.). Если вы не знакомы с vi или emacs, используйте pico или другой простой в использовании текстовый редактор.

Внимание!!!

Не следует учиться программировать на bash из-под пользователя root! В противном случае - может случиться все что угодно! Я не буду нести никакой ответственности, если вы случайно допустите ошибку и испортите вашу систему. Вы предупреждены! Используйте учетную запись обычного пользователя без каких-либо привилегий. Вы можете даже создать нового пользователя только для обучения написанию сценариев. Таким образом, худшее, что произойдет в данном случае — это исчезновение данных в каталоге этого пользователя.

Ваша первая программа на Bash

Нашей первой программой будет классическая «Hello World». Конечно, если уже вы программировали раньше, вы должно быть устали от таких примеров. Однако это - традиция и кто я такой, чтобы менять ее? Программа «Hello World» просто выводит слова «Hello World» на экран. Запустите текстовый редактор и наберите в нем следующее:

#!/bin/bash
echo "Hello World"

Первая строка сообщает Linux использовать интерпретатор bash для запуска этого скрипта. В этом случае, bash находится в каталоге /bin. Если у вас bash находится где-то еще, сделайте соответствующие изменения в данной строке. Явное указание интерпретатора очень важно, удостоверьтесь еще раз, что указали его, поскольку данная строка говорит Linux какой именно интерпретатор нужно использовать для выполнения инструкций в скрипте. Следующее, что нужно сделать, это сохранить скрипт. Назовем его hello.sh. После этого вам нужно сделать скрипт исполняемым:

$ chmod u+x hello.sh

Если вы не понимаете, что делает эта команда, прочтите справочную страницу команды chmod:

$ man chmod

Как только это будет сделано, вы сможете запустить программу, просто набрав ее название:

$ ./hello.sh

Hello World

Получилось! Это ваша первая программа! И хотя она скучная и не делает ничего полезного, она показывает как именно все работает. Просто запомните эту простую последовательность действий: напишите код, сохраните файл, сделайте его исполняемым с помощью chmod и запустите.

Команды, команды и команды

Что именно делает ваша первая программа? Она печатает на экран слова «Hello World». Каким образом она это делает? Она использует команды. В нашей программе мы написали только одну команду - echo «Hello World». Что именно тут команда? echo. Эта программа принимает один аргумент и печатает его на экран.

Аргументом является все, что следует после ввода названия программы. В нашем случае «Hello World» это и есть аргумент, переданный команде echo. При вводе команды ls /home/, аргументом команды ls является /home. Ну и что это все означает? А означает это то, что если у вас есть программа, которая принимает какой-то аргумент и выводит что-то на экран, вы можете использовать ее вместо echo. Предположим, что у нас есть программа под названием foo. Эта программа будет принимать один аргумент (строку из слов) и печатать их на экран. Тогда мы можем переписать нашу программу вот так:

#!/bin/bash
foo "Hello World"

Сохраните ее, сделайте исполняемой и перезапустите ее (примечание для новичков - этот пример работать не будет. - Прим. перев.):

$ ./hello
Hello World

Точно такой же результат. Использовался ли тут какой-то уникальный код? Нет. Написали ли мы какую-то программу? Нет, если только вы не являетесь автором программы echo. Все, что вы сделали - просто встроили программу echo в наш скрипт и снабдили ее аргументом. Примером альтернативы использования команды echo в реальном программировании является команда printf, которая имеет больше возможностей, если вы знакомы с программированием на C. Ну и на самом деле, точно такой же результат можно было бы получить и без написания скрипта:

$ echo "Hello World”
Hello World

Написание скриптов на bash предлагает широкий спектр возможностей и этому легко научиться. Как вы только что могли видеть, вы используете другие команды Linux, чтобы писать ваши собственные скрипты. Ваша программа-оболочка представляет собой несколько других программ, собранных вместе для выполнения какой-либо задачи.

Другие полезные программы

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

$ touch file1

$ mkdir trash
$ mv file1 trash
$ rm -rf trash
$ mkdir trash

Вместо того, чтобы вводить это все в интерактивном режиме, напишем скрипт, выполняющий эти команды:

#!/bin/bash

touch file1
mkdir trash
mv file1 trash
rm -rf trash
mkdir trash
echo “Файл удален!”

Сохраните его под именем clean.sh и теперь все, что нужно сделать - это запустить его. Он переместит все файлы в каталог, удалит его, создаст его заново каталог и даже напечатает сообщение об удалении файлов. Запомните, если вы обнаружите, что регулярно делаете нечто требующее набора одной и той же последовательности команд - это вполне можно автоматизировать написанием скрипта.

Комментарии

Комментарии помогают сделать ваш код более читабельным. Они не влияют на то, что выводит программа. Они написаны специально для того, чтобы вы их прочли. Все комментарии в Bash начинаются с хэш-символа #, за исключением первой строки (#!/bin/bash), имеющей специальное назначение. Первая строка - не комментарий. Возьмем для примера следующий код:

#!/bin/bash
# Эта программа считает от 1 до 10:
for i in 1 2 3 4 5 6 7 8 9 10; do
echo $i
done

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

Переменные

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

#!/bin/bash
x=12
echo ”Значение переменной x - $x”

Здесь мы присвоили переменной x значение 12. Строка echo “Значение переменной х - $x” напечатает текущее значение x. При определении переменной не допускается наличие каких-то пробелов между именем переменной и оператором присваивания: "=". Синтаксис следующий:

имя_переменной=ее_значение.

Обращение к переменным выполняется с помощью префикса "$" перед именем переменной. Именно таким образом мы получаем доступ к значению переменной х с помощью команды echo $x.

Есть два типа переменных - локальные и переменные окружения. Переменные окружения устанавливаются системой и имеют специальной назначение. Обычно их значение может быть выведено с помощью команды echo. Например, если ввести:

$ echo $SHELL

/bin/bash

Вы получили имя оболочки, запущенной в данный момент. Переменные среды задаются в файле /etc/profile и в ~/.bash_profile. Команда echo может применяться для проверки текущего значения переменной.

Примечание: задание переменных среды подробно описано в этой статье - "Как задавать п еременные среды" . В статье также описаны некоторые особенности оболочки Bash.

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

#!/bin/bash
echo "Значение х - 12".
echo "У меня есть 12 карандашей".
echo "Он сказал мне, что значение х равно 12".
echo "Мне 12 лет."
echo "Как получилось, что значение х равно 12?"

Хорошо, теперь предположим, что вы решите поменять значение х на 8 вместо 12. Что для этого нужно сделать? Вы должны изменить все строки кода, в которых говорится, что х равно 12. Но погодите... Есть другие строки кода, где упоминается это число, поэтому простую автозамену использовать не получится. Теперь приведем аналогичный пример, только с использованием переменных:

#!/bin/bash
x=12 # задаем переменной х значение 12
echo "Значение х = $х"
echo "У меня есть 12 карандашей"
echo "Он сказал мне, что значение х равно $х"
echo "Мне 12 лет"

echo "Как получилось, что значение х равно $x?"

Здесь мы видим, что $x выводит текущее значение переменной х равное 12. Поэтому теперь, если вы хотите задать новое значение х равное 8, то все что вам нужно сделать, это изменить одну строчку с х=12 на х=8, и в выводе все строки с упоминанием x также изменяться. Поэтому вам не нужно руками модифицировать остальные строки. Как вы увидите позже, переменные имеют и другие способы применения.

Управляющие операторы

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

#!/bin/bash
cp /etc/foo .
echo ”Готово”

Это небольшой скрипт, назовем его bar.sh, копирует файл с именем /etc/foo в текущий каталог и выводит «Готово» на экране. Эта программа будет работать при одном условии - файл /etc/foo должен существовать. В противном случае вот что произойдет:

$./bar.sh
cp: /etc/foo: No such file or directory
Готово

Таким образом, как вы видите, есть проблема. Не у каждого, кто будет запускать вашу программу, будет файл /etc/foo. Наверное, было бы лучше, если б ваша программа сначала проверяла наличие данного файла, а затем при положительном ответе - выполняла бы копирование, в противном случае - просто бы завершала работу. В псевдо-коде это выглядит так:

если /etc/foo существует, то
скопировать /etc/foo в текущую директорию

напечатать "Готово" на экране
в противном случае,
напечатать на экране "Этот файл не существует"

выход

Можно ли это сделать в Bash? Конечно! Набор управляющих операторов Bash включает в себя: if, while, until, for и case. Каждый из этих операторов является парным, то есть начинается он одним тегом и заканчивается другим. Например, если условный оператор if начинается с if и заканчивается fi. Управляющие операторы - это не отдельные программы в системе, они встроены в bash.

if … else … elif … fi

Это один из наиболее распространенных операторов. Он позволяет программе принимать решения следующим образом - «если условие верно - делаем одно, если нет - делаем что-то другое». Чтобы эффективно его использовать, сначала нужно научиться пользоваться командой test. Эта программа выполняет проверку условия (например, существует ли файл, есть ли необходимые права доступа). Вот переписанный вариант bar.sh :

#!/bin/bash
if test -f /etc/foo
then
# Файл существует, копируем его и печатаем сообщение на экране
cp /etc/foo .
echo "Готово".
else # Файл не существует, поэтому мы печатаем сообщение

# и завершаем работу
echo "Этот файл не существует."
exit

Обратите внимание на отступы строки после then и else. Они не являются обязательными, но зато делают чтение кода гораздо более простым в том смысле, что делают логику программы более наглядной. Теперь запустите программу. Если у вас есть файл /etc/foo - он будет скопирован, в противном случае будет напечатано сообщение об ошибке. Команда test проверяет существование файла. Ключ -f проверяет, является ли аргумент обычным файлом. Ниже приведен список опций test (Не стоит пытаться запомнить их все, т.к. это все равно нереально. Его всегда можно посмотреть в руководстве команды test - man test. Прим. перев.):

Ключи команды test:

-d проверяет наличие файла и то, что он является каталогом

-e проверяет существование файла

-f проверяет наличие файла и то, что это обычный файл

-g проверяет наличие у файла SGID-бита

-r проверяет наличие файла и то, что он доступен на чтение

-s проверяет наличие файла и то, что его размер больше нуля

-u проверяет наличие у файла SUID-бита

-w проверяет наличие файла и то, что он доступен на запись

-x проверяет наличие файла и наличие у него прав на запуск

Оператор else используется, когда вы хотите, чтобы ваша программа еще что-то делала, если первое условие не выполняется. Существует также оператор elif, который может использоваться вместо еще одного if. elif означает "else if". Он используется, когда первое условие не выполняется, и вы хотите проверить еще одно условие.

Если вам не нравится приведенная форма записи if и test, есть сокращенный вариант.

Например, код:

if test -f /etc/foo
then

Можно записать вот так:

if [ -f /etc/foo ]; then

Квадратные скобки - это еще один вариант записи test. Если у вас есть опыт в программировании на C, этот синтаксис для вас может быть более удобным. Обратите внимание на наличие пробелов до и после каждой из скобок (Наличие пробелов объясняется просто: открывающая квадратная скобка - это команда оболочки. В этом можно легко убедиться набрав в консоли команду which [ . А раз это отдельная команда, то ее нужно отделить пробелами от остальных опций. - Прим. перев.). Точка с запятой: ";" говорит оболочке о завершении одного оператора и начале следующего. Все, что находится после этого символа будет работать так, как будто он находится на отдельной строке. Это делает код более удобным для чтения и, естественно, что такая запись необязательна. Если вы предпочитаете другой вариант записи - then можно сразу поместить в другой строке.

Если вы используете переменные - их нужно помещать в кавычки. Например:

if [ "$name" -eq 5 ]; then

оператор -eq будет объяснен далее в этой статье.

while … do … done

Оператор while используется для организации циклов. Он работает так «пока (while) условие истинно, делать что-то». Рассмотрим это на примере:

#!/bin/bash
while true; do
echo "Нажмите CTRL-C для выхода."
done

true - это тоже программа. Единственное, что она тут делает - это запускает тело цикла снова и снова. Использование true считается медленным, потому что ваш скрипт должен запускать ее раз за разом. Можно использовать альтернативный вариант:

#!/bin/bash
while :; do
echo "Нажмите CTRL-C для выхода."
done

Это позволяет добиться точно такого же эффекта, но быстрее, потому что «:» - это встроенная функция bash. Единственное отличие состоит в принесении в жертву читабельности кода. Используйте из приведенных вариантов тот, который вам нравится больше. Ниже приведен гораздо более полезный вариант использования переменных:

#!/bin/bash
x=0;
while [ "$x" -le 10 ]; do
echo "Текущее значение х: $ х"
# Увеличиваем значение х:
x=$(expr $x + 1)
sleep 1
done

Здесь мы используем для проверки состояния переменной x запись с квадратными скобками. Опция -le означает «меньше или равно (less or equal)». Говоря обычным языком приведенный код говорит: «пока (while) х меньше или равен 10, выводить на экран текущее значение х, после чего добавлять к текущему значению х единицу». Оператор sleep 1 приостанавливает выполнение программы на одну секунду.

Ниже приведен список возможных операций сравнения целых чисел (полный список приведен в man test. Прим. перев.):

x -eq y x = y (equal)

x -ne y x не равен y (not equal)

x -gt y x больше, либо равен y (greater than)

x -lt y x меньше, либо равен y (lesser than)

Операторы сравнения строк:

x = y строка x идентична y

x != y строка х не совпадает y

-n x выражение истинно, если строка х ненулевой длины

-z x выражение истинно, если строка х имеет нулевую длину

Скрипт, приведенный выше, нетрудно понять, за исключением, может быть, только этой строки:

x=$(expr $x + 1)

Комментарий приведенный выше он говорит нам, что он увеличивает х на 1. Но что означает запись $ (...)? Это переменная? Нет. На самом деле это способ сказать оболочке, что вы хотите запустить команду expr $x + 1, и присвоить результат ее выполнения - х. Любая команда, заключенная в $ (...) будет выполняться:

#!/bin/bash
me=$(whoami)
echo "Привет! Меня зовут $me"

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

#!/bin/bash
echo "Привет! Меня зовут $(whoami)"

Вы сами можете выбрать, какая из записей вам ближе и понятнее. Существует и другой способ для выполнения команд или передачи результата их выполнения переменной. Как это сделать - будет объяснено позже. Пока используйте запись вида $(...).

until … do … done

Оператор until применяет способом аналогичным приведенному выше while. Разница лишь в том, что условие работает наоборот. Цикл while выполняет до тех пор пока условие истинно. Цикл until - до тех пор пока условие не станет истинным. Например:

#!/bin/bash
x=0
until [ "$x" -ge 10 ]; do
echo "Текущее значение х равно $ х"
x=$(expr $x + 1)
sleep 1
done

Эта часть кода выглядит знакомой. Попробуйте ее набрать и посмотреть, что он делает. Приведенный цикл будет работать, пока x не станет больше или равен 10. Когда величина x достигнет значения 10, цикл остановится. Таким образом, последнее значение напечатанное значение х будет 9.

for … in … do … done

Цикл for используется, когда вам надо перебрать несколько значений переменной. Например, вы можете написать небольшую программу, которая печатает 10 точек:

#!/bin/bash
echo -n "Проверка системы на наличие ошибок"
for dots in 1 2 3 4 5 6 7 8 9 10; do
echo -n "."
done
echo "Ошибок не обнаружено"

Опция -n команды echo предотвращает автоматический перевод строки. Попробуйте один раз вариант с -n и вариант без этой опции, чтобы понять, что я имею в виду. Переменная dots последовательно принимает значения от 1 до 10 и одновременно скрипт печатает на экране точку.

Приведенный дальше пример показывает, что я имею в виду под выражением «переменная последовательно принимает несколько значений»:

#!/bin/bash
for x in paper pencil pen; do
echo "значение переменной х равно $х"
sleep 1
done

При запуске программы, вы видите, что х сначала имеет значение «pencil», а затем она принимает значение «pen». Когда у переменной заканчивается список возможных значений, цикл завершается.

Ниже приведен гораздо более полезный пример. Этот скрипт добавляет расширение .html для всех файлов в текущей директории (Этот скрипт реально так поступает и вам возможно это не нужно. Поэтому все-таки создайте отдельного пользователя, если вы еще до сих пор этого не сделали, и экспериментируйте под ним. - Прим. перев.):

#!/bin/bash
for file in *; do
echo "Добавляем расширение .html для файла $file ..."
mv $file $file.html
sleep 1
done

Символ * имеет специальное значение, которое в данном случае означает "все в текущем каталоге", т.е. - все файлы в каталоге. Переменная file последовательно принимает значения, соответствующие именам файлов в текущем каталоге. Затем используется программа mv для переименования файла в файл с расширением .html:

case … in … esac

Оператор case очень похож на if. Он отлично подходит для тех случаев, когда нужно проверить несколько условий, и вы не хотите для этого использовать несколько вложенных операторов if. Поясним на примере:

#!/bin/bash
x=5 # инициализируем х значением 5
# проверяем значение х:
case $x in
0) echo "значение х равно 0"
;;
5) echo "значение х равно 5"
;;
9) echo "значение х равно 9"
;;
*) echo "значение неизвестно"

;;
esac

Оператор case проверяет переменную х на равенство трем значениям. В приведенном примере, он сначала проверит, равен ли х нулю 0, затем равен ли он 5, затем равен ли он 9. И, если все проверки завершились неудачно, скрипт выведет сообщение, что значение x определить не получилось. Помните, что «*» означает «все», и в этом случае, «любое другое значение, помимо указанных явно». Если х имеет любое другое значение, отличное от 0, 5 или 9, то это значение попадает во категорию «*». При использовании сase каждое условие должно заканчиваться двумя точками с запятой.

Зачем нужно использовать case, когда вы можно использовать if? Ниже приведен пример эквивалентного скрипта, написанного с использованием if. Решение о том, что быстрее написать и легче прочесть, предлагается принять самостоятельно ;) :

#!/bin/bash
x=5 # инициализируем х значением 5
if [ "$x" -eq 0 ]; then
echo "Значение х равно 0"
elif [ "$x" -eq 5 ]; then
echo "значение х равно 5"
elif [ "$x" -eq 9 ]; then
echo "значение х равно 9"
else
echo "Значение х определить не удалось"
fi

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

Кавычки играют важную роль в написании скриптов оболочки. Существует три типа кавычек. Это двойные кавычки: ", одинарные ' (апостроф) и обратные ` (находятся слева от клавиши 1. Прим. перев.). Имеет ли каждый из приведенных видов какое-то особое значение? Да.

Примечание: Статья Wildcards, Quotes, Back Quotes, Apostrophes in shell commands ( * ? [] ” ' ') прекрасно описывает использование специальных символов. Пожалуйста, ознакомьтесь с ней в случае, если вы не знакомы с использованием этих специальных символов в скриптах оболочки. Ниже приведено краткое объяснение использования некоторых из них.

Двойные кавычки используются главным образом для объединения нескольких слов в строку и сохранения в ней пробелов. Например, "Эта строка содержит пробелы". Строка, заключенная в двойные кавычки рассматривается как единое целое. Например:

$ mkdir hello world
$ ls -F
hello/ world/

Здесь мы создали две директории. Команда mkdir принимает два слова hello и world, как два отдельных аргумента, и поэтому создает два каталога. Теперь посмотрим, а что произойдет, если написать код таким образом:

$ mkdir “hello world”
$ ls -F
hello/ hello world/ world/

Команда создала каталог с именем из двух слов. Кавычки объединили два слова в один аргумент.

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

Одинарные кавычки в основном используются для работы с переменными. Если переменная находится в двойных кавычках, то к ней можно обратиться через $имя_переменной.Если переменная находится в одинарных кавычках - это не возможно. Чтобы пояснить это приведем пример:

#!/bin/bash
x=5 # задаем х равным 5
# используем двойные кавычки
echo "Используем двойные кавычки, значение х равно $х"
# используем одинарные кавычки
echo 'Используем одинарные кавычки, значение х равно $х'

Почувствовали разницу? Вы можете использовать двойные кавычки, если вы не планируете использовать переменные для строки, которая в них находится. И да, если вам интересно, прямые кавычки также можно использовать для сохранения пробелов в строке тем же способом, что и двойные кавычки

$ mkdir 'hello world'
$ ls -F
hello world/

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

x=$(expr $x + 1)

Как вы уже знаете, результатом работы этой команды будет то, что выражение $х + 1 присваивается переменной x. Того же результата можно достичь и с использованием обратных кавычек:

x='expr $x + 1′

Какой тип кавычек лучше использовать? Тот, что вам больше нравится. Изучая скрипты вы найдете, что обратные кавычки используются чаще, чем запись $(...) . Тем не менее, я считаю, $ (...) легче читать, особенно если у вас код наподобие этого:

#!/bin/bash
echo “I am 'whoami'”

(На мой взгляд, лучше использовать именно запись типа $(...), потому что запись в обратных кавычках и одинарных можно легко перепутать при наборе кода и при его чтении. - Прим. перев.)

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

Оригинал статьи

Статья также опубликована здесь.

Поскреби Ubuntu, получишь Debian...

2010-09-22T22:00:00.001+04:00

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

Итак, берем Ubuntu Alternate CD, вставляем в диск и перезагружаемся. На всякий случай, я все свои эксперименты проводил в виртуалке в Virtualbox. В установщике выбираем режим экспертной установки и ставим только базовую систему. Можно еще в диалоге создания учетных записей разрешить учетную запись root. Меня в Ubuntu больше всего раздражает заблокированная учетка root и неправильно настроенная sudo. После перезагрузки входим в систему и ставим пакет gnome-desktop-environment. Те, кто использует Debian, наверняка знает, что этим метапакетом ставится GNOME.

Затем пускаем службу GDM и получаем вот такую картинку:

После входа в систему наблюдаем вот такой рабочий стол (обратите внимание на расположение кнопок окна):

А чтобы все программы, требующие административных привелегий в GNOME, спрашивали пароль root, а не пользовательский, делаем следующее. Запускаем в терминале gksu-properties и устанавливаем целых две настройки вот так:

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

Ну а тем, кто хочет восстановить статус-кво, нужно поставить пакет ubuntu-artwork. Получится в итоге вот такое:

Заметьте, что теперь кнопки переехали в левую часть заголовка...

Дальше с этой системой можно делать все, что угодно :) - доустановить нужные пакеты, оформление... Так что мы, практически, получаем почти Debian с более новыми пакетами.

Почему нам не нужен третий дистрибутив Linux

2010-09-21T23:07:00.002+04:00

Это мой перевод еще одной статьи из блога Novell о том, нужен ли рынку решений дистрибутив Linux от Oracle. Статья мне показалась интересной, хотя бы своим тоном по отношению к недавнему покупателю Sun. Ссылка на оригинал - в конце статьи.

Майкл Аппельбаум, директор по Linux-решениям

Хорошо известно, что Novell и Red Hat по-прежнему задают тон, когда речь идет о Linux для промышленных решений, но Oracle пытается прорекламировать новое решение на Linux, которым она надеется улучшить свое состояние на этом рынке. Изменят ли эти последние новости отношение этого рынка к Oracle? Эксперты с этим не согласны.

Лучше всего задаться таким вопросом: а нужен ли корпоративному рынку еще один дистрибутив Linux?

Когда дело доходит до корпоративных решений на Linux, Novell и Red Hat по-прежнему доминируют на рынке. В последних результатах, представленных IDC, Novell и Red Hat совместно получают 95% доходов от Linux, причем в прошлом году эта доля была 94%. Oracle же не достигла даже 1% о доходов рынка Linux. Несмотря на заявления Oracle о наличии тысяч клиентов по Linux-направлению, аналитикам еще предстоит увидеть ее хоть сколь-нибудь заметное влияние на рынок. Между тем, доля Novell здесь продолжает расти, увеличившись за последний год на 5 процентов с аналогичным снижением доли Red Hat.

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

Почему же есть только два успешных коммерческих поставщика Linux? Во-первых, для создания и поддержки Linux-дистрибутива корпоративного класса необходимо наличие хорошей инфраструктуры. Не так легко получить право на поддержку сертифицированных приложений, причем тут есть определенный элемент проблемы «курица-яйцо». Только Novell и Red Hat имеют каталог приложений, которые исчисляются тысячами, причем Novell опережает Red Hat по этому показателю в два раза и предлагает более 500 сертифицированных приложений Oracle. Предоставление поддержки корпоративного класса - сложное и дорогое занятие, хоть это и не препятствие для Oracle. И, чтобы сделать такие инструменты как SUSE Studio для развертывания приложений для облачных вычислений, требуются инновационное мышление и ресурсы. Другими словами, для входа на этот рынок есть реальные барьеры, даже если это рынок, которые может кое-кому показаться коммодитизированным (Это термин, который я решил не переводить. Самое нормальное объяснение ему я нашел здесь. Вот цитата оттуда: «Коммодитизация — то, что случается с продуктами, которые становятся достаточно дешёвыми в массовом производстве, и вместо одного уникального товара возникает море из торговых марок. Различий в потребительских качествах между разными брендами не остаётся, так что прежние звёзды теряют при этом свою уникальность. «Компьютер станет также распространён, как микроволновая печь» — это коммодитизация.». - Прим. перев.).

Давайте с вами рассмотрим - имеется ли на рынке потребность в третьем дистрибутиве Linux? Давайте посмотрим на эту ситуацию глазами клиента, купившего поддержку Linux от Oracle:

Будет ли это поставщик решений с бОльшим опытом, чем Novell и Red Hat? Нет.

Будет ли это поставщик, который будет привержен идее Linux-инноваций для всех физических, виртуальных и облачных платформ, которые могут понадобиться клиентам? Нет. В центре интересов Oracle находится только сам Oracle. Если вам потом понадобится купить решение VMware или для мэйнфреймов, что ж надо было думать раньше.

Будет ли это поставщик, заинтересованный в развитии Linux как стратегической платформы и уделяющий особое внимание ее разработке? Опять нет. (Просто попросите кого-нибудь из Oracle объяснить сегменты рынка и указать рекомендуемые области использования Solaris и Oracle Linux, а затем смотрите, как они будут выкручиваться).

В конечном счете, все дело в том, что рынку просто не нужен третий дистрибутив Linux. Наличие двух сильных игроков - Novell и Red Hat - делает рынок достаточно конкурентным, и наши команды по R&D совместно с талантливыми людьми из сообщества ПО с открытым исходным кодом рождают исключительные инновации в таких областях как виртуализация, облачные вычисления, кластеры и HA-решения, управление предприятиями. Хотя, безусловно, в интересах Oracle быть на рынке решений Linux, ведь их доля на рынке отстает.

Конечно, нужно признать историческую роль Oracle в качестве сильного партнера экосистемы Linux, включая Novell, с такими инициативами, как OCFS и тесты баз данных Oracle на разных дистрибутивах Linux, включая SUSE Linux Enterprise Server. Это ключевые элементы, которые делают нынешний Linux таким ярким.

Вопрос: нужен ли клиентам третий дистрибутив Linux? Пока по крайней мере, другого ответа, кроме «нет» найти нельзя.

Оригинал на английском

Кто покупает Novell? Делайте ваши ставки!

2010-09-19T15:33:00.006+04:00

Мой перевод статьи-размышления от Joe Brockmeier о том, кому может достаться Linux-бизнес Novell

Прошел слух, что Novell достигла предварительного соглашения о продаже, что расколет ее бизнес на две части и продаст ее Linux-отделение "неназванному стратегическому покупателю". Предполагая, что сделка все-таки состоится, кто же этот покупатель, и что это будет означать для SUSE и проекта OpenSUSE ?

Краткая отмазка: Novell мой бывший работодатель. Я ушел из компании в конце января, и, насколько я знаю, предложение в 2 млрд. долларов от Elliott Associates тогда еще даже не обсуждалось. Во всяком случае у меня нет какой-либо внутренней информации (позвони же мне, Ян...), так что написанное ниже - всего лишь мои размышления. У меня нет никакой заинтересованности в каком-то определенном покупателе. Я только надеюсь, что мои бывшие коллеги будут работать в компании, которая будет относиться с уважением к ним и проекту OpenSUSE.

Давайте рассмотрим потенциальных покупателей. Novell недавно заключила несколько стратегических соглашений с VMware, и имеет давние партнерские отношения с IBM и SAP. Oracle сейчас также находится в режиме постоянных приобретений, и, вполне возможно, захочет закусить бизнесом SUSE Linux после своей покупки Sun. Но зачем было разрушать нарождающееся сообщество открытого исходного кода (OpenSolaris), когда можно иметь два (OpenSUSE)?

Давайте начнем с Oracle. Oracle имеет свою собственную платформу Oracle VM, имеющую в основе Xen и Red Hat Enterprise Linux(RHEL). Ну хорошо, RHEL с логотипами Oracle. Oracle Unbreakable Linux полностью бинарно совместим с RHEL безо всяких излишних затрат на развитие, которые Red Hat фактически вкладывает свой дистрибутив.

Правда, есть одна маленькая проблема, в грядущем релизе Red Hat просто выкинет Xen в окно, предпочитая ему KVM. Oracle должен будет либо последовать ее примеру и инвестировать в такой переход, или ей придется нарушить совместимость с RHEL после релиза RHEL 6. Если Oracle останется на Xen, ей придется подумать о переходе на другой дистрибутив. Novell по-прежнему до сих пор не вкладывает свои деньги ни в одну платформу, предпочитая стратегию «и нашим и вашим», то есть поддерживая все платформы виртуализации.

Возможно, я излишне оптимистичен, но я считаю маловероятным то, что Oracle собирается поглотить бизнес SUSE. Если это произойдет, я не верю в будущее проекта OpenSUSE. Даже если Oracle все же решит поддерживать его, стиль работы Oracle с сообществом отвратителен. Покупка Oracle сильно затормозит тот прогресс, на который взял курс этот проект, и, кажется, весьма вероятно, что компания увидит «утечку мозгов» подобно той, что произошла после покупки Sun.

IBM - другой претендент. IBM поддерживает партнерские отношения со всеми крупными Linux-компаниями: SUSE, затем Novell, Red Hat и Canonical. Покупка одного из трех и создание своего собственного дистрибутива выглядит не слишком хорошо. Это может даже сделать Red Hat одним из конкурентов IBM, чего никто не хочет. Но IBM и Novell сильно завязаны друг на друге в бизнесе мэйнфреймов, поэтому IBM может решить, что иметь в своем портфеле SUSE будет очень хорошо. Если IBM серьезно относится к форку OpenOffice.org - Symphony, то она также может захотеть заполучить кого-то из разработчиков Novell, участвующих в Go-OO.org. Хотя это, вероятно, подтолкнет HP, Dell и других к Red Hat или другим дистрибутивам. IBM может быть хорошим управленцем для сообщества OpenSUSE; безусловно, гораздо более лучшим, чем Oracle.

Еще один из вариантов - SAP. У нее много стратегических соглашений с Novell/SUSE и много крупных клиентов на SUSE Linux. Но SAP использует также другие продукты Novell, что входит в противоречие со слухом, что компания покупает только Linux-отделение, а все остальное достанется инвестиционным фирмам. Если SAP собиралась бы купить Novell, кажется, более вероятно, что она бы просто купила компанию целиком без лишней суеты.

Все это подводит меня к наиболее вероятному выбору: VMware. VMware в последнее время уже покупала другие решения с открытым исходным (Zimbra, SpringSource), поэтому не будет преувеличением сказать, что эта компания, возможно, захочет добавить SUSE Linux в свой портфель. VMware также может захотеть иметь свой собственный дистрибутив Linux, чтобы помочь своим клиентам и партнерам построить больше готовых решений, которые будут работать на продуктах VMware для виртуализации. И для этого на рынке нет лучшего решения, чем SUSE Studio. Мне кажется, что SUSE Studio - это действительно хорошее дополнение к VMware Appliance Marketplace. Red Hat сейчас только на пути построения своего собственного решения для виртуализации, так что это также помогло бы конкурировать VMware с поставщиком Linux номер один.

Как это отразится на проекте OpenSUSE и SUSE Linux в целом? Думаю, что все будет по крайней мере также, если не лучше, по сравнению с тем периодом, когда у руля стояла Novell. Скорее даже лучше, потому что Novell временами впадает в кризис самоидентификации, когда она пытается разобраться, как все ее бизнес-единицы сочетаются друг с другом. SUSE же идеально впишется в стратегию компании VMware - по крайней мере, на взгляд со стороны.

И в завершение совсем кратко - а что же Microsoft? Вот это точно вряд ли. Мне трудно представить себе, как она собирается действовать, оставаясь в рамках антимонопольного законодательства.

Так кто же скрывается под неизвестным «стратегическим покупателем»?

Я ставлю все, что у меня есть, на VMware, но я вполне могу оказаться неправ. Это могут быть IBM, SAP, или (только не это!) Oracle. Или это кто-то другой, о котором я не подумал. Есть варианты?

Оригинал статьи

От переводчика.

Что не удалось Novell?

Первое: никакой маркетинг. Novell имеет прекрасный набор продуктов для полноценного построения инфраструктуры предприятия любого масштаба - eDirectory, ZenWorks, все сервисы OES. Причем, каждый из этих продуктов пока не имеет конкурентов по полноте охвата всех имеющихся платформ и по своему функционалу.

Второе: слабая работа с сообществом. Пример такой работы следовало бы брать с конкурента номер 1. Novell участвует во многих открытых проектах, но мало кому известны масштабы этого участия.
У Novell реально классные продукты. У нас на курсах многие администраторы с теплом в глазах вспоминали Netware, надежность которой осталась непревзойденной до сих пор. И очень жаль что эта операционная система оказалась вытесненной продуктом гораздо худшего качества.

Другой путь к свободе

2010-09-17T11:00:00.001+04:00

Предлагаю вниманию читателей блога интересные размышления о свободе и свободном ПО, автор которых Jos Poortvliet - нынешний лидер сообщества openSUSE.

Дисклеймер: политические взгляды переводчика могут не совпадать с мнением автора статьи

Jos Poortvliet

В конце прошлой недели Нью-Йорк Таймс поместила историю о том, как правительство России использует вопросы лицензирования программного обеспечения для борьбы с протестами и митингами несогласных. В статье объясняется, что русская милиция изымает их компьютеры под предлогом использования пиратского программного обеспечения. В результате данные, полученные из этих компьютеров, помогают органам изучить планы активистов, что в дальнейшем приводит к их арестам.

И хотя Microsoft отреагировала на эту ситуацию выдачей разрешительных лицензий для таких организаций, читая статью я подумал, что есть другой, гораздо лучший способ помешать органам использовать тему лицензирования ПО как повод для арестов. Хоть этот способ не остановит авторитарные правительства от борьбы с инакомыслящими, использование свободного и открытого программного обеспечения может затруднить органам узаконить этот тип действий.

Во-первых, философия свободы пронизывает все существо тех мужчин и женщин в сообществе, разрабатывающем программное обеспечение с открытым исходным кодом, что приводит ко многим нововведениям, препятствующим ограничениям свобод. Например, это такие вещи, как шифрование с помощью GPG и технология TOR, которые делают возможным использование анонимных коммуникаций для миллионов пользователей в таких странах, как Китай и Иран. Не говоря уже о том, что в мире открытого ПО у нас есть сильный акцент на безопасность и защиту от таких угроз, как вирусы или "бекдоры", помещаемые в коммерческое ПО путем давления со стороны правительств.

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

И да, это РЕАЛЬНО лучший продукт, чем может предложить мир проприетарного ПО - несмотря на то, что он «другой» по своей сути. Свободное ПО не совершенно — например, как Нидерланды, где я живу, совсем не совершенны. В самом деле, чтобы нормально жить в моей стране, скажем, жителю Северной Кореи, нужен какой-то срок на адаптацию, примерно также, как и пользователю Windows нужно привыкнуть к использованию openSUSE. Но в Нидерландах и с открытым ПО реально лучше, потому что они более свободны.

Да, мы создаем сильные и убедительные альтернативы проприетарному ПО. Но НЕ достаточно просто иметь лучший продукт - свобода это также его неотъемлемое качество. Работающий TOR-сервер - даже если вы живете в демократической стране и вам нечего скрывать - помогает жителям других стран, имеющих репрессивные правительства, потому что вы даете им возможность использовать ваше интернет-соединение - для сокрытия от любопытных глаз своего правительства. Свободное ПО воплощает ожидания и убеждения для деятельности, связанной со свободой и организацией сообществ, например, таких групп активистов, как Baikal Wave. Любому лицу, группе или организации, которые желают действовать на основе того, во что верят, следует рассмотреть возможность использования свободного программного обеспечения как способ жить и работать без ущерба для своих убеждений.

Я не скажу, что свободное и открытое ПО делает мир совершенным - но это шаг в нужном направлении. В конце концов, «в мире, где общение речь зависит от ПО, свобода слова зависит от свободного ПО»! (D.B. Martin)

Оригинал статьи

Размышления Марка Шаттлворта об Ubuntu, Canonical и внедрении свободного программного обеспечения

2010-09-15T21:32:00.004+04:00

Те, кто регулярно читает opennet.ru, наверняка обратили внимание на горячее обсуждение письма Марка Шаттлворта о вкладе Canonical и Ubuntu в свободное ПО в целом. Почитав это письмо, я нашел в нем достаточно интересных мыслей, что сподвигло меня на перевод этого текста. Думаю, что мой перевод позволит словам Марка достичь гораздо большей аудитории.
Краткое резюме для тех, кто не хочет читать:

1. Свободное ПО - это огромная область, работы на которой хватит всем. Поэтому и надо заниматься работой, а не считать кто и сколько сделал.
2. Свободное ПО, как алмаз, который нуждается в правильной огранке, чтоб достичть своего пользователя. В истории IT есть много случаев, когда становились популярными не самые лучшие с точки зрения качества и надежности работы продукты. Поэтому, для популяризации свободного ПО нужно учитывать реальные потребности пользователей и подстраиваться под них.

Критика в адрес Canonical по поводу ее вклада в разработку ядра Linux и GNOME заставила меня задуматься: доволен ли я тем, чем занимаюсь каждый день моей жизни. Насколько для меня важно чувствовать, что результаты моей работы служат другим людям и делают мир лучше. Явлется ли мое участие в проекте Ubuntu тем делом, возможность заниматься которым можно посчитать за счастье.

За последний месяц у меня было два случая, позволяющих положительно ответить на данный вопрос. Первый - письмо с благодарностью из Новой Зеландии, от человека, который отметил, что Ubuntu 10.04 внесла реальные изменения в жизнь его семьи. Для них этот проект, предоставляющий целостное, интегрированное окружение для работы и существующий благодаря труду тысяч людей, похож на маленькое чудо человеческой щедрости. Второй случай - контракт на поддержку десятков тысяч рабочих станций, работающих на Ubuntu 10.04. Общее между этими двумя случаями - два столпа, на которых зиждутся проекты Ubuntu и Canonical: предоставлять всему миру результаты труда огромного сообщества свободного программного обеспечения как подарок, бесплатно, свободно, без ограничений и делать это на постоянной основе.

Первая история из Новой Зеландии о тех, кто учит детей пользоваться компьютером с раннего возраста и наблюдает насколько больше они могут получить знаний от Ubuntu, чем от Windows, и насколько доступнее делать это с Ubuntu. Для них то, что Ubuntu приносит им весь мир свободного программного обеспечения как единое целое - это здорово, это - прорыв, и они очень благодарны за это.

Это история, повторение которой я надеюсь увидеть 100 миллионов раз. И она делает честь и приносит удовольствие не только мне, не только тем, кто отдает Ubuntu свою любовь и энергию, но и всем тем, кто участвует в разработке свободного ПО в целом. Ubuntu в отдельности не заслуживает всеобщего признания, это часть большой и сложной экосистемы, но без Ubuntu продвижение свободного программного обеспечения просто не достигло бы таких масштабов.

Мы все понимаем, что тело свободного ПО состоит из многих органов, многих клеток, каждая из которых имеет свои собственные приоритеты, интересы и назначение. Тело может существовать только благодаря их совместной работе. Мы лишь небольшая часть целого, это честь для нас - взять на себя ответственность в создании своего дистрибутива. Мы несем ответственность за выбор Ubuntu теми, кто только начинает свое путешествие в мир свободного ПО, и мы упорно работаем над тем, чтобы быть уверенными, что все ее компоненты хорошо складываются вместе.

Ubuntu и то, что она делает, не могло бы произойти без усилий прекрасного Linux-сообщества, которое, в свою очередь, не могло бы существовать без сообщества GNU, которое также не смогло бы подняться на сколь-нибудь значимое место без усилий таких компаний, как IBM и Red Hat. И может быть все пошло бы совсем не так, если бы не участники проектов Mozilla и Netscape, GNOME, KDE, Google и всех остальных, кто использовал свободное ПО для разных задач, что делало его только лучше. Есть десятки тысяч людей, которые никак не связаны с Ubuntu и которые сделали эту историю - реальностью. Многие из них работали более десятка лет - и прошло много времени прежде, чем пришел неожиданный успех, в то время как Ubuntu на сцене только лишь 6 лет. Именно поэтому Ubuntu не может признаваться единственной и неповторимой лишь только для красного словца и чтобы порадовать своих поклонников :).

Тем не менее проект Ubuntu делает кое-что уникальное, специфичное и важное для свободного ПО: создает у конечных пользователей устойчивый образ того, что со свободным ПО могут работать все, как с экономической точки зрения, так по легкости использования и готовности решать проблемы, возникающие то там, то здесь. И я считаю, что это подарок тем людям, которые собирают каждый из пакетов Ubuntu. Если мы сможем предложить свободное ПО аудитории в 10 раз большей чем сейчас, мы десятикратно усиливаем вашу щедрость, что делает каждый час нашей с вами жизни (который мы проводим исправляя ошибки или улучшая что-либо) в 10 раз ценнее. Я очень горжусь тем, что трачу время и силы на Ubuntu. Да, я мог бы делать множество других вещей, но я не могу себе представить что-то еще, что имело бы аналогичное влияние на мир.

Я готов признать, что не каждый может видеть картину моими глазами. Передача результатов своей работы аудитории в 10 раз большей без учета усилий, затрачиваемых на двустороннюю связь с конечными пользователями и работу над новыми возможностями, может выглядеть со стороны просто как рост скачиваний или увеличение потока отчетов об ошибках в 10 раз. Другими словами, если upstream не видит ничего кроме «кода», то он и не сможет увидеть ничего кроме кода. Я действительно не знаю, что с этим делать: Ubuntu - не средство для доставки конечным пользователями всего многообразия написанного кода, мне кажется это не то, в чем нуждается мир. А нуждается он в средстве, которое позволяло бы брать этот код и следило за тем, чтобы тот код, который уже есть, оставался в состоянии высокого качества и надежности. Все, что нужно для рабочих станций уже есть и даже код соответствует ожиданиям, не было только возможности вынести область его использования за пределы серверов, чтобы представить широкой публике уже готовое решение.

Второе письмо я не могу процитировать. Оно предполагает контракт на оказание услуг Canonical в оказании помощи по миграции более чем 20 000 настольных компьютеров с Windows на Ubuntu. В последнее время в этой области много предложений, их темп ускоряется по мере укрепления доверия к Ubuntu. Хоть Linux уже давно зарекомендовал себя прекрасным рабочим столом для вдохновленного и целеустремленного разработчика, существует разрыв между его потребностями и потребностям крупных организаций. Другой такой компании, которая была бы настолько же привержена идее свободного ПО для настольных систем в том же масштабе, как Canonical, нет и поэтому я очень горд тем, какую роль мы играем в этой экосистеме. Для меня было бы очень печально, если б все усилия, которые сообщество свободного ПО затрачивает на разработку приложений для рабочих станций, были потрачены впустую.

В настольных компьютерах, которые Canonical поддерживает в крупных организациях, нет чего-то секретного или закрытого. Подлинным чудом для меня является то, что и в истории из Новой Зеландии, и в истории с миграцией компьютеров фигурирует один и тот же код. Для меня это истинное назначение свободного ПО. Когда я сам участвовал в проектах с открытым кодом, я всегда был рад, когда результаты моей работы могли служить не только моим потребностям, но и оказаться полезными многим другим.

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

Canonical использует различные подходы для взаимодействия с другими компаниями, которые работают с Linux, и не занимается скрытой критикой конкурентов просто потому, что у нас есть свои принципы. Сила свободного ПО именно в наличии огромного количества разных компаний, совместно работающих над различными целями.

В последние несколько недель неоднократно заявлялось, что Canonical преследует какие-то свои собственные интересы и действует отнюдь не в интересах сообщества, занимающегося открытыми исходными кодами. Это все лживые заявления, потому что большинство из нас наоборот мотивировано делать все, что мы только сможем, чтобы способствовать делу свободного ПО как в интересах конечных пользователей, так и сообщества, которое его делает, и мы убеждены, что существование Ubuntu и Canonical это лучший способ для достижения этой цели. И этот пост показывает результаты размышлений над этими вопросами: это моя собственная позиция показывающая, что именно я делаю и почему я испытываю чувство гордости от тех усилий, которые затрачиваю каждый день.

Что мы вместе делаем для свободного ПО? И что же я сам могу сделать для него?
Во-первых, мы занимаемся доставкой его конечным пользователям. Мы снижаем влияние потребительской инерции и тех факторов, которые мешают людям попробовать бесплатное ПО и решить для себя, нравится ли оно им в той мере, чтобы начать им пользоваться. Сотни из тех, кто сейчас участвует в свободном ПО (разработчиков, переводчиков, дизайнеров, пропагандистов) получили возможность стать частью нашего движения, поскольку для них не стало проблемой слегка намочить ноги в воде. И это совсем не легко. Просто посмотрите на результаты нашей многолетней работы над упрощением инсталлятора Linux, что стало возможно только благодаря труду многих групп людей и было бы просто невозможно без участия Canonical и Ubuntu.

Есть тысячи людей, которые довольствуются сборкой свободного ПО для себя, и это не преступление. Но желание облечь его в такую форму, чтобы другие могли его попробовать, изучить и затем удобно использовать, нужно тоже приветствовать. И именно этому в сообществе Ubuntu придается огромное значение: если вы почитаете planet.ubuntu.com, вы станете свидетелем радости многих людей, использующих свободное ПО. Как сообщество мы глубоко удовлетворены тем, чтобы люди использовали его для решения каких-то задач в своей жизни. Это радует гораздо больше, чем истории о том, как мы «сделали это быстрее» или «добавили новую функцию». Мы, конечно, работаем и над тем и над другим, но сообщество больше ценит влияние на мир, а не на код. Люди очень ценят свое время и опыт. Я горжусь тем, что Ubuntu привлекает людей, вносящих свой щедрый вклад в общее дело. Поэтому мы благодарим и Kubuntu, и Xubuntu, и Puppy, и Linux Mint. Они не висят у нас на хвосте, они стоят на наших плечах, так же, как мы стоим на плечах гигантов. И это здорово. Наша работа будет более значимой и ценной, потому что их работа достигает тех пользователей, которых не достигли мы.

Что еще?
Посмотрите на проект Papercut, основанный на том положении, что все невероятные технологии и усилия, направленные на какой-то сложный проект (например, такой как ядро Linux) имеют нулевую ценность, если средний пользователь не может с ним работать. И, наоборот, проект ценен тогда, когда он просто работает. Сотни пожеланий пользователей были учтены во многих различных приложениях, пользу от чего получает не только Ubuntu, но и любые другие дистрибутивы, их использующие. Если вы думаете, что это легко, попробуйте оценить усилия, затрачиваемые на сортировку и рассмотрение каждого из тысяч предложений, координацию исправлений и их дальнейшее распространение. Результаты неустанного труда большой команды видны невооруженным взглядом.

Другой пример: сохранить миллионам пользователей 1 час в неделю - это экономия энергии, которую можно получить, используя свободное ПО. Хоть команда дизайнеров Canonical играет ведущую роль в создании проекта Papercuts, настоящие звезды представлены здесь - http://www.omgubuntu.co.uk/2010/06/maverick-papercut-hunting-season-opens.html . Каждый может внести предложение, как для версии Desktop http://ubuntuserver.wordpress.com/2010/01/20/ubuntu-server-papercuts-project/, так и для Server.

Лично я положил много на руководство и управление проектом и создание структуры сообщества. Когда мы только начинали Ubuntu, я потратил много времени на анализ существующих сообществ, на то как в них разрешаются неизбежные трения и разногласия, возникающие, когда у вас есть много умных и талантливых людей, взаимодействующих между собой. Для решения этого вопроса мы составили кодекс поведения, который будет гарантировать, что наша страсть к технологии и/или работе не подавит основную цель - собрать разных людей вместе, чтобы совместно работать над общей платформой. Я очень рад, что эта идея распространилась и на другие проекты: у нас нет цели тайно вынашивать идеи, проекты и мысли, которые шли бы вразрез с нашим назначением.

Мы создали простейшую структуру: технический совет (technical board) и совет сообщества (community council). Такой подход в настоящее время широко распространена и во многих других проектах. Поскольку проект Ubuntu вырос, управление претерпело изменения, в настоящее время есть несколько управляющих команд для таких групп, как Kubuntu, форумы и IRC, которые дают советы и руководят такими группами, как LoCo, модераторы, оперативный отдел, разработчики, которые, в свою очередь, стремяться к техническому совершенству и умению работать с людьми, как часть огромного мирового сообщества. Это удивительно и прекрасно. Когда люди начинают участвовать в Ubuntu, как правило, они мотивированы не только желанием быть частью замечательного сообщества, но и исправлением конкретной проблемы или внесением какой-либо идеи по улучшению. С течением времени некоторые из этих людей сознают, что они могут помочь людям быть более креативными, разрешать разногласия, организовывать работу группы так, чтобы результат был гораздо лучше, чем сможет сделать один человек. Наша структура управления проектом создает все возможности для таких людей: они составляют основу и структуру, которая делает это сообщество легко масштабируемым, производительным и довольным.

Такой проект, как Ubuntu, нуждается в постоянном уходе, чтобы защищать свои ценности. Когда вы малы и поднимаете плакат с надписью «мы делаем вот это» вы, как правило, привлекаете только тех людей, которых это интересует. Когда проект перерастает в нечто мощное и заметное, вы, как правило, начинаете привлекать ВСЕХ, потому что люди хотят быть там, где что-то происходит. И значимость проекта может легко пойти вниз. Так, я по-прежнему трачу много энергии на работу с советом сообщества Ubuntu и командой Canonical по взаимодействию с сообществом, и они оба являются талантливыми и трудолюбивыми, потому что эта часть моей работы приносит мне огромное удовольствие. Совет сообщества Ubuntu относится к своим обязанностям хранителя ценностей проектов сообщества очень серьезно. Он в основном состоит из людей, которые не связаны с Canonical, но которые тем не менее считают, что проект Ubuntu важен для свободного программного обеспечения в целом. И бесподобный Jono Bacon, восхитительный Daniel Holbach, и невозмутимый Jorge Castro - профессионалы, которые понимают, как сделать работу сообщества продуктивной и успешной.

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

В последние годы я стараюсь обращать больше внимания на соревнование за наилучшее оформление в свободном ПО. Я считаю, что свободное ПО обладает лучшим качеством, но думаю, нам нужно точно знать, что мы хотим создать для наших пользователей, будь то рабочая станция, нетбук или сервер. Поэтому я трачу так много моего времени на вдохновление различных сообществ - и Ubuntu, и upstream - чтобы приглашать в них тех, кто видит ПО глазами обычного пользователя, а не опытного хакера. Это фундаментально изменит ценность открытого ПО, и я не могу надеяться, что такую задачу можно осилить в одиночку, но я тем не менее горжусь тем, что являюсь чемпионом этого подхода и рад, что все предложенное неуклонно принимается.

В свободном ПО уже были дизайнеры и до того, как мы это предложили. Я надеюсь, они чувствуют, что внимание Canonical в области концепции лидирующей роли дизайна сделало их жизнь легче, и сообщество в целом больше ценит их усилия и восприимчиво к их идеям. И все-таки, если вы действительно заботитесь о внешнем виде свободного ПО, команда по дизайну Canonical (Canonical design team) ждет вас.

Я делаю некоторую часть работы по оформлению сам и участвую в разработке дизайна Unity - интерфейса для Ubuntu Netbook Edition 10.10. Это следующее поколение старого интерфейса UNR. Самое главное в нем - это утверждение, что рабочие станции Linux не должны быть застревать в 90-х, мы можем и будем пытаться построить новые и эффективные способы взаимодействия с компьютерами. Я был в восторге от скорости, с которой некоторые объекты Unity были приняты сотнями проектов, их цель сделать использование Linux гораздо более простым и прекрасным для всех, так как скорость этой адаптации является мерой того, насколько быстро пользователи смогут лучше адаптироваться к новым способам использования своих компьютеров.

Дизайн сам по себе ставит нас в положение, удобное для обвинения в желании свалить работу по его внедрению на других, так что я горжусь нашей замечательной командой, которая занята реализацией некоторых из этих основных компонентов. В частности, dbusmenu оказалось полезным для организации согласованности внешнего вида приложений GNOME и KDE, работающих под Unity, и я очень надеюсь, что оно будет принято в другие проекты, которые нуждаются в тех интерфейсах, которые оно предоставляет. Я полностью доверяю нашей инженерной команде, нацеленной на качество готового продукта, которая предоставит разработчикам простой и ясный API и руководство о том, как его использовать. Если вы использовали полный набор индикаторов в 10.10, то вы в курсе той работы, которая была сделана без лишнего шума и вобрала в себя результаты многих различных проектов и превратившей панель в нечто прекрасное и эффективное. Utouch также приближается к своему первому релизу и будет продолжать развиваться, так что и Ubuntu, и GNOME, и KDE получат простой способ реализации поддержки жестов Multi-Touch.

Помимо этого, я также занимаюсь финансовой поддержкой различных проектов. Целесообразность вклада денег в свободное ПО должна определяться ответом на следующий вопрос: может ли результат вложения денег в другой проект, помочь большему количеству людей? Есть много способов помогать людям: на $100 000 можно отправить многих в школу, одеть и накормить их. Поэтому я действительно должен быть уверен, что этими деньгами я привношу реальное воздействие на жизнь людей. Благодарственные письма, которые я получаю каждую неделю, помогают мне сохранить уверенность в этом. Более того, мои собственные наблюдения того каталитического эффекта, который Ubuntu дает всей экосистеме ПО с открытым исходным кодом, с точки зрения привлечения новых разработчиков, создания новых платформ, создания нового бизнеса, признания новых участников, придают мне уверенность, что обеспечиваемое мной финансирование оказывает значимые последствия.

Когда мы только задумывали Ubuntu, экосистема Linux была в некотором смысле полностью сформирована. У нас уже было ядро. У нас уже были GNOME и KDE. У нас были X, libc и GCC и все остальные хорошо знакомые инструменты. Естественно, что в них были ошибки, недостатки, были планы по их устранению. Но кое-чего не хватало: иногда это «кое-что» формулируется как «маркетинг», а иногда как «все для конечного пользователя». Я помню, как подумал «вот то, что я могу сделать». Именно поэтому Ubuntu и Canonical не прикладывают усилия к тому, что и так хорошо работает, вместо этого мы сосредотачиваем свое внимание на новых идеях, новых инструментах и новых компонентах. Я считаю это живительным взаимодействием со всей экостистемой открытого ПО, и я слышу от многих людей, что они воспринимают его точно так же. Те, кто говорят «Canonical не участвует в разработке X», правы, но упускают из вида все, что мы делаем с нуля. Конечно, есть мало того, что мы делаем в одиночку, и мало чего из того, что мы делаем, не смог бы сделать кто-то другой, но я думаю, что энергия сообщества Ubuntu и энтузиазм ее пользователей отражает тот факт, что в проекте есть кое-что отличное от других. Это «кое-что» заставляет нас торжествовать, гордиться своим трудом, и мотивирует нас продолжать.

Свободное ПО больше, чем любой из проектов. Оно больше, чем ядро Linux, чем GNU, чем GNOME и KDE, чем Ubuntu, Fedora и Debian. Каждый из этих проектов играет свою собственную роль, но это все в целом реально меняет мир. Поэтому, когда мы начинаем спорить друг с другом о том, какая часть свободного ПО перспективнее, мы рискуем упустить картину в целом. Это немного похоже на аутоиммунные заболевания, когда организм начинает атаковать сам себя. Тот, кто напряженно работает в течение всего дня, чтобы донести свободное ПО до более широкой аудитории, играет на той же стороне, что и я, если уж мы применяем такую терминологию. Я восхищаюсь и уважаю всех тех, кто вкладывает свою энергию в продвижение свободного программного обеспечения, даже если он делает это по-другому.

Ссылка на оригинал