Причина очевидна. В Linux каждая программа хранит сведения о своих настройках отдельно. Единой же точки, откуда программы могут получать сведения друг о друге, фактически нет. Поэтому каждое взаимодействие организуется специальными указаниями. Оконные диспетчеры вроде KDE или Gnome берут на себя лишь очень малую долю такой организации — не могут же они учесть все возможные места хранения информации о программах!
В операционных системах обширного семейства Windows ныне порядок принципиально иной. Все сведения обо всех программах хранятся в единой базе данных — системном реестре. Оттуда любая программа может узнать, кто и как выполняет необходимые для неё внешние функции.
Основная задача реестра — организация взаимодействия по системе COM (Component Object Model — модель объекта из компонентов), где любая сложная структура состоит из множества слабозависимых компонентов и за каждый вид обработки каждого компонента может отвечать отдельная программа. Правда, СОМ — лишь сильно упрощённая версия системы CORBA (Common Object Request Broker Architecture — общая архитектура брокера объектных запросов), употребляемой в операционных системах семейства Unix, из которого выросла Linux. Но для неквалифицированного конечного пользователя — вроде меня — СОМ несомненно удобнее CORBA — прежде всего как раз благодаря единой точке описания всех взаимодействий.
Увы, единый системный реестр обладает собственными немалыми недостатками. Главный из них — любая ошибка работы с ним одной из программ способна разрушить всю внутреннюю логику базы данных и заблокировать любые осмысленные обращения. Чаще всего это происходит при установке новых программ: чтобы перенаправить на себя определённые вызовы, они правят уже существующие записи в базе. Но авария возможна и при многих других обстоятельствах. В частности, общесистемный сбой, сопровождаемый BSOD (Blue Screen Of Death — синий экран смерти), может разрушить все записи реестра, к которым в этот момент были обращения хотя бы на чтение.
Вдобавок сведения в реестре хранятся в двоичном виде. Это вроде бы чуть ускоряет их поиск и обработку. Зато и найти в реестре нужные данные можно только с помощью специальных редакторов. А уж исправление ошибок требует сверхъестественных усилий. Чаще всего повреждения в реестре устраняют хирургически: переустанавливают всю систему с нуля.
В ранних версиях Windows — до 3.11 включительно — в системном реестре хранились только сведения, важные для всех программ, вроде координат системных шрифтов и указаний, файлы и запросы каких типов какая программа может обрабатывать. Причём всё это описано обычным текстом, так что найти сведения и исправить ошибки можно буквально на глаз. Настройки же каждой программы, интересные только ей самой, она хранила в отдельных файлах — и чаще всего даже не в общесистемном каталоге, а в собственном.
Конечно, у такой системы есть свои накладные расходы. Перевод реестра из текстовой формы во внутреннюю требует какого-то времени при каждой загрузке системы. Организация доступа к индивидуальным настроечным данным падает на плечи отдельных программистов — и далеко не все справляются с этой нагрузкой эффективно. Словом, резоны, заставивших Microsoft в дальнейших разработках перейти на единый реестр, очевидны.
Но столь же очевидны и издержки избыточной интеграции. Выше приведен далеко не исчерпывающий перечень. Скажем, некоторые настройки могут раскрыть тонкости внутренней структуры программ, в чём заинтересованы далеко не все авторы: понятие коммерческой тайны всё сильнее ломает информационные технологии. Поэтому системные запросы к реестру ограничивают полномочия программ — но просмотреть реестр можно и в обход этих запросов.
Взаимодействуют не только программы. Развитие рынка в немалой степени определяется возможностями сотрудничества специализированных бизнесов. Для этого им жизненно необходимо знать о возможностях друг друга.
В советское время все производства и услуги принадлежали государству. Оно вело единый реестр и стыковало всё необходимое для решения конкретных задач. Увы, издержки такой централизации побольше, чем у системного реестра Windows: в статье «<а href=“http://awas.ws/OIKONOM/СОММСОМР.НТМ’’>Коммунизм и компьютер» я рассмотрел лишь очевиднейший источник неэффективности. Так что BSOD, закрывший коммунизм в 1991-м, был неизбежен.
Нынче у нас — анархия в стиле Linux:[45] бизнесы узнают друг о друге лишь из рекламы, чья достоверность сомнительна, а эффективность ничтожна уже хотя бы потому, что просмотреть весь рекламный поток физически невозможно. Поэтому зачастую приходится развивать у себя вспомогательные структуры, хотя их работу могут куда дешевле сделать сторонние специалисты.
Очевидна потребность в информационных структурах, собирающих сведения обо всех бизнесах ради формирования по запросам партнёрств, решающих конкретные задачи. Кто возьмётся за эту работу, пока почти свободную от конкуренции, зато способную резко поднять эффективность всей экономики?
Право подчинения[46]