1. Planet
  2. Русский
  3. Page 7

Fri, Jul 08, 2011

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

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

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

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

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

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

Tue, Jul 05, 2011

Дистрибутивы Linux. Часть II
Хоть 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 и сразу рассказать про них все (в ней тогда будет «многабукав» и читать ее мало кто рискнет :) ). Но если у меня получилось дать некую базу для дальнейшего гугления интересующей информации по сайтам конкретных проектов, думаю, что я достиг поставленной цели.

Mon, Jul 04, 2011

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

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

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

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

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

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

Thu, Jun 30, 2011

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

Дистрибутивов 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-пакетах.
Следующее непонятное определение - репозиторий пакетов. Это место, откуда пользователи берут ПО для своего дистрибутива. Обычно это некое сетевое (но может быть и локальным) хранилище пакета, в котором помимо собственно пакетов для дистрибутива находится набор метаданных, которые используются пакетным менеджером для управления ПО на машине пользователя. Именно благодаря этим метаданным пользователям достаточно легко найти нужные пакеты в репозитории, а пакетному менеджеру выяснить, какое ПО требует обновлений.
По способу поддержки репозитория можно выделить три типа дистрибутивов:

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

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

Fri, May 06, 2011

Снова skype

Что бы не говорили о небезопасности использования skype, пользуются им большое количество людей. И я в том числе 🙂  Поэтому когда слетела (по моей неосторожности) моя система opensuse 11.3, и бэкапов к сожалению я не делал, я перебрался на запасной аэродром — экспериментальную, обновленную с 11.3 систему opensuse 11.4 с установленными lxde u kde3 (kde4 я до сих пор недолюбливаю).

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

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

xorg-x11-libXv-32bit
libqt4-32bit
libqt4-x11-32bit
libpng12-0-32bit

Wed, Apr 13, 2011

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

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

Сначала о выступлениях в торжественной части.
Первым выступал директор Департамента государственной политики в области информационных технологий и координации информатизации Минкомсвязи России с докладом на тему - «Создание национальной программной платформы. Разработка приложений, основанных на использовании СПО» - г-н Милашевский И.А. На доклад, естественно, он вышел с ноутбуком от 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 Пол Хольт и инженер по политике продаж Борис Девоуг делали доклад о корпоративных решениях для закачиков. Небольшой нестыковкой было то, что слайды были переведены на русский язык, поэтому докладчики выступали «вслепую» :). Но свой текст они знали на пять баллов, поэтому не ошиблись ни разу.

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

Thu, Mar 10, 2011

Dinar Valeev posted at 10:56

flash + 11.4 + youtube
При миграции на 11.4, заметил странное поеведение Flash плагина на youtube. При переходе с видео на видео, flash плагин крешится. Либо показывается черный экран, вместо видео.

Всему виной как оказалось, включенное апаратное усорение во флеше.

Отключить его можно в меню "Settings" flash плеера.

Thu, Feb 24, 2011

Выход новой версии opensuse

У меня две хороших новости.

Одна — скоро выходит новая версия любимой операционной системы, Opensuse 11.4.  Я так нечасто бываю на официальном сайте, что (о стыд!) подумал, что можно уже загружать. Ну, а осталось ждать всего две недели. Я доволен и текущей версией, но всегда ожидаешь нового, неизведанного. Так что уже скоро!

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

Удачи всем линуксоидам, линуксоюзерам и блоггерам!