Теперь в системд будет свой mount - systemd-mount

Как будто бы я буду когда-то грепать по иероглифам. Делать мне больше нечего, ага. Я просто предложил вариант чтобы ничто не пропало при конвертировании, а то «iconv -c -t koi8-r» режет всё, что не попадает в KOI8-R.

Проблема и софта, и системы
Нет единой организации, структуры
Нет стандартов, нет понятий о порядке директорий

На микрокомпьтерах ASCII
Компьютер - инструмент, и нечего его жалеть

UTF-over8 мне не интересный
Под юникод большинство подразумевает UTF-8
Это уже стандарт, и в вебе, и в энтерпрайзе

Оптимизировать нужно дисковое IO в Linux, производительность которого на уровне ДНА

Какие такие парсеры тебе необходимо пейсать?

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

Нафига тебе унификация значений?

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

Возникнет гонка обращений к реестру и начнутся тормоза. В винде так и происходит.

А вдруг возникнет гонка обращений к диску? И реестров может быть больше одного. Например, пользовательский и системный.

А мне вот всё жалко. И стандарты тоже. Их же люди прумали для своих целей, они не виноваты что они такие. А потом их раз и - на помойку. Мол, устарели, уже всё... А с поставленными перед ними задачами они как справлялись так и справляются. Это касается и KOI8-R. Так что, фразу «стандарт устарел» корректнее читать «поменялись задачи и цели», а не «стандарт плохой».

Оптимизировать нужно дисковое IO в Linux, производительность которого на уровне ДНА

500k IOPS с одного (не самого топового) NVMe диска. Тебе мало?

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

Ага.

Не правда же! Тебе надо будет написать больше букв или твой текстовый редактор будет дописывать текст в конфиге и пути к файлам тоже?

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

Давай так... Вот есть у нас группа людей, которые администрируют серверы. Они себе понаписали всякие тулзовины типа ansible / chef / puppet и с автоматизацией конфигурации теперь более-менее ок. И на белом коне в тред врываешься ты, декларируя: «Я сделаю удобнее!». Уверен, что будет удобнее?

Не правда же! Тебе надо будет написать больше букв или твой текстовый редактор будет дописывать текст в конфиге и пути к файлам тоже?

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

Вот прям в произвольном месте?

Вот прямо так можно написать по одной штуке на ветку. А можно ввести дополнительную сущность «комментарий к параметру».

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

Логично сначала обсудить задачи. Типа, «Нам надо комментарии!». Мы как раз на этом этапе и находимся. Потом написать стандарт на хранение и стандарт на взаимодействие с этим реестром. Потом написать первую реализацию. Если написать сразу реализацию, то всплывёт куча неучтённых моментов, вроде «А мой конфиг хранит матрицы и последовательности операций над ними, в ваше key-value пихать не удобно, оно говно!»

Логично сначала обсудить задачи. Типа, «Нам надо комментарии!». Мы как раз на этом этапе и находимся. Потом написать стандарт на хранение и стандарт на взаимодействие с этим реестром. Потом написать первую реализацию. Если написать сразу реализацию, то всплывёт куча неучтённых моментов, вроде «А мой конфиг хранит матрицы и последовательности операций над ними, в ваше key-value пихать не удобно, оно говно!»

Нет, задачи нам надо обсуждать, когда мы решили, что твой подход потенциально интереснее текущего. Пока что просто ещё один dconf.

Уверен, что будет удобнее?

Не я один врываюсь. Идея не новая. Обычно подобные треды заканчиваются «Текстовые файлы работают, не надо ничего менять».

Уверен, что будет удобнее?

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

Стандартов тупо нету

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

Пока что не ложится, потому что у нас нет вывода на экран и примера схемы, которую нужно будет писать авторам logrotate.

Слушай раз на миллион

Не я один врываюсь. Идея не новая. Обычно подобные треды заканчиваются «Текстовые файлы работают, не надо ничего менять».

Мб потому что они действительно работают?

Слушай раз на миллион

Что раз на миллион? Мы эти железки вторую неделю тестируем, и каждый день нормальные IOPS.

Пока что просто ещё один dconf.

Что плохо в нём по твоему мнению? Можно взять его за основу и сделать лучше.

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

Что плохо в нём по твоему мнению? Можно взять его за основу и сделать лучше.

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

Как будто бы я буду когда-то грепать по иероглифам.

Так я и сказал, что у тебя очень ограниченный случай, а ты из него делаешь общие выводы, вроде «Юникод плохо, память жрёт. Не надо его использовать!».

А что делать, если я хочу написать конфиг и разослать его на пяток машин?

Написать вредакторе, сохранить в файлик, на пятке машин сделать какой-нибудь:
reg-import myfile.
Это опять же может быть в самом редакторе. Меню «Send to another PC». Ты её жмяк, у тебя спрашивают пароль от ssh (или не спрашивают, если есть ключ).

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

1. Удалённое подключение к целевой железке.
2. Импорт схемы.
Тебе всё равно надо будет подключиться к железке, чтобы залить текстовый файл. Поэтому оверхеда не будет.

Есть кучи других кодировок для иероглифов: BIG5, GB, JIS, KSC, EUC, Shift-JIS, EBCDIC,... и т.д. А юникод ненужен.

Ну вот, значит надо взять от dconf всё лучшее и отвязать его от гнома. =)

То, что текстовые файлы в итоге всегда оказываются проще.

Не во всём.

Их можно копировать, бекапить

Дамп реестра, импорт реестра

их можно класть в одну директорию со скриптами и получать локальность конфигурации

Хм... Надо подумать как тут поступить.

в них можно писать комменты

Это решаемо.

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

Ммм... Как тебе сказать. В прошлый раз это было копирование через два teamviewer и RDP куда-то Филлипины. И нет, никакого SSH там не было.

А юникод ненужен.

Так как ты засунешь текст на разных языках в одну строку? Использовать разные кодировки и специальную последовательность переключения? А если у тебя в одном алфавите больше, чем 255 символов?

Подытожим: Он не нужен тебе. Не надо обобщать.

Это решаемо.

Всё решаемо. Но я до сих не понимаю выгоду от такого подхода. Страдать придется всем - разработчикам софта, которым придется поддерживать ЕЩЁ ОДИН режим конфигурации, админам, которые в любых нестандартных условиях окажутся в луже (читай выше про Филиппины). Короче, куча лишних телодвижений. Для чего? Какую _КОНКРЕТНУЮ_ задачу ты не можешь решить без реестра? Какую _КОНКРЕТНУЮ_ выгоду ты получаешь?

Ммм... Как тебе сказать. В прошлый раз это было копирование через два teamviewer и RDP куда-то Филлипины.

Тогда это будет копирование файла и импорт. Или можно сделать автоимпорт при копировании в определённое место.

Тогда это будет копирование файла и импорт. Или можно сделать автоимпорт при копировании в определённое место.

Это все прекрасно. У нас разные версии софта и нет SSH доступа. Как твой редактор узнает схему? Копировать её с Филиппин?

Их можно копировать, бекапить

А кто тебе запрещает копировать бинарник реестровый?

по ним проще грепать

Это минус, т.к. реестр грепать вообще не нужно.

Это минус, т.к. реестр грепать вообще не нужно.

Правда? А если я вот хочу все-таки выяснить, где у меня ещё такой путь в конфигурации прописан?

Страдать придется всем - разработчикам софта

Если это будет основной формат, то будет даже проще. Написал схему, меньше писать парсер конфига.

админам, которые в любых нестандартных условиях окажутся в луже (читай выше про Филлипины)

Ну как бы нет проблемы скопировать кусочек реестра.

Какую _КОНКРЕТНУЮ_ задачу ты не можешь решить без реестра?

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

Какую _КОНКРЕТНУЮ_ выгоду ты получаешь?

Унификация. Совмещение справки и подсказок с редактором. Защита от опечаток и простых ошибок. Упрощение разработки нового софта. Например, получение уведомления об изменениях параметра другой программой пишется (не надо следить за файлом) гораздо проще и работает быстрее (не надо парсить ещё раз), при этом возникнет меньше ошибок вроде «правил один параметр, не закрыл скобочку, сервер перечитал конфиг и упал».

Как твой редактор узнает схему?

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

Унификация. Совмещение справки и подсказок с редактором. Защита от опечаток и простых ошибок. Упрощение разработки нового софта. Например, получение уведомления об изменениях параметра другой программой пишется (не надо следить за файлом) гораздо проще и работает быстрее (не надо парсить ещё раз), при этом возникнет меньше ошибок вроде «правил один параметр, не закрыл скобочку, сервер перечитал конфиг и упал».

Вынужден тебя разочаровать, с такой мотивацией тебя скорее всего пошлют. Сама по себе унификация бесполезна. Если хочешь примеров — посмотри на конфигурацию pf (pf.conf). Такие правила очень удобно читаются, и если совать их в реестр получится полная параша.

потому что у нас нет вывода на экран

Какого у нас нет вывода на экран? Редактор реестра не вывод на экран? Можно сделать reg-cat.

которую нужно будет писать авторам logrotate.

Практически тоже самое, что я написал.

Мб потому что они действительно работают?

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

Какого у нас нет вывода на экран? Редактор реестра не вывод на экран? Можно сделать reg-cat.

Ты не привел того, как это будет выглядеть на экране. Если это будет key-value параша, как с logrotate, то лучше не стоит даже браться.

Практически тоже самое, что я написал.

Ещё раз — конкретику. Не забывай, что logrotate написан на C. Тебе нужно будет сделать библиотеку под это дело.

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

Можно, конечно. Но оно будет кому-нибудь нужно? И будет ли оно стоить всей этой возни с редактором?

Он не нужен тебе.

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

Вот прям в произвольном месте?

Пусть хранилище будет не Key-Value, а Key-Value-Type-Comment.

Пусть хранилище будет не Key-Value, а Key-Value-Type-Comment.

А если перед секцией хочу?

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

Вывод: ты не умеешь должным образом пользоваться не только компьютером, но даже зубной щеткой. Только не рассказывай, что ты собрал себе компьютер и щетку своими руками (начиная с получения необходимых материалов) — не поверю.

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

Systemd/Linux