> А в конфиги никто и не должен лезть, кроме рута и всяких там специализированных утилит для конфигурации нескольких хостов одновременно.Конфиги нужны тогда и только тогда, когда в них не лезет никто кроме рута. Если одна программа меняет конфигурацию другой программы на лету нужно API. API работает с объектами. Ваши волшебные "специализированные утилиты для конфигурации нескольких хостов" должны работать через это API в противном случае, если они работают с текстовыми конфигами, получается жуткая каша из костылей с подпорками.
Безумие, которое я видел в Linux:
Люди пишут демоны, цель которых опубликовать RESTful API для редактирования одного текстового конфигурационного файла и правильного перепинывания, конфигурируемой программы в лучшем случае через SIGHUP. Это всё от отсутствия API и отсутствия стандартизации удаленного конфигурирования.
Нормальный способ 1: https://www.dmtf.org/standards/ws-man
Использовать стандарт WS-Management. Этот стандарт предполагает оформление конфигурации в качестве дерева CIM-классов, которые впоследствии становятся доступными для взаимодействия через SOAP. Это промышленный стандарт конфигурирования не только ПО, но и устройств. Известные имплементации: Dell iDrac, Open Pegassus, WinRM
Терпимый способ 2: RESTful API
Проблема в том, что это API должен написать разработчик. В том числе предоставить работающий веб-сервер на стороне своего приложения. И вот если всего этого нет начинается безумная свистопляска с вспомогательными сервисами.
Нормальный способ 3: Шина данных
Можно опубликовать объекты, которые должны подпадать под изменения в шину данных IPC/RPC при этом шина подключена к центральному хранилищу конфигурации и есть ACL для изменения параметров. Этот способ и есть сочетание COM+, DCOM и Windows Registry. В Linux похожее взаимодействие реализуется через D-Bus + dconf + gobject introspection, и только для GNOME. Systemd, кстати, публикуется в D-Bus, но там ограничения в том, что доступна только работа с юзерспейсом. Ядро объектно ориентированных шин не имеет, если таковой не считать Netlink, которую тащат уже и во FreeBSD. Про ACL я вообще промолчу, это тихий ужас.
> С кластерами дел не имел, но что-то мне подсказывает, что в линуксе, который единственный в топ-500 суперкоплюхтеров, все с этим в порядке.
Нет не в порядке. Кластер - это не про топ-500, это просто обычная группа компьютеров или виртуальных машин, на котором запущено одно и то же приложение с целью отказоустойчивости и балансировки нагрузки.
Из моего опыта нормально автоматизированы кластерные службы в Windows и в Solaris. Остальное опять костыли и подпорки.
Видимо бесполезно объяснять, потому что вы не видели сложных задач... Нельзя пользоваться простым текстовыми конфигурациями в кластере без решения задач по атомарности и транзакционности, если в один и тот же момент времени программу могут захотеть переконфигурировать сразу несколько других программ.
Еще одно безумие, которое делают в проектах на UNIX-подобных ОС: Хранить конфигурацию таких программ в полноценной БД типа PostgreSQL. Но нельзя же ставить сервера БД на каждый чих. Кроме того это не решает проблему объектов, которым нужно хранить состояние и потерять его при перезагрузке.
> Вы и правда не видите разницы между единой для всей системы точкой отказа, куда без конца пишут всякий мусор от "реестра" DE?
> Пример для FreeBSD не составит труда привести? Или опять гном в виде аргумента?
Я не собираюсь гадать, что вы там и где себе устанавливаете на домашний компьютер. Но при попытке создать кластер на FreeBSD у вас будет создана бинарная база конфигурации (реестр) тех программ, которые вы кластеризуете в системе и сделает её вам corosync. Поймите, ваша вендетта реестрам - это всё от глупости и скудности опыта. Любой кто борется с реестрами - просто идиот, я уже приводил в пример использование реестров при создании программно-определяемых хранилищ. Реестр - это каталог объектов конфигурации. Структура данных такая... именно их используют в отказоустойчивых кластерах, потому что текстовые конфиги - это полный мрак. Сделайте домашку: https://vermaden.wordpress.com/2020/09/03/freebsd-cluster-wi.../ и потом поговорим.
> Тут уже я порекомендую вам обратиться к системному администратору, потому как /proc что в линуксе, что в бсд - виртуальная фс, которая никуда не записывается. В отличии от реестра, лол
А реестр Windows это что такое? Файлик на диске что ли?! Реестр Windows это виртуальная файловая система, которая монтирует группу разных файлов (registry hive). При этом внутри самих хайвов часть объектов являются волатильными, то есть размещенными исключительно в RAM и никогда не попадающие на диск. Не будьте ослом и прочитайте статью, которую я кидал выше про volatile registry keys.
Вы не можете по regedit.exe определить, который раздел сохранится после перезагрузки, а какой временный. Там даже не все хайвы подключаются для просмотра и редактирования. Перед тем как спорить, лучше всё-таки прочитать о том, о чем собрались спорить.
> В отличие от Шиндовс, текстовые и нетоглько конфиги внутри /home, вполне себе понятны без бингования msdn. Некоторые вещи особенно удобны, в виде вынесения .cache для всего софта. И его, например, очень просто и легко отсимлинчить или отхардлинчить средствами системы даже простому юзеру. А в десяточке-11 уже разрешили простому смертному их создавать? Или по-прежнему нужны внешние утилиты или повершелл?
Ах ну да. Чтение документации - это плохо, а умение догадаться по конфигам - это достоинство. Будете больше читать документации не так позорно будет в интернете не знать что реестр Windows частично хранится только в RAM и все драйверные параметры и состояния служб никто не пишет на диск...
Теперь про симлинки... ну их как бы нет в NTFS. Там Reparse Points: https://learn.microsoft.com/en-us/windows/win32/fileio/repar...
И да, они опять объекты а не файлы. Но меня больше интересует другое. Почему создание симлинка в BSD с использованием вашей любимой оболочки - это нормально, а от того, что для создания Reparse Point нужен PowerShell, сразу прыщить начинает?
