Автоматическая блокировка экрана в GNU/Linux

Не знаю, по мне так проще нажать хоткей, отходя от компа, чем не забыть взять с собой телефон.

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

ну в этом случае у bluetooth может хватить радиуса действия.
Вариант для тех у кого телефон постоянно на зарядке от компа контролировать наличие usb устройства.
Для ответа снял со шнура и комп залочился.

Да это понятно, просто я думал, если вы постоянно это используете, то уже сделали для себя надежный метод защиты от ложных срабатываний, но вы стало быть так и живете с парой внезапных блокировок в сутки :)

Простое увеличение параметра -c ничего не даст, т.к. при первой же потере пакета l2ping вывалится с exit code 1 и будет ложное срабатывание. Другое дело — на уровне скрипта проверять успешность нескольких проверок подряд и на основе этого принимать решение о блокировке.

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

если интересно, вот ссылка на репозиторий github.com/r00takaspin/paranoid/tree/dev

работает под mac os/linux, но пока много ложных срабатываний

Пришлось слегка попотеть, надеюсь она вам правда была нужна и вы не поверили мне на слово, не прогуглили сами.
Litepoint один из производителей чипов, в том числе блютус
www.litepoint.com/whitepaper/Bluetooth%20Low%20Energy_WhitePaper.pdf
Страница 3.
peak — десятки mA, idle — десятки nA
В качестве примера на странице 4 — пик 12.5 mA, порядка 12микро ампер за секунду передачи. Возьмем за эталон, хорошо?
Страница 5. Передачи на скорости 1mbit 8-27 октетов. Думаю имеется в виду передача данных, включая служебных, протокола bluetooth. Заметим и учтем что чип применяет AES.
Рассмотрим паке(8 стр) — 8 октет служебных данных и кадр 2-37 октета. (Причем 2 байта — заголовок)
Т.е 10 байт это минимальный overheat, причем его достаточно для поддержания соединения.
Страница 12 — картинка. Такую нагрузку дают стеки. В данном случае запрос ARP.

C блютус покончили, езернет(ваш пинг)
en.wikipedia.org/wiki/Ethernet_frame
В вашу пользу начальные и конечные данные я отброшу, наверняка их нет в итоге — блютус же давал начало фрейма.
6+6 маки, 2 тип запроса, CRC 4 байта. Причем скорее всего не отброшено, что бы считаться корректно для этой части.

— Что мы получаем
Пусть для bluetooth-keepalive будет проверка каждые 10 секунд(Sniff-subtracking). Получается в минуту 60 байт для передачи.
ping ethernet over bluetooth каждую минуту(однократный) это — 10+18 байт в одну сторону. Т.е 56 байт.

===Т.е для вашей ситуации передача выгоднее
Давайте решим задачку(О которой спор, и я оговорился там, 8 минут передачи менее эффективно). 8 часов пассивного соединения это 28.125 kb, на скорости 0.3Mbps(ухудшим ситуацию) это 65.918ms передачи данных.

С этим ок. По вашей ситуации:
В день вы передаете 61.523ms, что согласно приведенной таблице — 0.8 миллиампер в день на передачу, плюс шифрование (AES процессора), плюс операционка возбудится что ее пингуют. вобщем я оцениваю в 100mA расходы максимум(cpu, ram, шина бла бла). В моем же методе дальше чипа информация не проходит, а значит тратится в районе 1mA.

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

P.S нас рассудит эксперимент