?

Log in

No account? Create an account
почему надо ненавидеть майкрософт - Поклонник деепричастий [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

почему надо ненавидеть майкрософт [сент. 29, 2003|07:13 pm]
Anatoly Vorobey
Let's Bash Microsoft Today — забавная дискуссия в веблоге Филиппа Гринспана о том, за что стоит ненавидеть Майкрософт (или не стоит). В основном в комментах.

Кстати, хотя со многими высказанными там претензиями я согласен, многие другие кажутся мне непонятными или даже невразумительными. И откуда, интересно, такая ненависть к реестру (он же registry)? Вот это я давно не могу понять. У меня есть немало конкретных претензий к Майкрософту по поводу реестра (плохо документирован, в основной программе редактирования не хватает многих важных возможностей, итп.), но я не понимаю, что такого уж ужасного в идее центрального реестра конфигурационной информации, в принципе.
СсылкаОтветить

Comments:
[User Picture]From: alickop
2003-09-29 09:18 am
Все-таки, гораздо удобнее хранить конфиги в ini-шниках в папке с программой. Проще систему переустанавливать. Как пример можно привести организацию этого дела в OS/2: там тоже был реестр, но там сама система хранила всякий мусор (типа положения и цвета окон), а все настройки лежали в папках с программами.
(Ответить) (Thread)
[User Picture]From: esycat
2003-09-29 09:31 am
Системный реестр, на сколько я понимаю, позволяет хранить все настройки в едином формате, причём занимается этим сама система, а не каждый девелопер выдумывает собственный формат конфигурационного файла. Если бы все программы аккуратно и красиво записывали свои данные в registry, а у станадртного regedit'а было больше необходимых возможностей и удобный интерфейс (как графический, так и консольный), то мне это кажется более разумным и удобным, нежели захламление домашней директории пользователя .progname директориями с настройками каждого приложения.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: avnik
2003-09-29 09:22 am
Тем что сделали еще одну сложную интересную штуку со своеобразным интерфейсом. Если бы они сделали registry_fs смонитированную в /registry
или к z: (к букве Зю) был бы простой и понятный каждому файловый интерфейс. Можно было не парится по поводу бекапа и прочего работали бы tar/cpio/cp -r/да хоть нортон

Ну так ведь получилось то как всегда ;)
(Ответить) (Thread)
[User Picture]From: sergeax
2003-09-29 10:05 am
Такой shell extension был ещё в Windows 95. Но никто им не пользовался.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: zigmar
2003-09-29 09:22 am
Насчёт реестра - ИМХО, основной недостаток это переносимость. Чтоб все свои настройки перетащить с одной машины на другую на юниксе - списал все нужные дот-файлы, и вперёд. А когда программа начинает писать всё в реестрт, то это уже превращается в танцы с бубном.
Вообще реестр это, по-моему, что-то что может быть удобно с точки зрения програмера/API, но никак не с точки зрения юзера/админа.
(Ответить) (Thread)
[User Picture]From: esycat
2003-09-29 09:37 am
Не возьмусь утверждать, ибо в основном знаю людей, работающих с линексом в качестве администраторов серверов, но, как мне кажется, любой обычный пользователь линекса должен быть в состоянии написать примитивный бач-файл, кот. будет сохранять все необходимые настройки и восстанавливать их из сохранённого файла.
Другое дело, что многие программы пишут свои данные в реестр как бог на душу положит, и далеко не всегда с первого взгляда становится очевидно, что же именно нужно сохранять.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: object
2003-09-29 09:32 am
В .NET MS делает существенный шаг от реестра к так называемым установкам side by side. Основная претензия к реестру - то, что он создавался как более структурный INI-файл, а превратился в базу данных, таковой по способам доступа не являясь. Чистка реестра с удалением мертвых установок прератилась в целую науку. Поэтому появились всевозможные надстройки, как использующие данные реестра (OLE Viewer собирает вместе настройки COM-компонент), так и складирующие данные за пределами реестра (конфигурация COM+). Теперь вот еще .NET. В итоге все очень хаотично, но я тоже не считаю идею реестра чем-то неверным в принципе. Просто она перестала укладываться в архитектуру нынешней системы.
(Ответить) (Thread)
[User Picture]From: meshko
2003-09-29 09:59 am
Вот, вот, про INI-file, который превратился в базу данных -- это совершенно правильно. Идея класть туда UID'ы и регистрировать там всякие COM'ы...
Можно еще так сформулировать: в реестре свалены в одну кучу два вида информации. Во-первых настройки, которые может и должен читать и изменять пользователь. Во-вторых нечитаемая информация об операционной системе, которую руками трогать нельзя и опасно.
Я ругаю реестр не как абстрактую идею (которую защищиать легко), а ругаю то, что из неё получилось.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: dimrub
2003-09-29 09:38 am
Тем что сделали еще одну сложную интересную штуку со своеобразным интерфейсом. Если бы они сделали registry_fs смонитированную в /registry
или к z: (к букве Зю) был бы простой и понятный каждому файловый интерфейс.


Дерево registry доступно как поддерево общего дерева объектов. Если кому-то надо, мог бы написать device driver, который маунтил бы registry где угодно. Но, вроде, не написали. Значит, никому не нужно, наверное.

Насчёт реестра - ИМХО, основной недостаток это переносимость. Чтоб все свои настройки перетащить с одной машины на другую на юниксе - списал все нужные дот-файлы, и вперёд. А когда программа начинает писать всё в реестрт, то это уже превращается в танцы с бубном.

В regedit есть функции импорта и экспорта, решающие эту проблему на ура.

Вообще, критики registry забывают как минимум два момента:

1. В your average *NIX конфигурация типичной программы раскидана по как минимум десяти файлам, запиханных в самые злачные места файловой системы. Это и домашняя директория пользователя, и /etc и /etc/rc.d (или любой его вариант) и /usr/etc и /var/.* и т.п. При этом зачастую не понятно, каково отношение между всеми этими разнообразными файлами. Ну а если вы используете дистрибуцию Линукса, то к файлам пакета прибавляются еще и всевозможные дефолтные установки дистрибутива. Короче, черт ногу сломит. И эти люди не разрешают нам ковырять в носу?

2. Registry, помимо помещения всей этой информации в одном месте, в удобном для пользователя виде (и пожалуйста, не надо мне говорить про неудобство ублюдочных regedit и regsvr32: API открыт, кому надо - напишет лучше, и продаст, и спасибо пусть сказать не забудет), registry еще и оснащено механизмом security, гранулярность которого позволяет большее удобство в работе, нежели любые файловые конфигурации.

No ini files for you. NEXT!
(Ответить) (Thread)
[User Picture]From: alickop
2003-09-29 10:00 am
Как раз хотел написать, что относительно безопасности и удобства разграничения прав доступа - регистр поудобнее будет, чем ini
(Ответить) (Parent) (Thread)
[User Picture]From: kot_begemot
2003-09-29 11:19 am

Registry и бритва Оккама

На самом деле, идея централизованого хранилища (а вернее - базы данных) конфигурационной информации - вполне имеет право на существование и даже является во многом прогрессивной (в частности, способствует стандартизации и централизации). Но, как и многое другое у Microsoft, страдает от кривого исполнения. Вместо того, чтобы воспользоваться существующим, отлаженным и удобным интрефейсом иерархической файловой системы, изобретается параллельная сущность с теми же (практически) свойствами, чем вносится бардак и разнобой.
В этом - весь Microsoft. Любая идея доводится до полного абсурда неряшливостью и ущербностью воплощения...
(Ответить) (Thread)
[User Picture]From: avnik
2003-09-30 07:47 am
Ну я уже говорил что-то подобное, только не так складно и красиво ;)

Идея хорошая, только интерфейс к ней какой-то уж слишком своеобразный.

PS А не мог ли Вас кстати на приветовском форуме читать?
(Ответить) (Parent) (Thread) (Развернуть)
From: indimo
2003-09-29 11:23 am
даааа ru.os.cmp

в общем-то проблема лежит в практической плоскости управления настройками программ, в том числе настройками самой операционки. Вряд-ли какая-либо методология хранения настроек способна решить задачу организации управления. Пока есть широкие возможности раскидать настройки в разные места, их будут раскидывать самым неожиданным образом. И не важно лежат они в реестре или в файлах.
(Ответить) (Thread)
[User Picture]From: avnik
2003-09-30 07:53 am
Для ru.os.cmp тут не хватает товарища fifoДжона Гладких</> - а так - очень близко ;)

Может коммьюнити соответствующее учудить?
Правда боюсь что народ там будет не совсем тот ;)
(Ответить) (Parent) (Thread)
[User Picture]From: stas
2003-09-29 12:24 pm
Боюсь, тут как с многими другими идеями Микрософта - идея-то сама по себе не так уж плоха, а вот исполнение подкачало. И в плане UI, и в плане устойчивости, и в плане надёжности, и в плане документации, и в плане стандартизации...
(Ответить) (Thread)
[User Picture]From: gdy
2003-09-29 12:40 pm
Даже странно, что никто не упомянул Application Data.
Вообще по теме: Data and Settings Management в Application Specification for Microsoft Windows 2000 for Desktop Applications
(Ответить) (Thread)
[User Picture]From: doriy
2003-09-29 03:21 pm
Тут скорее дело не в реестре, а в Гринспане. Более заядлого критика Майкрософта на весь интернет и найти трудно :)
(Ответить) (Thread)
[User Picture]From: dimrub
2003-09-29 03:44 pm

Оффтопик

Скажите, а справедливо ли мое предположение, что Вы живете в Праге и при этом работаете программистом?
(Ответить) (Parent) (Thread) (Развернуть)
From: (Anonymous)
2003-10-01 02:22 am

Dyk.

ponjatie Registry ne pridumal Microsoft.
E'to OSF DCE (Distributed computing environment) pridumal.

Microsoft sodral (t.e. dejstvitel'no razvil) DCOM isxodja iz DCE , a vsledstvie pojavilas' i registry.

Vot tak vot.


(Ответить) (Thread)