> Имеем gettext для всяких языков, преобразующия "param" в приличную строку, возможно "param_description" в какой-то комментарий по этому поводу, и гую больше почти ничего не нужно.

Именно об этом я и говорил.

> унификация синтаксиса файлов "конфигурации"

Зачем? Это не требуется! В приведённом примере ...

netbios name {
param 'HOSTNAME' # Вот здесь и унифицируй!
name 'vfdf'
}

Остальное - лишнее.

Re:

Можно подумать, сейчас, если обсыпется ext2, то данные сами собой вернутся с электронных небес, мановением волшебной палочки доброй феи. "Встань и иди".

P.S. Да, у ext2 относительно простая структура хранения собственно данных. Но она же и относительно расточительная для таких вот случаев. Поэтому, нравицца-не нравицца, если эта штука пойдет в жизнь, то на / будут ставить reiser или тому подобную хрень. А уж если обсыпется, скажем, рейзер, то тут-то с огурчиком придется неслабо помучиться, растаскивая упакованные хвосты на части.

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

>>>что англоязычный снобизм (как и любой снобизм - униховый в т.ч.) - >>>это не очень красиво по-человечески и не очень продуктивно для >>>бизнеса (хотя мы MBA не получали:) А какая этому есть альтернатива? Берем самый свежий софт, переводим его на нац язык и дальше идем своим путем? Linux-RU_ru, Linux-UA_ua, JP_jp и т/д/

Re:

> Кривые пакеты - это _в основном_ кривые руки и таких пакетов без auto* было бы гораздо больше, вне зависимости от качества рук программиста. Под все системы install.sh не настроишь. А некоторых /usr/lib допустим в /usr/lalala/lib, под них тоже надо было бы настраивать install.sh?

На самом деле, autotools - это механический умножитель таких вот настроечных задач. Поэтому если автор blah-blah.m4 сделал какую-то глупость, то все, кто этим m4 пользуется, по полной программе огребают дерьма. А некоторые <beep> суют на кой-то хер этот blah-blah.m4 себе в m4/ и таким образом предотвращают попытки выправить кривизну blah-blah.m4 централизованно.

> whereis bla-bla не работает?

Как я понял, еще есть программисты которые пишут пакеты без auto* . Прямо как прозрел. Вопрос. Куда потом вы эти программы сдаете/ставите? Случаем, не для личного использования пишете? Как whereis найдет путь на системе где whereis нету?

> Удавил бы @#$%ров. Ну ЧЕМ он Вам помешал? Если юзер идиот -- то sawfish двигает окошки -- и баста. Если нет -- sawfish читает его мысли :)

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

> cd ~/bin; ln -s /usr/games/xbill xsvu

Вы мне льстите:)

Re:

> Там где был, там и остался.

У меня, начиная с версии где-то 1.0 есть неприятные глюки (в 0.37 было все нормально еще). Плюс, проблема с меню на последних версиях [GTK].

Re:

> cd ~/bin; ln -s /usr/games/xbill xsvu

> Вы мне льстите:)

Ну, да, в прошлый раз там был xhavoc, теперь вот и до вас добрались.

А софиш убрали из-за нескольких трудноустранимых (и медленно устраняемых багов). К тому же, Джон Харпер в то время не особенно сильно интересовался судьбой своего детища, возможно, от неприятия дивного нового мира имени ХИГ.

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

Кстати Dselect'у спасибо за то что обратил мое внимание на sawfish своим скрином "matrix has you" ;)

Супер wm.

> На самом деле, autotools - это механический умножитель таких вот настроечных задач. Поэтому если автор blah-blah.m4 сделал какую-то глупость, то все, кто этим m4 пользуется, по полной программе огребают дерьма. А некоторые <beep> суют на кой-то хер этот blah-blah.m4 себе в m4/ и таким образом предотвращают попытки выправить кривизну blah-blah.m4 централизованно.

Я не собираюсь развязывать флейм о auto. :) Эта ветка и так долго грузится. Аналогия _всегда_ неудачна :) И Вы нашли минус у аналогии а не у предмета дискуссии. Этой аналогией я хотел показать анологичные реформы которые произошли в прошлом, и что они решили многие проблемы.

Рубяты вы сходите туда и почитайте:

5. Why Linux/UNIX/*BSD Need a Registry

>А получили ... удобство, независимость от ОС и дистрибутива, не заботишься о поиске конфликтов или о нужной версии библиотеки или где она лежит, а make вообще классная фича, и используется везде где нужно сделать что-то подобное компиляции.
Товарищ явно не читал "Stop the autoconf insanity!" (http://freshmeat.net/articles/view/889/), иначе бы никогда не употреблял слово "удобство" рядом с "autoconf".

Открой для себя чтение длинных веток по страницам ;)

Re:

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

В смысле, метасити.

К скорости софиш у меня претензий нет.

Нет не читал, читаю :) А вообще см. мой пред пост :)

Re:

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

Поведение autotools механистично. Это и плюс - можно не _думать_ о тонкостях до тех пор пока нет проблем, а если проблемы появились, то раскручивать их за время, аппроксимруемое линейной функцией, - но это и минус, потому что нет ручной оптимизации и никто не гонится особо за производительностью, а кэширование результатов сканирования вообще иногда мешает жить.

Но я уверяю вас, сидеть за make --debug ничуть не менее утомительно, чем разглядывать config.log.

> На самом деле, конечно, аргументы из этой статьи, э-э-э, довольно дубовые.
Почитай на досуге комментарии к этой статье, те, что ниже. Там её обсосали со всех сторон. Вывод один - autoconf sucks.

Re:

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

Re:

... ну, конечно, когда день не проходит во флейме с svu о том, сосет ли гном, или не сосет :-).

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

вы что-то имеете против фон Неймановской модели? или сэр не знает что это такое?

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

это у мя глюки или тред действительно из Top10 вылетел? =)

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

>netbios name {
>param 'HOSTNAME' # Вот здесь и унифицируй!
>name 'vfdf'
>}

Ну, разговор о том, чтобы унифицировать значение символов "{}#;'"(в приведенном примере). То есть конфиг сети тоже должен быть такого типа:

device eth0 {
link {
options up arp
address xx:xx:xx:xx:xx:xx
mtu 1496
}
address 10.0.0.1/24 {
scope global
}
address 10.2.0.1/16 {
scope link
}
vlan 11 {
address 10.2.0.1/24
...

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

>Ууужаааас. А я FM от своего Пассата даже в глаза не видел. Вроде, мне его даже не дали при продаже... Наверное, я болван. И совсем не хочу учиться на шишках:). Я, конечно, перегибаю - но Вы сами спровоцировали своей максимой про "любое действие".

Не хочу хамить но наверно :). Вот такой гемморой предлагаете?

http://www.prokofiev.ru/prikol/pics/p10/b5-grm.htm

:)) Шутка хорошая. И у меня именно такой Пассат. И меня мало колебет его ГРМ - главное, что при его покупке мне с очень важным и значительным видом сообщили, что ремень уже поменян:). И я верю, что когда настанет время - периодический сервис поменяет его ышшо раз.

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

в реестре храняться конфиги, откуда большие объемы ?

Реестр это хорошая идея. Все от нее плюются, потому как микрософт ее хреново реализовал:
1. Бинарный формат, проблемы с доступом и бекапом
2. Огромное кол-во Недокументированных ключей
3. Невозможность вставлять комментарии.

В линуксовой версии эти недостатки отсутсвуют. А плюсов куча:
1. унификация конфигов
2. backup/restore отдельных веток, а не целых конфигов
3. поверх можно сделать удобное удаленное конфигурирование
итд
Так что линух только выйграет от этой затей.

> Так что линух только выйграет от этой затей.

Угумс, массовики-затейники, блн...

Конечно это шутка :)
Но давайте призадумаемся если вводить хоть какую то централизацию конфигов, то несомненно надо договариваться о том, что они лежат в /etc, а не раскиданы где кому как удобно!!!!
Для примера мне бло бы намного удобно что бы конфиги не хранились в моем /home/users , а лежали в /etc и только после этого говорить и создавть нечто подобное реестру!!!!
Ведь если конфиги будут лежать в одном месте, то возникает просто проблема написания междумордия для работы с ними.

Кстати я не знаю аглицкого :), но для меня это не помеха

офф злостный - Идею возникшую там наврядли угробят, но достаточно того что в России стандарт слотов расширения PCI хотя на всех платах есть и другие (забыл как их зовут), по цене одинаковые с PCI, но их хрен найдешь здесь - не везут :(

Кстати к моему Москвичу-2141 тоже никаких мануалов не шло прикупал в магазинах, однако там и так интуитивно-понятный интерфейс, только реализация страдает ну очень сильно :(

1. унификация конфигов

как?

2. backup/restore отдельных веток, а не целых конфигов

а сейчас?

3. поверх можно сделать удобное удаленное конфигурирование

как?

Реестр на XML'е??? Да вы рехнулись!!!

l-xoid (*) (03.06.2004 13:59:44)

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

"Но давайте призадумаемся": для чего создавали /etc /usr/etc /usr/local/etc ...

"где кому как удобно" что?

> Для примера мне бло бы намного удобно что бы конфиги не хранились в моем /home/users , а лежали в /etc и только после этого говорить и создавть нечто подобное реестру!!!!

т.е. дать пользователю право писать на системный раздел?

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

Ещё и проблемы с безопасностью.

P.S. КАК ВЫ СОБИРАЕТЕСЬ РЕШАТЬ ЭТИ ВОПРОСЫ ЭКСПЛУАТАЦИИ

int19h (*) (03.06.2004 1:34:06) >Да-да... работать исключительно в консоли - тоже "не такой уж >гемор", если подумать. Зато тру и элитно.

не знаю чем ты думаешь, а я просто работаю.

поверь, я работаю в консоли (иногда в Konsole) даже когда никто не видит ;-)

> Реестр на XML'е??? Да вы рехнулись!!! Доброе утро :)

Для новоприбывших - ТАМ НЕ XML

> Ну, разговор о том, чтобы унифицировать значение символов "{}#;'"(в приведенном примере). То есть конфиг сети тоже должен быть такого типа:

Да нет же! Это касается только вновь созданных файлов формата xx.aconf, то есть файлов содержащих гуёвые описания обычных xx.conf. Т.е. это некая надстройка, не меняющая основной сути.

> Тут же возникнут проблемы с поддержкой таких данных програмой поднятия сети - sh просто не умеет обрабатывать структурированые данные

То есть не возникнут! К файлам ifup-eth0 создаётся файл ifup-eth0.aconf в котором можно воротить всё что угодно! Главное чтобы сопоставление не потерялось.

> Для новоприбывших - ТАМ НЕ XML

Какая разница!!
Держите меня семеро!
:)

> "где кому как удобно" что?

/etc/ , /usr/local/etc/, еще есть /usr/share/mc (сам себе /etc) потом /usr/X11R6/lib/X11/*

> т.е. дать пользователю право писать на системный раздел?

у меня тож такое сомнение, но с другой стороны, или quote или отдельная fs все решат.

> Ещё и проблемы с безопасностью.

Проблемы? ну могут быть, н оне такие сильные как представляется и все что я придумал - решаются. А можно поподробнее? Может не все я придумал :)

> 1. унификация конфигов

А зачем это нужно? И как можно унифицировать delay-pool с os level?

> 2. backup/restore отдельных веток, а не целых конфигов

Это так часто требуется? Так кто ж мешает сохранить секцию файла, а не весь файл? Воспитание не позволяет?

> 3. поверх можно сделать удобное удаленное конфигурирование

Его и сейчас никто не мешает сделать!

ImHO идея построить все конфиги "в колонну по четыре" да еще с помощью "общего реестра" нежизнеспособна потому как:

1) идет в противоположную сторону от *NIX way (разбиение общей задачи на мелкие функционально-незваисимые подзадачи)

2) Поддержание _непротиворечивости_ такого "реестра" может стоить весьма дорого - одна ошибка в одном из многих конфигов имеет меньшие шансы "обрушитиь" систему нежели в предлагаемом монстре

3) *NIX-оид по своей природе консервативен (точнее ленив) не зря же в *NIX рулит API из аж ЧЕТЫРЕХ функций ;)

короче - посмотрим лет пяток, с большой долей вероятности (ImHO) все вернется к "etcfs" ;)

Ss, только честно, до какого места в треде дочитал а потом решился прокомментировать ? Дочитал до того как registry.tar.gz тестировали ?

что говорит Патрик?

про юзверский config

> Для примера мне бло бы намного удобно что бы конфиги не хранились в моем /home/users , а лежали в /etc

Та хотя бы вместо ~/.blahrc /home/users/.etc/blah/blah.conf ... Был на эту тему длиннючий flamewar в debian-devel, решили, что существующий зоопарк ~/.blahrc вряд ли удастся победить :((

Мдя, мельчает народец на лоре, определенно мельчает.

Уже > 700 постов, а даже не был поднят "еврейский вопрос", не говоря уж

про черные дыри или формализм рекурсивных функций Черча.

>Ss, только честно, до какого места в треде дочитал а потом решился прокомментировать

Тред я не читал вовсе - я читал http://registry.sourceforge.net/

Про нежизнеспособность - да, возможно. Вон, у мака народ дициплинированный, там этот номер прошел - да и унихового наследия у них реально не было. Для того, чтобы получилось под линухом - нужна договоренность и реальные действия нескольких самых больших игроков (Sun/IBM/RH/Novell/Suse?). Чтобы получилось под унихом вообще - в этот список надо добавить HP/SGI. А это все такие монстры... А их раскачать это такое дело...

> большой долей вероятности (ImHO) все вернется к "etcfs"

Я бы уточнил. Либо (возможно, даже скорее всего) просто никуда не уйдет, либо если уйдет - то уже не вернется:)

Что, разумеется, не мешает мне надеяться на лучшее:)))

>"Но давайте призадумаемся": для чего создавали /etc /usr/etc /usr/local/etc ...

И дальше что? Я собираю прогрмаму или ставлю из rpm а она мне конфиг швыряет /usr/etc ну и нахрена мне это надо? ну пропишу я ключи для зашвыривания его в /etc, а как быть с rpm?

> не мешает мне надеяться на лучшее:)))

Лучшее - враг хорошего! :-)

ps Ну дык что там начёт моей реализации? Серъёзных траблов вроде нет. И волки сыты и овци целы. :-)

>К файлам ifup-eth0 создаётся файл ifup-eth0.aconf

Образовалось непонимание:-(. Как я понял, .aconf - это конфиг програмы конфигурирования. Но эта программа должна знать синтаксис файла конфигурации, который она будет править. При разнообразии синтаксисов самих файлов конфигурации задача создания програмки управления всем становится нетривиальной.

Впрочем, беру назад свои слова об необходимости нового shell-а. При организации конфигов по типу subj-а старый добрый sh справится со всем.

>Для новоприбывших - ТАМ НЕ 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

Отсутствие атомарных ChangeSets и нотификации об изменениях - это серьезные траблы.

По поводу нотификаций. Если прога A поменяла ключик x.y.z - хочу, чтобы прога B была оповещена. Причем именно про этот ключик - а не про ветку x.y.