Linux и все, все, все… Колонки и статьи в LinuxFormat, 2006-2013

Алексей Федорчук aka alv

Версия книги для чтения online (очень большая). Версии для оффлайнового чтения в большинстве актуальных машинно-читаемых форматов можно скачать со страницы Библиотека Блогосайта.

Колонки и статьи Алексея Федорчука, печатавшиеся в журнале LinuxFormat на протяжении 2006-2013 годов, собранные в хронологическом порядке. Они посвящёны UNIX, Linux и другим UNIX-подобным системам, их приложениям, а также идеологическим вопросам Свободного и Открытого Программного Обеспечения (FOSS). Публикуются в авторской редакции.

Содержание

Вступление

Здесь я собрал в хронологическом порядке все свои колонки, печатавшиеся в журнале LinuxFormat на протяжении 2006-2013 годов. Цель сборника – сохранить аутентичные свидетельства уходящей эпохи, затрагивающие события, как уже ставшие достоянием истории, так и те, которым эта участь предстоит. Дополнительно включены несколько статей как бы технического характера – и в качестве таковых существенно устаревшие. Однако они представляют собой снапшоты описанных в них систем на момент сочинения соответствующих материалов – и потому тоже являются своего рода историческими свидетельствами.

Все материалы даны в авторской редакции, которая может отличаться от окончательной «бумажной» версии. Для ориентировки во времени указаны год и номер журнала, в котором они публиковались – прошу обращать на это внимание, если что-то покажется не соответствующим реалиям сегодняшнего дня.

Статьи из исторического цикла LinuxFotmat’а в этот сборник не включены: они образовали одну из составных частей книги Мир FOSS. Вопросы истории, которая готовится к размещению в Библиотеке Блогосайта.

Я приношу свою искреннюю благодарность бывшим и действующим сотрудникам редакции журнала LinuxFormat: Елене Толстяковой, Валентину Синицыну, Кириллу Степанову. И надеюсь на дальнейшее плодотворное сотрудничество.

Сайт журнала LinuxFormat: http://www.linuxformat.ru/
Официальный форум: http://forum.linuxformat.ru/
Редакционная подписка: http://shop.linuxformat.ru/
Подписка через LinuxCenter: http://www.linuxcenter.ru/

Колонки

2006

Новый инсталлятор Debian

LinuxFormat, #78 (апрель 2006)

Debian обзавелся новым инсталлятором. Точнее, это все тот же Debian Installer, впервые появившийся в Sarge, но несколько модифицированный. Теперь установка совершается в один этап – без перезагрузки: после развертывания базовой системы следует предложение настроить доступ к архивам пакетов, далее – выбрать целевые наборы (Standard System, Laptop, и так далее), – которые немедленно и устанавливается. Так что по рестарту машины система имеет место быть в полностью скомпонованном виде.

За эту идею разработчики Debian выражают благодарность коллегам по Ubuntu. Хотя на самом деле они пошли дальше. Как известно, вариант Debian Installer от Ubuntu изначально отличался тем, что осуществлял установку «в полтора этапа» – после рестарта происходило развертывание дополнительного софта. Дебиановцам удалось целиком вписаться в один этап.

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

Процессор Cell и его роль в Linux-революции

LinuxFormat, #78 (апрель 2006)

Много лет назад (1992 г.) в журнале PC Magazine появилась статья под зловещим названием: Через десять лет все платформы, кроме IBM PC, уйдут в небытие (воспроизвожу по памяти). Тогда это казалось невероятным.

Увы – мрачный прогноз сбывался опережающими темпами. И на пользовательских десктопах безраздельно воцарились процессоры от Intel, все прочие архитектуры ушли в нишевые области. А недавно рухнул последний бастион анти-интеловской обороны: Apple начала переход на PC-архитектуру.

Конечно, стандартизация «железа» имела свои положительные стороны. Однако согласитесь – в унифицированном мире жить просто скучно…

И вот – процессоры Cell от фирмы IBM. Революционные архитектурно, фантастически производительные и сверхъестественно дешевые. Могущие в равной мере служить сердцем и игровых станций, и сверхмощных серверов. Которым не хватает лишь одного – адекватной операционки. Каковая не замедлила появиться: в ядре Linux версии 2.6.16 заявлена поддержка процессоров Cell. И этот факт может повернуть все ее развитие.

Представим себе игровые станции на процессорах Cell под Linux. Это даст стимул к совершенствованию графической подсистемы, что приведёт наконец к пресловутой её «десктопизации».

Рискну предположить, что «десктопизация» Linux пойдет совсем не так, как DOS и Windows – не к тотальному универсализму, а к специализированным станциям (пусть сначала и игровым). То есть – генеральным путем развития UNIX и Linux.

Примечание. Увы, возлагавшиеся на Cell надежды не оправдались: они так и осели в игровом сегменте. И постепенно энтузиазм пользователей, устанавливавших на них Linux, иссяк. Нынче нечто подобное происходит с ARM-процессорами. Какова будет судьба Linux’а на них? Боюсь, не более радостная.

Open Source: разработчики и спонсоры

LinuxFormat, #79 (май 2006)

Когда Red Hat и Novell диверсифицировали линейки своих Linux-дистрибутивов на как бы коммерческие и стопроцентно свободные ветви, они пошли разными путями. Во взаимоотношениях Suse и OpenSuse все ясно: вторая представляет собой, по сути, бета-версию собственно коммерческого продукта, на которой обкатываются инновации – то есть это Suse для смелых.

Взаимоотношения же Red Hat и Fedora Core эволюционировали во времени. Сначала наследница Корнея Чуковского представляла собой просто Красную Шляпу с чуть подрезанными (за счет не вполне свободного софта) полями и примятой (из-за отсутствия техподдержки) тульей. То есть своего рода Red Hat для бедных. Затем «беднякам» была предоставлена некоторая свобода – создается Fedora Foundation, призванный управлять проектом самостоятельно. И вот теперь поступает заявление, что фонд со своей задачей не справился, и проект Fedora Core возвращается под крыло родительской компании. Правда, руководство им будет осуществляться на паритеных началах с независимыми разработчиками.

Как это скажется на пользователях? Да, скорее всего, никак. Те, кто может себе позволить, будут продолжать покупать Red Hat ради технической поддержки. А те, кто в ней не нуждаются, найдут пути для решения возникающих проблем.

Kubuntu в роли пасынка?

LinuxFormat, #79 (май 2006)

Как известно, проект Ubuntu и его «дочерние предприятия» – Kubuntu и Edubuntu, – финансируются Марком Шаттлвортом. Однако он не прямо башляет разработчиков: для этого существует специальная компания Canonical, зарегистрированная на острове Мэн (Ирландское море), в задачу которой и входит справедливое распределение средств, выделяемых космонавтом-линуксоидом.

Однако именно справедливость распределения и была поставлена под сомнение разработчиками Kubuntu. В частности, и потому, что множественное число в отношении последних – некоторое преувеличение: кроме дюжины энтузиастов, по штату этим делом занимается один-единственный человек, Джонатан Риддел из Эдинбурга. Именно ему пользователи Kubuntu обязаны рекордными по срокам сборками новейших (и тестируемых) версий KDE. Недавнее интервью с ним можно было прочитать – правда, в нем Риддел на жизнь не жалуется. Да и, по слухам, на машине самого Марка стоит именно Kubuntu…

Примечание. За прошедшие годы проект Kubuntu активно развивался. В частности, именно с этим дистрибутивом связано самое большое внедрение Linux’а как десктопной системы за всю историю: к началу 2011 учебного года Kununtu была установлена на 42 двух тысячах школьных компьютеров Бразилии.

Однако вскоре после этого фирма Canonical прекрашает финансирование проекта по выходе версии 12.04, то есть следующий релиз (12.10) должен был бы разрабатываться уже «на общественных началах». Однако такого, вроде бы, не случилось: с мая 2012 года роль спонсора принимает на себя компания Blue Systems, известная финансированием ряда связанных с KDE проектов. Правда, при этом остаётся пока не решённым вопрос с торговой маркой Kubuntu – но,будем надеяться, он тем или иным способом будет решён.

Xubuntu: в благородном семействе прибыло

LinuxFormat, #80 (июнь 2006)

До сего дня Ubuntu распространялся в двух вариантах – собственно Ubuntu с Gnome в качестве десктопа, и Kubuntu, в котором его роль выполняет KDE. Что отсекало от него тех, кто питает симпатий к одной из этих сред. И вот – выход еще одного варианта, Xubuntu, приобщающего пользователя к африканскому гуманизму посредством десктопа XFce. Последний представлен здесь в бета-версии 4.4, существенно отличной от всех предыдущих.

Xubuntu – это самый обычный Dapper, укомплектованный штатными приложениями XFce (файловым менеджером Thunar, текстовым редактором mousepad, и т.д.). Сторонних приложений – также минимум: в качестве боаузера – Mozilla Firefox, почтовую службу отправляет Mozilla Thunderbird, обработкой картинок занят Gimp. Что же до конторских обязанностей – они возлагаются на AbiWord, ни малейшего OpenOffice.org мы тут не увидим.

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

Desktop’изация BSD

LinuxFormat, #81 (июль 2006)

Недавний выход релизов DesktopBSD и PC-BSD опять поднял вопрос о пригодности BSD-систем вообще к настольному применению. Обе эти системы – дистрибутивы FreeBSD, дополненные графическими инсталляторами на базе универсального BSD Installer, средой KDE в качестве пользовательского окружения, укомплектованные набором KDE-приложений. Сами по себе они интересны, но оставляют впечатление недоделанности. И, в сущности, представляют собой нечто среднее между демо-версией и трамплином для прыжка к настоящей FreeBSD.

Возникает закономерный вопрос – а почему бы не использовать на десктопе самую обычную FreeBSD? Тем более, что и сами ее разработчики предприняли некоторые шаги в этом направлении. Я имею ввиду недванее заявление Скотта Лонга о том, что отныне при развитии этой системы будут учитываться и интересы так называемых «простых» пользователей.

Речь идет об улучшении автоконфигурирования оборудования, в первую очередь – о разработке аналога механизма HAL (Hardware Abstraction Layer), позволяющего, в частности, подключать любые съемные носители прозрачно для пользователя. Конечно, и для многих пользователей Linux единственным средством для этого признается mount, а все остальное – от Глюкавого. Каюсь, и автор этих строк до недавнего времени был в их числе. Однако нынче, преодолев свой консерватизм, признаю, что HAL – штука крайне удобная. И ее внедрение во FreeBSD немало способствовало бы «desktop’изации» этой ОС.

Семь шагов Linux-дистрибуции

LinuxFormat, #82 (август 2006)

Первые дистрибутивы Linux, возникли из стремления избавиться от лишней ОС – ведь, чтобы сварить суп из курицы (Linux), следовало как минимум иметь кошку (MINIX). И, например, спасение пользователей от ада пакетных зависимостей оставалось делом рук самих пользователей – благо таковыми в то время были почти исключительно разработчики Linux’а же.

Потом началась эпоха промышленного применения это ОС – сначала в качестве сетевых узлов разного рода. И к пользователям-разработчикам присоединились пользователи-админы. Которые не имели времени на ручное разруливание зависимостей – и для них были придуманы первые дистрибутивы с контролем оных (Debian, Red Hat). В 1998 году впервые заговорили о продвижении Linux на пользовательские десктопы. Итогом их стало появление Mandrake – первого по настоящему юзерофильного дистрибутива. Однако скоро пользователи осознали, что на своих десктопах они являются также и администраторами, что вызвало волну популярности дистрибутивов Source Based – и пальму первенства пользовательских симпатий завоевал Gentoo. Каковой тоже не стал панацеей от всех бед – потребовались системы, совмещающие возможность полной пересборки с быстротой развертывания и простотой обновления – квинтэссенцией этого направления стал Archlinux.

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

И, наконец, нынче намечается обращение к истокам Linux-дистрибуции – в лице современных производных Slackware, в первых рядах которых выступает ZenWalk – максимально компактный, но легко наращиваемый. Каким будет следующий виток пользовательских предпочтений?

LinuxWorld 2006

LinuxFormat, #84 (октябрь 2006)

Может быть, кое-кто из моих читателей помнит чувство сопричастности высоким технологиях, охватывавшее посетителей первых компьютерных выставок в конце 80-х – начале 90-х годов прошлого тысячелетия. Или – первые выставки UNIXExpo середины 90-х, когда нашим глазам впервые предстала вся мощь рабочих станций, оснащенных разными вариантами одноименной операционной системы. Ну и, наконец, многим памятен прошлогодний каскад выставок, посвященных Open Source и Linux, оставивший ощущение того, что эти сферы перестали быть периферией IT-мира.

Традиция выставок продолжена была и в текущем году. Вслед за вторым Open Source Forum Russia настало время и LinuxWorld (4-5 сентября). Первое впечатление от нее – будничность. Немногочисленные посетители степенно беседуют с представителями экспонирующихся фирм. Что же до последних – ба, знакомые всё лица, в очередном перечислении не нуждающиеся. Не показатель ли это того, что мир Linux и Open Source окончательно миновал стадию ажиотажного развития и вступил в период планомерного практического применения? Думаю, так – и это не может не радовать. Но, с другой стороны, в жизни должно быть место празднику. Может быть, им станет грядущий LinuxLand? В момент, когда вы будете читать эти строки, ответ будет получен…

На злобу дня, или Oracle vs Red Hat

LinuxFormat, #85 (ноябрь 2006)

Нынче все сообщество Open Source всколыхнула новость о том, что Oracle будет выпускать свой Linux, предназначенный для запуска своей же СУБД. И не просто свой дистрибутив – а Red Hat цельнотянутый, освобожденный от «ненужных» компонентов, типа MySQL или Posgress. Первая реакция, естественно, была: вот он, звериный оскал капитализма, бездушного и бездуховного, при котором все покупается и все продается. Однако, если вдуматься по отгорании костров эмоций, чего такого страшного произошло?

Действительно, у Oracle, собственно, есть два пути. Первый – они будут делать свой дистрибутив узко-нишевого назначения – для запуска своей СУБД. Эта ниша хоть и глубока (в финансовом отношении), но все равно ниша, и широкие массы трудящихся никак не затрагивающая. Второй же вариант – создавать инфраструктуру для поддержки своего детища, то есть, в конечном счете, вкладывать в Open Source силы и средства. А это, в итоге, новые рабочие места для программистов открытого софта. От чего сообществу никакого вреда, окромя пользы, быть не может…

Ну а разговоры о морали, нравственности и тому подобных материях – они, конечно, интересны, но оставим их потомкам. Если ребята из Red Hat покажут себя настоящими мужиками и в этой драке выстоят, – что ж, уважение сообщества им гарантировано. Если нет – вспомним слова Олега Куваева: «Тех, кто утонул, замерз, умер от голода, спился – их не было здесь. И даже память о них затёрлась…»

Примечание. Прошло почти шесть лет. Red Hat не просто выстоял, а окреп технологически и финансово, претендуя нынче на роль гегемона Open Source. А Oracle действительно развивает свой дистрибутив сугубо «промышленного» назначения. Причём неплохо вписалась в мир Open Source, хотя и не вполне однозначно. Но в любом случае, ей мы обязаны развитием файловой системы btrfs.

Будущее Open Source: коммерциализация или сайентификация?

LinuxFormat, #86 (декабрь 2006)

Этот вопрос широко обсуждается в свете недавних событий, тех самых, что были тёрты-перетёрты как в «бумажной», так и «сетевой» периодике до такой степени, что о них как-то и упоминать уже неприлично. Однако они наводят на размышления несколько более общего характера. В частности – а не будет ли вмешательство в развитие Open Source софтверных гигантов началом конца свободного софта?

С одной стороны, да – нельзя исключить возможности превращения Linux’а, точнее, некоторых его дистрибутивов, в сугубо коммерческие, возможно, даже частично закрытые продукты. С другой же – вспомним, откуда начинались и UNIX, и Linux, и Open Source вообще? С научных лабораторий, университетов, академических организаций. И люди, его создававшие, никуда не пропадут, да и сферу своей деятельности сменят далеко не все. Так что коммерциализация построенной на Open Source и вокруг него инфраструктуры вполне может вызвать возвращение базовой его части к истокам – так сказать, сайентификацию этого явления. И тогда Open Source снова, как во времена создания BSD UNIX (да и более ранние) будет выполнять свои прямые функции – фундаментальных исследований в области Computer Science, тогда как коммерческие организации – прикладными работами и извлечением прибыли из оных. Что ж, так было всегда – одни люди занимались наукой, другие – ее использованием в практических, в том числе и коммерческих, целях…

2007

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

LinuxFormat, #87-88 (январь 2007)

Время от времени на форумах обсуждается вопрос о скорости загрузки различных ОС и дистрибутивов. В ходе которого мне неоднократно встречалась мысль, что Linux (или некий его конкретный дистрибутив) грузится очень долго (по сравнению с Windows XP), и это являет собой препятствие к его распространению на пользовательских декстопах.

Последнее мне представлялось весьма спорным: в большинстве случаев UNIX-машины используются непрерывном или близком к тому режиме, стартуя в худшем случае раз в сутки. Однако можно представить себе и ситуации, когда скорость загрузки оказывается важной – например, при всякого рода демонстрациях в режиме «пришел – показал – ушел». Вот я и решил проверить справедливость утверждения о медленности старта Linux-системы – в обыденной жизни я вижу его крайне редко, обычно после тотального обновления. Благо и повод подходящий представился – обновление моей Kubuntu Dapper до версии Edgy Eft, в которой впервые была применена новая система инициализации – upstart, особенность которой – «распараллеливание» отработки стартовых скриптов.

Измерения проводились на машине с AMD64 3500+ (реальная частота 2200 Mhz). Результаты были следующие: примерно 32 секунды от меню GRUB до приглашения к авторизации в KDM, и не более 40 секунд – до полной загрузки KDE при автоматической регистрации в системе.

Много это или мало? Судить не берусь – тут компетентным будет мнение коммивояжера или рекламного агента на выезде. Меня – устраивает.

Debian или Kebian?

LinuxFormat, #89 (февраль 2007)

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

Как? Самый простой способ – заглянуть на страницу, с которой можно скачать официальные снапшоты тестируемой версии, обновляемые еженедельно. Здесь мы увидим полный слепок дистрибутива в текущем его состоянии, ныне он насчитывает 22 диска, пронумерованных, как ни странно, с 1-го по 22-й. Но что мы видим в конце? Еще два образа первых дисков – debian-testing-i386-kde-CD-1.iso и debian-testing-i386-xfce-CD-1.iso. С помощью дедуктивного метода товарища Ш.Холмса не трудно догадаться, что второй из первых дисков предназначен для установки Debian с KDE в качестве умолчального десктопа, третий же предлагает в этом качестве среду XFce. Что же лежит на «первом» первом диске? Элементарно, Ватсон – методом исключения приходим к выводу, что на нем будет не иначе как GNOME.

Теперь остается только скачать какой-либо образ и проверить свои подозрения. Я, разумеется, проделал это с диском, подозрительным на присутствие KDE. И что же оказалось после установки с него? Оказалось, что, если инсталлировать Debian методом цыпленка, клюющего клавишу Enter, мы безальтернативно, даже в режиме эксперта, получаем рабочую станцию с KDE in corpore – включая kdeedu, kdegames, kdetoys. Благо, хоть без всех мыслимых и немыслимых локалей, входящих в состав kde-i18n. Будет в нашем распоряжении и kdewebdev – а вот собственно средств разработки KDE не окажется. И, как ни странно, не найдем мы в инсталлированной системе и KOffice – место его займет «вседесктопный» OOo.

По аналогии можно сделать умозаключение, что при умолчальной инсталляции с «первого» первого диска мы получим рабочую станцию GNOME, а с диска третьего – ее же, но в XFce-обрамлении. Ничего не напоминает? Если вы скажете, что напоминает Ubuntu, Kubuntu и Xubuntu – не смогу возразить. Так что же, теперь у нас вместо Debian’а будут Ге-биан, Ке-биан и Хе-биан? Можно было бы сказать и так. Однако установку с диска netinstall пока не отменили – и его посредством можно обзавестись базовой системой, которую останется только нарастить по собственному усмотрению. В общем, остается только повторить слова нашего великого Генсека: «Мне нравится».

Linux на Cell: уже реальность?

LinuxFormat, #89 (февраль 2007), не опубликовано

Не прошло и года, как я предавался умозрительным спекуляциям о Linux на платформе Cell – надо отметить, что реально машин с этим процессором тогда никто еще и в глаза не видел. Что же, теперь этот камень служит вместо пламенного мотора в игровой консоли Sony PlayStantion 3. У любого компьютерщика, поглядевшего на тактико-технические данные этой «игрушки», поневоле появится мысль: а как бы эту мощь приспособить для использования в мирных, то есть рабочих, целях?

Посудите сами: процессор Cell о восьми ядрах (правда, всего лишь семь из них заняты непосредственно делом, восьмое выполняет коммуникативные функции) и тактовой частотой 3,2 GHz, 256 Мбайт ОЗУ типа Rambus (наконец-то память эта нашла свое применение), винчестер от 20 до 60 Гбайт (двухдюймовики с SATA), видеоподсистема от Nvidia с 256 же мегабайтами собственной памяти. И это не считая всяких мелочей типа привода BlueRay, считывателя всяческих флэш- и прочих карт, портов USB, интерфейса WiFi… Ей-Богу, такое железо грешно использовать для банальных игр.

Однако каким образом прикрутить его к задачам производственным? Ведь в комплекте нет не только никакого соответствующего софта, но даже подходящей операционки. Разумеется, мысли тут же обращаются в сторону Linux. На сегодняшний день имеется лишь один дистрибутив, официально поддерживающий платформу Sony PS3. Это – Yellow Dog Linux, ранее ориентированный на Mac’и и процессоры PowerPC. Однако Linux-мир не оскудел умельцами: на Sony PS3 уже были успешно установлены и Gentoo, и Debian. А на сайте http://www-128.ibm.com/developerworks/ начата публикация цикла статей, посвященного программированию Linux-приложений для платформы Cell.

К сожалению, России не довелось быть не только родиной слонов, но и местом их оперативной продажи – до наших палестин эти «игрушки» пока не добрались…

Примечание. Как я уже говорил в одной из первых колонок 2006 года, мечтам о мирном использовании процессоров Cell сбыться было не суждено. И в первую очередь из-за позиции фирмы-производителя… нет, не самих процессоров (той, похоже, всё это было до лампочки), а построенных на их базе «игрателей»: Sony чинила к тому все возможные препоны и рогатки. А потом время ушло, и PS3 стали никому не интересны.

Дети капитана Патрика

LinuxFormat, #90 (март 2007)

На протяжении последнего времени наиболее часто в тематической печати фигурировали Red Hat и Debian со своими клонами. И как-то в тени остался третий кит Linux-дистрибуции, Slackware. Хотя исторически его следовало бы назвать первым.

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

В их числе следует назвать в первую голову ZenWalk – дистрибутив, избравший своим тотемом дельфина. И развивающийся со стремительностью, присущей этому морзверю: в конце февраля вышла его очередная версия (4.4 – напомню, что предыдущие чередовались с интервалом менее чем в полгода). Чем интересен этот дистрибутив? Если Ubuntu во всех его проявлениях можно считать одним из способов легкой, для начинающего пользователя, установки Debian, то ZenWalk играет ту же роль в отношении Slackware. Скачал образ диска размером несколько более 400 Мбайт, пользователь в считанные минуты получает компактную, но полностью готовую к употребелению систему – с чрезвычайно элегантно оформленным XFce в качестве десктопа, набором утилит, вполне достаточным для счастья, легкими офисными пакетами и инструментамиweb-редактирования, не вполне полной, но достаточной для начала поддержкой русского языка.

А дальше для наращивания мощи перед ним два пути. Первый – наименьшего сопротивления, то есть использование встроенной системы пакетного менеджмента, netpkg, не более сложной в обращении, чем apt или packman. Второй же – традиционное для Slackware и его потомков конструирование собственной системы.

CRUX – крестоносец идеи

LinuxFormat #91 (апрель 2007)

На заре тысячелетия ряд дистростроителей, утомленных сложностью юзерофильных дистрибутивов, обратился к истокам – первозданной простоте, свойственной Slackware, но уже на новом витке истории, с учетом накопленного опыта. На этой волне появились, почти одновременно, Gentoo, CRUX и Archlinux.

Судьба их оказалась различной. Gentoo, став самым популярным дистрибутивом в семействе Source Based, оказался центром большого и активного сообщества. Arch, развиваясь в направлении все большей пакетизации, приобрел менее широкий, но устойчивый и все более растущий круг пользователей. CRUX же, занимающий промежуточное положение (и во многом послуживший прототипом для Arch’а), по сей день остается мало известным. Релизы его выходят почти с годичным интервалом. Выход последнего (2.3, 20 марта 2007 года) и послужил поводом для этой колонки.

CRUX распространяется в виде образа CD в 200 Мбайт, содержащего прекомпилированную систему, включая не только X, но и WindowMaker. И разворачиваемую за считанные минуты. Такая компактность достигается за счет урезания «балласта» – в том числе всей документации, кроме man-страниц. Однако это – все: за пределами «базы» нет ни одного пакета, ни одного репозитория, только порты, посредством которых собираются все остальные приложения. Коллекция портов не поражает своим объемом, но всегда актуальна. Ну а чего в портах не найдется – тут уж «спасение утопающих» … сами знаете чье дело: сочинить собственный порт нужной программы в CRUX очень просто. И кстати: субъективно это самый быстрый дистрибутив, который я видел…

Обновление Debian-семейства

LinuxFormat, #92 (май 2007)

Знаковые события уходящего месяца – превращение Debian Etch в стабильный релиз (за номером 4.0) и выход Ubuntu (во всех ее ипостасях) версии 7.04. Если второе случилось точно по графику, то первое – с некоторым запозданием (впрочем, в масштабах времени Debian’а квартальное опоздание можно считать в пределах ошибки эксперимента). И, тем не менее, сопряженность выхода этих двух дистрибутивов – символична.

Два года назад, когда началось триумфальное шествие Ubuntu по пользовательским десктопам, возникло не лишенное оснований опасение – а не приведет ли это к кончине ветерана дистростроения?

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

Будем надеяться, что «мирное сосуществование» отцов и детей в Debian-семействе будет продолжаться. К вящей пользе тех, кто применяет того или иного его представителя.

Мир изменился…

LinuxFormat, #93 (июнь 2007)

И произошли эти изменения стремительно – на протяжении первых месяцев текущего года. Еще совсем недавно слова Open Source и Linux были не частыми гостями даже на страницах общекомпьютерной прессы, выставки и конференции этой тематики, хотя и имели место быть в последние годы, собирали исключительно узкий круг профессионалов. А Linux-сайты и форумы, хотя и были традиционно многочисленными, посещались лишь энтузиастами (и теми, кто готовился таковыми стать).

Что же мы увидели за истекшие месяцы? Слова Open Source и Linux на страницах СМИ, по крайней мере онлайновых.

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

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

Хорошо это или плохо для Linux и Open Source – покажет время. Однако можно тешить свое тщеславие – к текущему изменению мира руку приложили и мы…

Не спрашивай, что ты сделал для Linux’а…

LinuxFormat, #95 (август 2007)

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

Дистрибутив типа Ubuntu/Kubuntu разворачивается до полностью работоспособного состояния за полчаса, и не требует никаких дополнительных действий (кроме разве что сугубо косметических). Не намного больше времени уйдет на установку Archlinux или Zenwalk, которые не считаются эталонами дружественности. И тем не менее требуют только многократно документированной правки пары-тройки конфигов. Правда, все это – при условии хорошего доступа к Сети.

У вас проблемы с коннектом? И это не смертельно, Mandriva, например, может быть полностью укомплектована без доступа в Интернет вообще. Вероятно, то же самое относится к Suse, Fedora, клонам Red Hat (я говорю только о тех системах, которые «щупал» в последнее время). И писать о настройках системы нынче становится просто смешно.

Так что же, братья-линуксописатели, пора переквалифицироваться в управдомы? Отнюдь. Наступает время, когда можно спокойно начинать писать о том, что относится к непосредственной сфере деятельности. Не о том ли мечтали мы долгие годы?

SCO’тский вопрос

LinuxFormat, #96 (сентябрь 2007)

В последние дни в новостях и на форумах интенсивно обсуждается судьбоносное решение суда по делу между Novell и SCO. А также комментарии заинтересованных сторон, последовавшие за ним. Повсеместно задаются вопросы: хорошо это или плохо? А я задам другой вопрос: а есть ли предмет для обсуждения?

Действительно, а что нового мы узнали из решений и комментариев? Что права на торговую марку UNIXTM (а это слово – не более, чем торговая марка) принадлежат консорциуму The Open Group, вроде бы никто никогда не сомневался. А уж что такое исходный код UNIX – тайна сия велика есть. Особенно с учетом того, что последним чистым UNIX’ом от AT&T была SystemVR3 – потому что в R4 было столько BSD-кода, что на ум неизбежно приходил вопрос – где кончается полиция и где начинается Беня Крик? На который резонные люди из Одессы дали ответ много лет назад…

В Linux’е есть код первозданного UNIX’а? Хрестоматийный пример с malloc показывает, что это нечто вроде какашек от ихнего пуделя, давно отошедшего в мир верхних собак.

Так что, дорогие коллеги, мы просто являемся зрителями очередного матча по национальному американскому виду спорта – публичному судилищу. Кто судит, кого, за что и почему – никого не волнует. Да и между кем матч проходит – тоже по большому счету не важно. Главное – нагнетать азарт зрителей и болельщиков. Типа как для разминки…

И зададимся последним вопросом: а нам оно нужно? Не лучше ли размяться на перекладине, помолотивши кулаками по макиваре, помахавши бокэном… (нужное дописать)? А потом со свежими силами взяться за свое непосредственное дело. И пусть нас не волнуют ихних глупостей…

P.S. Типа дисклаймера – всем предыдущим я ни в коем случае не хотел обидеть создателей UNIX’а – их идеи живут и побеждают. Вот только какое к ним отношение имеют торговые марки и прочая лабуда?

ZFS: конец файловым проблемам?

LinuxFormat #97 (октябрь 2007)

Разметка диска и файловые системы – те немногие элементы «высшей математики» POSIX’ивизма, представление о которых не помешает любому пользователю. Причем получить его желательно до установки первого дистрибутива. Иначе трудно исключить ситуацию, когда будет мучительно больно за бесцельно потраченное дисковое пространство в одной ветке файлового древа и острую нехватку оного – в другой.

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

ZFS, похоже, предлагает окончательное решение этого вопроса. Эта 128-битная (!) файловая система была разработана фирмой Sun для ОС Solaris. Потом она была включена в OpenSolaris, портирована во FreeBSD и (через FUSE) поддержана Linux’ом. Ожидается, что она будет файловой системой по умолчанию в MacOS X «Leopard».

В ZFS наличное дисковое пространство предстает в виде единого пула (zpool), доступ к которому могут иметь все включенные в него ветки файловой иерархии. Кроме того, 128 разрядов ZFS гарантируют, что с ограничениями на ее размер не придется столкнуться за всю грядущую историю человечества. По словам создателя XFS, Джеффа Бонвика, для этого пришлось бы вскипятить океан. Наконец, целостность данных и быстродействие при доступе к ним – тоже не последние козыри этой ФС.

Похоже, буква Z в названии действительно символизирует… точку в развитии файловых систем.

Mandriva на Руси: второе нашествие Бонапарта?

LinuxFormat, #98 (ноябрь 2007)

Дистрибутив Mandriva издревле пользовался на Руси большой популярностью – еще с тех пор, как именовался Mandrake и в ипостаси Russian Edition распространялся IPLabs Linux Team (впоследствие Altlinux). После же создания Mandriva.ru – не просто представительства компании, а официального, наряду с французским и бразильским, центра разработки, – популяризация и внедрение ее пошли семимильными шагами. Серия мастер-классов, прошедших от Москвы до самых до окраин, официальные курсы с сертификацией, центральное положение на недавно прошедшем Софтуле, сертификация по требованиям безопасности ФСТЭК, продвижение в качестве образовательного софта для школ и ВУЗов Ханты-Мансийского автономного округа… Иными словами, Mandriva имеет все шансы стать дистрибутивом номер 1 в России.

Не присутствуем ли мы при рождении нового монополиста – теперь уже от мира Open Source? Не исключаю, что Mandriva займет господствующее положение в сфере российского образования. А возможно, даже и госчиновничества. Вот только монополией это не будет по определению – ибо не оскудели просторы FOSS более иными дистрибутивами. UNIX остается UNIX’ом и в Югре, и в Ботсване. И школьник. получивший первичные навыки работы в Mandriva, без труда адаптируется к любому другому дистрибутиву Linux или BSD-системе.

Так что не стоит бояться нашествия Бонапарта с его двунадестью народами. А разве что порадоваться тому, что именно Mandrake был одним из пионеров интернационализации Linux’а…

Linux и творческая интеллигенция

LinuxFormat, #99 (декабрь 2007)

В последнее время много говорится о Linux в образовании, что, конечно, очень благородно. Но стоит взглянуть на этот вопрос с другой стороны: а что используют инженеры человеческих душ, на произведениях которых, когда они станут классиками, будет учиться подрастающее поколение? Будучи модератором на нескольких литературных форумах, я часто задавался вопросом: каковы побуждения поэтов и писателей к использованию Windows и ее приложений, в первую очередь, MS Office, из которого реально применяется, естественно, только Word?

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

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

Вторая же, и, как мне кажется, главная причина – это просто незнание возможностей обработки текста, которые предоставляют связка из текстового редактора и полудюжины классических UNIX-утилит. Так не помочь ли братьям-литераторам узнать о них? Это высвободит им время на сочинение тех самых вечных произведений, которые будут читать наши дети и внуки…

2008

Поэзия – Linux’у

LinuxFormat, #100/101 (январь 2008)

В предыдущей колонке я затронул тему Linux’а и творческой интеллигенции – чисто в академическом аспекте, мол, хорошо бы поэтам и писателям повнимательнее присмотреться к открытому софту и «альтернативным» операционным системам. Но сегодня можно констатировать, что приобщение творческой интеллигенции к миру свободных операционок началось: 15 декабря 2007 года Linux был торжественно установлен на ноутбук Алисы Деевой, поэтессы, создателя литературных порталов Игнения и Фабула.

Я, конечно, знаю, что многие линуксоиды – поэты в душе, и среди них немало и таких, которые претворяют душевные порывы в строки и строфы. Но чтобы сложившийся поэт, далекий от IT-сферы, обратился бы к Linux’у – такого, как говорится, старожилы не припомнят.

В качестве дистрибутива был выбран Kubuntu 7.10 (i386) – ведь для пользователя-гуманитария наиболее подходящим будет самый гуманистический из всех Linux’ов. И практика подтвердила правильность выбора: несмотря на препоны и рогатки, обусловленные особенностями локального провайдерства, система была благополучно установлена и поступила в эксплуатацию. В результате на Руси появился первый поэт-линуксоид.

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

Примечание. Эти ожидания пока не оправдались. Но первый сборник стихов и прозы Алисы Деевой в виде электронных книже различного формата вы в Библиотеке Блогосайта увидеть можете.

Nexenta, или еще раз о жирафе Анюте

LinuxFormat, #102 (февраль 2008)

Вышел очередной кандидат в релизы операционной системы Nexenta. Чем она примечательна, эта система? Для начала – ядро от SunOS, известной в народе как OpenSolaris (хотя нынче мало кто помнит, что Solaris – собственно говоря, интегрированная среда, а ядро этой операционки как называлось испокон века SunOS, так и продолжает носить это имя по сей день). Что, соответственно, обеспечивает поддержку «из коробки» самой совершенной файловой системы всех времен и народов – ZFS.

Далее – хотя все низкоуровневые утилиты, разумеется, унаследованы от материнской системы, но остальное обрамление чуть более высокого уровня – стандартный набор приложений GNU, привычных любому пользователю Linux’а.

И, наконец, система управления пакетами. А это – самая обычная deb-based система, использующая apt. Привычная, конечно, не каждому – но любому, кто сталкивался с Debian и его клонами. Правда, репозиторию бинарников Nexenta далеко до богатства самого Debian’а или Ubuntu. Тем более, что, начиная с нынешнего кандидата в релизы, разработчики прониклись мыслью Козьмы Пруткова. И потому получил он имя – Nexenta Core Platform. То есть это скорее основа для сборки собственной полнофункциональной системы. Будет ли кто-то этим заниматься? Вопрос спорный. Но почему бы и нет? Сочетание ZFS и удобства deb-пакетов – достаточно хороший стимул. Тем более, что нативной поддержки ZFS в дистрибутивах собственно Linux в ближайшее время ожидать не приходится.

Семинары, семинары…

LinuxFormat, #103 (март 2008)

С чего начинается Родина? Известно, с чего – с картинки в твоем букваре. А с чего начинается информатика? Со школьной скамьи. И именно этому (впрочем, как и ВУЗовской скамейке) был посвящен семинар, прошедший в Санкт-Петербурге 24-25 января 2008 года. Говорили там о многом – и об истории свободного софта на Руси, и о теоретически-юридических аспектах его использования, и о практике этого дела в его правовой ипостаси. О практике применения свободного софта говорили тоже.

Однако… А для чего учат в школе и ВУЗе? Не для того ли, чтобы полученные знания использовать в практической работе? И потому семинар в Старом Осколе выглядел как бы логическим продолжением Санкт-Петербургского. Потому что на нем говорили уже о внедрении свободного программного обеспечения на реально работающих предприятиях – горно-обогатительных комбинатах, электрометаллургических и машиностроительных заводах, строительных предприятиях и так далее. Будет ли оно успешным? А вот это зависит от многих факторов. В том числе и от наших с вами усилий. Поле для приложения сил – огромно, и не только в Старом Осколе. Цели ясны. Задачи определены. За работу, товарищи?

Сделайте мне … хорошо

LinuxFormat, #104 (апрель 2008)

Вековечная мечта пользователей Linux – чтобы все работало «из коробки», похоже, близка к осуществлению. Что можно наблюдать на примере альфа-версии Kubuntu – 8.04. Устанавливаемая, как и раньше, сполпинка, что в варианте Desktop, что в инкарнации Alternate, она более не требует ничего – никакой докачки кодеков для всяческой мультимедии. Как разрулили правовые проблемы – не знаю. Но факт остается фактом – вся музыка и видео заиграли у меня сразу. То есть уже не требуется запроса – сделайте мне … хорошо. Потому что ответом будет – а тебе и так хорошо.

К слову сказать, в Kubuntu 8.04 штатно идет KDE 3.5.9. Отлаженный, вылизанный просто до неприличия – никогда не думал, что бывают столь доведенные до ума программы.

А что же KDE 4, о котором столько говорили большевики, меньшевики и прочие анархо-синдикалисты? Джонатан Риддел сделал сборку Kubuntu и с KDE 4. Лично меня она очень удручила. Вроде бы как есть у нас GNOME для домохозяек, не так ли? Так зачем превращать KDE в его подобие? Впрочем, это тема для совсем отдельной истории…

Как вас теперь называть?

LinuxFormat, #105 (май 2008)

Linux или GNU/Linux? Какое из этих названий больше соответствует идеалам свободного софта и открытых исходников? Этот древний вопрос был активизирован в результате недавнего визита в Москву Ричарда Столлмана, широко известного в узких кругах как RMS. Как известно, когда при нем говорят «Linux», он всегда поправляет – «GNU/Linux». Есть ли на то основания?

При всем уважении к деятельности RMS как пропагандиста идей свободного софта, нахожу, что оснований для этого не так уж и много. Да, Линус при разработке своего ядра использовал программы из проекта GNU – в том числе и такие не второстепенные, как компилятор gcc и bash. Но полагать, что всё системное окружение ядра Linux (вроде средств обращения с файловыми системами) – производные от программ GNU, мягко говоря, неверно. Пользовательские утилиты – да, в основном GNU’того происхождения. Но если уж говорить о пользовательском окружении вообще – то большинство пользователей работает всё-таки в Иксах. Поэтому не меньше оснований называть систему в целом X/Linux. А поскольку просто в Иксах работать невозможно – без использования оконного менеджера или интегрированного десктопа, – то логично говорить о системе KDE(GNOME, WindowMaker – нужное дописать)/Linux.

Ну и не последний аргумент против GNU/Linux, по моему мнению, – просто банальное неблагозвучие с точки зрения русского языка. Не говоря уж об ассоциациях с «Антилопой гну» из всем известного романа…

Ханс Рейзер: точка в деле?

LinuxFormat, #106 (июнь 2008)

Итак, дело Ханса Рейзера, создателя файловой системы ReiserFS, обвинявшегося в убийстве своей жены, можно считать законченным. Вердикт присяжных: виновен в убийстве первой степени. То есть – заранее обдуманном и предумышленном. Шансы на пересмотр вердикта, как говорят люди, знакомые с американской правоохранительной и правоприменительной системой, практически нулевые. Тем не менее, никакой ясности в деле так и не появилось – более чем за полтора года.

С самого начала дела меня преследовало ощущение deja vu – где-то я с этим уже сталкивался. А потом понял – это же повторение сюжета недописанного романа Чарлза Диккенса – «Тайна Эдвина Друда». Со всеми его атрибутами: исчезновением человека, отсутствием трупа, косвенными уликами и явным подозреваемым, против которого нагнетается отношение общества. Разница лишь в том, что в романе речь идет о литературных героях и злодеях, а в нашей истории – о реальных людях, наших современниках…

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

Однако печально всё это. В том числе и потому, что файловой системы Reiser4 мы, скорее всего, не увидим уже никогда…

PS. На всех машинах вашего покорного слуги стоит ReiserFS третьей версии. Reiser4 тоже стоит на одном из разделов – в экспериментальных целях…

Примечание. С тех пор в деле появилось много всего – и тело, и признание. Не прибавилось одного – ясности (А.Ф., август 2008).

Безальтернативность: всегда ли это плохо?

LinuxFormat, #107 (июль 2008)

Linux всегда ценился его пользователями за свободу выбора. В области дистростроения это нашло своё выражение в том, что инсталляторы наиболее прогрессивных дистрибутивов предоставляли всё большие возможности выбора пакетов, а сами пакеты становились всё более дробными. Апогей этой линии развития – Debian, в котором авторский пакет может делиться делиться на множество автономно устанавливаемых пакетов дистрибутивных. С учетом зависимостей, разумеется, но, при желании, исключительно «жестких».

И вдруг – появление дистрибутивов с безальтернативной установкой жестко заданного набора приложений. Наиболее ярко это проявилось в Ubuntu и Zenwalk. Не смотря на несхожесть, эти дистрибутивы позиционируются одинаково, предназначаясь для двух полярных групп пользователей: совсем начинающих и многоопытных, которые вдоволь наигрались в пересборку ядра, компиляцию «с нуля» собственной системы, индивидуальный выбор пакетов…

С точки зрения обеих групп, безальтернативность установки – это благо. Начинающий пользователь еще не знает назначения пакетов и не способен на сознательный выбор. А пользователь многоопытный выбирает не пакеты, а дистрибутивы, наиболее соответствующие его вкусам. А поскольку со временем абсолютная численность тех и других растёт – растёт и популярность «безальтернативных» дистрибутивов.

Какой Linux учить?

LinuxFormat #108 (август 2008)

Последнее время кто только не говорит о необходимости внедрения Linux’а повсеместно – в школах, ВУЗах, на производстве. Что же, с этими утверждениями спорить трудно – надо его внедять везде, где это целесообразно. Вот только внедрение Linux’а требует одной малости – знания предмета внедрения.

А с этим и на производстве, и в ВУЗах, и тем более в многочисленных школах наблюдается некоторая напряженка: не вырастила страна за чёртову дюжину лет существования Linux’а на Руси достаточного количества специалистов по этой системе – тех, которые могли бы не просто внедрить Linux, но и обучить собственные кадры на объектах внедрения. То есть этих специалистов еще предстоит обучить Linux’у – или они сами должны ему обучиться.

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

Первая, наиболее распространенная, – что начинающие пользователи и будущие гуру должны учиться наиболее дружественным к пользователю системам; в этом ряду чаще всего называют Fedora, Ubuntu, Mandriva, Altlinux – тем более, что два последних дистрибутива начинают утверждаться в российских школах. Недостатки этого подхода очевидны – риск «утонуть» в дистро-специфических деталях и отсутствие стимула к углубленному изучению предмета.

Вторая точка зрения, менее распространенная, гласит, что будущих гуру надо учить по «методу большого болота», то есть системам типа Slackware, Gentoo, Arch. Резон к тому очевиден – выбравшемуся из большого болота лужи малые будут нипочем. Однако многие ли без предварительной подготовки смогут из большого болота выбраться?

И потому рискну выскать третью точку зрения (ведь реальный мир не бинарен, а как минимум троичен, что будет темой следующей колонки): учить надо такую систему, которая обеспечит поэтапное вступление в мир Linux’а, объединяющую быстроту и легкость развертывания «юзерофильных» дистрибутивов с предоставлением условий для углублённого изучения системы. И как минимум один дистрибутив, объединяющий в себе эти качества, есть: Zenwalk Linux.

LinuxFormat: юбилей в троичном счислении

LinuxFormat, #109 (сентябрь 2008)

В сентябре журналу LinuxFormat – единственному в России специализированному периодическому изданию по одноименной тематике, – исполняется три года.

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

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

А теперь откроем любой номер за текущий, 2008, год: минимум половина материалов принадлежат отечественным авторам, в том числе – законченные и продолжающиеся циклы статей по различным вопросам программирования, компьютерной графике, издательским системам. Циклам, вполне способным трансформироваться в книги – и примеры этому уже есть. А чего бы еще хотелось – это в ознаменование трехлетнего юбилея увидеть в журнале статью о троичном компьютинге – ведь идеи этого развивались в то время, когда всё программное обеспечение представляло собой Open Source, если не по букве, то по духу.

Xfce: назад в будущее?

LinuxFormat #110 (октябрь 2008)

Зададимся вопросом: чего мы хотим от интегрированной рабочей среды? Богатства и гибкости настроек? Их простоты и прозрачности? На все эти вопросы я ответил бы положительно, хотя в качестве главного фактора выделил бы сквозной характер настроек.

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

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

Не роняет ли это высокое звание интегрированной среды? Отнюдь. Как наполнить среду приложениями, необходимыми для практической работы именно нам – каждый из нас знает лучше любого разработчика и майнтайнера. Роль же среды – «радовать глаз гармонией цветов и не отвлекать от собственно работы» (attila с http://forum.posix.ru, которому автор выражает свою признательность).

Будем надеяться, что эта добрая традиция продолжится и в грядущей Xfce 4.6, альфа-версия которой только что была выложена для всенародного тестирования.

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

FreeBSD на десктопе

LinuxFormat, #111 (ноябрь 2008)

Если «десктопизацию» Linux’а можно считать свершившимся фактом, то в отношении FreeBSD картина вырисовывается более противоречивая. С одной стороны, тенденция в сторону «пользовательских столов» не миновала и эту ОС – как саму, так и её юзерофильных отпрысков вроде PC-BSD и DesktopBSD. С другой же, всё громче слышен грозный ропот админов: «FreeBSD – это святое, юзеры, уберите от неё свои грязные десктопные лапы». Где же истина?

Как обычно, посередине. Начнём с того, что админы совершенно необоснованно присвоили себе эксклюзивные права на FreeBSD, в чём легко убедиться, вспомнив историю. Ведь это была первая из берклианских систем, ориентированная на самую демократическую платформу того времени – i386, каковая, очевидно, и предназначалась для столь же демократической публики, то есть для пользователей. Правда, тогда довольно специфических, всё больше специалистов в области Computer Science, но тем не менее, никаким боком не системных администраторов. То, что последним удалось прикрутить эту ОС к своим потребностям, лишь идет в плюс и ей, и им, но не даёт ни малейших прав собственности.

Ну а создатели «настольной FreeBSD» просто пошли проторенным путём майнтанеров юзерофильных дистрибутивов Linux’а, без учёта её собственной специфики (и специфики пользователей, для которых она создавалась).

Так не настал ли исторический момент вернуть FreeBSD на десктопы пользователей такой, какая она есть? Со всеми её нынешними усовершенствованиями, но без новомодных вытребенок. Ведь (позволю процитировать сам себя) главная причина неиспользования FreeBSD на десктопах – в том, что её мало кто там использует. Попробуем?

Пердем – персональный демон

LinuxFormat #112 (декабрь 2008)

Все знают, что пермаш – это персональная машина, пердач – персональная дача, перпен – это… нет, не то, что вы подумали, а персональная пенсия, и так далее. А вот что такое пердем?

Это – персональный демон, система PC-BSD, дистрибутив ОС FreeBSD, недавно появившийся в инкарнации 7.01, причём сразу в вариантах для архитектур i386 и x86_64. От своей праматери он отличается программой инсталляции, работающей в графическом режиме, и собственным менеджером пакетов собственного же формата – PBI, крамольного с точки зрения настоящих юниксоидов. Ибо каждый такой пакет не линкуется динамически с разделяемыми библиотеками, а заключает все необходимые функции «внутре». Впрочем, использовать эти пакеты никто не неволит: в распоряжении пользователя PC-BSD по прежнему остаются классические порты FreeBSD, да и сама система обновляется традиционной пересборкой ядра и «мира».

Впрочем, и главная особенность инсталлятора PC-BSD не в том, что он графический и красивый. И даже не в том, что на выходе выдаёт работоспособную систему, укомплектованную необходимыми приложениями, правда, подходящую только тем, кто не испытывает отвращения к KDE 4-й ветки. Нет, главное в нём – возможность не просто задействовать файловую систему ZFS на этапе установки, но и разместить на ней корень файловой иерархии. То есть легко и быстро выполнить ту процедуру, которая в классической FreeBSD требует некоторых ручных действий (заметим, не очень сложных, но всё же…). И еще: автоматическое монтирование сменных накопителей – то самое, служащее поводом для обвинения «фришников» в суровости, в PC-BSD работает «из коробки», через механизм HAL. Который в собственно FreeBSD также доступен – но также требует некоторых мануальных пассов.

Из сказанного ясно, кому будет полезна PC-BSD: тем, кто хотел ознакомиться с новшествами берклианского мира, но пока ещё морально не готов затрачивать на это усилия сверх самых необходимых. Теперь им и пердем в руки.

2009

Серенада солнечной долины…

LinuxFormat, #113-114 (январь 2009)

… была исполнена при очередном релизе OpenSolaris – 2008.11. И у тех, кому еще не довелось ее прослушать, возникает вопрос: что это? В двух словах – нечто вроде Ubuntu на ядре SunOS: та же мгновенная безальтернативная инсталляция ОС, рабочего окружения (GNOME) и необходимого для начала набора приложений, автоматическое (и, если повезет, успешное) определение оборудования, локализация «из коробки», простой в использовании диспетчер пакетов, набор графических фронт-эндов к системным утилитам. Плюс прозрачная для пользователя разметка диска под файловую систему ZFS.

То есть вековая мечта о «десктопном UNIX’е с человеческим лицом» оказывается близкой к реальности, как никогда. Конечно, не без недочетов, и местами весьма неприятных. За время знакомства с системой я несколько раз переходил из состояния полного восторга к глухой неприязни и обратно. Только вот скучно не было ни разу…

Думается, и ориентирована эта система на те же полярные категории пользователей: а) тех, для кого это будет первой системой – то есть пользователей, не имеющих еще сложившихся предпочтений, и б) тех, кто уже всё знает и умеет. С одной оговоркой: всё знает именно о Solaris – тем, что ведет она себя часто не так, как мог бы ожидать пользователь Linux или BSD, и объясняется поднимающееся иногда раздражение.

Сможет ли OpenSolaris занять на десктопах то место, которого он, несомненно, достоин? А вот это будет зависеть от того, наберет ли он достаточную пользовательскую базу. Причем из той категории, промежуточной между «полными ньюбами» и «законченными Solaris-гуру», для которой его, кажется, не предназначали. Для чего нужно – побольше пакетов и охват «железа» пошире. И тогда будет стимул для освоения «солнечной» специфики.

Файловая система btrfs: Linux-ответ ZFS?

LinuxFormat, #115 (февраль 2009)

После появления ZFS, объединившей в себе файловую систему и систему управления томами, трудно было ожидать чего-то принципиально нового в этой области. Однако в Linux, по лицензионным соображениям, она может использоваться только через FUSE, что лишает её основных преимуществ перед файловыми системами традиционными. И потому в этой ОС не замедлили появиться свои решения. Самым оригинальным из них оказалась btrfs, последние версии которой уже включены в релиз-кандидаты грядущего ядра 2.6.29.

Подобно ZFS, btrfs – интегрированная среда, включающая файловую систему и систему управления томами, в том числе на многодисковых устройствах, превращая в анахронизм как программные RAID, так и LVM. По простоте использования она ничуть не уступает ZFS, а по быстродействию, даже на однодисковом пуле, несколько превосходит, оставляя позади по большинству показателей все традиционные файловые системы. Очень важно, что btrfs даёт возможность безболезненной конверсии в неё из ext2/ext3 и обратно.

Таким образом, btrfs удовлетворяет двум из трёх главных требований к системам хранения данных и управления ими. Третье требование – надёжность, но о ней можно будет судить только после испытания временем. А подвергнуть её таковому – это и в наших силах тоже: начинать использовать её в экспериментальном режиме можно здесь и сейчас.

Тётя Ася или дядя Джаббер?

LinuxFormat, #116 (март 2009)

Службы обмена мгновенными сообщениями вошли в нашу жизнь давно и уже прочно – и личную, и в общественную. А в нашей стране они почему-то прочно ассоциируются с ICQ – «аська» стала столь же нарицательным именем, как аспирин или ксерокс. Может быть, потому, что народу с давних пор памятна тётя Ася, никогда не приезжавшая в гости без поллитры… отбеливателя?

И потому столь болезненно на наших согражданах отзываются регулярные смены протоколов, коими AOL – владелец сервиса ICQ – пытается прижучить пользователей альтернативных его клиентов. И которые на несколько дней – до выхода патчей или рассасывания естественным образом – парализуют всё общение, осуществляемое через тётю Асю.

Конечно, пользователей Linux’а это затрагивает мало: каждый из них давно озавёлся Jabber-аккаунтом как запасным или основным. Но разве в нашем, товарищи, духе бросать на произвол судьбы братьев-вендузяднегов? И особенно – сестёр-вендузяднец? И не наш ли долг – помочь им в сориентироваться в море альтернативных средств общения?

А ведь средств этих – воистину без счёта: каждый пользователь служб gmail или yandex, обладатель «живого журнала» или «живого интернета» – потенциальный пользователь Jabber’а, причём стать пользователем кинетическим он может, подчас не меняя своего любимого IM-клиента. И единственное, что для этого нужно – просто узнать о такой возможности.

Так что не окажется ли тётя Ася в роли той самой унтер-офицерской вдовы, которая сама себя высекла?

Нет OEM’ным ОС?

LinuxFormat, #117 (апрель 2009)

Изо всех концов нашей необъятной Родины мы давно слышим стоны – по непосильному бремени насильно навязываемой нам Windows, предустанавливаемой на компьютеры. И вот стоны эти были услышаны – ЦеСТ начал таки нещадную борьбу с нетрудовыми доходами производителей, продающих OEM ОС в нагрузку к «железу», за сохранность наших с вами кошельков. Что же, удачи им в этом благородном деле. Лично я ничего не имею против без-win’ных компьютеров, точнее, меня этот вопрос не волнует даже в финансовом отношении – номинальная стоимость Windows в OEM-исполнении всё равно нивелируется разницей цен разных магазинов и их внутренними курсами пересчёта условных единиц в безусловные.

А вот с главным обоснованием этой акции – оторвать «железо» от «софта» вообще и от ОС в частности, – я бы как раз поспорил. В древние времена, когда машины были большими, «софт» всегда затачивался под конкретное «железо», а «железо» – под «софт», и процесс этот был двунаправленным. Потом наступили времена кросс-платформенных решений. Ныне этот путь исчерпан: единственная возможность повышения производительности в IT-сфере – вернуться к «взаимозаточке» аппаратных и программных компонентов. Что очень хорошо можно видеть на примере «нетбуков» и прочих мобильных устройств. Так может быть, вместо того чтобы бороться за мифический OEM-серебренник, подумать о том, как «затачивать» Linux под современное железо? Глядишь, тогда и «железо» начнут затачивать под Linux…

Debian GNU/kFreeBSD: знает ли мсье толк в извращениях?

LinuxFormat, #118 (май 2009)

Поводом для настоящей заметки послужило сообщение о том, что проект Debian GNU/kFreeBSD получил статус официального в рамках «надпроекта» Debian. В двух словах, это – ядро FreeBSD, надстроенное комплексом системных и пользовательских утилит GNU и пакетной инфрастурктурой Debian, причём весь юзерланд и прикладной софт собирается с glibc вместо BSD libc.

О самом дистрибутиве говорить не буду, дабы не укреплять далее репутацию злобного Зоила. Но позволю задать себе вопрос: а за каким зелёным это нужно? Нет, конечно, нарастить ядро и юзерленд FreeBSD (между нами говоря, гармонично друг с другом увязанными) можно, вместо традиционных портов, любой другой системой пакетного менеджмента. Но зачем же менять юзерланд? Ведь BSD-окружение либо функционально эквивалентно GNU’ому, либо (ИМХО, конечно) превосходит последнее.

Надо сказать, что такой проект – FreeBSD Distributions на базе BSD libc в обрамлении apt-get’а – некогда существовал, и выглядел куда более логичным. Но прекратил своё развитие, в частности, по причине физического краха сервера.

Единственное объяснение столь противоестественного гибрида я вижу в возрождении имперских амбиций Debian’а…

Мир без солнца

LinuxFormat, #119 (июнь 2009)

Разговоры о продажи фирмы Sun циркулируют в Сети давно. А ныне факт покупки её компанией Oracle можно считать почти свершившимся: юридические вопросы с иском акционеров, недополучивших, как им кажется, своего бабла, по мнению знающих людей, будут улажены легко.

Какие следствия для мира FOSS будет иметь исчезновение старейшей UNIX-компании? Напомню, что на её иждивении находится ряд крупных свободных проектов – Openoffice.org, MySQL, VitrualBox, не говоря уже о собственно ОС – OpenSolaris, и ряде средств разработки. Не загнутся ли они под чутким руководством Ларри Эллисона?

Наибольшие опасения вызывает судьба OpenSolaris: а нужна ли будет Oracle ещё одна ОС, в добавление к собственному клону RHEL? ОС, за время своего «свободного плавания» не достигшая ни полностью работоспособного состояния, ни критической массы комьюнити? Мне кажется, что ответ будет отрицательным. Но так ли это страшно? Все здоровые инновации OpenSolaris (а их немало) могут быть легко инкорпорированы в Linux. И, чем чёрт не шутит, вдруг новые хозяева изменят лицензию на ZFS? После чего она легко впишется в Linux-ядро.

А за остальные свободные проекты Sun’а волноваться нечего: MySQL выступит «легковеным» дополнением к собственно Oracle, OpenOffice.org не бросят, как востребованный конечным пользователем, VirtualBox, Sun Studio etc. – как интересные для всех разработчиков.

И как знать, не увидим ли мы вскоре нового монополиста – теперь уже в сфере свободного софта? Да ещё в сцепке с собственной аппаратной платформой: не зря ведь Ларри обмолвился, что «Sparc не бросим, потому что он хороший».

Будут ли машины большими?

LinuxFormat, #120 (июль 2009)

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

И возникает вопрос – а нужны ли нам гигагерцы и гигабайты? Да, нужны. Один раз в жизни – когда мы собираем ядро (если, конечно, это вообще потребуется). И какова потребная мощность? Ну ясно, что какой же русский не любит быстрой езды? То есть, пардон, компиляции? Отвечаю: ядро Linux’а с умолчальным конфигом на машине с 3 Ггц и 4 Гбайт собирается где-то минут 7. На недобуке о 800 Мгц и 512 Мбайт памяти – раза в четыре дольше. Это важно? Особенно учитывая, что наш недобук ещё и электроэнергии потребляет куда меньше…

NILFS выходит из тени

LinuxFormat, #121 (август 2009)

Ядро Linux версии 2.6.30 порадовало нас, в числе прочих новшеств, и поддержкой NILFS (New Implementation of a Log-Structured File System) – Лог-структурированной Файловой Системы в Новом Исполнении. И действительно, в ряду ФС последнего поколения, таких, как более известные ext4 или btrfs, она выделяется рядом особенностей.

Во-первых, журналирование осуществляется по принципу log-файлов, то есть без перезаписи изменений, а лишь с дополнением журнала изменения состояния файловой системы.

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

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

Все эти особенности должны способствовать повышению как надёжности, так и быстродействия. О надёжности говорить пока рано – она имеет статус экспериментальной и не рекомендуется для повсеместного использования. Но быстродействие NILFS2 оказывается вполне на уровне её подруг-конкуренток – ext4 и btrfs.

Btrfs – ждём стабилизации?

Подготовлена для: LinuxFormat, #121 (август 2009), но была заменена на заметку про NILFS2

Файловая система btrfs не так давно стала полноправным членом семейства нативных ФС для Linux (начиная с ядра 2.6.29). И едва это случилось – она претерпела кардинальное изменение формата, что ознаменовалось выходом, после почти полугодичного перерыва, инструментария для работы с ним – btrfs-progs 0.19, рассчитанным на грядущее ядро 2.6.31. Который, по уверению разработчика, Криса Мэзона, способен создавать файловую систему с кардинально повышенным быстродействием. Несовместимую, однако, с инструментарием предыдущей версии.

Я решил проверить обоснованность этого заявления. Результаты – парадоксальны: действительно, при операциях с обычными, в том числе и очень большими, файлами, она показывает просто рекордные результаты в сравнении не только с традиционными ФС, но и с утверждающейся в качестве стандарта ext4. А вот манипуляции с очень мелкими файлами (каковых без счёта в любой Linux-системе) – просто провальны: местами замедление их более чем двукратное.

Увы – до стабилизации btrfs мы ещё не дожили: следует ждать очередной смены формата на предмет большей сбалансированности её быстродействия.

Куда развиваться свободному софту?

LinuxFormat, #122 (сентябрь 2009)

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

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

Я понимаю – развитие и KDE3, и GNOME2 дошло до той черты, когда остаётся только выискивать баги, полировать мелочи, ну и прочая косметика. А это – полезно для пользователя, но смертельно скучно для разработчика. Особенно для того, кому разработка – способ самореализации, а не банальная рубка бабла на росте пользовательской базы. Вспомним, насколько интенсивно развивались в последние полтора десятка лет find или grep? Не больше, чем ахалтекинцы за тысячелетия существования своей породы. И по той же самой причине.

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

А куда деваться софту свободному, который по определению ориентирован на оптимальное решение задачи, а не художественный подстриг капусты?

Не это ли – самый главный внутренний тормоз для развития FOSS?

Феномен Juick’и

LinuxFormat, #123 (октябрь 2009)

Всеобщая интернетизация породила несколько форм самовыражения личности в Сети: сначала это были домашние страницы, затем – блоги и социальные сети и, наконец, микроблоги. Об одном из последних – Juick, или просто Джуйке – и пойдет речь. Открывшись в октябре 2008 года, она наиболее полно воплотила в себе идею сочетания собственно микроблогов, форумов по интересам, чатов для общения.

Для участия в Джуйке требуется только аккаунт в Jabber и любой Jabber-клиент. В последнем и сочиняются сообщения в соответствие с очень несложным синтаксисом, по которому существует полная справка.

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

Причём здесь Linux? Так уж исторически сложилось, что среди участников Джуйки линуксоидов если не большинство, то очень много. И почему-то почти любая тема рано или поздно сводится к Linux’у. А сервер, на котором живёт Джуйка, работает под управлением CentOS.

В общем, лучше один раз увидеть, чем сто раз прочитать. А ещё лучше – попробовать.

Русская Fedora: первый год жизни

LinuxFormat, #124 (ноябрь 2009)

20 ноября исполняется год проекту Russian Fedora – не пора ли подвести первые итоги?

Для начала – что это такое. Russian Fedora – не новый дистрибутив, не клон и не форк Fedora оригинальной. Это – ремикс, то есть пересборка исходной системы. И основная её задача – коррекция перегибов законодательства некоторых слабо развитых стран в отношении авторских и смежных прав. Выполняемые в рамках проекта сборки так и называются – Russian Fedora Remix. И обеспечивают «из коробки» работу аудио- и видеокодеков, воспроизводство Flash, установку фирменных драйверов для видеокарт Nvidia и ATI/AMD, отличный от «умолчального» рендеринг шрифтов за счёт пересборки freetype. Разумеется, почти всё это есть и в репозиториях «головного» проекта. И Fedora, установленная с оригинального носителя, может быть превращена в свою русскую родственницу легким движением руки. Но – лишь при условии хорошего коннекта. А RFRemix избавляет пользователя не только от лишнего «рукоблудия», но и от необходимости подключения к сети.

А тем временем на подходе очередная, 12-я, версия Fedora – и оригинальной, и отечественной сборок. Чем грозит она нам, пользователям? Во-первых – ускорением, и загрузки, и реакции на наши действия. Во-вторых, оптимизацией (в том числе и) под процессоры Atom, что сделает её подходящим выбором для нетбуков и неттопов. А в-третьих – новой версией GNOME, опционально включающей GNOME Shell – но это совсем другая история.

GNOME Shell: всё для блага человека

LinuxFormat, #125 (декабрь 2009)

GNOME Shell – новый способ взаимодействия пользователя с рабочим столом GNOME, предлагаемый разработчиками как революционный и «пользительный». Предполагается, что он станет стандартным в грядущей 3-й версии этой среды, но уже сейчас его можно без труда включить в версии 2.28 (например, в Fedora 12).

Революционность его – в наличии двух принципиально разных режимов:

  1. «оверлейного», котором можно только запускать приложения и открывать документы, причём делать это абсолютно единообразно;

  2. «рабочего», в котором собственно и выполняется работа.

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

В современном виде GNOME Shell ещё не очень пригоден для повседневного применения, в частности, из-за скудости настроек. Но опробовать его потенциал можно уже сейчас. Мне – понравилось…

Примечание. Увы, настройки остались столь же скудными и в релизе. Да и несколько дней общения не «на посмотреть», а в реальной работе показали малую пригодность применения GNOME Shell’а в этих целях. Так что я её исключил из своего арсенала сразу по выходе релиза.

2010

Дистрибутив Linux: кто он сегодня?

LinuxFormat, #126-127 (январь 2010)

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

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

Комплектация пакетами? Скажем, когда-то Slackware содержала большое количество средств разработки, Red Hat – системного администрирования, а Mandrake – пользовательских приложений. Ныне же каждый «большой» дистрибутив включает в себя практически весь набор свободного софта, созданного человечеством. А удобные средства управления пакетами позволяют легко превратить самую рас-серверную инсталляцию в юзерофильную систему. Да, не с дистрибутивного носителя, а… откуда? Правильно, из репозитория.

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

Пингвины пишут своими шрифтами

LinuxFormat, #128 (февраль 2010)

Материалов о том, как прикрутить к Linux привычные (или необходимые по делу) шрифты классового врага, в Сети без счёта. Но не решить ли проблему кардинально – то есть разработать собственные шрифты, метрически идентичные? А что, и замахнёмся – подумали в компании PingWin Software. И представили для общественного тестирования комплект гарнитур с именами PWT Arion, PWT Courant, PWT Timer, PWT Tahion, PWT Verde – для тех, кто ещё не забыл, что такое Windows, они будут значимыми.

Специально подчёркиваю – это не столько аналоги, сколько гомологи. То есть – в них не были использованы глифы созвучных гарнитур, шрифты отрисованы с нуля. А ещё в них учтены все символы, используемые в национальных алфавитах нашей необъятной Родины, основанные на кириллице – те, кто в школе изучал языки титульных наций, поймут, о чём я говорю.

По ряду причин принять участие в формальном тестировании я не смог, но провёл собственное. Трое суток они стояли у меня в качестве системных, шрифтов браузера по умолчанию, шрифтов текстового редактора (и стоят по сей момент). И ни разу за это время у меня не заболели глаза – а они у меня очень к этому делу чувствительные.

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

Обновления системы: нужны ли они народу?

LinuxFormat, #129 (март 2010)

Лёгкость апгрейда базовой системы и её приложений испокон века рассматривается как один из критериев качества дистрибутива или ОС. И действительно, приятно, проснувшись поутру и включив машину, получить сообщение, что на текущий момент доступно столько-то обновлений. Чувствуешь себя на острие технического прогресса. Вот только необходимо ли это в современных условиях?

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

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

Новое оборудование, требующее поддержки в ядре? А чего нынче может быть нового в плане «железа»? Тем более, что появление процессоров Clarkdale (см. следующую колонку), похоже, поставит точку в развитии «камнестроения» для настольных компьютеров неигрового назначения.

Вот и думается, что нынче раз установленная система с продуманным набором приложений способна служить до полной физической амортизации машины…

Конец «камнестроения»?

LinuxFormat, #129 (март 2010), не публиковалось.

Самым важным событием наступившего года в IT-сфере было, как мне кажется, представление новых процессоров от Intel – Clarkdale и Arrandale. Почему? Да потому, что процессорам для обычных десктопных систем развиваться больше некуда. По крайней мере, для пользователей Linux и соплеменных систем.

Судите сами: два CPU-ядра, интегрированный GPU, тактовые частоты – до 3,46, турборежим на одном ядре – до 3,73. Интегрированный GPU более чем достойной производительности в неигровых приложениях. Тепловой пакет позволяет собирать аналоги неттопов с полностью пассивным охлаждением, то есть абсолютно бесшумные. Чего ещё нужно пользователю, чтобы спокойно встретить свою компьютерную старость? Так что в развитии десктопного «камнеобразования» подведена последняя черта.

Какое это может иметь отношение к Linux’у? Да такое, что можно прекратить бесконечные апгрейды «железа» и забыть о всякого рода проприетарных драйверах – интегрированное видео от Intel всегда хорошо поддерживалось штатными средствами оконной системы X. А вычислительной мощности заведомо хватит на любые повседневные задачи.

Неттопия на практике

LinuxFormat, #130 (апрель 2010)

К теме, нужны ли нам большие машины, я уже обращался (LXF, #120) – тогда чисто теоретически. Пришло время проверить свои соображения на практике – путём приобретения неттопа в следующем виде: платформа Pegatron с «впрессованным» процессором Atom 330, чипсетом ION (то есть с интегрированным видео уровня GeForce 9xxx), 1 Гбайт впаянного ОЗУ и разъёмом SO DIMM с потенциалом ещё на 2 Гбайта. Каковой и был реализован – вкупе с обычным ноутбучным винчестером о 5400 об./мин.

В итоге получилась очень милая машинка размером чуть больше двух пачек сигарет, абсолютно бесшумная и холодная, способная функционировать в режиме 7×24 без малейшего вреда для нервов хозяина. Производительность? Рекордов в деле компиляции ядра или тотальной пересборки Gentoo от неё не ждите. Но для большинства пользовательских задач – текстовый редактор и даже процессор типа OOo, сёрфинг по Сети и так далее – более чем достаточна.

И опять же вопрос – а причём здесь Linux? Да в общем ни при чём, кроме как то, что он прекрасно на ней работает. В варианте Fedora – с некоторыми ручными пассами, связанными с установкой фирменных драйвером Nvidia. Впрочем, преодолимыми и хорошо документированными (например, на форуме russianfedora.ru). Ну а в варианте от Ubuntu – просто из коробки.

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

Примечание. Правда, радость моя оказалась недолгой. Машинки действительно оказалось достаточно для перечисленных выше задач. Но, скажем, два параллельных сеанса Иксов она уже не тянула. А о запуске пары-тройки виртуальных машин можно было и не мечтать. А поскольку такие задачи у меня возникают, и так как машинка вполне справлялась с фильмами и играми, я поступил по завету Ленина: «Всё лучшее – детям!»

Незнаменитый офис

LinuxFormat, #131 (май 2010)

Когда речь заходит об открытых и свободных офисных пакетах, вспоминают, как правило, OpenOffice.org, реже – вечный долгострой проекта KDE, KOffice. И мало кто упомянет в этой связи компоненты GNOME Office – текстовый процессор Abiword и табличный процессор Gnumeric. Что, в общем-то, резонно – обе эти программы вполне самостоятельны и их интеграция достаточно искусственна. Что, однако, не умаляет их достоинств. Каковыми считаются лёгкость, быстродействие, простота интерфейса. Но при этом забывают о функциональности – а ведь каждая из этих программ обладает своими уникальными особенностями.

Для Abiword’а это средства коллективной работы. Во-первых, он поддерживает мультиверсионные документы – в том числе и те, что были сделаны таковыми в MS Word. Во-вторых и главных, Abiword располагает инструментами удалённого редактирования, по собственному протоколу AbiCollab.net, прямому подключению TCP и, наконец, по протоколу XMPP – то есть через самый обычный Jabber-клиент.

Ну а «фирменные фичи» Gnumeric’а – это изобилие статистических и инженерных функций (более ста из которых уникальны) и широчайшие возможности для построения технических диаграмм и графиков.

То есть считать Abiword и Gnumeric жалким подобием левой руки OOo – несправедливо. Просто это действительно программы не для офисного клерка, а для инженера, научного работника… в общем, технического специалиста.

Fedora в новой сфере?

LinuxFormat, #132 (июнь 2010)

С первых дней своего отщепления от прародительского Red Hat’а дистрибутив Fedora рассматривался как полигон для отработки новых технологий. И потому интенсивно обновлялся в межрелизный период. Что сугубо приветствовалось энтузиастами-экспериментаторами, но вызывало вполне понятную настороженность со стороны «промышленного сектора начального уровня». В результате ниша «Red Hat для бедных» оказалась заполненной его клонами, такими, как CentOS и Scientific Linux.

Но похоже, что «командорской компании» это не понравилось. И отныне политика обновления Fedora меняется: в межрелизный период будут выпускаться только обновления безопасности, смены версий ядра и прочих основных компонентов системы отменяются. Что, конечно, пойдёт на пользу стабильности дистрибутива и откроет перед ним перспективы промышленного применения для тех, кто не нуждается в технической поддержке «настоящего» Red Hat или просто не может себе её позволить.

Но не потеряет ли Fedora своей фронтирной прелести для энтузиастов и экспериментаторов? Надеюсь, что нет. Думаю, что вместо двухступенчатой схемы дистрибуции – стабильного релиза и так называемого Rawhide сама собой сложится трёхступенчатая, подобная Debian’овской. Собственно, явочным порядком она и образовалась при подготовке 13-й версии. Каковую, надеюсь, заинтересованные лица смогут увидеть ко времени прочтения этих строк.

Нативная ZFS для Linux и будущее btrfs

LinuxFormat, #133 (июль 2010)

Как известно, самая прогрессивная файловая система современности – ZFS. Применяясь в Solaris и FreeBSD, она была доступна в Linux только через FUSE, на чём многое теряла. И исключительно в силу несовместимости лицензий ядра Linux (GPL) и ZFS (CDDL). Но ныне мы видим победу технологии над юриспруденцией – чисто техническое разрешение этого конфликта.

Оно представлено в виде обычного модуля ядра Linux – но под лицензией CDDL, распространяемого отдельно от GPL-лицензированного кода ядра этой ОС. Чем и обходится антагонистическое противоречие – запрет на распространение бинарников, в которых смешан код под этими лицензиями. Но совместное его использование в виде отдельных программ никто не запрещает.

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

Важнее другой вопрос: будет ли развиваться btrfs? Ведь возможности этих файловых систем во многом перекрываются. Впрочем, вопрос этот возникает и вне связи с ZFS – инструментарий btrfs не обновлялся уже более года. Терзают смутные подозрения, что Oracle прекратило финансирование работ Криса Мэзона. Если так – становится грустно. Потому что btrfs, кое в чём уступая ZFS, превосходит её простотой использования, так поддерживается в Linux’е штатно.

Памяти советской геологии

LinuxFormat, #134 (август 2010)

Вступление: мысль создать сайт о советской геологии и советских геологах была у меня давно – но всё не хватало мужества. События последних лет заставили меня поторопиться – один за другим уходят к верхним людям мамонты геологической науки. В результате я таки и взялся за этот проект…

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

Какое отношение это имеет к Linux’у? Да только то, что весь проект выполняется на Linux-машинах. Вот дошла эта ОС до жизни такой, что в ней можно просто заниматься самыми разными практическими делами. В том числе и геологическими. Не напрягаясь уже вопросами перекомпиляции ядра, прикручивания кириллицы или настройки Иксов. Иначе говоря, началась нормальная цивилизованная жизнь. Не об этом ли мы мечтали долгие предшествующие годы?

А ещё – Open Source и геология на самом деле очень родственные явления. Ибо основаны на одних и тех же принципах: свободе распространения базовой информации с целью построения на ней конечных решений

К соучастию в проекте приглашаются все, кто в теме, кто знает и помнит…

KDE 3: реанимация или гальванизация?

LinuxFormat, #135 (сентябрь 2010)

Для многих старых пользователей KDE, начинавших ещё с 1-й версии, выход KDE 4.0 был шоком. И дело не в недоработках её – для первого представителя новой ветки они естественны: но это было не то KDE, которое они знали и любили. И потому с тоской вспоминали доброе старое время – даже два корректирующих релиза KDE 3.5.X от этого не спасали: было очевидно, что дни 3-й ветки сочтены.

И вот недавно Тимоти Пирсон (Timothy Pearson) решил исправить положение коренным образом, начав проект Trinity KDE. В двух словах это дальнейшее развитие 3-й ветки с некоторыми заимствованиями из 4-й – теми, что не идут в разрез исконной идеологией KDE. С первыми результатами его работы можно ознакомиться посредством Kubuntu 10.04, где они объединены под именем KDE3/Trinity 3.5.11.

Увы, успех этого безнадёжного предприятия видится сомнительным. Кроме очевидных проблем с версиями библиотек Qt и привлечением разработчиков, главным камнем преткновения будут кадры. За истекшие два с половиной года KDE 3 растеряло изрядную часть своих некогда преданных поклонников: одни, скрепя сердцем, погрузились в мир плазмоидов 4-й ветки, другие мигрировали на более иные десктопы. Новые же пользователи воспринимают KDE 4 как данность. И проект Тимоти может оказаться просто невостребованным широкими народными массами. Тем не менее, я очень хотел бы пожелать ему удачи.

Судьба OpenSolaris: бессмертна ли мафия?

LinuxFormat, #136 (октябрь 2010)

Пересказывать новость, что Oracle изменила политику разработки OpenSolaris, не буду. Скажу только, что этим новый владелец подписал ей смертный приговор: если она и была чем интересна потенциальным пользователям – то своими инновациями. А превратившись в Solaris… не для бедных даже, а для нищебродов, питающихся объедками с барского стола, она станет не интересной никому (как, подозреваю, вскоре и большой Solaris).

Благо, ещё до того образовался новый проект – IllumOS, быстро оформившийся в независимый форк OpenSolaris’а. И теперь ему предстоит «проверка на вшивость»: набрала ли эта система критическую массу пользователей и разработчиков для самостоятельного плавания? Я бы хотел верить в положительный ответ на этот вопрос.

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

Линуксоид как высшая ступень эволюции Homo sapiens

LinuxFormat, #137 (ноябрь 2010)

Сегодня я хочу познакомить вас с популярно-научным сайтом антропогенез.ру, посвящённым происхождению и эволюции человека. Почему такое определение? Потому что это настоящий научный сайт, который имеет все шансы стать популярным. Его авторы – это «настоящие» антропологи и археологи, работающие в тех сферах, о которых пишут. Так что на этом сайте нет ни захватывающих погонь за снежным человеком, ни рассусоливания «от Адама». Авторы разговаривают с читателем на равных. Что, разумеется, предполагает, что и читатель обладает некоторым минимумом знаний. Или – желанием таковой приобрести. В общем, всё точно как в Linux. Почему мне и показалось уместным рассказать здесь об этом сайте.

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

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

RFRemix 14: сбытие мечт?

LinuxFormat, #138 (декабрь 2010)

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

Но мечты иногда сбываются: ныне место «человечьего» Linux’а готова занять Fedora 14. Которая для нашей части человечества выступает в амплуа RFRemix. И лицо её обращено к

  • совсем начинающим пользователям – им оно обещает простую и безболезненную установку;

  • экспериментаторам – максимально свежий софт никуда не пропал и из этого релиза;

  • будущим труженикам корпоратива – как тренировочная площадка для промышленных систем;

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

Впрочем, «мгновенность» распространяется на всех: при установке с LiveCD развёртывание системы занимает первые минуты.

2011

Как читать Linuxformat

LinuxFormat, #139-140 (январь 2011)

В век всеобщей интернетизации «бумажные» журналы могут показаться атавизмом. Казалось бы, какой смысл читать на бумаге то, что можно было бы прочитать в Сети несколько месяцев назад? Однако…

Многие ли из нас читают с экрана то, что вроде бы интересно, но с задачами сегодняшнего дня не связано? Я так нет. И потому для меня праздник, когда мне привозят номера Linuxformat’а. Я откладываю текущие дела, укладываюсь на досадную укушетку и читаю. Запасшись предварительно набором маркеров и цветных закладок – дабы отмечать то, что может потом пригодиться не только в общеобразовательных целях. Статьи, которые мне могут понадобиться в ближайшее время, я закладываю зелёными бумажками, то, что может теоретически пригодиться когда-нибудь – синими. Ну а что действительно для общего образования – красными.

На торчащем корешке закладки я маркёром ставлю аббревиатуру: например, здесь про KVM, здесь интересное про zsh, здесь – что-то любопытное про векторную графику.

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

Сказанное – не реклама Linuxformat’а. Просто я действительно получаю удовольствие от его чтения.

Парадокс линуксописательства

LinuxFormat, #141 (февраль 2011)

Уже много лет я задаю себе вопрос: для кого пишут авторы, сочиняющие про Linux сотоварищи? И для чего они это делают?

Конечно, ответ на второй вопрос очевиден: они пишут о том, что им интересно. Потому что писать можно только о том, что интересно самому – тогда есть шанс, что это будет интересно ещё кому-то.

А вот для кого – вопрос посложнее. Ведь ни один из нашей пишущей братии не открывает никаких америк: ответы на все вопросы технического плана можно найти в документации. И, что интересно, нас, линуксописателей, читают как раз те, кто сами прекрасно умеют находить ответы на возникающие вопросы. Те же, кто не читает документации – как правило, не читают и нас.

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

Мы живём среди компьютеров и свободного софта – и пишем о них. Если для кого-то написанное нами будет поводом заитересоваться этими темами – будем считать, что не зря долбили по клавишам.

Linux от Oracle

LinuxFormat, #142 (март 2011)

Пару лет назад мир свободного софта в очередной раз содрогнулся: компания Oracle объявила о выпуске собственного дистрибутива Linux – на базе не кого-нибудь, а текущей версии RHEL. Начались прорицания под стать Дельфийскому оракулу: либо Oracle съест Red Hat, либо преданные сторонники последнего забойкотируют Нерушимый Linux (именно так называлась первая версия от Oracle).

Прошло время, страсти поостыли. И Red Hat никуда не делся, и Linux от Oracle нашёл своё место под солнцем. В частности, в виде третьей своей версии, увидевшей свет 12 февраля. Которая именуется уже просто – Oracle Linux. В чём же её цимес?

В первую очередь – в ядре, которое тоже удостоилось имени собственного, Unbrecable Enterprise Kernel (сокращённо – uek). Давно уже общим местом стало воспевать «отзывчивость» дистрибутива Fedora и всех генетически связанных с ней систем. Так вот, Oracle Linux в этом отношении ей ничуть не уступает. А с учётом разницы в «железной» базе (Fedora у меня стоит на быстром SSD, для Oracle Linux нашёлся только полуутильный винчестер пятилетней давности), то возможно, что и превосходит.

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

ОС Barrelfish: рыбозасолочный цех

LinuxFormat, #143 (апрель 2011)

Разработчики не часто удивляют нас появлением новых операционных систем. Оно и понятно: казалось бы, в существующих ОС реализованы все разумные идеи. Ан нет: осенью 2009 года мы имели удовольствие видеть представление Barrelfish – ОС с принципиально новой, мультиядерной (multikernel), архитектурой: в ней, подобно сельдям в бочке, несколько ядер (kernel), соответствующих ядрам (core) аппаратной платформы, работает независимо, с собственными приложениями.

Возможно, такой «рыбозасолочный» подход будет более эффективным при мультипроцессинге, нежели традиционные механизмы SMP или NUMA. А ведь именно эффективное распараллеливание задач между наличными ядрами – ныне единственный способ наращивания производительности, особенно ввиду скорого появления восьмиядерных процессоров даже в пользовательских декстопах.

Интересны разработчики и лицензия новой ОС. Первые – Высшая техническая школа Цюриха (ETHZ), известная многими именами учёных в области точных и компьютерных наук и… компания Microsoft, просто известная. А лицензия – практически стандартная в BSD-стиле.

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

Linux и OCR – братья на век

LinuxFormat, #144 (май 2011)

До недавнего времени Linux не мог похвастаться эффективными средствами для распознавания текстов: резонные люди рекомендовали прибегать к связке из FineReader+Wine.

Да и задача эта не выглядела актуальной: мне казалось, что большая часть «старого» контента уже оцифрована, а новый только в цифровой форме и создаётся. Однако по мере развития своих гуманитарных проектов (геологическго и исторического) я убедился, что был не прав: существует море «неокученных» старых материалов по этой теме. А материалы новые часто легче оцифровать с печатных версий, чем получить «файлы-исходники»: увы, один за другим уходят мамонты советской геологии.

Но действительности со свободными средствами распознавания оказалось «всё не так суицидально, ежли в корень посмотреть»: в 2008 году были открыты исходники OCR Cuneiform, которые тут же портировались на Linux и FreeBSD.

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

  • Scan Tailor (разработка Иосифа Арцимовича) – она выполняет предварительную коррекцию отсканированного документа, и

  • YAGF (создана Андреем Боровским) – это интегрирующая графическая оболочка для Cuneiform, упрощающая её использование и расширяющая возможности.

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

Куда катится мир?

LinuxFormat, #145 (июнь 2011)

Всё началось с того, что были придуманы широкоформатные мониторы. Вроде бы для блага человека – чтобы человеку тому было комфортней смотреть фильмы. Хотя существует версия, что они просто дешевле в производстве: из одной «заготовки» дисплеев с пропорцией 16:9 можно нарезать больше. Так или иначе, но нас, пользователей, убедили, что широкоформатный дисплей – это круто. Убедили вполне рыночным методом – исчезновением из продажи мониторов «квадратных».

После этого оказалось, что для большинства более иных, нежели просмотр фильмов, задач «длинные» мониторы не очень удобны: при работе с браузером, текстовым редактором или процессором остаются, как правило, «мёртвые боковины». В соответствие с заветами Ильфа и Петрова, эту трудность надо было преодолеть. И преодолели: появляются интерфейсы Unity и GNOME Shell. Каковые, при всей их прогрессивности, фронтирности и прочих бесспорных достоинствах, вызывают у большинства «действующих» пользователей Иксов отторжение. Не беда: теперь остаётся только убедить пользователей начинающих, что это круто. И ведь убедят – потому что начинающие пользователи, коими и будет прирастать могущество Linux’а, имеют шанс ничего иного не увидеть: эти интерфейсы умолчальны в свежевышедшей Ubuntu и грядущей Fedora.

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

P. S. А на предмет задействования «боковин» много лет назад придумали Window Maker, по сей день один из самых эстетичных оконных менеджеров. Может быть, это послужит стимулом для реанимации проекта?

Волхвы-то кричали с того и с сего

LinuxFormat, #146 (июль 2011)

Пару-тройку лет назад была написана такая заметка: Куда развиваться свободному софту? см. LinuxFormat, #122 (сентябрь 2009). К сожалению, автор её оказался хорошим пророком. Именно так всё и произошло. Много лет говорили большевики, меньшевики и разные анархо-синдикалисты о UNIX’е с человеческим лицом. О том UNIX’е, что может использоваться кем угодно – от геолога до поэта. Лет пять назад всё почти так и стало. Ну а пару лет назад всё стало именно так. Да-да, пару лет назад все основные дистрибутивы Linux’а были доведены до того состояния, когда могли использоваться всеми, занимающимися своей работой. Однако…

… однако именно в этот момент начинаются приключения. Сначала – KDE4. Да, не прошло и нескольких лет, как их довели по функциональности до последних «трёшек». Но ведь это ничему не научило GNOME-строителей. Они пошли тем же путём. И при этом уверяют нас, что это и есть магистраль прогресса. И предлагают привыкать к этому. Вспоминается стишок, который я когда-то услышал из уст известной детской писательницы Юнны Мориц. Он абсолютно обсценный, поэтому процитирую только последние строки:

Нравится, не нравится –
Терпи, моя красавица!

Что точно отражает суть дела.

Хвала Ахурамазде, есть ещё пока XFce. Но вдруг и его разработчиков коснётся эта болезнь дурного свойства? И куда податься тогда бедному юзеру? Идти покупать Mac?

Linux в «верхнем» образовании

LinuxFormat, #147 (август 2011)

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

Это было восполнено на проходившей в конце мая конференции, организованной порталом nixp.ru. Она была очень интересной, на ней затрагивались вопросы от коммерциализации СПО до web-разработок на его базе. Однако в связи с темой данной колонки я остановлюсь лишь на докладе Дмитрия Шурупова «Свободное ПО в образовательном процессе кафедры ИКТ МИЭМ».

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

Увы, это грозит стать и слабым звеном системы: студенты заканчивают обучение и уходят. А притока новых кадров может и не быть. И это общая болезнь СПО – не только в образовании, и не только у нас: перворазработчики уходят в иные сферы, а на смену им либо не приходит никто, либо приходят – и перекраивают всё по своему. Чтобы затем так же уйти.

Разработка СПО – не хобби. Это такая же профессия, как у научного работника, то есть не дающая немедленной практической отдачи. И возможность профессиональной работы в сфере СПО требует сочетания массы факторов. До сих пор, за исключением единичных случаев, оно было реализовано только в героические времена разработки BSD.

О LUG’ах и горе Верблюд

LinuxFormat, #148 (сентябрь 2011)

Региональные группы пользователей Linux (LUG’и) на рубеже тысячелетий сыграли у нас огромную роль в приобщении пользователей к этой ОС. Ведь даже просто получение дистрибутива тогда было проблемой: каналы оставляли желать лучшего, системы онлайновой торговли ещё не сложились, а в обычных магазинах диски с Linux’ом на каждом прилавке не валялись.

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

Так что LUG’и выполняли тогда функции распространения и дистрибутивов, и информации о системе. Не говоря уже о помощи начинающим пользователям «словом и делом».

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

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

Многих, но не всех. Только деятельность эта стала иной. Например, заключаясь в организации неформальных встреч пользователей. Примером чему – недавний (29-31 августа) Фестиваль, посвящённый Дню системного администратора, организованный Северо-Кавказской LUG в живописном месте района КМВ.

Мне удалось побывать там – и фестиваль этот показался мне знаменательным: народ не хватался за диски и ноуты для демонстрации любимых систем, а вполне непринуждённо общался на различные темы – не обязательно связанные с Linux’ом. И не это ли вторая жизнь LUG’ов? Ведь не Linux’ом единым жив человек…

Снова Open Source в науке

LinuxFormat, #149 (октябрь 2011)

О том, что фундаментальная наука и Open Source – явления очень родственные, было написано немало. И вот очередное тому подтверждение: в пещере Малапе, Южная Африка, обнаружены, возможно, остатки мягких тканей австралопитеков. А это более двух миллионов лет. Остаётся только удостовериться в том, что так оно и есть.

И вот ребята, это дело нашедшие, обращаются за помощью к научному сообществу. Чтобы не городить отсебятины, просто процитирую пару фрагментов с ресурса АНТРОПОГЕНЕЗ.ру, о котором я некогда уже писал – см. LinuxFormat, #137 (ноябрь 2010).

Первый:

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

И второй:

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

Немного похоже на то, что написал 20 лет назад Линус Торвальдс, верно?

Дети мага Мандрейка

LinuxFormat, #150 (ноябрь 2011)

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

Вышедший летом релиз Mageia представлял собой косметическую доработку исходной системы. А вот недавний релиз Mandriva 2011 уже содержит кардинальные новшества – начиная от изменения формата пакетов на rpm5 и внедрения systemd и заканчивая основательной переделкой десктопа KDE. В результате система получилась фронтирная, очень эстетичная, но весьма тяжеловесная, даже по сравнению с Mageia – тоже не эталоном лёгкости.

И это повод вспомнить о более раннем форке Mandriva – PCLinuxOS, давно уже превратившемся в самостоятельный дистрибутив с собственной концепцией и пакетной базой. Она не очень обширна, но зато система оказывается весьма компактной и аккуратной. До недавнего времени она существовала только в 32-битном варианте, но в настоящее время полным ходом идёт тестирование 64-разрядной версии, релиза которой можно ожидать в ближайшее время.

Таким образом, старым поклонникам мага Мандрейка предоставляется достаточно широкий выбор.

Как завладеть миром?

LinuxFormat, #151 (декабрь 2011)

Героиня одного известного, хотя и спорного, романа, объясняет, что нужно для завладения миром: достаточно заставить людей с некоторой регулярностью совершать бессмысленные действия. Например, дважды в году переводить стрелки часов вперёд и назад. Однако с этим можно поспорить: главное – не заставить, а убедить людей, что тем самым они совершают нечто полезное. Скажем, экономят электроэнергию.

Похоже, что это начинают осознавать разработчики Open Source. Иначе чем объяснить регулярно возникающие в последнее время предложения о переименовании сетевых интерфейсов, свалке всех исполняемых бинарников, как пользовательских, так и системных, в /usr/bin, и так далее. Особенно показательно в этом плане внедрение systemd – очень прогрессивная вещь, ускоряющая загрузку системы. И хорошая аналогия с переводом часов. Ведь основные процессы, пожирающие время при загрузке пользовательской машины – это связи с сетевыми службами, NTP и так далее. Ускорить которые не в силах никакое распараллеливание. Ну а что с внедрением SSD понятие скорости загрузки вообще теряет смысл, промолчим.

Однако венец всему – это последние версии FireFox, где панели вкладок и закладок поменяли местами, а кнопку Reload передвинули слева направо. Если в предыдущих случаях новшествам, при большой фантазии, можно было придумать разумное объяснение, то тут это – перевод часов в чистом виде.

И это – попытка захватить мир? Или просто в этом мире ребятам больше нечем заняться?

2012

Куда казаку податься?

LinuxFormat, #152-153 (январь 2012)

В прошлой колонке автор сетовал на непрошеные новшества, то и дело возникающие в Linux’е. Что вызывает законный вопрос: если так дело пойдёт и дальше, то куда бедному линуксоиду податься? Ведь очевидно, что всякие systemd’ы рано или поздно расползутся по всем дистрибутивам.

И тут напрашивается ответ: FreeBSD, для которой на подходе 9-я версия. С новым инсталлятором, позволяющим установить систему в те же несколько кликов мыши, что и самый юзерофильный дистрибутив Linux’а. С возможностью разместить корень файловой системы на ZFS – самой совершенной файловой системе из тех, которые признаны стабильными (btrfs, может, и не хуже, но до стабильного состояния ещё не доросла). С системой бинарных обновлений, не требующих тотальной перекомпиляции всего и вся. И при этом – с прежней простотой и прозрачностью конфигурационных файлов, не замутнённым новомодными systemd и прочей прелестью.

Сложно для начинающего, скажите вы мне? Да не особо. Но на всякий пожарный случай есть вариант, снижающий порог вхождения в тему: PC-BSD. Основанная на базе FreeBSD, она снабжена графическим инсталлятором и собственным пакетным менеджером – спорным по принципам, но всё более следующим к классическому UNIX Way.

Измена Linux’у, опять же скажете вы? А вот тут впору вспомнить слова Антон Палыча Чехова: «Если вам изменила жена, радуйтесь, что она изменила вам, а не отечеству». Тем более, что в данном случае не мы изменяем Linux’у, а, скорее, Linux изменяет UNIX’у. Так что можно сказать, что от присяги мы свободны.

PCLinuxOS в отечественной редакции

LinuxFormat, #154 (февраль 2012)

Не так давно, в ноябрьском номере, затронув тему потомков мага Mandrake, я упомянул и дистрибутив, труднопроизносимое название которого фигурирует в заголовке этой колонки. Поводом же для повторного обращения к этой теме стали дальнейшее успешное развитие проекта, во-первых, и сообщества его русскоязычных пользователей – во-вторых. А в-третьих и главных – активное развитие локального репозитория. Который содержит не только полное зеркало репозитория официального, но и пакеты, востребованные в нашей, русскоязычной, среде. А также просто пакеты, собираемые по заявкам трудящихся. Причём нынче уже не только в 32-битном, но и в 64-битном варианте.

В двух словах – зачем нужен ещё один дистрибутив Linux’а, в частности этот (для себя я называю его «лосиным» – от сокращённого названия PCLOS). У него есть две особенности. Первая – это система rolling release, то есть одновляемая постоянно. И потому всегда содержащая достаточно свежие версии ядра, Иксов и так далее. А вторая – это, как ни странно, система относительно консервативная. Вы не увидите в ней всяких новомодных штучек типа systemd сотоварищи. И потому она предсказуема и управляема – в крайнем случае, руками. А, будучи при этом ещё и Системой Быстрого Развёртывания, она доводится до рабочего состояния за критически малое время.

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

Очень грустная колонка…

LinuxFormat, #155 (март 2012)

… потому что ушёл к верхним людям Евгений Яворских, известный читателям ряда «бумажных» компьютерных журналов как Акустик, а участникам форумов UNIX-тематики как Jevgeni. Автор бессчётного количества статей о всякой разной мультимедии – и в Linux’е, и даже в Windows. Написавший «бумажные» книги про звук и видео на персональном компьютере – 2004 и 2005 год, соответственно: ни одной вы сейчас в продаже не найдёте, расхватали как пряники. И создатель «сетевого руководства» Пингвиний BUNT – о первых шагах линуксоида, на примере Ubuntu разного рода. И человек с не очень простой судьбой – но об этом здесь говорить не уместно.

Уверен, что верхние люди примут его как должно. А нам останутся его яркие и нестандартно написанные материалы – в равной мере увлекательные и полезные. К сожалению, далеко не все они доступны в Сети. Но ведь это дело поправимое, верно? Старые «бумажные» выпуски журналов и OCR ещё никто не отменил. Да и в редакционных архивах наверняка немало осталось.

Гибридное видео, или мичуринцы из NVIDIA

LinuxFormat, #156 (апрель 2012)

Одним из величайших достижений советских селекционеров было получение гибрида воблы со стерлядью. Он обладал вкусовыми достоинствами первой и стоимостью второй. Недавно этот успех удалось повторить мичуринцам из NVIDIA: они скрестили интегрированные GPU процессоров Core iX и собственные GPU. Гибрид этот должен был обеспечить энергосбережение первых и производительность вторых, и потому его назвали… нет, просто, OPTIMUStm.

Суть его – на задачах, требующих «высокой» графики, работает GPU от NVIDIA, на обычных же происходит переключение на встроенный GPU. Это обеспечивается как «железной», так и программной составляющими. Причём последняя работает только под Windows. И линуксоиды – обладатели ноутбуков с OPTIMUStm, оказались в положении потребителей гибрида воблы со стерлядью, заплатив за то, чем воспользоваться не могли.

Разумеется, немедленно возникла свободная реализация этого решения – проект Bumblebee. Бинарные его пакеты доступны на сайте проекта для Arch, Debian и Ubuntu, наличие исходников позволяет скомпилировать их для чего угодно, Этом воспользовались, в том числе, и майнтайнеры openSUSE. Установив и настроив пакет bumblebee, достаточно запустить исполняемый файл с аргументом – именем программы, требующей «крутой» графики, чтобы включился GPU NVIDIA. Последний по завершении её отключается, переходя в энергосберегающий режим работы с GPU от Intel.

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

Блеск openSUSE

LinuxFormat, #157 (май 2012)

openSUSE появилась на моём ноутбуке неожиданно – из-за его «мичуринского» видео (описанного в прошлой колонке) более иные дистрибутивовы не захотел запускаться. Однако прижилась она не поэтому, а вследствие своих особенностей. Из которых отмечу самые для меня интересные.

Это, по-первых, модуль инсталлятора, отвечающий за разметку диска и файловые системы – то, что в дальнейшем изменить сложнее всего. В openSUSE он на стадии установки позволяет сделать всё, что можно придумать, вплоть до создания файловой системы ext4 «без журнала», определения любых субтомов для btrfs, монтирования tmpfs в любые точки, где она оправданна.

Во-вторых, система управления пакетами zypper. Разработанная по мотивам apt и yum, она вобрала в себя лучшие их черты: по простоте синтаксиса она превзошла второй, по функционалу – первый. А «обёртка» из YaST2 облекает её в элегантную графическую форму.

В-третьих, сам YaST2 – универсальная среда для настройки всего и вся: оборудования, загрузчика, параметров ядра, стартовых сервисов, сетевых соединений и служб, виртуальных машин…

И в-четвёртых – «трёхступенчатая стабилизация»: пользователь может сидеть на текущем релизе, или идти вдоль верстовых столбов (Milestones) релиза грядущего, или, оставаясь в рамках «текучки», использовать отдельные достижения светлого будущего, доступные иначе только в отдалённой перспективе.

Сочетание этих особенностей и определяет своеобразие openSUSE, делая её почти оптимальным дистрибутивом для десктопа. Почему «почти»? А об этом – в следующей колонке.

openSUSE: и на на солнце бывают пятна

LinuxFormat, #158 (июнь 2012)

Прошлую колонку я закончил на том, что openSUSE мог бы претендовать на звание оптимального дистрибутива для десктопа. Что же не даёт ему занять эту ступень «пьедестала почёта»? Всего две мелочи.

Во-первых, среди многочисленных достоинств openSUSE не числится одного – визуального быстродействия, столь выделяющего, например, Fedora. И можно сколько угодно рассуждать о том, что визуальное быстродействие не имеет никакого отношения к скорости выполнения реальных задач – именно оно определяет первое впечатление пользователя о дистрибутиве, да и позднее – психологический комфорт его применения.

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

Первое «пятно» можно замазать использованием prelink’а. Это демонстрирует Fedora, где prelink давно задействован по умолчанию. Применение prelink в openSUSE значительно снижает исходную её «задумчивость». Кроме того, уже по ранним версиям тестируемого ныне релиза видно, что майнтайнеры работают над повышением визуального быстродействия.

Второе «пятно» закрашивается эффективным механизмом поиска пакетов и установки их «в один клик». Однако отсутствие централизованного хранилища «сторонних» приложений – аналога RPMFussion в Fedora или AUR в Archlinux – по прежнему чувствуется. Но, может быть, и эта задача будет решена со временем?

Примечание. Не прошло и нескольких месяцев со времени публикации этой колонки, как обе описанные в ней проблемы были решены. Сначала коренным образом был преобразован интерфейс поиска пакетов системе OBS (Open Build Service). И теперь установка приложений из сторонних репозиториев, сопровождаемая подключением оных, стала предельно простой.

Ну а быстродействие openSUSE действительно было кардинально повышено в вышедшем недавно релизе 12.2. Да и всё большее распространение SSD в качестве по крайней мере системных носителей всё больше нивелирует разницу в производительности любого софта.

Во славу Гомера

LinuxFormat, #159 (июль 2012)

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

Одна из таких систем появилась в конце 2010 года, и называется ALT Linux Homeros. Как нетрудно догадаться по названию – это дистрибутив для людей с ограничениями по зрению, в том числе и совершенно слепых. Он основан на 6-й платформе Altlinux, среде Emacs и emacspeak. Они дополнены речевым сервером VoiceMan и синтезаторами – русско- и англоязычным (по умолчанию – RHVoice и mbrola, соответственно).

Распространяется Homeros в виде LiveCD (объёмом менее 400 МБ), предусматривающего возможность установки, в том числе и без визуального контроля вообще. Однако и в Live-режиме можно получить достаточно полное представление о её возможностях. Описать которое довольно сложно – это надо видеть и, главное, слышать. Что я и рекомендую проделать всем любознательным, вне зависимости от остроты их зрения. На меня самое большое впечатление произвело зачитывание текста по мере его набора – работает эффективней любого спеллчекера.

Разработчик Homeros’а – Михаил Пожидаев, и создавал он эту систему для себя. Я надеюсь, что и подробности о ней он скоро представит сам, в одном из ближайших номеров журнала.

Нативная ZFS – Linux’у!

LinuxFormat, #160 (август 2012)

Ровно 2 года назад (LXF#133) я писал о великой победе инженерной мысли (воплощённой Брайаном Беллендорфом) над юридическим крючкотворством сочинителей лицензий – методе прикручивания поддержки ZFS на уровне ядра Linux. Он получил дальнейшее развитие в проекте ZFS on Linux. Правда, майнтайнеры «майнстримовых» дистрибутивов не торопились включать в свои системы поддержку нативной ZFS даже опционально. И пионером тут выступил Sabayon – не очень распространённый и довольно «хулиганский» отпрыск Gentoo: в его 9-й релиз включена возможность задействовать ZFS на стадии инсталляции (разумеется, не по умолчанию).



В принципе, никто тут не может чувствовать себя обделёнными: разработчики ZFS on Linux предлагают его пользователям Ubuntu в виде пакета, помещённого в ppa-репозиторий и готового к немедленному употреблению. А в качестве заботы о прочих предоставляют, в дополнение к непременным исходникам, также подробные инструкции по сборке пакетов deb- и rpm-форматов.



Не знаю, воспользовались ли этой любезностью майнтайнеры более иных фронтирных дистрибутивов, но вот майнтайнеры openSUSE – воспользовались. И ныне пакет поддержки ZFS со всем сопутствующим инвентарём пользователи этого дистрибутива могут легко отыскать в системе Open Build Service и установить «в один клик». Не без некоторых подводных камней, заставляющих вспомнить родственников сочинителей лицензий, но в принципе такая возможность есть. А что они за это получат – поговорим в другой раз.

Бич свободных лицензий

LinuxFormat, #161 (сентябрь 2012)

Как это ни парадоксально, но один из главных тормозов прогресса свободного софта – это свободные лицензии. И причин тому несколько.

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

И оно бы ладно – меряться длиной свободы ничуть не хуже, чем размером иного органа. Однако из этого вытекает «во-вторых»: все свободные лицензии в той или иной мере не совместимы друг с другом, достигая стопроцентной совместимости только сами с собой. То есть код под разными лицензиями в едином проекте может использоваться либо с теми или иными ограничениями, либо не может вообще. Примером последнего случая является судьба ZFS on Linux, описанная в колонках LFX#133 и LXF#160. Тут, правда, инженерная мысль одержала победу над крючкотворством лизензиатов. Но это потребовало лишних усилий разработчиков и до сих пор доставляет неудобство пользователям. Хотя, казалось бы, именно авторы свободных лицензий декларируют, что «всё для блага пользователя, всё для счастья пользователя».

Примеров непроизводительных трудозатрат для преодоления несовместимости лицензий можно привести много. Один из самых масштабных – это создание BSD-лицензированных аналогов программ, распространяемых под GPL, в рамках практически всех проектов BSD-семейства. И поневоле возникает мысль: а если бы всё эту энергию, да в мирных целях…

openSUSE 12.2: детектив вокруг релиза

LinuxFormat, #162 (октябрь 2012)

Когда вы будете читать этот номер, выход означенного релиза будет состоявшимся фактом. Однако ему предшествовала почти детективная история. 31 августа «по России слух прошёл», что на официальных зеркалах проекта лежат образы долгожданного релиза. Правда, они почти мгновенно исчезли, но оставались доступными несколько уже неофициальных зеркал, организованных предприимчивыми студентами. Хотя на следующий день и они таинственным образом исчезли. Возникает вопрос – не была ли это сознательная утечка информации со стороны разработчиков? Цель которой – развлечь народ в то время, когда они отдыхают от трудов праведных и сочиняют текст пресс-релиза. Что делает честь их чувству юмора.

Однако заинтересованные лица (включая автора этих строк) вожделенные успели образы скачать и даже установить с них систему. Что дало возможность ознакомиться с ещё необъявленным релизом досрочно. Система, с них установленная, оказалась более чем работоспособной. Тем более, что вслед за тем появились уже и официальные репозитории, так что не возникло проблем, скажем, с сетевой установкой или обновлением кандидата в релизы.

Что же до собственно релиза – он вполне оправдал возлагавшиеся на него надежды. А именно: в нём нет ничего ультра-революционного. И по прежнему существует выбор между стилем «гипермодерн», причём в очень смягчённом варианте, и традиционным стилем, вот уже более двух десятилетий обеспечивающим openSUSE привязанность пользователей.

OpenSUSE: первый шаг к релизу 12.3

LinuxFormat, #163 (ноябрь 2012)

Едва успели утихнуть восторги в связи с выходом openSUSE 12.2, как на горизонте возник маяк на пути к следующему релизу – 12.3-Milestone0. Эти «верстовые столбы» интересны тем, что позволяют следить за тенденциями развития дистрибутива. Поэтому я не буду останавливаться на версиях ядра, Иксов, KDE и так далее – за время подготовительного цикла всё это не один раз поменяется. А скажу пару слов именно о тенденциях. И начну, как в анекдоте, с негативных.

Главная из них – о возможности отката на старую систему инициализации можно забыть, systemd пришёл всеръёз и надолго. Как и GRUB 2, и GPT-разметка. Что само по себе и ничего бы – да вот только установить GRUB 2 на диск с таблицей разделов GPT оказывается весьма затруднительно. И полноценно настроить GRUB 2 средствами YaST, как и в текущем релизе, по прежнему невозможно. Остаётся надеяться, что либо в следующем релизе сохранится GRUB Legacy – либо YaST подретушируют в соответствие с требованиями современности.

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

Юстируем шрифты

LinuxFormat, #164 (декабрь 2012)

Кое-кому памятны времена, когда на шрифты в Иксах трудно было смотреть без слёз (в прямом смысле). Потом, с одной стороны, к Иксам научились прикручивать шрифты из Windows, оказавшиеся, по недосмотру Microsoft’а, свободно доступными при соблюдении некоторых условий. А с другой – начали появляться и качественные шрифты, уже по настоящему свободные. И тут выяснилось, что качество шрифтов само по себе не гарантирует их «смотрибельности» на экране: не меньшее значение имеют условия их рендеринга.

Начался период экспериментов с опциями сборки библиотек поддержки вывода шрифтов – сначала отдельными умельцами, потом в Ubuntu дело было поставлено на промышленную основу. И постепенно в большинстве дистрибутивов Linux’а из «первой десятки» шрифты приобрели пристойные очертания «из коробки». Казалось бы, чего ещё желать? Оказалось, что есть чего.

Одним из первых проектов по «улучшению» шрифтов был infinality.net, в рамках которого разрабатывались патчи для поддержки субпиксельного рендеринга. Применение их было сугубо делом вкуса, да и необходимость в них, как я уже сказал, постепенно отпадала, хотя патчи эти есть в репозиториях большинства дистрибутивов. Но один из результатов этого проекта остаётся интересным всем, кто к шрифтам «не ровно дышит».

Это – пакет fontconfig-infinality. Сам по себе он ничего не патчит и ничего не «улучшает». Но – позволяет выбрать стиль рендеринга, например, командой infinality-ctl setstyle. Стили эти таковы: отладочный, linux, infinality, osx, osx2, win7, win98, winxp. И различаются они параметрами хинтинга. Какой из стилей лучше, какой хуже – не скажу: смотрите сами…

2013

О причинах systemd’изации

LinuxFormat, #165-166 (январь 2013)

Феномен тотального внедрения менеджера инициализации systemd требует своего объяснения. И самое простое из них – методом аналогии.

Вспомним стоны о несовершенстве законодательства, раздававшиеся со всех концов нашей страны на заре её капитализации. Для исправления чего за последние 20 лет законов было принято больше, чем за все годы советской власти. Законов на все случаи жизни – от регулирования Интернета до отношения к «животным-компаньонам». Что, впрочем, не сделало их исполнение более обязательным. Потому что никому из наших законотворцев не пришло в голову выступить с инициативой: наложить мораторий на принятие новых законов лет на десять. И попробовать исполнять хотя бы часть законов существующих.

Аналогичная ситуация нынче сложилась и вокруг Linux’а. К исходу нулевых «законотворческих» инициатив было накоплено… целые геологические напластования. Оставалось только применить их в разработке готовых решений. Однако начался новый виток инициатив. И в результате время решений опять откладывается. Вероятно, до той поры, пока современные инициативы не покажутся устаревшими, и их надо будет заменять более прогрессивными.

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

Возвращаясь к PCLinuxOS

LinuxFormat, #167 (февраль 2013)

Ровно год назад (LXF #154, февраль 2012) сочинил я колонку о дистрибутиве PCLinuxOS и его отечественном сообществе – в весьма оптимистичных тонах. Однако – как сглазил. Во-первых, активно развивавшиеся 64-битные сборки так и не вышли из тестовой стадии. Во-вторых, официально поддерживаемые десктопы свелись к KDE и LXDE (в трёх и двух вариантах, соответственно), причём качество промежуточных релизов подчас оставляло желать лучшего. В-третьих же и главных – дистрибутив растерял свой имидж самой rolling’овой системы из всех rolling releases: в отношении таких ключевых компонентов, как ядро и KDE, он стал отставать на полкорпуса, а то и на корпус.

Тем не менее, на distrowatch.com PCLinuxOS из десятки сильнейших не выходил – а это показатель если не числа пользователей, но их интереса к дистрибутиву. И отечественные пользователи в основном не разбежались, подобно хлопцам пана атамана (напомню, их местообитание – pclinuxos.su). Мир замер в ожидании…

И оно оказалось не напрасным: в конце ноября – начале декабря выходит в свет полная линейка KDE- и LXDE-сборок (правда, по прежнему только 32-битных). А вслед за тем начинается перенос базового репозитория – ко времени выхода журнала, надеюсь, он будет здесь pclinuxos.com. Так что похоже, что слухи о смерти PCLinuxOS оказались столь же преувеличенными, как некогда – великого писателя. И он по прежнему будет радовать нас сочетанием традиционной ориентации в устройстве с модерном в комплектации софтом.

Немножко о DragonFly…

LinuxFormat, #168 (март 2013)

Не секрет, что далеко не все линуксоиды в восторге от изменений, происходящих нынче с их операционкой. И потому начинают потихоньку посматривать по сторонам в поисках запасного аэродрома. И одно из привлекающих взгляд направлений – DragonFly BSD. Отпочковавшись от FreeBSD 4-й ветки, она почти 10 лет развивалась самостоятельно и успешно. Однако – не вполне интересно для конечного пользователя.

В частности, из рук вон плохо было в ней с приложениями и управлением оными. В момент зарождения этой ОС Мэтт Диллон декларировал и собственную систему пакетного менеджмента, а в качестве паллиатива предложил порты FreeBSD. Увы, не сложилось: на собственную систему просто не хватило сил, а сборка бинарников из Free’шных портов напоминало шитие на живую нитку.

Тогда в качестве следующего паллиатива в DragonFly приняли систему pkgsrc из NetBSD – надёжную и безотказную, но имеющую два неискоренимых недостатка: малое количество поддерживаемых приложений и сильное отставание их от апстрима. Что фактически закрывало DragonFly дорогу на пользовательские декстопы.

И вот колесо фортуны свершило оборот: в DragonFly в качестве системы управления пакетами опять вариация на тему портов – dports. Плюс к которой – pkgng из той же FreeBSD, версии 9.1. Нет, не сказать, что всё сразу и в одночасье стало хорошо. Но есть шанс, что хорошо таки будет. А у применителей есть повод поглядеть на DragonFly в реальной работе. Потому что это очень хорошая система…

Файловая система для SSD

LinuxFormat, #169 (апрель 2013)

За последние лет 10-15 мы неоднократно читали победные реляции об успехах в компьютерной области. Однако настоящим успехом последних лет можно считать только начало широкого распространения SSD-накопителей: впервые за всю историю дисковая подсистема перестала быть хроническим тормозом производительности.

Это обусловлено тремя факторами: ценовым, хардверным и софтверным. С первым всё ясно: нынче не обязательно быть Крезом, чтобы позволить себе в ноуте или десктопе такой накопитель на 120-240 ГБ, чего достаточно для системы, приложений и текущих рабочих данных (при условии, что система эта Linux).

С хардверным фактором тоже понятно: самый бюджетный SSD нынче оставляет традиционные винчестеры в… очень далеко. Главное же – рост надёжности: если первые SSD вызывали вполне обоснованные опасения за их долголетие, то сейчас в десктопном сегмент эта проблема практически снята.

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

И вот – свершилось: в ядро Linux версии 3.8 штатно включена поддержка F2FS – «файловой системы, дружественной к флэшкам». Разумеется, она ещё ожидает «обкатки» во всех отношениях. Однако то, что разработана она фирмой Samsung, одним из основных производителей SSD, позволяет надеяться на то, что обкатка эта длинной не будет.

Роман-предупреждение

LinuxFormat, #170 (май 2013)

Великие мыслители, жившие в проклятое старое время, писали сочинения о том, как хорошо станет в светлом будущем, в отдалённой перспективе. Этот жанр называется утопическим романом.

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

А ещё были ребята, которые писали о том, что если всё станет хорошо, то это будет почти также нехорошо, как если бы всё стало совсем плохо. Потому что тогда всё станет совсем одинаково. Имя этому жанру – роман-предупреждение.

Когда-то давно было много UNIX’ов. Потом число их поуменьшилось, но вместо них появилось много Linux’ов, а также разных BSD’ей. И каждый мог выбрать себе систему на ощупь, на вкус и по весу.

Нынче дело идёт к тому, что останется один Linux. А нужен ли один Linux? Ведь в своё время он взял именно тем, что Linux’ов было много. А одна система, истинно верная, у нас и так есть. Я не буду повторять, как она называется. Потому что есть и ещё одна система, не менее верная. И пусть они промеж собой решают, кто там настоящий ленинец, а кто троцкист-уклонист.

Но вот если не станет наших многих Linux’ов, будет… Нет, не страшно – человечество и худшие беды переживало. Но станет скучно.

Монотеизм или дуализм? А может – язычество

LinuxFormat, #171 (июнь 2013)

В прошлой колонке (LXF #170) был дан эскиз апокалиптической картины – засилья одного-единственного истинно правильного Linux’а, под гребёнку которого подгребут все дистрибутивы этой ОС.

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

Первое – это дистрибутив с самой развитой инфраструктурой. Второе – число «настольных» его пользователей которого количество всех остальных «десктопных линуксоидов», вместе взятых. Третье – это дистрибутив, породивший неисчислимое множество ремиксов, респинов и прочих клонов. И, наконец, четвёртое и главное – разработчики Ubuntu не собираются отказываться от его своеобразия в угоду новомодным тенденциям.

Однако не Ubuntu единой живо многообразие Linux’ов. Не следует забывать и о прародительском Debian’е, который в силу своей «многоядерной» ориентации не может замкнуться на унифицированном Linux’е. И который дал необозримый океан производных дистрибутивов. В том числе таких любопытных, как aptosid и siduction, основанных на «нестабильной» ветке Debian’а. Очередная версия первого из них только что вышла. По опыту прежних лет днями можно ожидать и появления свежего siduction’а. И тогда им будет посвящена следующая колонка.

Песнь о потомках Sid’а

LinuxFormat, #172 (июль 2013)

Жил-был мальчик Sid, который всё портил. И делал это так умело, что его именем назвали unstable-ветку дистрибутива Debian. Которая, как знают все его поклонники, может дать фору иным стабильным релизам. А потому издревле многие хотели использовать её в мирных, а не только в тестировочных, целях. Что и было реализовано в виде дистрибутива sidux, который по копирастическим причинам сменил имя на aptosid, а затем ответвил от себя дистрибутив siduction.

Не смотря на внешнее сходство, между этими дистрибутивами есть и существенные различия. aptosid – это действительно Sid, адаптированный для практического десктопного применения с использованием KDE в качестве рабочей среды по умолчанию. Он разрабатывается по модели полного rolling’а, то есть штатно предполагает не апдейт с релиза на релиз, а перманентное обновление системы вслед за таковым исходного Sid’а.

Сборки siduction охватывают почти все рабочие среды – от тяжёлых (KDE, GNOME 3) через «средние» (Xfce) до лёгких (LXDE, Razor-qt), а также noX (»голая» консоль). Причём все они регулярно обновляются до текущих версий соответствующего десктопа (как, кстати, и ядро), иногда значительно опережая прародительский Sid. Модель разработки siduction ближе к регулярным релизам, нежели к rolling’у.

Это я к тому, что, не смотря на все поползновения разделить мир Linux’а на два антагонистических класса – systemd’овцев и ubuntu’йцев, он пока не скудеет разнообразием: не далее чем в мае вышли новые версии и aptosid, и siduction. Что не может не радовать.

Куда идёт Kubuntu?

LinuxFormat, #173 (август 2013)

С давних лет привыкли мы, что Ubuntu и её отпрыски – близнецы-сёстры между собой (да и со своей матушкой): один инсталлятор, один базис, одни репозитории. Разве что десктопы разные – но они и в одном дистрибутиве бывают разные. Но так ли будет впредь?

Всё началось с того, что Canonical сняла с довольствия Джонатана Риддела – чуть ли не единственного оплачиваемого разработчика одного из отпрысков, Kubuntu. Который, прочем, недолго оставался не при делах, будучи взят на содержание Blue Systems – фирмой, известной финансированием ряда проектов, так или иначе связанных с KDE. И в то время обсуждался вопрос – а сохранит ли Kubuntu своё название, так как компонент её имени после литеры «K» является торговой маркой, которая может быть использована на определённых условиях.

Как показала история, имя своё Kubuntu сохранила. Но и, с выходом релиза 13.04, приобрела своеобразие: собственный инсталлятор, ещё более простой, нежели прародительский, и Muon Discover – собственный аналог Центра приложений головного проекта и остальных его сателлитов.

Самое же главное – в другом: если Ubuntu, начиная с грядущего релиза 13.10, переходит на дисплейный сервер Mir, призванный заменить X Window System, которую давно уже пытаются списать в тираж, то Kubuntu сохраняет верность последней как минимум на два ближайших релиза. После чего, вслед за всем прогрессивным человечеством, планирует переход на Wayland.

Не начало ли это распада былого единства? Поживём – увидим.

Mir или не Mir, вот в чём вопрос

LinuxFormat, #174 (сентябрь 2013)

Об искоренении Иксов из Linux’а в последние годы говорят не меньше, чем об искоренении пьянства на Руси – во времена Горбачёва. И с тем же успехом. Долгожданный Wayland пока остаётся жданным долго, в полностью рабочем состоянии его ещё никто не видел. А вот с дружно обруганной в сообществе альтернативой – Mir’ом, дело выходит по другому. В настоящее время он доступен для установки в Ubuntu Saucy Salamander из тестового репозитория. И, как ни странно, с некоторыми оговорками, но работает. Причём абсолютно нечувствительно для пользователя – о том, что под десктопом лежит не X-сервер, а дисплейный сервер Mir, можно догадаться только по специально предназначенному для того уродливому курсору. И, надо полагать, он будет включён в релиз 13.10 «головного» дистрибутива.

А вот в таких сателлитах, как Kubuntu и Lubuntu, его не будет, правда, по разным причинам. Майнтайнеры Lubuntu мотивируют своё решение ресурсоёмкостью Mir’а, тогда как их дистрибутив рассчитан на старые и слабые машины. В Kubuntu же без комментариев планируют использовать Иксы ещё два релиза, после чего плавно переходить на Wayland.

А вот майнтайнеры Xubuntu на распутье. В знак чего выпустили тестовую сборку 13.10 с Mir’ом. Мимо которой я пройти не смог. И потому вру, как очевидец: Xubuntu поверх Mir’а работает тоже. Причём – на системе AMD APU, оказавшейся ранее слабым местом в собственно Ubuntu. И работает столь же прозрачно, как и в «головной» системе. Так что остаётся только дожидаться, какой же ответ дадут майнтайнеры дистрибутива на стоящий перед ними гамлетовский вопрос…

Заработать на FOSS: маечки или ехать?

LinuxFormat, #175 (октябрь 2013)

В начале августа мир свободного софта был потрясён наглым бесчинством… нет, не бухгалтера Кукушкинда, а Патрика Вернера, разработчика дистрибутива Parted Magic. Который пожелал брать за своё произведение деньги – аж 4,99 американских рублей. Все геркулесовцы, как один человек, ответили дружным осуждением… правда, от поголовного перехода на сою воздержались.

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

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

Правда, у тех, кто не может поступиться принципами и отбашлять Патрику 5 уёв, есть выход: собрать собственный аналог Parted Magic’а. Что, скажу по секрету, вполне по силам почти любому линуксоиду-применителю. Но ведь это надо делать – а скачивать готовую разработку на халяву гораздо приятнее.

Дорога к Mir’у

LinuxFormat, #176 (ноябрь 2013)

… Только-только смолкли горестные стоны по поводу отказа Intel поддерживать Mir в своих видедрайверах…

… Едва стихло ликование народа по поводу выхода бета-версии релиза 13.10 Ubuntu, в который Mir всё-таки включили по умолчанию…

… Как снова нам прислали из рук вон плохую весть, что в релизе 13.10 Mir’а по умолчанию таки не будет…

Но так ли она плоха, что из рук вон?

С точки зрения пользователя десктопа с видеосистемой от Intel, между Иксами и Mir’ом внешне почти нет разницы. Так что его эта новость не затрагивает.

С точки зрения пользователя десктопа с видео от AMD или Nvidia – весть скорее хороша. Потому что в большинстве случаев ему всё равно пришлось бы откатываться на Иксы – даже со свободными драйверами Mir пока работает не совсем гладко (а проприетарных просто нет).

Да, Mir нужен пользователям гаджетов – хотя только тем, кто не мыслит их без Linux’а. Но много ли таких на белом свете? Да и в Ubuntu Touch он как раз и будет.

Конечно, Mir нужен разработчикам – для унификации кодовой базы десктопных и мобильных версий. Вот пусть они и доводят до ума его десктопную линию, а потом предлагают её по умолчанию.

Так что можно только восхититься здравомыслием разработчиков Canonical, которые не стали тренироваться на своих пользователях, заставляя их материться, снося Mir при несовместимости с их «железом». Но дали возможность тем, кому он действительно нужен или интересен, поставить его самостоятельно.

Слово о Cinnamon’е

LinuxFormat, #177 (декабрь 2013)

В историческом цикле, завершившимся статьёй этого номера, я упомянул Cinnamon – форк GNOME 3, созданный в рамках дистрибутива Mint, представляющего собой дериват Ubuntu. Первоначально эта среда представляла собой попытку придать GNOME Shell’у облик классического GNOME 2, заодно снабдив её средствами настройки, которыми GNOME 3 не блистал. Однако развитие последнего шло в направлении, для разработчиков Mint’а неприемлемом. И в конце концов они вынуждены были отказаться от базиса GNOME – в октябре сего года появилась полностью пересобранная среда Cinnamon 2, в которых большинство базовых компонентов «третьегнома» заменено собственными аналогами.

В полностью отлаженном виде она будет включена в Mint 16, релиз которого, надеюсь, будет доступен ко времени выхода этого номера. Однако уже сейчас её можно опробовать как в составе Mint 15, так и, с некоторыми оговорками, Ubuntu 13.10. И опробование это оставляет самое благоприятное впечатление – в частности, своими прекрасными средствами настройки: в них богатство, не уступающее конфигуратору KDE, совмещается с простотой центра управления старого GNOME 2. И, что характерно, все настройки выполняются без привлечения сторонних «твикеров», изобилием которых успела прославиться Ubuntu с её средой Unity. Не проявился в Cinnamon’е и баг с переключением раскладок, недавно доставивший столько веселья пользователям Saucy Salamander.

Очередной идеал? Нет, просто ещё один островок спокойствия и здравомыслия в бушующем море тотального «подмякитного» прогресса.

Статьи

Ubuntu и Kubuntu: гуманистический Linux

LinuxFormat #76 (февраль 2006)

В этой статье речь пойдет о семействе дистрибутивов Ubuntu, включающем, кроме эпонима, также Kubuntu и Edubuntu, а также несколько национально-специфических систем и сторонних разработок (среди которых недавно появилась разработка Google, Goobuntu).

Об Ubuntu и Kubuntu

Основатель этого семейства дистрибутивов – южноафриканец Марк Шаттлворт, один из разработчиков Debian и по совместительству – бывший глава бывшей Интернет-компании Thawte Consulting. Деятельность которой была столь успешна, что на закате эпохи dot-com’ов ее приобрела известная корпорация VeriSign за астрономическую сумму, сделавшую Марка весьма богатым человеком. После чего он повел себя не очень стандартным для акулы капитализма образом.

Что надлежит сделать порядочному человеку в случае нежданного богачества? Перво-наперво, «поделиться с пацанами». И каждый из бывших сотрудников Thawte Consulting получил премию – миллион рэндов (более US $100000). Во-вторых, следует осуществить голубую мечту своего детства. И Марк слетал в космос туристом, оказавшись в этом качестве вторым человеком в истории Земли. В-третьих, стоит подумать о тех, кому не повезло стать миллионерами. И Марк создает и финансирует несколько некоммерческих организаций – по развитию образования в Африке, помощи развивающимся странам, и так далее. И, наконец, вернуться к тому, с чего начинал – в данном случае в начале всех начал оказался Linux, на котором был построен бизнес компании Thawte. А посему Марк собирает команду для разработки собственного дистрибутива Linux. В основу которого, естественно, кладется Debian – собственно, Ubuntu и характеризуется как Debian с «человеческим лицом». Говорят, что само слово Ubuntu на одном из африканских языков означает нечто подобное нашему понятию гуманизм.

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

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

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

Вторая особенность Ubuntu – в том, что при инсталляции системы по умолчанию автоматически устанавливается и настраивается графическая среда GNOME. Но, поскольку это – лишь один из возможных пользовательских десктопов, немедленно был создан вариант дистрибутива, использующий в качестве рабочего окружения KDE. Который логично получил имя Kubuntu. Подчеркнем, что Ubuntu и Kubuntu – это одна и та же система, использующая общий репозиторий пакетов. И различия их проявляются только в комплектации инсталяционного CD или DVD. Третий же основной представитель семейства, Edubuntu – это Ubuntu, укомплектованный образовательными программами.

В Kubuntu (как и в Ubuntu) в качестве программы установки используется тот же Debian Installer, что и в последней (Sarge) версии материнского дистрибутива. Правда, несколько модифицированный. Если установка Debian выполняется в два этапа, разделенные рестартом машины (первый – разметка диска и установка базовых компонентов, второй – дополнительных пакетов и начальное конфигурирование), то вариант от Ubuntu – как бы в полтора: вся базовая установка и начальное конфигурирование совмещены в один этап, а после перезагрузки происходит только развертывание дополнительных пакетов (GNOME или KDE с соответствующими приложениями – для Ubuntu и Kubuntu, соответственно).

И еще одна важная особенность установщика Ubuntu: в ходе инсталляции по умолчанию не создается аккаунта суперпользователя, и в дальнейшем все действия по администрированию системы выполняются через программу sudo, sudoedit или штатными средствами GNOME или KDE – все они требуют для доступа к правам root ввода обычного пользовательского пароля. Правда, при установке в режиме эксперта root-аккаунт может быть создан – но в дальнейшем это повлечет некоторые сложности, так что начинающему пользователю лучше этого не делать.

Настройка доступа к репозиториям пакетов

По завершении установки пользователь получает в свое распоряжение почти готовую к использованию среду – локализованную (для Руси – локаль UTF8), с офисным пакетом (OpenOffice.org), коммуникационными, графическими и мультимедийными приложениями (таковыми выступают штатные средства GNOME или KDE). Но, к сожалению, именно «почти»: русификация нуждается в некоторой доработке, а использование мультимедийных приложений ограничено, по понятным лицензионным соображениям, только открытыми форматами (типа ogg). Исправление этих мелких и во многом вынужденных недоработок требует доустановки пакетов. И потому одно из первых, что потребуется начинающему пользователю – это освоение системы пакетого менеджмента Ubuntu. И здесь первый шаг – настройка доступа к репозиториям пакетов.

После обычной установки имеется доступ только к одному такому репозиторию – установочному CD или DVD. Но кое-какие компоненты можно получить только из репозиториев сетевых. Делается это с помощью программного комплекса apt.

Источники пакетов, получаемых через apt, описываются в специальном конфигурационном файле – /etc/apt/sources.list. После пользовательской установки по умолчанию он содержит строку вида

deb cdrom:[Kubuntu 5.10 _Breezy Badger_ – Release i386 (20051012)]/ breezy main restricted

плюс еще несколько закомментированных строк, распадающихся на отдельные секции. Формат каждой строки таков (рис. 1):

  • тип пакета – deb для бинарников и deb-src для исходников;

  • URL архива – в наших условиях это будет http://ru.archive.ubuntu.com/ubuntu;

  • имя собственное дистрибутива – для текущей версии breezy (собственно дистрибутив), breezy-updates, breezy-backports, breezy-security (дополнительные компоненты;

  • тип репозитория – main и restricted (основная часть дистрибутива, поддерживаемая командой обновления безопасности), universe и multiverse (дополнительная часть, лишенная соответствующей поддержки).

Нам они понадобятся все, включая и те, что являются как бы не совсем официальными (universe и multiverse). Так что достаточно просто снять комментарии со всех строк, начинающихся с deb и deb-src – не исключено, что некоторые пакеты придется строить из исходников.

Сделанного достаточно, чтобы доустанавливать пакеты из дистрибутива, не включенные в комплект установочного компакт-диска, а также получать все штатные обновления. За обновлениями же не вполне штатными (например, KDE последних версий) нужно следить на сайте http://www.kubuntu.org – там будут исчерпывающие указания по подключению дополнительных репозиториев.

Основы пакетного менеджмента

Теперь необходимо сначала сказать несколько слов о пакетах, используемых в Ubuntu и Kubuntu.

Cемейство дистрибутивов Ubuntu основывается на дистрибутиве Debian и наследует его формат пакетов (deb). Это – архивный файл, включающий скомпилированные исполняемые бинарники (и все необходимые им для работы компоненты), и так называемые управляющие файлы, в том числе описания зависимостей пакета.

В Debian и его клонах зависимости имеют несколько градаций: обязательные (depends), настоятельно рекомендуемые (recommends), рекомендуемые умеренно настойчиво (suggests). Первая градация – это обычные «жесткие» зависимости – пакеты, без которых установка и работа данного невозможна. Ну а настоятельно рекомендуемые и рекомендуемые просто – это две разновидности «мягких» зависимостей, добавляющих пакету те или иные необязательные, но полезные функции. Впрочем, таково субъективное мнение майнтайнера данного пакета – вполне возможно, что мнение пользователя будет иным.

В отношении средств управления пакетами в Kubuntu имеется богатый выбор. Однако в этой статье речь пойдет только о двух из них – dpkg и apt.

Команда dpkg сотоварищи

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

$ sudo dpkg -i path2/packagename.deb

и дело в шляпе – через считанные мгновения пакет packagename.deb будет установлен.

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

Обратная процедура – удаление ненужных пакетов. Это делается двояко: команда

$ sudo dpkg -r packagename

удалит пакет, но сохранит настроечные его файлы, а команда

$ sudo dpkg -P packagename

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

Вообще-то dpkg – это целое семейство команд, включающее, кроме себя самой, еще несколько: dpkg-deb, dpkg-query и так далее. Один из представителей этого семейства, который так и называется — dpkg-reconfigure, служит цели переконфигурирования уже установленных пакетов. Делается это так:

$ sudo dpkg-reconfigure packagename

После этого вызывается диалоговая программа конфигурации – debconf, и ответы на серию более или менее тривиальных вопросов позволяют добиться желаемого результата.

Инструментарий apt

Набор apt (Advanced Packaging Tools) – это программный комплекс, охватывающий все стороны управления пакетами. Он включает в себя почти десяток команд, тесно переплетающихся друг с другом. Так, назначение команды apt-cache – в получении информации о пакетах, причем не только установленных на локальной машине, но и находящихся в сетевых репозиториях. Сведения эти берутся из локальной базы данных, создаваемой во время инсталляции системы, и в дальнейшем обновляемой с помощью apt-get:

$ sudo apt-get update

При этом устанавливается соединение со всеми репозиториями, перечисленными в файле /etc/apt/sources.list, и локальный кэш пакетов приводится в соответствие с их текущим состоянием.

Теперь можно произвести тотальное обновление системы:

$ sudo apt-get upgrade

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

В некоторых случаях apt-get upgrade не сможет выполнить обновление каких-либо пакетов, о чем честно и сообщит. Причины этому могут быть разные – например, конфликт новых зависимостей пакетов. На сей случай имеется более радикальное средство – dist-upgrade. Именно к нему следует прибегнуть и при обновлении старой версии дистрибутива до нового релиза:

$ sudo apt-get dist-upgrade

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

Вот теперь можно взяться и за отдельные пакеты. Дистрибутивные deb-пакеты вовсе не совпадают с пакетами авторскими – они намного более дробные. Например, каждый из авторских пакетов KDE, типа kdenetworks или kdegraphics, делится на множество мелких монофункциональных deb-пакетов. И тут на помощь придет команда apt-cache search, которая в качестве аргумента воспринимает ключевое слово. И в ответ на команду вида

$ apt-cache search ftp

последует список всех пакетов, в описании которых фигурирует ключевое слово ftp.

Выявив нужный пакет, следует обратиться к команде apt-get install. посредством которой будет он благополучно скачан и установлен – со всеми обязательными (depends) зависимостями. Перед этим будет опять-таки выведен список подлежащих установке пакетов, объем скачиваемого материала и изменения в занятом дисковом пространстве. А также будет дан список пакетов, связанных с данным разными типами «мягких» зависимостей – пользователю останется только решить, нужны ли они ему.

Инструмент apt-get выполняет и удаление пакетов:

$ apt-get remove packagname

При этом настроечные файлы сохраняются – для их удаления требуется опция —purge, которая выполнит полную очистку системы от всех компонентов пакета.

Очень ценна опция -i, обеспечивающая инверсию действия операторов. То есть команда

$ sudo apt-get remove packagname -i

установит пакет packagename, а команда

$ sudo apt-get install packagname -i

напротив, удалит его. Что очень полезно при экспериментировании с большим количеством пакетов.

Если нужно собрать из исходников много пакетов, пересобрать систему целиком или требуется компиляция с какими-либо особыми условиями, следует прибегнуть к инструменту – apt-build. Это – отдельный пакет, который устанавливается обычными образом, и в ходе установки настраивается. Настройки включают: выбор степени оптимизации, облегченной (соответствующая флагу gcc -O1), средней (флаг -O2) или усиленной (-O3), указание дополнительных флагов gcc, если в них есть необходимость, опций для команды make, выбор процессора (Pentium, Pentium-4 и так далее). Если же для отдельных программ условия компиляции нужно изменить – apt-build можно переконфигурировать обычным образом:

$ sudo dpkg-reconfigure apt-build

Команда apt-build включает ряд операторов, таких, как update – обновление списка доступных пакетов, upgrade – сборка обновленных пакетов, world – полная пересборка всей системы. То есть инструмент apt-build, не смотря на сугубо пакетную природу использующих его дистрибутивов, имеет ничуть не меньшие возможности по индивидуалированной компиляции, чем система портов FreeBSD или аналогичные средства Source Based дистрибутивов Linux.

Kubuntu по русски

Дистрибутив, претендующий на «гуманное отношение к пользователям», должен в обязательно порядке уметь разговаривать с ними на родном их языке. в том числе и русском. И тут Ubuntu и Kubuntu в первом приближении выглядят терпимо: если в ходе установки выбрать русский язык и соответствующую ему страну, то есть Россию, то по завершении процесса мы получаем более-менее русифицированные Иксы с прогрессивной локалью UTF-8.

А вот в консоли дело обстоит из рук вон плохо: шрифт для вывода кириллических символов при старте машины автоматически не подгружается, а попытка ввести русские буквы приводит к появлению на экране вполне нечленораздельной абракадабры. Конечно, Kubuntu не ориентирован на использование в текстовом режиме. Однако и терпеть в консоли такое безобразие тоже не хочется. Так что давайте уж доведем до ума русификацию консоли.

Процедура эта достаточно просто выполняется вручную. Во-первых, обеспечиваем загрузку шрифта со встроенной таблицей sfm (screen font map): вызываем для редактирования необходимый конфиг

$ sudoedit /etc/console-tools/config

и вносим в него строки:

SCREEN_FONT_vc1=LatArCyrHeb-16
SCREEN_FONT_vc2=LatArCyrHeb-16
SCREEN_FONT_vc3=LatArCyrHeb-16
SCREEN_FONT_vc4=LatArCyrHeb-16
SCREEN_FONT_vc5=LatArCyrHeb-16
SCREEN_FONT_vc6=LatArCyrHeb-16

Загружаемый таким образом шрифт выглядит весьма убого, но его можно заменить шрифтами либо из пакета terminus-fonts, либо из коллекции с http://www.posix.ru/download.shtml (последние нужно поместить в каталог /usr/share/consolefonts/ вручную).

Во-вторых, устанавливаем юникодовскую раскладку клавиатуры (ru-utf, скачать ее можно здесь же: http://www.posix.ru/download.shtml):

$ sudo cp path2/ru-utf.kmap.gz /etc/console/boottime.kmap.gz

И после перезагрузки машины убеждаемся, что обрели способность к вводу символов кириллицы. Раскладка – для win-маркированных клавиш (то есть с нормальным расположением знаков препинания), переключение латиница/кириллица – по правому <Control>

Есть и другой способ русификации, более соответствующий Debian Way – установка и конфигурирование пакета console-cyrillic, что предлагается читателю в качестве самостоятельного упражнения.

Вторая проблема из числа локально зависимых, требующая решения, – проверка орфографии. С этим также некоторая напряженка. По умолчанию в этом качестве использует aspell – что естественно при юникодной локали (так как ispell с юникодом до сих пор не работает). Имеется и пакет с русским словарем для него, aspell-ru – но только для архитектуры i386. Для AMD64 же можно предложить два решения.

Первое – через http://rpmfind.net/ отыскать более-менее свежий rpm-пакет для архитектуры AMD64, установить alien – трансформатор пакетов из одного формата в другой и его посредством преобразовать rpm в deb:

$ fakeroot alien aspell-ru-0.99f7-2.x86_64.rpm

Каковой и устанавливается обычным образом:

$ sudo dpkg -i alien aspell-ru-0.99f7-2.x86_64.deb

Второе же решение – просто автоматом построить соответствующий deb-пакет посредством apt-build, после чего остается подключить его к любимому текстовому редактору или просто запускать из командной строки.

Борьба за мультимедиа

Все сказанное ранее относилось к любому из дистрибутивов семейства Ubuntu. Теперь же речь пойдет о специфике Kubuntu. В нем для проигрывания аудио штатно предназначена программа amaroK, а за воспроизведение видео отвечает универсальный медиаплейер Kaffeine. Сразу после установки, что называется, «из коробки», оба они в состоянии только запускать звуковые ogg-файлы, ни mp3, ни Real Audio их восприятию недоступны, как, впрочем, даже и банальные avi’шки домашнего производства.

Столь нехорошее поведение объясняется отсутствием движков и кодеков. И связано с лицензионными соображениями. Дело в том, что алгоритмы, на которых основываются программы воспроизводства аудио/видео (например, mpeg-кодирования) запатентованы в тех странах, законы которых признают патенты на алгоритмы (или, скажем, законы природы). И майнтайнеры дистрибутивов, ориентированных на международное распространение (а разработчики Ubuntu/Kubuntu именно к тому и стремятся), вынуждены с этим считаться.

Благо законы нашей Родины, вопреки Салтыкову-Щедрину, в такой глупости до сих пор замечены не были, и мы можем слушать музыку или смотреть кино, не чувствуя себя интеллектуальными преступниками. Остается только обеспечить свое право возможностью его использовать.

Для чего нам и потребуется устанавливать эти самые кодеки/движки. Возникает вопрос – какие? Для ответа придется прибегнуть к методу ползучего эмпиризма (рис. 2).

Сначала займемся звуком, воспроизводимом посредством amaroK. Посредством

$ apt-cache search amarok

смотрим, какие движки (engine) к нему можно подключить в принципе. Оказывается, следующие:

amarok-gstreamer – GStreamer engine for the amaroK audio player
amarok-arts – aRts engine for the amaroK audio player
amarok-engines – output engines for the amaroK audio player
amarok-xine – xine engine for the amaroK audio player

Не буду тянуть кота за хвост – я остановился на варианте amarok-xine, дополненном пакетом akode-mpeg – ведь mpeg потребуется в любом случае. После чего amaroK начинает нормально играть не только mp3 и Real Audio, но и, в качестве бесплатного приложения, – классово чуждый WMA. Правда, Kaffeine – категорически отказывается что либо, кроме ogg-файлов – но все-таки основное его назначение – крутить видео. А этого он пока тоже делать не хочет.

Изучение вывода команды

$ apt-cache search kaffeine

приводит к заключению, что нужно установить gstreamer0.8-mpeg2dec – после этого начинается показ фильмов, содранных с VideoCD – но без звука. Ставлю gstreamer0.8-mad – после этого в них появляется звук. Но мои домотканные avi’шки по прежнему не прокручиваются. Последняя надежда – устанавливаю gstreamer0.8-ffmpeg. Теперь, наконец, начинают крутиться и они, так что эксприменты можно прекратить со спокойной душой.

Linux-пресса на Руси: Вопросы истории

LinuxFormat,, #78 (апрель 2006)

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

Здесь не будет ни полной библиографии статей, ни даже упоминаний всех изданий, уделивших место для предмета нашего разговора. Моя цель, скорее, выявить тенденции развития Linux-прессы в прошлом и ее перспективы – в грядущем. Термин «Linux-пресса» употребляется здесь для краткости – не следует забывать, что речь идет также о UNIX и Open Source вообще.

Но сначала – несколько слов о том, с чего все началось. У истоков Linux-прессы лежал журнал «Монитор» (вскоре прекративший свое существование), который в 1994 году напечатал статью Владимира Водолазкого о том, как легко и без головной боли установить Linux. В этой статье, вероятно, слово Linux впервые прозвучало в русскоязычном окружении. Актуальность же она сохраняла еще годы спустя, будучи не только источником информации об этой ОС, но и руководством к действию: ксерокопии ее ходили по рукам в сопровождении горы дискет с дистрибутивом Slackware, и, вероятно, не одно поколение «линуксоидов первого призыва» ставило свою первую систему с этого «комплекта». Итогом той давней публикации стала книга Владимира «Путь к Linux» – первое (1999 год) отечественное издание на эту тему. Но это – уже другая история.

Первым журналом, в котором сложилась устойчивая традиция линуксописания, не прерывающаяся и по сей день, стал «Мир ПК». В нем, начиная с 1995 года, регулярно начали публиковаться как переводные, так и оригинальные статьи о самых разных аспектах ОС Linux. Причем отечественные авторы преобладали, и их публикации проявили отчетливую тенденцию к циклизации: до сих пор памятны циклы статей Игоря Хименко (по совместительству – одного из соратников Сергея Кубушина, развивавшего тогда на Украине инновационный дистрибутив KSI; однако и это отдельная тема), посвященные файловой системе Linux, процессам, командной оболочке bash. Правда, со временем традиция циклических публикаций в «Мир ПК» угасла…

Начиная с 1997 года, многие общекомпьютерные журналы начинают публиковать статьи по тематике UNIX, Linux и Open Source – не часто, но относительно регулярно такие материалы появляются в журналах «PC Magazine/RE», «LAN» и «Открытые системы». Характер этих публикаций различен. Если «PC Magazine/RE» печатает почти исключительно переводные статьи весьма случайного содержания, то «LAN» и «Открытые системы» (тот же издательский дом «Открытые системы», что и «Мир ПК») отдают предпочтение отечественным авторам, и в их материалах можно наметить ту же тенденцию к циклизации, впрочем, также не получившую развития. Упомяну тут и журнал «СУБД», проживший короткую, но яркую жизнь (оборвавшуюся вскоре после приснопамятного августа 1998 года) – это был практически единственный компьютерный журнал «академического» стиля. И, хотя специальных материалов о Linux в нем не было, его тематика тесно пересекалась с UNIX и Open Source.

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

Первым в этом ряду должно упомянуть журнал Byte Россия. Начав свое существование в 1998 году под эгидой издательского дома «Питер», он с первых же номеров начал регулярно печатать материалы по UNIX и Open Source, причем переводные статьи сразу же составляли меньшинство по сравнению с работами отечественных авторов. Очень скоро эти материалы были выделены в специальный раздел – Byte/UNIX, своего рода журнал в журнале, редактором которого стал Алексей Выскубов. Это была первая попытка создания специализированного издания по тематике UNIX, Linux и Open Source вообще: помимо статей о Linux, здесь уделялось внимание и BSD-системам, и общим вопросам идеологии свободного программного обеспечения. В частности, именно на его страницах увидели свет переводы статей Николая Безрукова об особенностях разработки программ с открытыми исходными текстами, сохраняющие актуальность и по сей день. Благо, они доступны в сети.

Вообще трудно переоценить роль Byte Россия в развитии русской Linux-прессы того времени – тираж его в 2000 году достиг 17 тысяч, и не последнюю роль в этом сыграли материалы UNIX-раздела. Однако, в конце 2000 года журнал был продан другому издательскому дому, политика его резко изменилась, раздел Byte/UNIX был ликвидирован, полностью сменилась редакционная команда. И хотя в начале 2001 года в нем еще по инерции публиковались некоторые материалы по Linux, интерес к нему со стороны линуксописателей (и, подозреваю, линуксочитателей) был утрачен безвозвратно.

Однако развитие Linux-прессы продолжалось, правда, существенно сместившись в сторону онлайновых СМИ. Эстафету подхватила Компьютерра: в начале 2001 года в рамках этого издательского дома возник проект Софтерра (редактор Сергей Scout Кащавцев) со специальным разделом – FreeOS (Федор Сорекс), посвященным свободному ПО вообще и ОС Linux (а также Free-, Open- и прочим BSD), в частности. Все материалы проекта публиковалась в Сети, но некоторые статьи раздела попадали также и на страницы «бумажной» Компьютерры.

Наибольшим успехом проекта можно считать выход тематического номера журнала «Домашний компьютер», тоже относящегося к издательскому дому Компьютерра (ДК, 2002, #12). Созданный под идейным руководством Максима Отставнова, он содержал материалы по всем аспектам устройства и использования Linux, в том числе и в домашних условиях. К сожалению, этот успех был последним: в течение первых месяцев следующего года проект FreeOS плавно сошел на нет (да и Софтерра как таковая – тоже) , материалы его исчезли из прямого доступа с сайта журнала, и кое-что, похоже, утрачено безвозвратно, как и онлайновая версия тематического выпуска ДК.

Следующим номером в эстафетном забеге Linux-прессы оказался Upgrade – усилиями Алены Приказчиковой и Сергея Голубева, начиная с середины 2002 года, почти каждый номер в «софтверном» разделе содержал материалы про Linux и Open Source, чему способствовал и приток новых авторов. Тенденция к систематическому освещению темы нашла свое воплощение в тематическом выпуске Upgrade Special, посвященном Linux вообще и дистрибутивам Live CD в особенности (середина 2004 года). Однако, как и в случае с ДК, он одновременно стал символом упадка интереса к Linux и Open Source со стороны редакции Upgrade: в последующее время материалы по этой тематике появлялись там лишь эпизодически.

Сказанное не значит, что остальная компьютерная периодика перестала уделять внимание Linux-тематике. С самого дня своего создания (начало 2001 года) значительную активность на этом поприще проявлял журнал Chip – вплоть до выпусков спецномеров, целиком посвященных Linux, и сопровождавшихся компактом с тем или иным его дистрибутивом. В 2002 году возник журнал «Системный администратор», коему по титулу положено освещать вопросы, связанные с сетевым администрированием – а в этой сфере Linux и свободные BSD-системы доминируют и по сей день (особенно на территории РФ). И материалы о них появляются на его страницах с завидной регулярностью. Время от времени к тематике Linux и BSD обращается «Хакер» – правда, подчас с материалами весьма спорными.

В ряду общекомпьютерных периодических изданий следует выделить упомянутый ранее журнал «Открытые системы». Его специфика в том, что, наряду со статьями популярного направления он публикует и сугубо научные материалы, посвященные теоретическим вопросам Computer Science (что не удивительно, учитывая его академические корни). К сожалению, популярность его все время падает, а в последние годы он практически пропал из розничной продажи.

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

Таким образом, мы плавно подошли к 2005 году. Я не пророк, но думаю, что он войдет в историю как второй, после 1998 года, переломный рубеж в развитии Linux в России. Если первый ознаменовался выходом прототипа первого российского дистрибутива – Mandrake Linux от IPLabs Linux Team (в последующем – Altlinux) и попыткой создания первого специализированного издания (Byte/UNIX), то в течении 2005 года, во-первых, в России резко активизировалась деятельность лидеров мирового дистростроения (Red Hat и Novell/Suse), и, во-вторых, к нему приурочены первые массовые выставки-конференции, специально посвященные тематике Open Source (Open Source Forum Russia, LinuxWorld Russia, LinuxLand на Софтуле).

А для Linux-прессы год этот памятентем, что в течении его начали выходить первые специализированные периодические издания, полностью посвященные Linux и Open Source – Chip Linux Special и Linux Format.

Chip Linux Special – ежеквартальное издание, которое берет свое начало с весны 2005 года. Он генетически связан со специальными выпусками журнала Chip, и издается тем же издательским домом «Бурда», что и прародитель. Комплектуется исключительно оригинальными статьями отечественных авторов. Специфика журнала – сконцентрированность вокруг материалов по «титульной» ОС, расширение тематики в сторону других свободных систем (например, BSD-семейства), насколько я знаю, не планируется.

Эта статья в целом уже была написана, когда поступила печальная весть: журнал Chip Linux Special более издаваться не будет. О причинах этого мне ничего не известно, да и сами источники сложно назвать официальными: помимо личного общения с членами команды Chip Special Linux можно назвать только новость на Linux.org.ru, в которой (со ссылкой на телефонный разговор с издательским домом «Бурда») сообщалось, что журнал было решено закрыть. Хочется надеяться, что «слухи о его смерти сильно преувеличены» и Chip Special Linux еще порадует нас своими выпусками – благо приобрести его можно было «от Москвы и до Находки».

Linux Format – ежемесячный журнал, родившийся в сентябре 2005 года усилиями фирмы Линуксцентр, занимавшейся онлайновой торговлей дистрибутивами свободных ОС и профильной литературой. Он представляет собой перевод одноименного английского журнала, своего рода русское его зеркало: каждый номер по содержанию соответствует аналогичному номеру оригинала (хотя и выходит с некоторым запозданием, обусловленным затратами времени на перевод, верстку и печать). За одним исключением: начиная с 4-го номера, в журнал включаются и оригинальные статьи отечественных авторов. Рискну предположить из исторических аналогий, что с течением времени процент последних будет возрастать. Ведь все патриархи отечественной компьютерной прессы (Мир ПК, Компьютер-Пресс, PC Magzine/RE) начинались некогда как чисто переводные издания.

Отличительная черта Linux Format –открытость. Все стороны его существования – от содержания очередного номера до причин недоставки конкретного экземпляра – можно обсудить на UNIXforum’е и на форуме журнала. Члены редакционной команды в обсуждении участвуют – и, должен вам заметить, к обоснованным мнениям читателей всегда прислушиваются.

Впрочем, много говорить об этом издании не буду: раз вы читаете материал этого номера, то знакомы с ним в достаточной степени. А потому завершу свое сочинение рассуждениями на тему, каким видится идеальный журнал по тематике UNIX, Linux и Open Source (см. следующую статью).

Идеальный журнал

LinuxFormat, #78 (апрель 2006)

Традиционно «толстые» компьютерные журналы разделяются на две части: блок новостей и, так сказать, «тело» журнала – собственно материалы номера. Оправдана ли такая организация в век тотальной интернетизации? В век, когда все, имеющие хоть какое-то подключение к Сети, получают интересующие их последние известия из онлайновых источников, новостные разделы даже компьютерных еженедельников выглядят сборником анекдотов с бородой Карла Маркса. Что же тогда говорить о «новостях» ежемесячников?

Так что же, ликвидировать новостные блоки? Отнюдь – это было бы политически неправильным. Увы – изрядная часть населения постсоветских пространств лишена прелестей Интернета, и Печатное Слово, пусть несколько устаревшее (да и доставленное, силами российской почты, с запозданием), для нее – единственный источник информации. А потому предлагается компромиссный вариант: заменить сборники анек… пардон, новостей – аналитическими их обзорами. Которые, давая достаточно сведений читателям, не имеющим подключения к Сети, в то же время не вызывали бы раздражения своей «бородатостью» у тех, кто таковое имеет. А в идеале – были бы просто интересны сами по себе. Конечно, составление таких обзоров – дело нелегкое, но оправдается повышением читательского внимания.

Теперь об основной части – статьях. Журнал, рассчитывающий на самоокупаемость (а в идеале – и на принесение прибыли) обязан ориентироваться на самые широкие пользовательские массы И потому должен содержать материалы нескольких градаций: для совсем начинающих, для «действующих» пользователей, и для тех, кто ставит своей задачей углубленное изучение каких-либо частных вопросов. Хорошо это или плохо – обсуждать не будем, такое «смешение жанров» на данном этапе развития Linux-прессы является необходимостью. Как показала трагическая кончина журнала «СУБД» (да и безрадостная судьба аккумулировавших его «Открытых систем»), специализированное издание «для профи» пока не имеет шансов выжить на постсоветском пространстве. С другой стороны, ориентация издания на «чайников» чревата потерей интереса к нему, как только «чайники» таковыми быть перестанут (а с помощью хорошего журнала это произойдет очень быстро).

Какой видится компоновка материалов? Возможны варианты: по степени «продвинутости» предполагаемого читателя, по тематике, в том числе и с выделением некоего центрального материала и его «системного окружения». Впрочем, я – категорический противник «темы номера», что приемлемо для еженедельника, но для ежемесячного издания смертельно: ведь если читателю не интересна именно эта тема номера, он на целый месяц лишается возможности что-либо почерпнуть из любимого журнала.

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

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

Я прекрасно понимаю, что общий дизайн издания определяется множеством привходящих факторов (в том числе и политических). Но и тут возможны варианты. Например, давать необходимые команды и листинги «внеформатными» врезками. Или – сделать онлайновое дополнение к журналу, которое содержало бы именно ту часть статей, которая подлежит использованию методом Cut&Paste. Такое дополнение, не дублируя содержание основного материала, будет способствовать его практическому использованию.

Second Open Source Forum Russia

LinuxFormat #81 (июль 2006)

Общекомпьютерные мероприятия, типа великих выставок современности, долгое время не баловали своим вниманием тематику Linux и Open Source. Правда, во времена почти былинные существовала ежегодная выставка UNIX Expo, которая, естественно, не могла пройти мимо Linux’а – именно на одной из этих выставок я приобретал свои первые дистрибутивы. Однако времена те канули в Лету вместе с дешевым долларом приснопамятным августом 1998 года.

Тем более неожиданным оказался всплеск выставочной активности фирм и организаций, связанных с Linux и Open Source, случившийся в прошлом, 2005, году, когда с апреля по сентябрь прошло сразу три мероприятия этой тематики – Open Source Forum Russia, LinuxWorld Russia и Linuxland на Софтуле-2005, в рамках которых, кромес собственно выставок, функционировали и конференции с докладами, в том числе и вполне академического типа. Массовость и представительность этих мерпориятий всяляли надежду, что они станут началом доброй традиции. И вдвойне радостно, что надежда эта оправдалась.

Первой ласточкой в текущем году, как и в году минувшем, стал Второй Российский Форум по Открытому коду (Second Open Source Forum Russia), проводившийся в рамках международной IT-выставки Interop, которая и сама по себе заслуживает нескольких слов.

Базой для проведения мероприятия выступил Международный выставочный центр «Крокус Экспо», расположенный на 66 километре МКАД – на внешней ее стороне. Что само по себе и не страшно. Тем более, что обещание выставочного транспорта от метро Тушинской и Планерной было выполнено – по крайней мере, в первом случае могу это засвидетельствовать лично. Однако добраться до места назначения оказалось задачей не вполне тривиальной: въезд на МКАД (и, в обратную сторону, съезд с нее), построенный во времена развитого социализма, на современные транспортные потоки отнюдь не расчитан.
Сам по себе выставочный комплекс заслуживает только добрых слов. В частности и потому, что под сводами его в те дни удручающей жары царила прохлада. Да и выствочные площади ьыли организованы удобно и просторно.

Правда, собственно выставка к Open Source имела мало отношения. На ней не были представлены ни фирмы – майнтайнеры дистрибутивов, ни разработчики какого-либо открытого софта. Глубокое траление выставочных стендов позволило выявить в них лишь два классово близких компонента.

Первым был стенд российского представительства печально прославившейся в последние годы фирмы SCO. Которая, правда, не все свои силы тратила на судебные тяжбы, а еще и разрабатывала собственную версию UNIX – SCO OpenServer. Демо-версия которой, во искупление грехов, и предлагалась к свободной раздаче.

Вторым порадовавшим моментом был стенд журнала «Системный администратор», с традиционно обширным набором номеров – от старых, давно ставших библиографической редкостью, до последнего, июньского.

Собственно Second Open Source Forum Russia, проходивший 22 июня, собрал весьма представительный сомн докладчиков. В их числе были – и знаменитый Йон мэддог Холл (Jon maddog Hall), исполнительный директор Linux International, рассказывавший о распространении Linux в мире, и Ян Мердок (Ian Murdock), создатель дистрибутива Debian и первый лидер одноименного проекта, говоривший об соотношении открытых исходников, открытых стандартов и о том, как они влияют на окружающий мир. Содержанием доклада Азы Доцлера (Asa Dotzler) – одного из учредителей проектов Mozilla и Firefox, – был рассказ о том, как Firefox превратился в майнстрим современного развития WWW. Зив Сураски (Zeev Suraski), один из создателей PHP, поведал об интегрирующих возможностях, заложенных в последенй версии этого языка сценариев…

Надо отметить, что тема Linux и Open Source рассматривалась не только на специализированном форуме. Немалое внимание ей было уделено и в программе презентаций на стенде IBM, раворачивавшейся на протяжении 22 и 23 июня. Где, помимо ее собственных представителей, выступили докладчики от фирм Altlinux, ASPLinux, Novell, затрагивая вопросы безопасности, использования Linux в корпоративной среде, в настольных и мобильных системах, и многие другие.

Марк Шаттлворт в Петербурге

LinuxFormat #82 (август 2006)

Марк Шаттлворт (Mark Shuttleworth) – один из немногих разработчиков Linux, известный за пределами мира Open Source. Во-первых, его знают как удачливого Интернет-предпринимателя, разбогатевшего на гребне волны dot-com’ов. Во-вторых, он стал вторым в истории Земли космическим туристом. И в-третьих, Марк – учредитель ряда фондов помощи слабо развитым странам, организаций создания образовательных программ в странах «Третьего мира» и тому подобных мероприятий.

Однако в мире Open Source Марк известен, разумеется, не этим. Здесь его знают как разработчика Debian – в прошлом, и как организатора разработки семейства дистрибутивов Ubuntu – в настоящем. В этом своем качестве он возглавляет фирму Canonical – именно она осуществляет финансирование разработки всего семейства, обеспечивает распространение дистрибутива и его коммерческую поддержку, а также ведет прочую организационную работу.

Надо сказать, что дистрибутивы семейства Ubuntu (кроме собственно Ubuntu, в его состав входят также Kubuntu, Xubuntu, Nubuntu и Edubuntu) за короткое время снискали себе немалую популярность. В частности, и потому, что бесплатно рассылаются по всему миру, в том числе – даже в нашу страну. В результате чего в России сложилось достаточно большое и весьма активное сообщество пользователей Ubuntu.

Поэтому известие о визите Шаттлворта в Россию (Москву и Петербург), проходившем 15-16 июня, заинтересовало в основном широкие массы узкого круга, связанного с UNIX, Linux и Open Source. Тем более, что в программу посещения обоих городов входила встреча с теми, кто эти круги представляет – московскими пользователями Ubuntu и Linux вообще, и с Петербургской LUG.

Московская встреча состоялась 15 июня в Институте философии РАН и организована была, насколько я знаю, фирмой Altlinux. Однако на ней я не присутствовал, и потому сказать ничего не могу. А вот на питерской – побывать довелось, о чем и рапортую.

Встреча с Петербургской LUG 16 июня была подготовлена фирмой Линуксцентр и учебным центром «Феникс». В зале последнего, расположенном на территории Географического факультета Санкт-Петербургского Университета, она и происходила. Программа мероприятия включала три пункта: выступление Марка, ответы на вопросы участников и – ну конечно же, какая встреча юниксоидов обойдется без пива? – нечто вроде фуршета.

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

Надо отметить хорошее техническое обеспечение встречи. Аппаратура «Феникса» позволила выполнить аудио- и звукозапись всей встречи – не только выступления, но и впорсов, в том числе и с места. Именно обработка аудиозапсис (смею надеяться, литературная) легла в основу всего нижеследующего материала – в связи с чем выражаю свою признательность организаторам встречи.

Выступление

Выступление Марка осуществлялось на английском языке – он начал его заявлением, что по русски говорит плохо (хотя, по агентурным данным, делает это совершенно без акцента – да и сказанная по русски вводная фраза это подтверждала). Однако перевод выступления обеспечивал Дмитрий Дмитриев из компании Linux Ink, известный своими работами по русификации Red Hat/Fedora и разработкой русской версии Scientific Linux. Так что суть речи Марка была доступна даже тем, кто, подобно вашему покорному слуге, английский на слух воспринимает с трудом.

Для начала Марк рассказал историю своего приобщения к Linux, ставшую уже в анналах Open Source почти столь же хрестоматийной, как история про принтер Ричарда Столлмена или про терминальную программу Линуса Торвальдса. Один приятель дал Марку кучу дискет с дистрибутивом Slackware и шесть упаковок пива, сказав, что это – все, что нужно для освоения Linux. Правда, существует версия, упаковка была одна – с шестью бутылками. Однако я более склонен доверять переводу Дмитрия. Действительно, говоря по русски, без поллитры с Linux’ом тогда, лет десять назад, разобраться было проблематично. Так что вряд ли Марк в этом процессе обошелся даже шестью исходными упаковками…

Далее последовал рассказ о том, как зародилась идея дистрибутива Ubuntu, и об особенностях процесса его разработки. Здесь Марк подчеркнул, что одной из целей дистрибутива было – достижение гармонии между стабильностью и актуальностью включенного в состав софта. Первая задача достигается долговременной поддержкой стабильных релизов, выходящих через определенные промежутки времени (примерно полугодичные, хотя подготовка текущего релиза несколько затянулась), и на протяжении длительного (трех- или пятигодичного) периода пользующихся поддержкой. Вторая же задача осуществима за счет регулярных промежуточных обновлений, предназначенных для пользователей, желающих работать с самым современным софтом.

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

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

Однако и тут Марк подчеркнул, что связи, так сказать, вертикальные – с разработчиками крупных программных пакетов, таких, как Gnome, KDE, Apache, MySQL, Postgress, и многие, многие другие – являются более важными. Потому что в конечном счете именно их работа обеспечивает успех или неуспех любого дистрибутива.

В этом контексте прозвучал и ответ на вопрос, который меня интересовал с первого дня знакомства с Ubuntu: почему для титульного дистрибутива семейства, ориентированного, в том числе, и на начинающего пользователя, в качестве пользовательского окружения был выбран Gnome, хотя, казалось бы, KDE справляется с этой ролью как минимум не хуже. Марк объяснил сделанный выбор тем, что в момент создания Ubuntu Gnome был более простой в использовании средой, нежели KDE. Когда же разработчики KDE, оценив концепцию дистрибутива, предложили вариант со своим десктопом, – родился Kubuntu.

Зашла речь, конечно, и о бизнес-модели, призванной сделать разработку дистрибутива коммерчески выгодной. Здесь интересен следующий момент: вместо создания единой централизованной компании фирма Canonocal, обеспечивающая финансирование разработки Ubuntu и обеспечение его поддержки, привлекает к сотрудничеству распределенные фирмы из разных стран – в настоящее время их более 300, – которые и осуществляют регионально-ориентированную поддержку.

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

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

Действительно, ведь сам принцип разработки открытых исходников базируется на вовлечении в процесс максимально широкого круга лиц, к таковой в принципе способных – и это одна сторона вопроса. Другая же, оборотная, выливается в проблему эффективности контроля над изменениями, которая может обеспечить целостность системы разработки и защиту ее от повреждения некорректно написанными фрагментами кода. То есть, попросту говоря, все сводится к тому, чтобы система была «дуракоустойчивой» – и при этом чтоб никто из разработчиков не ушел обиженным…

Вопросы разработки тесно связаны с вопросами обучения. И в планы Canonical входит создание центров обучения, тестирования и сертификации специалистов, в том числе и в России.

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

Вопросы и ответы

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

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

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

Вопрос: Многие компании сейчас завоевывают мир простыми средствами разработки. На сегодняшний день под Linux нет простых средств разработки. Каково Ваше видение простых интерфейсов разработчика?

Ответ: Разработчики Linux пошли довольно трудной дорогой – заново изобрести велосипед. То есть установить новые правила разработки, правила открытого и свободного программного обеспечения. Мы, конечно, не можем рассчитывать на поддержку и помощь со стороны тех людей, которых привлекают легкие правила. Если Вы хотите добиться изменения ситуации, Вы должны убедить сообщество, что такие вещи, как хорошая документация, красивый дизайн, простота использования – это важные и нужные вещи. Я не думаю, что многое из того, что используется сейчас в мире коммерческой разработки программного обеспечения будет портировано под Linux. В первую очередь мы увидим перенос серверных приложений и баз данных, таких, как Oracle, потому что на них есть реальный спрос. Десктопные же приложения, например, Photoshop, имеют под Linux свои аналоги, например, Gimp, и необходимости в их переносе нет. В любом случае, не следует думать, что кто-то это сделает за Вас.

Вопрос: я читал блог разработчика ядра Red Hat, который сказал, что у них очень много жалоб на то, что это работает в Ubuntu, но не работает в Fedora. Он сравнил ядра этих дистрибутивов, чтобы посмотреть на различия, и обнаружил в ядре Ubuntu много мелких дополнений, которые не были включены в главную ветку разработки ядра.

Ответ: ядро Ubuntu публикуется на сайте kernel.org, так что для разработчиков ядра очень легко переносить из него все дополнения в главную ветку. Как правило, эти исправления переходят из версии в версию, но не всегда добираются до новых версий. Бывают, конечно, и случаи, что разработчик торопится и просто забывает переслать свои исправления в главную ветку.

Вопрос: Можете ли Вы что-нибудь сказать относительно планов портирования Ubuntu на платформу Sparc?

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

Вопрос: В настоящее время многие крупные компании, в первую очередь Microsoft, стараются завоевывать умы молодежи своими проектами по образованию, стажировке, трудоустройству. Если у Canonical что-нибудь подобное или будет ли?

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

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

Ответ: В текущие релизы включаются программы, которые люди используют в первую очередь – почта, Интернет, связка Linux с Apache и базами данных. В частности, программа установки Ubuntu предусматривает инсталляцию готового Интернет-сервера. Тяжелые сервера приложений будут включаться в дистрибутив только в том случае, если это будет востребовано сообществом. Сообщество пока не нуждается в серверах приложений (гомерический смех в зале).

Вопрос: Не являясь разработчиком, я выбрал Ubuntu в качестве десктопа. Может быть, мой выбор неправилен, и надо было выбрать Xandros или Linspire? (смех в зале)

Ответ: Попробуйте их все – и решите, какой лучше подходит (гомерический смех в зале, переходящий в овацию).

Следует учитывать, что такие дистрибутивы, как Xandros, Linspire или, например, MEPIS включают в себя много коммерческого софта, не распространяемого свободно. Ubuntu же включает только свободный софт и при этом работает из коробки на новом «железе». Кроме того, у Ubuntu очень большое сообщество разработчиков, благодаря чему ошибки исправляются быстро.

Вопрос: В последней версии 6.06 есть прекрасная поддержка свежего «железа». Однако постоянно выходят новые устройства, видеокарты и так далее. В то же время для Ubuntu заявлена поддержка на пять года для десктопа и пять лет для сервера. Будет ли при этом обновляться ядро для включения поддержки новых устройств?

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

Вопрос: Есть ли у Вас планы по убеждению вендоров аппаратуры открывать код дайверов своих устройств. И что Вы предпочитаете – помогать вендорам писать драйвера под Linux или создавать собственные?

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

Вопрос: Как Вы оцениваете взаимоотношения между разработчиками GPL-программ и разработчиками закрытого софта? И есть ли какие-нибудь соображения по поводу BSD-лицензии, которая накладывает гораздо меньше ограничений в этом отношении?

Ответ: Если это Ваш проект, Вы можете использовать модель двойного лицензирования, выпустив две версии – одну под GPL, другую под коммерческой лицензией.

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

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

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

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

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

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

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

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

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

Интервью

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

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

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

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

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

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

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

Снова aptitude: режим командной строки

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

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

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

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

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

$ aptitude search keyword

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

$ aptitude search term

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

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

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

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

$ aptitude show mlterm

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

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

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

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

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

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

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

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

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

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

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

$ sudo aptitude install pkg_name

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

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

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

$ sudo aptitude reinstall pkg_name

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

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

$ sudo aptitude remove pkg_name

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

$ sudo aptitude purge pkg_name

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

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

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

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

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

$ sudo aptitude markauto ’~slibs’

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

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

$ sudo aptitude unmarkauto pkg_name

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

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

$ man 8 aptitude

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

Избежать принудительного выполнения «рекомендаций» можно с помощью опции -R, данной в командной директиве установки конкретного пакета. Если же игнорирование «рекомендаций» требуется всегда – это можно будет запечатлеть в конфигурационном файле. Как именно – будет сказано чуть ниже. Пока же допустим, что мы уже изменили умолчальное поведение aptitude – теперь операторы инсталляции учитывают только «жесткие» (depends) зависимости.

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

Должен предупредить: применение опции -R к установленной системе Ubuntu/Kubuntu требует осторожности. Базовая ее инсталляция осуществляется по принципу «плюс recommends». И применение к ней aptitude -R делает как бы «ненужными» многие пакеты. Одни из них – действительно (на мой взгляд) лишние. Однако в «черный список» могут попасть и нужные библиотеки. Так что перед тем, как нажать <Enter> в ответ на предложение

Хотите продолжить? [Y/n/?]

внимательно прочтите весь предшествующий ему вывод.

Тем не менее, вполне возможно, что по разрешении указанных противоречий, опцию -R все же захочется сделать умолчальной. Для этого нужно внести изменения в конфигурационные файлы aptitude. Вообще-то aptitude обращается к тем же конфигам, что и apt (/etc/apt/sources.list, /etc/apt/apt.conf),однако имеет и собственный – ~/.aptitude/config. По умолчанию он пуст, но может быть отредактирован по потребностям. В частности, для придания опции -R статуса по умолчанию, в этот файл следует внести такую строку:

aptitude::Recommends-Important «false»;

К слову сказать, можно, напротив, сделать так, чтобы при установке пакета автоматически инсталлировались также и «предлагаемые» (suggest) зависимости. Это достигается строкой

aptitude::Suggests-Important «true»;

Вообще-то опций конфигурирования для aptitude предусмотрено великое множество – и многие из них применимы не только к командному, но и к интерактивному режиму, позволяя настроить внешний вид интерфейса и многое другое. Ознакомиться с полным набором опций конфигурирования aptitude и их умолчальными значениями можно в официальной документации – она влючена в состав дистрибутива и находится в каталоге /usr/share/doc/aptitude/html/{lang}/. Здесь под {lang} подразумевается язык документа – кроме английской (en) версии, в репозитории Ubuntu существуют переводы его на французский, финский и чешский языки; кстати, в репозитории Debian русской версии этого документа также не обнаруживается. А текущие настройки можно посмотреть в файле /usr/share/aptitude/aptitude-defaults.

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

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

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

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

Zenwalk Linux: не его ли учить?

LinuxFormat #112 (декабрь 2008, DVD-версия)

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

Самой модной темой для обсуждений в российском сообществе в последнее время стало повсеместное внедрение Linux в школах, вузах, на производстве… да разве всё перечислишь? Судя по тому, что одно из российских зеркал сайта www.kernel.org расположено на сервере perespim.ru, не за горами и внедрение этой ОС в сфере, так сказать, интимной. Желающих убедиться прошу сюда: http://kernel.perespim.ru/pub/linux/; кстати, вопреки присказке, что «быстро хорошо не бывает», зеркало вполне шустрое.

Так что ответ на вопрос, кого учить Linux, более или менее ясен: всех. Сложнее с ответом на другой вопрос: а кто будет учить? Ибо повсеместное внедрение Linux требует знания предмета, как минимум, от тех, кто это внедрение будет осуществлять. А здесь наблюдается напряжёнка: наша страна за годы существования этой ОС не вырастила достаточного количества специалистов – их еще самих предстоит обучить.

Это выводит нас на третий вопрос: а какому именно Linux следует учить будущих гуру – внедренцев этой системы в масштабе страны (а то, глядишь, и в мировом)? А может, их вообще следует учить FreeBSD или, скажем, DragonFly BSD?

Применим фильтры

На www.distrowatch.com на сегодняшний день зарегистрировано около 350 активно развиваемых дистрибутивов (включая полторы дюжины BSD-систем), плюс еще пара сотен проектов, которые тоже нельзя не учитывать: реанимация давно, казалось бы, умерших начинаний – отнюдь не редкость в мире Open Source. Но все ли они одинаково полезны для информационного здоровья будущих Linux-гуру?

Сконцетрируемся всё-таки только на активно развивающихся проектах, в рамках того же Distrowatch’а разделяемых на два десятка категорий . Среди них для начала отфильтровываем узкоспециализированные решения: кластерные, восстановительные, security-системы; все они предназначены для тех, кто «уже умеет» (и, главное, знает, для чего ему они нужны).

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

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

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

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

Но и после такого многоступенчатого отбора список кандидатов остаётся более чем обширным. Правда, и мнений относительно того, как сделать окончательный выбор, оказывается не намного меньше. Тем не менее, наиболее распространенных точек зрения – две. Согласно первой, будущие гуру должны учиться на наиболее дружественных к пользователю системах, таких, как Fedora и прямые клоны Red Hat, вроде CentOS или Scientific Linux (о самом RHEL тут речи нет из-за дороговоизны технической поддержки, да и ненужности её в данной ситуации), SUSE, Ubuntu, Mandriva, ALT Linux – тем более, что некоторые из них уже пустили корни в российских школах. Список неполон, но его уже достаточно, чтобы было над чем задуматься.

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

Во-вторых, большинство «дружественных пользователю» систем буквально напичканы инструментами для настройки всего и вся, призванными облегчить жизнь администратора. И до определенного предела они эту роль выполняют. Но при этом освобождают от знания механизмов, скрытых под красивым GUI, а сами являются настолько дистрибутив-специфичными, что блестящее знание Yast из SUSE мало чем поможет при работе с клонами Red Hat. А ведь мы помним, что речь идёт об обучении будущих «внедренцев» – и какой именно дистрибутив они будут внедрять, заранее неизвестно.

Вторая точка зрения, явным или неявным образом, гласит: будущих гуру надо учить по «методу большого болота» – системам типа Slackware, Gentoo, Arch. Причины очевидны:

  • знание tarball-based систем, как правило, наиболее универсально: крылатая фраза «Изучая Slackware, ты изучаешь Linux» имеет под собой все основания;

  • в компенсацию своей относительной сложности (точнее, непривычности), такие дистрибутивы, как правило, прекрасно документированы (Gentoo вообще приближается к эталону в этом отношении);

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

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

А вот к этому-то дистрибутивы данного типа не очень пригодны. Каждый, кто имел дело со Slackware, Gentoo и подобными, подтвердит, что в них всё легко и просто. Но лишь после того, как на настройку и индивидуализацию системы затрачены должные усилия, причём не всегда совместимые с немедленной практической работой.

И потому выскажу третью точку зрения: учить надо систему, обеспечивающую поэтапное вступление в мир Linux, в которой сочетаются легкость развертывания «пользовательских» дистрибутивов и возможность углублённого изучения системы. И как минимум один дистрибутив, отвечающий этим условиям, есть: Zenwalk Linux (www.zenwalk.org). Доказательство чего автор надеется представить ниже.

Почему Zenwalk?

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

  • разметке диска;

  • созданию файловых систем;

  • обеспечению загрузки системы;

  • развертывании её с дистрибутивного носителя;

  • постинсталляционных настроек.

Причём пункты 1, 2 и 4 по сути своей были одинаковы во всех дистрибутивах: независимо от внешнего оформления, за ними скрываются те же утилиты и файлы. Некоторая индивидуальность проявлялась в развертывании системы, правда, зачастую все сводилось к альтернативе: попакетный выбор компонентов, с учетом или без учёта зависимостей или установке неких предопределённых наборов – по назначению (сервер, рабочая станция) или по окружению (KDE, GNOME и т.п.). Были, конечно, и более или менее сбалансированные сочетания обоих вариантов, но двоичность подхода от этого не менялась…

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

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

В дальнейшем эта концепция нашла свое воплощение в таких дистрибутивах, как MEPIS, Corel Linux (ныне Xandros) и Lindows (позднее Linspire, ныне слившийся с Xandros). Очень последовательно она проводится в Ubuntu и его бессчётных производных. Характерно, что в основе всех их лежит Debian – его система управления пакетами оказалась наиболее благоприятной для реализации «безальтернативной» установки.

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

Таким образом, на первый план выходит качество реализации «безальтенративного» дистрибутива и чувство меры у его разработчиков. В Vector Linux, помнится, меня удивило изобилие функционально дублирующих друг друга приложений, что выглядит непозволительной роскошью для одного CD. Программы KDE в Vector часто заменялись их Gtk-аналогами, и не всегда более функциональными.

Ubuntu куда более последователен: дистрибутив-эпоним содержит только программы, основанные на Gtk и библиотеках GNOME, Kubuntu – на Qt и kdelibs, Xubuntu – немногочисленные собственные плюс затыкающие прорехи приложения Gtk/GNOME. Однако, и здесь есть излишества. К чему включать локали и шрифты для языков, о существовании которых, за пределами круга их носителей, мало кто слышал? Причем без простой возможности от них избавиться…

На фоне своих собратьев Zenwalk Linux выглядит квинтэссенцией «безальтернативного» подхода, причём направленного на максимальное упрощение и облегчение системы – как в установке, так и в изучении, и в использовании. Начинается это с выбора рабочей среды – Xfce, самой быстрой и легкой среди интегрированных. Да, недостаточно нагруженной функционально в сравнении с GNOME/KDE (некоторые сказали бы, функционально не перегруженной, подобно им), но зато пригодного к практической работе сразу после установки. Настройки, собранные в единой панели, немногочисленны и предельно прозрачны.

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

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

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

И, наконец, третье: включённые в дистрибутив приложения совсем не обязательно самые функциональные в своём классе, но всегда – самые легкие, самые простые в освоении и использовании.

В Zenwalk абсолютно нет тяжелых, узкоспециализированных приложений, а также программ, которые принято относить к категории профессиональных (за исключением GIMP – но он сколько-нибудь функциональных легких аналогов не имеет). Предполагается, что задача авторов дистрибутива – обеспечить пользователю «место для жизни», а уж подбором того, что ему требуется для профессиональной деятельности, он займётся сам.

Далее, Zenwalk, будучи потомком Slackware, наследует простоту и прозрачность её внутреннего устройства: при наличии минимального опыта и навыка, в настройку любых параметров можно вмешаться вручную. Однако эти самые минимальные опыт и навык нужно еще приобрести, не так ли? И тут на помощь начинающему пользователю приходит графическое средство сквозной настройки системы – Zenwalk Panel.

Здесь читатель вправе обвинить меня в противоречии собственному утверждению, что графические инструменты затеняют суть процесса настройки. Возразить на это легко: Zenwalk Panel как раз и являет собой исключение из этого правила. Потому что, свято следуя принципу «одна иконка – один параметр» похоже, она позволяет легко установить корреляцию между выполненными через графический интерфейс действиями и изменениями конфигурационных файлов. То есть представляет собой своего рода лабораторную модель для отработки навыков настройки и приобретения необходимого опыта, позволяющего в дальнейшем вмешиваться в этот процесс руками.

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

Так вот, средства управления пакетами дистрибутива Zenwalk избавляет вас от этой докуки. Собственно, средство это одно, но существует в двух ипостасях: утилиты командной строки netpkg и её графической оболочки xnetpkg. Они взаимодополняют друг друга: одни действия удобнее выполнять из командной строки, другие – из графического интерфейса.

Кстати, всё, что было сказано об аскетичности подбора ПО, касалось только штатного дистрибутива, распространяемого в виде ISO-образа. В сетевых репозиториях проекта доступно если и не всё изобилие свободных программ, то изрядная его часть, включая KDE, GNOME и большинство их приложений, несколько оконных менеджеров для тех, кто не любит интегрированных сред, OpenOffice.org, Seamonkey, и множество других.

Конечно, «запас» пакетов в репозиториях Zenwalk далеко не столь обширен, как у Gentoo, Debian или даже Arch Linux. Однако он восполним самыми различными способами.

Во-первых, кроме официального репозитория проекта, поддерживается так называемый пользовательский (ZUR – zur.zenwalk.org), пополнение которого обеспечивается сообществом.

Во-вторых, Zenwalk сохраняет двоичную совместимость со Slackware, и потому остро недостающие пакеты можно поискать в его официальных репозиториях или на сайтах вроде www.linuxpackages.net.

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

Как видно, пользователь Zenwalk имеет достаточно возможностей для индивидуализации своей системы: он может полностью сменить рабочее окружение как в сторону облегчения (перейдя на какой-либо из легких оконных менеджеров), так и в сторону многофункциональности (мигрировав на KDE или GNOME), доустановить дополнительные пакеты, не отягощая себя размышлениями об их зависимостях, выполнять регулярное обновление как отдельных пакетов, так и системы в целом.

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

Zenwalk: знакомимся ближе

Если мне удалось убедить вас в том, что Zenwalk – штука стоящая, есть смысл познакомиться с ним дистрибутивом поближе.

Как уже было сказано, Zenwalk является одним из клонов Slackware, старейшего из ныне живущих дистрибутивов Linux. Возникнув в середине 2004 года под названием Minislack, своё нынешнее имя он получил на втором году жизни, в августе 2005.

Создатель дистрибутива, Жан-Филипп Гийомен [Jean-Philippe Guillemin], ставил своей целью создать компактную и быструю систему, сочетающую гибкость Slackware с простотой установки и настройки, легкостью актуализации и наращивания. Он оказался не одинок в своих намерениях, и постепенно вокруг Zenwalk сложилась и команда основных разработчиков, и сообщество пользователей. Совместными усилиями они обеспечивают как регулярное обновление базовой системы, при неуклонном следовании исходным принципам в отношении её компактности, так и наращивание массива дополнительных приложений.

Zenwalk не имеет фиксированного релиз-цикла, однако новые версии выходят не по мере готовности, а скорее по необходимости, при обновлении ключевых комопнентов системы, таких, как ядро, Xfce и так далее. Периодичность выхода релизов варьируется от одного-двух до трех-четырёх месяцев. В каждый момент времени сосуществует две ветки системы – current, то есть текущая стабильная, и snapshot – находящийся в процессе разработки прототип будущего релиза.

Ветвь current распространяется в следующих вариантах:

  • стандартная редакция – ISO-образ установочного диска, представляющего цельную систему, начиная с ядра и базовых утилит и заканчивая X.org, Xfce и такими приложениями, как Iceweasel, Geany, Abiword, Gnumeric; объем его, в зависимости от версии, колеблется от 450 до 500+ МБ и не обнаруживает тенденции к «разбуханию» за счет увеличения числа приложений на всём протяжении жизни дистрибутива;

  • core-редакция – аналогичный образ, содержащий только ядро, консольные утилиты и приложения общего назначения, объемом около 200 МБ; это именно та основа, на которой пользователь может построить полностью индивидуализированную систему путем доустановки необходимых ему пакетов, без удаления чего бы то ни было лишнего (его здесь просто нет);

  • LiveCD-редакция содержит полнофункциональную систему (объем образа несколько чуть более 500 МБ), идентичную Standard Edition, но запускаемую и работающую с CD-диска; она предназначена в основном для демонстрационно-ознакомительных целей, однако содержит средства установки на жесткий диск, после чего превращается в стандартную версию;

  • серверная редакция – это традиционный набор LAMP (Linux, Apache, MySQL, PHP), то есть базовая система (аналогичная core) и средства поддержки интернет-сервера, суммарным объемом менее 250 Мбайт; в отличие от прочих, она имеет собственный (более длительный) релиз-цикл.

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

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

Например, в момент, когда пишутся эти строки, происходит активная разработка Xfce версии 4.5 и связанные с ней пакеты обновляются чуть ли не ежедневно, причём не всегда согласованно. Это иногда приводит к комическим эффектам, например, обновлению базовой части Xfce без соответствующей корреляции с библиотеками, на которых она основывается. Хотя такие коллизии легко разрешаются посредством «мануальной терапии», совсем начинающего пользователя они могут несколько обескуражить.

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

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

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

И на прощание

Ознакомившись с вышеизложенным, читатель вправе задаться вопросом: если дистрибутив Zenwalk такой умный, то почему он такой бедный (пользователями)?

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

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

Управление rpm-пакетами: нынче не то, что давеча

LinuxFormat, #125 (декабрь 2009)

Многие, чьё знакомство с Red Hat и его клонами пришлось на 90-е годы, надолго сохранили предубеждение и против формата их пакетов, и против утилиты управления оными. Конечно, дать команду rpm -ihv – проще, нежели собрать нужный пакет из исходников. Однако, в сравнении с портами FreeBSD, с одной стороны, и с Debian’овским APT’ом – с другой, она приобретала вид вполне бледный.

Но всё течёт, всё меняется – и ныне rpm-based дистрибутивы располагают развитыми системами пакетного менеджмента, работающими как в текстовом, так и в графическом режиме. В настоящей заметке мы остановимся на двух из них – yum и PackageKit на примере использования в дистрибутиве Fedora.

Незнаменитый yum

Yum – система управления rpm-пакетами и их репозиториями, предлагающая автоматическую установку, обновление и удаление пакетов и пакетных групп с автоматическим контролем зависимостей. По механизму действия и функциональности она сходна с системой APT, разработанной для Debian. Однако если последний получил в последние годы широкую известность – не в последнюю очередь благодаря популярности Ubuntu, а также тому, что усилиями сначала Connectiva, а затем Altlinux широко распространился за пределами родного дистрибутива, – то yum остаётся малоизвестным.
Однако yum, с одной стороны, по своим возможностям управления rpm-пакетами ничуть не уступает утилитам семейства apt для deb-пакетов, а с другой, используется достаточно широко: эта система принята в качестве основной в Fedora, RHEL и их прямых и косвенных потомках.

Аббревиатура yum интерпретируется как Yellow dog Updater, Modified, то есть Обновитель Yellow dog Модифицированный. Однако его связь с одноимённым дистрибутивом – портом Red Hat на архитектуру Power, не совсем прямая. Его пакетный менеджер, именовавшийся YUP, послужил основой для Сета Видала (Seth Vidal), при написании yum для дистрибутива Red Hat. Символично и дословное его значение (yum – по английски конфетка) – его можно трактовать так, что эта система в состоянии сделать конфетку даже из такого… не самого приятного продукта, как пакеты в формате RPM.
Yum быстро получил признание среди ряда клонов Red Hat, в частности, был принят в качестве штатного менеджера пакетов в ASPLinux. Однако в самом Red Hat он долго конкурировал с apt-rpm, и развитие yum’а одно время только силами команды ASPLinux и осуществлялось. Однако в конце концов он утвердился в RHEL и его клонах (CentOS, Scientific Linux), в Fedora и в Yellow Dog.

Система yum включает в себя собственно одноимённую утилиту, набор дополнительных утилит (yum-utils) и многочисленные плагины, в виде самостоятельных пакетов расширяющие функциональность главной программы.

Запускается yum одноимённой командой, требующей указания субкоманды (возможно, с опциями последней), и, в ряде случаев, аргументов в виде имени пакета или группы пакетов, что в общей форме выглядит так:

$ yum subcommand [arguments] —[options]

Команда yum без указания субкоманды выведёт краткую справку касаемо последних и их опций. Аналогичный результат будет получен посредством субкоманды

$ yum help

А указание имени субкоманды в качестве аргумента, например, так

$ yum help install

выведет краткие сведения о её назначении.

Субкоманды yum’а определяют одно из действий, которое команда должна выполнить – установку или удаление пакета, вывод информации о нём, поиск пакетов и так далее. Обычно назначение субкоманды легко угадывается из её названия и (или) краткой характеристики в выводе help’а.

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

  • search [string] – поиск пакета по имени или его фрагменту;

  • list – вывод списка пакетов, всех (all или без указания фильтра), установленных (installed) или доступных (available);

  • info pkgname – вывод полной информации о пакете.

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

  • install pkgname1 … pkgname# – установка из репозиториев единичного пакета или нескольких пакетов, имена которых даны (в краткой форме) в качестве аргумента, вместе со всеми их зависимостями;

  • localinstall path2/fullname.rpm – установка пакета из локально хранящегося файла; зависимости его извлекаются из репозиториев, если таковые доступны;

  • update [pkgname] – обновление пакета, указанного в качестве аргумента; в отсутствие аргумента выполняется тотальное обновление системы, аналогично сумме apt-get update и apt-get upgrade;

  • erase pkgname – удаление пакета вместе со всем, что от него зависит; пакеты, от которых зависит удаляемый, остаются в неприкосновенности, даже если они никем не используются.

Все субкоманды второй группы для своего исполнения требуют прав администратора.
Отдельно надо сказать о субкоманде shell – она запускает собственную интерактивную командную оболочку yum’а, в сеансе которой можно оперировать уже просто его субкомандами, аргументами и опциями, пуская главную команду yum.

Рис. 1. Yum с его интерактивной оболочкой

Исполнение любой субкоманды начинается с синхронизации локальной базы пакетов с базами репозиториев. Затем происходит проверка зависимостей – и по её результатам выводится итог: сколько пакетов, включая зависимости, должно быть установлено, обновлено или удалено, их имена, подлежащий скачиванию объем информации. И запрашивается подтверждением на выполнение операции.
Опции yum довольно многочисленны, привязаны как к главной команде, так и к отдельным субкомандам. Исчерпывающую справку о них можно получить через

$ man (8) yum

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

$ man yum-utils

Важнейшей из этих команд является package-cleanup, предназначенная для получения сведений о непорядках в локальной базе данных пакетов и их устранения. Она имеет несколько опций. Например,

$ package-cleanup —problems

выведет список нарушенных зависимостей, а с помощью команды

$ package-cleanup —leaves

можно вывести список пакетов, от которых не зависят никакие другие компоненты.

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

  • fastestmirror – проверка скорости доступа к зеркалам репозитория и выбор самого быстрого из них, выполняется при каждом запуске команды yum;

  • presto – при обновлении пакетов скачивает из репозиториев только дельты изменений (deltarpms), минимизируя таким образом трафик;

  • refresh-packagekit – обеспечивает обновление системы PackageKit, о которой будет говориться в следующей заметке.

Эффективное использование yum требует некоторых мероприятий по настройке, включающих:

  • настройку собственно yum;

  • подключение и настройку плагинов;

  • подключение дополнительных репозиториев.

За настройки собственно yum отвечает файл /etc/yum.conf – он содержит общие параметры для этой утилиты в формате:

название=значение

Значение может быть булевым (0 – запрещено, 1 – разрешено), численным – от 1 и до… разумного предела (значение 0 равносильно отключению) или символьным – например, путь к каталогу или список пакетов; в последнем случае значения разделяются пробелами. По умолчанию yum.conf выглядит так:

  • cachedir=/var/cache/yum – каталог для кэширования метаданных репозиториев и пакетов, скачиваемых в ходе установки ;

  • keepcache=0 – определяет, сохранять ли скачанные пакеты в локальном кэше или удалять их после успешной установки;

  • debuglevel=2 – уровень отладочных сообщений;

  • logfile=/var/log/yum.log – каталог для файлов протоколирования действий yum;

  • exactarch=1 – значение по умолчанию предписывает устанавливать пакеты, точно соответствующие архитектуре;

  • obsoletes=1 – определяет логику замены «устаревших» пакетов при тотальном обновлении;

  • gpgcheck=1 – включение этой опции обязывает к проверке подписей при установке;

  • plugins=1 – использовать или нет плагины к yum’у;

  • installonly_limit=3 – максимальное количество пакетов, запрещённых к обновлению (можно только устанавливать параллельно более новую версию).

Кроме перечисленных, существует ещё немало параметров настройки yum. Так, очевидно, что опция installonly_limit имеет смысл только при наличии списка запрещённых к обновлению пакетов. Он задаётся параметром

installonlypkgs=pkgname1 pkgname2 … pkgname#

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

exclude=pkgname1 pkgname2 … pkgname#

Полезной может оказаться параметр skip_broken – он заставляет пропускать установку пакетов с нарушенными зависимостями.

Параметр recent нужен для субкоманды list с одноимённой опцией: он устанавливает срок, в течении которого добавленные в репозиторий пакеты считать новыми.

Что очень раздражает в yum – это синхронизация метаданных о репозиториях, происходящая каждый раз при его запуске с любой субкомандой – даже от лица пользователя, когда реально кэш метаданных обновлён быть не может. Такая ситуация изменяется параметром metadata_expire, которому можно дать то значение, которое покажется разумным. Или вписать строку

metadata_expire=never

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

Обратимся к плагинам. Они устанавливаются точно так же, как и любые другие пакеты. Соответствующие каждому из установленных плагинов конфигурационные файлы располагаются в каталоге /etc/yum/pluginconf.d и имеют имена, по которым легко догадаться, к какому из плагинов относится любой конфиг.

Большинство плагинных конфигов предельно просто и содержит единственную строку, разрешающую его подключение:

enabled=1

В конфиге плагина presto можно запретить локальное кэширование дельт, раскомментировав параметр

keepdeltas = false

А можно определить, что же считать дельтой. Например, параметр

minimum_percentage = 95

указывает, что если изменённая часть пакета составляет 95% или менее от цельного, то будет скачиваться она, если же больше – загрузится пакет целиком.

Чтобы настраивать параметры доступа к репозиториям, их необходимо сначала подключить. Подключение «левых» репозиториев не сложно: вся метаинформация о любом репозитории, пригодном для эксплуатации yum’ом, собрана в виде обычного rpm-пакета, который может быть обычным же образом установлен. Вся загвоздка в том, что пакет этот хранится внутри собственного, ещё не подключённого, репозитория, и потому yum’ом установлен быть не может.

Так что нам придётся добраться до нужного пакета, описывающего репозиторий, в Сети, скачать его, установить с помощью команды rpm, а затем уже обеспечить доступность репозитория.

Рассмотрим эту процедуру на примере подключения репозитория для пакетов флэш-плейера. Для этого заходим на официальный сайт Adobe, в пункте Download отыскиваем строку Get flash player, и из выпадающего списка Select version to download… выбираем YUM for Linux, какой (в виде файла adobe-release-i386-1.0-1.noarch.rpm) и скачиваем. Затем даём команду

# rpm -Uhv adobe-release-i386-1.0-1.noarch.rpm

По её успешном исполнении в каталоге с конфигами репозиториев можно будет увидеть новый файл adobe-linux-i386.repo. Одновременно он станет доступным для обновляющих манипуляций командой

# yum update

Подключить новый репозиторий можно и совсем вручную. Проделаем эту операцию для репозитория (почти) ежедневных сборок браузера Chromium от Тома Колловея: создадим в каталоге /etc/yum.repos.d файл chromium.repo и впишем в него такие строки:

[chromium] name=Google Chrome baseurl=http://spot.fedorapeople.org/chromium/F$releasever/ enabled=1 gpgcheck=0

Надеюсь, мне удалось показать, что yum делает употребление rpm-пакетов абсолютно безвредным. В случае же напряжённых отношений с командной строкой для управления rpm-пакетами можно обратиться к графической утилите PackageKit, речь о которой пойдёт в следующем разделе.

PackageKit – кит пакетного менеджмента

Если yum всегда оставался в тени Debian’овского APT’а, то о графической надстройке PackageKit говорят ещё меньше. Хотя она не является чем-то специфическим для rpm-based дистрибутивов: её можно прикрутить к пакетам любого формата в любых дистрибутивах, вплоть до Archlinux и Gentoo.

Система PackageKit распадается на серию бэк-эндов для работы с конкретными менеджерами пакетов и интерфейсные надстройки.

Бэк-энды PackageKit предполагают работу с такими системами, как yum, apt, smart и так далее, вплоть до pacman. Интерфейсом к ним служат

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

  2. либо графические фронт-энды, каковых минимум два – gnome-packagekit и kpackagekit, ориентированные на работу в средах GNOME/Xfce/LXDE и KDE, соответственно.

При инсталляции в Fedora по умолчанию устанавливается бэк-энд для yum и фронт-энд gnome-packagekit (при выборе в качестве рабочей среды KDE он заменяется на kpackagekit). Но в репозиториях доступны пакеты поддержки apt и smart, а также консольный клиент pkcon.

Пакетные менеджеры, поддерживаемые системой PackageKit, имеют обычно собственный развитый инструментарий для управления пакетами из командной строки (не исключение и Fedora, как мы видели в заметке про yum). Поэтому консольная утилита pkcon представляет интерес только своей теоретической универсальностью – она одинакова в любых дистрибутивах, поддерживающих PackageKit, так что задерживаться на ней не будем.

Графическая ипостась PackageKit в виде субпакета gpk-application запускается из главного стартового меню, в зависимости от используемой среды, через пункты Приложения -> Установка и удаление программ (GNOME) или Администрирование -> Установка и удаление программ (Xfce). Причём сделать это можно от лица обычного пользователя – пароль администратора будет запрашиваться по ходу дела, при необходимости выполнения действий, требующих соответствующих полномочий. После запуска перед нами появляется окно следующего вида:

Рис. 2. PackageKit – общий вид

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

  • статусу – установлен или доступен;

  • назначению – для разработчиков или конечных пользователей;

  • режиму – графическому или текстовому;

  • «степени свободы» – free или non-free.

По умолчанию никакая фильтрация не проводится.

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

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

Более подробную информацию о пакете можно получить через меню Selection. Так, пункт Get file lists выведет список файлов и путей к ним в том виде, в котором они будут установлены в системе. Пункт Depends on даст список его зависимостей. А пункт Required by – список пакетов, которые зависят от выбранного.

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

Рис. 3. Вывод списка зависимых пакетов

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

Если всё идёт как надо, после описанных выше манипуляций мы будем иметь в системе установленный работоспособный пакет. Что и предлагается проверить в панели сообщения об успехе инсталляции – на ней имеется кнопка Запустить, которая вызывает старт свежеустановленной программы.

Однако нельзя исключить ситуации, что в ходе проверки зависимостей будут выявлены ошибки – как правило, они связаны с конфликтом версий пакетов, от которых зависит устанавливаемый. И единственное, что тут можно сделать – открыть вывод More details, тупо просмотреть его и закрыть панель ошибок. Выбранный пакет при этом, разумеется, установлен не будет.

Удаление пакетов происходит аналогично – только в обратном порядке:

  • сначала снимается отметка с установленного пакета;

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

  • список очень внимательно изучается, после чего следует согласие на удаление или отказ от него.

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

PackageKit в 12-й версии Fedora получит (за счёт отдельных плагинов) такие дополнительные возможности, как автоматическая установка пакетов по щелчку на имени файла в браузере или из командной строки – в ответ на сообщение command not found.

Все действия по установке и удалению пакетов (а также тотальному обновлению системы, о чём будет говориться позднее) через PackageKit фиксируются в специальном лог-файле – /var/log/yum.log; как явствует из названия, он не специфичен для этой системы, а отражает действия через менеджер пакетов yum. Однако gnome-packagekit предоставляет удобную форму визуализации его содержимого, вызываемую через пункты меню System -> Software log, где показываются: дата действия и его характер (установка, обновление или удаление), имя совершившего его пользователя и приложения (субпакета в составе gnome-packagekit):

Рис. 4. Журнал установки, обновления и удаления пакетов

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

Первое из них – проверить доступные репозитории, те самые, которые подключались на стадии установки, что делается через меню System -> Software sources. Скорее всего, все нужные источники пакетов из числа официальных для Fedora вообще и Russian Fedora в частности уже включены, но лишний раз убедиться в этом не мешает.

Затем имеет смысл обновить систему – через пункт меню System -> Refresh package lists, который сначала приведёт список доступных пакетов в актуальное (и соответствующее подключённым репозиториям) состояние, а затем предложит список пакетов, могущих быть обновлёнными, с которым остаётся только согласиться.

И теперь обновление будет выполнено, если не произойдёт ошибки —. хотя нельзя исключить и последнего варианта. В этом случае придётся обратиться к командной строке и yum’у.

Пунктами меню Software sources и Refresh package lists вызывают самостоятельные субпакеты, входящие в gnome-packagekit – gpk-repo и gpk-update-viewer, соответственно. Но они могут быть запущены автономно, через главное стартовое меню среды – Система -> Администрирование -> Источники программ/Обновление программ.

Из сказанного можно сделать вывод, что PackageKit в своей графической ипостаси – простое и удобное в обращении средство управления пакетами, функционально сходное с Synaptic’ом для deb-пакетов. В сравнении с последним он производит впечатление более медлительного. Однако это связано не с ним самим, а с rpm-форматом и базами данных для yum, требующими скачивания существенно большего объёма метаинформации. Второй недостаток PackageKit – трудность определения причин возникновения ошибок как при установке конкретного пакета, так и тотального обновления системы. Это я отнёс бы к некоторой недоработанности системы PackageKit в целом – ведь по сравнению с Synaptic’ом она ещё очень молода.

Однако и в нынешнем своём виде PackageKit пригоден для повседневного использования в сфере управления пакетами, если не выходить за пределы штатных ситуаций – при их возникновении yum нам в руки.

openSUSE LiveCD: нетривиальная установка

LinuxFormat, #162 (октябрь 2012)

Большинство современных дистрибутивов Linux распространяется в двух основных вариантах: в виде образов оптических дисков, служащих исключительно для установки системы, и в виде образов LiveCD/DVD, предназначенных как для знакомства с ней, так и и для последующей инсталляции. Не исключение тут и openSUSE, официальный набор образов которой включает:

  • полный установочный DVD;

  • небольшой образ для установки по Сети;

  • GNOME-Live и KDE-LiveCD, различающиеся используемыми рабочими средами.

О последних и пойдёт речь в настоящей статье.

Вступление

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

Это мнение имеет под собой основания: в большинстве случаев при установке с LiveCD возможности пользователя вмешаться в этот процесс минимальны или напрочь отсутствуют. Результатом же такой установки является точная копия образа «живого» диска со всеми его умолчальными настройками и заранее предопределённым набором приложений. А поскольку в отношении последних предпочтения составителей LiveCD наверняка не на 100% совпадают с предпочтениями пользователя «со стажем», в дальнейшем ему придётся затратить немало времени на индивидуализацию своей системы.

Однако инсталляция openSUSE с LiveCD оказывается исключением из общего правила. И предоставляет не меньше возможностей по индивидуализации системы, нежели установка с полного DVD или «сетевого» диска. А в отношении настроек – даже больше. Как это оказывается возможным – и будет предметом настоящей статьи.

Как уже было сказано, официально в рамках проекта распространяется два варианта LiveCD – с KDE и GNOME в качестве рабочих сред, каждый в сборках для 32-битной и 64-битной архитектур. В силу личных предпочтений автора дальнейшее изложение проводится на примере KDE-LiveCD – но пользователи GNOME вполне могут применить те же приёмы при установке своего любимого десктопа.

Официальные LiveCD в отношении версий ядра, рабочих сред и приложений точно соответствуют установочному DVD на момент выхода текущего релиза. Однако существуют и периодические «верстовые» (Milestomes) сборки, предназначенные для тестирования релиза будущего. По своему наполнению они идентичны официальным, однако версии этого наполнения повышаются «от столба к столбу». В промежутках же между «верстовыми столбами» с периодичностью примерно раз в неделю собираются «саженные столбики» – снапшоты текущего состояния подготавливаемого релиза. Разумеется, за стабильность «вестовых» и особенно «саженных» сборок никто не ручается, и использование их для «рабочих» инсталляций не рекомендуется.

Кроме официальных LiveCD, существует большое количество неофициальных их вариантов. Например, для KDE это версии с «чистым» KDE 4.X (то есть в оригинальном оформлении проекта KDE), и с ностальгическим KDE 3.5.10. Сборки LiveCD с прочими рабочими средами – XFce, LXDE, Enlightenment – также имеют статус неофициальных.

Live-среда: запуск

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

Из меню загрузчика следует, что можно либо загрузить Live-среду, из которой, как мы скоро увидим, будет доступна опция установки, либо непосредственно приступить к инсталляции. В данный момент нас интересует как раз первый вариант. Почему он является предпочтительным – станет ясным из дальнейшего изложения.Никаких дополнительных опций, вроде настройки сети, Live-вариант загрузки пока не предусматривает – этим можно будет заняться уже непосредственно в «живом» режиме. Так что нажимаем Enter на первом пункте главного меню и через некоторое время видим рабочий стол KDE.

Первая наша цель – ознакомиться с возможностями Live-режима. Однако делать это лучше в комфортной обстановке, что для меня, например, подразумевает в первую очередь шрифты, подходящие для глаз, для кого-то – иные параметры внешнего вида. Чем мы для начала и займёмся. Впрочем, те, кого внешний вид среды по умолчанию устраивает, могут спокойно пропустить следующий раздел.И ещё важное предупреждение: знакомство с LiveCD – занятие довольно медленное и печальное. Ибо привод компактов нынче не самое быстрое устройство хоранения данных, а кэширование его содержимого в оперативную память (даже если её более чем вдоволь) в openSUSE не предусмотрено.

Подготовка Live-режима

Дабы привести рабочий стол Live-среды в соответствие если и не со своими эстетическими идеалами , то хотя бы с физическими возможностями восприятия, отправляемся в стартовое меню главной управляющей панели, где выбираем пункт Configure desktop (я предупреждал, что с Великим и Могучим в Live-среде будет напряжонка) и по открытии окна настройки параметров щёлкаем по иконке Applications Appearance. В развернувшейся панели слева выбираем пункт Fonts, а справа жмём на кнопку Adjust all fonts.

Теперь отмечаем «птицами» боксики Font и Size и выбираем подходящие гарнитуру и кегль, сверяясь с образцом в нижней части окошка. Выбрав подходящий вариант, в панели шрифтов, включаем режим anti-aliasing’а в соответствие со своим визуальным восприятием. Каковое, впрочем, будет получено только впоследствие, после перезапуска сеанса (ни ни в коем случае не системы – это убёт все сделанные настройки). Однако перед этим я подгоняю управляющую панель к размеру, воспринимаемому моими глазами. Для чего щёлкаю на ней правой кнопкой мыши, в контекстном меню выбираю пункт Panel Options, а затем – Panel Settings. После чего, ухватившись мышью за кнопку Height, тащу её вверх до получения удовлетворительного результата.

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

Настройка окружения администратора

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

Так что последний штрих в подготовке к дальнейшей работе – это настройка «административного окружения». Для чего следует запустить ту же самую программу конфигурирования десктопа, но уже от лица суперпользователя. Самый простой способ сделать это – с помощью комбинации клавиш Alt+F2 вызвать командную строку минитерминала, в которой и надлежит ввести

kdesu systemsettings

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

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

Предвижу резонное замечание: зачем возиться с настройками окружения пользователя и администратора, если все эти действия будут иметь силу только для текущего Live-сеанса? Столь же резонно возражу. Во-первых, не такие уж это сложные действия, чтобы пренебречь комфортом в ходе знакомства с LiveCD и установки. А во-вторых, и главных, не пропадёт ваш скорбный труд по настройке пользовательского и административного окружения. Почему? Пусть это пока остаётся Военной Тайной.

Преамбула к установке

На знакомстве с Live-средой я останавливаться не буду. Замечу только, что это самая обычная среда KDE, с набором типовых её приложений – достаточно обширным, так что начинающему пользователю есть где порезвиться. Однако занятие это наскучит ему достаточно скоро. Не в последнюю очередь и потому, что все они не блистают быстродействием в условиях «живого» режима. И тут пользователю захочется посмотреть на те же приложения во всей красе – в инсталлированном виде. Наступает психологический момент для установки системы.

Установка openSUSE – дело не шести секунд. Конечно, в Live-режиме это время можно скрасить рядом приятных и полезных занятий. Так, те, кто ещё не наигрался в игрушки, имеют все условия, чтобы резаться, скажем, в Reversi или раскладывать пасьянсы, каковых немного больше, чем вдоволь. Люди же серьёзные могут почитать материалы официального сайта проекта, в том числе и на русском языке. Благо, для этой цели в Live-режиме имеется целых два браузера.

Конечно, для этого хорошо бы иметь и соединение с Интернетом. Если провайдер обеспечивает DHCP-подключение, всё просто: сеть волшебным образом поднимется сама собой. Однако в данном варианте не фатально будет и любое иное подключение: в нашем распоряжении есть рабочий Network Manager, который, при всех его недостатках, позволит настроить и VPN-, и DSL-, и WiFi-соединение. Ибо нет таких настроек, которые не могли бы выполнить большевики-линуксоиды, и сеть, тем или иным способом, будет поднята. Так что никаких препятствий к повышению своего образовательного уровня не будет.

Так что возможность занять время установки делами разной степени полезности – это первый довод в пользу установки системы из Live-среды, а не методом «лобового напора».

Однако чтение материалов, как я уже сказал, – занятие для серьёзных людей. Люди же несерьёзные, вроде автора этих строк, предпочтут провести время установки за непринуждёнными беседами, например, в Джуйке. И на первый взгляд их ожидает облом: в Live-среде ни малейшего Jabber-клиента не найти и следов.

Однако это решается легко: если Jabber-клиента в системе нет, его следует установить. На вопрос как? ответить очень легко: либо с помощью консольной системы zypper, либо посредством модуля управления программами универсальной системы YaST2 в графическом режиме. Оба способа – предмет отдельной тему. Здесь лишь отмечу, что во втором случае и пригодились нам настройки «административного окружения», ибо YaST2 запускается от лица суперпользователя.

Так что возможность читать документацию и поговорить с приятными собеседниками online – это второй довод в пользу инсталляции openSUSE из Live-среды. Правда, те самые серьёзные люди поставят это в упрёк: мол, не стоит ради пустопорожнего трёпа городить огород с установкой дополнительных приложений. На что у меня есть два возражения:

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

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

Так что Kopete может оказаться далеко не единственным кандидатом на установку. Так, не помешает установить в Live-среде и пакеты русификации, такие, как kde4-l10n-ru, kde4-l10n-ru-data и kde4-l10n-ru-doc для русификации KDE, libreoffice-l10n-ru для русификации LibreOffice. Впрочем, полностью русифицировать систему можно и иным способом (см. врезку). Прочие дополнительные пакеты каждый выбирает в меру своих предпочтений.

Наконец, самое интересное: пакеты можно не только устанавливать в Live-среду, но и удалять из неё – и после инсталляции на диск их не будет! Здесь я «отдельно, с большим наслажденьем» удаляю немало того, что полагаю лишним на «живом» диске, в частности, всю мультимедиа – но и это дело личных предпочтений.

Таким образом, Live-среда даёт ничуть не меньше возможностей для индивидуализации системы, нежели выборочная установка с DVD или по сети. И даже больше: потому что никто не в силах запретить подключение, наряду со штатными, также и сторонних репозиториев, в том числе содержащих так называемые не вполне свободные программы (типа мультимедийных кодеков), которые при других раскладах установки приходится доустанавливать впоследствии.

Таким образом, третий довод в пользу установки из Live-режима – безграничные возможности по индивидуализации системы. Причём реализуются все эти возможности, что называется, малой кровью: пользователь может полностью избавиться от заботы о зависимостях как при установке пакетов, так и при их удалении.

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

При установке же с openSUSE LiveCD от всего лишнего можно избавиться радикально. Потому как предварительно можно должным образом настроить YaST или отредактировать конфигурационный файл zypper‘а, в зависимости от того, что используется для удаления и установки пакетов.

Четвёртый довод в пользу установки в Live-режиме по сравнению с прямой инсталляцией: возможность выполнять её в визуально приятном окружении, о чём говорилось в предыдущем разделе.

Есть и пятый довод, но и он пока останется Маленьким Секретом, который я раскрою под занавес.

Дабы при удалении пакетов вместе с ними удалялись и их ставшие ненужными зависимости (если они больше нигде не задействованы), при использовании zypper’а следует отредактировать файл /etc/zypp/zypp.conf, а именно: снять символ комментария со строки

# solver.cleandepsOnRemove = false

и заменить значение false на true.

При использовании же модуля управления пакетами YaST2 тот же эффект достигается включением в меню Параметры пункта Удалять ставшие ненужными зависимости.

Чтобы при установке пакетов они тянули за собой только обязательные зависимости, не затрагивая так называемых рекомендованных, в файле /etc/zypp/zypp.conf следует снять символ комментария со строки

# solver.onlyRequires = false

и заменить значение false на true.

Та же цель в модуле управления пакетами YaST2 достигается включением в меню Параметры пункта Игнорировать рекомендованные пакеты для уже установленных пакетов.

Однако торопиться с отключением установки рекомендованных пакетов не следует. Ибо в число оных входят и языково-зависимые пакеты, о которых говорилось ранее. Так что, вместо того чтобы устанавливать их попакетно, достаточно при отключённом игнорировании рекомендованных пакетов выполнить операцию тотального обновления системы командой zypper up или через YaST2. Результатом будет полная русификация системы.

Установка

И вот настал решительный момент щелкнуть мышью по иконке Install на предмет заняться установкой системы. Она начинается с панели приглашения к оной. После приглашения можно видеть отличительные особенности инсталляции в Live-режиме:

  • нет пункта выбора режимов – то есть режим обновления установленной системы не предусмотрен;

  • нет возможности отключить автоматическую настройку после инсталляции;

  • нельзя включить использование диска Add-on.

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

Стадия выбора рабочего стола при Live-установке пропускается. Что естественно – выбор этот делается в тот момент, когда диск с соответствующей средой (KDE или GNOME) ставится на закачку.

Так что следующим номером нашей программы будет разметка диска – возможности установщика openSUSE в этой области поистине необъятны, так что здесь мы на них задерживаться не будем, это должно быть предметом отдельного разговора. Далее создаётся аккаунт обычного пользователя, после чего выводится итоговая панель Live Installation Settings (то, что в русском переводе интерфейса типовой установки обозвали Параметрами установки).

Не ищите здесь секции индивидуального выбора пакетов: её здесь нет. Да и не нужна она, ибо все необходимые пакеты мы имели возможность установить «вживе» ещё до запуска инсталлятора.

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

А пока он идёт – ответим на вопрос, как нам удалось устанавливать и удалять пакеты, да так, что сделанные в Live-среде изменения сохранятся в инсталлированной системе. Хотя, казалось бы, после перезагрузки они должны были бы бесследно исчезнуть. Для чего дождёмся в окне инсталлятора окончания разметки диска и расправы с файловыми системами. После чего текущим действием будет одно-единственное – копирование корневой файловой системы (Copying root filesystem).

Вот вам и разгадка Военной Тайны. Ибо где расположена корневая файловая система Live-среды? Правильно, в оперативной памяти. А куда инкорпорируются исполняемые файлы, библиотеки и прочие компоненты установленных в ходе Live-сеанса пакетов? В корневую файловую систему. А откуда изымаются компоненты пакетов удаляемых? И где отражаются изменения, выполненные в общесистемных конфигах? Опять таки, всё это модификации корневой файловой системы – точнее, её образа в оперативной памяти.

Так что в процессе установки с LiveCD не происходит ни развёртывания образов метапакетов, ни попакетной распаковки индивидуально выбранных пакетов. В сущности всё дело сводится к переносу текущего слепка оперативной памяти на целевой носитель. И потому на нём по завершении установки все изменения, сделанные в Live-среде до запуска инсталлятора, сохранятся в неприкосновенности. В этом и заключается сила описанного метода – насколько мне известно, не имеющего аналогов в более иных дистрибутивах Linux.

Итоги установки

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

Торопиться с перезагрузкой мы не будем. Ибо пора раскрыть Маленький Секрет пятого довода в пользу установки из Live-режима: это возможность сохранения пользовательских настроек рабочей среды. Причём за настройки для административного аккаунта можно не волноваться: поскольку каталог /root, где они упокоились, лежит на корневой файловой системе, все конфигурационные файлы из него будут скопированы в соответствующее место на винчестере.

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

Однако никто не запрещает нам скопировать конфиги уходящего в небытие пользователя linux‘а, например, на флэшку, а затем перенести их в установленную систему. Или сразу поместить их в /mnt_point/home/username, где mnt_point – точка монтирования для раздела на винчестете (не следует забывать, что по окончании установки все задействованые во время неё файловые системы размонтируются), а username – учётное имя пользователя, чей аккаунт был создан во время установки. Нужно будет только потом изменить их владельца и проверить права доступа.

Файлы, подлежащие копированию, – это в первую очередь конфиги KDE (/home/linux/.kderc) и Kopete (/home/linux/.kde4/share/config/kopeterc), а возможно, и других установленных в Live-среде программ.

Вот теперь можно и перезагрузиться. Установка в Live-режиме не предполагает отказа от автоматического конфигурирования системы. Каковое и происходит сразу после её рестарта. И завершается появлением умолчального рабочего стола KDE.

Впрочем, вид его не совсем умолчальный. Беглый взгляд на главное меню показывает, что оно стало русифицированным, утратило пункты, соответствующие удалённым пакетам и, напротив, в его закоулках мы найдём приложения, установленные ранее в Live-сеансе. А шрифты и главная панель сохраняют тот вид, который мы придали им перед установкой.

Заключение

Из всего сказанного выше можно сделать вывод, что установка с LiveCD – отнюдь не обязательно прерогатива совсем начинающих пользователей Linux’а. Конечно, для них такая инсталляция as is обеспечивает максимально быстрое развёртывание системы, содержащей необходимый для начала работы минимум приложений. Но если затратить некоторое время на настройку и наращивание возможностей Live-среды, то систему эту можно сделать и актуальной, и индивидуализированной. Причём существенно более простыми методами, чем при ручном выборе пакетов при установке с DVD или NET-диска.

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

Правда, следует оговорить, что способ этот подходит только тем, кто отдаёт предпочтение средам KDE 4 или GNOME 3, потому что официальных LiveCD с другими десктопами просто нет. Что же до неофициальных – они обычно выходят с некоторой (а иногда и значительной) задержкой относительно текущего релиза. Хотя и эта проблема в принципе решаема – но с существенно большими затратами времени и сил. Так что любителям Xfce, LXDE или, тем более, оконных менеджеров проще прибегнуть к установке с полного DVD или диска для сетевой инсталляции.

ZFS on Linux: практика применения

LinuxFormat, #165-166 и #167 (январь и февраль 2013).

Настоящая статья посвящена практическому использованию ZFS в Linux. Оно рассмотрено на примере openSUSE, хотя почти всё из сказанного применимо и к любым другим дистрибутивам – все дистроспецифические детали оговорены явным образом.

Обзор возможностей

Прежде чем погружаться в вопросы, связанные с ZFS, читатель, вероятно, хотел бы убедиться в том, что это стоит делать. То есть – ознакомиться с возможностями, которые она ему предоставляет.

Для начала – немного цифр. В отличие от всех предшествовавших файловых систем и систем размещения данных, ZFS является 128-битной. То есть теоретическое ограничение на её объём и объёмы её составляющих превышают не только реальные, но и воображаемые потребности любого пользователя. По выражению создателя ZFS, Джеффа Бонвика [Jeff Bonwick], для её заполнения данными и их хранения потребовалось бы вскипятить океан.
Так, объём пула хранения данных (zpool – максимальная единица в системе ZFS) может достигать величины 3×1023 петабайт (а один петабайт, напомню, это 1015 или 250 байт, в зависимости от системы измерения). Каждый пул может включать в себя до 264 устройств (например, дисков), а всего пулов в одной системе может быть тоже не больше 264.

Пул может быть разделён на 264 наборов данных (dataset – в этом качестве выступают, например, отдельные файловые системы), по 264 каждая. Правда, ни одна из таких файловых систем не может содержать больше 248 файлов. Зато размер любого файла ограничивается опять же значением в 264 байт.
Количество таких ограничений можно умножить. Как уже было сказано, они лежат вне пределов человеческого воображения и возможностей. И привожу я их только для того, чтобы вселить в пользователя уверенность: ни он сам, ни его внуки и правнуки в реальности не столкнутся c ограничениями на размер файловой системы или отдельного файла, как это бывало при использовании FAT или ext2fs.

Так что перейду к особенностям ZFS, наиболее интересным, по моему мнению, десктопному пользователю. Здесь в первую очередь надо отметить гибкое управление устройствами. В пул хранения данных можно объединить произвольное (в обозначенных выше пределах) число дисков и их разделов. Устройства внутри пула могут работать в режиме расщепления данных, зеркалирования или избыточности с подсчётом контрольных сумм, подобно RAID’ам уровней 0, 1 и 5, соответственно. В пул можно включать накопители, специально предназначенные для кэширования дисковых операций, что актуально при совместном использовании SSD и традиционных винчестеров.

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

Пул хранения может быть разделён на произвольное количество иерархически организованных файловых систем. По умолчанию размер их не определяется, и растёт по мере заполнения данными. Это избавляет пользователя от необходимости расчёта места, потребного под системные журналы, домашние каталоги пользователей и другие трудно прогнозируемые вещи. С другой стороны, не запрещено при необходимости и квотирование объёма отдельных файловых систем – например, домашних каталогов отдельных излишне жадных пользователей.

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

Среди других возможностей ZFS, интересных настольному пользователю, можно упомянуть:

  • создание снапшотов файловой системы, позволяющих восстановить её состояние в случае ошибки;

  • клонирование файловых систем;

  • компрессия данных файловой системы и дедупликация (замена повторяющихся данных ссылками на «первоисточник»);

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

В общем, даже если не говорить об быстродействии ZFS (а оно весьма высоко, особенно в многодисковых конфигурациях), перечислять её достоинства можно очень долго. Так долго, что поневоле успеваешь задаться вопросом: а есть ли у неё недостатки?

Разумеется, есть. Хотя большая их часть – скорее особенности: например, ограничения при добавлении или удалении накопителей в пуле, или отсутствие поддежки TRIM.

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

Первый недостаток если не ликвидирован, то сглажен трудами Брайана Белендорфа [Brian Behlendorf] со товарищи и майнтайнерами прогрессивных дистрибутивов вкупе с примкнувшими к ним независимыми разработчиками. Аппаратные же претензии ZFS мы сейчас и рассмотрим.

Аппаратные потребности

Итак, ZFS предоставляет пользователю весьма много возможностей. И потому вправе предъявлять немало претензий к аппаратной части – процессору (изобилие возможностей ZFS создает на него достаточную нагрузку), оперативной памяти и дисковой подсистеме.

Впрочем, претензии эти отнюдь не сверхъестественные. Так, процессор подойдёт любой из относительно современных, начиная, скажем, с Core 2 Duo. Минимальный объём памяти определяется в 2 ГБ, с оговоркой, что применение компрессии и дедупликации требуют 8 ГБ и более.

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

К «железным» претензиям добавляются и притязания программные. В первую очередь, ZFS on Linux требует 64-битной сборки этой ОС, поскольку в 32-разрядных системах действует ограничение на адресное пространство физической памяти. Кроме того, в конфигурации ядра должнв быть отключена опция CONFIG_PREEMPT. Поэтому, например, в openSUSE ZFS может использоваться с ядром kernel-default, но не kernel-desktop, каковое, вопреки названию, устанавливается по умолчанию при стандартной настольной инсталляции.

Если вас привлекли достоинства ZFS и не устрашили её «железные» аппетиты, самое время опробовать её в деле. Что потребует знакомства с некоторыми специфическими понятиями.

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

Центральным понятием ZFS является пул хранения данных [zpool]. В него может объединяться несколько физических устройств хранения – дисков или дисковых разделов, причём первый вариант рекомендуется. Но не запрещено и создание пула из одного диска или его раздела.

Каждый пул состоит из одного или нескольких виртуальных устройств [vdev]. В качестве таковых могут выступать устройства без избыточности (то есть всё те же диски и/или их разделы), или устройства с избыточностью – зеркала и массивы типа RAID-Z.

Зеркальное устройство [mirror] – виртуальное устройство, хранящее на двух или более физических устройствах, но при чётном их количестве, идентичные копии данных на случай отказа диска,

RAID-Z – виртуальное устройство на нескольких устройств физических, предназначенное для хранения данных и их контрольных сумм с однократным или двойным контролем чётности. В первом случае теоретически требуется не менее двух, во втором – не менее трёх физических устройств.

Если пул образован устройствами без избыточности (просто дисками или разделами), то одно из vdev, соответствующее ему целиком, выступает в качестве корневого устройства. Пул из устройств с избыточностью может содержать более одного корневого устройства – например, два зеркала.

Пулы, образованные виртуальными устройствами, служат вместилищем для наборов данных [dataset]. Они бывают следующих видов:

  • файловая система [filesystem] – набор данных, смонтированный в определённой точке и ведущий себя подобно любой другой файловой системе;

  • снапшот [snalishot] – моментальный снимок текущего состояния файловой системы, доступный только для чтения;

  • клон [clone] – точная копия файловой системы в момент его создания; создаётся на основе снимка, но, в отличие от него, доступен для записи;

  • том [volume] – набор данных, эмулирующий физическое устройство, например, раздел подкачки.

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

pool_name/path/[dataset_name][@snapshot_name]

Пулы и наборы данных в именуются по правилам пространства имён ZFS, впрочем, довольно простым. Запрещёнными символами для всех являются символы подчёркивания, дефиса, двоеточия, точки и процента. Имя пула при этом обязательно должно начинаться с алфавитного символа и не совпадать с одним из зарезервированных имён – log, mirror, raidz или spare (последнее обозначает имя устройства «горячего» резерва). Все остальные имена, в соответствие с демократическими традициями пространства имён ZFS, разрешены.

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

Модели именования устройств

В современном Linux’е использование для накопителей имён «верхнего уровня», имеющих вид /dev/sda, не является обязательным, а в некоторых случаях и просто нежелательно. Однако правила менеджера устройств udev позволяют определять и другие модели идентификации накопителей. В частности, штатными средствами дисковой разметки openSUSE предусмотрены варианты идентификации по:

  • метке тома (/dev/disk/by-label);

  • идентификатору диска (/dev/disk/by-id);

  • пути к дисковому устройству (/dev/disk/by-path);

  • универсальному уникальному идентификатору, Universally Unique IDentifier (/dev/disk/by-uuid).

А с полным списком вариантов идентификации блочных устройств можно ознакомиться, просмотрев имена подкаталогов в каталоге /dev/disk, их содержимое – это символические ссылки на имена «верхнего уровня».

С идентификацией по метке тома и по UUID, вероятно, знакомо большинство читателей. И к тому же в пространстве имён ZFS они не используются. А вот с идентификацией by-path и by-id нужно познакомиться поближе.

Модель именования by-path использует имена устройств, привязанные к их положению на шине PCI и включающие номер шины и канала на ней. Имя дискового устройства выглядит примерно так:

pci-0000:00:1f.2-scsi-0:0:0:0

Дисковые разделы маркируются добавлением к имени устройства суффикса part#.
Модель именования by-path идентифицирует устройства вполне однозначно, и особенно эффективна при наличии более чем одного дискового контроллера. Однако сами имена и устройств, и разделов описываются довольно сложной для восприятия последовательностью. Да и в большинстве «десктопных» ситуаций модель эта избыточна.

Модель идентификации by-id представляет имена носителей информации в форме, наиболее доступной для человеческого понимания. Они образованы из названия интерфейса, имени производителя, номера модели, серийного номера устройства и, при необходимости, номера раздела, например:

ata-SanDisk_SDSSDX120GG25_120823400863-part1

Таким образом, все компоненты имени устройства в модели by-id определяются не условиями его подключения или какими-то правилам, а задаются производителем и жестко прошиты в «железе». И потому эта модель является наиболее однозначной для именования устройств. А также, что немаловажно, строится по понятной человеку логике. Не случайно именно она принята по умолчанию в инсталляторе openSUSE.

Какую из моделей именования устройств выбрать для данного пула – зависит от его назначения и масштабов. Имена «верхнего уровня» целесообразно применять для однодисковых пулов (особенно если в машине второго диска нет и не предвидится, как обычно бывает в ноутбуках). Они же, по причине простоты и удобопонятности, рекомендуются для экспериментальных и разрабатываемых пулов. И очень не рекомендуются – во всех остальных случаях, так как зависят от условий подключения накопителей.

Этого недостатка лишена модель by-id: как пишет Брайан, при её использовании «диски можно отключить, случайно смешать и подключить опять произвольным образом – и пул будет по-прежнему корректно работать». Как недостаток её рассматривается сложность конфигурирования больших пулов с избыточностью. И потому она рекомендуется для применения в «десктопных» и «квартирных» (типа семейного сервера) условиях.

Для больших (более 10 устройств) пулов из дисков, подключённых к нескольким контроллерам, рекомендуется идентификация by-path. Однако в наших целях она громоздка и избыточна.

Наконец, ZFS on Linux предлагает и собственную модель идентификации – /dev/disk/zpool, в котором именам by-path ставятся в соответствие уникальные и осмысленные «человекочитаемые» имена, даваемые пользователем. Модель эта рекомендуется для очень больших пулов, каковых на настольной машине ожидать трудно.

Так что дальше я буду использовать имена «верхнего уровня», говоря об абстрактных или экспериментальных ситуациях, и об именах by-id, когда речь зайдёт о практических примерах применения ZFS.

Включение поддержки ZFS

Для практического использования ZFS on Linux перво-наперво необходимо обеспечить её поддержку в вашем дистрибутиве – ибо по причинам, описанным в предыдущей статье, сама собой она не поддержится ни в одном Linux’е.

Как это сделать, зависит от дистрибутива. В Сети можно найти подробные инструкции для Ubuntu и Gentoo, которые легко распространяются на клоны обеих систем. Не столько инструкции, сколько руководства к самостоятельному действию имеются на сайте проекта ZFS on Linux для абстрактных RPM- и Deb-based дистрибутивов. Я же расскажу о том, как это делается в openSUSE релизов 12.1 и 12.2.

Как вы наверняка догадались, ZFS не поддерживается в openSUSE ни «искаропки», ни в официальных репозиториях. Но зато в репозиториях неофициальных, так называемых «домашних», пакеты её поддержки представлены аж в двух экземплярах: в mUNIX9 и в ghaskins. Точные их адреса легко найти через систему OBS (Open Builging System) по ключевому слову zfs.

Какому из репозиториев отдать предпочтение – вопрос спорный. Первые свои опыты с ZFS on Linux я проводил, основываясь на пакетах из mUNIX9. И они прошли без всяких осложнений, хотя и велись в сугубо экспериментальном режиме. Однако к моменту понимания, что эта система для меня – «всерьёз и надолго», последняя тогда версия zfs имелась только в репозитории ghaskins. Однако его использование требует некоторых дополнительных манипуляций.

Кроме того, в репозитории ghaskins на данный момент имеются пакеты только для openSUSE релизов 12.1 и 12.2. Репозиторий же mUNIX9 охватывает все актуальные ныне версии SLE и openSUSE. включая Tumbleweed и Factory.

Различаются репозитории и набором пакетов. В ghaskins, кроме «рабочих» модулей zfs и spl для ядра default, можно видеть массу отладочных их сборок (рис. 1).

В репозитории mUNIX9 с этим существенно скромнее – имеются модули только для ядра default и для xen (рис. 2)

Так что окончательный выбор я предоставляю читателю. Но на какой бы репозиторий он ни пал, его следует подключить. И сделать это можно любым из трёх способов. Первый – с помощью zypper’а:

# zypper ar -f [URL] [Name]

Второй способ – через модуль Репозитории… центра управления YaST2 посредством кнопки Добавить (рис. 3):

выбора пункта Указать URL (рис. 4):

и ввода необходимых значений в поля Имя репозитория и URL (рис. 5):

Наконец, третий способ, для самых ленивых – отыскать пакеты zfs, spl и сопутствующие через OBS и прибегнуть к «установке в один клик». В этом случае подключение репозиториев будет совмещено с установкой пакетов.

В первых двух же вариантах после подключения репозитория надо будет установить (с помощью zypper’а или модуля управления пакетами YaST’а) следующее (пример дан для репозитория mUNIX9, но из ghaskins потребуются те же компоненты):

Возможно, не вредным окажется и пакет zfs-test. А вот zfs-dracut, предназначенный для создания initrd с поддержкой ZFS, несмотря на его потенциальную нужность, установить не удастся: требуемый для него пакет dracut в openSUSE пока не поддерживается.

Следует учесть, что при использовании ядра kernel-desktop (а скорее всего, так оно и есть) пакет zfs-kmp-default потянет за собой и соответствующее ядро kernel-default. Пункт загрузки которого будет внесён в меню GRUB, но не будет отмечен как умолчальный – этим надо озаботиться самому.

И, наконец, при использовании пакетов из ghaskins потребуется, скорее всего, сделать в каталогах /etc/init.d/rc3.d и /etc/init.d/rc5.d символические ссылки на файл /etc/init.d/zfs. Иначе файловые системы ZFS, к созданию которых мы приближаемся, не будут автоматически монтироваться при старте и размонтироваться при останове системы.

При использовании репозитория mUNIX9 эти действия будут нечувствительно выполнены в ходе установки пакетов.

Вот теперь можно приступать к применению ZFS в мирных практических целях.

Создаём простой пул

Освоив ранее основные понятия, мы научились понимать ZFS. Для обратной же задачи – чтобы ZFS понимала нас – нужно ознакомиться с её командами. Главные из них – две: zpool для создания и управления пулами, и zfs для создания и управления наборами данных. Немного, правда? Хотя каждая из этих команд включает множество субкоманд, с которыми мы со временем разберёмся.
Очевидно, что работу с ZFS следует начинать с создания пула хранения. Начнём с этого и мы. В простейшем случае однодисковой конфигурации это делается так:

# zpool create tank dev_name

Здесь create – субкоманда очевидного назначня, tank – имя создаваемого пула (оно обычно даётся в примерах, но на самом деле может быть любым – с учётом ограничений ZFS), а dev_name – имя устройства, включаемого в пул. Каковое может строиться по любой из описанных ранее моделей. И, чтобы не повторяться, напомню: все команды по манипуляции с пулами и наборами данных в них выполняются от лица администратора.

В случае, если в состав пула включается один диск, и второго не предвидится, можно использовать имя устройства верхнего уровня – например, sda для цельного устройства (обратим внимание, что путь к файлу устройства указывать не нужно). Однако реально такая ситуация маловероятна: загрузка с ZFS проблематична, так что как минимум потребуется раздел с традиционной файловой системой под /boot (и/или под корень файловой иерархии), так что команда примет вид:

# zpool create mypool sda2

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

# zpool create mypool ata-ata-ST3500410AS_5VM0BVYR-part2

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

# zpool create mypool dev_name1 dev_name2

где dev_name1 и dev_name1 – имена устройств в принятой модели именования.
В приведённом случае будет создано нечто вроде RAID’а нулевого уровня, с расщеплением [stripping] данных на оба устройства. Каковыми могут быть как дисковые разделы, так и диски целиком. Причём, в отличие от RAID0, диски (или разделы) не обязаны быть одинакового размера:

# zpool create mypool sdd sdf

После чего никаких сообщений не последует. No news – good news, говорят англичане; в данном случае это означает, что пул был благополучно создан. В чём можно немедленно убедиться двумя способами. Во-первых, в корневом каталоге появляется точка его монтирования /mypool. А во-вторых, этой цели послужит субкоманда status:

# zpool status mypool

которая выведет нечто вроде этого:

pool: mypool
state: ONLINE
scan: none requested
config: NAME STATE READ WRITE CKSUM
mypool ONLINE 0 0 0
sdd ONLINE 0 0 0
sdf ONLINE 0 0 0 errors: No known data errors

А с помощью субкоманды list можно узнать объём новообразованного пула:

# zpool list mypool
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
mypool 18,9G 93K 18,9G 0% 1.00x ONLINE -

Легко видеть, что он равен сумме объёмов обеих флэшек, если «маркетинговые» гигабайты пересчитать в «настоящие».

К слову сказать, если дать субкоманду list без указания аргумента – имени пула, то она выведет информацию о всех пулах, задействованных в системе. В моём случае это выглядит так:

# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
mypool 18,9G 93K 18,9G 0% 1.00x ONLINE -
tank 199G 20,8G 178G 10% 1.00x ONLINE -

Обращаю внимание, что даже чисто информационные субкоманды вроде list и status требуют прав администратора.

Разумеется, два пула в одной, да ещё и настольной, машине – излишняя роскошь. Так что пул, созданный в экспериментальных целях, подлежит уничтожению, что делается с помощью субкоманды destroy:

# zpool destroy mypool

После чего он пропадёт из списка пулов. А что можно сделать с пулом до его уничтожения, увидим со временем.

«Избыточные» пулы

Избавившись от ставшего ненужным пула, рассмотрим второй вариант – создание пула с зеркальным устройством. Создаём его из двух накопителей одинакового объёма:

# zpool create -f mypool mirror sdf sdg

Проверка показывает, что итоговый пул, как и следовало ожидать, равен объёму одного накопителя:

# zpool list mypool
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
mypool 3,72G 91,5K 3,72G 0% 1.00x ONLINE -

При различии объёмов больший диск будет «обрезан» до объёма меньшего.

Полное зеркалирование любыми, по моему мнению, в настольных условиях – роскошь непозволительная: банальные бэкапы данных проще и надёжнее. Тем не менее, не исключаю, что некоторая избыточность на уровне проверки контрольных сумм может оказаться не лишней, да и не столь накладна. Так что давайте посмотрим и на третий вариант пула из более чем одного устройства – RAID-Z.

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

# zpool create mypool raidz sdd sdf sdg

что даст нам следующую картину:

# zpool list mypool
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
mypool 11,1G 205K 11,1G 0% 1.00x ONLINE -

Впрочем, как мне кажется, в настольных условиях не стоит выделки и эта овчинка.

Пул кэшируемый

И, наконец, последний вариант организации пула из более чем одного устройства – создание пула с кэшированием. Для чего создаём из двух устройств простой пул без избыточности и подсоединяем к нему устройство для кэша:

# zpool create mypool sdd sdf cache sdg

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

# zpool list mypool
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
mypool 18,9G 82K 18,9G 0% 1.00x ONLINE -

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

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

О некоторых опциях команды zpool

Команда zpool поддерживает ещё множество субкоманд, предназначенных для экспорта и импорта пула, добавления к нему устройств и изъятия оных, и так далее. Но сейчас я расскажу о некоторых опциях, которые могут оказаться необходимыми при создании пула.

Одна из важный опций – -f: она предписывает принудительное выполнение данной операции и требуется, например, при создании пула из неразмеченных устройств.

Полезной может оказаться опция -n. Она определяет тестовый режим выполнения определённой субкоманды, то есть выводит результат, например, субкоманды zpool create без фактического создания пула. И. соответственно, сообщает об ошибках, если таковые имеются.

Интересна также опция -m mountpoint. Как уже говорилось, при создании пула по умолчанию в корне файловой иерархии создаётся каталог /pool_name, который в дальнейшем будет точкой монтирования файловых систем ZFS. Возможно, что это окажется не самым лучшим местом для их размещения, и, как мы увидим в дальнейшем, это несложно будет изменить. Но можно задать каталог для пула сразу – например, /home/data: это и будет значением опции -m. Никто не запрещает определить в качестве такового и какой-либо из существующих каталогов, если он пуст, иначе автоматическое монтирование файловых систем пула в него окажется невозможным.

Наконец, нынче важное значение приобретает опция ashift=#, значением которой является размер блока файловой системы в виде степеней двойки. По умолчанию при создании пула размер блока определяется автоматически, и до некоторого времени это было оптимально. Однако затем, с одной стороны, появились диски так называемого Advanced Format, с другой – получили распространение SSD-накопители. И в тех, и в других размер блока равен 4 КБ, хотя в целях совместимости по-прежнему эмулируется блок в 512 байт. В этих условиях автоматика ZFS может работать некорректно, что приводит к падению производительности пула.

Для предотвращения означенного безобразия и была придумана опция ashift. Значение её по умолчанию – 0, что соответствует автоматическому определению размера блока. Прочие же возможные значения лежат в диапазоне от 9 для блока в 512 байт (29 = 512) до 16 для 64-килобайтного блока (216 = 65536). В интересующем нас случае четырёхкилобайтного блока оно составляет 12 (212 = 4096). Именно последнее значение и следует указать явным образом при создании пула из винчестеров AF или SSD-накопителей.

Создание файловых систем

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

Для создания файловых систем предназначена субкоманда create команды zfs, которая требует единственного аргумента – имени создаваемой ФС и обычно не нуждается ни в каких опциях:

# zfs create pool_name/fs_name

Внутри пула можно создавать сколь угодно сложную иерархию файловых систем. Единственное условие – родительская файловая система для системы более глубокого уровня вложенности должна быть создана заблаговременно. Ниже я покажу это на конкретном примере создания файловых систем внутри каталога /home – наиболее оправданное место для размещения наборов данных ZFS.

Начну я немножечко издалека. При стандартной установке openSUSE не обойтись без создания учетной записи обычного пользователя, и, следовательно, в каталоге /home будет присутствовать по крайней мере один подкаталог – /home/username.

Смонтировать же файловую систему ZFS в непустой каталог невозможно, и, значит, мы не можем сразу прибегнуть к опции -m для определения «постоянной прописки» создаваемого пула.

Поэтому для начала делаем для пула «прописку» во временной точке – пусть это будет традиционный /tank:

# zpool create -o ashift=12 tank ata-SanDisk_SDSSDX120GG25_120823400863-part3 ata-SanDisk_SDSSDX120GG25_120823402786-part3

Теперь создаём файловую систему для будущего домашнего каталога:

# zfs create tank/home

А внутри же неё – необходимые дочерние ветви, как то:

# zfs create tank/home/alv

которая потом заменит мой домашний каталог – в нём я не держу ничего, кроме конфигурационных файлов;

# zfs create tank/home/proj

это файловая система для моих текущих проектов, и так далее.

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

# zfs destroy pool_name/fs_name

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

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

$ mount | grep tank
tank/home on /tank/home type zfs (rw,atime,xattr)
tank/home/alv on /tank/home/alv type zfs (rw,atime,xattr)
tank/home/proj on /tank/home/proj type zfs (rw,atime,xattr)
...

Для обеспечения монтирования файловых систем ZFS при рестарте машины не требуется и никаких записей в файле /etc/fstab: это также происходит само собой, совершенно нечувствительно для пользователя. Правда, если для файловой системы ZFS определить свойство mountpoint=legacy, то с ней можно управляться и традиционным способом.

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

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

Файловые системы: устанавливаем свойства

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

# zfs get all fs_name

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

Так, абсолютно лишним представляется свойство atime, то есть обновление времени последнего доступа к файлам. Оно, во-первых, снижает быстродействие, с другой – способствует износу SSD-накопителей (правда, нынче и то, и другое чисто символичны). Так что отключаем это свойство для всех файловых систем:

# zfs set atime=off tank/home

Аналогичным образом расправляемся и со свойством xattr:

# zfs set xattr=off tank/home

А вот дальше можно заняться и индивидуализацией. Как я уже говорил, в момент создания файловые системы ZFS «безразмерны». Если это не подходит, для них можно установить квоты. Однако я этого делать не буду – в моём случае это приводит к потере половины смысла ZFS. А вот зарезервировать место для критически важных каталогов, дабы его не отъела, скажем, мультимедиа, известная своей прожорливостью, будет не лишним. И потому я для файловых систем tank/home/proj и tank/home/alvустанавливаю свойство reservation. Для файловой системы проектов оно будет максимальным:

# zfs set reservation=10G tank/home/proj

Для остальных ограничусь более скромным гигабайтом резерва.

Далее, поскольку данные в файловой системе tank/home/proj для меня действительно важны, и шутить с ними я склонен даже гораздо меньше, чем с дамами, предпринимаю дополнительные меры по их сохранности путём удвоения числа копий (по умолчанию оно равно 1):

# zfs set copies=2 tank/home/proj

А для данных не столь важных – тех, что часто проще скачать заново, нежели отыскать на локальной машине, можно выполнить и обратную операцию – отказаться от подсчёта контрольных сумм:

# zfs set checksum=off tank/home/media

Для файловых систем, содержащих хорошо сжимаемые данные (например, для моего домашнего каталога, где лежат одни dot-файлы), можно включить компрессию:

# zfs set compression=on tank/home/alv

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

При желании для некоторых файловых систем (например, того же домашнего каталога) можно отключить такие свойства, как exec, setuid, devices – легко догадаться, что результат будет аналогичен указанию опций монтирования noexec, nosuid, nodev для традиционных файловых файловых систем. И, разумеется, для файловых систем, изменение которых нежелательно, можно придать свойство readonly.

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

О перемонтировании

После создания файловых систем и задания всех необходимых их свойств наступает психологический момент для перемонтирования их по месту «постоянной прописки» – то есть в каталог /home. Что потребует некоторых подготовительных действий.

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

# chown -R alv:users /tank/home/*

Теперь нужно скопировать конфиги из каталога /home/alv в /tank/home/alv:

# cp -Rp /home/alv/.* /tank/home/alv/

не забыв про опцию -p для сохранения атрибутов.

Все предыдущие операции можно было выполнять, получив права администратора с помощью команды su (или, при желании, sudo). Причём где угодно – в текстовом виртуальном терминале или в терминальном окне Иксового сеанса (например, в konsole KDE). Теперь же потребуется переавторизоваться в «голой» консоли.

Монтирование файловых систем ZFS в каталог с любым содержимым невозможно, так что требуется очистить каталог /home от следов прежней жизнедеятельности пользователя таким образом:

# rm -Rf /home/alv

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

# ps aux | grep alv

обращая внимание на идентификаторы процессов (PID). А затем последовательно мочим их в сортире:

# kill -9 ####

Выполнив все указанные действия, определяем для набора данных tank/home свойство mountpoint, что и осуществит перемонтирование:

# zfs set mountpoint=/home tank/home

Теперь остаётся только с помощью команды ls убедиться, что в /home появились новые подкаталоги с нужными атрибутами:

drwxr-xr-x 26 alv users 48 Sep 23 14:27 alv/
drwxr-xr-x 18 alv users 18 Sep 22 02:28 proj/
...

А команда

# mount | grep /home

покажет нам новые точки монтирования файловых систем:

tank/home on /home type zfs (rw,noatime,noxattr)
tank/home/alv on /home/alv type zfs (rw,noatime,noxattr)
tank/home/proj on /home/proj type zfs (rw,noatime,noxattr)
...

Как я уже говорил выше, при использовании пакетов из репозитория mUNIX9 на этом дело с подготовкой файловых систем ZFS к практической работе можно считать законченным: при перезагрузке машины все они будут благополучно смонтированы в автоматическом режиме. Пакеты же из ghaskins потребуют ещё одного деяния – создания в каталогах /etc/init.d/rc3.d и /etc/init.d/rc5.d символических ссылок на файл /etc/init.d/zfs.

Вместо заключения

За чертой статьи остались многие вопросы применения ZFS, в частности, экспорта и импорта пулов, совместного использования наборов данных в разных дистрибутивах Linux’а (и, возможно, не только его), создания снапшотов и клонов, восстановления после сбоев. Очень интересно изучить проблему размещения на ZFS корня файловой иерархии и возможность загрузки с неё. Однако надеюсь, что рассказанное на предыдущих страницах позволит читателю оценить достоинства ZFS как универсальной комплексной системы размещения данных. Полагаю, что приведённых сведений будет достаточно и для начала практической работы с ней.

Оглавление

Вступление 1

Колонки 1

2006 1

Новый инсталлятор Debian 1

Процессор Cell и его роль в Linux-революции 2

Open Source: разработчики и спонсоры 2

Kubuntu в роли пасынка? 3

Xubuntu: в благородном семействе прибыло 3

Desktop’изация BSD 4

Семь шагов Linux-дистрибуции 4

LinuxWorld 2006 5

На злобу дня, или Oracle vs Red Hat 5

Будущее Open Source: коммерциализация или сайентификация? 6

2007 6

Скорость загрузки системы: путь на пользовательский десктоп? 6

Debian или Kebian? 6

Linux на Cell: уже реальность? 7

Дети капитана Патрика 8

CRUX – крестоносец идеи 8

Обновление Debian-семейства 9

Мир изменился… 9

Не спрашивай, что ты сделал для Linux’а… 10

SCO’тский вопрос 10

ZFS: конец файловым проблемам? 11

Mandriva на Руси: второе нашествие Бонапарта? 11

Linux и творческая интеллигенция 12

2008 12

Поэзия – Linux’у 12

Nexenta, или еще раз о жирафе Анюте 13

Семинары, семинары… 13

Сделайте мне … хорошо 13

Как вас теперь называть? 14

Ханс Рейзер: точка в деле? 14

Безальтернативность: всегда ли это плохо? 15

Какой Linux учить? 15

LinuxFormat: юбилей в троичном счислении 16

Xfce: назад в будущее? 16

FreeBSD на десктопе 17

Пердем – персональный демон 17

2009 18

Серенада солнечной долины… 18

Файловая система btrfs: Linux-ответ ZFS? 18

Тётя Ася или дядя Джаббер? 19

Нет OEM’ным ОС? 19

Debian GNU/kFreeBSD: знает ли мсье толк в извращениях? 20

Мир без солнца 20

Будут ли машины большими? 21

NILFS выходит из тени 21

Btrfs – ждём стабилизации? 21

Куда развиваться свободному софту? 22

Феномен Juick’и 22

Русская Fedora: первый год жизни 23

GNOME Shell: всё для блага человека 23

2010 24

Дистрибутив Linux: кто он сегодня? 24

Пингвины пишут своими шрифтами 24

Обновления системы: нужны ли они народу? 25

Конец «камнестроения»? 25

Неттопия на практике 25

Незнаменитый офис 26

Fedora в новой сфере? 26

Нативная ZFS для Linux и будущее btrfs 27

Памяти советской геологии 27

KDE 3: реанимация или гальванизация? 28

Судьба OpenSolaris: бессмертна ли мафия? 28

Линуксоид как высшая ступень эволюции Homo sapiens 29

RFRemix 14: сбытие мечт? 29

2011 29

Как читать Linuxformat 29

Парадокс линуксописательства 30

Linux от Oracle 30

ОС Barrelfish: рыбозасолочный цех 31

Linux и OCR – братья на век 31

Куда катится мир? 32

Волхвы-то кричали с того и с сего 32

Linux в «верхнем» образовании 33

О LUG’ах и горе Верблюд 33

Снова Open Source в науке 34

Дети мага Мандрейка 34

Как завладеть миром? 35

2012 35

Куда казаку податься? 35

PCLinuxOS в отечественной редакции 36

Очень грустная колонка… 36

Гибридное видео, или мичуринцы из NVIDIA 36

Блеск openSUSE 37

openSUSE: и на на солнце бывают пятна 37

Во славу Гомера 38

Нативная ZFS – Linux’у! 39

Бич свободных лицензий 39

openSUSE 12.2: детектив вокруг релиза 40

OpenSUSE: первый шаг к релизу 12.3 40

Юстируем шрифты 40

2013 41

О причинах systemd’изации 41

Возвращаясь к PCLinuxOS 41

Немножко о DragonFly… 42

Файловая система для SSD 42

Роман-предупреждение 43

Монотеизм или дуализм? А может – язычество 43

Песнь о потомках Sid’а 44

Куда идёт Kubuntu? 44

Mir или не Mir, вот в чём вопрос 45

Заработать на FOSS: маечки или ехать? 45

Дорога к Mir’у 46

Слово о Cinnamon’е 46

Статьи 47

Ubuntu и Kubuntu: гуманистический Linux 47

Об Ubuntu и Kubuntu 47

Настройка доступа к репозиториям пакетов 48

Основы пакетного менеджмента 49

Команда dpkg сотоварищи 49

Инструментарий apt 50

Kubuntu по русски 51

Борьба за мультимедиа 52

Linux-пресса на Руси: Вопросы истории 53

Идеальный журнал 56

Second Open Source Forum Russia 57

Марк Шаттлворт в Петербурге 58

Выступление 59

Вопросы и ответы 61

Интервью 63

Снова aptitude: режим командной строки 64

Zenwalk Linux: не его ли учить? 68

Применим фильтры 68

Почему Zenwalk? 70

Zenwalk: знакомимся ближе 72

И на прощание 74

Управление rpm-пакетами: нынче не то, что давеча 74

Незнаменитый yum 74

PackageKit – кит пакетного менеджмента 78

openSUSE LiveCD: нетривиальная установка 82

Вступление 82

Live-среда: запуск 83

Подготовка Live-режима 84

Настройка окружения администратора 84

Преамбула к установке 84

Установка 87

Итоги установки 87

Заключение 88

ZFS on Linux: практика применения 89

Обзор возможностей 89

Аппаратные потребности 90

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

Модели именования устройств 91

Включение поддержки ZFS 93

Создаём простой пул 96

«Избыточные» пулы 97

Пул кэшируемый 98

О некоторых опциях команды zpool 98

Создание файловых систем 99

Файловые системы: устанавливаем свойства 100

О перемонтировании 101

Вместо заключения 102

Перейти к верхней панели