>[оверквотинг удален]
>файл можно выгрузить подретактировать и импортировать снова, в репазитории храниться 3-и
>снапшота конфигурации каждой службы, тоесть первый снапшот создаётся при импортирование, второй
>при старте службы, третий при её изменение, тем самым позволяя делать
>откат изменений, далее SMF следит за состояние служб, если служба по
>какой-то причине падает, то SMF её перезапускает, если падает какая-то служба
>необходимая для работы этой, то SMF переведёт эту службу в режим
>обслуживания, если упавшая служба была критичной для этой, естественно ведутся логи,
>тоесть это заменя старым скриптам SYS INIT, всё это связано с
>FMA - Fault Management, тоесть это всё единая система, задача которой
>противостоять сбоям, производиить самодиагностику и востоновление после сбоев...:)

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

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

Реестр - это бинарный файл (файлы).
А когда применяются бинарные файлы?
1) Для упрощения работы пионэров-программистов. Им лень или они просто не знают нужных средств в языке.
2) Для подсаживания клиента на "иглу". Очень выгодно для коммерческого ПО.
3) Для ускорения обмена информацией. Фактически речь уже идет о базе данных.

Где здесь место для описания настроек программы, которые один раз считали из файла и держим в памяти?

Есть некоторые идеи по хранению настроек программ в MySQL, например. Идея имеет право на жизнь. Наверное, хостерам с огромной клиентской базой это будет удобно. Админам огромного количества серверов, наверное, это тоже покажется удобным. НО!

Полагаю, что при наличии транзакций, нормальных локов и версионности в файловой системе, аналогичный инструментарий может работать и с обычными текстовыми конфигами. И даже в распределенной среде c централизованным управлением. Примеры есть. Возьмите хотя бы Check Point.

Прелесть UNIX в том, что при всей его мощности и кажущейся сложности он остается ПРОЗРАЧНЫМ и понятным, основываясь на таких базовых понятиях как "файл". И то, что в свободных и открытых реализациях до сих пор придерживаются текстовых конфигов - тому подтверждение.