LINUX.ORG.RU

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


0

1

Идея унификации разрозненных по формату текстовых конфигурационных файлов привела к появлению проекта Linux Registry - объединяющего конфигурационный параметры различных программ в одном хранилище (XML формат). Информация представлена в виде иерархического списка, для манипуляции параметрами предусмотрен простой API. На сайте можно найти набор патчей и конверторов для перевода некоторых программ под Linux Registry. (это сообщение взято целиком с www.opennet.ru)

>>> Подробности

anonymous

Проверено: svyatogor

Ответ на: комментарий от Dselect

> КАК Вы будете стандартизировать их содержание?

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

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

> Для особо одаренных повторю еще раз: в UNIX конфиги часто
> являются sexp'-ами ( грубо говоря, исполняются читающим их
> shell-script'-ом). КАК Вы будете стандартизировать их
> содержание?

для особо одаренных - если можно стоя на гамаке, то это не означает что так и нужно.

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

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

> Упрощение жизни разработчикам. Однако подходит ли для этого именно XML - большой вопрос.

О чём и речь. Уже выше было сказано, что бардак-то в головах... Несомненно порядок в /etc навести надо, но причём тут всякие реестры? Проблем это принесёи куда больше, чем решит. Кто достаточно и с умом порулил в /etc, тот поймёт.

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

>На самом деле очень странно они подходят к идее реестра ... Итак во первой черёд немаленькую часть конфигов из /etc/ читает сам libc напирмер резольвер, а также низкоуровневые утилиты типа mount отсюда мораль - перед тем как писать конфиги в xml в glibc должен появиться мало мальски юзабельный xml парсер а там как известно ваобще никакого нету .....

А вот и ответ на этот вопрос:

>It requires existing software to be changed to use its API. This will substitute hundreds of configuration-text-file parsing code, into clear Registry's API key-value access methods.

Неплохо, да? Зато "унификация конфигурирования" будет - на радость унификаторам-реформаторам.

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

>Почитай сцылку, там же написано, что название "Linux Registry" -

>только для маркетинга, и работать будет под разными юнихами.

>mikhail (*) (02.06.2004 17:10:10)

2Sun-ch: Прими к сведению! :)

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

> А зачем вносить изменения в XF86Config?

Ваше решение - внешнее относительно XF86Config. Мы говорили про решение только через этот файл, с его ..... форматом. А текущее решение почти такое же, как Вы предлагаете - только проще, через gconf (потому как парсить этот Ваш .mykbdmaprc мне тоже совершенно не сдалось).

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

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

Выполнимый код - это и есть данные. Между данными и кодом нет и не должно быть никакой разницы.

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

> RTFM? Он даже буковок таких не знает!

Ну мы ж не звери - расшифруем ;)

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

>Да оно нитак страшно, когда речь идет о fonts.conf k примеру. Но

>увидеть resolv.conf или /etc/hosts в XML-формате, что-то очень уж не хочется.

>ansi (*) (02.06.2004 17:12:24)

Страшный сон(?): busybox размером 8Mb

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

> Ваше решение - внешнее относительно XF86Config.

Зато работающее.

> Мы говорили про решение только через этот файл, с его ..... форматом.

Ну если хотите в гамаке и т.д.

> А текущее решение почти такое же, как Вы предлагаете - только проще, через gconf (потому как парсить этот Ваш .mykbdmaprc мне тоже совершенно не сдалось)

Отпарсить a=b не сильно сложнее, чем <a><value>b</value></a>. А вот прочитать значительно проще.

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

>> It requires existing software to be changed to use its API. This
>> will substitute hundreds of configuration-text-file parsing code,
>> into clear Registry's API key-value access methods.


> Неплохо, да? Зато "унификация конфигурирования" будет - на
> радость унификаторам-реформаторам.

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

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

> Между данными и кодом нет и не должно быть никакой разницы.

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

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

> всегда нужно отделять выполнимый код от данных.

Кто Вам такую чушь сказал?

> приведите пример скрипта где такое невозможно и я вам поверю

vi /etc/init.d/*

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

> Это общий случай. Называется модификация конфигурации при помощи специально предназначенного для этого ПО.

нет. все-таки это частный случай модификации довольно-таки кривоватого по формату XF86Config.

> Да Вы издеваетесь? Это массовый пользователь будет RTFM? Он даже буковок таких не знает!

да. издеваюсь. будет. если не оставить ему альтернатив.

> Но если такая простая вешь как добавление русской раскладки - требует RTFM - фтопку такую систему (точнее, путь живет - но пользоваться ей будут только geeks & nerds).

любое действие требует rtfm. если, конечно, человек - не болван и не хочет учиться на своих шишках.

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

> Можно я это где-нибудь запишу?

Пожалуйста.

> "Между интерфейсом и реализацией".

Кстати, да.

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

> > Между данными и кодом нет и не должно быть никакой разницы.

> Можно я это где-нибудь запишу?

Запишите. А лучше почитайте что-нибудь по функциональному программированию.

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

> Зато работающее.

Да пожалуйста.

> Ну если хотите в гамаке и т.д.

Вы не правильно поняли смысл обсуждаемого. Я высказал претензию к XF86Config. Народ не поверил. Я попросил решение, использующее XF86Config - решение нашлось, но помимо XF86Config. Это доказывает то, что формат XF86Config ПЛОХО ПОДХОДИТ для того, для чего он предназначен? Мне кажется - да.

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

> Отпарсить a=b не сильно сложнее, чем <a><value>b</value></a>. А вот прочитать значительно проще.

Я не хочу НИЧЕГО ПАРСИТЬ. Я не парсер пишу, а утилиту конфигурования XKB. Может быть, Вы мне посоветуете по inodes прогуляться в поисках файла? Я хочу иметь getConfigValue/setConfigValue - И ВСЕ!!! И, заметьте, не хочу морочить себе голову их реализаций. А если при этом я ДАРОМ получаю возможность отслеживать изменения в этих переменных (увы, LR про это, вроде, молчит - или я чего-то не заметил?), да еще редактор gconf-editor - совсем замечательно.

svu ★★★★★
()

Ну и кто хоть прочитал http://registry.sourceforge.net/??!?

XML? - там его нет вообще.
Backend для хранения ключей? - All key-value pairs are stored in
clear-text files.
Централизация? - тоже мимо!!! - Этот реестр ДЕЦЕНТРАЛИЗОВАН.
Daemon центральный - тоже облом, тоже нет.

Моё мнение, что это рулез!!! И это НЕОБХОДИМО. И это plus, в отличии от
например LSM(Linux Security Modules - доказательства на сайтах RSBAC
и grsec).

Поэтому перед тем как ОРАТЬ как орда полудурков - хотя бы прочитайте
оригинал. Те кто привык думать - пойдут и прочитают и поймут -
ЭТО НАДО и LinuxRegistry не плохой вариант для этого НАДО.
Те же из кричащих, кто начнут кричать, что сам дурак - мне сказать им
ничего, даже сочуствовать не буду.

UNIX WAY - это clear, simple, robust, а не то что думают любители мазо-
хисты.

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

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

Возможно.

> Я видел полки книжных магазов в Питере - совсем не так плохо...

Это одно, а ВЫ по этим книжкам решили ВСЕ проблемы при администрировании?

> Извините, не понял. Знание английского - требование к любому работнику?

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

> Без него диплом средней школы теперь не дают?

Что сейчас в средней школе творится я не в курсе, а раньше иностранный язык проходили, ещё и экзамен сдавали . В ВУЗе тоже.

> Я не знаю ни одного текстового конфигурационного файла с комментариями больше чем на одном языке (в 99% случаев - английском).

А что мешает его перевести? Причём тут перевод и реестр с XML?

> В gconf, где комментарии переводятся - очень большое количество комментариев реально переведено на русский

Но не все? А если не переведён нужный мне, то gconf ф топку? Маразм!

> Простых средств поменять его в конкретном месте из C программы нет.

Неужели?

> Реально нет публичного стабильного API по его чтению и записи.

У-у! А уж без API никак с текстовым файлом?

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

Не модульный. А оно надо?

> Конечно, брадатым админам с vi...

Я не тот. vi почти не юзаю...

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

> vi /etc/init.d/*

полная чушь. что именно там нельзя выделить отдельно в код отдельно в настройки ? заметьте что любое данное (даже промежуточное) может быть экспортировано вовне и впоследсвии импортировано.

во-вторых - кто вам сказал что эти скрипты тоже войдут в registry ? прочитайте наконец то что критикуете

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

да так, пара мелких производителей процов. да еще кое-кто (не буду показывать пальцем) хаял i386 на счет отсутствия PAX

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

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

Я не могу - не программист я. Без понятия, сложно это или тривиально. Но для того, чтобы понять, что менять _весь_ софт ради унификации конфигов (пусть даже это будут тривиальные изменения), при том, что сама необходимость такой унификации - ещё вопрос (зачем? и так всё отлично работает) - это, с точки зрения здравого смысла - абсурд, и для того, чтоб это понимать - программистом быть необязательно. Имхо.

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

что-то подобное есть на libpcm.sf.net

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

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

Этот частный случай становится общим как только форматы не стандартизованы. А httpd.conf удобно парсить программно? Есть стандартный API? Хотя бы либка такая в apache есть - чтобы к гуевинке прилинковать?

> будет. если не оставить ему альтернатив.

Альтернатива всегда будет. На сегодня это винюки и макос. И единственный способ вытащить массового пользователя оттуда - дать ему ОЧЕНЬ ПРОСТОЙ способ выполнять разные ПРОСТЫЕ действия, в частности, устанавливать раскладки.

> любое действие требует rtfm. если, конечно, человек - не болван и не хочет учиться на своих шишках.

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

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

Вот. А я уж подумал, тут одни безумные пионеры тусуются :-)

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

> заметьте что любое данное (даже промежуточное) может быть экспортировано вовне и впоследсвии импортировано.

А оно и так "экспортирвано вовне и впоследствии импортировано". Только с помощью ФС, а не какой-то лабуды.

> да так, пара мелких производителей процов. да еще кое-кто (не буду показывать пальцем) хаял i386 на счет отсутствия PAX

Слово, которое делает Ваше утверждение неверным -- "всегда".

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

> Ваши предложения по хранению и актуализации. А также по остлеживанию изменений, которые кто-то при помощи ... разумеется, ed, ручками внес в /etc/X11/XF86Config. Жду предложений с нетерпением.

А-а! Вот ты про что! Про "бардак" помнишь? Как раз про это!
И какие изменения надо отслеживать?

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

libc переписать тоже неплохая идея. Хотя бы потому, что там много чего нет, например, работы со строками нормальной, того же юникода, того же простого парсера xml. И это сейчас делается, даже если не учитывать dietlibc, насколько я знаю, в RedHat запущен проект по переписыванию libc и получается довольно приятная библиотека.

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

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

Бли-ин! Вы читали вообще о чем я говорил? Я кончно понимаю что есть красавцы, для которых кроме линукса и KDE в нем нет ничего. Но... Есть, были, будут системы, в которых по умолчанию нет средств редактирования xml. И простым редактором легче обойтись с простым текстовым конфигом чем с хмлем, уж сколько не втирайте мне про угловые скобки -- все равно "равно" понятнее.

А счастья все равно нет -- "настраиваться одинаковым образом" не будет, будет зоопарк написан на xml.

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

> Я не могу - не программист я. Без понятия, сложно это или
> тривиально. Но для того, чтобы понять, что менять _весь_
> софт ради унификации конфигов (пусть даже это будут
> тривиальные изменения), при том, что сама необходимость
> такой унификации - ещё вопрос (зачем? и так всё отлично
> работает) - это, с точки зрения здравого смысла - абсурд, и
> для того, чтоб это понимать - программистом быть
> необязательно. Имхо.

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

унификация конфигов - это следующий шаг после FHS

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

Ну и кто хоть прочитал http://registry.sourceforge.net/??!?

XML? - там его нет вообще.
Backend для хранения ключей? - All key-value pairs are stored in
clear-text files.
Централизация? - тоже мимо!!! - Этот реестр ДЕЦЕНТРАЛИЗОВАН.
Daemon центральный - тоже облом, тоже нет.

Моё мнение, что это рулез!!! И это НЕОБХОДИМО. И это plus, в отличии от
например LSM(Linux Security Modules - доказательства на сайтах RSBAC
и grsec).

Поэтому перед тем как ОРАТЬ как орда полудурков - хотя бы прочитайте
оригинал. Те кто привык думать - пойдут и прочитают и поймут -
ЭТО НАДО и LinuxRegistry не плохой вариант для этого НАДО.
Те же из кричащих, кто начнут кричать, что сам дурак - мне сказать им
ничего, даже сочуствовать не буду.

UNIX WAY - это clear, simple, robust, а не то что думают любители мазо-
хисты.

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

> А оно и так "экспортирвано вовне и впоследствии
> импортировано". Только с помощью ФС, а не какой-то лабуды.

ну что за тупость ? прочитай наконец текст по ссылке !

это "лабуда" полностью работает на ФС, никакого уровня абстракции не добавляется ! прочитай хоть цитату в треде

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

> Этот частный случай становится общим как только форматы не стандартизованы.

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

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

> А я FM от своего Пассата даже в глаза не видел

а вождению вас тоже никто не обучал? и пдд вы ни разу не читали? вот так прямо взяли и поехали?

ananas ★★★★★
()

>Причём тут перевод и реестр с XML?
А ты пробовал ЧИТАТЬ, что написано на сайте?

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

Сделал пост два раза, а то он утонул в дискуссии :)))
Народ не спорьте, сначала прочитайте по ссылке оригинал
и технические детали.

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

> Это одно, а ВЫ по этим книжкам решили ВСЕ проблемы при администрировании?

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

> Что сейчас в средней школе творится я не в курсе, а раньше иностранный язык проходили, ещё и экзамен сдавали . В ВУЗе тоже.

Знаю. Но английский обязательным не был.

> А что мешает его перевести? Причём тут перевод и реестр с XML?

Есть средство для i18n xml - называется intltool. Оно переводит транслируемые строки в удобный формат, совместимый с gettext - поэтому переводчики без проблем работают с этим материалом. В случае httpd.conf ничего такого нет. Да, это возможно (да пребудет с нами unix way) - но _никто_ этого не делает (возьму это "никто" обратно, если приведете мне пример двуязычного текстового конфига). Почему? Снобизм.

> Но не все? А если не переведён нужный мне, то gconf ф топку? Маразм!

У gconf есть механизм. Этот механизм используется и работает, эффективно работает. Вообще, будет ли такой механизм в LR - я не знаю. Но у httpd.conf этого механизма нет и не предвидится.

> У-у! А уж без API никак с текстовым файлом?

"Как". Но, я уже выше написал - Я НЕ ХОЧУ НИЧЕГО ПАРСИТЬ. Я не парсеры пишу, а утилиту конфигурирования. Почему необходимость в многоуровневых API нужно доказывать?

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

>Этот частный случай становится общим как только форматы не стандартизованы. А httpd.conf удобно парсить программно? Есть стандартный API? Хотя бы либка такая в apache есть - чтобы к гуевинке прилинковать?

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

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

anonymous
()

Linux Registry не пройдёт

По описанию система не так уж плоха, но всё равно она не пройдёт на unix.

Есть очень хорошее объяснение почему в unix всё именно так как мы имеем, а не иначе. Для каждой задачи нужна своя структура данных и абстракцию тут разводить бессмысленно. Да и <b>намного</b> удобнее редактировать /etc/passwd, httpd.conf, /etc/hosts, xorg.conf и все остальные текстовые конфиги, чем XML. Никакого смысла добавлять больше шелухи, чем полезной информации в конфиг файлы нет. Никто из тех, кто принимает решения не позволит, чтобы конфиги нельзя было без XML редактора или утилиты (rg) подправить и посмотреть.

А пользователям кто лишь кнопки мыши нажимает всё равно в каком формате что хранится.

KISS - keep it simple and stupid, unix way.

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

> Вообще, будет ли такой механизм в LR - я не знаю.

Посмотрел документ еще раз - вроде, не будет:

Key Comment

Pretty much as a configuration file comment. Not intended to be used in GUI applications, because it isn't internationalizable.

А жаль. Это они зря.

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

Вопрос к svu.

а исходные тексты Х`ов не содержат функций, позволяющих считывать настройки из родных конфигурационных файлов?

Или это не помогает? Ну а тогда есть ли реальная польза от открытого исходного кода даже для программера гуевых приложений?

P.S. Прошу не разводить флейма насчет моего сообщения

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

> Я высказал претензию к XF86Config. ... Это доказывает то, что формат XF86Config ПЛОХО ПОДХОДИТ для того, для чего он предназначен? Мне кажется - да.

Это доказывает, что у кого-то кривые руки.

> Я не хочу НИЧЕГО ПАРСИТЬ. Я не парсер пишу, ...

А ещё чего ты не хочешь? Я куею как народ обленился!

ps Нет бы выйти с предложением к девелоперам иксов, так нет же, изобретают КОСТЫЛИ!

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

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

Да. Ыменно. Почему вы ЛИШАЕТЕ возможности написать конфигурялку для Апача. Большую, красивую, раскудрявую, с мудрым хелпом, визардами и пр? Это некошерно? Настоящие парни должны закрыть апач от гуеписателей при помощи неменеджимого конфига? Кстати, tomcat вполне справляется жить с конфигурационным файлом на XML - и у него стандартная вебовская морда для конфигурения есть...

> а вождению вас тоже никто не обучал? и пдд вы ни разу не читали?

Первое не требовало rtfm. А второе было нужно не для вождения, а для сдачи на права. Так что вожу я безо всяких rtfm...

svu ★★★★★
()
Ответ на: Linux Registry не пройдёт от mihalych

>Да и <b>намного</b> удобнее редактировать /etc/passwd, httpd.conf, /etc/hosts, xorg.conf и все остальные текстовые конфиги, чем XML

я бы еще добавил, что каждая программа при этом имеет возможность развиваться свободно и самостоятельно, и не оглядываться на этот XML. ведь ла линуксе юникс не заканчивается :) есть еще много ОС :)

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

> это "лабуда" полностью работает на ФС,

Everything is file. (C) UNIX

> никакого уровня абстракции не добавляется !

А какой уровень абстракции добавит эта по@#$%на, если она нифига не разбирается в семантике того, что хранит? В чем отличие этой штуки от файла (ну, кроме того, что через ж*** его надо читать/писать)?

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

> а исходные тексты Х`ов не содержат функций, позволяющих считывать настройки из родных конфигурационных файлов?

Я смотрел. Это XFree-specific код, поэтому применять его я застремался (на сегодняшний день мой код почти server-agnostic - и я за это борюсь:). Кроме того, насколько я помню (это было давно), этот API не публичный (но точно не помню). И, главное, прочесть-то я смогу. А поменять ОДНУ-ДВЕ переменные и сохранить все обратно - такого кода (прямого и удобного) там точно нет.

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

Для конфигурялок - никакого:) Разве что уточнить смысл переменных конфигурации. Конечно, можно было закопипастить код - но я почему-то не захотел:)

svu ★★★★★
()

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

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

Что такое FHS - это случаем не Filesystem Hierarchy Standard?

Так это ж говно!!!

man hier у кого БСД, а FHS в топку!!!

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

Так напишите им в список рассылки свои предложения ;-) Пока что всё равно проект находится на ранней стадии и ничего не поздно поменять (в т.ч. и название). Мне кажется что разработчики ещё до конца не уверенны что именно требуется от подобной системы.

Вот, кстати, ещё один подобный проект: http://freedesktop.org/Standards/config-spec

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

> Почему вы ЛИШАЕТЕ возможности написать конфигурялку для Апача.

а тут уже парсер - первоочередная задача, а не второстепенная, как в вашем примере про gswitchit. и что вам мешает выдрать парсер конфига из кода апача?

> Первое не требовало rtfm. А второе было нужно не для вождения, а для сдачи на права. Так что вожу я безо всяких rtfm...

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

ananas ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.