>Сдаётся мне, что циферки эти KRoN73 придумал сам. Уж больно они круглые.

Цифры по памяти, т.к. перезагружать GUI с кучей открытых окон для точного теста просто в лом. Более точные цифры, с точностью до секунды я на ЛОРе уже писал.

>Да и номера версий он указать не удосужился...

А Gentoo - не показатель? :) Естественно, Gnome 2.12, KDE 3.4.2

> Цифры по памяти, т.к. перезагружать GUI с кучей открытых окон для точного теста просто в лом. Более точные цифры, с точностью до секунды я на ЛОРе уже писал.

Время засекалось по секундомеру после ввода пароля в GDM? :)

> А Gentoo - не показатель? :) Естественно, Gnome 2.12, KDE 3.4.2

Не-а. Неизвестно, насколько регулярно ты его обновляешь.

440LX 233MHz 196MB ASPLinux

Старт тачки до логина xdm - 17-24 с
blackbox 0.70 - 1-3 с
xfce 4.2.2 + rox 2.2 - 6-10 c
gnome 2.8.1 - 15-22 c
kde 3.3.1 - 37-49 c

кеды - тормозное говно!

> сек
секса у физиков не было, попрошу писать без ошибок!

XML — в топку!

> Тогда оный xml будет парситься один раз, на стороне X server.

Господа GNOMEры, шли бы вы со своим зю-мэ-эль "ужасно далеко, куда
подалее, и лучше б, если раз и навсегда".

(взято из http://lkml.org/lkml/2005/10/2/77)

> Can somebody tell me why the Kernel-Development dont
> wanne have XML is being used in the Kernel??

I think it's mostly because the marketeers haven't got to everyone yet
:-) The kernel might be e-enabled, but it's not fully
iBuzzwordcompliant.

> А вообще, хорошо бы научить sysV init параллелиться. у меня паралеллился на федоре. вырубил кудзу и поставил в /etc/rc в соотв местах &

>Время засекалось по секундомеру после ввода пароля в GDM? :)

Именно так :) Собственно, я на Gnome -то в первый раз пересел прощупать его с KDE из-за его скорости загрузки :) После перехода с винды на Linux именно в KDE сидел пару месяцев. А теперь как загружу KDE - боже, как я в этом зоопарке работал-то?? :)

>> А Gentoo - не показатель? :) Естественно, Gnome 2.12, KDE 3.4.2 >Не-а. Неизвестно, насколько регулярно ты его обновляешь.

Ну, я думал, что Gentoo - это диагноз :D В общем, каждое утро обновляю. Часов в 7 утра esync делается, а часов в 9 я жму emerge -auvDN world, и если в списке желающем обновиться ничего криминального, подтверждаю и иду на работу :)

Поздно. xml уже в иксах. Уже на freedesktop.org. Удивлюсь сильно, если его совсем нет в KDE (наверняка есть или будет в KOffice). И победное его шествие по линуховому десктопу в самом разгаре (в ядре он, возможно, не нужен). Если гном не нравится - посмотрите на макос, там xml очень широко используется.

> Как это ни разу? А откуда он тогда в процессоре
> возьмется?
В процессоре? Ты оговорился, или и правда думаешь,
что файлы считываются в процессор?

> Один раз-то должен загрузиться :)
Но не целиком, и не сразу, а страницами (по 4К обычно)
и лишь по мере необходимости. В результате, конечно,
один раз всё равно будет считан, и, скорее всего,
полностью, но уже точно не 2 раза.
Впрочем, svu поправился, сказав, что проблема не в
самой загрузке файла, а в повторном парсинге xml.

>440LX 233MHz 196MB ASPLinux

Памяти себе докупи, дурень. И дистриб смени и тогда все у тебя загрузится быстрее.

24 секунды с xdm - охренеть.

>А теперь как загружу KDE - боже, как я в этом зоопарке работал-то?

Вот что с людьми делает отсутствие навыков минимизации.

Ты когда такие вещи говоришь, признаешь себя не слишком сообразительным и умелым человеком. Заметь.

> Именно так :) Собственно, я на Gnome -то в первый раз пересел прощупать его с KDE из-за его скорости загрузки :)

KDE грузился из GDM? Да, это диагноз. KRoN73, ты очень зря не рассмотрел в моих словах иронию. Я открытым текстом писал выше, что сравнение должно производиться ТОЛЬКО ПРИ СТАРТЕ ИЗ XDM, только в этом случае можно рассчитывать на какую-то объективность. Эх, KRoN73... Ты ещё сравни старт kedit и gedit из-под гнома.

> Ну, я думал, что Gentoo - это диагноз :D В общем, каждое утро обновляю. Часов в 7 утра esync делается, а часов в 9 я жму emerge -auvDN world, и если в списке желающем обновиться ничего криминального, подтверждаю и иду на работу :)

Но.... ЗАЧЕМ???? Неужели в жизни нет ничего более интересного????

> Поздно. xml уже в иксах. Уже на freedesktop.org.

Всё, пыонеры дорвались...

> Удивлюсь сильно, если его совсем нет в KDE (наверняка есть или будет в KOffice). И победное его шествие по линуховому десктопу в самом разгаре (в ядре он, возможно, не нужен). Если гном не нравится - посмотрите на макос, там xml очень широко используется.

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

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

Конечно, настоящие профессионалы не следуют за модой, а пишут на ассемблере PDP-11

> Не волнуйтесь, дети, MS придумает вам что-нибудь взамен

Вы бы хоть википедию почитали, МС довольно поздно "врубилась" в XML. Причем по понятным причинам

> Конечно, настоящие профессионалы не следуют за модой, а пишут на ассемблере PDP-11

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

> Вы бы хоть википедию почитали, МС довольно поздно "врубилась" в XML. Причем по понятным причинам

Ничего, она ещё наверстает. И будет диктоваит вам моду и тут. Как с .Net, Avalon и прочим. И дятлы ВСЕГДА будут только догонять :)

> Это как любая мода: сначала бурный рост, потом - загнивание и забвение. Не волнуйтесь, дети, MS придумает вам что-нибудь взамен

Интересно, линух уже пережил свой бурный рости или у него еще всё впереди ? :)

> выбирают из них самый адекватный.

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

> Тем они и отличаются от дятлов, которые узнали об xml и теперь бездумно пихают его везде, где его только можно пихнуть

Расскажите об этом дятлам в фирмах IBM/Sun/Apple/... Может, они Вам даже деньги заплатят за консультации по решениям, альтернативным XML.

> Потому что о других способах не знают и знать не хотят.

Уверены, что народ на freedesktop.org не знает ничего, кроме XML?

> Конечно, настоящие профессионалы не следуют за модой,

Да, таки не следуют.

> а пишут на ассемблере PDP-11

А GNOMEры как раз и есть такие чудаки, которые все пишут на угребишном
макроассемблере (a.k.a. C) такую громадину (что она абсолютно 
бесполезная -- это другой вопрос).

Причем такое ощущение, что пишут они как раз для тех *NIX'ов, что
работали на PDP, в лучшем случае -- VAX'ах.

> Поздно. xml уже в иксах.

В худшем случае -- поиграются и выкинут, в лучшем -- это ускорит смерть
живого трупа XFree86/Xorg.

> Если гном не нравится - посмотрите на макос,

А своей головой Вы когда-нибудь думаете?

> там xml очень широко используется.

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

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

Не может. Распространенность людоедства среди племени нумбу-юмбу ничего
не говорит о его (людоедства) адекватности.  
Очередной маркетологический бред.

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

А я и так вижу, что не нулевая: модной бывает только всякая дрянь.

> А своей головой Вы когда-нибудь думаете?

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

> На ошибках учатся, причем умные люди учатся на чужих ошибках.

Чтобы признать XML ошибкой, Вам придется сначала обосновать, чем его применение (например, в случае того же макос) является ошибочным - и предложить альтернативу, по возможности.

> Не может. Распространенность людоедства среди племени нумбу-юмбу ничего не говорит о его (людоедства) адекватности.

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

> Очередной маркетологический бред.

Маркетинг тут точно не при чем. Это уже менеджмент. Решение, основанное на стандарте, _дешевле_ нестандартного (по всему жизненному циклу продукта). Эта разница в цене часто (в большинстве случаев, я б сказал) окупает чисто технологические преимущества, предоставляемые нестандартным решением.

> А GNOMEры как раз и есть такие чудаки, которые все пишут на угребишном макроассемблере (a.k.a. C) такую громадину

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

> Причем такое ощущение, что пишут они как раз для тех *NIX'ов, что работали на PDP, в лучшем случае -- VAX'ах.

То-то сантехники в своей распоследней солярке стандартизовали гном...

> Золотые слова. Как только Вы поймете, что определение адекватности может включать в себя распространенность и "стандартность" технологии (причем с очень неплохим коэффициентом) - Вы увидите, что между модой и адекватностью корреляция ненулевая.

Чё, svu, дебила из себя строишь? А слабО вытекающую изо рта слюну тут изобразить?

Самый стандартный и распространённый формат - ТЕКСТОВЫЙ. Он же - самый простой и универсальный. Бинарный может быть быстрее, но он менее универсален: неудобен для человека. xml удобен для сложных структурированных данных, но парсинг его - тормозной. Отсюда - простой вывод, доступный любому дауну: если возможен и эффективен обычный текстовый формат, то используйте его! KISS, маму вашу!!! Что, лапки чешутся усложнить всё, что можно? Чешутся - идите лучше займитесь онанизмом ко всеобщей пользе: и плодить не будете таких же, как вы сами, и дерьмософт не преумножите.

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

А если нет? А если нужна структура? Ваять custom parsers?

> Самый стандартный и распространённый формат - ТЕКСТОВЫЙ

Самый распространенный формат - бинарный. Он компактнее, быстрее и проще в интерпретации программой, проще в проверке ошибок и граничных условий.

> Бинарный может быть быстрее, но он менее универсален: неудобен для человека.

Заменяем слова: "Бинарный" на "Текстовый" и "человека" на "программы". Кому конфиги нужны - человеку или программе ? Человек интерпретирует конфиг и работает в соответствии с ним или программа ?

Человеку нужно только одно - приемлемое для него представление конфига программы. В каком виде и где он хранится ему, мягко говоря, наплевать. Тебе ж всё равно, каким образом файловая система хранит твой текстовый конфиг ? А если это шифрованная ФС, скажешь, что конфиги так и хранятся открытым текстом в последовательных секторах ? Главное, чтобы в случае чего имелась возможность с ним работать.

> Заменяем слова: "Бинарный" на "Текстовый" и "человека" на "программы". Кому конфиги нужны - человеку или программе ? Человек интерпретирует конфиг и работает в соответствии с ним или программа ?

Человек иногда правит конфиг сам. Потому и придумали текстовые конфиги - чтоб человеку удобнее было их читать и править. Догоняем помаленьку?

> Самый распространенный формат - бинарный.

Формат конфигов??? Враки. Таки текстовый.

> Он компактнее, быстрее и проще в интерпретации программой, проще в проверке ошибок и граничных условий.

С этим - согласен.

> Человеку нужно только одно - приемлемое для него представление конфига программы.

Именно. И этого легко достичь при помощи текстового конфига. Для работы человека с ним не нужно наворачивать никаких дополнительных программ - достаточно обычного текстового редактора. Ещё раз повторяю: KISS!

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

Не наплевать, см. выше.

> Тебе ж всё равно, каким образом файловая система хранит твой текстовый конфиг ?

Негодная аналогия. Мне не приходится править ФС вручную. А конфиги иногда - да. Подручными средствами типа текстового редактора.

> Памяти себе докупи, дурень.

Мозгов себе докупи, дурень тупой, из памяти используется 50 метров, после загрузки тачки в xfce. 64 метров кэш у mplayer.

> И дистриб смени и тогда все у тебя загрузится быстрее.

Всё и так быстро, кроме тормозного КДЕ, который вроде как и не нужен.

> 24 секунды с xdm - охренеть.

Завидуешь? Спорим у тебя медленней на такой же тачке ;-)

RTFM, господа GNOMEры

> > если возможен и эффективен обычный текстовый формат, то используйте его
         
> А если нет? А если нужна структура? 

Тогда -- сначала RTFM вот здесь:

http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html

потом берете реализацию, какая Вам больше нравится:

http://community.schemewiki.org/?scheme-faq-standards

и вперед, с песней!

> Ваять custom parsers?

НЕТ! 

> http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html

Вам в XML что не нравится? Угловые скобочки? Так их можно и круглыми заменить и построить XML при помощи s-выражений. А вот где взять альтернативу infoset ?

Если в кране нет воды, а в бюджете — денег...

> > А GNOMEры как раз и есть такие чудаки, которые все пишут на
> > угребишном макроассемблере (a.k.a. C) такую громадину

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

Ой, не надо тут за процы песню заводить. Тот же LISP немного (~ 20%)
уступает в производительности C++, да и то -- только потому, что над
компилерами гораздо меньше людей работает, чем над gcc.

В конце концов, раз на всякие cairo процов хватает, то виноваты
не процы...

> существующая база пользователей,

А пользователям-то какая разница? Особенно целевой аудитории GNOME...

> разработчиков

Долбо%@ов, которым мозгов не хватает на что-то сложнее С, гнать в шею!

> делают это дело несколько проблематичным.

Лень, глупость и непомерно высокое самомнение пЫонеров a la Havoc это
делает проблематичным.

> Вам в XML что не нравится?

Попытка изобрести велосипед. Причем с квадратными колесами.

 <match target="font" >
  <test compare="less" name="size" >
   <double>11.0</double>
  </test>
  <edit name="antialias" >
   <bool>false</bool>
  </edit>
 </match>

А описания того, как такие программы должны себя вести, a la R5RS, нет.

> Угловые скобочки?

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

> Так их можно и круглыми заменить и построить XML при помощи
> s-выражений.

А на кой ляд он нужен, этот XML? Что он может сделать такое, чего
не могут s-expressions?

> А вот где взять альтернативу infoset ?

alist ? structure ?

> Тот же LISP

Вообще-то, конфликтует с #3. Разработчики LISP-а не знают, в массе своей. Спорить будете? Но главное даже не это. Главное в выборе C - легкость bindings к другим языкам. С сегодня - "наибольший общий делитель". Тут LISP сразу идет лесом.

> В конце концов, раз на всякие cairo процов хватает, то виноваты не процы...

cairo рассчитан на аппаратные ресурсы GPU, в первую очередь. Все-таки матчасть учить надо.

> А пользователям-то какая разница? Особенно целевой аудитории GNOME...

Пользователи не потерпят слишком медленного десктопа. Так что если managed среда окажется медленной - такой десктоп проиграет. Разумеется, можно ваять на упомянутом выше LISP (если вспомните на сайт www.gnome.org самых ранних времен - там обещали всяко пользовать schema) - но об этом выше.

> Долбо%@ов, которым мозгов не хватает на что-то сложнее С, гнать в шею!

Гнать никого из индустрии не будут. Она устроена не так, как Вам бы хотелось. Кстати, спасибо ей за это. "Живи сам, давай жить другим". Но и опять-таки - совсем не незнание LISP объясняет выбор С. Об этом многократно говорилось.

Вообще, может, не будем устраивать продолжение предыдущих мегафлеймов?;)

> Что он может сделать такое, чего не могут s-expressions?

infoset. Главное - семантика. s-выражения сами по себе пусты. Как пуст голый синтакс xml.

> alist ? structure ?

infoset несколько глубже, мне кажется.

> Человек иногда правит конфиг сам. Потому и придумали текстовые конфиги - чтоб человеку удобнее было их читать и править. Догоняем помаленьку?

Сам ? Это как ? Мысленно манипулирует магнитными полями на жестком диске ? "Догоняем помаленьку?"

> Формат конфигов??? Враки. Таки текстовый.

Угу. Расскажи об этом корелу, адобу, микрософту и прочим. Только не надо меня уверять, что они делают "проприетарное г...". Лучше докажи, что их продукты не самые распространенные :)

> Именно. И этого легко достичь при помощи текстового конфига.

Этого легко достичь с помощью структурированного представления :)

Ты ж наверное в курсе, что C/C++ имеют вполне конкретный синтаксис. Причем, текстовый. Хочешь, дам программу на C, разобраться в которой будет весьма занимательно ? Хотя казалось бы - чистый текст. Тем более, выполняет самое известное действие - "Hello world !" рисует :)

> Не наплевать, см. выше.

То есть, тебе не всё равно, на сколько секторов и в каком порядке разлегся файл конфига ? И формат файловой системы тоже имеет значение ? :)

> Мне не приходится править ФС вручную. А конфиги иногда - да.

Во-первых, при чем тут править ФС ? Во-вторых, а почему не приходится ? Не потому ли, что существует адекватный инструментарий ? Собственно, если для ФС инструментарий нужен, то почему он не нужен для конфигов ?

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

> Разработчики LISP-а не знают, в массе своей. 

И что? Вместо 50 дармоедов-Це-кодеров возьмут 2'х математиков...

> Главное в выборе C - легкость bindings к другим языкам.

Нет, просто некоторым тупоголовым *NIX'оидам лень сделать нормальный
CLR. 

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

Большинство пользователей предпочет стабильную софтину (пусть она даже
в 2 раза медленней работает), а не сырое глюкало a la GNOME. Причем
всякие там geeks -- не исключение. Не верите? Спросите на lkml, что
народ думает про gcc 4.x. 
А ждать 10 лет, пока Вы отладите свой супер-быстрый desktop, не будут
ни пользователи, ни конкуренты: и тем, и другим _плевать_ на 20%'й
проигрыш в производительности.

> Так что если managed среда окажется медленной

Вместо нее возьмут быструю :) Раз уж всякий embedded RT софт вполне
себе пристойно работает в managed среде (Oberon, к примеру), то для
desktop'а и подавно можно найти (или подхакать) подходящий runtime.

> - такой десктоп проиграет.

Нет. Пока Вы там будете баги фиксить, конкуренты успеют Вас вытеснить
раз 5. Не будете? Тогда вытеснят еще раньше... 

> Гнать никого из индустрии не будут.

конечно, никто не будет запрещать бесплатно работать, сколько влезет. :)

> Вообще, может, не будем устраивать продолжение предыдущих мегафлеймов?;)

Не будем. Поживем -- увидим, кто прав.

> > Именно. И этого легко достичь при помощи текстового конфига.

> > Этого легко достичь с помощью структурированного представления :)

Да, например, записав конфиг как программу.

> Ты ж наверное в курсе, что C/C++ имеют вполне конкретный синтаксис.
> Причем, текстовый. Хочешь, дам программу на C, разобраться в
> которой будет весьма занимательно ?

Ни один язык не защищает от тупости программиста.

> Во-вторых, а почему не приходится ? 

Потому, что ФС, которую приходится править, идет к такой-то матери
семимильными шагами.

> Не потому ли, что существует адекватный инструментарий ?

Нет. См. выше. Инструментарий-то есть, но он скорее "на случай ядерной
войны".

> Собственно, если для ФС инструментарий нужен,

Еще раз: запуск fsck -- это чрезвычайное происшествие. Правка
конфигов -- нет.

> то почему он не нужен для конфигов ?

Нужен. Текстовый редактор. Все остальное -- творчество душевнобольных,
изучают его психиатры, а не пользователи/админы.

> Вместо 50 дармоедов-Це-кодеров возьмут 2'х математиков...

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

> Ни один язык не защищает от тупости программиста.

Это не тупость. Это конкурсная работа, и таких много :)

> Потому, что ФС, которую приходится править, идет к такой-то матери семимильными шагами.

А почему того же нельзя сказать про конфиги ? Почему они прямо таки обязаны правиться без инструментария ?

> Инструментарий-то есть, но он скорее "на случай ядерной войны"

То есть, без необходимости в ФС не лезем, а когда она возникает - используем инструментарий. Почему такой подход неприменим к конфигам ? Зачем их постоянно править ?

> Нужен. Текстовый редактор.

Это не инструментарий. Это софт общего назначения. Как функции read/write для ФС - им всё равно что читать и писать, о содержимом заботится программа. Например, при работе с passwd, group и shadow админ использует специализированные инструменты. Почему ?

> > Потому, что ФС, которую приходится править, идет к такой-то матери
> > семимильными шагами.

> А почему того же нельзя сказать про конфиги ? 

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

> Почему они прямо таки обязаны правиться без инструментария ?

По определению. В конфигах содержатся вещи, которые пользватель (админ),
скорее всего захочет изменить, поэтому конфиги _обязаны_ быть 
human-readable, а уж как этого добиться  -- это задача программера.

> То есть, без необходимости в ФС не лезем,

Без необходимости вообще никуда не лезем.

> а когда она возникает - используем инструментарий.

Ага, ls, cat, echo, grep :)

_Настройка_ ФС осуществляется с помощью текстовых файлов. Тех,
которые в /proc/sys/fs. Пример:

$ ls -1 /proc/sys/fs/xfs/
age_buffer_centisecs
error_level
inherit_noatime
inherit_nodump
inherit_nosymlinks
inherit_sync
irix_sgid_inherit
irix_symlink_mode
panic_mask
refcache_purge
refcache_size
restrict_chown
rotorstep
stats_clear
xfsbufd_centisecs
xfssyncd_centisecs

И никаких бинарников, никакого XML.

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

> Почему такой подход неприменим к конфигам?

Во-первых, конфиги для того и созданы, чтоб менять поведение программы.
Если бы его не надо было менять, параметры просто были б hard-coded.

> Зачем их постоянно править ?

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

> Например, при работе с passwd, group и shadow админ использует
> специализированные инструменты. Почему ?

Исключительно ради автоматизации процесса. Никто Вам не мешает то же
самое сделать с помощью $EDITOR.

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

Вроде, договаривались же замять флейм? Или таки? Тогда укажу Вам на отсутствие логической связки. Если пользователь хочет поменять некие вещи - они не обязаны быть human-readable. Они должны быть human accessible - не более.

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

Касательно "human accessable" тут уже высказались :)

> _Настройка_ ФС осуществляется с помощью текстовых файлов. Тех, которые в /proc/sys/fs

Ну вообще-то это не файлы, хотя и представлены таковыми в файловой системе. Это есть ни что иное, как интерфейс к бинарному конфигу - ни больше ни меньше. То есть, своеобразный инструментарий управления параметрами ФС. Тот самый "human access", хотя и не самый удачный даже для текстового представления :)

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

И как это связано с вопросом ?

> Однако, еще раз подчеркиваю: изменение конфига -- штатная ситуация, он _именно для этого и создан_.

Это опять таки не говорит о необходимости именно текстового конфига.

> Исключительно ради автоматизации процесса. Никто Вам не мешает то же самое сделать с помощью $EDITOR.

Кроме лишних телодвижений - ничего не мешает. Удивительно другое - в этом вопросе лишние телодвижения народ смущали, а во многих других - нет. Я вижу только одно объяснение - лень и отсутствие интереса :)

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

> Если пользователь хочет поменять некие вещи - они не обязаны быть
> human-readable.

Обязаны.

> Они должны быть human accessible - не более.

Ага. Но если для этого нужно что-то, кроме $EDITOR -- в топку.

> Вроде, договаривались же замять флейм?

Да, таки лучше замять. 

> Касательно "human accessable" тут уже высказались :)

Не повторяйте чужие глупости.

> > _Настройка_ ФС осуществляется с помощью текстовых файлов. Тех, которые в /proc/sys/fs

> Ну вообще-то это не файлы, хотя и представлены таковыми в файловой системе.

Все, что представлено файлом в файловой системе и есть файл. :)

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

> И как это связано с вопросом ?

А так, что Вы до кучи мешаете настройку и восстановление (fsck).

> > Однако, еще раз подчеркиваю: изменение конфига -- штатная
> > ситуация, он _именно для этого и создан_.

> Это опять таки не говорит о необходимости именно текстового конфига.

Ну, красноглазые пущай с registry @$утся. А нам как-то текст поудобнее.

> Обязаны.

Кому?

> Ага. Но если для этого нужно что-то, кроме $EDITOR -- в топку.

На Вашем личном компе, разумеется. Не более того.

> Да, таки лучше замять.

Плохо получается:)

Завязываем с flame'ом!

$SUBJ

Sir yes sir!

> Ну, красноглазые пущай с registry @$утся. А нам как-то текст поудобнее.

В /dev/null такое мнение, нам, красноглазым, удобней с текстом.