Компьютерра (№255) - Журнал «Компьютерра» № 20 от 30 мая 2006 года

Если мы распределяем файлы по разным веб-серверам, всегда остается шанс, что на один из серверов файл попадет на секунду или две позже, чем на другой. В этом случае e-tag, сгенерированные серверами, будут отличаться. Мы можем изменить настройки так, чтобы генерировать e-tag только на основании размера файла, но это означает, что файл не обновится в браузере, если мы изменим его содержимое, а размер останется неизменным. Тоже не идеально.

Твой лучший друг кэш

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

Или все же слегка иначе? Ведь перед отправкой любых JavaScript— или CSS-файлов клиент запрашивает страницу, которая на них ссылается с помощью тегов

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

header(«Expires: „.gmdate(„D, d M Y H:i:s“, time()[phone]).“ GMT»);

header(«Cache-Control: max-age=315360000»);

Так мы говорим браузеру, что содержимое файла останется неизменным в течение десяти лет (т.е. плюс-минус 315 360 000 секунд), поэтому, единожды загрузив файл, браузер может следующие десять лет использовать локальную копию. Конечно, необязательно использовать для отправки JavaScript и CSS именно PHP. Мы перейдем к этому через несколько минут.

Ошибка на ошибке

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

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

Чтобы сделать этот процесс максимально безболезненным, следует для начала уяснить, что нам вообще не нужно переименовывать файлы. Между реальным расположением файла на диске и URL, с которого он доставляется пользователю, нет ничего общего. Так что в случае Apache мы можем использовать mod_rewrite, создав простое правило для редиректа определенных URL к нужным файлам:

RewriteEngine on

RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /$1$2 [L]

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

foo.v2.gif foo.gif

/css/main.v1.27.css css/main.css

/javascript/md5.v6.js /javascript/md5.js

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

Вы можете поинтересоваться, почему мы просто-напросто не использовали динамические ссылки (например, /css/main.css?v=4)? Дело в том, что, согласно спецификации HTTP, пользовательские агенты вообще не должны кэшировать такие URL. И хотя IE и Firefox это игнорируют, Opera и Safari точно следуют букве — поэтому, чтобы гарантировать корректную работу всех браузеров при кэшировании наших ресурсов, мы избегаем использовать динамические ссылки.

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

function smarty_version($args){

$stat = stat($GLOBALS[‘config’][‘site_root’].$args[‘src’]);

$version = $stat[‘mtime’];

echo preg_replace(‘!.([a-z]+?)$!’, «.v$version.$1», $args[‘src’]);

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

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

$GLOBALS[‘config’][‘resource_versions’] = array(

‘foo.gif’ => ‘2.1’,

‘/css/main.css’ => ‘1.27’,

‘/javascript/md5.js’ => ‘6.1.4’,

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

function smarty_version($args){

if ($GLOBALS[‘config’][‘is_dev_site’]){

$stat = stat($GLOBALS[‘config’][‘site_root’].$args[‘src’]);

$version = $stat[‘mtime’];

$version = $GLOBALS[‘config’][‘resource_versions’][$args[‘src’]];

echo preg_replace(‘!.([a-z]+?)$!’, «.v$version.$1», $args[‘src’]);

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

Собираем все вместе

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

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

RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /redir.php?path=$1$2 [L]

header(«Expires: „.gmdate(„D, d M Y H:i:s“, time()[phone]).“ GMT»);

header(«Cache-Control: max-age=315360000»);

# ignore paths with a ‘..’

if (preg_match(‘!..!’, $_GET[path])){ go_404(); }

# make sure our path starts with a known directory

if (!preg_match(‘!^(javascript|css|images)!’, $_GET[path])){ go_404(); }

# does the file exist?

if (!file_exists($_GET[path])){ go_404(); }

# output a mediatype header

$ext = array_pop(explode(‘.’, $_GET[path]));

switch ($ext){

case ‘css’:

header(«Content-type: text/css»);

case ‘js’ :

header(«Content-type: text/javascript»);

case ‘gif’:

header(«Content-type: image/gif»);

case ‘jpg’:

header(«Content-type: image/jpeg»);

case ‘png’:

header(«Content-type: image/png»);

header(«Content-type: text/plain»);

# echo the file’s contents

echo implode(‘’, file($_GET[path]));

function go_404(){

header(«HTTP/1.0 404 File not found»);

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

RewriteEngine on

RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /$1$2 [L,E=VERSIONED_FILE:1]

Header add «Expires» «Mon, 28 Jul 2014 23:30:00 GMT» env=VERSIONED_FILE

Header add «Cache-Control» «max-age=315360000» env=VERSIONED_FILE

Из-за порядка исполнения Apache, мы должны добавить строчку Re-writeRule в главный конфигурационный файл (httpd.conf), а не в .htaccess, иначе строчки Header будут исполнены первыми, перед установкой переменной окружения. Сами строчки Header могут быть размещены и в главном конфигурационном файле, и в .htaccess — их местоположение ни на что не влияет.

Сокращенный перевод.

© 2006 Carson Systems, Vitamin

Оригинал: www.thinkvitamin.com/features/webapps/serving-javascript-fast

РЫНКИ: Ну и как тебя называть?

Автор: Виктор Шепелев

Unix отсутствует. Просто не существует в природе. То есть нет такой конкретной вещи, в которую можно ткнуть пальцем и сказать: «Вот это — Unix». А все остальное тогда будет никакой не Unix. Собственно говоря, удивительный термин *nix (и даже — *n?x, как дань Linux) — результат вот этого несуществования единственно правильного Unix’а.

Как это вышло

Причиной такого положения дел стал антимонопольный комитет США. Не стоит сразу представлять себе судебный процесс «Консервативная монополия Unix мешает развитию новой перспективной ОС Windows». Антимонопольный процесс против American Telephone and Telegraph (AT&T) в 1949 году помешал распространению влияния телекоммуникационного гиганта на новорожденные отрасли: AT&T было запрещено заниматься продажей каких бы то ни было компьютерных решений, и рекомендовалось ограничиться телефоном и телеграфом.

Именно поэтому исследовательское подразделение AT&T, Bell Labs, с тех пор прибыли само по себе не приносило: все создаваемые компьютерные технологии свободно лицензировались всем желающим. Если бы не это, еще неизвестно, как сложилась бы судьба созданной в Bell Labs операционной системы Unix. Многие из лицензиатов (в основном, конечно же, университеты) создавали слегка или сильно модифицированные версии для собственных нужд. Одной из этих версий, созданной в университете Беркли, Калифорния ничем не примечательным аспирантом Биллом Джоем, была уготована долгая и извилистая судьба.

В начале 1980-х годов в результате очередного антимонопольного судебного процесса AT&T была разделена на несколько подразделений, в результате чего у корпорации оказались развязаны руки (в смысле получения прибыли от торговли компьютерами). И вновь — тяжело предположить, как бы сложилась судьба Unix без этого события: с одной стороны, агрессивный маркетинг AT&T способствовал быстрому и эффективному распространению ОС; с другой — новая стратегия лицензирования (без исходного кода) положила начало разделению разработки Unix на несколько разных независимых веток и многолетнему противостоянию этих веток (так называемые unix wars).

Одной из «веток» стал разработанный в Беркли «берклиевский набор софта» (Berkeley Software Distribution, BSD), по прежнему распространявшийся свободно и с исходниками. Возможно, именно этот факт повлиял на DARPA[На всякий случай: DARPA — Defense Advanced Research Projects Agency (Агентство перспективных исследований при Министерстве обороны США) — так или иначе поддерживало огромную часть исследований, которые сформировали образ современных IT] при выборе — кому бы дать денег для разработки протокола TCP/IP. Дали. Разработали (4.2BSD, август 1983 года). Этот фактор (совместно со многими другими) повлиял на огромную популярность и быстрое распространение BSD. Ну а Билл Джой, с которого начиналась эта версия Unix, тем временем создал собственную фирму под названием «Солнышко».

Оригинальная Unix System V от AT&T, созданная в Беркли BSD, Sun OS от Sun Microsystem и еще несколько дистрибутивов, основанных на System V и BSD, вступили в сложное взаимодействие, включавшее и конкуренцию, и заимствование полезных фич, и юридические споры — в общем, было весело. Однако все это привело к размытию образа Unix и потере ориентиров в стиле «лебедь, рак и щука». Попытки исправить ситуацию привели к очередному пату: AT&T и Sun скоординировались и создали System V version 4, а многие независимые производители, которым не понравился этот альянс гигантов, объединились в Open Software Foundation[Не путать с Free Software Foundation — ничего общего!] и попытались создать «свой» Unix по имени OSF/1 (в общем, это была неудачная попытка)[Вообще говоря, у них там все еще сложнее получилось: сначала группа независимых поставщиков Unix создала группу по его стандартизации X/Open, в ответ на это объединились AT&T и Sun; а уже это привело к появлению Open Software Foundation].

Этот жизнерадостный период (конец 80-х — начало 90-х), называемый Unix wars, имел много интересных последствий: считается, что пока юниксопроизводители воевали друг с другом, Windows захватил десктопы, а внезапно появившийся Linux — сердца простых юниксоидов, которым скандалы производителей были до фени. Впрочем, в данном контексте нам будут намного интереснее другие последствия противостояния.

Что из этого вышло

А последствия были такие: программистам стало очень печально жить. Как водится, в результате маркетинговых войн (когда каждый стремится сотворить систему круче чем у прочих) совместимость различных клонов Unix пошла на убыль. То есть программа, написанная под какую-нибудь Sun OS, совершенно не обязательно станет работать под какой-нибудь другой BSDI (хотя, по идее, и то и другое — Unix). Менеджерам-маркетологам этот вопрос был, в общем, без разницы («а так даже лучше — чего это наши программы будут работать под ОС конкурента?»), но, к счастью, культура Unix всегда определялась скорее программистами и продвинутыми пользователями, нежели менеджерами.

В 1985 году за дело взялась серьезная организация IEEE, которая ведает большой частью американских и международных стандартов. При участии многих выдающихся профессионалов к 1990 году появился стандарт POSIX (о происхождении аббревиатуры — см. эпиграф; официальная расшифровка — Portable Operating System Interface[X в аббревиатуре — что-то вроде «привет юниксоидам»]).

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

Соответственно своей цели (обеспечить переносимость прикладных программ), POSIX не предъявляет никаких требований к архитектуре операционной системы. POSIX определяет только взаимодействие между программой и ОС в стиле «системный вызов по имени А с параметром Б должен выполнить В и вернуть результат Г или ошибку Д». Это означает, что «POSIX-совместимая операционная система» не является синонимом «Unix». Например, в исходный код Linux (чтобы там ни думала себе SCO) не входит ни единой строчки из изначального AT&T Unix. Тем не менее программы, работающие в System V или BSD, без проблем запустятся в Linux. Торвальдс достиг этого результата действиями «в лоб»: взял стандарт POSIX и реализовал его. Получилось[Когда Oracle портировала свою БД (уже работавшую на Sun Solaris, наследнике Sun OS) на Linux, кто-то задал оракловским инженерам вопрос типа «и что, трудно было?» Ответ был характерен: «мы запускали make» (в смысле — собрали программу из исходников, и все заработало)].

Я вам больше скажу — Windows NT совместима с одной из частей POSIX (1003.1b, real-time extensions, описывающей переключение процессов, синхронизацию потоков и т. п.). И если скачать с сайта Microsoft набор утилит Services for Unix (SFU) — брюки превращаются… во вполне POSIX-соместимую систему (то есть теоретически любая Unix-программа на Windows+SFU должна собраться и запуститься без проблем). И еще более того — поддержка SFU корпорацией Microsoft как отдельного продукта практически прекращена — потому что он теперь будет входить в стандартную поставку Windows. Такие форточки.

Интерфейс взаимодействия операционной системы и прикладных программ (традиционно называемый OS API, Application Programming Interface) естественно, существует в каждой ОС и в очень большой степени определяет легкость программирования под нее. Использованный при создании POSIX метод «практической стандартизации», когда собираются лучшие из используемых подсистем и объявляются стандартом, показала себя существенно эффективней других вариантов: «теоретической стандартизации» (когда собираются ученые и решают «как будет умнее») и неконтролируемой проприетарной разработки (когда единственная фирма-производитель ОС предоставляет API по мере собственного разумения каждого конкретного отдела).

Образцовым примером проприетарного API является, как несложно предположить, Microsoft Windows API. Его наиболее «любимые» программистами характеристики стали уже притчей во языцех:

Далеко не все API документировано, в результате чего прикладные программы, разработанные Microsoft, имеют возможности по интеграции с ОС, недоступные другим программам.

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

Увлеченность «новыми» технологиями: часть Windows API основывается, как и POSIX, на базовых типах и принципах языка C; другую часть невозможно использовать без знания Microsoft COM.

И просто непродуманность. Хрестоматийный пример: разрабатывая под Windows программу, работающую в командной строке, задачу вызова другой программы и перехвата ее вывода можно решить одним-единственным вызовом перекочевавшей из POSIX функции popen. Но вот разрабатывающий оконное приложение программист обязан пользоваться уже другим API, простейший пример использования которого занимает около двух страниц кода: инициализация внутренних структур, запрос и установка параметров, подготовка окружения.

К слову, и на Windows API существует международный стандарт ECMA-234; эмулятор WinAPI для POSIX-систем Wine опирается именно на этот стандарт.

Кому это нужно кто это выдержит

Как уже было сказано, самая первая версия стандарта POSIX — он же IEEE 1003 — была подготовлена в 1985—90 годах под руководством IEEE, Института инженеров по электротехнике и электронике, международной некоммерческой организации, занимающейся как раз стандартизацией различных технологий.

Этот стандарт включал две части: 1003.1 определяла требования к системным вызовам самой ОС, а 1003.2 (появившаяся в 1992 году) — требования к «окружению», то есть к программам-утилитам, которые должны присутствовать в POSIX-совместимой системе. Еще одна часть стандарта — требования к системе реального времени, в 1993 году вышедшая как 1003.4, а в 1996-м — разделенная и переименованная в 1003.1b (собственно система реального времени) и 1003.1c (управление параллельными процессами). Стандарт был также принят международной организацией по стандартизации как ISO/IEC 9945.

Тем временем закончились Unix-войны. Усталая AT&T на все плюнула и продала все связанные с Unix права, патенты и исходные коды фирме Novell; та тоже недолго мучилась и продала Unix частями: все права на торговую марку и название ушли в упомянутую выше X/Open, а права на исходный код — в печально знаменитую SCO Group (которой эти права не принесли счастья).

А вот из X/Open, в которой объединились ведущие поставщики Unix для создания общего стандарта[Собственно, именно это, а не уход AT&T, положило конец Unix-войнам], вышел толк. Объединившись в 1996 году с Open Software Foundation, под общим названием The Open Group, заполучив в свои ряды практически всех основных unix-игроков, некоммерческая организация занялась разработкой общей спецификации Unix (Single UNIX Specification), которая и вышла в 1998 году. Некоторое время Single UNIX Specification и POSIX существовали параллельно (причиной тому — бытовавшая в IEEE странноватая практика продавать копии стандартов за большие деньги и запрещать их свободное распространение); однако, в конце 90-х была создана специальная Austin Group, занятая объединением двух стандартов. В результате, в 2001 году вышла Single UNIX Specification 3, которая является одновременно и POSIX-стандартом IEEE.

Будучи по сути одним и тем же документом, SUS и POSIX преследуют различные цели: POSIX, как уже было сказано выше, это стандарт, которому должна соответствовать операционная система для переносимости программ; в то время как SUS — стандарт, которому нужно соответствовать, чтобы иметь право употреблять торговую марку UNIX.

И здесь мы возвращаемся к началу статьи и вопросу «что есть Unix». На сегодня все *n?x-системы (в том числе и BSD-клоны, в названии которых нет ни "n", ни "x") принято делить на:

Unix по происхождению: это ОС, которые основываются на оригинальном исходном коде Unix, разработанном в AT&T. Эти ОС совершенно необязательно соответствуют каким-либо стандартам. Этот тип, как правило, включает различные «исторические» версии Unix (созданные еще до появления всяких стандартов).

Unix по праву имени: системы, которые прошли сертификацию The Open Group и имеют право употреблять торговую марку UNIX в своем названии и/или описании. При этом совершенно не обязательно использовать оригинальный код AT&T. В основном это коммерческие дистрибутивы: HP-UX, Solaris и т. п., у авторов которых есть необходимость доказать пользователю «качество» системы и достаточное количество денег и времени, чтобы пройти непростой процесс сертификации.

Unix по функциональности: системы, которые не соответствуют ни пункту (1), ни пункту (2), но тем не менее в большой степени похожи на юникс и совместимы с ним. Сюда входят практически все варианты Linux; сюда же можно отнести открытые BSD-клоны (FreeBSD, OpenBSD и т. д.), которые, хотя и основаны на оригинальном BSD, произошедшем от AT&T Unix, активно развиваются и близки к существующим стандартам. Linux и BSD, разрабатываемые энтузиастами, как правило, достаточно близки к стандартам, но их авторы не горят желанием тратить деньги и время на официальное подтверждение этого факта.

Интересно, что само имя UNIX не рекомендуется употреблять «не по делу», применительно к несертифицированным системам и без значка ®, поскольку оно является зарегистрированной торговой маркой. Зачастую, говоря о *nix-системах, употребляют написание «Unix» или «unix» — вроде бы они зарегистрированными марками не являются[С вопросом больших-маленьких букв в этом слове связан забавный казус: слово «Unix», являясь аббревиатурой, в самых старых документах пишется маленькими буквами с большой "U"; Деннис Ритчи объясняет этот факт просто: «у нас только-только появилась новая пишущая машинка, на которой большие и маленькие буквы различались, и нам очень нравилось с ней играться»].

LSB

Несмотря на некоторую отвлеченность Linux от Single UNIX Specification, у линуксоидов тоже есть свои стандарты. Во-первых, стандартно ядро (в силу своей единственности); во-вторых, всякий Linux в меру сил POSIX-соместим; в-третьих, существует LSB.

LSB — это Linux Standard Base; стандарт, расширяющий POSIX, цель которого — увеличить совместимость Linux-дистрибутивов. Помимо вопросов, оговариваемых POSIX’ом, LSB определяет «правильное» расположение основных папок в файловой системе (/bin/ для программ, /etc/ для конфигурационных файлов и пр.), некоторые расширения системы X Windows, систему распространения пакетов[Кстати, система распространения пакетов — одна из крайне спорных частей LSB. Дело в том, что их существует как минимум две («как минимум» — известных и употребляемых во многих системах): rpm (произошедшая от RadHat Linux) и deb (произошедшая от Debian); причем deb гораздо старше и считается более зрелой, но стандарт навязывает использование rpm] и т. п. В отличие от POSIX, LSB в большой степени определяет облик Linux, а не только интерфейс взаимодействия ОС и прикладного софта.

Сертификацией на соответствие LSB занимается та же The Open Group, впрочем, слово «Linux», к счастью, можно использовать и без сертификации. Из распространенных дистрибутивов сертифицированными являются SUSE и RadHat.

Университеты: Виды бесплатного сыра

Авторы: Алексей Ковязин, Кузьменко Дмитрий

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

В супермаркетах, к сожалению, о таком рае для потребителей приходится только мечтать, но вот в мире баз данных сложилась ситуация, весьма сходная с описанной: за последние годы среди производителей стало принято раздавать свои продукты бесплатно, причем это касается не только открытых СУБД вроде Firebird и PostgreSQL, но и коммерческих монстров вроде IBM DB2 и Oracle. Что же стоит за этими внезапными приступами благотворительности?

Бесплатное бесплатному рознь

Для тех, кто ничего не знает о бесплатных базах данных[Кстати, не бросайтесь сразу набивать карманы. Во-первых, эти продукты никуда не денутся, а во-вторых, некоторые дистрибутивы (например, DB2-C и Oracle XE) «весят» сотни мегабайт], сделаем небольшой обзор. Прежде всего отметим традиционные продукты с открытым кодом: PostgreSQL, Firebird и, конечно же, MySQL.

PostgreSQL

Эта СУБД, поддерживающаяся сообществом энтузиастов, особенно популярна в университетской и научной среде. Она также предлагается многими провайдерами в качестве back-end для веб-разработки. Однако в сфере бизнес-приложений PostgreSQL так и осталась «гадким утенком», поскольку для ее установки (до версии 8) под Windows требовались достаточно сложные телодвижения с установкой cygwin и другим наследием Linux.

По моему мнению, PostgreSQL представляет собой мощный и перспективный «конструктор» для продвинутых разработчиков, которые ценят возможность расширения и доработки движка под свои нужды. Хорошей иллюстрацией «духа» этой СУБД может служить то, что список рассылки ее разработчиков называется «pgsql-hackers». Если уж они сами называют себя хакерами…

Никаких ограничений на использование PostgreSQL нет — это действительно бесплатная СУБД, без всяких подводных камней (в том числе технических и юридических).

Firebird

Побочный результат эксперимента компании Borland c ее СУБД InterBase в 2000 году, когда она была опубликована под лицензией InterBase Public License. Группа бывших разработчиков InterBase и просто энтузиастов скопировала исходные коды и затеяла проект под названием Firebird (любопытно, что проектом никто не владеет — существует только некоммерческая организация Firebird Foundation для поддержки процесса разработки Firebird).

Благодаря почти полной совместимости с InterBase и наличию готовых дистрибутивов для Windows и различных вариантов Linux/Unix, новая СУБД быстро завоевала популярность. Долгое время ее называли «бесплатный InterBase». В настоящий момент готовится к выходу версия Firebird 2.0, которая хоть и сохраняет совместимость с предыдущими версиями InterBase, но сильно отличается от своего предка.

Надо отметить, что коммерческий InterBase (ныне версии 7.5) поныне живет и здравствует, причем наличие InterBase 6 Open Edition и Firebird сыграло ему только на руку в плане увеличения популярности среди начинающих разработчиков, ведь Firebird очень удобна для разработки в качестве «встраиваемого» приложения — то есть «молчаливого» сервера базы данных, который устанавливается в тиражируемых приложениях (например, Firebird используется в качестве движка для компакт-диска журнала «Upgrade»). Конечно, это не означает, что сервер годится только для маленьких приложений, он прекрасно обслуживает системы с числом пользователей 100—150 человек и размером баз данных до 60 Гбайт.

Firebird не имеет никаких юридических или искусственных технических ограничений по использованию.

MySQL

MySQL — первая база данных с открытым кодом, на которой ее создателю, компании MySQL AB, удалось-таки заработать деньги (любой OpenSource-проект финансируется либо спонсорами, как Firebird и PostgreSQL, либо живет за счет продажи услуг и платных лицензий, как MySQL). Это, по утверждению ее PR-службы, самая быстрая в мире СУБД (при определенных условиях, естественно), ее использует NASA (вернее, на ней построены несколько сайтов агентства) и большинство динамических сайтов (а вот это сущая правда).