Шрифт:
Сервис, доступный пока лишь американцам, построен на базе привычных "коротких номеров". Отправив один из кодов на номер 698698 (NYTNYT), читатель получает на свой телефон SMS с кусочком выбранной статьи. Чтение можно продолжить, воспользовавшись ссылкой на полный текст или запрашивая продолжение посредством новых сообщений. Выбирать материалы можно как по рубриками (Latest, Business, World, National, Tech - всего полтора десятка разделов), так и по фамилии корреспондента или колумниста.
Услуга на данный момент является бесплатной, читатель оплачивает только передачу сообщений согласно тарифу своего оператора. В дальнейшем руководство NYT надеется использовать новый канал дистрибуции как дополнительную рекламную площадку. ЕВ
ТЕМА НОМЕРА: Цена вопроса
Автор: Илья Щуров Voyager
Стоя у окна в сараеподобном аэропорту небольшого чешского городка Пардубице и глядя в хвост улетающему в Москву самолету, я думал о цене ошибки ввода-вывода. Чтобы опоздать на рейс, достаточно было неправильно прочитать один байт во времени отъезда из отеля, указанного в "памятке отдыхающему". Поскольку это было уже второе опоздание на самолет за поездку, мы решили больше не искушать судьбу и ехать на Родину поездом - благо Чехия очень вовремя вошла в Шенген, и можно было надеяться проскочить границу с Польшей, не рискуя столкнуться с непреодолимыми трудностями в лице польских пограничников.
Железные дороги - один из классических примеров технологии, сделавшей мир меньше. И не менее классический пример отсутствия единого общемирового стандарта - всего-навсего на расстояние между рельсами. Когда перед Брестом сидишь в промерзшем вагоне, не имея возможности добыть элементарного кипятка, и ждешь, когда же, в конце концов, поменяют эти чертовы колеса, чтобы дальше можно было ехать по советским рельсам, мысли о пользе стандартизации поневоле лезут в голову. Как, впрочем, и понимание того, что сделать уже ничего нельзя: никто не станет перекладывать все железные дороги на территориях, сравнимых с территорией СССР, только чтобы соответствовать "международному стандарту". Потратить несколько часов на смену колес в каждом составе, пересекающем технологическую границу, - гораздо более реальное, хотя и "идеологически неправильное" решение проблемы.
Этот пример вдвойне показателен. С одной стороны, он заставляет задуматься о том, к чему может привести отсутствие стандарта. С другой - показывает, что нередко приходится принимать ситуацию такой, какая она есть, - и никакие заклинания и благие намерения не в состоянии ее изменить.
Тема сегодняшнего номера посвящена стандартизации форматов файлов офисных приложений. События последних лет показывают, что ситуация в этой области меняется: после десятилетий торжества бинарных файловых форматов и таких "стандартов де-факто", как DOC или XLS, им на смену приходят более "прозрачные", основанные на XML форматы с доступными спецификациями. Однако процесс этот нелегок. Слишком многое поставлено на карту, слишком многим рискуют мегакорпорации (не только Microsoft, но и ее "заклятые друзья" - IBM, Sun, Google и другие) - и спор инженеров и разработчиков быстро приобретает недоброе политическое звучание…
Стандарт, еще стандарт
Автор: Илья Щуров Voyager
Занимаясь тематикой свободного ПО уже несколько лет, я успел привыкнуть к некоторым простым и очевидным вещам. Например, к тому, что открытые стандарты для интерфейсов и форматов - это не только хорошо, но и очень важно. Причем важно для всех. Ну, скажем, любая блондинка из анекдота должна испытывать неописуемые нравственные страдания, пересылая своей знакомой файл в проприетарном формате DOC - а вдруг у той не окажется MS Windows или MS Office и она не сможет его прочитать или отредактировать? И уж конечно, я полагал, что за противостоянием "ODF vs. OOXML" следит все прогрессивное человечество.
Тем неожиданнее было обнаружить, что идея темы, посвященной стандартизации офисных форматов, встретила определенное сопротивление. "А кого это вообще волнует - какие там форматы файлов разработчики используют?" - спрашивал Володя Гуриев. Ответ на этот вопрос был мне столь очевиден, что я не нашел слов, чтобы его выразить. Пришлось писать статью.
Впрочем, вопрос действительно не очень простой. С чего бы это вокруг в общем-то технической процедуры стандартизации разгорелись страсти, достойные по накалу даже не мексиканских мыльных опер, а остросюжетных сериалов? Имеют ли какое-то значение стандарты в жизни "простого пользователя", если он зачастую не знает об их существовании? Каковы общие принципы развития информационных технологий - и как мы можем на них повлиять, чтобы извлечь из них максимальную пользу? Какова роль государственного управления в этих процессах?
Чтобы попытаться если не ответить, то хотя бы поместить в правильный контекст все эти и многие другие вопросы, нам придется поговорить о стандартах вообще, слегка погрузиться в историю, вспомнить браузерные войны и проанализировать события, происходящие буквально на наших глазах.
Вообще говоря, единого определения "открытого стандарта" не существует - разные источники приводят немного разные формулировки, и зачастую обсуждаются разные степени или аспекты "открытости". Тем не менее можно выделить основные свойства, которым должен удовлетворять "открытый стандарт". Спецификации стандарта должны быть доступны для ознакомления и использования - бесплатно или за некоторую фиксированную цену. Любой разработчик без какой-либо дискриминации должен иметь возможность реализовать стандарт. Стандарт не должен требовать лицензионных или патентных отчислений для своей реализации (отсутствие роялти). Еще одно важное требование: принятие стандарта и его новых версий должно происходить путем обсуждения и поиска консенсуса, по понятным и прозрачным правилам, чтобы любая заинтересованная сторона имела возможность повлиять на его развитие.
То, каким образом стандарт разрабатывается и поддерживается, является критически важным. Даже если одна компания опубликует спецификации какой-то технологии и даже если эта технология достаточно популярна, чтобы на нее ориентировались другие разработчики, спецификация не станет стандартом до тех пор, пока к процессу ее разработки не обеспечен равный доступ всех заинтересованных лиц. Например, если с выпуском новой версии некоторого ПО меняется и завязанная на него спецификация, производители конкурирующих продуктов, которые хотят поддерживать совместимость с этим ПО, оказываются в положении догоняющих, а "владелец" спецификации имеет преимущество.