Судя по периодическим сообщениям по телевидению и в Интернете, в настоящий момент речь об информационной безопасности страны вообще не идет - на ноутбуки чиновников через их Windows можно ходить как к себе домой. Эта же ОС используется и в правоохранительных органах, вспомните комментарии по делу Поносова. Linux проблемы не решает как потому, что является некачественно, хоть и бесплатно, переписанным Windows, так и потому, что не угрожает Microsoft в мире настольных приложений, как верно отмечено в просочившихся Хэллоуинских документах. Ведь переход на иной API потребует столько сил, что цена будет огромна. Все мы надеемся, что Microsoft скорее исправит недостатки, чем заставит нас уйти.

С другой стороны, и уходить некуда. Ведь что мы видим? Каждая попытка прикладных специалистов - биолога, физика или специалиста по библиотечному делу - сделать шаг вперед сопровождается новым видением данных и новым алгоритмом их обработки. Ликбез в школе проведен, все знают, что такое компьютер, и в состоянии изложить свои задумки на алгоритмическом языке. Дальше начинается поиск финансирования - чиновники, фонды, выдающие гранты. Не так уж редко до демонстрации крупного результата начинаниями движет только энтузиазм авторов, причем и в нашей, и в других странах. В таких случаях мы наблюдаем, что население не в состоянии перелить с алгоритмического языка на язык программирования и получить работающее ПО... на любой платформе. Неспособны получить визуализацию. Системно решив их проблему, мы не только поможем энтузиастам, но и сэкономим деньги на казенных проектах. За рубежом вся катастрофа в совокупности уже обозначена как необходимость создания нового поколения масштабируемого и простого в написании ПО (см., например, "Report to the president. Computational Science: Ensuring America's Competitiveness. President's Information Technology Advisory Committee. June 2005"). В этой связи Китай поступил крайне недальновидно, клонировав западную индустрию в национальной ОС Kylin. Чтобы это не повторилось, автор хотел бы указать на совершенные ошибки и предложить пути их исправления.

Тайна, скрытая от общественного сознания, состоит в том, что Запад спроектировал написание интерфейса с расчетом на когнитивные способности, которыми средний человек не обладает. Чтобы доказать это, разумеется, нужно предъявить другие средства, несовпадающие с уже известными индустрии. И проследить, чьи интересы это затрагивает. Автор имел возможность глубоко изучить вопрос в рамках обсуждения в международной организации по стандартизации HTML (см., например, w3.org/Search/Mail/Public/search?keywords=Dmitry+Turin), а также в закулисной переписке, которой это обсуждение сопровождалось. Разумеется, нет никакой государственной программы США, которая запрещала бы усовершенствования, но каждая фирма стремится создать препоны, чтобы пользователь не вздумал скопировать ПО и уйти, не заплатив. Основные деньги корпорации получают, не продавая программы, а обучая пользоваться ими. Правда, что касается W3-консорциума, есть у него в хартии пункт, запрещающий улучшения в явном виде, а именно - применение дублирующих технологий. Периодически вспыхивает агитация за отмену этого пункта, но протесты, перегорев, плавно сходят на нет. Все мы бессознательно воспринимаем международные организации как созданные пользователями и для пользователей, на самом деле скинулись мужчины, у которых деньги есть. Да и скинулись, в основном, чтобы перекрыть ветер в паруса конкурентов. Кроме W3C, автор имел возможность убедиться в этом и в ISO JTC1 SC32 WG3, где ключевые посты заняты представителями Oracle, Microsoft и IBM. Отсюда и расходы на программиста, например, под Oracle превышают стоимость дистрибутива Oracle. Отсюда и бoльшая цена программ по сравнению со стоимостью схемотехники (стоимостью материального производства!). Но мало кто задумывался, что это создано искусственно и сакрализировано (автор устал читать о сакральном в книгах серии "PHILOSOPHY").

Чем вообще отличается нормальная работа пользователя от ненормальной, из каких частей она состоит? Берусь утверждать, что это - доступ к данным, отображение данных и наблюдение данных. Рассмотрим эти три составляющие подробно.

Доступ по третьей парадигме

За всю историю существования компьютера было три парадигмы хранения данных. Их отличительными особенностями являются:

• для 1-й - команда 'move file', сдвигавшая весь файл целиком и расширявшая свободное пространство между файлами для записи нового файла;
• для 2-й - разделение файлов на кусочки одинакового размера, помещение кусочков в свободные места винчестера и перечисление этих мест в специальном файле-невидимке (FAT);
• для 3-й - хранение структур и отказ от концепции файлов (структуры используются всегда, за исключением редких по сравнению с бизнесом научных вычислений с массивами).

В последнем случае структуры ссылаются друг на друга по физическому адресу, доступному только для сравнения и для перехода к структуре, связанной с данной. К несчастью, изобретатель третьей парадигмы (Кодд) не имел доступа к ядру какой-либо ОС и не мог ее туда вмонтировать. И что еще более печально, он слил систему хранения с одной из многих возможных машин вывода и сделал физический адрес недоступным из-за ненадобности для этой машины - и этими двумя поступками смутил все последущие поколения разработчиков. Результат называется СУБД и состоит из части ОС и из машины вывода для оператора 'join' - и ни разработчики ОС, ни разработчики машин вывода не могут разделить эти два факта в своем уме.

Автор настоящей статьи столкнулся с этим, когда задумал машину вывода, делающую перспективную проекцию 3D-фигур в окно программы с помощью единственной функции 'printg ("SELECT * FROM GroupsTable.FiguresTable.TrianglesTable.PointsTable WHERE ...")', аналогичной функции 'printf' языка С для вывода текста (подробности ниже). Безотносительно к тому, правильное решение принял автор для 3D-фигур, неправильное - он вынужден прикрепить свою машину к СУБД, а не к ОС, потому что в ОС третья парадигма не реализована. Сбросьте пелену с глаз, повседневная реальность вообще комична - бизнес-приложения используют машину вывода 'join' для извлечения по одной структуре без всякого вывода.

Сегодня в нашей индустрии наблюдается помутнение умов - что-то похожее на танцевальную лихорадку или тюльпанную лихорадку в средневековой Европе. Кто-то на этом делает деньги. Произошел откат от структурного мировозрения к файловому: юниксовая концепция "всё есть файл" снова стала повсеместной, скатились даже до хранения XML. Не будем описывать здесь это в деталях, благо разоблачение XML-СУБД, представленное на сайте debank.com, вы можете без труда экстраполировать на всю юниксовую концепцию. Мы же отметим, что буфера при отказе от неё заменяются на транзакции. Стандартный поток вывода stdout - на небуферизированную доставку из одного хранилища в другое, запуск которой сам по себе начинает новую транзакцию ("сегмент отката" - в терминах Oracle - все-таки буфером не является). Стандартный поток ввода stdin заменяется на условие для триггеров AFTER OUTSIDE, действительное только в случае, если структура была добавлена, изменена, удалена или прочитана другим триггером, не состоящим с данным триггером в одной программе. Вложенные директории заменяются на вложенные схемы.

О другом далеко идущем следствии нужно сказать особо. Триггера становятся общим инструментом обработки данных; это означает, что программы состоят из тел триггеров (один специальный триггер висит не на какой-либо структуре, а на событии "старт программы"), их запуск поддерживается ОС, отсутствует понятие демон. Но нереализованность третьей парадигмы блокировала переход к асинхронному программированию. Которое предполагает, что условие срабатывания триггера не заставляет, а именно разрешает выполнение его тела. Если нет свободного процессора, тело может и подождать. Триггеры можно не только удалять и создавать, заново определяя их тела, но и дезактивизировать и активизировать их. Создавать вложенные триггеры, вкладывать и извлекать один триггер в другой. И работать по новой методологии: сначала разрабатывать набор независимых модулей, а затем добавлять связывающие ограничения.

Необходимость этого уже вылезла в аппаратуре под названием "стена памяти". В то время, как за один такт процессор в состоянии выполнить несколько команд, на единичный доступ к межпроцессорной памяти уходит около сотни тактов. И все из-за того, что ядра и АЛУ ждут окончания выполнения команды, и изменения порядка выполнения команд оказывается недостаточно. Соответственно, все задачи делятся на CF (cash friendly) с частыми обращениями по последовательным адресам или непоследовательно, но к одним и тем же ячейкам, - и на DIS/DIC (data intensive system/computing) с обращениями по слабо предсказуемым, практически случайным адресам. Но почти все современные задачи - управление социально-экономическими системами и войсками, криптоанализ, создание генных лекарств и оружия, предсказание погоды, климата, распространение загрязнений, проектирование крупногабаритных самолетов и кораблей - относятся ко второму классу. На них техника показывает производительность на три порядка ниже (osp.ru/os/2008/01/4836914), и повышают ее, отказавшись ожидать память и предоставив ей самой прислать запрошенные данные. Аналогичную асинхронность вводят в общении между ядрами и между процессорами. Естественным отображением на языки высокого уровня является асинхронное программирование и третья парадигма, которые уперлись в намеренно созданный файловый контроль доступа.

Масштабируемый доступ

Язык запросов более гибок и удобен для сбора данных из нескольких хранилищ и распределение их в несколько хранилищ, чем частные программы. Но нет необходимого синтаксиса - попробуем его создать. Рассмотрим на примере SQL. Первое, пусть каждое хранилище получит прозвище. Прозвище будет в запросе перед именем таблицы через двоеточие - как в sql50.euro.ru/sql5.19.2.pdf на с.121. Второе, группу хранилищ назовем обществом. Общество также указывается перед именем таблицы через двоеточие и означает прозвища всех хранилищ, входящих в группу (с.123). Таким образом одно sql-выражение с обществом означает множество sql-выражений с прозвищами. Кроме того, чтобы несколько обществ или несколько упоминаний одного общества никогда не указали на одно и то же хранилище одновременно, поместим перед ними символ %; а чтобы несколько упоминаний одного общества наоборот всегда синхронно указывали на одно и то же хранилище, поместим любое слово (одинаковое) и символ % перед этими упоминаниями (с.122-123, 126-128). И третье, введем понятие хранилище по умолчанию - в нем хранятся все прозвища и все общества. Без специальных указаний это - первое хранилище, к которому клиент приконнектился; потом его можно поменять. В целях безопасности распределенные запросы должны удовлетворять некоторым требованиям. Предлагаю концепцию полного недоверия одного хранилища другому (первые три пункта) и концепцию крайней простоты клиента (последний пункт):

• хранилище не содержит логин другого хранилища - чтобы при взломе не отдать еще и чужой логин;
• хранилище не редактирует (изменяет, вставляет, удаляет) данные другого хранилища - чтобы временный доступ к одному хранилищу, полученный при взломе, не мог разрушить другое хранилище;
• если это возможно, хранилище не получает данных из другого хранилища - чтобы при взломе не стали доступны данные еще и из другого хранилища;
• клиент не знает SQL - не упрощает и не производит декомпозицию SQL.

Таким образом одно хранилище не может ввести sql-команду в другое хранилище ни прямо, ни косвенно (прося клиента перенаправить команду). От клиента не требуется создавать новую sql-команду путем парсинга ситуации, но предполается умение запомнить отправленные команды в стеке и при необходимости совершить элементарные текстовые замены в них и повторные отправки. Т.е. при взаимодействии клиента сразу с двумя хранилищами команда отправляется сначала в одно, затем посылает клиенту специальное уведомление, прося сделать подстановку в только что отправленной команде и выслать результат преобразования второму хранилищу. Специальные уведомления должны быть настолько ограниченными, чтобы не допускать порождения sql-команды, вредной для второго хранилища. Теперь нам удобно делать репликацию, аггрегировать данные со множества серверов. Содержимое бинарных протоколов нам нужно как-то зарисовывать в чертежах и документах, предлагаю sql-команды записывать просто текстом, данные - в xml-виде, а уведомления как <?command/?> (с.133, 149, 171).

Чтобы несколько раз включить и выключить ноутбук в течение одной длинной транзакции, длящейся дни или даже недели, достаточно ввести оператор FREEZE, подобный DISCONNECT, который сохранит транзакцию в текущем состоянии; и оператор UNFREEZE, подобный CONNECT, который продолжит транзакцию с замороженного состояния, т.е. не начнет новую, как CONNECT. FREEZE возвращает идентификатор замороженной транзакции, который должен быть указан в UNFREEZE. На случай падения одного хранилища во время распределенной транзакции предлагаем оператор POSTPONE для заморозки на второй стадии двухстадийных и трехстадийных COMMIT, называемых на жаргоне 2PC и 3PC, и оператор ADJOURN для заморозки на третьей стадии трехстадийных COMMIT.

(Продолжение следует)

Дмитрий ТЮРИН,
dmitryturin.narod.ru