Что придёт на смену xorg.conf?

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

Естественно. Как subversion'у воспользоваться сисемой прав доступа на FAT, если её там нет?:) Ну, дык, я и не предлагаю на FAT это разворачивать. Да и никто уже не ориентируется на поддержку чего-либо на FAT, даже у M$ многие фичи и софтины на FAT не работают уже.

Всё больше похоже, что ты встрял в тред, прочита максимум пару последних страниц. Сорри, но мне неинтресно повторять уже сказанное выше:)

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

А как иначе?

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

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

"Порядок следования" - это уже СЦЕНАРИЙ. По "буржуйски" сценарий - script:)

>Пример может и не самый удачный, но идею более менее обрисовывает.

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

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

Насчет svn мне казалось, что дело не в fat-е. Для полноценного репозитория с нетривиальной системой прав, UNIX-прав тоже не хватит для описания, и даже ACL-ов, ибо в svn права доступа можно выставлять и на объекты ВНУТРИ репо. Но это тут оффтопично.

> Всё больше похоже, что ты встрял в тред, прочита максимум пару последних страниц. Сорри, но мне неинтресно повторять уже сказанное выше:)

Есть такое. Меня больше всего привлёк вопрос о семантике "конфигов" и "скриптов". Все, что я имел сказать, я сказал. А потом Остапа понесло :)

> По "буржуйски" сценарий - script:)

Спасибо, с разговорным вражеским знаком.

> Он обировывает неудачную реализацию:)

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

>Спасибо, с разговорным вражеским знаком.

Ну и отлично:)

Твой пример - именно сценарий из-за неправильной реализации. реализуй как я сказал выше - у тебя получится "честный статический конф". Посмотри как реализован механизм alternatives - там "весовые числа" для "ключей" могут быть или числами (тогда используется абсолютная величина числа для сравнения приоритетов), или ссылкой на ключ из того же "конфига" (тогда используется числовая величина ключа, на который ссылаются). И в конце концов весь этот очень простой механиз "выливается" в элементарные симлинки в ФС. Просто, как и всё гениальное - зумль с реестром "отдыхают":)

> "Порядок следования" - это уже СЦЕНАРИЙ.

Ога, и строка - это тоже сценарий. Да и число - тоже.

> Просто, как и всё гениальное - зумль с реестром "отдыхают":)

Ммм... То-то они уже на пенсии с тросточкой ходят...

>Однако, можно и что-нибудь другое найти. Если заняться поисками, конечно.

"Занятся поисками" ~ "притянуть за уши":) Можешь спросить про "физический порядок следования" у DB-программеров - услышишь много "лестного":) Потому как ЛОГИЧЕСКИХ порядков следования на практике нужно не 0, и не 1, а 0...(infinity) - для разных контекстов.

Я же вам привёл пример "конфига" вполне реальный, прямо "из под руки" - даже не искал его.

Вообще забавно получается: вы привели пример как бы "статического конфига", а он оказался скриптом, я же указал вам как сделать из него "честный статический конфиг". В то же время я вам привёл конфиг (ведь что плохого для кофига в наследовании?), а нём, получается, есть логика, кроме статики, и как сделать его "статическим конфигом" - не знаю... :(

>Ога, и строка - это тоже сценарий. Да и число - тоже.

В Forth'е, например, выглядит как число,Ю а на самом деле - действие:)

> Ога, и строка - это тоже сценарий. Да и число - тоже.

Ну да. Тут явно все признаки ценителя одновременно функциональных языков программирования и ОС Plan9.

>Ога, и строка - это тоже сценарий

не знаю. Если порядок следования в строке важен и она не обрабатывается не обычным однократным паттернматчингом, то - возможно:)

> Занятся поисками" ~ "притянуть за уши":)

Как розу ты не назови. (c) Я "притянул за уши" один пример, вы другой. В чем разница?..

>> Ога, и строка - это тоже сценарий. Да и число - тоже.

> В Forth'е, например, выглядит как число,Ю а на самом деле - действие

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

> Тут явно все признаки ценителя одновременно функциональных языков программирования и ОС Plan9.

Тут явные признаки софиста на разминке :D

>> Тут явно все признаки ценителя одновременно функциональных языков программирования и ОС Plan9.

>Тут явные признаки софиста на разминке :D

Тоже довольно интересная точка зрения :)

>Тут явно все признаки ценителя одновременно функциональных языков программирования и ОС Plan9

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

>Тут явные признаки софиста на разминке :D

Я не вижу здесь софистики. А чтобы её и не было - давайте чёткие определения понятиям (тем же "скрипт" и "статический конфиг") - тогда софистика в принципе невозможна:)

> Можем и про них поговорить - я последний год постоянно на Erlang, например, програмлю. А вы?

Ага. Чувствую себя провидцем. Я последнее время на жабке деньги зарабатываю :) Чувствуете разницу в текущей работе мышления?

>Тоже довольно интересная точка зрения :)

Вы уже посмотрели на реализацию alternatives? В Debian (AFAIR это изначально их разработка) или в Ubuntu, да и в других дистрибутивах есть, даже не в dev-based. Можете предложить реализацию попроще на XML и реестре?

> Я не вижу здесь софистики. А чтобы её и не было - давайте чёткие определения понятиям (тем же "скрипт" и "статический конфиг") - тогда софистика в принципе невозможна:)

Можно использовать следующие определения:

Конфигурационный файл:
In computing, configuration files, or config files, are used to configure the initial settings for some computer programs. They are used for user applications, server processes and operating system settings. The files are often written in ASCII (rarely UTF-8) and line-oriented, with lines terminated by a newline or carriage return/line feed pair, depending on the operating system. They may be considered a simple database. Some files are created and modified using an ASCII editor. Others are created and modified as a side-effect of changing settings in a graphical user interface (GUI) program. The formats of configuration files are often poorly documented.[citation needed]
Some applications provide tools to create, modify, and verify the syntax of their configuration files. For server processes and operating system settings, the only documentation may be the source code. Some configuration files are partially described by man or help pages.
Some computer programs only read the configuration files at startup. Others periodically check the configuration files for changes. Some can be told to re-read the configuration files and apply the changes to the current process, or indeed to read arbitrary files as a configuration file. There are no standards or strong conventions.
Recently, XML and YAML have become popular as configuration file formats. They have the advantages of having well-defined syntaxes, and tools to validate and verify the syntax of the files that are created in those formats.

Скрипт:
A scripting language, script language or extension language, is a programming language that controls a software application. "Scripts" are often treated as distinct from "programs", which execute independently from any other application. At the same time they are distinct from the core code of the application, which is usually written in a different language, and by being accessible to the end user they enable the behavior of the application to be adapted to the user's needs. Scripts are often, but not always, interpreted from the source code or "semi-compiled" to bytecode which is interpreted, unlike the applications they are associated with, which are traditionally compiled to native machine code for the system on which they run. Scripting languages are nearly always embedded in the application with which they are associated.
The name "script" is derived from the written script of the performing arts, in which dialogue is set down to be spoken by human actors. Early script languages were often called batch languages or job control languages. Such early scripting languages were created to shorten the traditional edit-compile-link-run process.

>Я последнее время на жабке деньги зарабатываю :)

Да это с первых постов было видно:) Ничего, если придётся на жабке, но на J2ME для embedded "позарабатывать" - на 99% уверен, что энтузиазма на счёт "универсаности XML" поубавится:)

>Можно использовать следующие определения:

Ну и где в этих определениях говорится, что конфиг!=скрипт ?

> Вы уже посмотрели на реализацию alternatives?

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

> Ну и где в этих определениях говорится, что конфиг!=скрипт ?

А вы действительно пытаетесь понять написанное или ищете в нем подтверждение своим взглядам?

>Да. Работаю на убунте и вполне с ней знаком на практике. Однако, причем тут конфигурация?

Если такой вопрос возник - значит не ознакомились.

>Это больше похоже на список общесистемных псевдонимов для программ, только применительно к консоли.

Вы ошибаетесь:)

>> Ну и где в этих определениях говорится, что конфиг!=скрипт ?

> А вы действительно пытаетесь понять написанное или ищете в нем подтверждение своим взглядам?

А вы таки всегда отвечаете вопросом на вопрос?:)

>>> Ну и где в этих определениях говорится, что конфиг!=скрипт ? >> А вы действительно пытаетесь понять написанное или ищете в нем подтверждение своим взглядам?

>А вы таки всегда отвечаете вопросом на вопрос?:)

Нет, просто устал ходить по кругу.

>Нет, просто устал ходить по кругу.

Ну так не ходите - найдите подтверждение того, что конфиги НЕ МОГУТ, НЕ ИМЕЮТ ПРАВА быть скриптовыми - и на этом закончим:)

> Вы ошибаетесь:)

Если и так, то не сильно.

Что, кстати, мешает заменить

update-alternatives --set editor /usr/bin/emacs21

скажем на

uniconfig -s "/System/Alternatives/editor" -t string -v "/usr/bin/emacs21" ?

а в программе (любой) вытаскивать его так-то так:

String editor = uniConfig.getKey("/System/Alternatives/editor", UniTypes.STRING);
if (editor != null) {
  doSometing(editor);
}

?

В такой схеме alternatives вполне вписывается в единую систему конфигов.

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

> А как иначе?

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

> Ну так не ходите - найдите подтверждение того, что конфиги НЕ МОГУТ, НЕ ИМЕЮТ ПРАВА быть скриптовыми - и на этом закончим:)

С точки зрения софистики, вы противоречите сами себе ибо: скриптовые конфиги = конфигурационные скрипты = скрипты.

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

>а в программе (любой) вытаскивать его так-то так:

В какой программе вытаскивать? зачем что-то ещё "вытаскивать"???

Например, у меня есть следующие альтернативы:

erlang-R11B: /usr/bin/erl /usr/bin/erl-R11B 100

erlang-R11B: /usr/bin/erl /usr/bin/erl-R12B 50

Что я должен "вытскивать", вместо того, чтобы просто в консоли запустить $ erl

Или просто выбрать пункт "Erlang" в меню DE?

Точно также реализовано с java-1.5/java-1.6/java-1.7:

Я просто запускаю:

$ java -jar ...

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

ФС - это и есть упрощённая база данных, придурок. Держать запущенной RDBMS там, где хватает возможностей ФС - идиотический оверхэд. А использовать RDBMS для иерархических данных - полный дебилизм. Марш в школу, неуч:)

> В какой программе вытаскивать? зачем что-то ещё "вытаскивать"???

Пример, который я привел, применим и к alternatives, и к настройкам отсальных программ. Любая программа для любых целей.

Кто будет вытаскивать? sh, bash, exec. К примеру.

> Держать запущенной RDBMS там, где хватает возможностей ФС - идиотический оверхэд.

Про базу данных поддерживаю. Про ФС - вопрос спорный.

>Если я пишу маленькую программку с простой системой инициализации, то скрипты мне нужны как зайцу пятая нога.

Всё верно! Ключевое слово - "Если":)

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

Ну вот:

[пространство имён]

ключ=значение

Нахрена здесь XML:)

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

Эта ваша фраза не имеет никакого объектианого смысла - это всего лишь ваше субъективное мнение:)

>Кто будет вытаскивать? sh, bash, exec. К примеру.

:)))))))))))))))))

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

> Эта ваша фраза не имеет никакого объектианого смысла - это всего лишь ваше субъективное мнение:)

Прошу заменять подобные фразы чем-нибудь более обоснованным.

> :)))))))))))))))))

А скажите, что не будет работать?

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

А чем вас не устраивает "POSIX API"? И чем POSIX - не кроссплатформенный??? На какую платформу, по вашему, ориентирован POSIX?

> А чем вас не устраивает "POSIX API"?

Хотя бы тем, что банальное открытие файла в windows осуществляется:

HFILE WINAPI OpenFile(
  __in   LPCSTR lpFileName,
  __out  LPOFSTRUCT lpReOpenBuff,
  __in   UINT uStyle
);

в *nix

int open(const char *path, int oflag, ...);

Ну и где здесь проблемы POSIX???

Я вижу только проблемы винды, которая "не поддерживает" POSIX, а ещё я вижу проблемы в вашей информированности, потому что в винде

int open(const char *path, int oflag, ...);

AFAIK работает:)

Это и есть "юолее простой вариант":

String editor = uniConfig.getKey("/System/Alternatives/editor", UniTypes.STRING);
if (editor != null) {
  doSometing(editor);
}

вместо

$ editor

?:))))

> вместо

> $ editor

> ?:))))

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

> ФС - это и есть упрощённая база данных, придурок. Держать запущенной RDBMS там, где хватает возможностей ФС - идиотический оверхэд. А использовать RDBMS для иерархических данных - полный дебилизм.

Мне иногда кажется, чо вы совершенно не в состоянии как-либо аргументировать свои высказывания. "пиридурок", "идиотический оверхэд", "полный дебилизм" - это не аргументы, а глупые попытки оскорбить анонимуса. Глупые потому, что анонимус выше ваших ругательств и смотрит только на аргументы. А их нет. И быть не может. Не может потому, что ФС - это и есть база. Только тупая, и в силу этого жрущая ресурсов больше чем RDBMS. Как правило ещё и с меньшей надёжностью и с репликацией в форме костылей. Вам видимо просто не понять простых фактов, заключающихся в том, что иерархические данные так же отражаются на реляционную модель как и любые другие, что доступ по индексам к необходимым банным осуществляется на порядки быстрее, что единый интерфейс доступа к данным позволяет создавать универсальные средства управления, что бывает так, что на компьютерах обычно всё равно имеется запущенный инстанс БД, что в локалке находится более одного компьютера или несколько компьютеров объединяются в кластер, и ещё много разных "что". Вот что действительно непонятно - так это нахрена нужна ФС, эта жалкая, медленная недобаза. Только для хранения нетипизированных данных. А много ли таких? Только /dev/*random

> Марш в школу, неуч:)

Вернётесь из школы - свистните на форуме :)

> Я вижу только проблемы винды, которая "не поддерживает" POSIX, а ещё я вижу проблемы в вашей информированности, потому что в винде

> int open(const char *path, int oflag, ...);

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

>Я вижу только проблемы винды, которая "не поддерживает" POSIX, а ещё я вижу проблемы в вашей информированности, потому что в винде

>int open(const char *path, int oflag, ...);

>AFAIK работает:)

Исключительно в силу _ограниченной_ поддержки POSIX. Но и WinAPI никто не отменял. Кроме того, что удобней

int fd = open("namespace/key", O_RDONLY);
char *buffer = (char *)calloc(1, 256);
if (buffer != null) {
  int s = read(fd, buffer, 256);
  char * value = parse_string(buffer);
  if (value == null) {
    println("type missmatch or key not found or something else...");
  } else {
    printf("value: %s\n", value);
  }
}
close(fd);

Только еще надо тип переменной из аттрибутов выдернуть. Лень писать...

(образно. ошибки можете не искать)

или

char * value = unicfg_read_key("namespace/key", UNICFG_STRING);
if (value == null) {
  println("key namespace/key not found.);
} else {
  printf("value: %s\n", value);
}

или даже

char * value = unicfg_read_key("namespace/key", UNICFG_STRING, "default_string");
printf("value: %s\n", value);

или так

import org.unicfg;

...

try {
  String value1 = UniCfg.getInstance().readKey("namespace/key1", UniCfg.ExpectedTypes.STRING);
  int value2 = UniCfg.getInstance().readKey("namespace/key2", UniCfg.ExpectedTypes.INTEGER);
  long value3 = UniCfg.getInstance().readKey("namespace/key3", UniCfg.ExpectedTypes.LONG);
  float value4 = UniCfg.getInstance().readKey("namespace/key4", UniCfg.ExpectedTypes.FLOAT);
  boolean value5 = UniCfg.getInstance().readKey("namespace/key5", UniCfg.ExpectedTypes.BOOLEAN);
  System.out.printf("value: %s\n", value);
} catch (Exception e) {
  System.err.println(e.getMessage());
  System.exit(-1);
}
Теперь жду аргументов от вас, если желаете продолжить диалог.