LINUX.ORG.RU
Форум — Talks  

Реестр! Ы!


0

1

Шучу, не обязательно реестр...

Навеяно срачем не по теме в теме: http://www.linux.org.ru/forum/talks/5707291
«Пост гнева относительно /etc/бла-бла-бла.conf»

Почему когда речь заходит о конфигах и реестре, то oldschool'ные (а может и не oldschool'ные, а просто тролли) *nix'оиды посылают лечиться приверженцев реестра и других БД-образных конфигохранилищь?

То, что в винде реестр представляет собой неудобоваримое нечто еще не означает что нельзя сделать хорошо.
Обычно выдвигается аргумент типа «Текстовый конфиг можно править текстовым редактором».
А что бинарный нельзя? Можно сделать редактор который будет выглядеть как текстовый, будет маленьким и удобным, его без проблем можно будет использовать на том самом удаленном сервере, о котором так часто пишут oldschool'ные тролли.
Можно сделать текстовый интерфейс на уровне файловой системы (Например через FUSE или как часть ядра. Oldschool'ные тролли «Ааа... жуть... Реестр в ядре... Иди на семерочку!»). Пользователь сможет править конфиг как текст, программы будут работать через библиотеку, храниться может это все очень по-разному. Более того, можно будет сделать текстовый интерфейс с разным сиснтаксисом.

Какие я вижу плюсы:
- Равноправие текстового (или еще какого там)и графического конфигураторов. Если в этом, так называемом реестре, сделать схемы, то строить GUI можно будет быстро и просто, гораздо проще чем писать парсер конфига.
Хочешь GUI, а хочешь grep, sed и т.п.
- Легко связать со справкой даже для текстового интерфейса (см. пред пункт)
- Единый формат. Одни программы легко меняют конфиги других.

★★★★★
← Ноуты, плыншеты, субноуты
Конкурс от Nokia →
 ← 1 2 3 4 5 6

эпическая победа!
пойду напьюсь что ли и спать..

stevejobs ★★★★☆
()

Ааа... жуть... Реестр в ядре... Иди на семерочку!

nanonymous
()

Где-то читал, что AIX как раз и есть реестровая Unix/

Deleted
()

Щас придут красног^W наиболее почитаемые и уважаемые пользователи и объяснят почему твоя идея гав^W плоха и куда тебе следует перейти.

gopnick
()

Одни формат, один линукс, один столлман.

...

wfrr ★★☆
()

Ааа... жуть... Реестр в ядре... Иди на семерочку!

sin_a ★★★★★
()

С fuse неплохо придумано. etcfs, так сказать.

Yareg ★★★
()

> Почему когда речь заходит о конфигах и реестре, то oldschool'ные (а может и не oldschool'ные, а просто тролли) *nix'оиды посылают лечиться приверженцев реестра и других БД-образных конфигохранилищь?

Туда им и дорога. Каждая прога должна хранить (прозрачно) свой конфиг отдельно. Чтобы там не было никакого хлама и ничего лишнего, не касающегося проги. Каждая программа должна иметь возможность использовать _любой_ конфиг (он должен использоваться с ключом. например, -c). Автор треда либо использует дурную программу, либо не осилил прочитать /etc/rc.d/my-program-name

different_thing
()
Ответ на: комментарий от Yareg

>- Надо переписать всё, что уже написано
Это да... Но со временем можно.
Не думаю, что авторам программы веселее ковыряться со своим парсером.

ls-h ★★★★★
() автор топика

Желаю ТСу долгой и мучительной смерти, например, посредством терморектального криптоанализа...

Eddy_Em ☆☆☆☆☆
()

> А что бинарный нельзя?

Ещё и бинарный? Убей себя, а)

Единый формат. Одни программы легко меняют конфиги других.

Это ещё нафиг? Белкин коммент всё проясняет

different_thing
()
Ответ на: комментарий от different_thing

>Каждая программа должна иметь возможность использовать _любой_ конфиг
-c registry_branch_name
-c registry_exported_file_name

Каждая прога должна хранить (прозрачно) свой конфиг отдельно.

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

ls-h ★★★★★
() автор топика

>Одни программы легко меняют конфиги других.

Причём внезапно и самым неожиданным образом.

По теме: не нужно. Реестр содержать в порядке гораздо сложнее, чем каталог с текстовыми конфигами.

kranky ★★★★★
()
Ответ на: комментарий от ls-h

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

А что, библиотек нет? Я, правда, свою писал, но это я)

different_thing
()

Отличная идея. Опишите формат таблиц БД. Нужна также возможность добавления параметров в конфиг.

Tark ★★
()
Ответ на: комментарий от ls-h

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

different_thing
()

еще один срачь чтоли хочешь?

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

FollowTheRabbit ★
()

>в винде реестр представляет собой неудобоваримое нечто

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

тот тред не читал

wxw ★★★★★
()
Ответ на: комментарий от wxw

Ага. А тут есть просто файлы. Все прелести отдельного конфига можно реализовать и через реестр. Только зачем?

different_thing
()

Зачем что-то придумывать, если есть GSettings?

mono ★★★★★
()
Ответ на: комментарий от FollowTheRabbit

Советские чугунные велосипеды

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


... интересно, почему же все предпочитают ездить на новеньких Меридах с аллюминиевыми рамами?

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

> интересно, почему же все предпочитают ездить на новеньких Меридах с аллюминиевыми рамами?

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

FollowTheRabbit ★
()

>Можно сделать редактор который будет выглядеть как текстовый
велик для велика?
убейся!
посылаю тебе, ТС, лучики ненависти!

megabaks ★★★★
()
Ответ на: комментарий от stevejobs

>а в реестре можно раздавать права на разные ветки
Итого, когда конфиги хранятся в БД мы имеем:
- Отдельную систему для разделенения прав
- Собственно БД
- Необходимость использования сторонних утилит
- Необходимость настройки репликации для использования одного и того же конфига на нескольких машинах
- Мутную структуру БД(никто еще не сказал, как он будет пытаться хранить стопицот конфигов разного формата(с кусками древовидной структуры причем) в обычной таблице)

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

Tark ★★
()
Ответ на: комментарий от different_thing

если с файлами это встроено в ФС?

в фс встроена только работа с файлами, фс не занимается внутренней структурой. Да и с транзакциями и параллельностью проблемки. Да и со структурой проблемки, фс - это дерево. Всё бы ничего, если бы один файл = одна настройка. Тут кто-то упоминал Plan 9..

stevejobs ★★★★☆
()

и да - бинарные конфиги не нужны!
почему? подумай
и если уж и делать «реестр» то только в виде дерева конфигов - но чтобы конфиги остались на своих местах в своём истинном виде!

megabaks ★★★★
()
Ответ на: комментарий от stevejobs

Я про права, вообще то.

Да и с транзакциями и параллельностью проблемки. Да и со структурой проблемки, фс - это дерево. Всё бы ничего, если бы один файл = одна настройка. Тут кто-то упоминал Plan 9..

Иииии? Нафига там транзакции и параллельность?

different_thing
()
Ответ на: комментарий от stevejobs

>в фс встроена только работа с файлами, фс не занимается внутренней структурой. Да и с транзакциями и параллельностью проблемки. Да и со структурой проблемки, фс - это дерево. Всё бы ничего, если бы один файл = одна настройка. Тут кто-то упоминал Plan 9..
Проблему с параллельностью и транзакциями легко решает любая VCS. А насчет структуры, уж про БД можно не говорить.

Tark ★★
()
Ответ на: комментарий от Tark

> - Отдельную систему для разделенения прав

но можно использовать и встроенную, что виндно на примере реестра вендов. хотя нафиг оно нужно.

- Собственно БД


то есть «централизованное хранилище». замечательно!

- Необходимость использования сторонних утилит


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

- Необходимость настройки репликации для использования одного и того же конфига на нескольких машинах


не нужно ничего настраивать, всё искаропки. Даже в виндовом реестре можно любую ветку реестра сохранить в файл. Хотя я упорно не понимаю, почему обычный пользователь должен лезть в потроха системы, если он в ней ничерта не понимает. А понимаешь - так не ной.

Мутную структуру БД


структура БД пользователя никак не касается. Какую разработчик захочет, такая и будет

в обычной таблице


можно не одну таблицу использовать, а две, три или десять, лол. Если это поможет тебе навести порядок.

stevejobs ★★★★☆
()
Ответ на: комментарий от Tark

Проблему с параллельностью и транзакциями легко решает любая VCS.

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

stevejobs ★★★★☆
()
Ответ на: комментарий от different_thing

Иииии? Нафига там транзакции и параллельность?

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

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

>не нужно ничего настраивать, всё искаропки. Даже в виндовом реестре можно любую ветку реестра сохранить в файл. Хотя я упорно не понимаю, почему обычный пользователь должен лезть в потроха системы, если он в ней ничерта не понимает. А понимаешь - так не ной.
Я про то, что в облаке(даже облачке, из серверов 5-6) нужно на нескольких серверах иметь одинаковые параметры. И именно для этого нужна будет репликакция.

можно не одну таблицу использовать, а две, три или десять, лол. Если это поможет тебе навести порядок.

В том то и прикол, что для того же бинда не две, три или десять, а штук 100 нужно будет, если не больше.

Tark ★★
()
Ответ на: комментарий от stevejobs

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

На кой черт? Если программа гуёвая, а мне настроить в простом nano хочется?

не нужно ничего настраивать, всё искаропки. Даже в виндовом реестре можно любую ветку реестра сохранить в файл. Хотя я упорно не понимаю, почему обычный пользователь должен лезть в потроха системы, если он в ней ничерта не понимает. А понимаешь - так не ной.

Ну и ставь семерочку. Опять же - лишние сущности, искаропки они или нет.

структура БД пользователя никак не касается. Какую разработчик захочет, такая и будет

Какая?

---

Всё, спать я

different_thing
()
Ответ на: комментарий от Tark

>- Все операции и разделение прав изкаропки(предоставлено файловой системой)
Часть настроек одной программы разрешить менять только Васе, а остальные Васе и Пете...
На уровне файлов -> Файлов больше, они меньше -> Неэффективная БД (по сути ФС это и есть специфическая БД)

ls-h ★★★★★
() автор топика
Ответ на: комментарий от stevejobs

Например на каждую древовидную структуру нужна отдельная таблица кстати.

Tark ★★
()
Ответ на: комментарий от stevejobs

>Хотя я упорно не понимаю, почему обычный пользователь должен лезть в потроха системы, если он в ней ничерта не понимает. А понимаешь - так не ной.
и это говорит нытик неосиливший найти конфиги в своём дистре и люто бешенно плюсующий реестр
эталонное /0!!!
я обожаю ЛОР )

megabaks ★★★★
()

http://pastebin.com/QTig3Ev0
По ссылке маленький кусочек конфига apache. Кто предложит такую структуру БД, от которой не захочется вырвать себе глаза, тот может взять с полки пирожок.

Tark ★★
()

А зачем? Всё и так уже есть, легко и удобно... Нет смысла продить излишние сущности.

MiracleMan ★★★★★
()

Ух ты, какой зелёный ньюфаг. :)

А что бинарный нельзя?


Нельзя. По определению.

Можно сделать редактор который будет выглядеть как текстовый


И который у вас в критоический момент отвалится или будет доступ только по ftp, а на целевой платформе чудо-конфигуратора не будет.

Дальше мы устроим квест под названием «восстановление частично побитого конфига». Сколько вы восстановите из бинарного и сколько и текстового. И за какое время.

гораздо проще чем писать парсер конфига


Мне казалось, что готовых хватает.

Какие я вижу плюсы


Минусы таковы:

1. Сомнительная возможность править конфиг из другой программы.
2. Ухудшение юзабилити: Вместо грамотных настроек внутри программы пользователю будет навязан regedit++.

atrus ★★★★★
()

Набросок черновика концепта:
Имеются база данных, главный демон, библиотека-интерфейс, программа-конфигуратор и демон, использующий fuse. Программа-конфигуратор может иметь несколько бэкэндов (CLI, ncurses, GUI etc.)

Демон стартует при загрузке системы и делает unionfs поверх /etc. Демон предоставляет каталоги /etc/user и /etc/system, а также интерфейс совместимости, типа /etc/passwd. То есть при попытке поменять шелл по умолчанию пользователя $username в /etc/passwd демон будет менять запись в БД по адресу, к примеру, system/global/users/$username/shell. Соответственно, эту же информацию можно найти в файловой системе по адресу /etc/system/global/users/$username/shell.

Так же, я надеюсь, можно заставить демон при попытке открыть на изменение /etc/system/global/users вывести в некотором формате все подключи. Но тогда при некорректном изменении придётся отбрасывать все правки.

Каждая программа может/должна создать себе произвольный ключ в user/$USER/, а также, если программа запущена из-под суперпользователя в system/. В system/global/ хранятся стандартные ключи, которые можно читать и писать, но нельзя удалять или создавать.

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

Главный вопрос: какую БД лучше использовать?

Yareg ★★★
()
Ответ на: комментарий от Tark

> что в облаке ... из серверов ... нужна будет репликакция.

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

В том то и прикол, что для того же бинда не две, три или десять, а штук 100 нужно будет, если не больше.


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

stevejobs ★★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6
← Ноуты, плыншеты, субноуты
Talks
Конкурс от Nokia →