С точки зрения производительности тоже достаточно интересная штука: при подключении через 4x 1GBps Ethernet (с использованием LACP, но это тема для отдельного поста) определенно упирается в сеть, но все равно отлично подходит для использования в решении многих прикладных задач. Из интересных опций можно отметить прозрачное использование нескольких SSD-дисков в каждом дисковом массиве в роли кэша.

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

К чему я это все вспомнил? На почту пришел очередной рекламный буклет от Sun с предложением попробовать Sun Unified Storage в виртуальной машине VirtualBox или VMWare, сам еще не установил — времени не нашлось, но возможно Вам покажется интересным. Конечно это не совсем то же самое, что и физическая железка — производительность дисковых и сетевых подсиситем не померять, но веб-интерфейс заценить можно.

Зато через какое-то время наткнувшись на очередную заметку про все ту же довольно избитую тему, я заметил ма-а-аленькую неприметную ссылку на «инструкцию по компиляции Google Chrome из исходников в Linux». В очередной раз пожав плечами с мыслью «а нам не привыкать, все равно Gentoo пользуюсь» отправился вводить заветное заклинание в свежесозданную консольку.

Заклинание это выглядит примерно следующим образом:

#!/bin/bash
CHROME=/usr/local/src
mkdir $CHROME/chrome
cd $CHROME/chrome
export LANG=C
$CHROME/depot_tools/gclient config http://src.chromium.org/svn/trunk/src
$CHROME/depot_tools/gclient sync
cd $CHROME/src/chrome
../third_party/scons/scons.py Hammer

Для успешного каста требуются следующие ингридиенты:

• subversion >= 1.4
• pkg-config >= 0.20
• python >= 2.4
• perl >= 5.x
• gcc/g++ >= 4.2
• bison >= 2.3
• flex >= 2.5.34
• gperf >= 3.0.3
• libnss3-dev >= 3.12

Начался процесс вполне оптимистично — строчки, генерируемые svn co побежали по экрану вполне весело, но когда этот процесс затянулся на более чем час – стало очевидно, что даже Google оказалось не по зубам выдержать такой наплыв желающх «заценить» новую игрушку и обеспечить достаточную пропускную способность на сервере с SVN. Правда и масштабы проекта мягко говоря впечатляют — директория с исходным кодом перед инициализацией компиляции оказалось очень даже весомой: 2.6 GB. В общем в итоге я не придумал ничего лучше, чем по старой традиции оставить браузер компилироваться на ночь и с чистой совестью уползти спать.

В итоге оказалось, что в результате получается не вовсе браузер, а лишь некоторые непонятно зачем нужные бинарники: надо было внимательно читать инструкцию, особенно обведенный в красную рамку блок — студенческая привычка при чтении чего-либо подсознательно отфильтровывать всю на первый взгляд второстепенную информацию, попадающую в категорию «слишком много букв», дала о себе знать В общем там об этом все заранее предупреждали — я просто не заметил, ну да ладно: в wine-то оно точно заведется, все тот же Google с легкостью помог обнаружить соответствующий мануал, для моего Gentoo он свелся к следующему:

#!/bin/bash
emerge --sync; emerge -av wine cabextract
cd /usr/bin
sudo wget www.kegel.com/wine/winetricks
sudo chmod +x winetricks
winetricks riched20 riched30 flash allfonts
cd ~
wget gpdl.google.com/chrome/install/149.27/chrome_installer.exe
wine chrome_installer.exe
rm chrome_installer.exe

Запуск с ходу из инсталлятора ничем хорошим не закончилcя, но вот такая команда вполне нормально запустила-таки браузер

wine ~/.wine/drive_c/windows/profiles/m11/Local Settings/Application Data/Google/Chrome/Application/chrome.exe--new-http --in-process-plugins

(если кто соберется копипастить — не забываем подменять m11 на свое имя пользователя)

Первое впечатление — ужасный V**ta-like дизайн, вернее не то чтобы он совсем ужасный — минималистичность очень даже полезное свойство для дизайна браузера, но в мое KDE 3.5.9 темно-фиолетовой раскраски он не вписывается ну совсем никак. Ну да ладно — пока он стоит «просто побаловаться», то можно и потерпеть. Далее я решил пройтись по основным «фишечкам», заинтересовавшим меня в комиксах — все реализовано вполне «как обещали», очень много концептуально правильных решений, которых в старом-добром FF определенно не хватает (перечислять наверное смысла нет — все и так уже, наверное, в курсе что там есть «вкусненького»). Но и многих абсолютно жизненно-важных вещей я там не обнаружил — начиная с блокировки рекламы и заканчивая все тем же стандартно-фиксированным дизайном и отсутствием центрального репозитория плагинов. Кое-какие неприятности можно свалить на все еще не окончательную доведенность до ума wine (проблемы с SSL/TSL, скажем), но на них я смело закрывал глаза — пока не будет полноценной Linux-версии о регулярном использовании данного продукта речи быть просто не может. Скорость работы новинки также произвела впечатление — на его фоне даже FF чисто субъективно показался медлительным (не смотря на все огрехи wine, как оно будет выглядить в native-версии — предсказать сложно).

Меню настроек оказалось вполне стандартным — ничего лишнего, лишь самые необходимые вещи, даже ребенок разберется. Хотя сложно на самом деле сказать плюс это или минус: если вдруг взбредет в голову потюнить что-либо более специфическое, могут возникнуть проблемы, хотя впринципе возможно там всетаки предусмотренно какое-то более расширенное меню настроек, по аналогии с about:config в FF, а я его просто не нашел.

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

P.S.: А вот тут есть RSS, если вдруг кто еще не в курсе.

Источники информации

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

Основным источником информации послужила презентация Brad Fitzpatrick в Токио.

Платформа

• Linux (Debian Sarge)
• Perl
• Apache
• MySQL 4.0/4.1 в основном с InnoDB
• Perlbal, веб-сервер и балансировщик нагрузки
• memcached для распределенного кэширования
• MogileFS, распределенная файловая система
• Gearman
• TheShwartz
• djabberd

Статистика

• на данный момент 15320315 учетных записей; (10.04.08)
• из них активно используется 551589;
• наиболее активно сервис используется в США и Российской федерации, а 2/3 пользователей — девушки и женщины;
• более 15 миллионов новых записей в блогах за месяц;
• более 50 миллионов просмотров страниц в день, при пиковой нагрузке — несколько тысяч в секунду (сильно устаревшие цифры, 2004 год);
• связь с внешним миром осуществляется через два BIG-IP (активный + в режиме ожидания) с автоматическим восстановлением работоспособности в случае сбоя в работе одного из них, защитой от DDoS, L7 набором правил, включая TCL;
• более сотни серверов, насчет конфигурации известен только тот факт, что практически на каждом сервере установлены огромные объемы оперативной памяти (более 12 GB) для эффективного кэширования.

История

• Все началось с одного обычного сервера. Он выполнял роль как веб-сервера так и базы данных. Единственный плюс такого подхода к организации работы оборудования — достаточно дешево. Само собой достаточно скоро этот сервер перестал справляться с нагрузкой.
• Следующим шагом было разнесение веб-сервера и базы данных на разные серверы, всего их получилось два. По прежнему имелось два узла, сбой в которых означал недоступность сервиса. По прежнему вычислительная мощность такой системы оставалась более чем скромной.
• Первым из тех двух серверов, как ни странно, перестал справляться с нагрузкой веб-сервер — докупили еще два. Веб-сервера три, внешний IP — один, теперь приходится как-то распределять нагрузку! А как добавить еще одну базу данных?
• Новый сервер баз данных был подключен в роли slave к исходному, данные в нем обновлялись с помощью репликации, а обрабатывал он только операции чтения, оставив все операции записи первому серверу.
• Есть предположения о том, к чему привело дальнейшее добавление новых серверов? Правильно — к полнейшему хаосу! Со временем стала возникать проблема масштабируемости баз данных. Операции чтения производились на каком-то одном сервере, но когда приходил запрос на запись данных, так или иначе данные приходилось производить обновление на каждом из slave серверов. В итоге выполнение синхронизации данных стало занимать подавляющее большинство процессорного времени slave серверов, что привело к отсутствию возможности продолжать масштабирование просто добавлением дополнительных серверов.
• Пришло время задуматься над архитектурой системы и распределением операций записи. Основной целью стало избавиться от такой серьезной избыточности данных, так как это было практически пустой тратой времени копировать одни и те же данные на десяток машин, да еще и с RAID на каждой из них.
• Наиболее эффективным подходом в такой ситуации является сегментирование базы данных. Все серверы баз данных разбиваются на небольшие кластеры. Каждый пользователь системы прозрачно привязывается к определенному кластеру, таким образом когда он обновляет свой блог или какие-либо еще данные, запись ведется в рамках только небольшой группы серверов, такой же принцип справедлив и для чтения.

  Применительно к LiveJournal эту схему лучше всего демонстрирует один из слайдов презентации, указанной в источниках информации:
  

  При работе такой системы не используется auto_increment в MySQL, а также используется составной primary key из номера пользователя и номера записи. Таким образом пространство имен объектов разбито на группы, соответствующие конкретному пользователю.

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

Программное обеспечение

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

memcached

Залогом быстрой загрузки любой страницы крупного интернет-проекта является кэширование. Но как всегда возникает вопрос: а на каком уровне обработки данных его стоит выполнять? Для динамических страниц недопустимо кэширование на уровне готовых страниц. Можно кэшировать на уровне mod_perl, но по сути это пустая трата оперативной памяти, так как создастся отдельный кэш для каждого потока Apache, и количество промахов мимо кэша будет огромно. Кэширование запросов MySQL или HEAP таблицы также не дали бы требуемого результата ввиду чрезвычайной распределенности базы данных.

Выходом из сложившейся ситуации стало написание собственной распределенной системы кэширования объектов, получившей название memcached. Она позволяет:

• использовать для кэширования свободную оперативную память практически любого компьютера, задействованного в системе;
• кэшировать объекты практически любого языка программирования в сериализованном виде: Perl, PHP, Java, C++ и так далее;
• использовать для передачи кэшируемых данных простой протокол, не требующий избыточности данных;
• избегать даже теоретической возможности полного сбоя работы кэшируещей системы в связи с полной равнозначностью серверов;
• достигать превосходной производительности при формировании HTML-кода страниц;
• в разы снизить нагрузку на базы данных в проекте любого масштаба.

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

Perlbal

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

• быстрый;
• небольшой размер;
• «сообразительный»;
• обработка «мертвых» узлов;
• может выступать как в роли reverse proxy, так и балансировщика нагрузки;
• базовый функционал классического веб-сервера;
• реализация внутреннего перенаправления данных;
• поддержка некоторых менее существенных трюков, реализованных обычно в виде plug-in’ов.

Perlbal не так активно используется вне LiveJournal, по сравнению с memcached, но для решения конкретной задачи он подошел как нельзя лучше.

MogileFS

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

Как и все файловые системы этого класса, MogileFS работает на уровне пользовательских приложений и использует достаточно тривиальные протокол передачи данных и общую архитектуру: клиенты, управляющие серверы, абстрактные базы данных, сервера для хранения самих данных — в этом плане ничего нового придумано не было. Доступ к файлам осуществляется с помощью HTTP-запросов PUT/GET либо через виртуальный NFS-раздел. Единственной особенностью можно назвать уклон в построение собой абстрактной прослойки между приложением и собственно кластером базы данных (в случае LiveJournal — сегмента), используемой в роли альтернативы более тривиальной master/slave схемы.

Gearman

Gearman по сути прост до безобразия, но это не мешает ему быть чрезвычайно эффективным. Возможно Вы уже догадались в чем суть этого еще одного продукта, написанного специально для LJ, если уже навели курсор на акроним в начале этого абзаца, если же нет — поясню: он управляет общей работой системы средствами клиент-серверной архитектуры и высокопроизводительного бинарного протокола. С их помощью он способен удаленно вызывать практически любые процедуры на удаленных серверах с минимальными задержками во времени. Казалось бы ничего особенного он сам по себе не делает, но на самом деле он выполняет очень важную функцию: увеличивает степень параллельности выполнения операций, необходимых для полноценного функционирования проекта. Единственное но в работе этого механизма заключается в том, что он не предоставляет никаких гарантий успешности выполнения работ.

В рамках LiveJournal Gearman применяется в основном для:

• обработка изображений средствами Image::Magick вне perl-приложений;
• создание pool’а DBI соединений (DBD::Gofer + Gearman);
• уменьшением нагрузки, создаваемой отдельными компонентами системы;
• улучшения субъективного впечатления пользователей о быстродействии сервиса, благодаря выполнению части работ параллельно в фоновом режиме;
• выполнение блокирующего ресурсы кода отдельно от обработчиков различных событий.

TheShwartz

В качестве альтернативы gearman’у для работ, для выполнения которых необходимы некоторые гарантии успешности, а также некоторая стабильность, была разработана эта библиотека. Общая схема работы осталась та же: клиент-серверная, но за стабильность приходится платить — производительность существенно ниже, возможно возникновение задержек.

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

Основными сферами применения TheShwartz в LJ являются:

• отправка электронной почты (SMTP клиент);
• LJ Notifications: каждое событие может вызывать за собой цепочку из тысяч уведомлений по электронной почте, SMS, XMPP и так далее;
• отправка RPC сообщений внешним сервисам;
• внедрение Atom потоков;

djabberd

Как всегда следуя принципу «чем проще — тем лучше», разработки LJ написали этот крошечный daemon, лежащий в основе их Jabber/LJTalk. Он способен спокойно работать с более чем 300 тысячами соединений, используя очень скромное количество оперативной памяти для поддержания каждого соединения.

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

Подводим итоги

• Если перед Вами появилась нетривиальная задача — не бойтесь написать программное обеспечение для ее решения самостоятельно! Пускай, возможно, это потребует некторых дополнительных усилий, но масса преимуществ, связанных с полным соответствием требованиям конкретного проекта, превосходит все издержки дополнительной разработки.
• Невозможно масштабировать проект просто постоянно добавляя новые сервера, рано или поздно все же прийдется задуматься об его архитектуре;
• Распределение нагрузок и параллельное операций порой заслуживают того, чтобы разработчики обратили на них внимание;
• «Мы ненавидим изобретать колесо! Но тем не менее, если колесо не существует или оно квадратное, то мы не боимся изобретать круглое колесо.» (с)

Оформлена она в виде классического daemon‘а, слушающего подключения на одном из TCP-портов (по-умолчанию: 11211). Работа же с ним осуществляется с помощью клиентских библиотек, доступных практически для всех популярных языков программирования.

memcached не использует конфигурационные файлы, но все же может быть в какой-то степени настроен под свои нужды с помощью параметров, указываемых при запуске daemon‘а, и переменных окружения. Например, часто используется параметр -m, позволяющий указать объем используемой для хранения объектов оперативной памяти.
По сути кэширование с помощью memcached представляет собой некое подобие глобального ассоциативного массива, то есть набора соответствий ключ → объект.

Как же оно работает?

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

• set — установить соответствие между ключом и указанным объектом;
• add — аналогично set, но только при условии, что объекта с таким ключом в кэше нет;
• replace — абсолютная противоположность add, выполняется только если такой объект в кэше есть;
• get — получить объект из кэша по указанному ключу.

Вывод напрашивается лишь один: проще не придумаешь.

В сравнении

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

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

На практике

Использование memcached на практике в написании приложений ничуть не сложнее, чем в теории. Например, если говорить о PHP, то для доступа к daemon‘y достаточно установить соответствующий PECL extension, который предоставит класс Memcached. С помощью его методов осуществляется доступ ко всем возможностям memcached, о которых я уже упоминал: connect, set, add, get и так далее.

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

О чем не стоит забывать

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

В заключении

…хотелось бы сказать, что эта технология является очень производительным и эффективным решением вопроса кэширования для масштабных интернет-проектов. Возможности по ее применению не ограничиваются Сетью, ведь она реализована в виде обычного daemon’а, что открывает ее для всего спектра программного обеспечения, так или иначе следующего «Unix way».

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

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

Предистория

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

Ассортимент оборудования, спрятанного внутри 1U корпуса, был вполне стандартным, ничего особенного: процессор Intel Xeon 5335, оперативная память Kingston 2х2 GB ECC Full-buffered, жесткий диск изначально только один — WD 150 GB 10000rpm SATA, а вот модель материнской платы, к сожалению, на память назвать не могу, вроде что-то от SuperMicro, с простенькой встроенной видеокартой, сетевой картой с двумя гигабитными Ethernet портами и встроенным же видимо software RAID-контроллером. Опытный глаз наверняка заметил бы в этом списке сильную недоукомплектацию, особенно проявляющуюся при упоминании процессора в единственном числе, отсутствии RAID, и скромным объемам оперативной памяти. Объясняется это достаточно просто — проект еще предстоит тестировать перед запуском, а этой платформы для этого будет более чем достаточно.

Перед запуском проекта в открытое плавание естественно предстоит upgrade оборудования.

День первый

Подготовка

Если верить бумажкам, идущим в комплекте с сервером, на единственный жестком диск в магазине установили демо-версию одной из серверных операционных систем от одной мало кому известной корпорации. Смотреть что это за зверь такой у меня особого желания не было, по-этому я не долго думая пошел искать среди своей коллекции дистрибутивов болванку с заранее выбранным opensource решением вопроса об операционной системе — FreeBSD 6.2.

Почему выбор пал именно на эту ОС объяснить не так уж и просто, но я все же попробую. Выбор был достаточно классический: Unix vs Linux, возникали еще некоторые сомнения насчет решений от Sun в виде Solaris и OpenSolaris, но от них я отказался достаточно быстро в основном из-за более чем скромной документации и проприетарного происхождения, попутно закрыв глаза на все положительные отзывы, которые я видел в Сети.

Так как мне хотелось иметь иметь перед собой конструктор для сбора системы именно таким образом, как было бы удобно мне, а не разработчикам дистрибутива, то список вариантов, выступавших на стороне Linux быстро начал сокращаться, начиная с CentOS. Предпоследним вычеркнутым из списка дистрибутивов Linux был Debian, что оставило в нем лишь Gentoo Linux. Финальный выбор между FreeBSD и Gentoo был сделан уже легче: во-первых, по своему опыту с ноутбуком я уже понял, что с Gentoo предстояло бы немало хлопот, а, во-вторых, в новый конструктор, как ни крути, «играть» намного интереснее, чем в старый, так что долго думать не пришлось

Установка

Найдя наконец диск с FreeBSD, я попытался решить следующий возникший вопрос: а как же установить операционную систему с компакт-диска на компьютер, не имеющий соответствующего привода? Так как сервер был запломбирован и находился на гарантии, вариант частично разобрать и подключить обычный привод отпал сразу же, ровно как и вариант с подключением внешнего привода по причине его отсутствия. Подходящее решение было найдено практически сразу же, благо жесткие диски подключались по принципу hotswap: вытащив жесткий диск без развинчивания корпуса, я подключил его к подвернувшемуся под руку настольному компьютеру, обладающему DVD-приводом. Загрузка прошла успешно и я приступил к установке, руководствуясь FreeBSD Handbook, пересказывать его особого желания у меня нет, остановлюсь лишь на некоторых особенностях этого процесса.

Первым этапом установки, где пришлось задуматься, был fdisk (разбиение диска на так называемые slice). Для избежания путаницы для самого себя, я решил, что размещу рабочие директории http-сервера и базы данных в /var, которую и выделил в отдельный slice, занимающий большую часть доступного дискового пространства. В ассортимент доступного при установке программного обеспечения я особо вникать не стал, так как знал, что у меня всегда будет возможность заняться им позже, и как следствие этого выбрал что-то очень близкое к стандартному набору ПО.
Подтвердив установку и подождав достаточно непродолжительный период времени, я перезагрузил систему, вытащив установочный диск в процессе. Установка оказалась на удивление элементарной, что привело к полученной с первой попытки работоспособной системе. Увидев долгожданное приглашение к вводу логина и пароля я убедился, что могу беспрепятственно получить доступ к консоли и сразу же выключил систему, чтобы перенести жесткий диск обратно на сервер.

Так как сетевое подключение еще только предстояло настроить, то на сервер переносить пришлось не только жесткий диск, но и монитор с клавиатурой. На новом оборудовании все так же прекрасно запустилось, и я принялся за настройку подключения. Особых проблем не возникло — в Handbook‘е все более чем качественно задокументировано, самым сложным был процесс выбора драйвера, вернее осознавание того, что он изначально правильно сам установился. Следующей маленькой проблемой было угадывание какой же из Ethernet-портов был только что настроен, и, соответственно, подключение кабеля именно в него, а не в его соседа. После завершения всех манипуляций я с радостью обнаружил, что ping от сервера до gateway’а успешно проходит, что по сути и означало окончание настройки сетевого подключения.
Следущей целью было избавить себя от необходимости пользоваться позаимствованными у другого компьютера клавиатурой и монитором. Дело тоже оказалось достаточно нехитрым, sshd установился и настроился вполне самостоятельно где-то в процессе установки, от меня потребовалось лишь создать дополнительного пользователя, написать нехитрую строчку в rc.conf: sshd_enable=»YES» и собственно запустить daemon’а. Этого было вполне достаточно, чтобы набрав на своем ноутбуке ssh в консоли, с указанием необходимых параметров, получить удаленный доступ к серверу по протоколу SSH.

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

День второй

Программное обеспечение

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

Прежде чем что-либо устанавливать, очень не пожалел, что ознакомился как с соответствующим разделом handbook’a, так и с доступным ассортиментом ПО. После этого я перешел-таки собственно к выбору и установке ПО:

• Так как одной из основных составных частей практически любого веб-сервера является http-daemon, именно с его выбора я и решил начать. Причем начал еще задолго до описываемых событий, вся многофункциональность Apache мне была не нужна, а аналоги mod_auth и mod_rewrite есть и в более легких http-серверах. Cамо веб-приложение, которое там предполагалось располагать, работает по большей части на PHP, так что ничего особенного от httpd совсем не требовалось. В итоге финальный выбор был между быстрыми и легкими вариантами: nginx и lighttpd, какой-либо весомой причины по которой я выбрал lighttpd с mod_fastcgi привести не могу, основным фактором был мой некоторый опыт работы с ним в прошлом, и отсутствие такового в отношении nginx. Установка прошла легко и непринужденно с помощью в сжатые сроки найденного в Google мануала.
• Другим немаловажным компонентом сервера является ftpd, как известно используемый для передачи файлов. Собственно говоря, если активное его использование не планируется, то особого значения какой именно сервер будет использоваться значения не имеет: любой из доступных устанавливается настраивается в пару простых шагов без каких-либо проблем (если это имеет значение — я выбрал vsftpd, так как мне уже далеко не один раз доводилось его настраивать на домашних компьютерах, и, как следствие, даже инструкция не понадобилась). Но при потенциальной возможности работы через Интернет, этот протокол является достаточно уязвимым, так как не использует никакого шифрования. Эта проблема решается с помощью механизма FTP over SSH, который представляет собой использование SSH в роли туннеля для передачи файлов по FTP. О том, как воспользоваться этим механизмом вам подскажет man ssh, какой-либо дополнительной конфигурации он не требует, разве что настройки соответствующим образом firewall’а, но об этом я расскажу позже.
• Сам PHP установлен последней доступной в ports версии и , как уже упоминалось, был подключен к lighttpd с помощью mod_fastcgi, какой-либо дополнительной конфигурации с моей стороны не потребовалось, я разве что выбрал список модулей (в общем-то тоже занятие не сложное, достаточно лишь осознавать какие именно используются, плюс я еще решил Suhosin установить) и просто просмотрел по диагонали все конфиги (в основном сам php.ini и lighttpd.conf) на предмет их соответствия потребностям моего приложения. Отдельная история возникла с лишь одним модулем — Blitz, который на данный момент все еще отсутствует в репозиториях как FreeBSD, так и подавляющего большинства (если не всех) дистрибутивов Linux. Его пришлось устанавливать вручную из исходников по соответствующему мануалу, что правда тоже дело не хитрое и заняло всего несколько минут.
• СУБД особо выбирать не пришлось — приложение написано было с расчетом на PostrgeSQL, ее соответственно и прикручивал к PHP. Этот этап был пожалуй одним из самых проблематичных, так как сразу после классического make install clean соответствующий daemon запускаться отказался. Какого-либо осознанного сообщения об ошибке /usr/local/etc/rc.d/postgresqld start не выводило как в консоль, так и в логи, но тем не менее консольный клиент psql и само веб-приложение жаловались на отсутствие запущенной СУБД. Этот факт сильно затруднял поиск возможных вариантов решения на просторах Сети, так что не найдя ничего полезного я решил заняться диагностикой проблемы и поиском решения для нее самостоятельно. Методом проб и ошибок, перебрав множество возможных вариантов запуска daemon’а, я пришел к выводу, что у пользователя от имени которого он должен был запускаться явно проблемы с доступом к файловой системе. Видимо так получилось из-за нестандартного расположения самой базы данных — в директории /var. Не смотря на тот факт, что chown и chmod были использованы по прямому назначению в отношении соответствующих директорий для установления прав доступа. В итоге оказалось, что директория указанная для этого пользователя как домашняя (по памяти пишу, могу ошибиться, но вроде /usr/local/pgsql) по каким-то причинам не создалась и соответственно именно этот факт и мешал запуску daemon’а. Восстановив справедливость в отношении этого пользователя, я обнаружил, что PostrgeSQL успешно запустился-таки, а мое приложение тоже стало функционировать именно так, как ему было положено. Проверив содержимое соответствующего конфига, я решил его больше не трогать, а то как говорится «premature optimization is the root of all evil»&copyright;. За компанию решил установить веб-интерфейс к PostrgeSQL — phppgadmin. Собравшись из портов, он повел себя как-то не очень адекватно, совсем не так каким я привык его видеть у себя на ноутбуке, разбираться в причинах было не охота — простое копирование и замена соответствующей директории по ftp буквально за минуту решило проблему.
• Вариантов фильтров сетевого трафика в FreeBSD имеется предостаточно: pf, ipf, ipfw. Опыта работы ни с одним из них у меня не было, так что выбор происходил из достаточно субъективных критериев — очевидности принципов работы правил и достаточности документации. Так как я был уверен, что каждый из них сможет обеспечить достаточный уровень безопасности, основываясь на указанных выше критериях в итоге я выбрал ipf. Документация позволила легко и непринужденно все установить и настроить, правда за компанию пришлось разбираться и с пересборкой ядра. В качестве базы для построения собственного списка правил я использовал приведенный все там же, в документации, пример. Само собой пришлось доработать его под конкретную систему, но методом проб и ошибок эта задача выполняется достаточно быстро (будте осторожны с 22 портом, используемым для SSH — очень легко на этом этапе случайно заблокировать самому себе доступ к серверу). Получившийся в итоге список правил приводить не буду, так как его еще предстоит довести до ума на активно работающей системе.

Заключение

Не прошло и двух дней, как из простого набора оборудования получился вполне готовый к работе веб-сервер, конечно же доводить до ума его придется еще достаточно долго, но просто стабильно работать он был в состоянии уже тогда. Дальше его отвезли в место постоянного его прибывания, подключили к более-менее приличному интернет-каналу, с моей стороны при этом потребовалось лишь слегка поменять настройки сетевого подключения, и вот — он уже доступен из Сети. Практически сразу же обнаружился один мой недочет в плане выбора ПО — буквально в первую же ночь после открытия публичного доступа к серверу нашлась масса желающих попытаться подобрать по словарю логин и пароль для доступа к серверу по SSH, но он был открыт лишь для одной учетной записи, у которой было мягко говоря нестандартное имя пользователя, даже его никто за ночь не смог угадать, а до более чем 20-символьного пароля дело так и не дошло. На следующее утро я, не долго думая, установил программу под названием sshguard, которая сразу же предотвратила все последующие попытки подобным образом издеваться над сервером. Дальше надо было настроить запись на DNS-сервере для ассоциации домена с IP нашего сервера, настроить почту, закончить работу над самим веб-приложением и много чего еще, но это уже совсем другая история.

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

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

Предистория

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

Ассортимент оборудования, спрятанного внутри 1U корпуса, был вполне стандартным, ничего особенного: процессор Intel Xeon 5335, оперативная память Kingston 2х2 GB ECC Full-buffered, жесткий диск изначально только один — WD 150 GB 10000rpm SATA, а вот модель материнской платы, к сожалению, на память назвать не могу, вроде что-то от SuperMicro, с простенькой встроенной видеокартой, сетевой картой с двумя гигабитными Ethernet портами и встроенным же видимо software RAID-контроллером. Опытный глаз наверняка заметил бы в этом списке сильную недоукомплектацию, особенно проявляющуюся при упоминании процессора в единственном числе, отсутствии RAID, и скромным объемам оперативной памяти. Объясняется это достаточно просто — проект еще предстоит тестировать перед запуском, а этой платформы для этого будет более чем достаточно.

Перед запуском проекта в открытое плавание естественно предстоит upgrade оборудования.

День первый

Подготовка

Если верить бумажкам, идущим в комплекте с сервером, на единственный жестком диск в магазине установили демо-версию одной из серверных операционных систем от одной мало кому известной корпорации. Смотреть что это за зверь такой у меня особого желания не было, по-этому я не долго думая пошел искать среди своей коллекции дистрибутивов болванку с заранее выбранным opensource решением вопроса об операционной системе — FreeBSD 6.2.

Почему выбор пал именно на эту ОС объяснить не так уж и просто, но я все же попробую. Выбор был достаточно классический: Unix vs Linux, возникали еще некоторые сомнения насчет решений от Sun в виде Solaris и OpenSolaris, но от них я отказался достаточно быстро в основном из-за более чем скромной документации и проприетарного происхождения, попутно закрыв глаза на все положительные отзывы, которые я видел в Сети.

Так как мне хотелось иметь иметь перед собой конструктор для сбора системы именно таким образом, как было бы удобно мне, а не разработчикам дистрибутива, то список вариантов, выступавших на стороне Linux быстро начал сокращаться, начиная с CentOS. Предпоследним вычеркнутым из списка дистрибутивов Linux был Debian, что оставило в нем лишь Gentoo Linux. Финальный выбор между FreeBSD и Gentoo был сделан уже легче: во-первых, по своему опыту с ноутбуком я уже понял, что с Gentoo предстояло бы немало хлопот, а, во-вторых, в новый конструктор, как ни крути, «играть» намного интереснее, чем в старый, так что долго думать не пришлось

Установка

Найдя наконец диск с FreeBSD, я попытался решить следующий возникший вопрос: а как же установить операционную систему с компакт-диска на компьютер, не имеющий соответствующего привода? Так как сервер был запломбирован и находился на гарантии, вариант частично разобрать и подключить обычный привод отпал сразу же, ровно как и вариант с подключением внешнего привода по причине его отсутствия. Подходящее решение было найдено практически сразу же, благо жесткие диски подключались по принципу hotswap: вытащив жесткий диск без развинчивания корпуса, я подключил его к подвернувшемуся под руку настольному компьютеру, обладающему DVD-приводом. Загрузка прошла успешно и я приступил к установке, руководствуясь FreeBSD Handbook, пересказывать его особого желания у меня нет, остановлюсь лишь на некоторых особенностях этого процесса.

Первым этапом установки, где пришлось задуматься, был fdisk (разбиение диска на так называемые slice). Для избежания путаницы для самого себя, я решил, что размещу рабочие директории http-сервера и базы данных в /var, которую и выделил в отдельный slice, занимающий большую часть доступного дискового пространства. В ассортимент доступного при установке программного обеспечения я особо вникать не стал, так как знал, что у меня всегда будет возможность заняться им позже, и как следствие этого выбрал что-то очень близкое к стандартному набору ПО.
Подтвердив установку и подождав достаточно непродолжительный период времени, я перезагрузил систему, вытащив установочный диск в процессе. Установка оказалась на удивление элементарной, что привело к полученной с первой попытки работоспособной системе. Увидев долгожданное приглашение к вводу логина и пароля я убедился, что могу беспрепятственно получить доступ к консоли и сразу же выключил систему, чтобы перенести жесткий диск обратно на сервер.

Так как сетевое подключение еще только предстояло настроить, то на сервер переносить пришлось не только жесткий диск, но и монитор с клавиатурой. На новом оборудовании все так же прекрасно запустилось, и я принялся за настройку подключения. Особых проблем не возникло — в Handbook‘е все более чем качественно задокументировано, самым сложным был процесс выбора драйвера, вернее осознавание того, что он изначально правильно сам установился. Следующей маленькой проблемой было угадывание какой же из Ethernet-портов был только что настроен, и, соответственно, подключение кабеля именно в него, а не в его соседа. После завершения всех манипуляций я с радостью обнаружил, что ping от сервера до gateway’а успешно проходит, что по сути и означало окончание настройки сетевого подключения.
Следущей целью было избавить себя от необходимости пользоваться позаимствованными у другого компьютера клавиатурой и монитором. Дело тоже оказалось достаточно нехитрым, sshd установился и настроился вполне самостоятельно где-то в процессе установки, от меня потребовалось лишь создать дополнительного пользователя, написать нехитрую строчку в rc.conf: sshd_enable=»YES» и собственно запустить daemon’а. Этого было вполне достаточно, чтобы набрав на своем ноутбуке ssh в консоли, с указанием необходимых параметров, получить удаленный доступ к серверу по протоколу SSH.

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

День второй

Программное обеспечение

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

Прежде чем что-либо устанавливать, очень не пожалел, что ознакомился как с соответствующим разделом handbook’a, так и с доступным ассортиментом ПО. После этого я перешел-таки собственно к выбору и установке ПО:

• Так как одной из основных составных частей практически любого веб-сервера является http-daemon, именно с его выбора я и решил начать. Причем начал еще задолго до описываемых событий, вся многофункциональность Apache мне была не нужна, а аналоги mod_auth и mod_rewrite есть и в более легких http-серверах. Cамо веб-приложение, которое там предполагалось располагать, работает по большей части на PHP, так что ничего особенного от httpd совсем не требовалось. В итоге финальный выбор был между быстрыми и легкими вариантами: nginx и lighttpd, какой-либо весомой причины по которой я выбрал lighttpd с mod_fastcgi привести не могу, основным фактором был мой некоторый опыт работы с ним в прошлом, и отсутствие такового в отношении nginx. Установка прошла легко и непринужденно с помощью в сжатые сроки найденного в Google мануала.
• Другим немаловажным компонентом сервера является ftpd, как известно используемый для передачи файлов. Собственно говоря, если активное его использование не планируется, то особого значения какой именно сервер будет использоваться значения не имеет: любой из доступных устанавливается настраивается в пару простых шагов без каких-либо проблем (если это имеет значение — я выбрал vsftpd, так как мне уже далеко не один раз доводилось его настраивать на домашних компьютерах, и, как следствие, даже инструкция не понадобилась). Но при потенциальной возможности работы через Интернет, этот протокол является достаточно уязвимым, так как не использует никакого шифрования. Эта проблема решается с помощью механизма FTP over SSH, который представляет собой использование SSH в роли туннеля для передачи файлов по FTP. О том, как воспользоваться этим механизмом вам подскажет man ssh, какой-либо дополнительной конфигурации он не требует, разве что настройки соответствующим образом firewall’а, но об этом я расскажу позже.
• Сам PHP установлен последней доступной в ports версии и , как уже упоминалось, был подключен к lighttpd с помощью mod_fastcgi, какой-либо дополнительной конфигурации с моей стороны не потребовалось, я разве что выбрал список модулей (в общем-то тоже занятие не сложное, достаточно лишь осознавать какие именно используются, плюс я еще решил Suhosin установить) и просто просмотрел по диагонали все конфиги (в основном сам php.ini и lighttpd.conf) на предмет их соответствия потребностям моего приложения. Отдельная история возникла с лишь одним модулем — Blitz, который на данный момент все еще отсутствует в репозиториях как FreeBSD, так и подавляющего большинства (если не всех) дистрибутивов Linux. Его пришлось устанавливать вручную из исходников по соответствующему мануалу, что правда тоже дело не хитрое и заняло всего несколько минут.
• СУБД особо выбирать не пришлось — приложение написано было с расчетом на PostrgeSQL, ее соответственно и прикручивал к PHP. Этот этап был пожалуй одним из самых проблематичных, так как сразу после классического make install clean соответствующий daemon запускаться отказался. Какого-либо осознанного сообщения об ошибке /usr/local/etc/rc.d/postgresqld start не выводило как в консоль, так и в логи, но тем не менее консольный клиент psql и само веб-приложение жаловались на отсутствие запущенной СУБД. Этот факт сильно затруднял поиск возможных вариантов решения на просторах Сети, так что не найдя ничего полезного я решил заняться диагностикой проблемы и поиском решения для нее самостоятельно. Методом проб и ошибок, перебрав множество возможных вариантов запуска daemon’а, я пришел к выводу, что у пользователя от имени которого он должен был запускаться явно проблемы с доступом к файловой системе. Видимо так получилось из-за нестандартного расположения самой базы данных — в директории /var. Не смотря на тот факт, что chown и chmod были использованы по прямому назначению в отношении соответствующих директорий для установления прав доступа. В итоге оказалось, что директория указанная для этого пользователя как домашняя (по памяти пишу, могу ошибиться, но вроде /usr/local/pgsql) по каким-то причинам не создалась и соответственно именно этот факт и мешал запуску daemon’а. Восстановив справедливость в отношении этого пользователя, я обнаружил, что PostrgeSQL успешно запустился-таки, а мое приложение тоже стало функционировать именно так, как ему было положено. Проверив содержимое соответствующего конфига, я решил его больше не трогать, а то как говорится «premature optimization is the root of all evil»&copyright;. За компанию решил установить веб-интерфейс к PostrgeSQL — phppgadmin. Собравшись из портов, он повел себя как-то не очень адекватно, совсем не так каким я привык его видеть у себя на ноутбуке, разбираться в причинах было не охота — простое копирование и замена соответствующей директории по ftp буквально за минуту решило проблему.
• Вариантов фильтров сетевого трафика в FreeBSD имеется предостаточно: pf, ipf, ipfw. Опыта работы ни с одним из них у меня не было, так что выбор происходил из достаточно субъективных критериев — очевидности принципов работы правил и достаточности документации. Так как я был уверен, что каждый из них сможет обеспечить достаточный уровень безопасности, основываясь на указанных выше критериях в итоге я выбрал ipf. Документация позволила легко и непринужденно все установить и настроить, правда за компанию пришлось разбираться и с пересборкой ядра. В качестве базы для построения собственного списка правил я использовал приведенный все там же, в документации, пример. Само собой пришлось доработать его под конкретную систему, но методом проб и ошибок эта задача выполняется достаточно быстро (будте осторожны с 22 портом, используемым для SSH — очень легко на этом этапе случайно заблокировать самому себе доступ к серверу). Получившийся в итоге список правил приводить не буду, так как его еще предстоит довести до ума на активно работающей системе.

Заключение

Не прошло и двух дней, как из простого набора оборудования получился вполне готовый к работе веб-сервер, конечно же доводить до ума его придется еще достаточно долго, но просто стабильно работать он был в состоянии уже тогда. Дальше его отвезли в место постоянного его прибывания, подключили к более-менее приличному интернет-каналу, с моей стороны при этом потребовалось лишь слегка поменять настройки сетевого подключения, и вот — он уже доступен из Сети. Практически сразу же обнаружился один мой недочет в плане выбора ПО — буквально в первую же ночь после открытия публичного доступа к серверу нашлась масса желающих попытаться подобрать по словарю логин и пароль для доступа к серверу по SSH, но он был открыт лишь для одной учетной записи, у которой было мягко говоря нестандартное имя пользователя, даже его никто за ночь не смог угадать, а до более чем 20-символьного пароля дело так и не дошло. На следующее утро я, не долго думая, установил программу под названием sshguard, которая сразу же предотвратила все последующие попытки подобным образом издеваться над сервером. Дальше надо было настроить запись на DNS-сервере для ассоциации домена с IP нашего сервера, настроить почту, закончить работу над самим веб-приложением и много чего еще, но это уже совсем другая история.

Вчера вечером, решив провести очередное обновление программного обеспечения, я обнаружил в списке замаскированных пакетов внушительное количество заветных цифр 4.0.0. Не долго думая все эти пакеты были отправлены в комментарии с целью разрешить их установку, а на ночь компьютер был оставлен включенным с указанием к утру предоставить мне рабочую версию KDE 4. И, как ни странно, с заданием он справился более чем успешно!

На утро если честно был слегка удивлен. увидев сообщение в консоли о том, что пакет kde-base/kdebase-meta-4.0.0 установлен успешно. Запустив по привычке etc-update и сделав на всякий случай backup настроек третьего KDE, я приступил к запуску свежеустановленного рабочего окружения.

Процесс оказался простым до безобразия, достаточно было лишь сменить тип сессии в kdm, и рабочее окружение успешно загрузилось. Представшее передо мной зрелище меня ничуть не удивило — мне уже доводилось собирать beta-версию KDE 4 из SVN, да и screenshot’ы стандартного рабочего окружения KDE я видел далеко не один раз.

Первым делом я решил запустить Kopete, реально конечно из-за того, что перед завершением сеанса работы с третьим KDE мне кто-то успел написать в ICQ, и меня ждал неоконченный разговор, но посмотреть как он изменился со времен беты тоже хотелось. Попытавшись зайти с его помощью в ICQ, я обнаружил что этого протокола в списке доступных нет, причина нашлась быстро с помощью консоли (которая изменений практически не претерпела) — kopete по-умолчанию был собран без флага oscar. Не долго думая, по-быстрому пересобрал клиент, но в ходе указания настроек account’а он мне заявил, что ему нужен еще и KWallet для хранения пароля. Отправив на сборку и его, я решил временно отложить повторное знакомство с kopete и запустил Pidgin, которым достаточно часто пользуюсь.

После решения вопроса со связью, я отправился на изучения остальных пунктов KMenu, ничего принципиально нового я там не нашел, но решил все же заглянуть в пункт под названием System Settings с целью сделать небольшой обзор доступных настроек и оценить потенциал нового рабочего рабочего окружения в плане «доработки напильником», чем я и планирую в обозримом будущем заняться. Большую часть интересных для меня настроек я нашел прямо в GUI, а если бы не поленился покопаться в конфигурационных файлах — нашел бы и все остальное.

Plasma — по-моему одно из самых существенных изменений в новой версии KDE, в котором невооруженным глазом можно увидеть огромный потенциал для развития пользовательских интерфейсов. Но если сейчас смотреть на эту технологию как обычный пользователь, то можно увидеть во всех эти widget’ах лишь недоделанность, неудобство и непривычность. В будущем, когда ассортимент и качество «плазмоидов» приумножится, эта технология станет очень гибкой и удобной в повседневном использовании для очень разнообразного спектра задач.

Самым большим недостатком доступной на данный момент версии KDE, на мой взгляд, является та самая черная панель внизу экрана, которая используется для размещения любых виджетов наравне с рабочим столом, но имеет один большой недостаток — практически полное отсутствие каких-либо настроек (за исключением непонятно зачем и кому нужного «Show tooltips»), и как следствие, отсутствие элементарных способов ее переместить или изменить в размерах. Именно из-за этого факта я сейчас и пишу снова из KDE 3.5.8, так как я слишком привык получать доступ ко всем функциям рабочего окружения из верхней части экрана, а переучиваться или искать какие-либо нестандартные решения этой небольшой проблемки на данный момент нет ни времени, ни желания.

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

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

Gentoo is all about choices

Абсолютно не важно, держите ли Вы в руках блестящую болванку с надписью «Прощай, предустановленная Vista!» или только подумываете о том, чтобы избавить свой ноутбук от тяжести этой ноши. Прочитав это повествование, Вы сможете представить себе процесс установки альтернативной операционной системы на ноутбук на примере Gentoo Linux и Sony Vaio. Я постараюсь освятить все особенности этого процесса, а также по возможности дать советы по избежанию потенциальных проблем. Не надейтесь найти здесь пересказ Gentoo Handook, ее стоит прочитать в любом случае, если Вы на самом деле задумали установить эту очень серьезную операционную систему.

Сам я занимался этим делом уже более полугода назад на ноутбуке Sony Vaio VGN-FE41ZR, не знаю почему мой выбор в свое время пал именно на эту модель, были доступны и более производительные и «навороченные» — видимо приглянулась она мне чем-то. Далее речь пойдет именно об этой модели ноутбука, но думаю большая часть написанного далее будет справедлива и для других моделей линейки Sony Vaio. Поначалу процесс установки и настройки был очень непрост, ведь часто приходилось пользоваться методом «проб и ошибок», да и достойную документацию найти удавалось далеко не по каждому вопросу. Все про все заняло далеко не один мой летний вечер, терпения потребовалось изрядное количество, но полученный в итоге результат до сих пор не дает повода пожалеть о потраченном свободном времени.

Как я уже успел намекнуть во вступлении, начинается все с болванки на которую записан тот самый волшебный образ. Никто не мешает выбрать любой из доступных вариантов, но предположим, что выбор пал на Gentoo Linux LiveCD 2007.0. Загрузка ноутбука с этого диска проходит плавно и непринужденно, ровно как и сама работа с уже загруженным LiveCD как в консоли, так и в используемом там рабочем окружении — Gnome. Следуя инструкциям из настольной книги начать установку операционной системы очень нетрудно, но если честно у меня прочитав пару раз этот немаленьких размеров текст возникла мысль попытаться сэкономить некоторое количество времени, воспользовавшись услугами двух предложенных автоматических инсталляторов — с графическим и консольным пользовательским интерфейсом — не повторяйте этой ошибки, так как качество реализации обоих вариантов на данный момент оставляет желать лучшего, заставить успешно установить систему один из них может занять ничуть не меньше времени, чем ручная установка. Лично мне приручить ни один из автоматических инсталлятора так и не удалось, но как ни странно тоже не пришлось жалеть об этом факте — как оказалось ручная установка очень качественно позволяет разобраться в структуре операционной системы вцелом, ровно как и в принципе работы отдельных ее компонентов.

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

Ядро

Как известно, для Gentoo доступно несколько вариантов ядер, в процессе установки мой выбор пал на suspend2-sources, но со временем полностью перебрался на gentoo-sources, так как я понял, что сами suspend-to-ram и suspend-to-hdd мне абсолютно не нужны, но suspend2 слегка отстают от gentoo по версиям. Тем более, насколько я знаю, в современных версиях основной ветки ядра suspend тоже поддерживается на достойном уровне (но так как мне он не нужен — пробовать на собственном опыте не доводилось).

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

• Просто скопировать ядро с LiveCD. Этот вариант является самым простым в плане реализации, систему с его помощью запустить вполне реально — пробовал, но в плане производительности ему до идеала о-о-очень далеко.
• Собрать ядро с помощью genkernel и стандартной его конфигурации. Прочитав man genkernel это занятие тоже становится простым и привычным. Именно этот вариант я и выбрал в первый раз, слегка подредактировав конфигурационный файл с помощью ––menuconfig в тех местах, где был точно уверен что это не повлияет на функциональность и положительно повлияет на производительность. Естественно этот вариант тоже годится только на первое время.
• Ручная сборка классическим способом — make, с использованием конфигурационного файла, взятого с LiveCD. Чисто теоретически возможно, но не могу порекомендовать этот способ, при его реализации возникает существенно больше проблем, до конца решить которые мне так и не удалось в процессе установки, а в последующем как-то не возникало желания возвращаться к ручной сборке ядра, так как привык к genkernel — просто и удобно.
• Метод «проб и ошибок». Если есть желание и возможность потратить существенное количество времени на подбор оптимальной конфигурации ядра прямо в процессе установки — почему бы этим и не заняться?

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

Сеть

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

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

• Сетевая карта — Ethernet
• Беспроводная сеть — WiFi
• Старый-добрый модем

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

Ethernet

Воткнув заветный штекер RJ45 в соответствующий разъем, я с удивлением обнаружил с помощью команды ifconfig, что на этом мои телодвижения по получению доступа в Интернет благополучно закончились. Все драйвера оказались на месте, DHCP-клиент без моего вмешательства получил IP-адрес, все необходимые настройки по-умолчанию были выбраны верно — вобщем в этом плане все отлично.

Конечно далеко не у всех локальная сеть организована таким же образом, как и у меня, возможно придется поизучать man ifconfig‘а или повозиться с VPN-соединением.

WiFi

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

Попробовав несколько вариантов, мне удалось-таки установить беспроводное соединение с помощью драйвера под названием ipw3945 и сопутствующего ему daemon’а ipw3945d. Подробно весь процесс описывать не буду, я думаю при необходимости подробную инструкцию найти особого труда не составит.

Я еще не упоминал, что в качестве рабочего окружения предпочитаю использовать KDE, как-то с самого начала к нему привык, как внешне так и внутренне он меня более чем устраивает. Не сочтите предыдущее предложение за отступ от темы, я всеголишь хотел как-то объяснить переход к разговору об утилите, предоставляющей GUI к работе с беспроводными соединениями, — KWifiManager. Утилитка достаточно своеобразная, манера ее поведения поначалу сильно удивляла, но со временем привыкаешь. Особенно странно она производит выбор беспроводной сети, к которой подключаться. Не смотря на установленную в настройках мою домашнюю сеть, как сеть по-умолчанию, она все равно частенько пытается залезть к соседям или еще куда. И что самое интересное — вернуть ее на путь истинный ее же средствами мне обычно так и не удается. Из-за этого пришлось написать bash-скрипт, который помогает укратить эту утилиту. Включать в текст записи его особо желания нету, если кто хочет его заполучить: оставьте соответствующий комментарий — выложу.

Альтернатива консоли

Консоль — штука конечно полезная, но со временем пользоваться только ей на домашнем компьютере все же надоедает, хочется чего-то большего — например, компании состоящей из X-сервера, Xorg и какого-либо рабочего окружения (как я уже успел упомянуть — в его роли я предпочитаю использовать KDE, о нем и буду дальше говорить, но Ваш выбор это естественно ни капли не ограничивает).

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

Одно время конечно возникали некоторые трудности, например в одной из версий X-сервера была неприятная недоработка с LED’ами на клавиатуре — не было видно нажат ли Caps Lock, или при одной конкретной комбинации программного обеспечения и ядра системы по странному стечению обстоятельств частоиспользуемая клавиша F2 приводила к сворачиванию X-сервера и возвращению в консоль, что тоже доставляло массу неудобств. На данный же момент все проблемы такого рода решены руками огромного opensource-сообщества и все снова замечательно работает точно также как и полгода назад сразу после установки системы.

Через некоторое время после установки KDE мне все же захотелось привести его в более приятный моим глазам внешний вид. Вооружившись любимым графическим редактором под названием The GIMP я принялся за дело. В итоге получилось нечто странное, которое выглядит примерно вот так:

Видео

Используемый по-умолчанию видеодрайвер vesa оставляет желать лучшего, этот факт заметен сразу же после первой загрузки рабочего окружения, а значит ничего не остается кроме как искать ему замену. Искать долго не придется — отличный видеодрайвер для присутствующей в внутри этого ноутбука Nvidia GeForce 7600 легко доступен через Portage, называется он, как ни странно, nvidia-drivers.

Впечатления он оставляет только положительные: легко настраивается, достаточно производительный, поддерживает множество технологий, в том числе пресловутый Composite Extension в Xorg, который необходим для работы большинства (если не всех) трехмерных приложений.

Аудио

С ним все еще проще — достаточно лишь не забыть включить ALSA и Intel HD Audio в конфигурации ядра.

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

Bluetooth

Синий зуб прекрасно чувствует себя под руководством встроенного в ядра драйвера BlueZ, с работой в качестве GUI для работы с этим устройством также неплохо справляются KDE’шные утилиты KBluetooth и компания.

На роль помощника в тестировании и настройке bluetooth’а я не смог придумать ничего лучше, чем выбрать свой старенький телефон Qtek S200. Передача файлов заработала безукоризненно в обоих направлениях, а вот с использованием телефона в роли GPRS-модема пришлось изрядно повозиться: узнать необходимые настройки соединения на сайте оператора, найти хотябы примерно подходящую документацию по данному вопросу, настроить все как положено. Когда дело дошло до процесса дозвона по указанному номеру, телефон по каким-то причинам отказывался реагировать на запросы компьютера. Попытки понять в чем же причина длились достаточно долго, пока я не наткнулся в интернете на подробное техническое описание своего телефона, где было сказано, что он просто-напросто не поддерживает доступ у своему GPRS-модему через bluetooth-соединение. Узнав об этом факте я решил больше себя не мучать и бросил эту затею, но чисто технически с другим телефоном оно должно было заработать, но на практике проверить руки так до сих пор и не дошли.

Разные мелочи

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

Очень удивил меня тот факт, что для приведения к жизни различных нестандартных кнопок вроде регулировки громкости, S1, S2 и Fn необходима достаточно серьезная «работа напильником»: модули ядра вроде sonypi способны оживить их лишь частично, для полного их функционирования возможно придется изрядно покопаться в конфигурационных файлах, а также написать/найти некоторое количество bash-скриптов. Надеюсь в будущем найду в себе силы довести это дело до конца, правда особого дискомфорта от ненастроенных кнопок я не испытываю — не успел к ним привыкнуть, да и реализованного на уровне оборудования mute sound мне вполне хватает.

Регулировка яркости дисплея работает прекрасно через консоль с помощью утилиты nvclock, но какого-либо GUI к ней мне найти не удалось, т.к. особой необходимости в этом не испытываю — все равно предпочитаю держать экран максимально ярким, лишь в очень редких случаях возникает необходимость его приглушить, но в таких случаях обычно проще бывает нажать Alt+F2 и набрать необходимую команду.

Встроенная камера заслуживает отдельного разговора. С одной стороны драйвера под нее есть и легко доступны, весь необходимый набор модулей для ядра — v4l, gspcav1, установить абсолютно не проблема. Найдя неплохую статейку в вики я достаточно быстро разобрался с их установкой, но после этого возник вопрос: а зачем оно собственно говоря надо? Как оказалось, камера является абсолютно бесполезным для меня device’ом, и я даже не придумал никакого адекватного способа проверить ее работоспособность. Так эти драйвера и находятся установленными в системе непонятно зачем.

Порт IEEE 1394 aka FireWire опробовать в действии не удалось, так как я не являюсь обладателем устройств, его использующих, но я не вижу каких-либо причин для того, чтобы он не работал: если мне не изменяет память, то он фигурировал в настройках ядра наравне с USB, который замечательно работает.

Cardreader’ов в комплекте было два — один встроенный для MemoryStick, и внешний в 34мм-слот для SD/MMC. Насчет первого не могу ничего сказать, так как карточек таких у меня не нашлось, а второй отлично определился без каких-либо дополнительных действий с моей стороны.

Про DVD-привод, miniJack и прочие стандартные вещи наверное и упоминать смысла нет — с ними все в порядке.

Подведем итоги

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

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

Закончить хотелось бы той же цитатой из Gentoo Handbook, которую я использовал в эпиграфе к этой статье: «Gentoo is all about choices.»

Наконец-то наступил тот самый день, которого так долго ждали многие пользователи различных дистрибутивов Linux и многих других unix-like операционных систем. Да-да, сегодня вышла новая major-версия знаменитого K Desktop Environment под номером 4.0!

Вкратце перескажу оффициальный пресс-релиз:

Набор библиотек, лежащих в основе KDE, был кардинальным образом переделан, изменения произошли в каждой из них. Появилось два новых framework’а: один мультимедийный.- Phonon, а второй — Solid — для интеграции интерфейса для работы с используемым оборудованием в рабочее окружение.

Рабочий стол KDE приобрел новую оболочку под названием Plasma, которая поддерживает огромное количество widget’ов, эффектов и прочих украшательств.

Все программное обеспечение, входящее в его состав также не осталось без изменений (немного от себя: лично мне больше всего понравились изменения в Kopete — единственный icq клиент под *nix, в котором появилась возможность использования x-status, которой сильно не хватало, успел заценить его еще некоторое время назад в beta-версии KDE 4). Помимо Konqueror появился новый файловый менеджер под названием Dolphin и просмотрщик документов Okular (основанный на KPDF, но поддерживающий существенно большее количество форматов документов).

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

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

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

Наиболее точно охарактеризовать то, о чем пойдет речь можно лишь процитировав одного из основателей традиций Unix и разработчика технологии под названием "Unix pipes" — Douglas’а Mcllroy’а:

"This is the Unix philosophy:

Write programs that do one thing and do it well.

Write programs to work together.

Write programs to handle text streams, because that is a universal interface."

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

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

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

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

Взгляд с точки зрения программиста

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

Как же это выглядит?

Одна задача — одна программа

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

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

Unix pipes

Этот механизм является основным способом реализации столько раз упоминавшегося выше интерфейса между элементарными программами. Реализация его поддержки является как раз второй задачей, которая ставится перед программистом, идущим по пути Unix. С использованием большинства языков программирования она является тривиальной, особенно это справедливо для C.

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

Взгляд с точки зрения пользователя

Слово pipes можно переводить по-разному, мне больше нравится вариант потоки, но также часто используется и дословный перевод — трубы. Также имеет смысл сразу сказать, что его реализация полностью основывается на командной строке и командах различных ее оболочек, а также тесно интегрирована с устройствами компьютера и файловой системой.

У каждой элементарной программы, соответствующей этой идеологии, должен быть входной и выходной стандартные текстовые потоки — stdin и stdout соответственно. Механизм unix pipes позволяет перенаправлять эти потоки любой программы произвольным образом с помощью трех простых операторов: |, > и <. Первый из них — | перенаправляет stdout команды слева от него в stdin команды справа, а > и < предназначены для перенаправление потоков в/из файлы по схожему принципу.

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

• cat — вывод содержимого указанного первым параметром файла в stdout (по умолчанию stdout в большинстве программ направляется в консоль)
• less — постраничный вывод текста, полученного в stdin в stdout (переключение страниц и некоторые другие функции производятся с клавиатуры, возможны и другие варианты использования, но они нам не нужны)
• grep — построчная фильтрация текста, полученного в stdin, вывод только строк, содержащих текст, указанный первым аргументом, и вывод результата в stdout.

Начнем с примера, позволяющего прочитать постранично любой файл:

cat readme.txt | less

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

cat readme.txt | grep unix > readme.txt

Этот пример должен был бы удалить из файла все строки, где нет слова "unix". Маленькое замечание: при использовании такого перенаправления, перед началом передачи данных файл обнуляется. В этом и заключается ошибка данного примера: файл очищается до того, как поток данных успел пройти через фильтрацию grep, что приводит к просто очистке файла. Если же Вам все же нужен отфильтрованный список строк — стоит разместить в другом файле (которым можно было бы подменить исходный при необходимости), просто поменяв его название:

cat readme.txt | grep unix > meread.txt

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

cat readme.txt | grep unix >> readme.txt

В unix-like системах есть еще одна интересная особенность, косвенно связанная с этим механизмом: все устройства являются файлами и соответственно, прикреплены к файловой системе, для них выделена отдельная директория, по традиции называемая /dev. Работа с ними также ведется на тех же правах что и с обычными файлами, например набрав в консоли:

cat readme.txt > /dev/dsp

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

Подводим итоги

С точки зрения простого пользователя использование opensource решений, построенных на базе философии unix, является как минимум нетривиальной задачей — ведь от него требуется как минимум понимание насколько мощная и гибкая система попала ему/ей в руки. Отсутствие единственного верного способа решения той или иной задачи ставит большинство людей попросту в тупик, у них начинают разбегаться глаза от десятков тысяч программ, доступа к которым есть у всех пользователей unix-like операционных систем, с помощью набора простой волшебной команды в консоли, состоящей не более чем из трех-четырех слов.

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