systemd 221 уже здесь

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

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

Мне очевидно обратное.

Тебе это только кажется.

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

Расскажи, из каких именно видов правил udev делается запись в sysfs?

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

ЩИТО? По именам чего именно они сортируются?

Тебе только кажется, что ты это знаешь.

Ещё один. Ты ни разу не писал правила для этого самого udev? Иначе должно быть очевидно, что они по смыслу императивные.

(Это не отменяет того, что goto в этих правилах — дичайший костыль, примотанный сбоку скотчем для того, чтобы не писать одинаковые условия в каждом правиле.)

из каких именно видов правил udev делается запись в sysfs?

В udev только один вид правил. Ты хотел спросить «какие операции в правилах udev приводят к записи в sysfs»? Тогда ответ ATTR{...}="...".

ЩИТО? По именам чего именно они сортируются?

По собственным именам, внезапно.

Ты ни разу не писал правила для этого самого udev?

Писал и пишу. Не часто, слава ТНБ.

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

У тебя проблемы с чтением. Я не спорил с тем, что язык фактически императивный. Я сказал, что это _провальная попытка_ создать декларативный язык.

из каких именно видов правил udev делается запись в sysfs?

В udev только один вид правил. Ты хотел спросить «какие операции в правилах udev приводят к записи в sysfs»? Тогда ответ ATTR{...}="...".

ОК. Я даже нашел 2 таких правила.

По именам чего именно они сортируются?

По собственным именам, внезапно.

Еще раз: по собственным именам _чего_? Вот фрагмент файла правил:

# T7 Volcano
ATTRS{idVendor}=="4102" , ATTRS{idProduct}=="1043" , ENV{ID_MEDIA_PLAYER}="iriver_t7-volcano"
# Walkman NWZ-S760 Series
ATTRS{idVendor}=="054c" , ATTRS{idProduct}=="05a8" , ENV{ID_MEDIA_PLAYER}="sony_walkman-nwz-s760"
# Nexus One
ATTRS{idVendor}=="18d1" , ATTRS{idProduct}=="4e11|4e12" , ENV{ID_MEDIA_PLAYER}="google_nexus-one"
# 6300
ATTRS{idVendor}=="0421" , ATTRS{idProduct}=="04fa" , ENV{ID_MEDIA_PLAYER}="nokia_6300"
# Zen Stone
ATTRS{idVendor}=="041e" , ATTRS{idProduct}=="4154" , ENV{ID_MEDIA_PLAYER}="creative_zen-stone"

По какому имени они упорядочены?

Ещё один. Ты ни разу не писал правила для этого самого udev? Иначе должно быть очевидно, что они по смыслу императивные.

В конфиге logrotate тоже имеет значение очередность блоков. Это не делает конфиг logrotate тюьринг-полным.

Ты ещё и императивность с тьюринг-полнотой путаешь?

Я тебе говорю, что язык описания правил изначально планировался как «установили пачку значений, назначили хук». А теперь там программирование, причем на GOTO. Ты мне начинаешь ныть про императивность/декларативность языков. Ну и кто тут тролль?

У тебя проблемы с чтением. Я не спорил с тем, что язык фактически императивный. Я сказал, что это _провальная попытка_ создать декларативный язык.

Я сказал «по смыслу императивный». Т. е. совершенно непохоже, что правила udev вообще когда-либо задумывались как декларативный язык. Там ключевые, неотъемлемые конструкции уже требуют императивности.

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

ЩИТО? По именам чего именно они сортируются?

По собственным именам, внезапно.

По какому имени они упорядочены?

Это ты не умеешь читать, по ходу. :] Файлы правил сортируются по их собственным именам.

Прекрати выдавать свои домыслы за мои слова. Я не спорю с костыльностью goto в этих правилах, а лишь замечаю, что они ни разу не декларативные.

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

По какому имени они упорядочены?

Он сейчас о том, что в udev нет понятия «блока правил». Там нет AST. Там просто здоровенная куча последовательных правил в файлах, и эти файлы сортируются по именам.

-____-

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

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

Это ты не умеешь читать, по ходу. :] Файлы правил сортируются по их собственным именам.

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

То, что файлы сортируются по именам файлов, настолько очевидно

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

То, что файлы сортируются по именам файлов, настолько очевидно

Ну вот те же юниты, например, считываются в неопределённом порядке

У юнитов в начале имени файла и цифр нет.

Потому что они как раз декларативные, и порядок их обработки не имеет значения. В отличие от.

facepalm.jpg

Декларативные юниты с секциями Exec* - этапять. Язык юнитов еще более ублюдочен, чем язык udev.

У юнитов в начале имени файла и цифр нет.

Даже если бы были. В мане по udev явно сказано, что «all rules files are collectively sorted and processed in lexical order». В то время как юниты, я думаю, считываются в порядке readdir().

Декларативные юниты с секциями Exec* - этапять. Язык юнитов еще более ублюдочен, чем язык udev.

Ты о возможности указать несколько команд в ExecStart=/ExecStop= в oneshot-юнитах? Это не делает язык юнитов императивным.

У юнитов в начале имени файла и цифр нет.

Даже если бы были.

Но их нет.

Ты о возможности указать несколько команд в ExecStart=/ExecStop= в oneshot-юнитах? Это не делает язык юнитов императивным.

Т.е. сам юнит императивный, но его язык - декларативный. Окей.

Минуточку. Язык описания юнитов (который, неформально выражаясь, описывает, что должен делать инит) — совершенно декларативный. В нём есть императивные секции, которые описывают последовательность запуска внешних процессов в рамках одной неделимой с точки зрения инита операции.

Это не «императивность языка юнитов». Это shorthand для скрипта из нескольких команд, если хочешь. Внешняя по отношению к systemd конструкция.

Это же толксы, тут можно.

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