А какой он, этот мифический Unix-way?

С трудом. Даже s-exp читать проще.

ты идиот? ты не умеешь читать? ты не понимаешь разницу между конфигурацией и работой runtime?

ну давай разжую:

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

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

systemd - не Unix-way только потому, что с некоторых пор он содержит в себе кучу всего помимо системы инициализации. Если бы он был только системой инициализации, без Journal и пр., то он ничем не нарушал бы Unix-way.

// я использую systemd

И еще раз речь идет об основных и базовых операциях и возможностях. Они быстрее и где то удобнее именно в реестре. Всякая экзотика типа этой не повод отвергать преимущество для базовых и самых распространенных операций.
:-) По сути это тот же спор что между исками и вяленым, косвенный ответ на который как всегда дал патрик, спросив «чоловики, а вам это не-smp ядро вообще нах.. нужно или нет , а то у меня большое желание его выкинуть к еб..ям» :-)

последняя спецификация yaml была направлена на то, чтобы json тоже был yaml языком :)

systemd с некоторых пор выполняет не только инициализацию и связанные с ней вещи...

http://www.wagner.pp.ru/~vitus/articles/true_unix_gui.html

затруднение с unix-way ещё в том что он комерчески проигрывал(пока будем надеятся) иным.

Unix(сейчас) менее unix-way чем невзлетевший Plan9(у которого конечно есть недостатки)

0) запус менеджера процессов и пуск стартового процесса и аргументом к ниму скрипт

1) в удобном для пользователя виде т.е либо прямой текст(и чекеры lint типа по внесению в них изменений) либо наличие тула для взаимооднозначной конвертации текст_удобный_для_редактирования_чтения fromTo вид удобный для программы чьей конфиг ( если учесть GNU то подход dwm.h - сырец ( в части обьявления констант и даже некоторых хуков) вполне удобен для настройки) - язык сырца желательно общестандартный ямлы Ntriple whatever

2)скриптом/консолью либо опятже GNU/opensourse настройка не аргументами командной строки и внитри проверка и запуск а не посредствено в коде либо запускаем либо нет - нефиг погружать на бинарный уровень то что вполне скриптуется и не требует сверхоптимизации

3) Универсальным (Plan9 like но с учётом 20 лет и других видов IPC) т.е на самом верхнем уровне интерфеск ченелов маст би - остальное как инструмент повышения производительности(т.е оптимизация и тесная_интеграция)

4) конкретика не важна- вожно что бы в результате среда_слуга(программно-апаратный комплекс) для человека был Тьюринг полон с практичным для человека способом отдачи команд(формирования составных).

5) +1 к ортогональности - удобно и что бы охватывало(не меньше) 80%

http://en.wikipedia.org/wiki/Property_list

А вот оно как:

In Mac OS X 10.7, a JSON format was introduced.

Чего бы в линупсах так не сделать?

ну вот взять к примеру вендовую версию игры Call of Cthulhu, которая зачем_то хранит конфиги (параметры разрешения, сглаживания, субтитры вкл/выкл) в реестре - и зачем?

Я понимаю что авторы переносили игру чисто под WinAPI и не хотели заморачиваться написанием своего костыля (как это делают в других играх, вынося параметры в config.cfg), но получилось уродство - вместо того чтобы в той_же_самой папке c игрой (по соседству с ланчером и либами) аккуратно лежал файлик config.ini, в который бы вносились изменения и который бы автоматом сносился вместе с остальными ресурсами игры при удалении, мы получаем еще пачку динамически изменяющихся данных в и без того нагроможденную структуру в которую прочие запущенные сервисы тоже _постоянно_ вносят какие то изменения (причем вперемешку - какая нибудь говно-утилита одновременно со звуковым манагером например), к тому же быстро распухающую от колличества циклов установок/удалений программ в системе..

Вот когда с либами говнеца хватили (от бездумного запихивания всего в System32), догадались/подсмотрели и сделали более менее правильно, чего с реестром то упираются?

JSON — недостаточно huge'n'bloated для линукса, линукс любит уродливые костыли.

xml xml'ю различен

одно дело raw xml ( возми свой сырец С|С++ и прогони через фильтр который удалит все не избыточные(для компилятора) пробельные(табы,пробелы,переводы строк где семантика не меняется) символы )

другое двересное(графовое) представление : с увеличением отступов для более глубоких узлов и цветовой подсветкой имён и атрибутов

ну попробуй перенести реестр в ini - будет такой же тормоз как и линух сейчас
ini в винде 3.1 занимал где то 100 строк сколько будет сейчас если все перенести из реестра в него и какой это будет тормоз ?

У плана есть ещё plumber кроме чистого 9P.
Как unix-way окружение можно привести i3wm, его было бы неплохо повторить в 9front.

вот именно это и объясни архитекторам бд :-)

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

Что мешает кроме реестра?

POSIX-несовместимость.

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

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

VS

вновьмодные хэшы(NoSql и т.п имя им легион) key-value для данных структура которых на перёд не извсестна ( и есть ли она вообще)

хэши для производительности всяуик структуры_даных юзают одноко у них в интерфейсе есть всегда полный import|export в текстовом виде / впрочем как и у классических БД.

еще разик, речь идет о реестре именно как бд хранения настроек, если хочешь сделать текстовый конфиг для реестра - велкам :-)

ось тормозит не потому что у неё конфиги в тексте заместо бинаря

ось тормозит ибо дыры в дизайне.

да ради бога кто против импорта экспорта из реестра линуха в текстовый файл ? :-) Но работают с бинарными форматами

реестра линуха

Ты что там пьешь/куришь?

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

почему там не оргграф с узлами/атрибутами и «под"узлами?

// я использую systemd

Во сколько раз медленнее работает по сравнению с sysvinit?

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

когда он тебе свалится, не ранее чем лет через 20 к сожалению, через пяток лет ты вообще забудешь свои славословия с адрес талмудов :-)
Кста, винду 95 точно так же встречали, «как блин где ini, че за тормоз и поему падает на каждый чих» зато потом .. :-)

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

что потом, винда 95 никогда не стала юзабельной, реестр не стал silver bullet, хранения системных настроек программ.

Ничто не мешает сделать доступ к базе данных настроек через fuse.

баш давно не юних вей ибо много в нём билтина

вместе с ней появилась и nt с ее реестром :-) а вот она уже была люкс

зачем когда ГигаHz и многоголовые процы? это удоражает сопровождение.

ini в винде 3.1 занимал где то 100 строк сколько будет сейчас если все перенести из реестра в него

А вот и разгадка. Ты почему то думаешь что конфигурационный файл должен быть один.

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

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

сказать есть чего ? :-)

Я с нежностью вспоминаю 98-й мастдай. Хоть он и был говном, но не таким, как всякие хрюндели, а тем паче - «семерки». По крайней мере, 98-й хотя бы более-менее работоспособным был.

платить покупкоц нового компа

...или заменить своё ntfs на reiser[4]fs

ну да но 95 это был тот еще подарок :-)

уговори билли :-))

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

Кстати, надо этого вендотролля беречь, их на ЛОРе маловато.

Так то был непонятный переход от 3.11 к nt4. Вот nt4 уже вполне была рабочей.

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

Непонятно только зачем было на ini забивать? - довели бы/снабдили бы ништяками и отдали сторонним приложениям под «личные нужды», а в реестр - вообще никого пускать не надо было..

Можно ведь сделать _один_ формат (JSON или т.п.) конфигов с двумя представлениями: текстовым и бинарным.
Небольшие и особо критичные (чтобы можно было править хоть чем, хоть где) конфиги хранить в текстовом представлении, остальное - в бинарном.
Естественно, не хранить в одном файле конфиги всех программ. Можно на каждую софтину по конфигу или группами. Тогда не будет срача, что в виндовом реестре.

для того что бы не покупать новый проц каждый год и не чуствовать что прошлогодний уже не торт использую wmii и т.п :)

и это будет медленнее чем чтение из одного загруженного в оперативку бинарника
А ругань, детсад блин :-)

у меня айс :-)

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

Зато не нужно постоянно держать гигабайтный бинарник в оперативе.