Devuan Excalibur 6

Вот если бы их не фиксили - тогда можно было бы о чем-то говорить. Но их фиксят.

И после этого, после обновления, следует рестарт всех запущенных компонент кадаврокомбайна, в том числе незатронутых CVE. Ага.

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

И после этого, после обновления, следует рестарт

Не следует.

Уточню - между пониманием требований отнюдь не головой и рукожопой разработкой

И это абсолютно неправильно. Отказать. Следующий.

Если у тебя нет никакого линукса с собой, то каким образом ты извлек из нерабочей машины логи?

Jtag? Например. Линуксы они разные бывают. И прочие подобные варианты

Назвать рукожопа рукожопом? Оно обдетсо? Да мне плевать как-то, носи звание с гордостью

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

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

Короче, аргумент так себе. Отказать.

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

А с другой стороны кабеля что? Ну-ка?

Комп. И не с линуксом

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

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

Таким образом получается, что у тебя должен быть с собой journalctl.

Я же говорю - плохой аргумент. Не продумал ты его до конца.

Начиная с одноплатников полно всякого железа с линухами и разъемом jtag на борту.

С помощью костылей и велосипедов можно решить всё.

Можно. Имея инструмент любого уровня. Это значит, что и прочитать журнал проблем не будет. Просто поставь journalctl, хоть на винду в wsl.

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

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

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

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

Если ты занимаешься отладкой подобных девайсов - у тебя либо должен быть соответствующий инструментарий, либо возможность его получить. Ситуация, в которой у тебя есть комп с виндой и жтагом, но нет возможности почитать журнал линуксом, мне представляется маловероятной, потому что в городе у тебя есть интернет, а если ты едешь на выезд за город обслуживать устройства - у тебя будет полный набор инструментов по определению. Потому что если нет - ССЗБ, ты точно так же можешь забыть не только про журнал, но и про любую другую специфику отлаживаемого девайса.

Если ко мне на объект приедет дурачок с виндой, а потом вспомнит, что на целевом девайсе journald и ему его нечем читать - то я его погоню в шею и попрошу прислать кого-то более сообразительного. Потому что это надо прям ума палату иметь, чтобы не подготовиться к вызову и не уточнить, что за девайс работает на объекте.

Почему-то я всё понял.

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

Объясняет, что такое темплейтовый юнит.

Плохо объясняет. Много воды и нет половины информации.

Очевидно, это означает, инсталляционно-зависимое. Как в твоем дистре сделают - так и будет.

И что же в этом случае надо написать в доке?

З.Ы. Ну очевидно переменную/конфиг где будет прописан список адресов для поиска юнитов в дополнение к стандартному.

Unit files are loaded from a set of paths determined during compilation

Но нет, оно, мать его, захардкожено... И да, открываем ещё один абзац и видим ЕЩЁ ОДИН косяк системд.

https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#Uni...

Ладно, оно есть. Но в 21 веке положено делать ссылки. В 19 веке кстати тоже было положено делать ссылки, только в виде текстовой сноуки "(см. туда то)".

То есть, всё там есть, ты просто пробежался по диагонали

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

Там и написано, просто ты не понял.

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

Ой не факт! Там и внутренний синтаксис, и ~200+ энкодеров, которые похожи, но каждый имеет свои собственные нюансы и поведение опций, и ещё более сложные фильтры...

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

Сфига ли?

Ну таки загляни туда! Это даже не симлинк, это 2 разных папки.

Не написано.

Я тебе прям стандарт процитировал. И не какой то левый, ты его сам мне показал!

Там ни слова нет про то, что что-то должно быть текстовым.

Не шлангуй, в */lib явно написано что должны быть бинарные исполняемые файлы и в качестве исключения - исполняемые скрипты. Юниты не являются ни тем, ни другим. Так что сова однозначно лопнет натягиваясь на глобус.

Я уже тебе говорил, чтобы ты читал оригинал, а не троекратно переваренный нейронкой кал. Вот что написано в оригинале: Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share. Архитектурно-НЕзависимые должны лежать в /usr/share, а зависимые - в /usr/lib.

Ты прицепился к [21] приписке, проигнорировав ключевое требование: /usr/lib includes object files and libraries. В первую очередь это должны быть бинарники и библиотеки!

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

Например туда запиханы... какие то фалйы переводов в /usr/lib/systemd/catalog. Абсолютно 100% архитектурно не специфичные. Чёрт, да там вообще всё! Абсолютно неспецифичная network и почти все прочие юниты, я просто тупо не смогу там найти хоть один юнит, который действительно должен тут лежать! И ещё круче - юзерские юниты запиханы сюда же.

А теперь внимание, вишенка на торте: Каталог /usr/share/systemd, где должны находиться неспецифичные (а скорее вообще все) юниты, существует и содержит юниты!!! Всего 3 штуки, но всё таки. И это явно не хитрый план, это чья то криволапость.

Это глюк. Ты взял свои знания и натянул их на тук хрень, которая там на самом деле написана.

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

И что же в этом случае надо написать в доке?

Предложи.

Но нет, оно, мать его, захардкожено… И да, открываем ещё один абзац и видим ЕЩЁ ОДИН косяк системд.

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

Ладно, оно есть.

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

Именно так и положено работать со свалками и портянками.

Вот из-за того, что ты так думаешь, в твоей голове и полно ложных знаний.

Там должно быть понятно написано

То, что ты это не понял - не значит, что документация плохая. Это значит, что ты читаешь жопой.

Ну таки загляни туда! Это даже не симлинк, это 2 разных папки.

/usr/local/lib/ и /usr/lib это ведь один путь!

Ты пьяный что ли? У тебя показания в двух постах расходятся.

Я тебе прям стандарт процитировал. И не какой то левый, ты его сам мне показал!

Нет, не процитировал. Там ничего не было о конкретизации текстовости конфигов. Слово «text» на странице вообще не встречается.

Не шлангуй, в */lib явно написано

Нет. Там написано, что в подкаталоге внутри lib могут лежать любые архитектурно-зависимые данные. Ты сейчас просто в очередной раз отрицаешь реальность: all architecture-dependent data.

проигнорировав ключевое требование

Это ключевое требование относится в /usr/lib, а не его подкаталогам, шизоид. Погуляй по остальным подкаталогам /usr/lib/*/, там еще тьма неисполняемых файлов и небиблиотек сотен других проектов. Так делает не только systemd, и все они прочитали стандарт и сделали как там написано. Но эникейщик с лора с ними не согласен, лол.

хотелось бы разобраться, являются ли юниты архитектурно-специфичными

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

Каталог /usr/share/systemd, где должны находиться неспецифичные (а скорее вообще все) юниты, существует и содержит юниты

У меня там ничего такого нет. Возможно, в твоем дистре что-то собрали через жопу.

Там должно быть понятно написано

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

И не лень тебе об стену чьей-то тупости биться... Это бесполезное занятие, я уже не пытаюсь давно.

Ты, прежде чем бороться с чей-то выдуманной тупостью, для начала поборол бы осязаемую собственную. А то у тебя в место фактов и рассуждений только одни лишь чувствуенные ощущения. Нихрена не знаешь, но мнение имеешь. Собственно, как и Кирюха.

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

Это называется «ламер».

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

С чего ты взял будто администрирование GNU\Linux это удел недоумков?

всё должно быть в 2-3 абзацах методички

Кому должно? Профессиональная работа требует профессиональной квалификации. Отсутствие знаний и умений подгоревшим пердаком не заменить - тут тебе опять не подфартило.

Можно не только бороться, вполне достаточно подчеркнуть.

Тут товарищ предлагает для чтения логов ставить дистр линукса. Он не понимает что не так

Для начала неплохо, чтобы ты сам попробовал понять, что не так в концепции имения инструмента для выполнения работы.

И после этого, после обновления, следует рестарт

Не следует.

И так и будет продолжать работать со старой libsystemd-core, несмотря на смену версии? Или там куча лишнего кода для того, чтобы ещё внутренности libsystemd-core самостоятельно мониторить? Ну-ну...

И да, systemd.spec на 60721 байт очень «упрощает» сопровождение...

Тебе нужно перезапускать только те компоненты, в которых есть критическое обновление. Если оно касается pid0 или чего-то подобного, тогда придется ребутаться. Впрочем, не велика проблема.

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

И да, systemd.spec на 60721 байт очень «упрощает» сопровождение…

Еще один эникейщик жалуется на слишком подробную документацию.

Предложи.

Так я и предложил. Ты не дочитал.

Это не косяк, всё так и должно быть.

:-D :-D :-D :-D :-D :-D

ППЦ!

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

Вот чтобы ментейнеры могли занимаься своей работой, а не бегали договариваться с каждым дистрибутивом где что размещать! У нас на дворе контейнеры, А/Б-корни, хромось, андроид, роутеры (последние 3 потенциально, если бы системд был хорошим продуктом), чёрт, да даже БСД и прочий зоопакр если бы системд не был таким спресованым куском мусора, там 90% функционала платформонезависимо.

в твоей голове и полно ложных знаний

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

Это значит, что ты читаешь жопой.

И поэтому я жопой в каждом третем абзаце нахожу косяки и неоторые из них либо тупые либо серьёзные? Или ты щас опять заявиь что нормально разбивать одну тему на 2 (и более? Конечно там ещё где то что то потеряно!) куска и не делать между ними ссылок? Типа это не баг, это фича для повышения порога вхождения до ИИ и фанатиков?

Ты пьяный что ли? У тебя показания в двух постах расходятся.

Devuan Excalibur 6 (комментарий) Devuan Excalibur 6 (комментарий)

Вот у тебя точно расходятся! Я тебе показываю /usr/local/lib/systemd/system/*, а ты тут же соскакиваешь на другую папку. Не, мне не принципиально, этот путь тоже противоречит стандарту и здравому смыслу, но ты не тупи.

Нет, не процитировал.

Именно что процитировал. Точно и без изменений скопировав с той ссамой страницы, на которую ты дал ссылку.

Слово «text» на странице вообще не встречается.

Зато встречается слово «библиотеки», «исполняемые объекты», «скрипты» и понятие «архитектурно зависимые файлы». Юниты никак не натягиваются на эти требования.

all architecture-dependent data

Ну так начни наконец отвечать на вопрос: как юнит поднятия нетворкда или д-баса натянуть на понятие архитектурно-зависимых данных?

Погуляй по остальным подкаталогам /usr/lib/*/, там еще тьма неисполняемых файлов и небиблиотек сотен других проектов

Так мы вроде не чьи то чужие косяки обсуждаем а именно системд.

Из соображений единообразия было принято решение класть в lib все юниты

Тогда что 3 файла делают в /usr/share/systemd? А зачем тогда добавлен /usr/local/lib/systemd/*?

Возможно, в твоем дистре что-то собрали через жопу.

А возможно как раз прочитав стандарт на размещение данных в ФС.

Да у тебя все кто видит косяки и они им не нравятся «не поняли».

Так я и предложил. Ты не дочитал.

Не мне предложи, пуллреквест предложи.

ППЦ!

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

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

Мейнтейнеры дистрибутива, а не systemd. Ты ничего не понял, перечитай еще раз.

Если бы я вручную вычёсывал свалки слабосвзанных фактов без понятной структуры

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

И поэтому я жопой в каждом третем абзаце нахожу косяки и неоторые из них либо тупые либо серьёзные?

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

Я тебе показываю /usr/local/lib/systemd/system/*, а ты тут же соскакиваешь на другую папку.

Только не говори мне, что ты не знаешь, в чем особенности /usr и /usr/local.

Именно что процитировал.

И где там написано хоть что-то про текстовые конфиги?

Зато встречается слово «библиотеки», «исполняемые объекты», «скрипты» и понятие «архитектурно зависимые файлы».

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

Так мы вроде не чьи то чужие косяки обсуждаем а именно системд.

У тебя есть systemd, чье поведение соответствует стандарту, и куча софта, чье поведение соответствует стандарту. Единственное, не соответствующее стандарту - твой манямирок.

Тогда что 3 файла делают в /usr/share/systemd?

Какие файлы-то? Покажи.

А зачем тогда добавлен /usr/local/lib/systemd/*?

Потому что /usr/local - это префикс для той же самой структуры, что лежит в /usr, и правила там точно такие же, как и в /usr. Единственная разница между /usr/local и /usr в том, что в /usr/local предназначен для софта, который ставитися локально - в случае линукса, НЕ из пакетов.

А возможно как раз прочитав стандарт на размещение данных в ФС.

Нет.

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

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

Ага-ага. Неосиляторы решили, что reboot - это решение неосиляторства, и сослались на расписание, кластеры и т.п.

Ага-ага.

По существу возражения будут, или как обычно?

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

Констрктивное возражение уже было: хардкодить переменные - идтотизм. Они должны считываться из конфига или передаваться параметром при запуске а не компилиться из сорцев. А в мануале должно быть написамо как именно. Причём подробно и понятно, а в разделе по путям это должно быть упомянуто или ссылкой или описанием.

Мейнтейнеры дистрибутива, а не systemd

А мейтейнеры дистрибутива вообще не должны бегать за этими придурками и исправлять их косяки. Как это было например с монтированием tmpfs в /tmp на протяжении больше чем 5 лет.

ты и не видишь связи между фактами

Я не вижу связи потому что там её нет. Кое кто забыл поставить ссылки или структурировать ман по темам!

Попробуй читать подряд, а не через слово.

И что я увижу? Там же каша из случайно взятых фактов. Практически в любом месте. И я уже задолбался приводить тебе примеры. Вот та же фигня с путями: они их перечисляют и... всё! Раздел про пути закончился! Дальше начинается другой! А где то там, в другой части портянки на 13 страниц этот же раздел продолжается в виде отдельного куска и я не телепат чтобы угадать куда читать дальше. Вниз, вверх, на другую страницу или вообще в другой мануал потому что они переменную захардкодили и дистрибутивы вынуждены накладывать патчи для соответствия стандартам.

Единичные проблемы есть в любой документации

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

Только не говори мне, что ты не знаешь, в чем особенности /usr и /usr/local.

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

И где там написано хоть что-то про текстовые конфиги?

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

чье поведение соответствует стандарту, и куча софта, чье поведение соответствует стандарту.

Повторяй эту мантру до тех пор, пока PDF не станет «тем что читает Adobe Acrobat»...

Какие файлы-то? Покажи

kbd-model-map language-fallback-map tmp.mount

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

оторый ставитися локально - в случае линукса, НЕ из пакетов.

Для этого есть /opt. А содержимое /usr/local/ в реальности всегда ставится из пакетов. Не буду спорить, возможно это косяк стандарта ФС. Остаётся факт того, что это 2 разные папки с разными нюансами и назначением. А самое главное - ты не сможешь и дальше игнорировать их существование потому что тебе не удобно.

Нет.

Да. Если разработчики системд помещают архитектурно-неспецифичные конфиги в */lib/* ещё не значит что все остальные должны поступать так же.

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

Констрктивное возражение уже было: хардкодить переменные - идтотизм

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

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

Еще раз для особо тугих: мейнтейнеры дистрибутива определяют собственные стандарты упаковки пакетов и, соответственно, значения констант, с которыми работает весь systemd.

Там же каша из случайно взятых фактов.

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

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

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

Для целевой федоры или целевой федора-коре? Или целевого образа контейнера с федорой? Какие две из этих трёх систем должны пойти лесом вместе со всеми линуксами, включая Дебиан, Убунту, Арч, Сьюз, Генту и всех прочих?

мейнтейнеры дистрибутива определяют собственные стандарты упаковки пакетов

При чём тут упаковка пакетов? Мы о переменной, которую захардкодили и хреново документировали, забыв перечислить все пути поиска предоставить средство её изменения на лету. Ты буквально должен подключать оверлейФС/сквашФС с дополнительным деревом юнитов и БЕЗ перезагрузки запускать новые сервисы. А ты предлагаешь патчить сорцы и пересобирать системд?

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

Ну если у тебя нет аргументов...

на них есть 2 разных стандарта.

Покажи мне отличающиеся стандарты FHS на /usr/lib и /usr/local/lib. Ссылку в студию, бегом.

Там где «всё остальное, чего тут быть не должно».

Там нет такого пункта.

Юниты не подходят.

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

Повторяй эту мантру до тех пор

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

kbd-model-map language-fallback-map tmp.mount

Первые два файла не являются юнитами. Это описания клавиатурных раскладок, архитектурно-независимые данные. И они лежат в /usr/share, как и предписывает стандарт.

А вот tmp.mount у меня лежит в /usr/lib/systemd/system/tmp.mount. Варианта два: либо у тебя какой-то старый systemd, в котором это случайно положили не в то место, которое надо, а потом исправили (у меня systemd 258 и всё в порядке), либо у мейнтейнеров твоего дистра кривые руки.

Для этого есть /opt.

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

А содержимое /usr/local/ в реальности всегда ставится из пакетов.

На линуксе содержимое /usr/local никогда не должно ставиться из пакетов. Это в BSD-системах так, что у тебя есть базовая система в корне, а всё остальное - в /usr/local. FHS предписывает, что это каталог для локальных установок.

Вот как это выглядит у меня на арче. Дохера пакетов, ноль содержимого /usr/local:

$ tree /usr/local
/usr/local
├── bin
├── etc
├── games
├── include
├── lib
├── man
├── sbin
├── share
│   └── man -> ../man
└── src

Да. Если разработчики системд

Еще раз: нет. Стандарт четко предписывает, что так можно делать. Остальной софт делает так. Единственные, кто с этим несогласен - ты, и полтора других клоуна из треда.

Какие две из этих трёх систем должны пойти лесом вместе со всеми линуксами, включая Дебиан, Убунту, Арч, Сьюз, Генту и всех прочих?

Никакие. Всё дистрибутивы при сборке устанавливают значения этих констант. Их не требуется менять, потому что это соглашения среди мейнтейнеров каждого дистрибутива, внутри их команд. Отдельные соглашения: дебиана, арча, сюза и так далее. Люди решили, и все пакеты у них упакованы вот так.

При чём тут упаковка пакетов?

При том, что это пути, по которым systemd ищет файлы. Когда ты ставишь из системы пакет, он по определению собран с учетом соглашения и размещает свои файлы там, где их ожидает найти systemd. Для твоего собственного творчества предлагается /usr/local и /etc. Ничего из этих путей менять не требуется, просто нет такого юзкейса. Совсем.

Ну если у тебя нет аргументов…

Свои аргументы я уже перечислил: они опираются на стадарты, документацию и опыт. Ты просто всё это игнорируешь. Если ты игнорируешь стандарты и не видишь факта в поведении, соответствующему стандарту, то я уже ничем не могу помочь, только рекомендовать тебе пойти чистить сараи.

Я не говорил, что продукт идеален - ты выдумал это сам. Я сказал, что те вещи, которые ты считаешь косяками (помимо пары неточностей в документации) - косяками не являются. Не являясь ни админом, ни программистом, ты почему-то рассуждаешь о том, как правильно строить операционные системы. Естественно, логичный вывод - да, ты банально не понимаешь, о чем тебе тут говорят.

Покажи мне отличающиеся стандарты FHS на /usr/lib и /usr/local/lib. Ссылку в студию, бегом.

Ой, да пожалуйста! https://specifications.freedesktop.org/fhs/latest/usrLocal.html

Иерархия /usr/local предназначена для использования системным администратором при локальной установке программного обеспечения. Она должна быть защищена от перезаписи при обновлении системного программного обеспечения. Он может использоваться для программ и данных, которые доступны для совместного использования группой хостов, но не находятся в файле /usr.

Локально установленное программное обеспечение должно быть размещено в каталоге /usr/local, а не в /usr, если только оно не устанавливается для замены или обновления программного обеспечения в каталоге /usr. [28]

Иерархия /usr/local предназначена для использования системным администратором при локальной установке программного обеспечения. Она должна быть защищена от перезаписи при обновлении системного программного обеспечения.

Она должна быть защищена от перезаписи при обновлении системного программного обеспечения.

It needs to be safe from being overwritten when the system software is updated.

Вот прям совсем то же самое, никакой разницы...

Ах, да, давай ещё попридираемся к формулировкам:

The following directories, or symbolic links to directories, must be in /usr/local

lib Local libraries

Никаких «платфорозависимых data», тут сказано только про библиотеки! Что помешает мне утверждать что конфигам там не место?

А стандарт говорит, что подходят, явно декларируя, что DATA должны лежать в подкаталоге.

Читай стандарт, там «architecture-dependent data». В каком месте 90+% юнитов архитектурно-зависимые?

На линуксе содержимое /usr/local никогда не должно ставиться из пакетов.

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

Всё дистрибутивы при сборке устанавливают значения этих констант.

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

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

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

Ничего из этих путей менять не требуется, просто нет такого юзкейса. Совсем.

Как это нет? А энтерпрайз на ro-образах с центрально распостраняемыми конфигами? А работа в префиксах? А портабельный софт? Если ты, я, разработчики системд не знают какого то юзеркейса это нифига е значит что его нет.

Свои аргументы я уже перечислил

Ты так и не сказал а)с какого Х все юниты причислены к архитектурно-зависимым данным, особенно те, которые на 142% от архитектуры не зависят и б)как переопределить список путей для юнитов не перекомпилируя и не перезагружая системд.

Ой, да пожалуйста! https://specifications.freedesktop.org/fhs/latest/usrLocal.html

Ни слова про какие-то особенные правила для содержимого между /usr/lib и /usr/local/lib

Вот прям совсем то же самое, никакой разницы…

Я эту разницу уже тебе сам объяснил раньше: в /usr/local ставится твой локально собранный софт.

Что помешает мне утверждать что конфигам там не место?

Здравый смысл.