Вышла Samba 3.2

... а в воздухе всё сильнее веяло капцом

>>Samba может быть интегрирована с Windows Server, как основной контроллер домена

>А нафига тогда Windows Server?

А нафига тогда BMW когда есть опенсорсная инвалидка?

>> МС уже скоро похоронит ее, а эти только что то допиливают....лучше свое бы что нибудь придумали-неумехи.

> O_o ...чего МС похоронит?

Линупс каэшно!

> а от vfs модулей я реально протащился :) recycle рулит. Покажите как в виндоуз сервере восстановить файл снесенный юзером, без малоуспешного ковыряния NTFS сторонними тузлами?

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

PS Удачных тебе ковыряний ext3/reiser.

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

Ни кто не спорит.Но _иногда_ бывает очень _полезно_ видеть все N версий изменяемого документа, сохранённые за пол рабочего дня. Да - это костыль, который нужен очень редко, но и "много есть" он не просит. CVS и иже с ним не предлагать - не забывайте что речь не только о линуксе... ;)

>Зачем? Зачем нужны "текстовые файлы"?

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

Затем, что для текстовых файлов я могу сделать diff, а не тупо сравнивать 2 дерева глазами. Я могу разослать филиалам фрагменты текстовых файлов... Достаточно, нет? Хорошо - гораздо удобнее прочитать один текстовый файл сверху вниз в поисках параметра, чем скакать по дереву.

XML это текстовый формат. Конфиги JabberD вполне хороши.

Гном позволяет одной программе менять конфиги другой. Иначе как gconf-editor меняет настройки, скажем наутилуса, это разные программы, не так-ли?

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

>>Линупс каэшно!

Уважаемый, вам сюда --> www.linups.org.ru

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

Религия не позволяет создать 50 reg-файлов и выбрать нужный вариант конфигурации одним кликом?

> Если он изменит параметр он может комментариями окружить изменения и записать зачем и что он сделал.

в reg-файле можно сделать то же самое.

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

fc /u settings1.reg settings2.reg

> Я могу разослать филиалам фрагменты текстовых файлов...

Я могу разослать филиалам reg-файл с фрагментом настроек

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

Экспортируй и читай.

Недостаточно? Хорошо. Тебя СУБД mysql, postreg или oracle не напрягают тем, что данные хранятся в них в бинарном виде? Нет желания заменить на удобные текстовые файлы? Так вот реестр это тоже БАЗА ДАННЫХ со всеми её преимуществами - производительность, простота выборки и обновления данных без утомительных ползаний по километровым текстовым файлам и программам гораздо проще динамически переконфигурироваться(например удаленно или локально через mmc) если настройки хранятся в СУБД, а не в текстовом файлике, который надо распарсить, аккуратно вычленить нужные параметры, проигнорировать комментарии вписать туда новые значения и заменить файл конфигурации исправленным.

> Уважаемый, вам сюда --> www.linups.org.ru

ЛОР переезжает?

>Что "полноценного в AD" Вам не хватает в Самбе? >Вы можете прикрутить LDAP а от vfs модулей я реально протащился :) > recycle рулит. Покажите как в виндоуз сервере восстановить файл > снесенный юзером, без малоуспешного ковыряния NTFS сторонними тузлами? как и на самбе. shadow copy, только чтобы настроить это и там и здесь покурить маны придется.

//incing

>>ЛОР переезжает?

Для вас - да.

> Упомянутый XML, как раз, такой стандарт. Пихнуть его пытаются куда
> надо и куда не надо, куда можно и куда не можно. Это никак не KISS!

Вот именно, что XML - не KISS. Его неудобно редактированть вручную.
Даже противно порой.

> Зачем? Зачем нужны "текстовые файлы"? Ну, хочется редактировать
> вручную - пожалуйста, бэкэнд в виде vfs

Текстовые файлы в нескольких стандартных простых форматах, лежащие в
правильных местах - это как раз KISS. И стандартная библиотека для их
разбора - вот вам и стандартный API. Получается "просто использует
стандартный вызов для получения нужного параметра".
Если настройки свалить в одну хитрую нетекстовую кучу - то она будет
расти и превращаться в помойку так же, как виндовый реестр. И так же,
как и в виндовом реестре, будет очень непросто взять нужные настройки
с одного компьютера на другой просто копированием файлов в mc.

> Ну, почитайте про libelektra - там написано.

freshmeat:
0 projects found
No matches

SF.net >> Search
Searching projects gives 0 results

Это несерьёзный подход :-)

>> Затем,что в текстовых файлах я могу привести 50 примеров
>> конфигураций закомментировав их, а админ выберет один.
> Религия не позволяет создать 50 reg-файлов и выбрать нужный вариант
> конфигурации одним кликом?

А в текстовике-то это явно удобнее, если без кликов?

>> Если он изменит параметр он может комментариями окружить изменения
>> и записать зачем и что он сделал.
> в reg-файле можно сделать то же самое.

В бинарном файле?

>> Затем, что для текстовых файлов я могу сделать diff, а не тупо
>> сравнивать 2 дерева глазами.
> fc /u settings1.reg settings2.reg

Опять же - сначала переделывать в текстовые, затем сравнивать. Поэтому лучше сразу текстовый.

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

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

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

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

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

Про "хитрую нетекстовую кучу" разговор не идет. Разговор о хорошо документированной древовидной структуре. И при чем тут mc? А хотя бы и mc - плагин для хождения по реестру, по виду такая-же файловая система. В том числе и на удаленной машине. (в FAR такое есть) "Превращаться в помойку" - нет, не думаю (у каждой системы свои болезни).

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

Значит, с библиотекой согласны? Должна быть? Так, упомянутая мной libelektra - это оно и есть. А в чем там оно на самом деле хранится - решайте сами. Нравятся текстовые файлы - используйте их; не нравятся - пользуйтесь mysql, ldap или что-нибудь еще.

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

Виндореестр сначала был неплохой придумкой, но он а) позволяет любой программе срать куда угодно, а не только отведённую ей ветку и б) его структура плохо продумана или плохо документирована. Это усугубляется принципиальным отсутствием текстовых комментариев, которые в традиционных конфигах сильно облегчают жизнь. И отсутствием удобных редакторов (вообще, удобных редакторов для древовидных данных пока не придумали, даже для зумеля, чего уж там говорить о реестре). Вопщем хорошая идея превратилась в говно, как обычно это бывает у микросовта.

> Значит, с библиотекой согласны? Должна быть?

Да, с библиотекой согласен. Стандартный доступ к
конфигурационной информации должен быть.

> А в чем там оно на самом деле хранится -
> решайте сами. Нравятся текстовые файлы - используйте их;
> не нравятся - пользуйтесь mysql, ldap или что-нибудь еще.

Значит, с текстовыми файлами согласны? :-)
А вот mysql - имхо, слишком тяжёлое решение. Ведь достаточно текстовых
файлов. Не будет же grub читать своё меню с помощью mysql, верно?

> Виндореестр сначала был неплохой придумкой
Это была ужасная идея с самого начала. Как говорится, defective by design.

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

> его структура плохо продумана...
Она, похоже, складывалась исторически, и принцип KISS при этом не учитывался вообще.

> ...или плохо документирована
Но ведь ни я, ни вы никогда и не пытались найти фирменную документацию на реестр, так? :-)

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

> вообще, удобных редакторов для древовидных данных пока не придумали
А mc для файловой системы - чем не удобный редактор для древовидных данных?

>Значит, с текстовыми файлами согласны? :-)

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

Это как выбор mailbox/maildir/БД/..... Почта - она и есть почта. Где она лежит - кому как удобнее.

Для централизованного управления удобнее централизованное хранилище. Никто же не делает аутентификацию/авторизацию в сети путем регулярного обновления passwd/shadow на каждой рабочей станции (хотя технически возможно). Так же и с конфигами. Если нужно централизованное хранилище - удобнее хранить в чем-то отличном от.

В принципе, у нас уже есть централизованное хранилище - /etc + ~. Надеюсь, ~ заменится на ~/etc или хотя бы ~/.config.

>В принципе, у нас уже есть централизованное хранилище - /etc + ~.

Замечательно! Но это централизованное хранилище годится только для сети 127.0.0.0/8 :)

Нужно централизованное хранение настроек не одного компьютера, а нескольких сразу? Просто заменяем нужные файлы в /etc ссылками на файлы на подключенном сетевом диске. И на нём централизованно храним всё, что надо. Для приложений всё остаётся прозрачно.