Системный реестр: что нужно бизнесам знать друг о друге

Прослушать новость

Настраивая на своём ноутбуке новую для меня операционную систему Linux, хотел, чтобы по ссылкам на Интернет из других программ вызывался браузер Opera. Указал это всюду, где нашёл упоминания браузера по умолчанию. Но из почтовой программы Thunderbird всё ещё вызывается стандартный в оконном диспетчере KDE браузер Konqueror.

Правда, меня бы это устроило: Konqueror построен на том же ядре Gecko, что и сверхпопулярный нынче Firefox, так что работать с ним почти так же удобно, как с Opera. Но почему-то каждая ссылка открывается в новом окне, хотя я специально предписал Konqueror открывать все внешние ссылки в новых страницах одного и того же окна.

Причина очевидна. В Linux каждая программа хранит сведения о своих настройках отдельно. Единой же точки, откуда программы могут получать сведения друг о друге, фактически нет. Поэтому каждое взаимодействие организуется специальными указаниями. Оконные диспетчеры вроде KDE или Gnome берут на себя лишь очень малую долю такой организации — не могут же они учесть все возможные места хранения информации о программах!

В операционных системах обширного семейства Windows ныне порядок принципиально иной. Все сведения обо всех программах хранятся в единой базе данных — системном реестре. Оттуда любая программа может узнать, кто и как выполняет необходимые для неё внешние функции.

Основная задача реестра — организация взаимодействия по системе COM (Component Object Model — модель объекта из компонентов), где любая слож-ная структура состоит из множества слабозависимых компонентов, и за каждый вид обработки каждого компонента может отвечать отдельная программа. Правда, COM — лишь сильно упрощённая версия системы CORBA (Common Object Request Broker Architecture — общая архитектура брокера объектных запросов), употребляемой в операционных системах семейства Unix, из которого выросла Linux. Но для неквалифицированного конечного пользователя — вроде меня — COM несомненно удобнее CORBA — прежде всего как раз благодаря единой точке описания всех взаимодействий.

Увы, единый системный реестр обладает собственными немалыми недостатками. Главный из них — любая ошибка работы с ним одной из программ способна разрушить всю внутреннюю логику базы данных и заблокировать любые осмысленные обращения. Чаще всего это происходит при установке новых программ: чтобы перенаправить на себя определённые вызовы, они правят уже существующие записи в базе. Но авария возможна и при многих других обстоятельствах. В частности, общесистемный сбой, сопровождаемый BSOD (Blue Screen Of Death — синий экран смерти), может разрушить все записи реестра, к которым в этот момент были обращения хотя бы на чтение.

Вдобавок сведения в реестре хранятся в двоичном виде. Это вроде бы чуть ускоряет их поиск и обработку. Зато и найти в реестре нужные данные можно только с помощью специальных редакторов. А уж исправление ошибок требует сверхъестественных усилий. Чаще всего повреждения в реестре устраняют хирургически: переустанавливают всю систему с нуля.

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

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

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

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

В советское время все производства и услуги принадлежали государству. Оно вело единый реестр и стыковало всё необходимое для решения конкретных задач. Увы, издержки такой централизации побольше, чем у системного реестра Windows: в статье «<a href=“http://awas.ws/OIKONOM/COMMCOMP.HTM”»Коммунизм и компьютер</a>» я рассмотрел лишь очевиднейший источник неэффективности. Так что BSOD, закрывший коммунизм в 1991 м, был неизбежен.

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

Очевидна потребность в информационных структурах, собирающих сведения обо всех бизнесах ради формирования по запросам партнёрств, решающих конкретные задачи. Кто возьмётся за эту работу, пока почти свободную от конкуренции, зато способную резко поднять эффективность всей экономики?