Re:

Гхм? bonnie++?

Re:

squidfs?

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

> Об разнице и речь. Стандарт никудышный...

Давайте по пунктам: что в нем не так. Составим список и пошлем ребятам, которые это делают. Главное - грамотно и _убедительно_, а не в духе "это все ацтой патамучта мы все делаим не так и так не привыкли" (это не к вам, это к некоторым другим деятелям в форуме).

> Ну, извиняйте, что на литературном и без матюков...

Да нет, просто слишком расплывчато как-то... поконкретней бы.

> Все по закону Мерфи: если что-то может стать помойкой, то станет ей!

Вы знаете, глядя на нынешний /etc, я вынужден с этим согласиться. Но пусть тогда уж это будет хотя бы слегка организованная помойка =)

Re:

Офигенно полезный комментарий. Товарищ, Вы читать умеете? там выше по тексту уже и названия подходящих FS мелькали.

Re:

Я спрашивал уже: в чем правда, брат? Выигрыша никакого, один только геморрой с вложенными каталогами.

> Только лень, она умная должна быть...

Что-то я последнее время этого не встречаю. :-(

> восхищаюсь! Люди совершенно разучились мыслить абстракциями! Дожили!

Ладно. Я понимаю о чём идёт речь. Читай чуть выше моё предложение. Я ж не отказываюсь от наличия проблемы, просто предлагаю иное решение.

Re:

А если не админ - это преступление уже на лоре? :-)

P.S. Я не админ. И надеюсь, никогда не доживу до жизни такой :-)

> 1. Программер?

Да.

> 2. Как ты себе представляешь систему безопасности этого "реестра"?

Стандартные униховые права на файлы и каталоги. Плюс ACL, если нужен fine-tuning (что нынче предоставляют все современные ФС).

> 3. Как ты себе представляешь систему удалённого (по слабым каналам) изменения настроек?

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

> 4. Что нужно будет изменить в Linux для нормального функционирования "реестра"?

Для начала неплохо было бы заиметь соответствующие бэкенды к GConf и KConf. Потом туда же настройки базовой системы. Остальные подтянутся.

> 5. Какова будет система инициализации?

Инициализации чего?

> 6. Какова будет система доступа программ a la chroot (jail, etc) к "реестру"?

Хороший вопрос. Честно - не знаю, ибо не сталкивался толком (не админ я, а на десктопе оно мне не надо). Можете указать конкретные грабли, и возможные варианты их обхода?

Re:

Это реально зависит.

В некоторых местах, я бы и код хранил (и, на самом деле, храню). Там, где именно _объектно_-ориентированный (а не класс-ориентированный) подход, то есть, методы класса могут и не совпадать с методами его "прототипа" (в терминах JS)

Re:

Потому же есть (cond (...))

Вопрос был не ко мне, но я все же постеблюсь :)))) Настроение....

2. Как ты себе представляешь систему безопасности этого "реестра"? Система безопасности полетит ко всем чертям, особенно когда начнется реализация этого на живом софте... Представим, что Вася пупкин хранит ЛИЧНЫЕ настройки в /etc/system/users/pupkin/somesoft/someparameter/somevalue - АПИшная функция будет собирать глобальный конфиг включая настройки Пупкина, в следсвии чего Пупкин может какую угодно хрень толкнуть по сути дела в глобальный конфиг! Дойдет это дело до маразма вроде того что примитивнейший текстовый редактор будет перед запуском строить гиперсхему конфига чтоб не рухнуть, от неверного параметра, или еще чего доброго чтоб не свалится с рутовыми правами.

3. Как ты себе представляешь систему удалённого (по слабым каналам) изменения настроек? Будет вроде CVS ... Тока вместо патчиков на чайнах патчи будут на чайнах и с офигенно здоровыми скриптами.

4. Что нужно будет изменить в Linux для нормального функционирования "реестра"? Сделать из него Винды :))))

5. Какова будет система инициализации? Приблизительно как программа запуска в эксплуатацию термоядерного реактора

6. Какова будет система доступа программ a la chroot (jail, etc) к "реестру"? Напрашивается уних-сокет и далее как в п.4

7. и т.д. и т.п. епрст :))))

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

Re:

Ага. Обманывали детей, чтобы не пугать мерзостью жизни :-)

Re:

А причем здесь функциональщики. Питон, JS и (отчасти) перл - совсем даже не функциональные языки. Однако поди ж ты, такие фокусы на каждом шагу (особенно, в JS).

Re:

> 1. Программер? > 2. Как ты себе представляешь систему безопасности этого "реестра"? > 3. Как ты себе представляешь систему удалённого (по слабым каналам) изменения настроек? > 4. Что нужно будет изменить в Linux для нормального функционирования "реестра"? > 5. Какова будет система инициализации? > 6. Какова будет система доступа программ a la chroot (jail, etc) к "реестру"? > 7. и т.д. и т.п.

Да... Иногда лучше жевать чем говорить. Вы почитайте уже про то, как этот "реестр" устроен, потом будете задавать вопросы. Если они останутся.

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

с текстовыми конфигами затереть таким способом файл не менее просто

Админ ОБЯЗАН ВЛАДЕТЬ АНГГЛИЙСКИМ ЯЗЫКОМ ХОТЯ БЫ НА УРОВНЕ ШКОЛЬНОГО КУРСА (ДЛЯ НАЧАЛА) !!!

Не надо забывать, что бОльшая часть документации идет именно на англ. языке.

И если человек заявляет, что ему лень читать на буржуинском языке, то реакция в этом случае должна быть незамедлительной - (иди учи язык) или (иди ты ны на ***)

> Я догадываюсь что ВАМ нужно.

Ваша идея - уже намного лучше, чем просто "а пошел ты .. файлы парсить". Но есть проблемы:

1. При разнообразии форматов в /etc Вам придется придумать заковыристый формат конфигурации парсера (фактически это будет rule-based парсер). Или Вам придется использовать очень могучий AI для парсера.

2. При всем этом немного геморройно будет реализовывать СhangeSet - и нотификацию об изменениях (последнее - вообще невозможно без специальных ухищрений с бекапами и diff, поскольку vi /etc/samba/smb.conf сохранит ВЕСЬ файл - а Вы ведь предлагаете считать vi основным и легальным средством доступа к конфигурации).

>Давайте по пунктам: что в нем не так.

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

> глядя на нынешний /etc, я вынужден с этим согласитьсяНо пусть тогда уж это будет хотя бы слегка организованная помойка =)

Короче в каждой ОС - своя помойка, только /etc - неорганизованная, простая (текстовая), читабельная... А win.reg. - организованная, двоичная, глючная - еще один источник проблем...

>> Но увидеть resolv.conf или /etc/hosts в XML-формате

>/etc/hosts даже Microsoft поленилась в реестр засунуть. Или в XP уже засунула?

Естественно, резолвят они через рееестр.

AlexM (*) (03.06.2004 11:59:26)

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

А во что он превратится Вашими усилиями?

Re:

Вауч.

Вы программируете микроконтроллеры (на старых моторолах и x86)?

Как работает x86 процессор лично я _представлял_ себе где-то до 486 включительно. С появлением в пентиуме навороченной конвейеризации я перестал это представлять. Да, я знаю об уникумах, которые могут в голове соптимизировать код, который будет на P+ лучше кода, сгенеренного умеренно оптимизирующим компилятором. Но, чес-слово, таких людей среди моих знакомых очень немного.

Ну всё. П#$дец. <Shturman>

> Рассказывать, что такое рост по экспоненте? :-)

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

> Да, но зачем пихать это в КОНФИГИ?? э

1. В них можно собственно хранить текущую настройку. 2. В них можно хранить стратегии. Программа реализует принципы. А конфиг может хранить сценарии применения принципов: вариант для слепых, для глухих, для супер быстрых набиральщиков которые шифт успеют нажать раньше чем кнопку с буквой другой рукой и тд.

> Админ ОБЯЗАН ВЛАДЕТЬ АНГГЛИЙСКИМ ЯЗЫКОМ ХОТЯ БЫ НА УРОВНЕ ШКОЛЬНОГО КУРСА (ДЛЯ НАЧАЛА) !!!

Админ SOHO (если ВООБЩЕ такая вещь сушествует - потому как у SOHO обычно денег нет на выделенного админа) не обязан знать английский. Более того, в идеале, стандартная сеточка из пары компов для очень маленькой конторки (3-4 человека) должна подымать из коробки на полуавтомате путем прочтения _очень_короткого_ документа и ответа на небольшое количество очень простых и понятных вопросов. Это мечта. И винюки на сегодня к ней ближе, чем линух. И это плохо.

Да, есть практика шаренья админов между множеством контор - это тоже выход.

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

svu (*) (03.06.2004 12:10:01)

Пиши GUI - НЕ ЛЕЗЬ В СИСТЕМУ.

Re:

Моими - ни во что. Во всяком случае, пока. Я пока скептично отношусь к данной идее.

Но то, что там основная идея - разнесение ключей по отдельным _текстовым_ _файликам_ (документированной, к тому же, вполне пригодной для ручного редактирования структуры) - это я не поленился прочитать (а int19 даже примеры бросал, как оно выглядит "на самом деле"). И права на эти файлики - это обычные юниксовые права (ну, где есть - там _можно_ и файловые ACLи добавить, если надо).

Все вопросы _надежности_ - это вопросы файловой системы, на которой это все лежит. Равно как и вопросы оптимизации хранения данных (по моим ощущениям, NTFS - само то для такого вот скопища файликов :-)).

Собственно, и реальные проблемы этого подхода уже обсосали здесь не по одному разу (читать Луговского, н-р)

> Моими - ни во что. Во всяком случае, пока. Я пока скептично отношусь к данной идее.

По-подробнее?

> Все вопросы _надежности_ - это вопросы файловой системы, на которой это все лежит. Равно как и вопросы оптимизации хранения данных (по моим ощущениям, NTFS - само то для такого вот скопища файликов :-)).

Может, структурной организации информации?

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

И в результате?

> NTFS - само то для такого вот скопища файликов :-)).

На самом деле, это правда больной вопрос. Я бы не глядя согласился с идеей LR как скопища файликов и развесистого дерева каталогов (может, даже не произосил бы слова XML:) - если бы в унихе это не было несколько тяжеловесно. Только во всяких hurd/plan9 такая структура даст хорошую производительность (для меня ntfs/reiser под вопросом - не знаю, насколько скорость конкретной реализации справится покрыть общие тормоза на vfs уровне).

Re:

Блин, а подумать?

if has("gui_running") if has("XWindow") if has("TrueVim") smth=blah-blah else smth=bluh-bluh endif ....

и далее по тексту.

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

P.S. Я не специалист в vim'е, но пугать детей моим годами пестуемым init.el неохота, поэтому такой вот псевдокод в стиле vim.

я не программировал микроконтроллеры. курс электроники и микропроцессорной техники да пара ассемблеров своими силами. если вас пугают такие вещи как "предсказание переходов" и "спекулятивное выполнение" не говоря уж о "суперскалярная архитектура" - еще не значит что они непознаваемы. хотя конечно нормальные люди в голове схематехнику этих чудес держать не станут :)))
ps: а что, "И", "ИЛИ", "НЕ" по другому работают в процессорах, начиная с pentium? :*)

> И где сейчас этот Sawfish? Правильно, выкинут из гнома. СЛИШКОМ умен. Слишком наворотлив. Короче, overqualified:) И это правильно :Р На масс-десктопе наворотам не место - они пользователя пугают.

Вы удивитесь, у меня на десктопе sawfish, а гнома там нет ;)Хотя да, вы же на корпоративный сектор ориентируетесь.

svu, пиши GUI - НЕ ЛЕЗЬ В СИСТЕМУ.

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

Охренеть. В этом самая поганая часть винды. Чтобы завести групу пользователей, добавить в нее пару юзеров и дать ей права на определенный кааталог под виндами нужно зайти в 5 разных програм. В то время как в xNIX достаточно написать 20 слов в консоли.

подумай :)
конструкция if elsif else - не единственная. и в случае более 2-3 веток не самая удобная

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

Угу. И получите gconfd:)))

> В то время как в xNIX достаточно написать 20 слов в консоли.

Хотите я дам Вам скриптов, которые за 20 слов будут добавлять пользователей в консоли при том, что пользователи в LR? Только что там внутри этих скриптов - чур, не смотреть:)

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

У этой задачи вообще есть только 2 больных места: унификация синтаксиса файлов "конфигурации" и поддержка популярным в настоящее время "sh" сложных структур данных. И то и другое отсутствует. Обе проблемы решаются так:

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

Т.о. решаются все проблемы. Все что нужно - добавить shell-у возможность оперировать сложными данными и приличный синтаксис для этого дела. И переписать кучу скриптов:-)

Re:

svu: в конце концов, если уж совсем плохо будет, можно попробовать модифицировать библиотеку так, чтобы она реализовывала VFS внутри себя, а для любителей VI был отдельный VFS-модуль (м.б. user-land, благо нынче этим уже никого не удивишь в линухе, у меня (в кэптив) вон NTFS через юзерленд пишется читается - и ничего, особых тормозов не видно).

Остаются, конечно, вопросы синхронного доступа, но и это все обходится без проблем, на самом деле. Вообще, по ощущениям, BerkeleyDB или этот MySQL'евский InnoDB (c роу-локингом) вполне может быть использован в качестве основы для такой вот оптимизации.

Для API скорость обхода дерева не столь важна (т.к. требуется, в основном обращение к ключу по полному пути), а для "человека с миднайтом наперевес" вполне хватит и внешних индексов директориальных.

Re:

Извините, не Вы ли предложили

gui_backgound и text_background

для описания соответствующего свойства в различных режимах работы редактора. А теперь таки подумайте, сколько *_background'ов вам придется отплодить для случая, когда веток больше одной и они могут быть перемешаны произвольным образом.

Да, на всякий случай. То, что я привел - это _КОНФИГ_. К коду он не имеет никакого отношения (ну, за исключением того, что в vi есть код, который умеет парсить такий вот конструкции).

Re:

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

Re:

Воистину всякую систему можно ухудшать до бесконечности...

Лука Флеймищев.

про sawfish

> И где сейчас этот Sawfish?

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

> Правильно, выкинут из гнома.

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

P.S.

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

> кирпичиков большие системы.

Причем каждый кирпичик должен быть доступен, понятен, я так думаю, что на среднем сервере структура будет дай боже ! О понятности тут речи быть не может.

О! Батенька! Да вы тут противоречите себе.

Ничего подобного! Конфиг на то и конфиг - чтобы конфигурировать, а начерта АПИ котрое не знает что и где и как и после чтения конфига через АПИ еще их и распарсивать ? Неее такой не нада :) Я лучше по старинке из одного файла.

>Вы хоть раз писали серьезные программы...

Не-а :))) Строго хеловорд'ы :))) За что платят не пойму .....

> я сам не терплю таких выражений...

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

> Но есть проблемы:

Конечно есть. Они будут при любой реализации.

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

Не такой уж и заковыристый, да и зачем придумывать, ежели проще надрать нужный код из исходников. Зачем делать два раза одну работу.

> и нотификацию об изменениях

Нотиффикацию кого?

> поскольку vi /etc/samba/smb.conf сохранит ВЕСЬ файл - а Вы ведь предлагаете считать vi основным и легальным средством доступа к конфигурации).

А вы предлагаете пользоваться GUIетой и VIем ОДНОВРЕМЕННО? Что тут за трудности?

Re:

:-))

Ну, svu озаботился скоростью доступа, ну, я и предложил решеньице.

На самом деле, конечно, пока все массово не повалили на этот регистри, и ext2 вполне хватит :-)

> Остаются, конечно, вопросы синхронного доступа, но и это все обходится без проблем, на самом деле. Вообще, по ощущениям, BerkeleyDB или этот MySQL'евский InnoDB (c роу-локингом) вполне может быть использован в качестве основы для такой вот оптимизации.

Чур меня, чур !!! Упаси боже админить сервер с таким хранением настроек. Если что вдруг упадет, будете настройки из BerkeleyDB ручками выковыривать ? В сад, в сад !! Причем в детский.

Интерестно как же народ встречал automake, autoconf. Какой же там был флейм?
- Это Windows way доверять установку стороннему инсталятору
- Туда можно вставить трояны
- Писать и тем более учить как писать configure.in и Makefile.am труднее чем какой нить install.sh
- Работает медленее чем просто install.sh
- "Лишние" заморочки :)

А получили ... удобство, независимость от ОС и дистрибутива, не заботишься о поиске конфликтов или о нужной версии библиотеки или где она лежит, а make вообще классная фича, и используется везде где нужно сделать что-то подобное компиляции.

И теперь никто не жалуется, многие не ставит пакеты если там нет configure в котором можно указать что, где и куда. А комбинация
./configure && make && make install
уже стандарт де-факто, если не работает то кривой пакет :) Никто не жалуется и не говорит, что это "как в Виндах".

Такой инсталятор - это как бы необходимость, как и стандарт на /etc/ необязательно LR, но что-то надо.

ЗЫ А назвать пакет Registry ... это наверное для привлечекния внимания было сделано. Теперь ждем иск от МС что они раскручивают свой пакет на уже расскрученом слове :))))

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

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

Это камень в огород программастов, у которых мозг прекратил развитие годочков эдак в 12, а потому ничего сложне Ц они не могут понять.

> - тогда и будем о них речь вести. А пока давайте не отвлекаться на абстрактные теоретические построения =)

Значит axiom, maxima, yacas, Reduce, Mathematica, Maple мне только почудились?

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

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