Сообщение Re[2]: Почему MS не освоили принцип слабой связности? от 08.09.2025 12:03
Изменено 08.09.2025 12:58 ksandro
Re[2]: Почему MS не освоили принцип слабой связности?
Здравствуйте, 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 лет, в этом тайном знании разобраться уже никто не мог. Причем это повторялось на нескольких местах работы, везде одни и те же проблемы. В итоге я все таки прихожу к выводу, что сделать нормальное централизованное хранилище конфигов, так, чтобы его вместе использовали разные программы, разрабатываемые разными коммандами разработчиков не возможно. По крайней мере не возможно сделать это красиво для более менее крупной экосистемы.
S>Потому, что реестр — это не только "настройки программы".
S>Реестр, изобретённый в Win 3.11s, был большим шагом вперёд.
Возможно тогда казалось, что это шаг вперед, но ИМХО они не осилили довести идею до ума, в итоге получился скорее шаг куда-то в сторону.
S>1. Это иерархическая БД, с гарантиями атомарности (что было круто по сравнению с тогдашними нежурналируемыми ФС)
Идея вроде даже правильная. Но реализация.... Эта самая БД хранилась на той же нежурналируемой ФС. В итоге мы вместо того, чтобы защититься от возможных глюков на уровне ФС. Мы квозможным глюкам ФС добавляем еще и глюки этой БД (а глюки были). В итоге у нас была возможность что из-за глюка в какой-то прикладной программы , которой о внутренностях ОС вообще ничего знать не надо, молда накрыться вся ОС.
S>2. Это централизованный способ управления всем, помогающий строить экосистему.
В том-то и дело, что какого-то вменяемого централизованного способа предложено не было. Любая программа писала в реестр все что хотела и куда хотела. А при деинсталяции чистить за собой реестр почему-то считалось дурным тоном. Как минимум, надо было изначально делать какую-то функциональность пакетных менеджеров. Нельзя было позволять кому угодно писать в реестр куда угодно. Более того, должна была быть какая-то возможность почистить настройки реестр за удаленной программой. По идее уже в 95 винде был отдельный пункт в меную "установка и удаление программ", был список установленных программ, была стандартизарованная работа с GUI было API почти для всего, но почему-то никакой стандартизации инсталяторов/деинсталяторов/апдейтеров не было. Если с файловой системой программы все-таки обращались более аккуратно, хотя тоже гадили, то загадить реестр было чуть ли ни принципом хорошего тона и считалось правильным.
S>МС видела себе ОС не как хранилище разрозненных программ, которые пользователь в силу своего разумения компонует друг с другом, а как экосистему, где программы "знают" друг про друга и помогают пользователю в сложных сценариях.
Как минимум нужно было как-то стандартизировать что они друг о друге знают, а не позволять кому попало гадить в реестр.
S>"Папку программы" пользователь может в некоторых пределах выбирать самостоятельно (в те времена ограничений было гораздо меньше, чем сейчас). Это означает, что программе Y найти программу X без помощи пользователя крайне тяжело. Вот, кстати, какая-нибудь JAVA до сих пор сама себя найти не может без пачки environment variables.
S>А в реестре всё лежит там, где разработчик предназначил — поэтому, глядя в реестр, можно очень много чего сказать о конкретном пользователе и его машине.
Но в итоге получилось что получилось.
S>Вот для этой светлой цели всё изобреталось. Чтобы не надо было в настройках каждой программы прописывать руками ссылки на другие нужные ей программы и прочую ерунду, заниматься которой так любят красноглазые.
Возможно идея казалось действительно светлой, но в реальности нормально ее реализовать скорее всего не возможно.
В нескольких местах, где я работал, были системы с микросервисной архитектурой и в умах разработчиков возникала светлая мысль, создать некий configuration service, в котором бы все компоненты системы хранили бы свою конфигурацию. при старте они бы могли ее получить, а сервис конфигураций гарантировал бы целостность, версионность, делал бы бекапы, позволял бы избежать дублирования значений, которые нужны разным сервисам, Давал бы сигналы сервисам, если конфиг поменялся и тд. и тп. Изначальная мысль выглядела всегда логичной и правильной. Но к сожалению всегда этот сервис конфигурации превращался в помойку, в которой никто не мог разобраться. Уже через год активного использования, этот общий конфиг выглядел жутким монстром, через 5 лет, в этом тайном знании разобраться уже никто не мог. Причем это повторялось на нескольких местах работы, везде одни и те же проблемы. В итоге я все таки прихожу к выводу, что сделать нормальное централизованное хранилище конфигов, так, чтобы его вместе использовали разные программы, разрабатываемые разными коммандами разработчиков не возможно. По крайней мере не возможно сделать это красиво для более менее крупной экосистемы.
Re[2]: Почему MS не освоили принцип слабой связности?
Здравствуйте, 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 лет, уже не было людей посвещенныз в эти тайные знания. Причем это повторялось на нескольких местах работы, везде одни и те же проблемы. В итоге я все таки прихожу к выводу, что сделать нормальное централизованное хранилище конфигов, так, чтобы его вместе использовали разные программы, разрабатываемые разными коммандами разработчиков невозможно. По крайней мере невозможно сделать это красиво для более менее крупной экосистемы.
S>Потому, что реестр — это не только "настройки программы".
S>Реестр, изобретённый в Win 3.11s, был большим шагом вперёд.
Возможно тогда казалось, что это шаг вперед, но ИМХО они не осилили довести идею до ума, в итоге получился скорее шаг куда-то в сторону.
S>1. Это иерархическая БД, с гарантиями атомарности (что было круто по сравнению с тогдашними нежурналируемыми ФС)
Идея вроде даже правильная. Но реализация.... Эта самая БД хранилась на той же нежурналируемой ФС. В итоге мы вместо того, чтобы защититься от возможных глюков на уровне ФС. Мы квозможным глюкам ФС добавляем еще и глюки этой БД (а глюки были). В итоге у нас была возможность что из-за глюка в какой-то прикладной программы , которой о внутренностях ОС вообще ничего знать не надо, могла накрыться вся ОС.
S>2. Это централизованный способ управления всем, помогающий строить экосистему.
В том-то и дело, что какого-то вменяемого централизованного способа предложено не было. Любая программа писала в реестр все что хотела и куда хотела. А при деинсталяции чистить за собой реестр почему-то считалось дурным тоном. Как минимум, надо было изначально делать какую-то функциональность пакетных менеджеров. Нельзя было позволять кому угодно писать в реестр куда угодно. Более того, должна была быть какая-то возможность почистить настройки реестра за удаленной программой. По идее уже в 95 винде был отдельный пункт в меную "установка и удаление программ", был список установленных программ, была стандартизарованная работа с GUI было API почти для всего, но почему-то никакой стандартизации инсталяторов/деинсталяторов/апдейтеров не было. Если с файловой системой программы все-таки обращались более аккуратно, хотя тоже гадили, то загадить реестр было чуть ли ни принципом хорошего тона и считалось совершенно правильным делом.
S>МС видела себе ОС не как хранилище разрозненных программ, которые пользователь в силу своего разумения компонует друг с другом, а как экосистему, где программы "знают" друг про друга и помогают пользователю в сложных сценариях.
Как минимум нужно было как-то стандартизировать что они друг о друге знают, а не позволять кому попало гадить в реестр.
S>"Папку программы" пользователь может в некоторых пределах выбирать самостоятельно (в те времена ограничений было гораздо меньше, чем сейчас). Это означает, что программе Y найти программу X без помощи пользователя крайне тяжело. Вот, кстати, какая-нибудь JAVA до сих пор сама себя найти не может без пачки environment variables.
S>А в реестре всё лежит там, где разработчик предназначил — поэтому, глядя в реестр, можно очень много чего сказать о конкретном пользователе и его машине.
Но в итоге получилось, что получилось.
S>Вот для этой светлой цели всё изобреталось. Чтобы не надо было в настройках каждой программы прописывать руками ссылки на другие нужные ей программы и прочую ерунду, заниматься которой так любят красноглазые.
Возможно идея казалось действительно светлой, но в реальности нормально ее реализовать скорее всего невозможно.
В нескольких местах, где я работал, были системы с микросервисной архитектурой и в умах разработчиков возникала светлая мысль, создать некий configuration service, в котором бы все компоненты системы хранили бы свою конфигурацию. При старте они бы могли ее получить, а сервис конфигураций гарантировал бы целостность, версионность, делал бы бекапы, позволял бы избежать дублирования значений, которые нужны разным сервисам, Давал бы сигналы сервисам, если конфиг поменялся и тд. и тп. Изначальная мысль выглядела всегда логичной и правильной. Но к сожалению всегда этот сервис конфигурации превращался в помойку, в которой никто не мог разобраться. Уже через год активного использования, этот общий конфиг выглядел жутким монстром, через 5 лет, уже не было людей посвещенныз в эти тайные знания. Причем это повторялось на нескольких местах работы, везде одни и те же проблемы. В итоге я все таки прихожу к выводу, что сделать нормальное централизованное хранилище конфигов, так, чтобы его вместе использовали разные программы, разрабатываемые разными коммандами разработчиков невозможно. По крайней мере невозможно сделать это красиво для более менее крупной экосистемы.