Журнал «Компьютерра» № 29 от 14 августа 2007 года
Шрифт:
Эрик любит подчеркивать, что в Университете Беркли свободный софт создавался и распространялся еще в 70-х годах, задолго до того, как было сформулировано его определение, основан Free Sofware Foundation и написана GPL. Оллмен участвовал в создании одной из первых реляционных СУБД (Ingres): "Мы делали ее приниципиально open source, хотя уже тогда существовали проприетарные базы данных. Это был исследовательский проект, мы хотели продвинуть нашу новую концепцию реляционной базы данных, а проще всего достичь этого – сделать базу как можно более доступной".
Впрочем, надо заметить, что между хакерским сообществом Университета Беркли, к которому принадлежит Эрик, и Ричардом Столлменом всегда существовали идеологические разногласия. "Я понимаю соображения Ричарда, – говорит Эрик, – но мне кажется,
"Политически я предпочитаю BSD-лицензии", – говорит Эрик. Первоначально sendmail распространялась именно под BSDL. Однако сейчас условия изменились, и в Sendmail license имеются требования, аналогичные копилефту. Удивительно, но это было вызвано соображениями, очень далекими от риторики Столлмена. "Бизнес, только бизнес", – объясняет Эрик. В 1998 году он основал компанию Sendmail, Inc., дабы зарабатывать на своих разработках. Тогда же стало ясно, что BSDL не очень подходит для выбранной бизнес-модели, и лицензия сменилась: "Откровенно говоря, это было сделано, чтобы конкуренты не могли просто взять наш код и использовать его против нас. Если вы – коммерческая компания и хотите открыть свой код, выпустите его под GPL. Например, Microsoft в свое время заимствовала TCP/IP-стек из BSD. Этого не могло бы произойти под GPL – точнее, MS пришлось бы открыть код".
Часть бизнес-модели Sendmail, Inc. – создание проприетарных решений. Сам по себе базовый код sendmail остается открытым, но компания создает некоторые продукты на его основе, зачастую включающие проприетарные решения – в том числе лицензированные у сторонних производителей (антивирусы, антиспам-системы). Однако другая существенная часть деятельности Sendmail, Inc. построена вокруг сервисов. Фронт работы здесь очень широкий: речь идет не только и не столько об установке готового ПО, сколько о создании системы хождения корреспонденции, которая удовлетворяла бы некоторым требованиям. Сейчас эти требования могут диктоваться, например, законами о сохранности личной информации, – компания, работающая с такой информацией, обязана их соблюдать, а нарушение (скажем, утечка из-за сбоя в работе почтовой системы) может повлечь за собой серьезную ответственность. Эта проблема естественным образом ложится на плечи вендора системы обмена корреспонденцией (или системного интегратора) – ему приходится заниматься такими вопросами, как управление рисками.
Сам зарабатывая деньги на программном обеспечении, Эрик Оллмен далек от того, чтобы считать "плохими" все софтверные компании – в том числе и работающие в проприетарных бизнес-моделях. Для него важнее другое. "Всегда существовали "злые" компании и хорошие и честные компании. Нельзя судить обо всех компаниях, смотря на деятельность только некоторых. Например, некоторые компании не заботятся об окружающей среде, стремясь заработать как можно больше денег в наикратчайшие сроки. Однако есть множество фирм, которые собираются существовать сотни лет, и они понимают, что если будут пытаться получить максимум прибыли сейчас, то уничтожат свой бизнес завтра".
Если говорить о программах, то свобода широкого конфигурирования и настройки под пользователя, присущая многим классическим open source-разработкам (включающим и саму sendmail, и Apache), для Эрика значит гораздо больше, чем формальная открытость кода: "Разработчики одного из open source-мейлеров, которым я когда-то пользовался, решили, что не нужно давать возможность пользователю его настраивать. Они считают, что знают лучше, как пользоваться e-mail. Я хочу работать не так, как вы привыкли, а так, как я привык. Мейлер, который я использую сейчас, не открытый, но конфигурируемый".
Завершая
беседу, я спросил Эрика, как меняется мир открытого ПО в последнее время. Подумав минуту, он ответил, что сейчас идут два параллельных процесса: количество стандартов сокращается, а количество их реализаций растет. На заре Интернета было множество несовместимых друг с другом почтовых систем и протоколов. "Ныне же есть SMTP – это ограничивает нас в выборе, но не создает особых проблем. С другой стороны, когда-то, выбирая MTA, вы могли поставить sendmail, sendmail или sendmail; сейчас же sendmail – один из многих", – говорит Эрик. И добавляет: "Мне кажется, что это хорошо".Идея технологии DomanKeys Identified Mail (DKIM) состоит в том, что компания, владеющая некоторым доменом (например, brandname.com), криптографически подписывает всю легитимную почту, исходящую с SMTP-серверов, действительно принадлежащих этой компании. Проверка подписи осуществляется через DNS-сервер, обслуживающий данный домен. Если же кто-то захочет отправить письмо с обратным адресом в @brandname.com через сторонний SMTP-сервер (или, скажем, с помощью компьютера, зараженного троянской программой), не имея доступа к DNS-серверу brandname.com, подделать подпись он не сможет – письмо будет отправлено, но без подписи (или с неверной подписью). Если известно, что данный домен всегда подписывает свою исходящую почту (например, речь идет о банке, который таким образом борется с фишинг-атаками), неподписанное письмо покажется очень подозрительным и скорее всего будет отвергнуто либо исследовано получателем «под микроскопом». Первыми станут подписывать свои сообщения те компании, для которых это критично (те же банки), но со временем количество внедрений будет возрастать, и неподписанные сообщения станут редкостью и будут вызывать подозрения. С другой стороны, аутентификация сообщений происходит на уровне сервисов и компаний, а не на уровне отдельных пользователей, и не входит в противоречие с анонимностью почтового обмена.
Фото предоставлены организаторами Interop Moscow 2007.
ТЕМА НОМЕРА: Круговорот толпы
Автор: Родион Насакин
Проторчав час в пробках, вы таки доехали до места и припарковались у торгового центра, в котором, по уверениям вашей половины, есть магазин с чудесными африканскими вазами, вошли в здание и… растерялись. Редкие невразумительные таблички со стрелками, сопровождаемыми не менее загадочными обозначениями, ни одного информационного терминала в зоне видимости и отрешенный от суетного мира охранник.
Поначалу вы неслись вместе с толпой, но вскоре поняли, что основной поток устремляется в продуктовый супермаркет, где искомыми вазами и не пахнет, после чего вышли из мейнстрима и стали плутать по пустынному многоэтажному лабиринту, вглядываясь в витрины и надеясь увидеть знакомые названия или, на худой конец, мало-мальски толковый указатель. Вполне возможно, что в конце концов вам повезло, и вы случайно обнаружили нужный магазин, убив, однако, гораздо больше времени, чем предполагали.
Подобные случаи, думаю, могут припомнить многие. Прелести общества потребления принесли с собой новые проблемы. Многие промышленные объекты и прочие просторные сооружения немедля были переоборудованы под торговые нужды, правда, ни о каком серьезном подходе к навигации покупателей тогда никто не думал. Да и позднее девелоперы, возводившие торговые центры, частенько игнорировали вопросы регулирования перемещений посетителей внутри зданий.
Это, конечно, неприятно, но не смертельно, к тому же неудачное проектирование плачевно сказывается на прибыльности торгового центра, так что застройщики начинают уделять этому аспекту больше внимания. Гораздо серьезнее, когда подобные недоработки приводят к скоплению людей на критических участках во время чрезвычайных ситуаций. Паникующую толпу контролировать нельзя, однако, как будет показано ниже, ее поведение вполне можно предсказать, тем самым минимизировав и даже сведя к нулю количество возможных жертв.