Здравствуйте, 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. А конфиги — ну, это лежит где-то в базе; никаких способов сделать дифф или блейм, или там откатиться к настройкам от прошлого четверга — не предусмотрено. Зато есть чудесный гуй для редактирования настроек. И служба эксплуатации сначала наруливает конфиги на стейджинге; а потом настраивает прод по скриншотам стейджинга
Особенно это весело с учётом того, что большая часть сочетаний значений настроек нежизнеспособна, но при этом есть какие-нибудь важные отличия прода от стейджинга, которые нельзя ненароком продолбать (вроде "использовать мок системы процессинга платежей по кредиткам").