>> Большинство датчиков не активны, пока не будет к ним обращения.
> Вот это совсем не факт. За все датчики расписываться как-то сильно шустро,
> не?Еще раз "Поэтому для них и не работает inotify.", для тех что обновляются сами можно получить событие через inotify.
>> Поэтому для них и не работает inotify.
> А с практической точки зрения - надо постоянно клевать датчик из программы,
> пробуждая программу и тыкаясь в датчик.
> Самое очевидное: free fall detector например явно работает всегда.
Значит и inotify для него работает.
> И да, а коньки как-то обрабатывают переход системы на батарею? Ну там
> скажем от адаптера - можно большинство датчиков 10 раз в секунду
> сканить, а от батареи - лучше раз в пару секунд.
Все зависит от вашей фантазии - вплоть до перехода на другой конфиг с отключением лишних показаний.
> Проблема скорее в том что проц не уходит на пониженные частоты/в глубокие
> режимы сна если кто-то дергается. И когда это хренадцать программ, читающих
> датчики всех мастей - получаеся "не очень".
> Грубо говоря, если 5 программ надо температуру проца, в обычном случае все
> 5 будут дергать датчик. А так один демон дернет датчие и
> раскидает всем 5 заинтересованным, по мере необходимости, что по идее эффективнее.
А если запущен только один conky и читает он датчики очень выборочно и не все параметры?
Сколько при этом раз демон дернет датчик за секунду? Пять программ могут дергать раз в секунду и только нужные параметры конкретных датчиков. Демону же придется рассчитывать на худшее и дергать 10-100 раз в секунду и все параметры.
>[оверквотинг удален]
> Так же как и со всеми остальными программами. За системные - отвечают
> QA которые тестировали релиз. Апликухи которые поставил юзерь ... для них
> это в общем случае скорее информативный сигнал. Ну то-есть они могут
> скажем корректно свернуть сетевую активность, если хотят, зная что сейчас сеть
> пропадет. А не хотят - активность зарубится как получится. Когда системный
> компонент пойдет и потушит сетевой интерфейс.
> Зато все это рулится одной кнопой из гуя - offline mode. Или
> скриптом - одно сообщение по dbus. Удобно. Одно логически сгруппированное действо
> - одним действием с системой, с минимальным шансом сделать что-то не
> так. И минимально необходимыми знаниями - "хочу самолетный режим".
Ну а сеть чем вы настраиваете? Логичнее поместить этот режим как один из профилей настройки сети.
> Программе или
> скрипту "кнопочка самолетного режима" нафиг не упало знать скажем полный список
> сетевых и-фейсов и как их правильно потушить. D-bus это обеспечивает.
>> и действительно перестанут использовать радио связь?
> Это будет чуть иначе: системные компоненты потенциально заинтересованные в сообщении подпишутся
> на него заранее. А получив его - пойдут да вырубят радио
> на "своих" железках. Отправителю сообщения вообще не надо знать кто и
> как это будет делать, ему надо только запросить самолетный режим. Остальное
> не его сложности. Элементарное разделение труда.
Вот именно - это должно быть в сетевом конфигураторе. А не в каждом сетевом приложении.
> И да, вы можете предложить решение лучше? Чтобы было столь же просто
> для инициатора?
Инициатор - пользователь? Кнопку в конфигураторе или опцию если конфигуратор консольный. И можно обойтись без сообщений, их обработки и демонов.
>> ИМХО единственный надежный вариант - запрет связи на уровне драйвера,
> Ну то-есть вы хотите сказать нам что kdbus очень нужен и полезен?
> :)
У программы под рутом и так хватит привилегий для этого.
>> и то если это не usb-wifi (со своей ОС) который может
>> сам начать проверять обновления.
> Большинство usb-свистков таки относительно простые штуки. А то что вы имеете в
> виду - это извините мобильные роутеры и прочие, а не свистки.
ХЗ все виданные мной huawei за последние лет пять именно такие. Даже если прикидываются обычным ppp.
> Самостоятельные (!!!!) компьютеры. Это такой намек что d-bus надо еще сетевое
> межсистемное конективити по хорошему, чтобы и такие штуки были в курсе
> что им надо заткнуться? :)
Не поможет :) Всегда найдется тот, кто прикинется что ничего не знает и знать не желает.
> А еще в идеале неплохо бы
> после предупреждения снять питание с девайса. На всякий. И питание экономится,
> и что-то там обновлять девайс в общем случае не сможет :)
Вот это верно, давно нужно унифицировать возможность отключать отдельные usb порты.
