Пакеты, которые какие-то настройки сопровождают, не лезут каждый в <config_name> , а бросают свой файл конфигурации в <config_name>.d. И все.

Ну, это ты мне рассказал частный случай, но, кроме apt ещё дюжая толпа софта использует такой протокол. Взять тот же шелл, web сервера, systemd, emacs и много много чего:

find /etc/ -name '*.d'

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

Второе.

Первое доказать просто, для второго, ты уж извини, но нужно что то большее чем твоё авторитетное мнение :)

При чем тут только apt вообще? Ты не понял, что я написал просто. Вот, к примеру, есть конфигурация, которая идет вместе с каким-нибудь проприетарным драйвером для иксов (я просто пример привожу). При установке драйверу не нужно залезать в единый файл xorg.conf, чтобы прописать свою конфигурацию, а просто уже готовый файлик бросается в xorg,conf.d.

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

Второе, ты уж извини, очевидно.

Я видимо туговат - разжуй пожалуйста :)

ты уж извини, но нужно что то большее чем твоё авторитетное мнение :)

Просто интересно - чьего авторитетного мнения тебе было бы достаточно?

Посмотри на количество проектов использующих этот метод.

Если тебе интересно почему именно это удобно, то можно разжевать:

Параметры в конфигах неравнозначны, у них разный scope, время жизни, приоритеты и, часто, релизный цикл.

Механизм include .d/* позволяет разделить их на группы, которыми можно управлять независимо разными утилитами, или даже одной и той же утилитой, но в разное время.

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

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

Первое доказать просто, для второго, ты уж извини, но нужно что то большее чем твоё авторитетное мнение :)

Ну вот тебе мое непререкаемо авторитетное мнение :)

Либо ты невнимателен, либо я неверно сформулировал вопрос (предложи как переформулировать).

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

Следи за руками:

На вопрос

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

тебе ответили: второе.

Дальше - обоснование этого ответа.

Хорошо, количество проектов - велико. Значит это устоявшийся протокол для чтения конфигурации.

Отсюда скорее следует наличие спецификации чем её отсутствие? Иначе, как все эти люди приходят к одному и тому же подходу?

Это в идеальном розовом мире конечно, но странно, что никто не задавался этим вопросом и все тупо всегда пишут новую доку для такого метода конфигурации, хотя по сути он легко генерализуется.

стандартизирован ли кем то этот подход, читай есть ли документ

Да, стандартизирован Императором Галактики. Да, документ есть, но ты его не сможешь прочитать - он на высшем галактическом наречии, которое из людей знают считанные единицы. Кстати, Поттеринг - один из них.

Иначе, как все эти люди приходят к одному и тому же подходу?

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

Обычно, людям не хватает интеллекта.

Если у тебя на работе начальники требуют спецификацию на каждый чих - вали оттуда как можно скорее.

ЗЫ: Если ты мазохист, или там просто любишь когда тебя дрючат во все дыры просто так, даже без всякого гейства, то можешь попытаться где-нибудь отрыть спецификации Unix System V. *.d - оттуда пришло, хотя сомневаюсь что даже в спецификациях будет что-либо кроме констатации факта использования такого решения.

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

Когда я был юн, я брал кусок кода первого apache с парсером конфига. Потом пришли корпоративные фрики, и все решили, что конфиг в xml лучше всех. Теперь, думаю, всем пофиг.

Сколько страниц текста будет в твоем стандарте?

Никто от меня ничего не требует.

Ага, рассказывай.

Если нет, то я вполне успешно разработаю упрощённый вариант под свой частный случай.

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

Есть 100500 самоочевидных вещей которые нигде не описаны и никак не стандартизированы, однако, являются т.н. «explicit standard». Если много народу используют одинаковое решение - просто используй его тоже, никаких стандартов и прочей ахинеи для этого не нужно.

И да, ответ на вопрос хедпоста - «спеки нет». Есть, конечно, http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_04.html «File name expansion», но это не спека и не дизайн.

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

Оффтоп, похоже всё таки в толкс и конструктива не будет :)

И сколько раз ты сдавал в тестирование реализации таких вот explicit стандартов в проектах не за еду и до сих пор не закрытых?

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

И это всего лишь механизм реализации, и всего лишь для одного семейства оболочек.

Ясно. Перестань заниматься программированием - по тебе плачет должность помощника менеджера среднего звена.

И сколько раз ты сдавал в тестирование реализации таких вот explicit стандартов в проектах не за еду и до сих пор не закрытых?

Ну в проектах так 20, например. И не сдавал в какое-то там тестирование, а просто реализовывал explicit standard.

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

Ну самому старому живому коммерческому проекту уже где-то 22 года. Он, правда, очень узкоспециальный, но тем не менее. А очень интенсивно используемому и по сей день - где-то 15 лет.

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

Завязывай с этим говнищем с TDD. Оно только в энтерпрайзе годится, чтобы друг на дружку проще было косяки списывать, для чего-либо серьёзного оно вообще мало пригодно.

Завязывай с этим говнищем с TDD

TDD как раз рулит. У ТС с другим проблемы.

И не сдавал в какое-то там тестирование

Видимо контора специализируется на саппорте, раз такое допускается и поощряется благодарностями и баблом. Оно и понятно больше багов больше денег.

TDD как раз рулит.

Оно рулит только для какой-то элементарщины, которая впрочем и составляет 90% энтерпрайза. Для чего-то мало-мальски серьёзного, TDD либо неприменимо вообще, либо резко увеличивает трудозатраты при сомнительном результате. Например - напиши тест для функции sin(x). Чтобы гарантировано все возможные ошибки реализации ловил. Или, например, написание теста для простенького автомата состояний может занять на порядки больше времени чем написание самого автомата и его математического доказательства.

У ТС с другим проблемы.

Ну в общем да. Ему в чиновники надо, или там в адвокаты. На каком нибудь lawyers.org.ru - нашёл бы единомышленников легко.

Видимо контора специализируется на саппорте, раз такое допускается и поощряется благодарностями и баблом. Оно и понятно больше багов больше денег.

Я тащемта сам себе контора, и саппорт у меня бесплатный. Бабло в основном на продажах и реализации разных хотелок зарабатывается. Или на объяснении почему хотелка бессмысленна, и как сделать правильно.

TDD как раз рулит.

Оно рулит только для какой-то элементарщины

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

Например - напиши тест для функции sin(x). Чтобы гарантировано все возможные ошибки реализации ловил

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

написание теста для простенького автомата состояний может занять на порядки больше времени чем написание самого автомата и его математического доказательства

Начались сказки. Причем, что характерно, эта конкретная сказка никак не противоречит TDD.

Я тащемта сам себе контора

А сотрудников сколько? И сколько человеко-лет было затрачено на разработку проектов про которые ты упоминал выше?

.d - это название каталога. Не стандарт, не протокол, не метод, а название.

Так же как например venv - типичное название для каталога с python-virtualenv окружениями.

То что ты там хочешь стандартизировать - это, вероятно, именование самих файлов, то есть вот apt читает /*.list, salt читает /*.conf, а кто-то может просто /*.

Или допустим несколько стандартных конфигов, которые идут в поставке: типа 00_users.conf, 50_network.conf и т.п.

Но это специфика. Её не стандартизировать надо на все случаи жизни, а задокументировать для своего приложения. Тестами обвязать по вкусу.

Обощать такое - получится либо неприменимо, либо банально.

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

Собственно эти Dir::Etc::Parts меня и вдохновило на поиск готовой спецификации ибо попытки имели место быть даже в такой древности как apt.

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

Реализуй мне тест для sin(x).

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

Ну так тест в студию.

Начались сказки. Причем, что характерно, эта конкретная сказка никак не противоречит TDD.

TDD не панацея и даже не новинка. С какого хрена оно сейчас внезапно стало популярно у хипстеров - совершенно непонятно. Весьма узкоспециальная штука.

Завязывай с этим говнищем с TDD

Я тоже последнее время сколняюсь к мнению, что для серверных продуктов с близкой к оптимальной реализацией и интерфейсом состоящим чуть менее чем полностью из легко считываемых/мокаемых сайд эффектов дешевле применять BDD и непрерывное нагрузочное тестирование ;)

А сотрудников сколько?

Человек по 20 бывало. Но самые долгоживущие и прибыльные проекты почему-то делались при помощи всего лишь одного-двух человек.

И сколько человеко-лет было затрачено на разработку проектов про которые ты упоминал выше?

А какая вообще может быть связь между человекогодами и качеством продукта? Если какая-то контора потратила 100500 человеколет на создание ненужно - это вообще ничего не говорит ни о качестве ненужно, ни о нужности ненужно, ни даже о степени глючности ненужно.

Ну представь - стартап назанимал денег, нанял тыщу программистов, они 10 лет писали тесты для sin(x), а потом оказалось что их sin(x) таки неправильно считает sin(0.023483729347894), что тот пентиум. И что, помогли эти 10 тыщ человекочасов и модный workflow написать годный sin(x)?

Реализуй мне тест для sin(x).
Ну так тест в студию.

Я выше сказал, в каком случае буду это делать.

TDD не панацея и даже не новинка.

О, TDD не является очень многим. Например, это не зеленый сыр, не письменный стол, не плохая погода и не 29 февраля.

Локальная понятно не лишняя.

И если я буду configuration management делать для 100500 микросервисов - можно и не очень локальную общую схему их конфигов написать.

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

А какая вообще может быть связь между человекогодами и качеством продукта?

Это конечно чисто эмпирическое наблюдение, но чем больше проект, тем дороже его саппорт. Речь естественно про успешные проекты.

Ну представь - стартап назанимал денег, нанял тыщу программистов, они 10 лет писали тесты для sin(x), а потом оказалось что их sin(x) таки неправильно считает sin(0.023483729347894), что тот пентиум. И что, помогли эти 10 тыщ человекочасов и модный workflow написать годный sin(x)?

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

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

Хорошо, с бесплатным и при этом не отнимающим значительную часть ресурсов саппортом.

Остальные неудачники на рынке тратят до 70% ресурсов на саппорт, видимо тебе надо устроиться CEO куда нить в фейсбук что ли, будешь самым высокооплачиваемым руководителем года.

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

Я тоже последнее время сколняюсь к мнению, что для серверных продуктов с близкой к оптимальной реализацией и интерфейсом состоящим чуть менее чем полностью из легко считываемых/мокаемых сайд эффектов дешевле применять BDD и непрерывное нагрузочное тестирование ;)

Ну как минимум это будет быстрее/дешевле с примерно такой же вероятностью всплытия глюков. По крайней мере для таких задач. Да и нагрузочное тестирование TDD никак не заменит. :)

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

Однако, это та же идея что в TDD, просто проверяются аспекты более высокоуровневых интерфейсов?

RFC для csv не много занимает места, но это не повод чтобы его не было.

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

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

Остальные неудачники на рынке тратят до 70% ресурсов на саппорт, видимо тебе надо устроиться CEO куда нить в фейсбук что ли, будешь самым высокооплачиваемым руководителем года.

Я мизантроп, в CEO не гожусь.

А то сколько денег и благодарностей ты получил, говорит больше о твоих маркетинговых способностях, нежели качестве продукта

Маркетинга-то я и не заметил. Хотя нет, вру, был для одной софтины маркетинг в Laserist'е (официальный бумажный журнал ILDA в 90-х). Толку было мало, от общения в инете и на конференциях толку гораздо больше было. А остальное - как-то само расходилось. А предпоследний проект вообще чуть ли не подпольно распространяется, ибо позволяет работать с забугорными приборами, производители которых не особенно хотят чтобы их использовали с чужим софтом, а отечественный потребитель не может их использовать с забугорным, ибо забугорный не умеет считать отечественные коэффициэнты и параметры требуемые всякими сраными ГОСТами. И ведь как пирожки горячие расходится, ну с учётом узкости и малоизвестности такой области как колориметрия.

Так что дело не в маркетинге, а в качестве. Если штука полезная, удобная, шустрая, делает то что нужно, не требует распоследнего железа и не падает от каждого чиха - то на сегодня это лучшая реклама для ПО.

Так что дело не в маркетинге, а в качестве

Или в узком сегменте рынка и отсутствии конкуренции. Выбор которого опять же скорее про анализ рынка и маркетинг чем про разработку.

Попробуй продать и поддерживать, ну например реализацию map-reduce. Её вполне реально сделать эффективную даже в одно лицо, но выйти на уровень уже имеющихся игроков по функционалу и интеграции в различные сервисы а уж тем более поддерживать, хм. Похоже на сказку?

Однако, это та же идея что в TDD, просто проверяются аспекты более высокоуровневых интерфейсов?

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