ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Oleg Molochnikov                     2:5030/1527.111 15 Feb 2001  20:18:54
 To : All
 Subject : Линукс 2000. Пути развития.
 -------------------------------------------------------------------------------- 
 

 
 
 >=== Begin L2000.txt ===
 
 Линукс 2000. Пути развития.
 
  Сегодня мало кто сомневается, что в существующем виде Линукс и все его
 реализации (Red Hat, Free BSD и др.) морально устарели и конкурентоспособны с
 Windows 2000 лишь в силу открытости кода и энергии энтузиастов.
  Рыцарские доспехи и вооружение феодальной эры операционных систем мало
 эффективны на современном поле боя. Присмотримся к кругу решаемых современными
 системами задач и попытаемся найти наиболее эффективные решения.
  Вот небольшой список задач, решаемых серверными платформами:
 
  WWW-сервер - программа, реализующая доступ через Internet к данным, хранящимся 
 на сервере в виде файлов или через сервер базы данных.
 Сопутствующие задачи:
 разграничение прав доступа к данным и администрированию WWW подсистемы, системы 
 распределенной загрузки и обеспечения отказоустойчивости на кластерах,
 криптографическая защита.
 
  Сервер баз данных - программа, реализующая доступ (в общем случае) через язык
 структурированных запросов (SQL) к данным в табличном виде, хранящимся на
 сервере в виде файлов.
 Сопутствующие задачи:
 разграничение прав доступа к данным и администрированию СУБД подсистемы, системы
 распределенной загрузки и обеспечения отказоустойчивости на кластерах,
 системы резервирования и восстановления данных,
 системы журнализирования изменений,
 криптографическая защита.
 
  Файловая система - система хранения данных в виде файлов (поименованной области
 информации) на любом из носителей.
 Сопутствующие задачи:
 разграничение прав доступа к данным,
 распределенные файловые системы на кластерах,
 системы резервирования и восстановления данных,
 криптографическая защита,
 системы удаленного доступа
 системы журнализирования изменений.
  Система администрирования. Самая устаревшая и неудобная часть системы, хранящая
 огромную базу данных по пользователям и их правам, настройкам компонент
 программного обеспечения в виде текстовых файлов с комментариями и утилиты для
 работы с этими файлами, часто взаимоисключающие друг друга. Первоначально
 подобный подход имел большие плюсы, облегчающие разработку программного
 обеспечения большим количеством энтузиастов со всего мира, но теперь эта система
 напоминает вавилонскую башню. Имеющая разную архитектуру в различных
 дистрибутивах, и идущая на кучу доморощенных хитростей, чтобы обеспечить
 криптографическую защиту информации, система начинает угрожающе шататься под
 растущей сложностью приложений.
 Уже сейчас многие программы имеют километровые файлы настроек, 98% из которых
 почти никогда не изменяются.
 Сопутствующие задачи:
 разграничение прав доступа к данным и администрированию системы,
 системы резервирования и восстановления данных,
 системы журнализирования изменений,
 криптографическая защита.
 
  Hевооруженным взглядом видно, что многие функции дублируются не однократно.
  Такое положение исторически возникло, что все вышеперечисленные системы
 представлены разными пакетами от разных разработчиков. К чему это приводит?
  Это приводит к следующим плачевным результатам:
 
  1. Система пошла по экспоненциальному пути развития. Она становится громоздкой 
 и все более тяжело управляемой. Груз старых решений сдерживает ее развитие.
  2. Многочисленная авторизация пользователя в каждой из подсистем приводит к
 эффекту "самого слабого звена в цепочки". Hайдя лазейку в криптографической
 системе одной подсистемы, злоумышленник ломает всю систему. Множество
 криптографических решений в разных системах облегчает такую возможность и
 затрудняет модернизацию защиты.
  3. Администрирование системы остается уделом профессионалов. Избыточная
 сложность администрирования заключается как в многократной настройке всех
 систем,
 вызванной раздельным сосуществованием всех пакетов, так и в принципе
 администрирования, заключающемся либо в прямом исправлении текстовых
 километровых файлов, как это делают профессионалы, либо в многочисленных
 утилитах, портящих настройки друг друга. Это существенно снижает внедряемость
 Linux-систем на предприятиях, не говоря уже о десктопных применениях.
  4. Модернизация системы для кластерных применений существенно усложнена, так
 как требуется либо модернизировать каждую из подсистем, либо придумывать их
 функциональные аналоги.
 
  Есть ли выход их этого положения? Есть и не один. Hа мой взгляд, оптимальное
 решение - это упростить систему, выкинув из нее дублирование функций.
  Как это сделать? Как вариант - встроить в ядро часть функций сервера баз данных
 и отказавшись от файловой системы в ее первичном виде. Давайте посмотрим, что из
 этого может получиться:
  Hачнем с постулата: файл - это поименованная область информации.
 Hо ведь для пользователя не важно, как именно хранится информация,  в виде файла
 с иерархическим именем, или в виде иерархии таблиц. Часть таблиц, реализующих
 отображение информации на жесткий диск или другой носитель, становятся
 системными, и с ними работает ядро напрямую, в обход механизма SQL. Программы
 работают с таблицами более высокого уровня. Отдельными таблицами представлена
 информация о пользователях системы и их правах. Конфигурационные файлы программ 
 обычно состоят из названия программной константы, ее текстового описания и
 значения, что легко отображается на табличную структуру.
  Постулат 2: любые данные могут быть представлены в виде иерархии таблиц.
  Это касается и процессов, пользовательских данных и исполняемых файлов.
  Преимущества этого подхода состоят  в простоте и элегантности реализаций
 распределенных файловых систем, уменьшения информационных потоков по медленным
 линиям связи, связанном с селективной выборкой запрашиваемых данных.
  Единый криптографический алгоритм для всей системы, реализуемый в виде модуля
 может быть легко заменен на более совершенный.
  Журнализация изменений данных при таком подходе реализуется легко и элегантно
 для всей системы.
  Упрощается создание средств администрирования системы и инсталляции
 программного обеспечения.
  Безопасность системы поднимается на качественно новый уровень, за счет
 уменьшения числа уязвимых компонент.
 
  Второй вариант или  вариант компромисс. Оставить файловую систему для
 совместимости, но сделать ее через отображение на таблицы.
 Те же преимущества для распределенных систем.
 
  Третий вариант или вариант минимум - просто ввести поддержку СУБД в ядро и
 сделать через нее администрирование системы и компонент.
  Преимущества: Упрощение администрирования, большая защищенность.
 
  В этой статье остались не раскрытыми большое количество проблем, возникающих
 при предложенных подходах. Буду рад услышать Ваше мнение по этому поводу и
 внести соответствующие коррективы. Пишите по адресу milkers@bstu.spb.su
 
 Олег Юрьевич Молочников.
 Hач. отд. ЕКС БГТУ
 Санкт-Петербург
 15 февраля 2001 г.
 >=== End L2000.txt ===
 
 Oleg
 
 ... UCN Fido Point System
 --- GoldED/LNX 3.0.1. e-mail: eks@bstu.spb.su
  * Origin: Nuclear.Com [Enter]... Atomic bomb has activated! (2:5030/1527.111)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор