Linux Registry

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

Е, не звучи чак толкова лошо, както вин регистъра :)

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

Въпросът е доколко лесно може да се вгради в текущите системи и приложения и дали няма по-добри алтернативи, отново с унифицирани кофигурационни файлове и форматите им. Ще видим, времето ще покаже :)

-----
Lay your troubles on my shoulder, put your worries in my pocket, rest your love on me

като чуя XML и нещо ми става на стомаха...

Мда, по-трудно се чете от хората, отколкото добрия стар plain text.

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

$ locate my.cnf
/etc/mysql/my.cnf

ма то е сложно - трябва и updatedb да правиш от време на време ( или в crontaba да си го сложиш)
Друго си е да си парснеш едно xml - че, да си го прекараш за по интересно през sql-че и да си направиш select-че
И то пак се върнахме до началото - хората са се погрижили да бъде индексирана цялата файлова система

Когато боговете говорят, ония с фактите никакви ги няма.

Ами в Gentoo си идва сложено, дори трябваше да го преместя от daily в weekly. А и не е разхвърляно въобще - всичко е някъде в /etc :). А това в какъв формат са файловете - все ми е едно, стига да не се зверя 10 минути, докато рабера кой таг кой е всъщност и каква работа върши.

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

1. Системна функционалност, която държи DOM в паметта и всяка програма работи директно с този DOM, а не с файла. Съответно, инструментите за конфигуриране променят пак него, а не файла, след което на определено време или след еди-колко си време без активност този DOM се сериализира в XML. Съответно, ако пипнеш директно XML-а някой се грижи да го парсне.

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

2. Конфигурацията не стои в един, а в много XML документи, които са навързани един с друг чрез препратки. И цялата тази красота - в отделна, подредена по аналогичен начин директорийна структура. Всеки софтуер си знае къде му е файлчето и си го парсва като момченце. Освен всичко друго, удобно е защото с едно cp можеш да си вземеш работеща конфигурация и да я боднеш на нова машина. Включително конфигурация на отделен модул, не на целия Linux и софтуерите в него.

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

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

> 1. Системна функционалност, която държи DOM в паметта и всяка програма
> работи директно с този DOM, а не с файла. Съответно, инструментите за
> конфигуриране променят пак него, а не файла, след което на определено
> време или след еди-колко си време без активност този DOM се сериализира в
> XML. Съответно, ако пипнеш директно XML-а някой се грижи да го парсне.

Отсега си представям колко DOS атаки ще се появят срещу този демон ...

А ако някой направи грешка при редактирането, която не позволява парсирането на XML-a (сложи една < в повече например)? _Всички_ приложения ще откажат да работят? Хайде, ако демона работи, може да се опита да направи нещо умно... А ако промяната се направи докато не работи?

А къде ще е конфигурацията на този демон? В същия файл или за него ще направим изключение? :Р

Как ще се определя кое приложение до кои части от файла ще има достъп? Не вярвам да очакваш, че всички приложения ще играят честно (дори и да искат).

> 2. Конфигурацията не стои в един, а в много XML документи, които са
> навързани един с друг чрез препратки. И цялата тази красота - в отделна,
> подредена по аналогичен начин директорийна структура. Всеки софтуер си
> знае къде му е файлчето и си го парсва като момченце. Освен всичко друго,
> удобно е защото с едно cp можеш да си вземеш работеща конфигурация и
> да я боднеш на нова машина. Включително конфигурация на отделен модул,
> не на целия Linux и софтуерите в него.

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

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

buzzwords, buzzwords... "фундаментална", "технология" ... Ами ако приложението няма нужда от структурирани данни? Ако структурата е толкова сложна, че не може да се представи (добре) в XML заедно със всичките му "технологии"?

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

Не мисля така. И за (мое) щастие в анархичната група на Линукс програмистите това никога няма да стане :)

Говорим си за XML ( eXtended Markup Language ) , а защо не за HTML ( който също е език за маркиране ?!? ) ?

Цитат : "
> 1. Системна функционалност, която държи DOM в паметта и всяка програма
> работи директно с този DOM, а не с файла. Съответно, инструментите за
> конфигуриране променят пак него, а не файла, след което на определено
> време или след еди-колко си време без активност този DOM се сериализира в
> XML. Съответно, ако пипнеш директно XML-а някой се грижи да го парсне.

Отсега си представям колко DOS атаки ще се появят срещу този демон ... "
Сигурно, ще измислиш и ДОС атака, която ще кара кой да е JavaScript вместо да ти показва датата и времето на системния часовник ( както и си го написал скрипта ) - да покзва припемрно : "Аз съм пич и пия бира" ?
Демон ?!? XML ?!? - дали ?
Аз за XML daemon не съм чувал - не твърдя, че ги чувам и другите неща но ... DOM - Document Object Model - не го виждам daemon-а тук , така че не видях и ДОС атаките. Бих казал ДОС атака срещу УебСървъра, който предоставя XML документа - да, но срещу самия документ ... все едно да се напише ДОС срещу .txt в plain text.

Цитат : "А ако някой направи грешка при редактирането, която не позволява парсирането на XML-a (сложи една < в повече например)? _Всички_ приложения ще откажат да работят? Хайде, ако демона работи, може да се опита да направи нещо умно... А ако промяната се направи докато не работи? "
А защо всеки трябва да прави редакция на този файл ( файлове ) - след като се ограничи права за редакция да има само супер потребителя - дори и някой да се обърка да го повреди файла : ".
Ами след като има такова ниво на достъп, сам си е виновен. Предполагам ще се съгласиш с мен ? Аз, нещо което не разбираам ( и работи някак си ) - не го пипам :) .

XML - пак тази абревиатура XML. А защо не .txt, .rtf или .doc - пак всеки ще си го парс-ва както си иска. Тук вече не опира до желание - ами до възможности - според мен.

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

Със здраве ...

*sigh* :(

Ето това са вече мнозинството Линукс потребители. Не разбира бъкел, но държи да си каже мнението ... И се обижда като му кажеш, че не разбира...

И ето, ти ги посочваш

DOS атаките ... не мисля, че са проблем. Със същият успех можеш просто да хапнеш процесорното време на машината, ако имаш право да пускаш процес(и) на нея.

Това с редактирането си е наистина сериозен проблем. Може би просто трябва да се забрани или админа да си поема риска Пък и не вярвам някой да тръгне на ръка да редактира XML, след като може да се използва инструмент, който да ти гарантира не просто XML синтаксис, но и спазване на схема.

Което е още едно предимство пред custom config - имаш механизъм, с който да направиш поне базова проверка дали ти е валидна конфигурацията, преди да пуснеш софтуера, който я използва.

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

Колкото до достъпа - лесно е. Слагаш атрибути за достъп и готово. Ако държиш. Щото не се сещам какво пречи в момента на произволно приложение да изяде (и промени, ако е root) конфигурациите на всички останали.

Защо трябва да е XML ли? Ами не трябва. Аз даже не искам. Предпочитам DOM, защото на приложенията не им трябва да парсират, а да си получат подредено конфигурацията. А защо трябва да е общ базов формат? Защото мноооого рядко се получава така, че структурата на конфигурацията да е толкова различна, че да изисква нов синтаксис.

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

Аз не виждам лошо щом проблемът е общ да има общо решение. А не всеки да се налага да измисля топлата вода. И, естествено, да не я доизмисля. Защото едно е да решиш проблема цялостно, веднъж и завинаги и после просто новия код да се върже по стандартния начин, а съвсем друго да почваш почти от A, Б всеки път.

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

Колкото до това дали хората ще го приемат или не - ако е успешен, ще го приемат. Ако не е - няма да го приемат. Мен не ме притеснява което и да стане. В крайна сметка, интересно е идеите да се изследват, за да видим какви зайци ще изкочат от тях

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

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

Когато боговете говорят, ония с фактите никакви ги няма.

Мисля, че не си прав. Що пък да се забави? Вместо да си парсираш сам файла, получаваш го директно структуриран. Цялото забавяне е едно парсиране при startup.

Че е сложно, сложно е. Че има възможности за издънки - има. Като с всяко общо решение на клас проблеми. Ама като се замислиш, библиотеките какво са? Не са ли точно същото нещо... коя да е библиотека. Защо никой не рита срещу библиотеките мислиш? Защото оценява ползата от тях. Тези, които не са добре направени - умират. Останалите се използват и хората им се кефят.

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

Разбира се, може и да бъркам. Знаеш ... поживем, увидим

Сложността на проблема е, че такова едно нещо напрактика си представлява база данни, както и да е реализирана (недай Боже с текстов файл, както някой каза) и тя си страда от проблемите на всяка база данни и си има изискванията за такава - т.е. всяка база данни с набъбването си става нестабилна - някой ще каже - "ама тая няма да е голяма" - но това не е сигурно. Трябва надеждно да се почиства от "мъртви" записи, и трябва явно да е на транзакционен принцип - в смисъл - ако нещо почне да пише или да трие - да е сигурно и за приложението и за базата, че транзакцията е завършила - не да се въвежда два пъти една и съща информация, ако при предишния запи приложението не е разбрало, че записът е станал примерно. А при триене, ако няма надеждни транзакции не ми се мисли какво може да стане. А - и заключване - ама на кое - на записа или на базата - с XML запис трудно ще заключиш (или бъркам?). И още , и още...

Когато боговете говорят, ония с фактите никакви ги няма.

Аз проблема го виждам другаде - виж коментара ми за базите данни

Когато боговете говорят, ония с фактите никакви ги няма.

Не бях помислял за размера, признавам. Отсега да кажа, че за мен размера няма да пречи особено много на бързодействието, поради простата причина, че за разлика от класическите бази, тук в почето случаи не се налага търсене - просто директно посочваш записа, който ти трябва (с път до него).

Транзакции без съмнение трябва да има. И съответно, за да не се блокират останалите приложения, работа в изолирано копие. Както виждаш, за файл не говоря - не смятам, че е разумно конфигурацията да се прави директно през файл, защото файловете от гледна точка на ОС са неструктуриран BLOB, който трудно се поддава на общо използване от повече от един процес.

Като се замислиш, ядове наистина много. И това, че трябва да се почиства - също. Директно изискване - целият софтуер в Linux-а ти трябва да е управляван. Не че само по себе си това е нещо лошо, включително да управляваш софтуера, който си дърпаш и инсталираш с ./configure ... но детайлите наистина могат да ти изядат главата. Дори само защото въпросната система няма да я има навсякъде и трябва да поддържаш и четене през файл, и четене през подобна DB.

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

Интересно, но всъщност никой (дори автора на темата) не прочете за конкретната реализация :).

[линк]

Накратко:
Отделните ключове се съхраняват като отделни файлове в /etc/registry за системната информация и в $HOME/.registry за отделните потребители.

Няма да има нито daemon, нито sql база, само програма и библиотека за парсване и променяне на ключовете.

>"Интересно, но всъщност никой (дори автора на темата) не прочете за конкретната реализация :)."

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

Когато боговете говорят, ония с фактите никакви ги няма.