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

Тогда вообще нихера непонятно - сплошные домыслы.

ткните меня в место, где написано

> конфиги я так понял там больше напоминают традиционные никсовые - key/value pairs.

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

Не переходили только потому, что ресурсов не хватало. А теперь с этой косностью стали прощаться хотя бы бл-ря IBM

Слышал, новый Dell имеет 624МГц проц от Интел? И весит меньше 150г.

> Идея унификации разрозненных по формату текстовых > конфигурационных файлов привела к появлению проекта Linux > Registry

Эээ, народ, не подскажете линк, где можно FreeBSD утянуть? :-)

> ткните меня в место, где написано

См. пункт 6.1 (True Facts About The Linux Registry), вторую строку в списке

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

>Если руки кривые, это не имеет значения.

А выключение питания во время операции записи/update?

А элементарные ошибки диска (например, посыпался)?

А...

Так, всёж, какие наборы частей этого механизма критически важны?

Короче говоря, вместо того чтобы нести тут всякий бред про XML, вы бы его поставили лучше... я вот сейчас посмотрел на этот самый реестр - так это просто дерево папок в /etc/registry, а все данные хранятся в обычных плоских файлах. Одна пара "ключ-значение" - один файл, сначала заголовок (похоже, по строке на атрибут), потом строка с "<DATA>", потом данные. Соответственно пермишены на ключ такие же, как на файл, в котором он хранится. Все.

> это просто дерево папок в /etc/registry, а все данные хранятся в обычных плоских файлах.

...а chroot, как обычно? Что с "зависимостями"?

Хе хе. Там написано вот что

> All key-value pairs are stored in clear-text files.

svu тебе расскажет, что в его понимании xml - тоже clear-text ;)

только где он метаданные хранить собирается?

Интересно было бы услышать, что думают разработчики пакетов, конфиги коих должны, якобы лежать в этом "чуде" 8). Сдается мне - не услышим ... 8)

Ооо! нашелся человек, который его поставил! Непохоже на лор.

И чего, прям-таки до жопы файлов? Беру свое предыдущее сообщение назад.

Ну тогда имхо для простых опций годится.

>вы бы его поставили лучше...

Неее братан ! Это не спортивно....:) новаторы-революционеры уже почувствовали вкус крови ;) Борьба пошла уже не между ЛР и ЛОР - борьба пошла между ХМЛ и FF. Таперича мочить будут друг друга непАдецки. Сейчас пройдутся по винде, затем друг друга начнут иметь бздуны и линухоиды, затем схлестнутся два девелопера на предмет абстрагировать/не абстрагировать.И этим все кончится....

А вот интересный вопрос - почему бы просто не сделать библиотеку, в которая будет подцеплять бакэнды, отвечающие за "ключи" в своем как-бы "разделе", типа libLinuxRegistry_passwd.so, экспортирующий функции openKey, closeKey, enumKeys, readValue, writeValue, valueExist... Ну и? кончено, commit и rollback, а на самом деле этот бакэнд будет просто править /etc/passwd.

Подцепляться он будет где-нибудь /etc/linuxregistry/backend строкой

\Sysconfig\Account: /usr/lib/libLinuxRegistry_passwd.so

И сможет SVU делать писать такой им желанный

context=lr_SessionStart();
lr_WriteValue(context,"\Syconfig\Account\root","password",&q uot;moysuperparol");
lr_Rollback(context);
lr_WriteValue(context,"\Syconfig\Account\root","password",&q uot;moynoviysuperparol");
lr_WriteValue(context,"\Syconfig\Account\root","gecos"," ;Eto systemniy administrator");
lr_Commit(context);
lr_SessionEnd(context);

И все довольны - у SVU есть программерский интерфейс, у саныча - текстовые конфигурашки :-) Ну и, понятно, создать набор простейших "параметрических" бакэндов, натравливаемых на любой файл подходящего формата, чтобы бедному SVU при написании программы можно было где-нибудь написать

\UserConfig\SVU-Software\YetOneLayoutSwitcher: /usr/lib/libLinuxRegistry_xml.so ~/.linuxregistry/newlayoutswitcher.xml
\UserConfig\SVU-Software\YetOneNextLayoutSwitcher: /usr/lib/libLinuxRegistry_xml.so ~/.linuxregistry/newlayoutswitcher2.xml

:-)

> Интересно было бы услышать, что думают разработчики пакетов, конфиги коих должны, якобы лежать в этом "чуде" 8). Сдается мне - не услышим ... 8)

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

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

> ...а chroot, как обычно?

Так это же было описание формата хранения файлов. Вообще-то предполагается что читать/писать это будут через API. А раз так, никто же не мешает написать демон, который это будет делать.

> Что с "зависимостями"?

Зависимостями между ключами? Не знаю... я пока еще не разобрался, что там за метаданные. Сначала похоже версия "реестра", а вот потом какая-то таинственная цифирка. Посмотрим.

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

>Идеалогия открытого ПО не настаивает на стандартизации. Но с одной стороны она вроде бы нужна. Здесь хотелось бы надеяться, что все неудачное со временем отправится в сорную корзину истории. Но не факт, не факт...

Имхо, как раз в открытом ПО это факт. Тут ведь не подиктуешь условия как пользователям некрософта - что дали, то и хавают. И пох - ИБМ там или ещё кто, никто не заставит СВОБОДНЫХ разработчиков ваять лабуду, по приказу дяди. Как захотят - так и сделают. И что-то мне подсказывает, что эта тема с реестром всё же не проконает. Думаю, подавляющее большинство коммьюнити будет против этой шняги.

Даже с чисто маркетинговой точки зрения это боольшая ошибка - назвать это чудо linux registry, это как mslinux - случись такое, никто из "закоренелых" пользователей линукса такой дистр не юзал бы, поскольку brand essence линукса - "не микрософт", и прочие "не"...

Мне лично сама мысль про линуксовый реестр просто дико неприятна, и те дистры, в которых подобное чудо появится я точно не буду юзать - хватит с меня еб###ни с приснопамятным regedit'ом, с дебильными ключами и путями длиной в километр, и с глюками этого монстра, когда что-то меняешь, а при следующей перезагрузке восстанавливается прежнее value, и чтоб разобраться надо читать 800 страничный талмуд, и нет гарантии, что это что-то даст... нах, нах, нах... пусть такое счастье нападёт на кого-то другого - а я буду привычно править vim'ом такие простые, понятные и прокомментированые текстовые конфиги.

> Ооо! нашелся человек, который его поставил! Непохоже на лор.

Для особо ленивых, там даже rpm'ка есть. На мою сузю встала на раз =)

> И чего, прям-таки до жопы файлов?

Да. Я запустил предлагаемый example-скрипт, конвертирующий fstab в этот самый реестр. Результат: каждая строчка fstab'а вылилась в каталог, в котором шесть файлов. Вот так:

>И все довольны - у SVU есть программерский интерфейс, у саныча - текстовые конфигурашки

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

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

linux:/etc/registry/system # ls -lR filesystems
filesystems:
total 0
drwxr-xr-x  13 root root 336 2004-06-03 05:58 .
drwxr-xr-x   4 root root 104 2004-06-03 05:58 ..
drwxr-xr-x   2 root root 192 2004-06-03 05:58 devpts
drwxr-xr-x   2 root root 192 2004-06-03 05:58 mediacdrecorder
drwxr-xr-x   2 root root 192 2004-06-03 05:58 mediadvd
drwxr-xr-x   2 root root 192 2004-06-03 05:58 mediafloppy
drwxr-xr-x   2 root root 192 2004-06-03 05:58 proc
drwxr-xr-x   2 root root 192 2004-06-03 05:58 procbususb
drwxr-xr-x   2 root root 192 2004-06-03 05:58 rootfs
drwxr-xr-x   2 root root 192 2004-06-03 05:58 swap
drwxr-xr-x   2 root root 192 2004-06-03 05:58 sys
drwxr-xr-x   2 root root 192 2004-06-03 05:58 windowsC
drwxr-xr-x   2 root root 192 2004-06-03 05:58 windowsE

filesystems/devpts:
total 24
drwxr-xr-x   2 root root 192 2004-06-03 05:58 .
drwxr-xr-x  13 root root 336 2004-06-03 05:58 ..
-rw-r--r--   1 root root  22 2004-06-03 05:58 device
-rw-r--r--   1 root root  17 2004-06-03 05:58 dumpfreq
-rw-r--r--   1 root root  24 2004-06-03 05:58 mpoint
-rw-r--r--   1 root root  31 2004-06-03 05:58 options
-rw-r--r--   1 root root  17 2004-06-03 05:58 passno
-rw-r--r--   1 root root  22 2004-06-03 05:58 type

...

>> ...а chroot, как обычно?

> Так это же было описание формата хранения файлов. Вообще-то предполагается что читать/писать это будут через API. А раз так, никто же не мешает написать демон, который это будет делать.

Возможно ли "подсунуть" демону некорректные данные из разных chroot, аля переполнение буфера и/или повышение полномочий?

Или предполагается запускать отдельные демоны для каждого изолированного процесса? Что у них будет общее? Возможны уязвимости?

вот тебе и пути длиною в километр.

имхо это лишнее, я в этом вопросе полностью солидарен с bsh.

ибо нефиг.

> угу и у обоих на херову тучу всего бакэндов метров на надцать

pavel@linux:/lib> ls -l libregistry.so

-rwxr-xr-x 1 root root 29772 2004-06-02 10:41 libregistry.so

pavel@linux:/lib> ldd libregistry.so

linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/libc.so.6 (0x4001d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

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

и вообще...

будет так продолжаться - перелезу нафиг на фрю.

а то писать 32-битные надстройки к 16-битным расширениям 8-битных интерфейсов - влом.

имхо конфиги в plain text отличаются именно удобством комментирования и редактирования.

это один из бооооольшущих плюсов юниксов над маздаем и макосью. и если он исчезнет в лине - тогда одним сторонником линя станет меньше.

Кстати если вы внимательно посмотрите на скриншоты в тексте статьи, то увидите, что это никакой не registry editor, а самый обычный конкверор, отображающий файлы в этом самом /etc/registry в виде дерева =)

> pavel@linux:/lib> ls -l libregistry.so

А теперь последний аргумент гыыыыы...

не не открытвым текстом... намекну только...

кто-нить знает WDFI File Alteration M....

Ну ну мужики ....

> имхо конфиги в plain text отличаются именно удобством комментирования и редактирования.

Как обстоят дела с удаленным редактирование конфигов? Каков объём передаваемых данных? Какие "сервисы" контролируют процесс?

жаль у меня сейчас нет установленного линукса, а то бы заценил.

но тогда придется делать разграничение по группам файлов, то есть делать отдельные каталоги для программ, что-то типа mplayer/mplayer.conf/и-тут-пошли ключи...

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

pavel@linux:/etc/registry>cat /etc/registry/system/sw/XFree/current/Module/Load

RG002 40 <DATA> dbe,extmod,fbdevhw,glx,record,freetype,type1,dri

Куда уж текстовей-то? =)

какие нафиг сервисы? :))

ssh в руки в вперед :))

а вообще моя фраза была больше от юзера, чем от админа.

> /etc/registry/system/sw/XFree/current/Module/Load

Каким "интуитивно-понятным" алгоритмом ты запонинал местонахождение нужной тебе информации?

> но тогда придется делать разграничение по группам файлов, то есть делать отдельные каталоги для программ

Так их и сейчас приходится делать =) Только нынче все извращаются как могут - кто конфиги прямо в /etc в один файл сваливает (mplayer), кто в отдельный каталог там же (XFree)... тут хотя бы это тандартизированно - системные настройки (fstab, inittab) в /system, софт - в /system/sw.

хм...

ну тогда хз...

BTW, что означают цифры? :))

хм... ну тогда не знаю :))

> Каким "интуитивно-понятным" алгоритмом ты запонинал местонахождение нужной тебе информации?

system/sw - там лежат настройки софта

current - текущий конфиг иксов (их можно делать несколько, на самом деле current это симлинк на один из них)

Module/Load - ну ты это, свой XF86Config (или xorg.conf) открой, что-ли =)

Имхо, здорово. Интересно, приживётся ли.. Стандартные интерфейсы это хорошо.

> ssh в руки в вперед :))

демон распарсивания на каждый ssh-коннект? Или один на всех?

(Не все ходят под root)

> Как обстоят дела с удаленным редактирование конфигов?

Пока никак. Это либа, а не демон. В любом случае, предполагаемое удаленное редактирование (да даже и чтение) конфигов будет надстройкой - то, что есть сейчас, должно быть достаточно маленьким и шустрым (и без лишних депов), чтобы его можно было использовать для системных конфигов типа hosts, fstab и inittab.

/etc/registry : каталог с настройками (вроде / в фс, только в отношении фс).

system: каталог с настройками всех программ.

sw: userspace софт.

XFree: ну тут все ясно.

current: версия

Module - секция конфига.

Load: параметр.

вроде все достаточно понятно, хз...

сколько шума из ничего. такое ощущение что спорящие с одной стороны не пишут программ, а с другой стороны не занимаются администрированием.
у меня в паре небольших проектов был большой гимор именно с конфигами. нужны были именно деревья, xml тогда был не настолько распространен, да и не использовал я его (как сейчас) и мне пришлось писать парсер. мать его так. не то чтобы сложно, а лениво очень. думаю svu подтвердит :)))
а сейчас админю понемногу. нельзя сказать что от меня убыло помнить про пять-десять форматов конфигов, но и большого удовольствия от этого тоже нет. httpd.conf, squid.conf, smb.conf, passwd, sendmail.cf, m4, netatalk.conf - можно и дальше продолжать. надоело. нужен стандарт. не обязательно xml, но пусть уж он будет един. и api, чтобы не изобретать велосипеды.

это не фронтэнд к чему-либо.

имхо это просто система упрощения конфигов...

а с юзерскими настройками должно быть проще - ставятся определенные пермишены на каждый файл, и таким образом решается, кто и что может редактировать. Еще ACL в руки, и вообще будет щастье.

А вообще - если не столь провокационное название - проект был бы встречен на ура.

Извиняюсь. Это должно быть так:

RG002
40
<DATA>
dbe,extmod,fbdevhw,glx,record,freetype,type1,dri 

Ещё раз:

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

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

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

-только в отношении фс +только в отношении настроек

пардон, опечатался.

не знаю, не ставил.

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

> а с юзерскими настройками должно быть проще - ставятся определенные пермишены на каждый файл, и таким образом решается, кто и что может редактировать. Еще ACL в руки, и вообще будет щастье.

Вот именно. Мне кстати понравилось как он разобрался с юзерами и группами. Пермишены стоят так, что, скажем, /system/users/root/home посмотреть может любой, а вот /system/users/root/shadowPassword - обломитесь =)

>- конфигами, читающимися через длиннючий пайплайн из всяких программ (не только m4)

>Ведь именно эти фичи и есть главная фишка unixway-подхода к конфигам. А ерархическа размудня - на хрен не нужна, тут уж лучше пойти ораклячьим путём и БД соорудить (обратно же - с правами доступа проблем не будет).

>Antichrist (*)

Урряааааа! Антихрист вернулся! Через пайплайн кто помешает к реестру обратиться? У него же наверняка будут методы удаленного RPC доступа (IBM постарается), про CORBA слышал?

> сколько шума из ничего. такое ощущение что спорящие с одной стороны не пишут программ, а с другой стороны не занимаются администрированием.

Я, например, не собираюсь ни с кем спорить: "Хочешь - не хочешь, счастье придет". Вот, что с ним потом делать, когда придёт оно...

P.S. Работать, как всегда, придётся "с данность" и мало кому есть дело до твоих "ощущений" по данному вопросу. :(

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

Никто. Нет здесь такого понятия - "валидные" ветки реестра. /system/sw отдается на откуп разработчикам, а уж как они там будут разбираться, это их проблемы. Хотя конечно возможно применение неймспейсов, скажем, по той же схеме, что в яве - т.е. например иксы пусть живут в /system/sw/org.xfree86 (или /system/sw/org.freedesktop.xserver) etc. Что скажете насчет такого варианта?

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

вообще на практике идея неплоха, повторюсь, если бы не такое название, то отношение к проекту было бы совсем другое. :))