> Потрясающе. И это, по-вашему, каким-то чудесным образом работает мимо winapi?

Естественно ни как. Только я в таких случаях предпочитаю использовать родное API. Чисто дело вкуса.

>В Си программе вы тоже просто наберете editor? :))))))

А при чём тут "C-программа"? alternatives не для C-программистов был придуман. К тому же - какой смысл писать программу, которая будет жёстко привязана к alternatives конкретного дистрибутива? А если алтернатива исчезнет? А если появится новая? Пеереписывать "C-программу"???

>Теперь жду аргументов от вас, если желаете продолжить диалог.

Каких аргументов? В пользу виндовз? Предъявляйте притензии к виндовз: - почему это она не поддерживает СТАНДРТ POSIX. Это вина стандарта? Феерично:)))

>Только тупая, и в силу этого жрущая ресурсов больше чем RDBMS.

Сам ты тупой:)))

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

Тебе так и не понять, что они криво и неэффективно отоборажаются на RDBMS. не понять потому, что кроме RDBMS ты НИХРЕНА не знаешь, неуч:)

>что доступ по индексам к необходимым банным осуществляется на порядки быстрее

Ты, придурок, конечно, не знаешь, что в ФС тоже есть индекс:)

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

Ты, придурок, конечно, не знаешь, что для доступа к РАЗНЫМ ФС - единый интерфейс, а к РАЗНЫМ RDBMS - разный:)

>что на компьютерах обычно всё равно имеется запущенный инстанс БД

С какого хрена?

>что в локалке находится более одного компьютера

И сколько компов у тебя "в локалке" дома? Oracle на выделенном сервере справляется?:)

>или несколько компьютеров объединяются в кластер, и ещё много разных "что".

Ты хоть бы про кластеры не упониман, ламер - ты их хоть в глаза видел?:)

>Только для хранения нетипизированных данных. А много ли таких?

Идиот... Срочно доктора к нему!

>Только я в таких случаях предпочитаю использовать родное API. Чисто дело вкуса.

т.е. вы хотите в линксе "родное виндовое апи... чисто дело вкуса"? Другие аргументы будут?:)

Скрипт versus конфиг

> Объясняю еще раз: скрипт - это описанный тем или иным образом алгоритм.

Ладно, возьмём за определение.

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

А это тоже алгоритм. Он присваивает переменной, заданной в программе, какое-то
значение. Причём переменная вполне может быть функцией. Тем не менее, возьмём
Ваше определение и разберём конкретный пример (ага, тот самый fonts.conf).

<match target="font" >
	 <test compare="less" name="size" >
		 <double>7.0</double>
	 </test>
	 <edit name="antialias" >
		 <bool>false</bool>
	 </edit>
	 <edit mode="assign" name="hintstyle">
		 <const>hintnone</const>
	 </edit>
</match>

Это что -- скрипт или конфиг? Судя по тому, что здесь таки описан алгоритм, это
скрипт. Согласны или как?

> #!/usr/bin/perl
> $a = 10;
> $b = 20;

> Ответ: какой скрипт не имеет логического смысла, т.к. не содержит в
> себе описания алгоритма.

1. А если его засунуть в зюмель -- смысл волшебным образом появится, 
   надо понимать?
2. Такого рода конфиги как раз являются частью описания алгоритма. Пример:

$ cat program.scm
#!/usr/bin/guile \
-l
#!
(define a 1)
(define b 20)
(load "user_settings.scm")

(define (foo x y) (+ (* x a) (* y b)))
(display (foo 1 2))

$ cat user_settings.scm
(set! a 10)
(set! b 20)

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

Д'Артаньян, перелогинься!

> MTA -- не моя предметная область. Для sendmail, видимо, никак. (Я и не утверждал, что такое разбиение всегда проходит). Вопрос sendmail -- нужна ли именно такая функциональность в одной программе.

Да-да, снова получили МегаАргумент "не нужно".

> Я обсуждал не переписывание существующих программ, а проектирование новых. Так вот, для новых дефолт -- неТП.

Скажешь, конфиги hal-а -- не программы? Может язык там и не тп, но это программа.

>> метаинформация, описывающая view и contorller. Например "password.enabled = (authorization.value == true)"

> ну мб. можно и её включать, но она должна быть факультативной, как и соотв. части API.

Её включать всё равно начнут, ибо в текущем виде конфиги устроят далеко не всех. И получат xul-ню.

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

Когда кажется, предлагается совершить культовый обряд.

> Проблема разделения прав на конфигурацию и пр. всё равно существует и лучше её решать единообразно.

http://standards.freedesktop.org/basedir-spec/latest/

>> Разумеется, если эвристика влияет на результат.

> Бывает и так. И ничего - годится для большинства случаев.

Зря про вонючие пули поскипал, они тут будут к месту.

>> Я знаю, что такого софта нет.

> Как же Вы, математик, живете?

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

> Будьте проще - смиритесь с миром, где практически весь софт good enough - и не более того.

Принципиальную разницу между "пользоваться" и "писать" good enough софт видишь? Мне лично за второе будет стыдно.

> Если совсем тупо, то я не знаю, что делать, если одну часть конфига некий юзер X имеет право редактировать, другую -- не имеет, а третью -- даже смотреть не может. Что, разбивать конфиг на 3 части?

Да. Посмотри в файлы ~/.profile, /etc/groups и /etc/shadow соответственно.

> К примеру, а строю последовательность из проксей, скажем для SOCKS. Порядок соединения должен быть таким: proxy1.some.host, proxy2.some.host, proxy3.some.host.

set proxiesList {proxy1.some.host proxy2.some.host proxy3.some.host}

Невероятно сложно(ц)

> а в программе (любой) вытаскивать его так-то так: String editor = uniConfig.getKey("/System/Alternatives/editor", UniTypes.STRING);

Опять надо всё переписать нах? Как уже достали эти революционно-комсомольские веяния...

> Просто держать конфиг в реляционной базе данных, дурашко. Это быстро, дёшево, надёжно, масштабируемо, реплицируемо и унифицируемо :-)

Нет, лучше хранить его в пхп-скриптах, ведь это Глобально И надёжно!

> Более того, если их повсеместно использовать, то к каждой программе нужно прикручивать интерпретатор скриптов. Perl, Python, Lua, Lisp, ... какой? Если я пишу маленькую программку с простой системой инициализации, то скрипты мне нужны как зайцу пятая нога.

Я прихожу к тебе по вечерам с нагретым утюгом и всю ночь изтязаю тебя за то, что ты в простой программе не используешь скрипты? :)

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

А зачем их формализовывать? Зачем!
?

> Даже в случае с ФС, можно накатать некоторый унифицированный API для доступа к настройкам. Причем изначально кроссплатформенный, не завязанный с точки зрения использующего его программиста на POSIX API.

Блин, ну вот что за желания построить всех под свой унифицированный формат? Прапорщиком служил? :)

> Принципиальную разницу между "пользоваться" и "писать" good enough софт видишь? Мне лично за второе будет стыдно.

Ты действительно математически проверяешь весь написанный тобой софт? Можно получить доказательство корректности кода tklor? Unit Tests (если есть) - не предлагать, они не являются мат. доказательством.

Насчет "стыдно" - это очень красиво звучит, но в условиях индустриального программирования важнее критерии "meet the deadline", "within a budget", etc - совершенно чуждые всякой этики. В кустарном опенсорце в свободное время(!) - да, можно позволять себе роскошь делать правильные вещи без оглядки на остальные параметры.

> Даже Microsoft не стала такого делать (а ведь опыта не занимать). Более того, что-то у них идет в текстовых конфигах, а что-то - правится напрямую в реестре.

> А почему?

Потому что даже реестр нормально сделать не осилили. А уж более сложное тем более.

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

Можно сделать стандарт, и все что поддерживает стандарт - можно штатно редактировать.

> Неужели годы работы в unix-системах тебя ничему не научили?

Единый формат хранения и общие библиотеки для обработки конфигов - это и есть Unix-way. Пока в /etc процветает велосипедо-Windows-way.

> Ты действительно математически проверяешь весь написанный тобой софт?

Да, я всегда уверен в том, что реализую алгоритм, дающий правильны ответ. Конечно, не факт, что написанный код будет лишён ошибок и будет соответствовать алгоритму.

Например, я не позволяю делать себе good enough код, который гарантированно валится в некоторых случаях, как, например, авторы 7z, info-zip или krusader-krarc (http://www.linux.org.ru/view-message.jsp?msgid=2887807). Вот мне моя натура не позволяет писать такую хню.

> Можно получить доказательство корректности кода tklor?

Я уже говорил, что задача о корректности алгоритма неразрешима.

> Насчет "стыдно" - это очень красиво звучит, но в условиях индустриального программирования важнее критерии "meet the deadline", "within a budget", etc - совершенно чуждые всякой этики.

Знаю. Но мы тут не о индусопрограммировании говорим, а вроде как об опенсорсе.

> В кустарном опенсорце в свободное время(!) - да, можно позволять себе роскошь делать правильные вещи без оглядки на остальные параметры.

Конечно, при постоянном переписывании всего нах никакого свободного времени на правильные вещи не останется.

>Достаточно. Вместо того, чтобы "гранулировать" конфиги, ты прдлагаешь объединить их в кучу, а потом придумывать "механизмы гранулирования" этой кучи? Led *** (*) (23.07.2008 2:17:02)

О боже. Опять... Еще раз - покажи пальцем кто и где хотел Объеденить все конфиги в один? Ту тебе пример приводили - у тебе на компьютере один диск? CD нету? DVD? Флэшки не втыкаешь? Или всетаки бывает?

Так вот на данный момент существующая реализация это набор дисков A: B: D: C: и так далее??? Нравится? Мне не нравится - мне mount очень нравится - а тебе нет.

>>Альтернативой было бы порезать конфиги на кусочки, соответствующие одному уровню прав. Мне кажется, излишняя нагрузка на FS и на человеческий мозг.

>Это вам кажется.

>Led *** (*) (23.07.2008 2:22:55)

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

> Да-да, снова получили МегаАргумент "не нужно".

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

> Скажешь, конфиги hal-а -- не программы? Может язык там и не тп, но это программа.

Как это противоречит тому, что я говорю? Кстати, чисто декларативные программы вполне без извратов отображаются на конфиги (см fontconfig).

> в текущем виде конфиги устроят далеко не всех. И получат xul-ню.

Ну MVC-конфиги необходимо выродятся именно в XUL. Вопрос, как обычно, зачем в конфиги пихать столь нетривиальную логику. Для многих и "plain XML" хватит (см. выше).

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

>> Проблема разделения прав на конфигурацию и пр. всё равно существует и лучше её решать единообразно.

> http://standards.freedesktop.org/basedir-spec/latest/

> Посмотри в файлы ~/.profile, /etc/groups и /etc/shadow соответственно.

Такой подход плохо апскейлится, увы.

> а вроде как об опенсорсе.

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

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

Он и так есть: stat(), open(), read(), write()

> Причем изначально кроссплатформенный, не завязанный с точки зрения использующего его программиста на POSIX API.

1. POSIX и есть кросс-платформенный API, а кто его не поддерживает -- сам себе злобный буратино.

2. Изобретая новый API, вы не достигните кросс-платформенности, а совсем наоборот. Появится (если Ваше поделие приживётся) ещё один API, не совместимый с существующеми.

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

То есть разрешаешь-таки пользоваться скриптовыми конфигами там, "где нужно". Отлично. А вот злые ирландцы хотят запретить :)

> Как это противоречит тому, что я говорю? Кстати, чисто декларативные программы вполне без извратов отображаются на конфиги (см fontconfig).

То есть конфиг на декларативном тьюринг-полном xslt ты тоже принимаешь?

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

Чтобы получить фетиши гика: валидацию, редактирование из gconf-editor. И не надо говорить про "хорошую" и "плохую" валидацию.

> Для многих и "plain XML" хватит (см. выше).

Для многих и key=value хватит.

Опаньки, на ловца и зверь бежит...

> Кстати, чисто декларативные программы вполне без извратов отображаются 
на конфиги (см fontconfig).

О, раз Вы fontconfig упомянули, может Вы таки ответите -- вот это

 <match target="font" >
	 <test compare="less" name="size" >
		 <double>7.0</double>
	 </test>
	 <edit name="antialias" >
		 <bool>false</bool>
	 </edit>
	 <edit mode="assign" name="hintstyle">
		 <const>hintnone</const>
	 </edit>
 </match>

скрипт или конфиг? И если такое представление -- не изврат, то что же
тогда изврат? (страшно подумать даже...)

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

А если я (админ) хочу запретить данному пользователю менять данную настройку
данной софтины? Прикажете её патчить? Даже в говнореестре -- и то додумались
ACL'и прикрутить...

>> а вроде как об опенсорсе.

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

И что, прогибаться теперь под них? Пусть красношляп, межделмаш и прочие сколько угодно пишут конфиги в xml. Для своих программ. А на прочие пусть шупальца не тянут. Это логично.

> То есть разрешаешь-таки пользоваться скриптовыми конфигами там, "где нужно". Отлично. А вот злые ирландцы хотят запретить :)

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

Если svu скажет, что надо загнать в XML .vimrc и питоновские модули -- я окончательно утрачу веру в человеческий разум :)

> То есть конфиг на декларативном тьюринг-полном xslt ты тоже принимаешь?

Декларативность условие необходимое, но не достаточное. Боюсь, что семантика xslt не сведется к условному дереву триплетов. Хотя запихать можно.

Про fontconfig ниже отвечу.

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

>Чтобы получить фетиши гика: валидацию, редактирование из gconf-editor. И не надо говорить про "хорошую" и "плохую" валидацию.

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

>> Для многих и "plain XML" хватит (см. выше).

>Для многих и key=value хватит.

Не забываем про типы и унифицированный парсер. Особенно если value -- произвольный набор символов, с переводами строк и пр. внутри :)

> Для своих программ. А на прочие пусть шупальца не тянут. Это логично.

Что такое "свои программы" в опенсорце? При том, сколько бабла эти компании вкладывают ядро, иксы, серверные приложения и пр. и пр.? Они индустриализуют все, что им нужно для бизнеса. Это нормально.

Про fontconfig -- пограничный случай.

Т.е. да, в XML запихивается и не выглядит совершенной дичью (потому что действия шаблонны -- сравнить поле и выполнить какие-то действия в случае, если...). Но можно было бы и воспользоваться чем-нибудь встраиваемым. Хотя тут проблема будет обратная -- нужно будет урезать семантику. Я, например, не понимаю. с какой радости fc делать произвольно расширяемым хотя бы на уровне SIOD. Не тот масштаб.

> А если я (админ) хочу запретить данному пользователю менять данную настройку данной софтины? Прикажете её патчить? Даже в говнореестре -- и то додумались ACL'и прикрутить...

Многие -- не значит все. Дык о том и речь, что если разделение прав внутри конфига нужно, надо либо размазывать настройки по FS, либо вводить механизмы а-ля реестр с ACL.

>> То есть конфиг на декларативном тьюринг-полном xslt ты тоже принимаешь?

> Декларативность условие необходимое, но не достаточное. Боюсь, что семантика xslt не сведется к условному дереву триплетов. Хотя запихать можно.

Пустой набор слов. Ответь "да" или "нет" тому, будет ли xslt хорошим форматом. Для него даже схема есть.

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

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

> Не забываем про типы и унифицированный парсер. Особенно если value -- произвольный набор символов, с переводами строк и пр. внутри :)

И что? xml с бардаком схем выдаст ровно то же самое.

> Что такое "свои программы" в опенсорце? При том, сколько бабла эти компании вкладывают ядро, иксы, серверные приложения и пр. и пр.? Они индустриализуют все, что им нужно для бизнеса. Это нормально.

В итоге, в погоне за прибылью, они то, вот что "вкладываются", загубят. Это так, карканье.

> Это так, карканье.

По звуку больше похоже на брюзжание;)

>> Это так, карканье.

> По звуку больше похоже на брюзжание;)

Я старая брюзжащая ворона :)

//последовать что ли примеру выфера и поставить ворону на аватару? :)

> //последовать что ли примеру выфера и поставить ворону на аватару? :)

- Алло, это Зоопарк?

- Нет, это ЛОР!

XSLT не является конфигом в моем смысле. Ибо хотя и сводится формально к дереву триплетов, но семантически его сильно перекрывает. Если программе нужен скриптинг на XSLT, пожалуйста. Только это не конфиги.

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

Степень логической связанности ты преувеличиваешь. К тому же схема -- неотъемлемая часть программы.

Кстати, когда отрываешь программную логику и помещаешь её в "ТП-конфиг", еще дальше держишь логически связанные вещи.

>> Не забываем про типы и унифицированный парсер. Особенно если value -- произвольный набор символов, с переводами строк и пр. внутри :)

> И что? xml с бардаком схем выдаст ровно то же самое.

Одна схема на конфиг. Зато единый стандартный парсер, единое API доступа, возможность объединять конфиги с одним форматом и прочие вкусности. О них уже писали предыдущие 19 страниц :)

В общем, я думаю, мы поняли позиции друг друга. Дальнейший спор будет повторением аргументов и я не считаю его продуктивным. Сорри, надо работать.

> К тому же схема -- неотъемлемая часть программы.

Потому её и надо держать в программе, а не абы где.

>> И что? xml с бардаком схем выдаст ровно то же самое.

> Одна схема на конфиг. Зато единый стандартный парсер, единое API доступа, возможность объединять конфиги с одним форматом и прочие вкусности. О них уже писали предыдущие 19 страниц :)

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

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

Либо перечитайте тред,ф не только последние 5 страниц, либо назови отличия т.н. реестра от FS

>Зато единый стандартный парсер

Итого - уже 40 страниц говорят о "едином стандартном парсере". Покажите, наконец, нам эту "вакуумную лошадку"!

> Сам ты тупой:)))
> Тебе так и не понять, что они криво и неэффективно отоборажаются на RDBMS. не понять потому, что кроме RDBMS ты НИХРЕНА не знаешь, неуч:)
> Ты, придурок, конечно, не знаешь, что в ФС тоже есть индекс:)
> Ты, придурок, конечно, не знаешь, что для доступа к РАЗНЫМ ФС - единый интерфейс, а к РАЗНЫМ RDBMS - разный:)
> С какого хрена?
> И сколько компов у тебя "в локалке" дома? Oracle на выделенном сервере справляется?:)
> Ты хоть бы про кластеры не упониман, ламер - ты их хоть в глаза видел?:)
> Идиот... Срочно доктора к нему!

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

2geek: слабо избавиться от слова "идиот" в лексиконе?

>2geek: слабо избавиться от слова "идиот" в лексиконе?

медицинский термин. Кроме того это был вопрос.

> медицинский термин.

"Если эта роль ругательная, попрошу ее ко мне не применять!" (с) С.С.Шпак

>"Если эта роль ругательная, попрошу ее ко мне не применять!" (с) С.С.Шпак

это надо в правила внести

Кстати, полезный совет для разработчиков xorg - пусть перестанут использовать autotools. Это одна из самых худших "программ" (по моему мнению) из всех, которые я видел. (Программой это поделие даже сложно назвать.) Есть нормальные системы сборки (например, cmake).

> Кстати, полезный совет для разработчиков xorg - пусть перестанут использовать autotools. Это одна из самых худших "программ" (по моему мнению) из всех, которые я видел. (Программой это поделие даже сложно назвать.) Есть нормальные системы сборки (например, cmake).

Да она не так плоха, просто ею ровным счётом никто не умеет пользоваться. Ну зачем для хелловорлда проверять наличие в системе компилятора для фортрана!?

>Кстати, полезный совет для разработчиков xorg - пусть перестанут использовать autotools.

А ты скажи им об этом - кроме тебя никто ведь не заметил никаких autotools в xorg... потому что и там попросту нет:)

>Программой это поделие даже сложно назвать

После твоих заявлений - даже не знаю как тебя можно назвать - на "поделие" не тянешь:)

>> Для своих программ. А на прочие пусть шупальца не тянут. Это логично.

>Что такое "свои программы" в опенсорце? При том, сколько бабла эти компании вкладывают ядро, иксы, серверные приложения и пр. и пр.? Они индустриализуют все, что им нужно для бизнеса. Это нормально.

Нельзя объять необъятное, заорганизованность корпораций убивает всякую жизнь и всякое развитие.

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

Именно на этом поле МС не может конкурировать с Линуксом, именно потому Линукс жизнеспособен

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

Согласен. Но этот принцип имеет предел применимости. У линукса наступил бы "потолок" внедряемости, если б он не начал прислушиваться ко мнению корпораций.

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

>Согласен. Но этот принцип имеет предел применимости. У линукса наступил бы "потолок" внедряемости, если б он не начал прислушиваться ко мнению корпораций.

С этим тоже трудно спорить. Одним словом нужна какая то комбинация подходов, т.е 80+20+ еще что то

Во флейме этот вопрос скорее не заметят, но всё-же: Есть версия gconf, работающая через dbus, Интересно, чего продолжают юзать OrBit версию. Или D-Bus версия gconf УГ недоработанное?