Станислав Некрасов

Вы хотите разложить на множители 1024бит число? за 20 минут?
https://ru.wikipedia.org/wiki/RSA-числа

RSA-240 имеет 240 десятичных знаков (795 бит) и было успешно факторизовано 2 декабря 2019 года Эмманюэлем Томе и его коллегами[6][7]. Для выполнения задачи было использовано несколько кластеров компьютеров в разных странах.

Макбуку не нужна мышка - там трекпад же классный.
Ну и если брать - то лучше g502, как по мне, ничего нет.

Список сообщений обновляется по факту, а не по таймауту, хотя всё зависит от клиента/сети и т. п.

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

100500 раз уже сказано, заплати 5$ за минимальный нормальный vps и не страдай фигней

Освоить базовый синтаксис русского языка.

Ошибка подчёркнута же в бэктрейсе, чего её искать? Что по вашему делает строка User(tg_id == tg_id)?

Потому что режим гарнитуры.
Исправить нельзя - это особенности bluetooth.

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

я не думаю что вам будет понятнее такой код:

класс ПростойКласс {
    приватно:
        свойство строка названиеПеременной
    публично конструктор (строка названиеПеременной) {
         контекст.названиеПеременной = названиеПеременной;
    }
    // ...
}

ПростойКласс[] массивКлассов = создать ПростойКласс[10];
пока (беззнаковое целое итератор = 0; итератор < 10; итератор++) {
    массивКлассов[итератор] = создать ПростойКласс("строка передаваемая в конструктор);
}

Вообще все эти понятия типа "функция может возвращать значение" (точнее наоборот, она обычно возвращает значение но может и не возвращать) родом из математики, и там никто не ноет что "почему все называют эти все штуки буквами греческого алфовита". Никто не кричит "почему синус принято обозначать sin а не син" и т.д.

Тут так же. Знание самого языка не поможет вам понять смысла конструкций типа for.

Обычный десктопный или веб калькулятор: от простой считалки до математического, инженерного или для программистов, как с простыми фичами, так и с более сложными: поддержка нескольких языков, тем и стилей, кроссплатформенности (win, mac, *nix, ios, android), истории вычислений, поддержка экзотических форм записи - стек с обратной польской записью, синхронизация и объединение между машинами (управление на телефоне/планшете/клавиатуре, экран - на мониторе ПК/планшете/другом телефоне), построение графиков 2D/3D и прочее. Разные платформы - dotNet, C++, Python, Web и т.п. Кому на что фантазии хватит - хоть до экселя встроенного. Главное - чтобы студентам было интересно. Можно даже на базе такого проекта диплом подготовить. Или, как вариант, взять все фичи, но разделить их на всех: сделать общий для всех проект - как для команды, что тоже будет очень полезным опытом. Можно даже взять реальный таск менеджер, в него завести все задачи проекта и провести всех студентов через реальный опыт работы в команде над общим проектом.

И возможно ли оттуда транслировать видеострим? смысл в том чтобы просчитать все на сервере и отдать клиенту видеострим.

Предлагаешь, чтобы на сервере стояла графическая карточка для каждого юзера?
Ну возьмем сервер,где играет 100-200 человек. Нужно 100-200 видеокарточек на сервере.
Хочешь 1000? 1000 карточек? Тут тупо на электричестве сервер разорится.

Далее. Каждый кадр нужно обработать, то есть одно дело, когда у тебя локально оно генерится и сразу в монитор. А тут нужно создать видеострим, а потом передать по инету.

Главное чтобы интернет был норм

Давай посчитаем как отдавать видеострим.
Берем например ну хотя бы hd 1920x1080x4 (2 млн цветов). Получаем 8294400 байт один кадр ( 8 мегабайт). Ты же хочешь нормальный фпс, ну хотя бы 50 в секунду, 400 мегабайт в секунду. на одного юзера.

Хочешь поговорить о крутом сжатии? Так вот, оно не работает на кадрах. Оно работает на стримах, когда можно проанализировать некоторое количество кадров и уже работать от них. Тогда надо решить вопрос сколько кадров мы будем удерживать для анализа и сжатия, перед тем как куда-то передавать. Игры типа контерстрайка, где 5-10 мс имеют значение сразу улетают в трубу. Сжатие может быть разным, в зависимости от того как резко меняется картинка, а неравномерность лагов хуже чем постоянный лаг. То есть надо решить еще и этот вопрос

То есть сжимать стрим на уровне кадров, если мы не можем их полноценно анализировать.
Нормальные современные кодеки умеют и в А-фреймы и Б-фреймы, то есть жмут в обе стороны. Плюс не ограничены во времени. А у нас и время поджимает, и генерация ограничена количеством кадров которые мы можем вместе использовать. В итоге сжатие будет не 90% как в современных видеокодеках, а хорошо если сожмет треть, и качество будет теряться. И трафик уменьшитсья ну до 50-100 мб/сек.
Теперь подумаем что у клиента отличный инет. А у сервера будет 50-100 мб/сек на КАЖДОГО игрока? Это какой канал должен быть у сервера для поддержания 100-200 игроков? А 1000?

В итоге твоя идея технически совершенно не рабочая.

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