shurshur

Да, это возможно, но придётся вместо Bot API использовать клиентский API (с протоколом MTProto). Тут наиболее распространены библиотека telethon для Python и официальная библиотека tdlib.

Вопрос уровня "в чём преимущества грибов над ягодами?" Это просто разные вещи со своими особенностями и нюансами, и нет смысла говорить о преимуществе одних или других без конкретного описания условий и требований.

На самом деле процесс и поток в реализации конкретной OS могут быть близки до такой степени, что потоки могут быть видны даже в списке процессов. Поэтому вполне можно сказать, что это практически одно и то же. Но не совсем.

Для создания нового процесса в UNIX-системах делаетя вызов fork, который создаёт полную копию текущего процесса, включая его код и данные (в других системах может не быть fork, но есть свои способы создания процесса). Для создания же нового потока также делается новый "процесс", но вместо копии данных и кода в нём передаётся ссылка на те же самые данные и код (очень по-питоновски - ссылка вместо deepcopy данных). Поэтому потоки могут работать с одними и теми же данными, а самостоятельные процессы нет. Но иногда это как раз и нужно. Например, потоки должны как-то отслеживать конфликты с доступом к одним и тем же данным, а для процессов такой проблемы не стоит.

Отдельно надо сказать, что понятие потоков и процессов в разных языках может быть реализовано не так, как это реализовано на уровне операционной системы. Например, JVM умеет делать потоки даже на системах без поддержки многозадачности. Она просто имитирует их внутри себя. Это же машина, виртуалка такая.

В Telegram Bot API нельзя получить список участников группы, только общее количество getChatMemberCount, список администраторов getChatAdministrators и информацию о конкретном участнике чата по заранее известному id пользователя getChatMember. Именно поэтому вагоны примеров в поисковиках в основном используют библиотеку telethon.

SET admin=Хелпер означает, что полю admin надо присвоить то же значение, что и у поля Хелпер. Но у нас нет в таблице никакого Хелпер.

Чтобы присвоить значение не по имени столбца, а конкретное значение, его надо обернуть в одинарные кавычки:

UPDATE profile SET admin='Хелпер' WHERE ...

Вообще, советую почитать элементарные основы SQL, тогда таких вопросов возникать не будет.

SELECT COUNT(DISTINCT category) FROM your_table_name

Очевидно, что если в цикле вызывать send_message, то будет отправлено столько сообщений, сколько итераций цикла. Надо собрать сообщение в одну переменную и затем одной операцией send_message его отправить. Примерно так:

message_text = ""
for res in cursor.fetchall():
    message_text += "{0} {1}".format(res[0], res[1]))
bot.send_message(..., message_text)

Для начала, 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 при загрузке, то на последующие перезагрузки это изменение не повлияет.