Ну вот и дождались Linux Registry!!! Ура!!!

> применение неймспейсов, скажем, по той же схеме, что в яве - т.е. например иксы пусть живут в /system/sw/org.xfree86 (или /system/sw/org.freedesktop.xserver) etc.

контроль непересечения?

> угу и у обоих на херову тучу всего бакэндов метров на надцать, > в надцати из котрых девелопер поленится, и напишет парсер конфига > не на чистом Си, а с какойнить парсинг-либрари от фердовых > разработчиков

Вот именно за этим и нужно создать три простейших парсера - для файлов типа /etc/passwd (а также любой CSV-образный файл, например group, inittab, fstab...), еще один бакэнд для XML-ок и третий для XF86Config-подобных (plain-text, но с вложенными секциями, имхо лучшее сочетание :-)).

P.S.: эти три фронтенда будут работать легко и непринужденно, их хватит 99.9% разработчиков, и весить от силы пару метров, если вообще не сотню-другую килобайт, на всех троих...

вот как раз эти неймспейсы надо будет стандартизировать, и сделать максимально упрощенными в понимании, так чтобы даже самые "новички" :) разобрались в нем без проблем...

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

> тогда вообще можно будет не использовать локальных настроек (тех, что в $HOME), а просто заменить их определенными ключами с нужными пермишенами.

Живучесть системы при возможности записи пользователем в / (рут-раздел) ?

Если не в <рут-раздел>, то каков порядок монтирования конфигов ?

Кстати говоря, порадовал файлик registry.kdevelop в архиве с сырцами. Похоже, бэкенда для KConf мы все-таки дождемся быстрее, чем для GConf =)

можно просто сделать что-то вроде базы данных программ, и регистрировать проги там.

конечно, решение половинчатое, но работать будет...

еще варианты??

> вот как раз эти неймспейсы надо будет стандартизировать, и сделать максимально упрощенными в понимании, так чтобы даже самые "новички" :) разобрались в нем без проблем...

Ещё раз:

Кто будет распределять "валидные" ветки реестра для разработчиков/софта в условиях распределённой разработки приложений?

Где будет вестись реестр зарегистрированных/"валидных" разработчиков/софта?

Где есть описание этой структуры в текущей редакции?

> надоело. нужен стандарт

Мдааа. Простой вопрос ... чтобы контролировать каталог с десятью конфигами, достаточно куда-нить сложить их мд-пятки. И периодически чекать, на предмет "неожиданно припух". А если они превратятся в туеву хуча файликов ? А если пятки лежат не локально ? Зае... чекать . Самый важный каталог остался без присмотра..... Осюда и начинаются дыры....

>в паре небольших проектов был большой гимор именно с конфигами...

Ну и ? Теперь захотелось гимора не с парсером 1-го файла а целой каталоговой ветви файлов ?

> лениво очень...

Гы! Так может лучше единожды написать парсер и пользовать во всех проектах ?

> Вот именно за этим и нужно создать три простейших парсера - для файлов типа /etc/passwd (а также любой CSV-образный файл, например group, inittab, fstab...), еще один бакэнд для XML-ок и третий для XF86Config-подобных (plain-text, но с вложенными секциями, имхо лучшее сочетание :-)).

CONFIG 4 GNU!!!

дык...

причем здесь возможность записи в рут-раздел??

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

хотя не знаю, конечно...

а вообще живучесть будет нормальная, если конечно же ACL будет прописано нормально.

> контроль непересечения?

Еще раз - это НЕ проблемы либы. Она обеспечивает иерархическую структуру, но не определяет, как ее использовать. Контроль - это уже проблемы разработчиков, то есть нас с вами. Я сделал предложение - использовать опыт явы. Вы можете назвать конкретные недостатки такого подхода?

я уже вам ответил в предыдущем сообщении :))

Еще раз:

> Кто будет распределять "валидные" ветки реестра для разработчиков/софта в условиях распределённой разработки приложений?

НИКТО

> Где будет вестись реестр зарегистрированных/"валидных" разработчиков/софта?

НИГДЕ

> Где есть описание этой структуры в текущей редакции?

ЕГО НЕТ

Это от лени почитать доку и научиться пользоваться стандартными утилитами.

Давайте эту ХРень еще в ядро засунем и в БСДшное то же

gr_buza (*) (02.06.2004 22:48:36)

> тогда вообще можно будет не использовать локальных настроек (тех, что в $HOME), а просто заменить их определенными ключами с нужными пермишенами.

> можно просто сделать что-то вроде базы данных программ, и регистрировать проги там.

Блн, да остановись и задумайся, в конце-концов:

Живучесть системы при возможности записи пользователем в / (рут-раздел) ?

Если не в <рут-раздел>, то каков порядок монтирования конфигов ?

Система UNIX, где текст заменили на XML ?! А смысл?

> можно просто сделать что-то вроде виртульной фс, в которой все эти настройки и будут храниться

Кстати говоря это оччень интересная мысль... с учетом специфических требований к такой фс, а именно очень большое количество очень маленьких файлов, возможно что специально заточенная под это дело фс справится лучше. Хотя, с другой стороны, есть ведь райзер =)

дык блин!!!

ЕЩЕ РАЗ!!!

НЕТ ТАМ XML!!!

это просто замена секций в конфигах на определнные каталоги.

вот и все!

некошерно как-то :))

уж сильно на винду смахивает :))

> Система UNIX, где текст заменили на XML ?! А смысл?

Тьфу. Я тут полчаса назад внятно объяснил, что XML'ем там не пахнет даже. Нет, этот диалог с глухим однозначно надо прекращать.

Короче: поставь это дело сам, посмотри, а ПОТОМ задавай вопросы. Если они еще будут.

> причем здесь возможность записи в рут-раздел??

А где у тебя лежат конфиги или откуда монтируются?

> а вообще живучесть будет нормальная, если конечно же ACL будет прописано нормально.

$ dd if=/dev/null of=/etc/registry/blah.xml ?

> уж сильно на винду смахивает :))

Это чем же? В винде это все запихано в один файл с неизвестным форматом, размазанный по фс. При использовании отдельной фс (естественно на уровне драйвера ядра) любая прога в системе может легко обойти API и работать с конфигами напрямую, опять же всякие sed/grep/awk работают без проблем. Окромя потенциального прироста в скорости, никаких проблем не вижу =)

еще раз повторить что xml тут нет???

вот, пожалуйста:

XML ТУТ НЕТ!!!!!!

>Тьфу. Я тут полчаса назад внятно объяснил, что XML'ем там не пахнет даже. Нет, этот диалог с глухим однозначно надо прекращать.

Почти что так:

The rg edit command provides an easy way to edit a group of keys using your prefered editor. It will dump the selected keys into an XML representation, and run the editor to let the user edit them. After user modifications, it will update, remove or include the keys based on the modified XML file. This real screenshot shows me using kedit to modify the XFree configuration keys related to the monitor.

GladAlex

> Давайте эту ХРень еще в ядро засунем и в БСДшное то же

Давайте :|

>>в паре небольших проектов был большой гимор именно с конфигами...

>Ну и ? Теперь захотелось гимора не с парсером 1-го файла а целой каталоговой ветви файлов ?

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

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

ну тогда и не знаю :))

pavel@linux:~> dd if=/dev/null of=/etc/registry/system/users/root/home
dd: opening `/etc/registry/system/users/root/home': Permission denied

Еще интересный факт: несмотря на всю простоту, оно использует UTF-8 в качестве единой кодировки конфигов.

Блин. ГнуЛинуксу как десктопу нужно:

Нормальный Xserver с современными возможностями (хороший кандидат - FD.O Xserver) и нормальной поддержкой со стороны производителей железа.

Стандартная либа парсинга конфигов. Желательно Ini-style и чтобы все варианты были продуманы (тот же XF86Config) и API удобный был. А убогий реестр не нужен. Это доказал YaST из SuSE. Unix/Linux должен быть clear and simple, а не помойка настроек как SuSE и Windows. К этой либе можно прикрутить сколь-угодно фронтендов. Чтобы в самих файлах конфигурации, коменты были на английском (для редактирования ручками), а локализованные каждая программа устанавливала в общую базу данных, которую бы и использовали различные фронт-енды.

Юзерские конфиги должны быть в .etc/ или .config/, т.е. занимать в юзерской папке только одну папку, не больше.

Всё вроде???

Вот, нашел про цифирки =)

/* The serialized format is
   -------------------------
   RG001\n
   type\n
   comment (with newlines)\n
   <DATA>\n
   The data encoded as text
   -------------------------
*/

Цифирки - это тип значения в ключе. 

/****************************************************/
/* Key data types */
#define RG_KEY_TYPE_UNDEFINED 0
#define RG_KEY_TYPE_DIR       1
#define RG_KEY_TYPE_LINK      2
/* this gap is for special key meta types, that can't go into regular files */
#define RG_KEY_TYPE_BINARY    20
/* This gap is for binary data types that have some semantics
   that somebody can invent in the future */
#define RG_KEY_TYPE_STRING    40
/* Data types bigger than RG_KEY_TYPE_STRING are still strings, but may have
   some semantics that will be handled by other liиraries */

Похоже на винду стандартизацией. Я пишу свой конфиг так как хочу, для DHCP он у меня по 10 файлам раскидан и smb.conf то же не тривиален - подстановки переменных. Стандарт тем и плох, что загоняет в рамки.

Файлы и vi рулят. Проще нагородить всякой фигни чем изучить уже существующее.

дык он и остается clear and simple.

по принципу - один ключ - один файл, одна секция - один каталог.

другое дело, что юзерские конфиги можно было бы складывать в одно место, во избежание путаницы.

Надо слинковать все исполняемые файлы системы в один - ХУ.ЕХЕ ! Это файло при запуске будет оптимально парсить единый для всех конфиг - ХУЕДЖЕСТРИ.CFG ...

> дык он и остается clear and simple.

> по принципу - один ключ - один файл, одна секция - один каталог.

Он не остается - он другим быть и не может. Примитив. Интересно, как защитники этого чуда представляют себе .emacs (или .vimrc :)) в виде пар ключ-значение?

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

другое дело, что все это раскидывается по каталогам...

> Я пишу свой конфиг так как хочу, для DHCP он у меня по 10 файлам раскидан и smb.conf то же не тривиален - подстановки переменных

А это лечится скриптами. Кстати обращаю внимание вот на какую вещь: никто, строго говоря, не запрещает файлу-ключу в реестре быть named pipe (во всяком случае, в исходниках парсится он линейно). Подумайте, как здесь можно извратиться =)

> Стандарт тем и плох, что загоняет в рамки.

И он хорош тем же =)

а как он выглядит, а то сейчас у меня линукса нет, а на шелле на соляре (в данный момент сижу с него), его нет??

> хороший кандидат - FD.O Xserver

Я Вас очень огорчу, если сообщу, что такой вещи в природе не существует? Есть x.org - которые недалеко ушел от XFree. И есть kdrive - который очень прогрессивен, но еще даже не альфа качества. Вы о каком?:)

> К этой либе можно прикрутить сколь-угодно фронтендов

Все-таки они, наверное, бекенды?:)

> занимать в юзерской папке только одну папку, не больше.

Вашими бы устами да мед пить:)

А в целом - почти согласен. Правда, не уверен, что список must have ограничивается всего двумя пунктами:)

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

Кстати да. Никто не мешает проге производить подстановку переменных и прочие извраты при чтении своих ключей.

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

Наверно будет как в винде (если приживётся) - приспособят заодно для сериализации, в итоге будет засрана половина неймспейсов ;)

http://www.dotfiles.com/

>1) тем что этот яст от гуя не оторвать

оторвать, yast'овский "реестр" правит конфиги /etc/rc.conf/чего-то_там потом запускает скрипт SuSEconfig который по /etc/rc.conf/чего-то_там правит нормальные конфиги

дык можно сразу править /etc/rc.conf/чего-то_там без YaST'а

>3) имеет ли яст CLI ? сомневаюсь

имеет

на xml свет клином не сошелся...

Да боюсь,что сошелся ... :)))))). Он буйные помыслы девелопера ничем не ограничивает. Добавил фичу - клацнул ее в xml-конфиг и далее попер не добавляя наворотов в парсер.... ляпотаааа.... :))))

В принципе если поймать АСМ-кодера и заставить его наваять свершустрый интерпретатор кооторый за 1 проход все это разберет... отчень рульная вещь будет. Разве что к ней понадобится эдакий XML редактор который это все не XMLом казать будет, а формами...

> Форматная помойка в /etc разгребается на одной-десяти машинах нормально, но когда нужно думать про единую инфраструктуру на предприятии и взаимодействии компонентов и блоков, захочешь стандартные конфиги.

А когда подумаешь про то как они выглядят сразщу перехочешь. Потому что КОНФИГ напрямую зависит от формата того, что там сохранено. Пара ключ-значение - это бледный и ублюдочный способ создать геморой, а не представить структурированные данные. Валяй редактируй regeditлм многострочные значения. regedt32 пришлось изобретать. XML нужен для структурированного обмена информацией между прораммами, платформами и прочее. НО НЕ ДЛЯ ЛЮДЕЙ. Потому что структура поглощает информацию. Редактировать XML ный конфиг - хуже этого только бинарный формат.

А смысл? Для фронтэндов? Пусть их пишет тот кому они нужны. Я лично после M$ пользованся сначала ГУЕм, потом всякими фронтэндами, а теперь всё больше прихожу к файлам и vi.

В *NIX мире есть один постулат - файлы, и не надо выдумывать всякие API, они от M$. Почти все вещи решаются скриптами гораздо легче чем на том же C хоть пюсуй его, хоть нет.

> другое дело, что юзерские конфиги можно было бы складывать в одно место, во избежание путаницы.

А они и складываются. В /user. Просто ребята (справедливо) сочли, что /etc/passwd и /etc/group - это все-таки системные, а не юзерские конфиги. Хоть и хранят информацию о юзерах.

> Пара ключ-значение - это бледный и ублюдочный способ создать геморой, а не представить структурированные данные

Докажи.

> Валяй редактируй regeditлм многострочные значения. regedt32 пришлось изобретать

В данном случае все куда проще:

$ vim /etc/registry/system/users/root/home

Хоть обредактируйся, да? И многострочные значения там хранятся в естественном виде - как несколько строк =) Вообще местный формат несколько напоминает maildir, если честно. А файлы с ключами - письма. Принцип тот же: заголовок, разделитель, и потом до конца файла тело сообщения. Вот тут то же, только в конце значение ключа.

> XML

Нет там XML! Нет!!!

нет, просто для удобства.

третий раз повторюсь: не смотрите на название, оно неудачно!!!

и никаким API тут и не веяло, я Вас уверяю.

> В *NIX мире есть один постулат - файлы, и не надо выдумывать всякие API, они от M$

Давай ты гуй "на файлах" сделаешь, без API. А мы посмотрим =)

Кстати в данном случае я вообще не понимаю претензий. Кому хочется, пользуют единый универсальный API. Кому нет - grep/sed/awk (ну теперь еще к этом добавится ls). Все мирно сосуществует. В чем проблема?

Ещё раз - нафига оно надо? Какая разница между ключ-значение и файл-содержимое? Есть стандартная функция --- read и не надо других. Какая разница если мне еще и содержимое ключа парсить.