Один из участников обсуждения “Все те же лица и все те же вопросы”предложил побеседовать о том, насколько сильны технологические навыки российских разработчиков СПО и насколько глубоки их участие и вклад в современные СПО-проекты, с директором компании “Инфра-Ресурс” Николаем Гарбузом. Выполняю данное мной обещание провести такую беседу.
PC Week: Насколько велик объем разработки СПО в России? Можно ли, даже с натяжкой, считать хотя бы один дистрибутив Linux российским?
Николай Гарбуз: Безусловно, в России есть успешные СПО-проекты. Например, ngnix, обслуживающий 6,5% веб-серверов мира. Однако исследования FSF и GNOMEне выявили весомых вкладов российских программистов в развитие Linux.
“Гражданская” принадлежность дистрибутива Linux — это сложный вопрос. Чтобы найти ответ, необходимо разобраться, что же есть на самом деле “дистрибутив Linux” (здесь и далее под дистрибутивом понимается только десктоп Linux-системы. — Прим. С. Г.).
“Дистрибутив Linux” — это сборник программ независимых авторов, выступающий как одна единица распространения с индивидуальным названием. При этом способ распространения дистрибутива (CD, DVD, FlashCard, репозитарий и т. д.) не имеет значения.
Все дистрибутивы Linux содержат:
- общее — ядро;
- общий — набор системных утилит;
- общий — набор прикладных программ независимых разработчиков;
- выборочные улучшения вышеперечисленного, сделанные поставщиком дистрибутива.
По составу включенных программ все дистрибутивы Linux совпадают на 90% и более. Все дистрибутивы Linux на 90% и более зависимы друг от друга, так как заимствуют исходный код из общих источников, именуемых совместно мэйнстримом или сообществом Linux. Разорвать зависимость отдельного дистрибутива от сообщества Linux на практике невозможно. Любой дистрибутив всегда больше акцептор мэйнстрима, чем донор.
PC Week: Тем не менее мы же говорим “французский дистрибутив”, “испанский дистрибутив”... Значит, все-таки какой-то указатель на государственную принадлежность у дистрибутивов есть? И вполне может быть “российский Linux”.
Н. Г.: Это просто статус. С технической точки зрения определить/узаконить гражданскую принадлежность дистрибутива Linux не представляется возможным, так как у мэйнстрима, поставляющего более 90% исходного кода, нет общего гражданства или юридической принадлежности.
Любой дистрибутив Linux — это продукт совместной деятельности независимых разработчиков в Интернете. Наши соотечественники работают в зарубежных СПО-компаниях, находясь дома. Российские СПО-компании нанимают зарубежных разработчиков также через Интернет. Следовательно, национальность разработчиков, частных лиц тоже не может быть критерием для определения “гражданства” дистрибутива.
Если нивелировать “косметические” детали (логотип, название, значки, обои и т. п.), то функциональная разница между, например, Fedora и Open SUSE окажется пренебрежительно мала.
Благодаря перечисленным выше фактам сегодня выбор дистрибутива Linux для рабочей станции сводится к переключению внимания между двумя системами управления пакетами — deb и rpm и двумя декстопами — GNOME и KDE. При этом сравнение дистрибутивов-кандидатов почти всегда производится по второстепенным для пользователя техническим параметрам, один из которых — название. Выбор дистрибутива Linux — это на самом деле выбор поставщика, владельца копирайта.
Вернемся к вопросу о “российском дистрибутиве Linux”. Слово “российский” — это статус, который говорит о том, что государство прямо или косвенно заинтересовано в развитии именно этого дистрибутива. Такая заинтересованность может быть, когда государство влияет на дистрибутив, например, через его поставщика. Государству управлять дистрибутивом Linux значительно проще, когда его поставщик — юридическое лицо, резидент.
Таким образом, российским можно назвать любой дистрибутив Linux, поставщик которого — резидентное юридическое лицо, обладающее копирайтом на название дистрибутива и отвечающее за использование авторских и смежных прав по российскому и международному законодательству.
PC Week: В юридическом смысле — безусловно. А в технологическом, применительно к известному тезису о безопасности, вытекающей из независимости? Согласитесь, налепить юридически значимый шильдик и реально контролировать разработку — совершенно разные вещи.
Современный дистрибутив — это очень много кода. Даже его инспекция требует серьезных ресурсов. Мне трудно поверить, что небольшие российские СПО-компании готовы поручиться за каждую строчку кода в якобы своих дистрибутивах.
Н. Г.: Безусловно, “российский” — это статус, юридическая характеристика. “Безопасный” — это соответствие требованиям, техническая характеристика. Из первого не следует второго и наоборот. Иначе получаем абсурд: “немецкий — значит безопасный” или “безопасный — значит китайский”.
“Независимость” дистрибутива Linux — это просто заблуждение. Как было показано ранее, любой дистрибутив Linux — всегда больше акцептор мэйнстрима, чем донор. Следовательно, он всегда зависим, безотносительно “гражданства” и т. д.
Смешивание понятий “государственной принадлежности”, “независимости” и “безопасности” приводит к взаимной подмене, вводит в заблуждение общественность, ухудшает характеристики любого дистрибутива Linux в силу возрастания неопределенности функции оценки и ее граничных условий.
PC Week: А как же контроль разработки?
Н. Г.: Следует оставить иллюзии о том, что отдельная “крупная компания”, даже российская, сможет гарантировать безопасность через контроль всего цикла разработки дистрибутива Linux. Для такого контроля надо назначить своих мантейнеров хотя бы в самых ответственных частях разработки операционной системы:
- — ядро;
- управление пакетами — www.redhat.com, www.debian.org;
- системные утилиты — www.gnu.org/software/software.html;
- пользовательский интерфейс — www.kde.org, www.gnome.org;
- драйверы устройств Intel, AMD, Nvidia и др.
У меня нет иллюзий, когда я смотрю на список организаций-разработчиков, но есть большие сомнения, что у какой-либо “крупной компании”, даже российской, хватит квалифицированных ресурсов (для справки: в репозитории дистрибутива Debian более 10 000 пакетов. — Прим. С. Г.), воли и влияния, чтобы назначить своих мантейнеров во всех ответственных частях разработки Linux.
При этом мы должны ясно различать мантейнеров (последняя инстанция в разработке систем) и пересборщиков. Первые оказывают реальное влияние на программистов и продукт. Вторые запускают команду make для уже отлаженных, заимствованных пакетов.
Из чего следует, что любая компания, которая готова “поручиться за каждую строчку кода в якобы своих дистрибутивах”, подобна игроку в мизер с длинной мастью без семерки, когда на прикупе два туза. Размер не имеет значения, ибо утверждение — блеф.
PC Week: А что же может обещать пользователю добросовестная компания?
Н. Г.: Добросовестный поставщик дистрибутива Linux может гарантировать только исправление найденных ошибок в собственном дистрибутиве, передачу исправленного исходного кода мантейнерам мэйнстрима и публикацию собственных разработок и улучшений под свободной лицензией.
При этом нет никакой гарантии, что мэйнстрим примет добровольные пожертвования по двум последним пунктам. К примеру, улучшения сугубо локального характера имеют низкий приоритет у мантейнеров мэйнстрима.
Говоря о безопасности информационных систем, мы должны ясно понимать, что это привилегия государства. Процедура сертификации на безопасность формализована и выполняется в рабочем порядке компетентными организациями. Из чего следует, что проще получить сертификат ФСТЭК, чем пространно рассуждать об инспекции всего исходного кода собственными силами, тем более тратить на это ресурсы.
Как видим, критерий “безопасность” не связан с размерами компании — поставщика дистрибутива Linux, так же как статус “российский” не связан с национальностью отдельных разработчиков.
Для доказательства верности вывода напрашивается пример дистрибутива Slackware Linux, который достаточно популярен и поддерживается фактически одним человеком, Патриком Волькердингом.
PC Week: Правильно ли я вас понял — ни один российский поставщик дистрибутивов не имеет возможности для полной инспекции кода?
Н. Г.: Совершенно верно. Хочу лишь уточнить, что не только российский, вообще ни один поставщик дистрибутива Linux в мире не имеет практической возможности полной инспекции кода без риска отставания в выпуске новых версий.
Обратимся к официальной статистике The Linux Fundation по разработке ядра Linux, версия 2.6.30. Ежедневные изменения, измеренные в строках исходного кода, таковы:
- добавлено новых строк — 12993;
- изменено существующих строк — 4958;
- удалено старых строк — 2830.
Безусловно, такой объем изменений в коде неизбежно порождает новые ошибки. Подсчитано, что приблизительно один раз в четыре дня новые изменения приводят к нарушению работоспособности старых, отлаженных участков кода. Это порождает повторное внесение изменений в исходный код, и цикл разработки замыкается. В разработке ядра Linux 2.6.30 было задействовано свыше 1000 профессиональных программистов из более чем 500 коммерческих компаний. Четверка компаний, внесших максимальный вклад в разработку ядра Linux, выглядит так: Red Hat — 12,0%; IBM — 6,3%; Novell — 6,1%; Intel — 6,0%.
Таким образом, компания, которая сможет производить регулярно полную инспекцию кода только ядра Linux, должна иметь штат системных программистов не менее 1000 человек и обладать научно-техническим потенциалом, соизмеримым с суммарным научно-техническим потенциалом лидеров по вкладам в ядро Linux. Я таких компаний не знаю.
Заметим, что мы проанализировали статистику разработки хоть и важного, но всего одного пакета ОС Linux из 10 000 существующих.
PC Week: Стало быть, задача по полному инспектированию кода нереальна, поскольку программы очень большие и потребуется слишком много специалистов?
Н. Г.: Не только по этой причине. Не стоит забывать, что исполняемый код любой современной операционной системы состоит из двух частей: явной части, записываемой на жесткий диск в момент установки, и неявной части, присутствующей на компьютере в виде BIOS и микрокода встроенных и периферийных устройств.
Разработка микрокода не поддается внешнему контролю и находится монопольно во власти поставщиков устройств. Иными словами, любой может взяться за полную инспекцию исходного кода, однако практическая ценность скорее окажется сомнительной хотя бы потому, что за время полной инспекции успеют не раз смениться версии, системы и платформы.
PC Week: То есть поиск ошибок и “закладок” на практике невозможен? Скажем, ваша компания не поручится за то, что где-то в недрах OpenOffice.org скрыта какая-нибудь вредная “закладка”?
Н. Г.: Если вы еще не столкнулись с ошибкой в программе, то это вовсе не значит, что в программе ошибок нет. Это известно любому специалисту в области разработки больших систем.
OpenOffice.org —именно такая система (в этом пакете более 70 000 файлов с исходным кодом. — Прим С. Г.). В больших системах важен не столько факт обнаружения ошибки, сколько оценка ее критичности и скорость исправления критичных ошибок. При этом ошибки с низким приоритетом могут не исправляться годами, когда подавляющее большинство пользователей с ними не сталкивается. Это касается всех больших программ, а не только свободных. Именно поэтому любые лицензии EULA передают программу на условиях “AS IS” без каких-либо дополнительных гарантий.
Говоря о закладках, надо понимать, что легче обнаружить их, исследуя работу программы со стороны среды исполнения, чем вглядываясь в гигабайты ежедневно обновляемого исходного кода. Тем более что угроза безопасности может появится без умысла, а вследствие ошибки программиста, как это было с червем Морриса, парализовавшим в 1988 г. все крупнейшие вычислительные центры США.
Таким образом, безопасность современной большой системы обеспечивается не аудитом исходного кода в момент его создания (это на практике невозможно), а скоростью локализации проблемы в случае ее выявления. И тому есть немало примеров. Так:
- 10 сентября 2007 г. AMD представила четырехъядерный процессор Opteron;
- 3 декабря 2007-го компанией AMD была опубликована информация о наличии в процессоре критической ошибки в кэше 3-го уровня;
- 5 декабря 2007 г. были опубликованы исправления для ядра Linux;
- в течение декабря 2007-го про аналогичные исправления для MS Windows не было известно ничего;
- 2 июня 2009 г. поиск в базе данных Microsoft исправлений по ключевым словам “Opteron” и “tlb bug” дал отрицательный результат.
PC Week: Так все-таки, возможно ли создать ГосОС на базе открытого кода, или все разговоры о безопасной и подконтрольной государству ГосОС на основе Linux — либо заблуждение, либо спекуляция?
Н. Г.: Безусловно, можно создать безопасную и подконтрольную государству ОС на основе Linux, если отказаться от спекуляций и заблуждений. Подконтрольная государству ОС на основе Linux появляется в условиях, когда поставщик — юридическое лицо, резидент, обладающий достаточной компетенцией и авторитетом в международном сообществе, чтобы оперативно вносить изменения в исходный код при обнаружении ошибки. И такие изменения принимаются в мэйнстрим.
PC Week: Вы постоянно говорите о технологической безопасности. Но ведь есть еще и безопасность в политическом смысле. Та, про которую в свое время говорил Виктор Алкснис. Безопасность не как технологический акт, а как доминирование в разработке.
Н. Г.: Безопасность государственной операционной системы — это не дискретная величина с чьей-либо гарантией, а вероятностная, зависящая от условий. Самая высокая вероятность безопасности может быть получена, когда государство контролирует синхронное производство и программной, и аппаратной частей вычислительных систем, включая микрокод.
В современных условиях, когда операционная система Linux создается коллективно, где разделение ответственности ведущих участников происходит согласно их компетенции, есть только один способ повышения безопасности — стать авторитетным разработчиком мэйнстрима в области компетенции, признанной другими участниками. Для этого необходим интеллектуальный потенциал, а у российских разработчиков его достаточно. Именно об этом, на мой взгляд, говорил Дмитрий Анатольевич Медведев на встрече с разработчиками СПО 21 сентября 2007 г., указывая курс на независимость России в области информационных систем.
PC Week: Спасибо за беседу.