почему надо ненавидеть майкрософт

[avva]

Let's Bash Microsoft Today — забавная дискуссия в веблоге Филиппа Гринспана о том, за что стоит ненавидеть Майкрософт (или не стоит). В основном в комментах.

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

Comments

[alickop.livejournal.com]

Все-таки, гораздо удобнее хранить конфиги в ini-шниках в папке с программой. Проще систему переустанавливать. Как пример можно привести организацию этого дела в OS/2: там тоже был реестр, но там сама система хранила всякий мусор (типа положения и цвета окон), а все настройки лежали в папках с программами.

[esycat.livejournal.com]

Системный реестр, на сколько я понимаю, позволяет хранить все настройки в едином формате, причём занимается этим сама система, а не каждый девелопер выдумывает собственный формат конфигурационного файла. Если бы все программы аккуратно и красиво записывали свои данные в registry, а у станадртного regedit'а было больше необходимых возможностей и удобный интерфейс (как графический, так и консольный), то мне это кажется более разумным и удобным, нежели захламление домашней директории пользователя .progname директориями с настройками каждого приложения.

[igorlord.livejournal.com]

Widnows 3.1 имели центральный формат .ini файлов. Система имела API для обработки катих файлов. Было на много удобнее, как в Макинтоше сейчас, точно знать где настройки программы.

[zimopisec.livejournal.com]

Во- первых, никто это делать не мешает и сейчас- я иногда в своих прогах инишники пользую.
А во-вторых- вся штука в том, что музыку, как известно, нельзя- руками:))

[avnik.livejournal.com]

Тем что сделали еще одну сложную интересную штуку со своеобразным интерфейсом. Если бы они сделали registry_fs смонитированную в /registry
или к z: (к букве Зю) был бы простой и понятный каждому файловый интерфейс. Можно было не парится по поводу бекапа и прочего работали бы tar/cpio/cp -r/да хоть нортон

Ну так ведь получилось то как всегда ;)

[sergeax.livejournal.com]

Такой shell extension был ещё в Windows 95. Но никто им не пользовался.

[(Anonymous)]

Это сделано уже в cygwin:
/>cd /proc/registry/
/proc/registry>ls
HKEY_CLASSES_ROOT HKEY_CURRENT_USER HKEY_LOCAL_MACHINE HKEY_USERS
HKEY_CURRENT_CONFIG HKEY_DYN_DATA HKEY_PERFOMANCE_DATA
/proc/registry>cd HKEY_LOCAL_MACHINE/
/proc/registry/HKEY_LOCAL_MACHINE>ls
HARDWARE SAM SECURITY SOFTWARE SYSTEM

[zigmar.livejournal.com]

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

[esycat.livejournal.com]

Не возьмусь утверждать, ибо в основном знаю людей, работающих с линексом в качестве администраторов серверов, но, как мне кажется, любой обычный пользователь линекса должен быть в состоянии написать примитивный бач-файл, кот. будет сохранять все необходимые настройки и восстанавливать их из сохранённого файла.
Другое дело, что многие программы пишут свои данные в реестр как бог на душу положит, и далеко не всегда с первого взгляда становится очевидно, что же именно нужно сохранять.

[object.livejournal.com]

В .NET MS делает существенный шаг от реестра к так называемым установкам side by side. Основная претензия к реестру - то, что он создавался как более структурный INI-файл, а превратился в базу данных, таковой по способам доступа не являясь. Чистка реестра с удалением мертвых установок прератилась в целую науку. Поэтому появились всевозможные надстройки, как использующие данные реестра (OLE Viewer собирает вместе настройки COM-компонент), так и складирующие данные за пределами реестра (конфигурация COM+). Теперь вот еще .NET. В итоге все очень хаотично, но я тоже не считаю идею реестра чем-то неверным в принципе. Просто она перестала укладываться в архитектуру нынешней системы.

[meshko.livejournal.com]

Вот, вот, про INI-file, который превратился в базу данных -- это совершенно правильно. Идея класть туда UID'ы и регистрировать там всякие COM'ы...
Можно еще так сформулировать: в реестре свалены в одну кучу два вида информации. Во-первых настройки, которые может и должен читать и изменять пользователь. Во-вторых нечитаемая информация об операционной системе, которую руками трогать нельзя и опасно.
Я ругаю реестр не как абстрактую идею (которую защищиать легко), а ругаю то, что из неё получилось.

[dimrub.livejournal.com]

Тем что сделали еще одну сложную интересную штуку со своеобразным интерфейсом. Если бы они сделали 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!

[alickop.livejournal.com]

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

[meshko.livejournal.com]

Про Юникс позвольте не согласиться. Есть системы, которые доказывают, что при грамотной организации юниксовский подход работает. FreeBSD например. Да даже и RedHat, когда немножко освоишься! А вот примеров систем, которые успешно используют registry нету :)
И вообще, Вам пришлость два раза использовать аргумент "надо будет, напишут", а это, по-моему, наводит на размышления. С текстовыми файлами настройки кроме текстового редактора и grep писать ничего не пришлось.

[sergeax.livejournal.com]

Вот, кстати, интересно: если *NIX у меня установлен на ноутбуке, который я таскаю с собой, а на работе и дома втыкаю в док-станции, к каждой из которых подцеплена своя периферия (мониторы, клавиатуры, принтеры и т.п.), то как система может поменять свою конфигурацию для каждого из случаев (дома, на работе, в дороге)?

[stas]

Но, вроде, не написали. Значит, никому не нужно, наверное.

Это не совсем верно. Никому не нужно настолько, чтобы самому сесть и писать. Вот мне, например, очень нужна программка, которая сидит в трее и умеет управлять IISом - но не нашёл, а самому писать лень, я лучше из command line справлюсь.

registry еще и оснащено механизмом security, гранулярность которого позволяет большее удобство в работе

А, это интересно. Кто-нибудь реально пользуется этой самой гранулярностью?

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

[kot-begemot.livejournal.com]

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

[avnik.livejournal.com]

Ну я уже говорил что-то подобное, только не так складно и красиво ;)

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

PS А не мог ли Вас кстати на приветовском форуме читать?

[indimo.livejournal.com]

даааа ru.os.cmp

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

[avnik.livejournal.com]

Для ru.os.cmp тут не хватает товарища fifoДжона Гладких</> - а так - очень близко ;)

Может коммьюнити соответствующее учудить?
Правда боюсь что народ там будет не совсем тот ;)

[stas]

Боюсь, тут как с многими другими идеями Микрософта - идея-то сама по себе не так уж плоха, а вот исполнение подкачало. И в плане UI, и в плане устойчивости, и в плане надёжности, и в плане документации, и в плане стандартизации...

[gdy.livejournal.com]

Даже странно, что никто не упомянул Application Data.
Вообще по теме: Data and Settings Management (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kcli/html/W2Kcli_chapter4.asp) в Application Specification for Microsoft Windows 2000 for Desktop Applications

[doriy.livejournal.com]

Тут скорее дело не в реестре, а в Гринспане. Более заядлого критика Майкрософта на весь интернет и найти трудно :)

Оффтопик

[dimrub.livejournal.com]

Скажите, а справедливо ли мое предположение, что Вы живете в Праге и при этом работаете программистом?

Dyk.

[(Anonymous)]

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.