Как будто бы я буду когда-то грепать по иероглифам. Делать мне больше нечего, ага. Я просто предложил вариант чтобы ничто не пропало при конвертировании, а то «iconv -c -t koi8-r» режет всё, что не попадает в KOI8-R.
Ну вот ты пишешь свой калькулятор. У него есть конфиг. Надо создать дефолтный. Надо читать конфиг и парсить. Для этого надо написать код. А можно написать схему, тогда кода для работы с конфигурацией в твоём калькуляторе станет меньше.
Нафига тебе унификация значений?
Я хочу унификацию для пользователя, чтобы все конфиги выглядели одинаково, чтобы был удобный редактор со справкой прямо там и автоматическим дописанием и проверкой на ошибки. Удобно же!
А мне вот всё жалко. И стандарты тоже. Их же люди прумали для своих целей, они не виноваты что они такие. А потом их раз и - на помойку. Мол, устарели, уже всё... А с поставленными перед ними задачами они как справлялись так и справляются. Это касается и KOI8-R. Так что, фразу «стандарт устарел» корректнее читать «поменялись задачи и цели», а не «стандарт плохой».
Я хочу унификацию для пользователя, чтобы все конфиги выглядели одинаково, чтобы был удобный редактор со справкой прямо там и автоматическим дописанием и проверкой на ошибки. Удобно же!
Давай так... Вот есть у нас группа людей, которые администрируют серверы. Они себе понаписали всякие тулзовины типа ansible / chef / puppet и с автоматизацией конфигурации теперь более-менее ок. И на белом коне в тред врываешься ты, декларируя: «Я сделаю удобнее!». Уверен, что будет удобнее?
Не правда же! Тебе надо будет написать больше букв или твой текстовый редактор будет дописывать текст в конфиге и пути к файлам тоже?
А твой будет? А что делать, если я хочу написать конфиг и разослать его на пяток машин? Хуже: что делать, если версия программы (и схема) на моей машине отличается от того, что на целевых железках?
Вот прямо так можно написать по одной штуке на ветку. А можно ввести дополнительную сущность «комментарий к параметру».
Теоретическое обсуждение это «эй парни, я вот считаю что моя хреновина (вот пруф) поможет сделать вашу жизнь лучше вот здесь и здесь (конкретные примеры, а не абстрактные парсеры); что вы об этом думаете?».
Логично сначала обсудить задачи. Типа, «Нам надо комментарии!». Мы как раз на этом этапе и находимся. Потом написать стандарт на хранение и стандарт на взаимодействие с этим реестром. Потом написать первую реализацию. Если написать сразу реализацию, то всплывёт куча неучтённых моментов, вроде «А мой конфиг хранит матрицы и последовательности операций над ними, в ваше key-value пихать не удобно, оно говно!»
Логично сначала обсудить задачи. Типа, «Нам надо комментарии!». Мы как раз на этом этапе и находимся. Потом написать стандарт на хранение и стандарт на взаимодействие с этим реестром. Потом написать первую реализацию. Если написать сразу реализацию, то всплывёт куча неучтённых моментов, вроде «А мой конфиг хранит матрицы и последовательности операций над ними, в ваше key-value пихать не удобно, оно говно!»
Нет, задачи нам надо обсуждать, когда мы решили, что твой подход потенциально интереснее текущего. Пока что просто ещё один dconf.
Не я один врываюсь. Идея не новая. Обычно подобные треды заканчиваются «Текстовые файлы работают, не надо ничего менять».
Уверен, что будет удобнее?
Это можно выяснить обсуждая конкретные задачи и пути их решения. Вот страшный пример с конфигом logrotate оказался совсем не страшным и неплохо ложится на концепцию реестра.
Это можно выяснить обсуждая конкретные задачи и пути их решения. Вот страшный пример с конфигом logrotate оказался совсем не страшным и неплохо ложится на концепцию реестра.
Пока что не ложится, потому что у нас нет вывода на экран и примера схемы, которую нужно будет писать авторам logrotate.
Что плохо в нём по твоему мнению? Можно взять его за основу и сделать лучше.
То, что текстовые файлы в итоге всегда оказываются проще. Их можно копировать, бекапить, по ним проще грепать, их можно класть в одну директорию со скриптами и получать локальность конфигурации, в них можно писать комменты, для того, шоп твоя программа могла их сделать не нужен dconf и половина гнома.
А что делать, если я хочу написать конфиг и разослать его на пяток машин?
Написать вредакторе, сохранить в файлик, на пятке машин сделать какой-нибудь: reg-import myfile. Это опять же может быть в самом редакторе. Меню «Send to another PC». Ты её жмяк, у тебя спрашивают пароль от ssh (или не спрашивают, если есть ключ).
Хуже: что делать, если версия программы (и схема) на моей машине отличается от того, что на целевых железках?
1. Удалённое подключение к целевой железке. 2. Импорт схемы. Тебе всё равно надо будет подключиться к железке, чтобы залить текстовый файл. Поэтому оверхеда не будет.
Так как ты засунешь текст на разных языках в одну строку? Использовать разные кодировки и специальную последовательность переключения? А если у тебя в одном алфавите больше, чем 255 символов?
Всё решаемо. Но я до сих не понимаю выгоду от такого подхода. Страдать придется всем - разработчикам софта, которым придется поддерживать ЕЩЁ ОДИН режим конфигурации, админам, которые в любых нестандартных условиях окажутся в луже (читай выше про Филиппины). Короче, куча лишних телодвижений. Для чего? Какую _КОНКРЕТНУЮ_ задачу ты не можешь решить без реестра? Какую _КОНКРЕТНУЮ_ выгоду ты получаешь?
Если это будет основной формат, то будет даже проще. Написал схему, меньше писать парсер конфига.
админам, которые в любых нестандартных условиях окажутся в луже (читай выше про Филлипины)
Ну как бы нет проблемы скопировать кусочек реестра.
Какую _КОНКРЕТНУЮ_ задачу ты не можешь решить без реестра?
Все могу, но не удобно. Это как когда производители придумывают новые болты и новые ключи/отвертки к ним.
Какую _КОНКРЕТНУЮ_ выгоду ты получаешь?
Унификация. Совмещение справки и подсказок с редактором. Защита от опечаток и простых ошибок. Упрощение разработки нового софта. Например, получение уведомления об изменениях параметра другой программой пишется (не надо следить за файлом) гораздо проще и работает быстрее (не надо парсить ещё раз), при этом возникнет меньше ошибок вроде «правил один параметр, не закрыл скобочку, сервер перечитал конфиг и упал».
Можно написать без схемы, параллельно поглядывая в мануал. Тогда это будет как с текстовым файлом. Я не предлагаю делать схему строго обязательно, а очень строго рекомендуемой.
Унификация. Совмещение справки и подсказок с редактором. Защита от опечаток и простых ошибок. Упрощение разработки нового софта. Например, получение уведомления об изменениях параметра другой программой пишется (не надо следить за файлом) гораздо проще и работает быстрее (не надо парсить ещё раз), при этом возникнет меньше ошибок вроде «правил один параметр, не закрыл скобочку, сервер перечитал конфиг и упал».
Вынужден тебя разочаровать, с такой мотивацией тебя скорее всего пошлют. Сама по себе унификация бесполезна. Если хочешь примеров — посмотри на конфигурацию pf (pf.conf). Такие правила очень удобно читаются, и если совать их в реестр получится полная параша.
Да я в целом и не спорю, но не надо пропагандировать мне юникод. Я так и писал уже: хотите юзать юникод - юзайте, но позвольте тем, кто не желает юзать юникод, его не юзать.
Человек не умеет должным образом пользоваться тем, что не собрано его руками.
Вывод: ты не умеешь должным образом пользоваться не только компьютером, но даже зубной щеткой. Только не рассказывай, что ты собрал себе компьютер и щетку своими руками (начиная с получения необходимых материалов) — не поверю.
Да, и потому я не умею должным образом пользоваться и ядром Linux, иначе бы давно уже пропатчил бы его сняв ограничения поддержки PSF шрифтов. Но, мало ли, начнёшь патчить, а это каким-то образом затронет и другие подсистемы... Это же надо знать прежде чем туда лезть... А это знают только авторы... А им в багзиллу я писал, пока ноль реакции...