Ross_F1, у телебота можно отключить треды (кажется, threaded=False в инициализации или в bot.polling, лень смотреть в документацию). Либо можно переместить всю работу с базой в отдельный тред и делать запросы только в нём. Есть даже готовые модули, которые реализуют такую прослойку, например, sqlite3worker.
Nertsan -, загрузчик мобильного устройства обычно ни с каких флешек даже не пытается. Тут скорее надо не инсталлятором пользоваться, а упражняться с debootstrap. Короче, это очень сложная затея, задача даже не со звёздочкой, а с десятью.
Я бы лучше рекомендовал купить Raspberry Pi или его аналоги, можно даже не самых новых ревизий, можно найти б/у недорого, например, я прям ща нашёл на авито RaspberryPI 2 за 1500 рублей в Москве, плюс несколько предложений за 2000. Это намного проще, чем страдать с кривыми проприетарными дровами и корявым загрузчиком.
Как вариант, может оказаться, что в месте установки этого радиуса уже есть роутер, который поддерживает установку openwrt, можно его перепрошить и установить сервер на нём. Или можно под это дело роутер обновить/заменить.
Кстати, старые роутеры тоже можно купить недорого, порой даже дешевле RPi, можно даже найти те, которые openwrt поддерживает идеально.
Greenberg2, меня алиэкспресс время от времени задалбывает (к счастью, стал реже, раньше мог каждые 10 минут пихать) и у Яндекса иногда начинает крышу сносить (у него как раз капча ща какая-то упоротая стала, попробуй найди символы, которые там нередко еле проглядываются). Плюс иногда зарубежные сайты технического характера кидают на cloudflare, в том числе такие, на которые я уже не раз ходил, но к счастью обычно без капчи.
Самое простое - взять рактически любой штатный логгер на линуксе, хоть rsyslog, настраиваем чтобы слушал сеть и на устройствах настроить логгирование в него. Самому логгеру настроить ротирование по вкусу либо штатными средствами (если у него они есть), либо через logrotate. Проще некуда.
Глубоко ТЕОРЕТИЧЕСКИ - да, может. Но надо понимать, что все домены НА САМОМ ДЕЛЕ на уровне DNS имеют точку в конце имени. И имя 123.123.123.123. (с точкой на конце) - не то же самое, что IP-адрес 123.123.123.123 (без точки).
Но главная беда в том, что софт будет понимать такие домены крайне ужасно. Например, без конечной точки сразу воспринимать их как IP. А с точкой на конце домены софт часто не понимает или удаляет эту точку - как и привыкли пользователи.
Мне кажется, имеет смысл рассмотреть предположение, что предыдущие неудачные выгрузки файлов задним числом всё же выполняется, но получаемый файл получается нулевой длины и затирает успещно загруженный... Правда, всё равно непонятно как...
Алексей Поваров, есть rsnapshot, который на базе rsync умеет делать дифференциальные и инкрементальные бэкапы. Но в реальности я бы смотрел в сторону чего-нить более серьёзного, типа borg.
Если просто делать наивно rsync, то да, в копии будет испорчено при очередной синхронизации.
Вообще, есть и такая стратегия, когда используется lsyncd, который держит почти моментальную копию дерева файлов в каталоге на втором сервере. Тогда даже промежуток времени между регулярными бэкапами будет закрыт - всегда будет актуальная или практически актуальная копия сайта.
Вариант - под систему или под раздел с данными подсунуть drbd с онлайн-репликацией - но это уже намного сложнее и чаще всего используется для виртуальных машин, причём лучше на "короткой" дистанции - типа два соседних сервера (можно даже подключить их по 10 Гбит/с или FibreChannel). И это умеют всякие proxmox из коробки. Но для виртуалки, купленной у хостера, это не особо годится.
Тынай Бакасов, если бот отправит двум разным пользователям или пользователь быстро отправит два разных сообщения - то вся нумерация легко поедет и удалиться может не то, что надо (в том числе у другого пользователя!). Я уж не говорю о том, что способ выдачи id может изменить телеграм на своей стороне, например, начать выдавать их с другим инкрементом или вообще без какой-либо монотонности. Если изначально соблюдать API как надо, то бот это без проблем переживёт и будет работать, а если нет...
Я могу пример привести из своей практики. Есть интеграция, в которой id выдают блоками по 1000 штук два независимых сервиса, один выдаёт нечётные, другой - чётные (чтобы не пересекались). Некоторые клиенты ошибочно думали, что id монотонны и всегда возрастают, но это не так: когда очередной блок берётся с другого генератора, чем в предыдущий раз, очередные id могут измениться в сторону снижения. Причём чем дольше длится интеграция, тем больше расхождение может накопиться (хотя в нормальной ситуации должно быть приблизительно поровну).
Причём это когда-то много лет назад было переделано из простых sequence в базе в рамках повышения отказоустойчивости. И это там реально работает. Так, при тормозах, кратковременной или полной недоступности базы основной функционал сервиса сохраняется. Причём он может так работать не один час, и такие аварии там несколько раз бывали.
Правильнее хранить предысторию, включающую все нужные id сообщений в рамках текущего активного диалога. В общем, если у бота не будет большой аудитории и нет высоких требований к его надёжности, то можно оставить и так, а чинить в случае если совсем припрёт. Ну и обязательно проверять вызов удаления на ошибки, чтобы бот не упал, если пользователь успеет сам своё сообщение и что-то пойдёт не так (тм)
PS: Я кстати был реально уверен что удалять бот чужие сообщения из личного чата не может. Но вероятно перепутал с редактированием - тут был кто-то, кто очень хотел ботом редактировать текст сообщения пользователя.
Можно поднять свой сервер LiberTranslate, можно осваивать всякие почти готовые решения типа EasyNMT, скачивать готовые обученные модели... Да, не супер качественно и не особо быстро без хорошей видеокарты, но зато очень недорого.
Также можно обратить внимание на то, что тексты на сайтах, вообще говоря, показываются далеко не один раз. И каждый раз их переводить не нужно, достаточно перевести один раз всё заранее или переводить конкретный текст в нужный язык при первом обращении. В зависимости от объёма сайта, это может очень существенно снизить общие затраты на перевод.
Вы о чём? Пользователь быстро поймёт, что у него shadow ban (а он это понять может легко, например, зайдя анонимно или с проверочного мульта). И как только он узнал, что так на сайте можно сделать, эта тактика против него перестанет работать окончательно.
Борьба с нежелательными регистрациями пользователей - это всегда компромисс между надёжностью защиты и неудобствами для пользователя.
Самое простое решение - перенести проблему множественной регистрации на тех, кто умеет с этим бороться лучше: на сотовых операторов (авторизация требует телефона и кода из SMS) или соцсети. Конечно, это не суперзащита, но заводить новый номер телефона или аккаунт в соцсети после каждого бана заметно сложнее, чем новую почту.
Можно заранее банить сети TOR и даже просто сети известных датацентров. Некоторые сайты так и делают. Да, это тоже не суперзащита, но опять же - сузит манёвренность нарушителя.
Можно сделать ограничения на начальном этапе. Например, первые три дня или первые 15 сообщений пользователь видит лишь часть разделов авторизованной области сайта, лимитирован в числе отправляемых сообщений в сутки итд. Усложнит регистрацию мультов - их придётся "прогревать", а за это время их можно будет обнаруживать и банить.
Ну а вообще если это вопрос общетеоретического характера, то можно давать общие советы, а если борьба с конкретным пользователем, то советы могут быть более целенаправленны. И, конечно, зависит от специфики сайта. То, что годится для форума, может не очень пригодиться для доски объявлений или сайта онлайн-курсов.
