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

Кстати, хотя со многими высказанными там претензиями я согласен, многие другие кажутся мне непонятными или даже невразумительными. И откуда, интересно, такая ненависть к реестру (он же registry)? Вот это я давно не могу понять. У меня есть немало конкретных претензий к Майкрософту по поводу реестра (плохо документирован, в основной программе редактирования не хватает многих важных возможностей, итп.), но я не понимаю, что такого уж ужасного в идее центрального реестра конфигурационной информации, в принципе.
stas: (Default)
From: [personal profile] stas
Только не надо туда ходить вручную. Просто нет необходимости.

Сегодня в масле потребности нет ;)

Реестр предназначен для хранения данных программ, а не пользователей.

Есть такие люди - программисты. Они кто - программы или пользователи?

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

_Своих_ настроек или всех вообще настроек?
Ну да ладно - допустим, это всё так. Но registry - это лишь один из возможных вариантов воплощения одной из моделей такой базы. И как таковой, обладает многочисленными недостатками.
Тема в том, что если я каждый раз для того, чтобы узнать, где что в registry хранится, должен запрашивать соответствующую программу - с тем же успехом эта программа может хранить свои конфиги в .ini или на клинописных табличках. Преимущество единой базы должно быть в том, что есть унифицированные инструменты доступа. Часть этих инструментов у registry есть - но увы, недостаточная. В первую очередь - из-за недостаточной документации, стандартизации и излишней ориентации на специализированные GUI. Для юзеров этого и вправду хватает, а вот как начнёшь копать вглубь - начинается кино и немцы.

Я себе представляю OLE, лазающее grep'ом по директории с CLSID и собирающее объекты из текстовых файлов.

Совершенно необязательно грепом. Файловая система поддерживает иерархические структуры не хуже спецформата микрософт, и уж точно - не медленнее. Особенно специализированная система - смотри, например, /proc.
А хоть бы и грепом - чем, в самом деле, плохо?

Date: 2003-09-30 08:05 am (UTC)
From: [identity profile] avnik.livejournal.com
А оин grep знают, а find еще нет ;)

Хотя честно говоря хочется гибрида ;) надо будет скрпитик написать на sh
From: [identity profile] livsy.livejournal.com
Сегодня в масле потребности нет ;)
Если на передней панели прибора есть ручки настройки то зачем лазить внутри?

Есть такие люди - программисты. Они кто - программы или пользователи?
Пользователи. Они не хранят свои данные в реестре. Они хранят свои данные в текстовых файлах.

Естественно реестр это только ОДНА из возможностей. Подскажите майкрософту лучшее решение и они безусловно заплатят вам деньги. Инструментов для унифицированного доступа к нему больше чем достаточно. Можете сказать чего вам конкретно не хватает, а не "стандартизации" и "ориентации"? Мне, например, не хватает стандартизации в текстовых файлах. Я не уверен ни в том что они имеют 8 бит на байт, ни в том что это вообще стандарт хранения информации.

Специализированные GUID'ы лежат в специальных разделах CLSID и TypeLib и не мешают данным программ и уж тем более не нужны юзерам. А пользователь вообще не должен знать ничего о реализации системы хранения данных, перед ним должен быть только пользовательский интерфейс.

Не могу понять причём здесь файловая система? И зачем её нагружать ещё и совместимостью с реестром? И уж в крайнем случае вы что думаете, что нельзя примонтировать дерево реестра к файловой системе? Просто в этом нет необходимости, а реестр есть и в нём есть необходимость. :)
stas: (Default)
From: [personal profile] stas
Если на передней панели прибора есть ручки настройки то зачем лазить внутри?

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

Специализированные GUID'ы лежат в специальных разделах CLSID и TypeLib и не мешают данным программ и уж тем более не нужны юзерам.

Если они никому не нужны - нафига они существуют?

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

Гениальная идея. Скажите мне, что значит акроним API и для чего он существует?

Пользователи. Они не хранят свои данные в реестре. Они хранят свои данные в текстовых файлах.

Ой. А чем же тогда напихан реестр?

Подскажите майкрософту лучшее решение и они безусловно заплатят вам деньги.

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

И зачем её нагружать ещё и совместимостью с реестром?

Либо я не понимаю, о чём вы говорите, либо вы не понимаете, о чём вы говорите. Что значит "нагружать"?

Просто в этом нет необходимости, а реестр есть и в нём есть необходимость. :)

Ваша уверенность в том, что вы знаете, что необходимо всем на свете, меня просто приводит в изумление. Мне бы такое самомнение.
From: [identity profile] livsy.livejournal.com
Например, чтобы подключить другой прибор - т.к. изготовители прибора ручки настройки приделали, а вход и выход - забыли :)

Хммм... В виндовс не надо лезть в реестр чтобы установить программу.

Если они никому не нужны - нафига они существуют?
Замечательно вы читаете, товарищ! Я написал не нужны пользователям, а вы -- никому. GUID это идентификатор для системы, а не для пользователя.

API это тоже интерфейс. API реестра достаточно для решения проблем на него возложеных.
Реестр "напихан" информацией о системе: её конфигурации, компонентах и связях между ними.

Нагружать = добавлять излишнюю функциональность. Зачем нужна совместимость реестра с файловой системой, если все проблемы решаются сущестующим интерфейсом?

Перед тем, как говорить об отсутсвии необходимости в чём либо я спрашиваю оппонента о том, что ему конкретно мешает или чего недостаёт, если он ничего не отвечает, то я говорю что система достаточна и ей ничего не нужно, так яснее?

January 2026

S M T W T F S
    1 2 3
45678910
11121314151617
18192021222324
25262728293031

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 4th, 2026 04:29 pm
Powered by Dreamwidth Studios