Linux Registry

> А Microsoft не ми ги давай за пример, моля. Какво толкова се е променило в Registry-то от 95-а
> насам? Наистина, не съм кой-знае колко запознат с детайлите по него, но ми се струва, че е
> ярка демонстрация защо не трябва да се пуска една технология на пазара, преди да узрее. И
> после да си блъскаш главата със съвместимости и т.н.

OK, предлагаш нещо, което според теб ще избегне повечето проблеми на Windows Registry. Би ли изброил тези проблеми и начините за избягването им? Признавам си, че не знам почти нищо за Windows Registry -- спасих се от програмирането за Windows малко преди да излезе Windows 95.

Предварително благодаря.

Предлагам на всеки от вас приветстващи идеята с XML да си инсталирате по един TomCat. Да разбъркате XML лайната дето ги има там. Да се надишате едно хубаво и пак да дойдете да си кажете мнението тук. Приатно дрогиране!!!

че преди доста време в един пак в подобен разговор ти твърдеше, че Windows Registry е просто, такова и трябва да си остане, за да върши работа. Разбира се, може и да не помня добре ...

И все пак, според мен Windows Registry има следните недостатъци:
- Съхранява се на диска в двоичен формат. Съответно, ако нещо се скапе, майка плаче. А понякога се скапва (може би липса на журнална фс, не знам). XML като базов формат с предварително известна схема е по-добър вариант, според мен
- Няма понятие валидна конфигурация. Можеш да наблъскаш каквото си поискаш където поискаш. Може би е по-сложно да се поддържа Registry + схема на валидност на определен клон от него, може би просто Microsoft са над тези неща (и да го духат админите), но за мен схемата е важно нещо
- Никой не може да ти каже на кой продукт, аджеба, принадлежат ключовете. Съответно, ако продукта не си ги махне при деинстал, постепенно става мамата си трака
- Продължение на горното: продуктът е длъжен сам да си маха ключовете. Защо бе, джанъм? Като го няма, значи вече не са нужни... А ако искаш някак да се запазят, за бъдещ reinstall - дай да направим подходящ начин да ги запазваме. Примерно в HKEY_LOCAL_SYSTEM_ATTIC
- Тук малко спекулирам, но доколкото знам, няма link-ве. Сещам се, че можеш да си ги емулираш като в низово поле запишеш самия link, но нЕкакси не ме кефи. Предпочитам да го може самото Registry. А-ла файловата система на *nix-те
- Твърде малко стандартни типове и липса на възможност за дефиниране на нови (със задаване на съответния код за проверка на валидност). Примерно, IPv6

Подобно на теб, и аз особено много от Прозоречно програмиране не отбирам, така че казах само неща, за които съм поне 75% сигурен, че са проблеми. А повече бих могъл да ти кажа при повечко практика с XML. Вероятно до няколко месеца. Stay tunned

> че преди доста време в един пак в подобен разговор ти твърдеше, че
> Windows Registry е просто, такова и трябва да си остане, за да върши
> работа. Разбира се, може и да не помня добре ...

Лъжеш се, никога не споря за неща, които не познавам.

> Няма понятие валидна конфигурация. Можеш да наблъскаш каквото си
> поискаш където поискаш. Може би е по-сложно да се поддържа Registry +
> схема на валидност на определен клон от него, може би просто Microsoft са
> над тези неща (и да го духат админите), но за мен схемата е важно нещо

И как ще контролираш тази схема? Не можеш да наложиш една схема за всички приложения, защото не знаеш каква конфигурация им е необходима. А някаква свръхобща схема напълно обезсмисля използването на XML.

> - Никой не може да ти каже на кой продукт, аджеба, принадлежат
> ключовете. Съответно, ако продукта не си ги махне при деинстал,
> постепенно става мамата си трака
> - Продължение на горното: продуктът е длъжен сам да си маха ключовете.

А кой да ги маха??? Хайде, да предположим че за частните конфигурационни параметри може да се измисли нещо което ще работи в _половината_ от случаите. А за тези които се използват от повече от едно приложение? След permission modes и reference counting ли ще въведем?

> - Тук малко спекулирам, но доколкото знам, няма link-ве. Сещам се, че можеш
> да си ги емулираш като в низово поле запишеш самия link, но нЕкакси не ме
> кефи. Предпочитам да го може самото Registry. А-ла файловата система на
> *nix-те

Хайдее, XML файловата система е готова ... Permissions, links, hierarchy ... Какво още липсва?

> - Твърде малко стандартни типове и липса на възможност за дефиниране на
> нови (със задаване на съответния код за проверка на валидност). Примерно,
> IPv6

Което ни връща отново на въпроса за добре дефинираната схема ...

> Подобно на теб, и аз особено много от Прозоречно програмиране не
> отбирам, така че казах само неща, за които съм поне 75% сигурен, че са
> проблеми. А повече бих могъл да ти кажа при повечко практика с XML.
> Вероятно до няколко месеца. Stay tunned

Използвам XML и "технологиите" около него вече (блах) 4 години. Мога да дам десетки примери против използването му за нещата които предполагаш. Преди броени дни трябваше да се оправям в 11 хиляди реда XML конфигурационен файл, измислен от едни оптимисти като теб. Сега ще го преписват, и вероятно ще сътворят също толкова голяма боза (т.нар. от Брукс second-system problem).

Пожелавам ти късмет все пак. (Защото знам, че неуспеха на начинанието е гарантиран (не само по технически причини) и няма вероятност да бъда принуден да използвам Linux Registry ;)

>И как ще контролираш тази схема? Не можеш да наложиш една схема за всички
> приложения, защото не знаеш каква конфигурация им е необходима. А някаква
> свръхобща схема напълно обезсмисля използването на XML.

Че аз и не искам такова нещо. Схемата ще бъде създавана динамично, като за основа ще се използва схемата на ОС. След което при инсталиране на ново приложение, то си регистрира своята схема, която надлеждно се добавя в голямата схема на платформата

> А кой да ги маха??? Хайде, да предположим че за частните конфигурационни
> параметри може да се измисли нещо което ще работи в _половината_ от
> случаите. А за тези които се използват от повече от едно приложение?

Тези, които се използват от повече от едно приложение, принадлежат на обща функионалност. Библиотека, ако щеш. И тя си ги маха. Сега, не ме питай какво става ако всеки instance иска да си има свои параметри ... не съм мислил, признавам си

> Хайдее, XML файловата система е готова ... Permissions, links, hierarchy ...
> Какво още липсва?

Липсва доброто желание на някой етусиаст да я напише Явно тези неща липсват в XML модела, значи, трябва да го разширяваме Изглежда, че в структурирането на данни без подобни понятия не може да се мине ...

> Което ни връща отново на въпроса за добре дефинираната схема ...

Както вече казах, схемата ще е жива, а не дефинирана веднъж и завинаги

> Мога да дам десетки примери против използването му за нещата които предполагаш.

Няма да се учудя да си прав. Все пак, наистина искам да знам какво точно предизвиква критиките ти към XML - конкретния стандарт или изобщо идеята за универсиализиране. И ако можеш да ми дадеш примерчета, тук съвсем сериозно. За да разбера как конкретно XML се дъни и кога не върши работа.

> Преди броени дни трябваше да се оправям в 11 хиляди реда XML
> конфигурационен файл, измислен от едни оптимисти като теб.

Аз не съм оптимист. Аз съм песимист. Виждал съм безброй пъти иначе добри технологии, използвани по ебаси начина. Само едно примерче: функция на C++, да речем декларирана така: int f (const int &i); в която програмиста прави cast на i към не-const, понеже разбираш ли, искал да го променя??? Е ... какво да ти кажа.

Предполагам разбираш, че за мен въпросната XML конфигурация е полу-сериозна - полу-на майтап и не съм се замислял особено много (средно по 10 мин на постинг), така че и аз не очаквам да я използвам без сериозен редизайн. Като ми се наложи да направя (а ще ми се, като се освободя достатъчно от текущи задачи) мини-модел на нещо подобно, което ще използваме за платформата, която пишем, ще те предупредя, за да очакваш с трепет рухването й

Хм, обикновено само чета тези форуми, но тук не се въздържам да кажа няколконеща:

И все пак, според мен Windows Registry има следните недостатъци:
- Съхранява се на диска в двоичен формат. Съответно, ако нещо се скапе, майка плаче. А понякога се скапва (може би липса на журнална фс, не знам). XML като базов формат с предварително известна схема е по-добър вариант, според мен

Никога не съм виждал "скапано" регистри под НТ базиран Вин (само под 9х, където наистина няма журнална ФС), не и в смисъл нарушена консистентност на самата база или срив. Ако говориш за приложение, което само си е оплескало конфигурационните стойнсти в рег. (или някое друго му ги е оплескало) и съответно не работи, това е съвсем друга работа и няма почти нищо общо с темата.

- Няма понятие валидна конфигурация. Можеш да наблъскаш каквото си поискаш където поискаш. Може би е по-сложно да се поддържа Registry + схема на валидност на определен клон от него, може би просто Microsoft са над тези неща (и да го духат админите), но за мен схемата е важно нещо

Нима при текстов файл не можеш да наблъскаш каквото си искаш където си поискаш?

- Никой не може да ти каже на кой продукт, аджеба, принадлежат ключовете. Съответно, ако продукта не си ги махне при деинстал, постепенно става мамата си трака

Хм, и с какво тук концепцията за тъпчене на текстови файлове в /etc директорията е по-добра?

- Продължение на горното: продуктът е длъжен сам да си маха ключовете. Защо бе, джанъм? Като го няма, значи вече не са нужни...

Отново, с какво тук концепцията за тъпчене на текстови файлове в /etc директорията е по-добра?

- А ако искаш някак да се запазят, за бъдещ reinstall - дай да направим подходящ начин да ги запазваме. Примерно в HKEY_LOCAL_SYSTEM_ATTIC

Експортираш си ги в .рег файл и след инстал ги вкарваш пак.

- Тук малко спекулирам, но доколкото знам, няма link-ве. Сещам се, че можеш да си ги емулираш като в низово поле запишеш самия link, но нЕкакси не ме кефи. Предпочитам да го може самото Registry. А-ла файловата система на *nix-те

Точно тук най-малко спекулираш, прав си. :)

- Твърде малко стандартни типове и липса на възможност за дефиниране на нови (със задаване на съответния код за проверка на валидност). Примерно, IPv6.

Като редактираш текстов файл с vi някой проверява ли валидността? Освен това в текстовия файл (вкл. и XML-a) всичко е стринг - грижа на приложението е да го конвертира до каквото му трябва, напр. числова стойност.

Сега аз да кажа няколко недостатъка на текстовите файлове (в ХМЛ или друг формат) / предимства на регистри-то (слагам само най-ярките).

- Access control на ниво key и дори value (само при NT, разбира се). Не мога да дам на потребителя Иван права да модифицира само Listen директивата в httpd.conf например - трябва да му дам права в-у целия файл.

- Представете си следната ситуация. Сървър с няколко админи. Двама си пускат шел отдалечено. И двамата отварят по-горе долу едно и също време http.conf, smb.conf или някой друг основен конфигурационен файл. Редактират. След това единият прави Save. След него и другият. Какво става с промените на първия? Ако се ползваше регистри вместо текстов файл всеки щеше да промени само стойността на директивата, която го интересува, и този фал нямаше да се получи.

- Текстовите файлове са удобни за ръчно редактиране. Не са удобни обаче за автомтично редактиране от страна на инсталационен скрипт / фронтенд приложение за конфигурация / централизирана система за управление поради разнородната си структура. Както се казва, ако хванете 10 произволни конфиг файлове, те ще имат 11 различни формата ;). Всяка стойност в регистрито може да се прочете/промени/изтрие/добави с проста команда (за админи) или АПИ функция (за програмисти). За да се промени/прочете/изтрие/добави стойност в текстов файл, понякога трябва да се напише скрипт, разравящ файла, което може понякога да е сравнително просто, но може и да не е. А представете си, че при писането на този скрипт се допусне грешка и това доведе до скапването на някой ключов файл в големи мащаби. (напр. prefs.js в мозила профилите на 500 потребители е скапан и не могат да си пуснат мейл клиент-а - весело нали?).

Основната разлика е, че при регистри-то приложенията не пипат директно по файловете, а отправят АПИ заявки към ОС-а, който играе ролята на посредник и контролира достъпа. При това положение е логично да се избере бинарен формат - учеличава се производителността и се намялява консумацията на дисково пространство. Абе с две думи може да се каже, че системата на регистрито се отнася към системата с текстовите файлове така, както клиент-сървър бази данни към такива от типа на dbase/foxpro/msaccess. Една съвременна ОС не може да претендира за завършеност, особено в десктоп направлението, без подобно решение сопоред мен.

Ами просто ми направи впечатление, че се говори за един голям файл и за XML. Няма един файл, а много и те не са XML. Само командата "rg edit" генерира XML и след редактирането записва ключовете и стойностите във файловете.
Едва ли ще е чак такъв проблем да се напише подобна команда, която да генерира друг, по-четим формат за недолюбващите XML & GUI.
Т.е. това т.нар. "Registry" няма почти нищо общо с онова Registry.

> Аз, нещо което не разбираам ( и работи някак си ) - не го пипам :) .
Che kak se uchish?!

> тук в почето случаи не се налага търсене - просто директно посочваш записа, който ти трябва (с път до него).
A to pytyat ne se tyrsi, vikash?

> При това положение е логично да се избере бинарен формат - ... и се намялява консумацията на дисково пространство.
> Абе с две думи може да се каже, че системата на регистрито се отнася към системата с текстовите файлове така, както клиент-сървър бази данни към такива от типа на dbase/foxpro/msaccess.

Mne, boldnatoto ne vinagi e vyarno. Neka da dadem za primer samoto Windows registry - da se zabelyazal nyakoga da e namalyavalo kato razmer na faylovete (izklyuchvame rebuild na chisto - ima tool-cheta za celta)?
Drug primer - PostgreSQL. Faylovete s tablicite mu nikoga ne namalyavat razmera si, osven ako ne izpylnish VACUUM. Predpolagam i s pochti vsichki BD-ta e taka.

Май съм се изразил двусмислено. Имах предвид, че консумацията на дисково пространство ще е по-ниска, в сравнение с варианта, при който същото количество информация се съхранява в друг, неоптимизиран за тази цел формат, напр. текстов. Не съм искал да кажа, че ще намалява динамично при намаляване на регистрито.

формата не е в размера, а в това, че почти не се налага, или много малко трябва да се парсва, т.е. скоростта на зареждане в много случаи е в пъти по-голяма

май

Пък и в момента, в който намериш корена, вече не се налага да търсиш, а просто да обхождаш

е несъществено при конфигурационни файлове - те се четат веднъж, при тръгване на приложението/услугата и толкова. Значи ще спестиш ... ъъъ ... няколко десетки милисекунди.

За сметка на това:
а) трябва ти специален инструмент за редактирането им
б) сещай се как се пуска този инструмент на машина, която е отдалечена от твоята. Не че не може, но ако искаш да е разумно, трябва ти протокол между твоя и отдалечения компютър, създаден специално за редактиране на конфигурации
в) въпросният инструмент трябва да владее всичко, което владеят безбройните инструменти за обработка на текстови файлове. Или да има процедура за обръщане към/от текст и тя да е ... бърза. Тук искам да споделя едно свое наблюдение над Windows Registry, на над 1 GHz процесор (с само 1/4 G памет, наистина) - търсенето е баааавно. Не знам колко реда информация има в това Registry (не е особено голяма инсталация на Windows), не знам и дали проблема не е в regedit, само знам, че като се наложи да търся ... сещаш се.
г) двоичните формати имат свойството трудно да се разширяват. Вече няколко пъти казах, че за мен е добре човек да може да си добавя свои типове, примерно. Дори и без това съм сигурен, че с времето всеки формат се развива, тоест променя. Конкретно за Registry предполагам че просто се прави миграция от единия формат към другия. Което е обаче не решение, а workaround на проблема. Просто защото всички инструменти, които работят директно с Registry, спират да работят.
д) слагам го на последно място, защото все пак може да се спори - поправянето на файл с двоичен формат е значително по-тежко от поправянето на текстов файл. Да, не много често се налага да се прави, но ако се наложи - по-трудно е.

Предполагам, че защитниците на двоичните формати ще изтъкнат, че те са по-сигурни, защото не се редактират директно, следователно се гарантира структурата им. На което аз ще кажа, че не се редактират директно само, защото е неудобно. Иначе всеки би използвал любимия си инструмент, поради съответните причини - може да се пуска отдалечено, по-красив е, интегриран е с нещо ... причини много.

Във всеки случай, ако познавах формата на Registry, аз лично бих го редактирал с двоичен редактор без да ми мигне окото, особено когато е отдалечено. И съответно вероятно бих допуснал грешки ... което налага инструмента за четенето да се съобрази с такива грешки ... което от своя страна налага поне минимална проверка на двоичния формат при четене, съответно води до забавяния и т.н. Такава проверка трябва да се прави така или иначе, между другото (и тя се прави) заради потенциални бъгове в редактиращите инструменти.

Което ни води до това, че формата не е 100% гарантиран, следователно не е с нищо по-добър от текстов файл. А колкото до текстовия файл - просто дефинираш схема, за спазването на която се грижи инструмент аналогичен на regedit и - получаваш 99% гарантирана структура.

Последно: двоичният формат не е преносим между платформи с различна наредба на целите числа в паметта - примерно MAC и x86. Е, и това може да се забиколи с избора на едната наредба и оставяне на инструментите да се оправят.

С всичките тези приказки исках да покажа, че единствената полза от двоичния формат е неговата скорост. Единствената. За сметка на това има купища недостатъци. И, не е подходящ за конфигурации.

Моята идея (наистина твърде сурова и също с недостатъци) е универсален (доколкото е възможно) текстов формат с гарантиран интерфейс към него. Интерфейсът те предпазва от грешки, но ти позволява да го заобиколиш, ако искаш и знаеш какво правиш. И, пак интерфейса позволява на приложенията без да разбират формата на файла, просто да си получат необходимата конфигурационна информация.

лошо няма. Повече участници - по-интересна и полезна дискусия. Така че заповядай винаги, когато можеш и имаш желание

Сега по постинга ти:

Понятието валидна конфигурация така или иначе съществува. Щеш не щеш трябва да гарантираш, че кодът ти е получил разумни параметри. Проверката се прави на няколко нива, като двете най-ниски могат да ти бъдат гарантирани от външен инструмент: имам предвид гаранция за правилната структура (т.е. синтаксис) + проверка на определени взаимовръзки (май на това му се вика семантика).

Нито Windows Registry, нито голия текстов файл ти дават такова нещо - трябва да си го правиш сам. Наистина, Windows Registry има заченки, но само толкова. Не можеш да направиш така, че примерно ключ еди-кой си да се намира задължително еди къде-си в йерархията. Е, според мен може (и е разумно) да се направи така, че приложението да може да дефинира схема на валидна конфигурация, използвайки стандартен механизъм, която му гарантира, че при четене на конфигурацията тя ще е валидна поне донякъде. Естествено, това означава, че няма само да си чете конфигурационния файл, но какво от това? Поне 80% от софтуерите ще бъдат доволни.

За голяма част от следващите ти коментари - виж постинга ми по-долу. Не си представям конфигурация от неуправлявани текстови файлове; представям си инструмент за съхраняване на конфигурации, който използва текстов формат за съхранение на данните на диска, заради допълнителни удобства на този формат, а не защото самият текст ти гарантира, че някой ще ти махне самия файл при премахване на приложението, което го използва.

И забележката ми към Windows Registry беше, че като аналог на инструмента, за който говоря, не ти дава възможност да следиш конфигурациите и да премахваш ненужните.

А, твърдиш, че имаш възможност в Registry да създадеш връзки. Би ли пояснил? И да ми кажеш как да го направя с regedit, примерно. Да кажа аз какво разбирам под връзка (link) - механизъм, позволяващ промените в определен лист / клон на конфигурацията да се виждат автоматично като промени в друг клон, за който е указано, че съдържанието му е съдържанието на първия клон.

Пример: няколко различни web сървъра (като демони, или сервизи, както му викат в Прозоречния свят), които има своя конфигурация + връзка към място, в което е описана да речем конфигурацията на виртуалните web сайтове, които се съхраняват на тази машина. И, добавянето на нов виртуален сайт става прозрачно и едновременно за всичките тези демони

Po-byrzo ot kakvo?
Az prosto ostanah s vpechatlenieto, che si mislish, che sled kato zadadesh tochen pyt, to elementyt shte byde nameren za 0 vreme (OK, konstanta :-) Vse edno kato znaesh pytya ot Plovdiv do Sofia da mojesh da stignesh za 0 vreme, ili nay-malkoto vremeto da ne zavisi ot razstoyanieto

Разликата е в това, че имаш контекст, който се състои от малко на брой елементи, всеки от които на свой ред е контекст за други елементи. В базите имаш малко на брой таблици с много елементи.

В момента ми се струва, че в една дървовидна структура се търси по-бързо, отколкото в индексите на база поради това, че с всяка стъпка навътре намаляваш броя на елементите, в които търсиш, след което попадаш на контекст, в който търсенето е точно 0 и може да съдържа произволен брой полета.

Но не съм се замислял особено много, признавам Струва си, но може би по-натам

На практика с една такава унификация се убиват няколко заека наведнъж. Разделянето на програми например с chroot-а ще почнем да си имаме проблеми, освен това разделянето на привилегии ще бъде много по-сложоно и размито. Разработката на софтуер се усложнява, защото при всяко махане/добавяне/промяна във формата на конфигурационния файл се налага известяване на този демон за промяната следователно, дори това да се прави, ако има грешки в новия софтуер е въсможно да създаде затруднения на въпросния демон. Освен това се получава задължителна унификация на средата,като последствие системата ще е много по-уязвима. Всичките тези щуротии в името на това на потребителя /който така или иначе не трябва да се занимава с конфигурирането на компютъра си / да му се покаже безумен XML браузър с n^m възможни настройки от които той изживявайки се като root, естественно нищо няма да разбира но за сметка на това ще държи да пробва.... Къде е ползата ?

Аз, честно казано, се уморих да мисля по проблема, така че ако някой иска да продължи - да заповяда. Може и наистина да не си струва, особено за малки инсталации - едно web-сървърче, прокси, защитна стена, mail и горе-долу това.

Така че, последно:

Може да се поспори доколко унифициарността на системата я прави по-уязвима - едва ли това е директно следствие от унифицирането (и, видите ли, хората знаят какво и как да атакуват), по-скоро е резултат от недобрата абстракция. Защото ползата от общия стандарт е че дори да се появи дупка, много повече хора ще помислят как да я запушат, отколкото ако всеки е сам за себе си. Рабира се, има си цена - докато я запушат, ще има повече жертви. Така че ползата е стратегическа, а тактически може да излезе скъпо.

XML инструмента, за който говориш далеч не е задължителен - ще го използваш, ако създателите на софтуера ги е домързяло да напишат такъв за своя софтуер, или той не ти дава пълен контрол. Не виждам нещо по-лошо в такъв XML браузър от regedit - напротив, виждам по-добро, най-малкото контрол над това, което юзера се опитва да направи.

Versioning си е проблем така или иначе; просто в неуправлявана среда като Windows Registry се забелязва по-трудно, отколкото ако те принудят да дефинираш валидност. Иначе не мисля че е голяма работа да смениш схемата при обратна съвместимост - ти така или иначе вече си се погрижил да поддържаш старата функционалност, колко му е да поддържаш и конфигурацията й.

Основната ми идея, повтарям, е да се унифицира решаването на конфигурационните задачи. За да не се налага всеки сам да решава тези задачи. Разбира се, ако може. Ако не може - здраве. Направихме си малко умствено упражнение, няма лошо

лошо няма. Повече участници - по-интересна и полезна дискусия. Така че заповядай винаги, когато можеш и имаш желание

Сега по постинга ти:

Понятието валидна конфигурация така или иначе съществува. Щеш не щеш трябва да гарантираш, че кодът ти е получил разумни параметри. Проверката се прави на няколко нива, като двете най-ниски могат да ти бъдат гарантирани от външен инструмент: имам предвид гаранция за правилната структура (т.е. синтаксис) + проверка на определени взаимовръзки (май на това му се вика семантика).

Нито Windows Registry, нито голия текстов файл ти дават такова нещо - трябва да си го правиш сам. Наистина, Windows Registry има заченки, но само толкова. Не можеш да направиш така, че примерно ключ еди-кой си да се намира задължително еди къде-си в йерархията. Е, според мен може (и е разумно) да се направи така, че приложението да може да дефинира схема на валидна конфигурация, използвайки стандартен механизъм, която му гарантира, че при четене на конфигурацията тя ще е валидна поне донякъде. Естествено, това означава, че няма само да си чете конфигурационния файл, но какво от това? Поне 80% от софтуерите ще бъдат доволни.

За голяма част от следващите ти коментари - виж постинга ми по-долу. Не си представям конфигурация от неуправлявани текстови файлове; представям си инструмент за съхраняване на конфигурации, който използва текстов формат за съхранение на данните на диска, заради допълнителни удобства на този формат, а не защото самият текст ти гарантира, че някой ще ти махне самия файл при премахване на приложението, което го използва.

Значи, при по-новите Уиндоуси (а май и при по-старите) след зареждането на ОС-а файловете на регистри-то се заключват "като за световно" - не могат да се отворят дори и в режим за четене. Целта е именно да не се позволява директен достъп на приложенията до тях. Мотивите за това са ясни. Ако правилно те разбирам, то различията ни се свеждат до това дали информацията да се съхранява в бинарен формат или в друг такъв (текстов), който да позволява файлът да се редактира директно, когато това е необходимо и възможно (т.е. само когато сме заредили друга ОС и файлът не е заключен). Аз мисля, че изключително рядко се налагат подобни интервенции, а и сега има възможности за тях (файлът може да се прехвърли на друга машина, да се закачи временно към нейното регистри, да се направят нужните промени, да се откачи и да се върне обратно на старото място). Затова според мен бинарният формат е логичният избор, тъй като консумира по-малко място и позволява по-голямо бързодействие.

И забележката ми към Windows Registry беше, че като аналог на инструмента, за който говоря, не ти дава възможност да следиш конфигурациите и да премахваш ненужните.

А, твърдиш, че имаш възможност в Registry да създадеш връзки. Би ли пояснил? И да ми кажеш как да го направя с regedit, примерно. Да кажа аз какво разбирам под връзка (link) - механизъм, позволяващ промените в определен лист / клон на конфигурацията да се виждат автоматично като промени в друг клон, за който е указано, че съдържанието му е съдържанието на първия клон.

Да, и аз това имах предвид - че си прав. Няма такава възможност, засега. Сега като си чета репликата, виждам че може да се тълкува по 2 противоположни начина. Исках да кажа, че по тази точка съм съгласен :)