Здравствуйте, Baudolino, Вы писали:
B>Зло всегда исходит от разработчика, а не от инструмента.
..., который использует не тот инструмент
B>1. Файлы удобнее просматривать и редактировать. С этим утверждением трудно спорить, однако, спорить и не нужно. Важнее ответ на вопрос, а зачем пользователю просматривать и редактировать настройки приложения вручную? Обладает ли пользователь достаточной для этого компетенцией?
Кто распространил мнение среди программистов, что все пользователи — дебилы? Не обладает компетенцией — значит сам себе злостный буратино. Боитесь, что многие будут портить настройки? Ну так сделайте автосохранение последних успешных настроек и быстрое и удобное их восстановление в случае чего. Иначе получается "так как большинство пользователей пользуются браузером IE, наш сайт остальные не поддерживает".
Вручную иногда значительно проще, чем ползать по менюшкам приложения. Тем более, что в гуе запросто может не быть тонких настроек.
B>2. С реестром работать удобнее, поскольку API заточен под хранение настроек (транзакции и т.п.). Для хранения настроек в файлах при этом существует множество готовых библиотек, но это может означать как зависимость от нестандартного API (минус), так и улучшенный по сравнению с реестром функционал (плюс).
Можно пример, когда транзакции для сохранения настроек действительно необходимы? Без какого-либо сарказма, просто пока такого ПО не встречал.
B>4. C т.з. быстрого развертывания оба способа эквивалентны, только это делается не через жопу (зачеркнуто) контроль версий.
Чем не нравится VCS? Для разработческих целей — самое оно. Для корпоративных проектов тоже вполне подходит.
Что предлагаешь взамен, через управление доменом (AD или как там его)?
B>5. С т.з. переноса пользовательских данных оба способа эквивалентны — пользовательский реестр хранится в %USERPROFILE% (было бы здорово, если бы у разработчиков хватало ума проверять совместимость своих продуктов с Easy Transfer).
Вычленить из USER_HOME нужный каталог с файлами настроек гораздо проще, чем сохранять ветку из реестра и переносить полученный файлик. Во втором случае как минимум на одно действие больше.
B>6. Флешка не является аргументом в пользу файлов, т.к. вы можете переместить на нее %APPDATA% (=%USERPROFILE%\AppData\Roaming) и хранить на ней настройки любого приложения (разумеется, если оно не хардкодит системные пути) незаметно от него.
Можно подробнее? Я правильно понимаю, что в этом случае переносится весь HKCU?
ИМХО, если бы Микрософт заместо API к реестру предоставило API для сохранения настроек в %APPDATA%, всем было бы лучше. Другое дело, что в те давние времена NTFS не был распространен, а реестр предоставлял видимость защиты пользовательских данных, что лучше, чем ничего.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Может статься, что файл настроек лежит себе тихо-мирно рядом с программой, а не в MyDocuments.
Теперь это, к сожалению, стало модно считать неправильным
Здравствуйте, Don Reba, Вы писали:
C>>К примеру, как мне для реестра описать, что в ключе aa/nnn/ddd хранятся только IPv6 адреса? DR>Я бы создал рядом значение с комментарием.
И как этот комментарий помешает программе записать туда неверное значение?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Для сохранения настроек приложения. Собственно, есть некоторое устоявшееся мнение, что реестр — это зло. Но вот с т.з. разработки, в чем это зло заключается?
Тем что он не позволяет скопировать приложение целиком и полностью на флэшку и перенести на другую машину
Здравствуйте, Sshur, Вы писали:
S>Не надо сравнивать HKLM, и все. А ежели ваше ПО хранит настройки в HKLM, то это в принципе то же самое, что конфиги в c:\windows писать
ПО оно сильно разное бывает.
Сервису например кроме как в HKLM больше некуда.
Здравствуйте, Niemand, Вы писали:
N>потому что xml файл намного более осязаем для юзера чем реестр — его можно снести на флешку, открыть блокнотом и не видеть кучу других ключей. (тут я вижу возражение что мол есть .reg файлы — но их надо вностить в реестр что уже для юзера сложнее).
Самое отпадное решение которое я как то увидел — это хранить конфиг в XML в REG_SZ ключе в реестре.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вот только проблем с этим огребешь по полной — хотя бы с секьюрити
Nope.
Достаточно ставить прогу туда, куда считаешь нужным. Т.е. в папку с правильно настроенными правами. Ну и уж точно не в c:\program files. Честно говоря это сомнительная идея — засирать диск с системой прикладным мусором.
Здравствуйте, x-code, Вы писали:
ВВ>>Для сохранения настроек приложения. Собственно, есть некоторое устоявшееся мнение, что реестр — это зло. Но вот с т.з. разработки, в чем это зло заключается? XC>Тем что он не позволяет скопировать приложение целиком и полностью на флэшку и перенести на другую машину
Вообще то это целиком и полностью зависит от приложения.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Sshur, Вы писали:
S>>Не надо сравнивать HKLM, и все. А ежели ваше ПО хранит настройки в HKLM, то это в принципе то же самое, что конфиги в c:\windows писать CC>ПО оно сильно разное бывает. CC>Сервису например кроме как в HKLM больше некуда.
Сервис можно запустить от имени специального юзера Без чего иногда и обойтись нельзя, если виндовс авторизация нужна к MSSQL например.
Но, сервис — специфичное ПО, его не надо переносить на 10 компов и он не работает на разных компах от имени разных пользователей. А сервер после падения поднимается целиком из образов диска или чего-то еще
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, CreatorCray, Вы писали:
CC>Самое отпадное решение которое я как то увидел — это хранить конфиг в XML в REG_SZ ключе в реестре.
А у нас как-то сделали хранение основных настроек в БД. Ну то есть строка подключения к БД где-то маленьким ключом в реестре хранится, а остальные настройки потом из БД подсасываются. Кстати, как раз для сервиса такое было
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Воронков Василий, Вы писали:
C>>А ты сам-то пробовал так делать? Вот попробуй и расскажи как получится. ВВ>Нет. А ты пробовал реальные конфиги установленных приложений добавлять в сурс-контрол?
Да. Вот с одного из серверов:
root@cloudmain:/etc# git log
commit 6537d193e872951efd3e237c4ed6e86cb3e1420c
Author: Alex Besogonov <Alex.Besogonov@gmail.com>
Date: Thu Nov 12 20:39:07 2009 +0000
Updates - new SSL root certs.
commit f761f162da380484df3ca8475edaa7446454d09c
Author: Alex Besogonov <Alex.Besogonov@gmail.com>
Date: Thu Nov 12 20:38:57 2009 +0000
Bind zones updates - add new cloud-based servers.
commit 90eadec5194fba60aecd6e18e22d8181f0f13d32
Author: Alex Besogonov <Alex.Besogonov@gmail.com>
Date: Thu Nov 12 20:38:41 2009 +0000
Use the dedicated outgoing interface (for SPF protection).
commit d05b485648cade0db2b13343f1245466a3279825
Author: Alex Besogonov <Alex.Besogonov@gmail.com>
Date: Thu Nov 12 20:38:10 2009 +0000
Disabled the separate /tmp partition (too small).
commit 483c353116766bdabdda92c43667d45f7533415d
Author: Alex Besogonov <Alex.Besogonov@gmail.com>
Date: Sat Jul 25 19:52:18 2009 +0000
Installed 32-bit JVM and switched applications to it, added redirection for hcptest.
Естественно, в вербозном логе отображаются все изменённые файлы. Так что никакие случайные "rm -Rf . /*" не создадут проблемы более чем на пару минут.
Здравствуйте, Sshur, Вы писали:
C>>Так вот — нифига оно не получается. В реестре полно ключей, которые постоянно меняются системой. Поэтому, полный backup реестра не имеет смысла — там будет слишком много мусорных изменений. Вменяемый merge тоже нереален. S>Не надо сравнивать HKLM, и все.
А надо.
S>А ежели ваше ПО хранит настройки в HKLM, то это в принципе то же самое, что конфиги в c:\windows писать
Куча ПО хранит глобальные настройки в HKLM (что есть правильно). Что ты с ним предлагаешь делать?
В ПравильныхОС всё просто — общесистемные настройки в /etc, а пользовательские — в домашке. Обычно с одинаковым форматом конфигов.
Здравствуйте, CreatorCray, Вы писали:
ВВ>>Вот только проблем с этим огребешь по полной — хотя бы с секьюрити CC>Nope. CC>Достаточно ставить прогу туда, куда считаешь нужным. Т.е. в папку с правильно настроенными правами. Ну и уж точно не в c:\program files. Честно говоря это сомнительная идея — засирать диск с системой прикладным мусором.
Я сомневаюсь, что нарушать паттерн "c:\program files" хорошая идея. Но это как говорится выбор каждого и устраивать флейм по этому поводу мне бы не хотелось.
Тем не менее у подавляющего большинства пользователей приложение именно в этой папочке и окажется. И если оно в принципе не умеет нормально работать с конфигом который лежит в c:\program files, то будет падать. В немалом количестве случаев.
Здравствуйте, Sshur, Вы писали:
S>PS. Все работает с поправкой, что SID пользователя в домене один и тот же на всех машинах. Чтобы такой финт повторить без домена, надо делать экспорт реестра именно из HKCU например регэдитом и потом импорт им же. Ну и настройки ПО хранятся в Software — лучше перенести настройки избранных приложений, чем весь мусор что там есть
Таки "просто положить в VCS" уже не получается. Нужно заниматься ручным экспортом. А некоторые приложения ещё и в разные места реестра пишут.
