shurshur

Для начала, id - это число. Зачем хранить их в виде строк?

Далее, при отправке from_user.id сравнивается также со строкой. Конечно же, равенство строки и числа невозможно.

И, наконец, отправка должна идти по числовому id.

Надеюсь, все адмиины из массива нажали /start у бота? Без этого им сообщения отправлять будет нельзя.

Проверять id отправителя того сообщения и сравнивать с id текущего пользователя.

message.reply_to_message.from_user.id == message.from_user.id

Если совпадают то не повышать репутацию.

iptables -m owner -h

Маркируем пакет от пользователя (-j MARK) и затем policy routing (ip rule add fwmark XXX lookup vpn) перекидываем в другую таблицу маршрутизации.

Очевидно, что в файле prefixes.json не json, вот и ругается при попытке его прочитать как json.

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

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

Посылать команды может разве что юзербот, но их использование запрещено правилами Discord.

По умолчанию при монтировании файловой системы ставится флаг dirty (для тех, которые имеют поддержку такого флага, а обычные fs для Linux все имеют), а при размонтировании снимается. Если dirty не установлен, то fsck при простом запуске (без дополнительных параметров при запуске из командной строки или через флаг в fstab) не выполняет фактическую проверку файловой системы (точнее, всё же выполняет иногда - через определённое количество монтирований или по прошествии некоторого количества месяцев, но это отдельная настраиваемая история). Просто сразу пишет filesystem clean.

Если отмонтирование не выполнено корректно (например, система была перезагружена без завершения как надо или флешка была резко выдернута), то fsck будет пытаться восстановить файловую систему. При этом на файловых системах с журналированием это может быть сделано достаточно быстро с помощью replay journal. Если же восстановить легко не получилось, то система выкинет в Shell с предложением прогнать fsck самому. В принципе, если файловая система ещё не превратилась в мелко нашинкованные макароны, это может пройти весьма успешно даже с жёсткими флагами fsck -f -y. Но тут уж пользователь сам берёт на себя ответственность.

В общем, проверка файловой системы при запуске происходит по сложным правилам, в том числе на основе указанных в fstab параметров. Кроме того, с помощью fsck.*-параметров загрузки ядра (в данном слуаче через grub) можно явно попросить systemd изменить поведение по умолчанию и, например, принудительно проверить файловую систему, даже если она была отмонтирована корректно. Если эти параметры передать в загрузчик вручную через редактирование в самом grub при загрузке, то на последующие перезагрузки это изменение не повлияет.

Из lua можно вызывать код, написанный на C/C++. Соответственно, требуемый функционал оформляем в виде библиотеки, которую используем в скриптах.

Пока бот выполняет time.sleep, он ниего не делает. Нужно использовать либо треды, либо asyncio (с асинхронным же asyncio.sleep).

Потому что len(a) ситается в начале цикле и передаётся в range, который вызывается один раз и больше не вызывается повторно. Чтобы вызывался, надо вместо for использовать while с условием, а итерируемое значение явно увеличивать в каждой итерации цикла.

И в чат так же можно, если у бота есть доступ к написанию сообщений в группу и в качестве chat_id передан правильный id чата.