Говнокодом должно считаться в первую очередь бездумное следование каким-то декларациям или практикам без понимания основ, которые за ними стоят. Да, как правило, использование global является признаком плохого кода и неудачного решения. Но в некоторых случаях небольшое количество использований global может быть оправдано и существенно упрощать код. Как правило, это несложные скрипты для решения своих собственных простых задач. В целом лучше обходиться без глобальных переменных, но не потому что так все говорят, а в результате понимания мотивов тех, кто это говорит.
Дело не в коммитах, а в том, что база открывается много раз, и операции при множественном доступе к базе конфликтуют. Правильно открывать базу один раз и commit делать на единственном экземпляре соединения. Ну или перейти на полноценную базу (mysql/mariadb, postgresql).
AlexaAioGram, call.message - это объект типа Message. Это не текст.
И вместо call.message надо вызывать call.message.answer('Сообщение') либо bot.send_message(call.message.chat.id, 'Сообщение'). Потому что call.message - объект, а не функция.
goodlike_by, пережатие в максимальном качестве вряд ли вытянет. На подобных устройствах приходится использовать возможности GPU для подобных задач, а это ограничивает возможность выбора кодеков и их параметров. Процессор там просто не вытянет - он очень медленный.
Далее, скорее всего, больше одного-двух потоков всё равно жать не получится - ресурсов не хватит. Я когда-то тестировал ретрансляцию видео с камеры (подключенной напрямую к плате шлейфом) на virt2real - это довольно слабая по меркам Pi платка - и там приходилось думать, какие параметры поставить, чтобы оно успевало единственный поток в realtime пережимать.
Я бы сказал, что Pi протянел в лучшем случае тупую ретрансляцию сырого потока без каких-либо действий с ним. И то, как уже выше сказали, проще купить NUC или ещё более дешёвый китайский баребон подобного класса, поставить на него Linux и делать все свои задачи.
Бессмысленное занятие - ловить по словам. Политика - слишком неопределённое понятие. Все выучат стоп-слова и будут спорить о политике без их использования.
Такие вещи правильнее модерировать, а не предотвращать на корню.
Сильно зависит от того, как реализован стек. Например, в некоторых реализациях в стеке реально один свитч главный, а остальные к нему slave, и настраивать нужно только главный.
waltaki, кстати да, с роутами... Если до конечной точки доходит оригинальный IP, то он по роутингу пойдёт мимо туннеля в обратную сторону. Тут уже будет упражнение на настройку policy routing.
WA призван не заменить, а дополнить JavaScript в браузере. Смиритесь.
Я знаю, и я боюсь, что с его приходом все вдруг поверять, что "это" работает быстро, и начнут клепать ЕЩЁ БОЛЬШЕ ПРИЛОЖЕНИЙ, которые захотят ЕЩЁ БОЛЬШЕ ПАМЯТИ.
Как ни банально это звучит, но можно сказать и так, что мир просто сошёл с ума :) Сейчас стало не интресно писать быстрые, эффективные и экономичные приложения. Памяти у всех должно быть много, и сожрать гигабайт-другой от неё для никчёмной функциональности очередной модной приложухи никого в наше время не смущает.
Я бы ещё мог понять, если бы это было для приложений, которые бы использовались для основной работы на текущем компьютере. В конце концов, можно смириться с тем, что фронтальное приложение потребляет значительную часть ресурсов. Беда в том, что все (реально, 100%) электронных приложений, с которыми мне доводилось иметь дело, были различными мессенджерами. То есть приложение, основная функция которого состоит в банальном обмене небольшими текстовыми сообщениями в параллельно запущенном с основной работой процессе, обязательно требует свой "законный" гигабайт оперативной памяти, по любому чиху глючит и по желанию левой пятки вытекает (в том числе даже и в своп). И всё это по причине острого нежелания писать нативный кроссплатформенный код. Типа пусть кроссплатформенным будет тяжёлый браузер с неповоротливым js-интерпретатором, юзер не развалится запускать эти браузеры пачками.
Великое счастье, что пока ещё не нужно подобные поделия ставить десятками, потому что подобных приложений пока ещё не так много. Но с учётом огромного количества недорогих js-разработчиков на рынке мы можем скоро придти и к этому. Мне слабо верится, что всякие WebAssembly как-то принципиально улучшат ситуацию. Скорее даже нет, просто все ломанутся ещё больше криво говнокодить приложухи и ещё больше съедать ресурс оперативной памяти пользователей.
zerx1, с syn flood лучше бороться с помощью более правильных инструментов, например, iptables. Такой скрипт на Python интересен разве что в образовательных целях.
aab137, как любили говорить в 90-х, "а кому сейчас легко?"
Конечно, надо изучать, как там всё устроено. Какие браузер делает запросы, какие у них параметры, откуда берутся... Если повезёт и устроено не очень сложно, то можно будет повторить, не изучая js-код, а лишь осознав логику используемого API. Но я бы не стал на это особенно сильно рассчитывать.
