Хорошо, то что описано на предыдущих страницах позволяет создать какой-то объект и позволить ему исполнять свой собственный код до посинения. Мы имеем, фактически, конструктор для создания систем. Это ещё не система, не так ли.

Я уж молчу о том, что в системе должны быть стандартные службы. Это очевидно.

Нужна ещё одна принципиальная вещь. Тоже служба, но специфическая.

Служба имён.

В традиционных ОС с этим делом бардак страшный - каждая система располагает кучей пространств имён, часто очень беспорядочно организованных. Имена файлов, хостов в сети, номера сокетов TCP/IP, имена протоколов, сетевых интерфейсов, пользователей, групп, да чорт ещё знает, чего. В NT, например, в ядре, есть своя таблица имён объектов ядра. Зачем? А вот. Имеет право. :-)

Какие службы имён нужны. Ну, во-первых, список классов - без него сама система работать не будет, ибо привязка идёт по именам.

Во-вторых, представляется разумным, чтобы каждая подсистема предоставляла каталоги объектов, являющихся точками входа в неё. Например, для сетевой подсистемы это будут каталог объектов, предоставляющих сетевой доступ. Нет, не сокеты TCP/IP, X.25 и X10 - это всё делается через создание объекта нужного типа - new system.socket( host, port ), например. Речь идёт про объекты, представляющие, например, microsoft network (каталог доступных хостов). Для SCSI- и USB-подсистем - каталог доступных на шине устройств. Ну и т.п. - конкретика, уместная в рамках подсистемы.

Каталоги псевдонимов

Ну, гм, конечно, можно писать new .map.russia.moscow.baryshikha-40-1-110.dz.socket, но, наверное, это неправильно по нескольким причинам. Уже, хотя бы, ввиду того, что реализация сокетов может измениться и следующая версия будет сделана кем-то другим.

Нужно что-то типа псевдонима. .system.alias.socket? .alias.socket?

Настройки.

Параметризация системы, видимо, неизбежна. В конце концов, должна же быть возможность указать IP-адрес, нет? :-)

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

Имея группы объектов таких классов любой шелл сможет в присущем ему стиле сообразить панель управления для любой службы уж сам, как-нибудь. Это избавляет службы и вообще приложения от завязок на детали построения интерфейса пользователя, а шелл (шеллы) - от завязок на конкретику системы параметров. Не нужен графический шелл - всё то же можно настроить и с командной строки. Поставил новый window manager - все панели управления сменили стиль.

И, главное, захотел запрограммировать настройки - ради бога. Захотел настроить по сети - вперёд. Захотел DHCP? Нет проблем, ясно, как и куда его пристегнуть.