Вопрос такой. Вот, известно что тот же реестр — это божественный объект. Если файл реестра повредить — то сломается вся операционная система и работать не будет ничего.

При этом было бы здорово этот файл заменить на нулевой, который в чистой Windows — с потерей предпочтений (заставка раб. стола, языки, часовой пояс и т.д.). Но чтобы просто все работало, настройки не так сложно же установить еще раз и это не критично.

Но! Так не получится, т.к. все программы жестко интегрируются в реестр и без него просто не будут работать.

Почему бы не освоить принцип слабой связности — и, к примеру, хранить настройки программы в ее папке? Ну т.е. чтобы оно не ломалось все одним пакетом как бы — а было разделено. ОС сломалась — сбросил до нуля — но это не влияет на установленные программы — если папка с программой сохранилась — то все будет работать без переустановки.

Здравствуйте, Shmj, Вы писали:

S>...

Когда появился реестр? В 95, а то и раньше? Наверное, тогда это им казалось хорошей идеей.
А потом — обратная совместимость. Собственно вся история винды — история про поддержку обратной совместимости начиная с ДОСа.
Читал как-то записки причастных к этому процессу — занимательное чтиво, после этого стал уважать и винду и МС.

S>Почему бы не освоить принцип слабой связности — и, к примеру, хранить настройки программы в ее папке? Ну т.е. чтобы оно не ломалось все одним пакетом как бы — а было разделено. ОС сломалась — сбросил до нуля — но это не влияет на установленные программы — если папка с программой сохранилась — то все будет работать без переустановки.

Сейчас почти всё так и работает.

T>Когда появился реестр? В 95, а то и раньше? Наверное, тогда это им казалось хорошей идеей.
T>А потом — обратная совместимость. Собственно вся история винды — история про поддержку обратной совместимости начиная с ДОСа.
T>Читал как-то записки причастных к этому процессу — занимательное чтиво, после этого стал уважать и винду и МС.

Софт работает с реестром через API.
Могли бы API оставить, а backend поменять.

А отказ от бэкапов реестра (ссылка

Автор: m2user
Дата: 03.09 17:44

) вообще выглядит как диверсия.
Ну какой там footprint от реестра.

Здравствуйте, m2user, Вы писали:

M>Софт работает с реестром через API.
M>Могли бы API оставить, а backend поменять.

Если бы программы лезли в реестр только за своми сеттингами, может быть. Но через реестр кто версию винды проверяет, кто установленный дотнет, кто ещё что. Имхо, менять — шило на мыло получится, один фиг придём к тому, что нужен древовидный system-wide key-value сторадж.
А они там реально за обратную совместимость топят, по крайней мере при Билли так было. Буквально ставят всякие известные программы и проверяют на новых версиях. Подробностей не помню, но реально, когда находили костыли в сторонних известных программах, даже тогда старались не отломать им обратную совместимость.

M>А отказ от бэкапов реестра (ссылка

Автор: m2user
Дата: 03.09 17:44

) вообще выглядит как диверсия.
M>Ну какой там footprint от реестра.

Тут согласен, footprint выглядит как отговорка. Но если честно, бэкап реестра сам по себе такое себе. Хочется бэкап — делай честный бэкап системного диска. Остальное баловство из разряда повезёт/не повезёт заресторить.

M>>А отказ от бэкапов реестра (ссылка

Автор: m2user
Дата: 03.09 17:44

) вообще выглядит как диверсия.
M>>Ну какой там footprint от реестра.
T>Тут согласен, footprint выглядит как отговорка.
Полагаб, просто был в жире таск 'нужно уменьшить футпринт', послали джуниору, джуниору хоть чтото надо сделать, он нашел большие и неиспользуемые в работе файлы и удалил их. И закрыл таск с дескрипшеном 'Я сделялъ!'

Здравствуйте, m2user, Вы писали:

M>А отказ от бэкапов реестра (ссылка

Автор: m2user
Дата: 03.09 17:44

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

M>Ну какой там footprint от реестра.
Ну на текущей машине размер кустов у меня не сильно большой ~250 Мб, но я и пользуюсь ею довольно аккуратно (ничего особо не ставлю и не удаляю)
Но я помню, что на какой-то старой машине эти файлы у меня разрослись до гигабайта, при том что, опять же, я не злоупотреблял установкой какого-то мусора (который потом не чистит за собой).

T>Если бы программы лезли в реестр только за своми сеттингами, может быть. Но через реестр кто версию винды проверяет, кто установленный дотнет, кто ещё что. Имхо, менять — шило на мыло получится, один фиг придём к тому, что нужен древовидный system-wide key-value сторадж.

Распилить БД реестра на куски помельче, чтобы не терять все важные настройки сразу.
Для внешнего приложения ничего бы не изменилось (оно и сейчас не знает ничего ниже API).

МР>Всё же давайте уточним, что не отказ совсем, а отключение этой функциональности по-умолчанию.
МР>Там же ниже приводится алгоритм (просто 1 ключ в реестре) как это резервное копирование вернуть.

Только об этом подумаешь, когда реестр уже сломан

МР>Ну на текущей машине размер кустов у меня не сильно большой ~250 Мб, но я и пользуюсь ею довольно аккуратно (ничего особо не ставлю и не удаляю)
МР>Но я помню, что на какой-то старой машине эти файлы у меня разрослись до гигабайта, при том что, опять же, я не злоупотреблял установкой какого-то мусора (который потом не чистит за собой).

Попробовал 7zip с уровнем сжатия normal — сжал SOFTWARE в 8 раз. Для бэкапов самое то.

Здравствуйте, m2user, Вы писали:

M>Только об этом подумаешь, когда реестр уже сломан
Так оно, конечно...
Но с этим механизмом тоже не всё ладно, как я понимаю (я, правда о нем узнал только от вас, и потом немного почитал по форумам):
— хранится только 1 копия
— перезапись происходит в момент успешного логина пользователя (если через секунду всё рухнет, то мы всё равно уже перезаписали)

Ну и основное, почему рекомендуют использовать точки восстановления — восстановление реестра не консистентно с ФС, поэтому его откат может не помочь, а даже сделать хуже.

Но вообще, я согласен, что средства резервирования/восстановления всегда были немного странными.
Точнее, возможно, они были вполне приличными, но информация о них до простого обывателя не доходила (а может это просто я ленился изучить нормально...)

Здравствуйте, Shmj, Вы писали:

S>Почему бы не освоить принцип слабой связности — и, к примеру, хранить настройки программы в ее папке? Ну т.е. чтобы оно не ломалось все одним пакетом как бы — а было разделено. ОС сломалась — сбросил до нуля — но это не влияет на установленные программы — если папка с программой сохранилась — то все будет работать без переустановки.

Потому, что реестр — это не только "настройки программы".
Реестр, изобретённый в Win 3.11s, был большим шагом вперёд.
1. Это иерархическая БД, с гарантиями атомарности (что было круто по сравнению с тогдашними нежурналируемыми ФС)
2. Это централизованный способ управления всем, помогающий строить экосистему.

МС видела себе ОС не как хранилище разрозненных программ, которые пользователь в силу своего разумения компонует друг с другом, а как экосистему, где программы "знают" друг про друга и помогают пользователю в сложных сценариях.
"Папку программы" пользователь может в некоторых пределах выбирать самостоятельно (в те времена ограничений было гораздо меньше, чем сейчас). Это означает, что программе Y найти программу X без помощи пользователя крайне тяжело. Вот, кстати, какая-нибудь JAVA до сих пор сама себя найти не может без пачки environment variables.
А в реестре всё лежит там, где разработчик предназначил — поэтому, глядя в реестр, можно очень много чего сказать о конкретном пользователе и его машине.
Вот для этой светлой цели всё изобреталось. Чтобы не надо было в настройках каждой программы прописывать руками ссылки на другие нужные ей программы и прочую ерунду, заниматься которой так любят красноглазые.

Важность всяких сценариев типа "пользователь угандошил кусок реестра" или там "пользователь хочет запускать параллельно десять версий паверпоинта, при этом у девяти из них настройки общие, а у десятого — изолированные" тогда казалась незначительной.

Не стоит ожидать больших изменений от микрософта. Видимо все, кто работал в кишках венды, уже на давно пенсии. А новые работают по правилу если работатет то не трогай!, возможно после попыток, окончившихся ничем.
Да и видно это было хорошо. Раньше каждая венда была так или иначе разная, хорошая, плохая но с изменениями. Сейчас в каждой новой венде все то же самое но обязательно меняется кнопка Старт и то, что обязатвльно надо делать: поддержка новых устройств, больше безопасности и т.п.

Здравствуйте, Shmj, Вы писали:

S>Но! Так не получится, т.к. все программы жестко интегрируются в реестр и без него просто не будут работать.

Это вовсе не обязательно, многие программы не срут в реестр.


S>Почему бы не освоить принцип слабой связности — и, к примеру, хранить настройки программы в ее папке?

Многие программы так и делают, но когда-то это жутко тормозило — читать кучу настроек из разных файлов при старте программы.
Реестр же работал со скоростью света, в сравнении с.

Кроме того, АПИ реестра предоставляло общие ср-ва хранения настроек, избавляя отдельные программы от необходимости делать то же самое, но уникально и в меру своей испорченности.


S>ОС сломалась — сбросил до нуля — но это не влияет на установленные программы — если папка с программой сохранилась — то все будет работать без переустановки.

Вот как раз для этого тоже — можно сохранить текущее состояние ОС (В т.ч. реестра прикладных программ) и вернуться к этому состоянию.
В случае хранения настроек в уникальном виде, такой механизм твоей проге недоступен.

Здравствуйте, Sinclair, Вы писали:


S>Потому, что реестр — это не только "настройки программы".
S>Реестр, изобретённый в Win 3.11s, был большим шагом вперёд.
Возможно тогда казалось, что это шаг вперед, но ИМХО они не осилили довести идею до ума, в итоге получился скорее шаг куда-то в сторону.

S>1. Это иерархическая БД, с гарантиями атомарности (что было круто по сравнению с тогдашними нежурналируемыми ФС)

Идея вроде даже правильная. Но реализация.... Эта самая БД хранилась на той же нежурналируемой ФС. В итоге мы вместо того, чтобы защититься от возможных глюков на уровне ФС. Мы квозможным глюкам ФС добавляем еще и глюки этой БД (а глюки были). В итоге у нас была возможность что из-за глюка в какой-то прикладной программы , которой о внутренностях ОС вообще ничего знать не надо, могла накрыться вся ОС.

S>2. Это централизованный способ управления всем, помогающий строить экосистему.

В том-то и дело, что какого-то вменяемого централизованного способа предложено не было. Любая программа писала в реестр все что хотела и куда хотела. А при деинсталяции чистить за собой реестр почему-то считалось дурным тоном. Как минимум, надо было изначально делать какую-то функциональность пакетных менеджеров. Нельзя было позволять кому угодно писать в реестр куда угодно. Более того, должна была быть какая-то возможность почистить настройки реестра за удаленной программой. По идее уже в 95 винде был отдельный пункт в меную "установка и удаление программ", был список установленных программ, была стандартизарованная работа с GUI было API почти для всего, но почему-то никакой стандартизации инсталяторов/деинсталяторов/апдейтеров не было. Если с файловой системой программы все-таки обращались более аккуратно, хотя тоже гадили, то загадить реестр было чуть ли ни принципом хорошего тона и считалось совершенно правильным делом.

S>МС видела себе ОС не как хранилище разрозненных программ, которые пользователь в силу своего разумения компонует друг с другом, а как экосистему, где программы "знают" друг про друга и помогают пользователю в сложных сценариях.

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

S>"Папку программы" пользователь может в некоторых пределах выбирать самостоятельно (в те времена ограничений было гораздо меньше, чем сейчас). Это означает, что программе Y найти программу X без помощи пользователя крайне тяжело. Вот, кстати, какая-нибудь JAVA до сих пор сама себя найти не может без пачки environment variables.
S>А в реестре всё лежит там, где разработчик предназначил — поэтому, глядя в реестр, можно очень много чего сказать о конкретном пользователе и его машине.

Но в итоге получилось, что получилось.

S>Вот для этой светлой цели всё изобреталось. Чтобы не надо было в настройках каждой программы прописывать руками ссылки на другие нужные ей программы и прочую ерунду, заниматься которой так любят красноглазые.

Возможно идея казалось действительно светлой, но в реальности нормально ее реализовать скорее всего невозможно.

В нескольких местах, где я работал, были системы с микросервисной архитектурой и в умах разработчиков возникала светлая мысль, создать некий configuration service, в котором бы все компоненты системы хранили бы свою конфигурацию. При старте они бы могли ее получить, а сервис конфигураций гарантировал бы целостность, версионность, делал бы бекапы, позволял бы избежать дублирования значений, которые нужны разным сервисам, Давал бы сигналы сервисам, если конфиг поменялся и тд. и тп. Изначальная мысль выглядела всегда логичной и правильной. Но к сожалению всегда этот сервис конфигурации превращался в помойку, в которой никто не мог разобраться. Уже через год активного использования, этот общий конфиг выглядел жутким монстром, через 5 лет, уже не было людей посвещенныз в эти тайные знания. Причем это повторялось на нескольких местах работы, везде одни и те же проблемы. В итоге я все таки прихожу к выводу, что сделать нормальное централизованное хранилище конфигов, так, чтобы его вместе использовали разные программы, разрабатываемые разными коммандами разработчиков невозможно. По крайней мере невозможно сделать это красиво для более менее крупной экосистемы.

Здравствуйте, vdimas, Вы писали:

V>Это вовсе не обязательно, многие программы не срут в реестр.

С виндой сейчас работаю немного, так что не знаю как оно сейчас. Но во времена расцвета винды, найти программу, которая не гадит в реестр было практически невозможно. Мне кажется тогда какждый мамкин программист должен был показать всем, что он крутой разработчик и умеет писать в реестр. Но гадили в реестр не только мелкие програмки, гадили в реестр вообще все, при этом никто никогда не подчищал. И винда не предусматривала никаких способов борьбы с этим.

V>Многие программы так и делают, но когда-то это жутко тормозило — читать кучу настроек из разных файлов при старте программы.
Во времена Доса так делали, и ничего страшного, не тормозило. В Windows 3.1 прекрасно помню файлы win.ini и system.ini почему-то тогда не тормозило, а потом стало тормозить? Да и реестр хранится в той же файловой системе. На практике он через некоторое время разбухал настолько, что наичнал тормозить всю систему просто благодаря своим размерам.

Если очень хотчется, то можно хранить настройки системы в бинарном виде, и использовать этот формат для ускорения загрузки системы, но нельзя давать писать туда же настройки всех прикладных программ, пусть даже они хранят, свои настройки в том же формате, и работают через то же api, но пусть хранят отдельно, не хочу я чтобы мой скринсейвер мог переписать мне всю системные настройки.

V>Реестр же работал со скоростью света, в сравнении с.

На только что установленной чистой системе да. Но стоило поставить необходимый минимум программ, начинало все тормозить.
Реестр использовал не текстовый а бинарный формат данных, это ускоряло работу с ним. Но там все хранилось в одном файле, даже настройки неиспользуемых и удаленных программ, этот файл читался при запуске системы. Я не знаю деталей, но, думаю он перечитывался и перезаписывался регулярно при работе программ с ним. Файл постоянно разбухал, и работа с ним была все медленнее и медленнее.

V>Кроме того, АПИ реестра предоставляло общие ср-ва хранения настроек, избавляя отдельные программы от необходимости делать то же самое, но уникально и в меру своей испорченности.

Ну вот оставили бы API, пусть это была бы стандартная бибилиоткека для работы с конфигурационными файлами и стандартный бинарный формат файла. Но нахрена все было писать в один файл.

V>Вот как раз для этого тоже — можно сохранить текущее состояние ОС (В т.ч. реестра прикладных программ) и вернуться к этому состоянию.
V>В случае хранения настроек в уникальном виде, такой механизм твоей проге недоступен.

Предполагаю, что изначально такие идеи были. Но на практике это не работало. Мне кажется просто на это дело забили и не стали доводить до ума. Может конечно столкнулись с какими-то серьезными проблемами при реализации. ИМХО пакетные менеджеры в мире Юникса уже появились в начале 90-х если бы идея единого стандартизированного реестра конфигов была бы соединина с идеей стандартного инсталятора деинсталятора для программ, который бы четко контролировал, какие ветки реестра может изменять данная конкретная программа, и еще если бы этому привязать права доступа, чтоб программа не могла писать не в свои ветки реестра (винда тогда была однопользовательской), то может быть из этого что-то бы получилось.

Здравствуйте, ksandro, Вы писали:
K>Идея вроде даже правильная. Но реализация.... Эта самая БД хранилась на той же нежурналируемой ФС. В итоге мы вместо того, чтобы защититься от возможных глюков на уровне ФС. Мы квозможным глюкам ФС добавляем еще и глюки этой БД (а глюки были). В итоге у нас была возможность что из-за глюка в какой-то прикладной программы , которой о внутренностях ОС вообще ничего знать не надо, могла накрыться вся ОС.
Это какая-то фантастика. Журналирование БД — хорошо известная практика, разработанная во времена нежурналируемых ФС. Это как считать, что построение кластера ухудшает доступность, т.к. к ненадёжности отдельных машин мы добавляем ненадёжность технологии кластеризации.
Если у вас есть какие-то ссылки на подтверждение вашего утверждения, будет интересно посмотреть.

K>В том-то и дело, что какого-то вменяемого централизованного способа предложено не было. Любая программа писала в реестр все что хотела и куда хотела.
Ну, всё верно. Никакой безопасности-то в 95 винде не было; там и на диск программа могла писать куда угодно, не исключая и System32. Речь шла не о построении "пуленепробиваемой системы", а хотя бы о построении системы, в которой программы могут кооперироваться.

K>А при деинсталяции чистить за собой реестр почему-то считалось дурным тоном.
Нигде такого не считалось.
K>Как минимум, надо было изначально делать какую-то функциональность пакетных менеджеров.
Во-первых, сама идея пакетных менеджеров появилась сильно позже Win 3.11s. Во-вторых, она изначально подразумевает онлайн-доступ к репозиторию для резолва зависимостей, а винда с поддержкой сети всегда отставала на два хода.
В-третьих, пакетные менеджеры как таковые вопросы развёртывания пользовательского софта не особо-то и решают. Потому, что помимо стуффа на файлухе (управляемого ПКМ) есть всякие интересности. Просто в красноглазом мире считается нормой все эти интересности делегировать пользователю, и если он не справился — сам дурак. А винду проектировали для того, чтобы пользователь мог в инсталляторе сделать клац-клац-клик-клик и начать работать. При том, что инсталлятор запускается с дискеты на машинке, которая вообще не воткнута ни в какую сеть.

K>Нельзя было позволять кому угодно писать в реестр куда угодно.
Это было невозможно сделать на системе без секьюрити дескрипторов.
K>Более того, должна была быть какая-то возможность почистить настройки реестра за удаленной программой. По идее уже в 95 винде был отдельный пункт в меную "установка и удаление программ", был список установленных программ, была стандартизарованная работа с GUI было API почти для всего, но почему-то никакой стандартизации инсталяторов/деинсталяторов/апдейтеров не было.
Как это не было? Пункт "установка и удаление программ" был как раз такой стандартизацией. Ну, вот такая стандартизация — вежливые программы ставили вместе с собой инструмент для уборки, и записывали его ... тадам! В реестр. HKLM\Software\Microsoft\Windows\Current Version\Uninstall.

А в 2000 году появился API Windows Installer. И гадить напрямую в реестр стало дурным тоном — вежливые ребята делали декларативную инсталляху, которая подробно описывала состояние системы (и даже зависимости от софта, ровно в стиле пакетных менеджеров). И, соответственно, при сносе софта всё развёрнутое удалялось обратно.
И, естественно, те, кто лазил в реестр мимо кассы, зачастую оставляли в системе мусор. Ну, так если я в линуксовом пакете в скрипте нагенерю какого-нибудь говна в инсталляционном скрипте, и забуду удалить в деинсталляционном — кто будет виноват?
K>Если с файловой системой программы все-таки обращались более аккуратно, хотя тоже гадили, то загадить реестр было чуть ли ни принципом хорошего тона и считалось совершенно правильным делом.
Это результат сразу нескольких эффектов.
1. С файлухой программы тоже обращались кому как в голову придёт. В частности, многие программы в процессе работы гадили рядом со своим расположением (благо, дефолтные права на запись в окресности Program Files отобрали уже в этом веке), что приводило к невозможности удалить фолдер при декларативном анинсталле. Этим страдали даже лучшие из умов, поэтому вся историю версий Офиса и Студии на конкретной машине можно проследить по содержимому их каталогов.
2. Лазить в реестр кривыми руками хотелось в основном жадным авторам. Был класс приседаний вида "давайте оставим в реестре дату первой инсталляции, чтобы при реинсталле не дать ещё один триальный период", а также класс приседаний "давайте оставим в реестре рекламу наших говнопродуктов, чтобы человек, даже снеся наш софт, мог случайно ткнуть ссылку и поставить его снова".
Вот это — не вина архитектуры системы, а скорее следствие денег, крутившихся в этой индустрии. Ну, вот как надписи вида "кристаллы +7 xxx xxx xxxx" на стенах — не следствие косячной архитектуры домов, а следствие высокой маржинальности данного вида бизнеса.
Это в наше время экосистемы могут себе позволить унижать и ограничивать вендоров софта. А в те времена рынок софта ещё не сложился; а без софта операционки никто бы в жизни не стал покупать. Так что Микрософт до поры до времени закрывала глаза на сомнительные практики, и только потом начала завинчивать гайки.

K>Как минимум нужно было как-то стандартизировать что они друг о друге знают, а не позволять кому попало гадить в реестр.
Это не взаимоисключающие понятия. Шла постепенная стандартизация того, кто что о ком знает. Ну там — как добавить пункт в Send To в Windows Explorer; как определить, что в системе стоит программа X версии Y, в составе которой была проинсталлирована фича Z. Как узнать, сколько в системе мониторов, и каких. Что за железки подключены. И так далее. В том числе — если я знаю что-то про настройки специфической программы X, я могу подсмотреть их в реестре. Несмотря на то, что они не описываются официальной документацией винды.
Кстати, один из самых злонамеренных малваров, которые я только видел, был софт, шедший в комплекте с каким-то bluetooth dongle. В XP дефолтный стек BT был рудиментарным; пацаны, помимо драйвера собственно донгла, доставляли ряд системных компонентов, которые добавляли всякую поддержку hi-fi звука и ещё что-то там. И вот прикол в том, что они там наруливали какие-то нетривиальные права на соответствующую ветку реестра; и после деинсталляции они сами ключики восстанавливали, а права — нет. В итоге отваливался весь Bluetooth, даже тот, который был до инсталляции. Потому что подключение любого BT-устройства в системе динамически добавляет ключик в эту ветку, а у системы права на ветку были отобраны .

K>Но в итоге получилось, что получилось.
Отож.

K>Возможно идея казалось действительно светлой, но в реальности нормально ее реализовать скорее всего невозможно.
Как мы понимаем с высоты накопленного опыта, идея оказалась недостаточно светлой. Во-первых, она недостаточно параноидальна по отношению к стороннему софту. Малварь казалась маловероятной угрозой — ну сами подумайте, вот купил человек коробку с диском в каком-нибудь best buy, поставил софт — а тот возьми и запори что-нибудь важное! Пёс с ним с дисклеймером в лицензии — на коробке есть координаты производителя, любой адвокат вцепится в него и отымеет по самые гланды. Поставщик не сможет спрятаться в чужой юрисдикции, а даже если спрячется — ну заработает он пару сотен долларов, потом партию малвары просто изымут из магазинов и сожгут.

Во-вторых, она таки не до конца продумана в плане возможных взаимодействий между программами. Всё отдано на откуп "самим программам", без внятной стандартизации и без контроля. Управление обновлениями, зависимостями, настройками — ничего не стандартизовано. Если бы не iOS, то мы бы и по сю пору считали, что ничего умнее, чем "возьмите где-нибудь файл .msi" или там "вы должны сами знать полное имя нужного вам пакета" придумать невозможно.

K>В нескольких местах, где я работал, были системы с микросервисной архитектурой и в умах разработчиков возникала светлая мысль, создать некий configuration service, в котором бы все компоненты системы хранили бы свою конфигурацию. При старте они бы могли ее получить, а сервис конфигураций гарантировал бы целостность, версионность, делал бы бекапы, позволял бы избежать дублирования значений, которые нужны разным сервисам, Давал бы сигналы сервисам, если конфиг поменялся и тд. и тп. Изначальная мысль выглядела всегда логичной и правильной. Но к сожалению всегда этот сервис конфигурации превращался в помойку, в которой никто не мог разобраться. Уже через год активного использования, этот общий конфиг выглядел жутким монстром, через 5 лет, уже не было людей посвещенныз в эти тайные знания. Причем это повторялось на нескольких местах работы, везде одни и те же проблемы. В итоге я все таки прихожу к выводу, что сделать нормальное централизованное хранилище конфигов, так, чтобы его вместе использовали разные программы, разрабатываемые разными коммандами разработчиков невозможно. По крайней мере невозможно сделать это красиво для более менее крупной экосистемы.
Это — другая проблема. Дело не в централизованности конфигов — распиливание конфигов по отдельным микросервисам скорее ухудшит ситуацию с помойкой, чем улучшит.
Дело в том, что конфиги в такой "высококонфигурируемая система" становятся существенной частью прикладной логики. При этом код системы лежит под контролем системы версионирования; есть всякие практики код ревью и CI/CD. А конфиги — ну, это лежит где-то в базе; никаких способов сделать дифф или блейм, или там откатиться к настройкам от прошлого четверга — не предусмотрено. Зато есть чудесный гуй для редактирования настроек. И служба эксплуатации сначала наруливает конфиги на стейджинге; а потом настраивает прод по скриншотам стейджинга
Особенно это весело с учётом того, что большая часть сочетаний значений настроек нежизнеспособна, но при этом есть какие-нибудь важные отличия прода от стейджинга, которые нельзя ненароком продолбать (вроде "использовать мок системы процессинга платежей по кредиткам").

K>Идея вроде даже правильная. Но реализация.... Эта самая БД хранилась на той же нежурналируемой ФС. В итоге мы вместо того, чтобы защититься от возможных глюков на уровне ФС.

лет 20 назад майкрософт делала WinFS
https://en.wikipedia.org/wiki/WinFS

бросили на пол пути, на сколько я помню тормоз получился, а все хотят скорость и самим решать где будет размен скорости на гарантии.

Здравствуйте, Gt_, Вы писали:

Gt_>бросили на пол пути, на сколько я помню тормоз получился, а все хотят скорость и самим решать где будет размен скорости на гарантии.
Это совсем другой проект, ортогональный обсуждаемой тематике.
Журналирование в NTFS было, АФАИК, с самого начала, и желающих разменять её гарантии на скорость как-то не шибко много.

Gt_>>бросили на пол пути, на сколько я помню тормоз получился, а все хотят скорость и самим решать где будет размен скорости на гарантии.
S>Это совсем другой проект, ортогональный обсуждаемой тематике.
S>Журналирование в NTFS было, АФАИК, с самого начала, и желающих разменять её гарантии на скорость как-то не шибко много.

это именно база данных и понадобилась поскольку гарантий у ntfs с гулькин нос.

Здравствуйте, ksandro, Вы писали:

K>Здравствуйте, Sinclair, Вы писали:


S>>2. Это централизованный способ управления всем, помогающий строить экосистему.

K>В том-то и дело, что какого-то вменяемого централизованного способа предложено не было.

Никто не написал про Групповые политики. Именно хранение всех настроек в единой базе данных позволяет легко в домене Виндовс для конкретного пользователя/компьютера настроить поведение/права и т.д. Т.е. построить экосистему в рамках одного предприятия.
Групповые политики — куски реестра, относящиеся к конкретной программе, хранятся на контроллере домена, настраиваются сисадмином и применяются на локальном компьютере. При этом поля настроек могут объединяться, замещаться в зависимости от групп в АД, куда входит компьютер и пользователь. Причем, применение групповых политик, по умолчанию, происходит раз в 45 минут.
Идея вполне норм, проблемы были с реализацией. До Виндовс ХП, если меня не подводит склероз, была ветвь реестра, куда можно было записать только ограниченное число значений, 64к, при ее заполнении реестр падал.