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

Логично. Но в любом случае это моя любимая кафешка рядос с домом, так что я к ним ещё зайду. Хорошие ребята там работают и вообще всё вкусно

А как в Белоруссии вообще с интернетом в среднем? Цены на кабель, мобильный интернет, какие тарифы?

В р-ке Беларусь.

Давайте потом что-нибудь расскажу на эту тему, когда проведу так сказать исследование рынка

В мане, процитированном @N0iseless , изложено описание инфраструктуры. Не в курсе сам, но похоже , что в openbsd аналогично все.

ebpf в openbsd нет. но какое-то средство запуска bpftrace программ есть.

Это реализация bpftrace. Это написано в мане. Что там под капотом, с этой точки зрения, не принципиально.

Нет, не принципиально. Тот факт, что при помощи ebpf можно писать практически любой код для ядра linux никак не компрометирует bpftrace. В линуксе bprftrace реализован средствами ebpf, в openbsd - через /dev/dt и какой-то сишный код в ядре.
=== Теперь вопросы.
Как связан jit и возможность запускать любой код? Если бы там  была VM без jit, как в обычном bpf - чем было бы лучше?
Почему иной подход к реализации интроспекции в openbsd должен иметь принципиально другие проблемы? (в настоящее время только потому, что нет паритета возможностей)
И в чём проблема в наличии ebpf? Я бы не отказался от него или функцимонального аналога. Не нужен - не включай, делов то. dt тоже по дефолту выключено и без ребута sysctl'ка не применится. Та же херня и с ebpf - не нужен - выпиливай.
Пользы от него всё равно намного больше, чем потенциального вреда от уязвимостей.

> Опрометчиво встраивать в ядро jit и позволять запускать код из пользовательского пространства, влияющий на ядро.
Да, также как и загружать неизвестный модуль ядра, например.
Если чел не понимает, что запускать недоверенный код - это проблема, наличие/отсутствие ebpf вообще ни на что не влияет.
Если ebpf не нужен - можно не включать его или не давать себе прав cap_sys_admin и т.п.
А тогда когда он нужен - он правда полезен.
Считаю истерику вокруг ebpf надуманной.

и jit, кстати, в ebpf выключается.

> Почему иной подход к реализации интроспекции в openbsd должен иметь принципиально другие проблемы?
Я, впрочем, повтыкал, кажется оно совсем убогое на фоне ebpf. За счёт этого проблемы оно правда будет иметь другие, скорее всего.

Откуда у злоумышленника CAP_SYS_ADMIN?

С ebpf в линукс скорее проблема в том, что там дух и атмосфера линукс, а не то, что он ко-ко-ко jit, кудах-тах-тах в ядре.
То, что kernel.unprivileged_bpf_disabled=1 они додумались сделать дефолтом только в 2017 году. Вот ЭТО проблема (была). А не сама идея и не то, что jit.

Насколько я помню, там были проблемы, которые позволяли непривилигированным пользователям запускать eBPF-приложения. Но это проблема самого линукс-вея, имхо. Утверждение: все приблуды для дебага системы в рантайме потенциально проблемы для безопасности. Как ptrace тот же. То, что обычный юзер может запустить считай модуль ядра - это проблема. То, что там jit - нет, не проблема, неинтересные детали реализации.

Жесткий махач

Модуль на каждый чих - дорого. Нужны адекватные дефолты и права доступа.

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

Особенно в openbsd, где модулей подгружаемых нет

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