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

Потому что режим гарнитуры.
Исправить нельзя - это особенности 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 игроков на одну серверную, а пару десятков тут, пару десятков там, спрос на него не слишком большой, поэтому и бизнесом этим мало кто занимается.
Отдельный плюс облачного гейминга бывает в том, что игры могут быть уже оплачены, и можно поиграть во что-то что лень себе покупать.

1 перетянуть ярлык в док
2 вызвать меню ярлыка в доке и выбрать "показать в finder"
3 из открывшегося окна перетянуть в корзину
4 удалить ярлык из дока

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

Ура, вы изобрели динамическую подгрузку локаций.
Предлагаю ещё обратить внимание на круглый такой объект, на который можно навесить ось и что-нибудь на ней возить. Не знаю, как называется, не изобрели ещё.

просто количество коммитов по пользователях
git shortlog -s -n

Вы генерируете перестановки по одной, пока не отсчитаете k. Это медленно, потому что k может быть очень большим. Перестановок-то n! - это дофига много.

Надо генерировать ее сразу по номеру.

Посмотрите на первый элемент. У первых (n-1)! перестановок там 1, у следующих (n-1)! - там 2, потом идет группа, начинающихся с 3 и т.д.

Уже вы можете понять в какой группе искомая k-ая перестановка. Тупо floor(k/(n-1)!) (если нумерация с 0 и перестановок и групп). Фактически, формула для первого элемента - a[0] = (k-1)/(n-1)! + 1.

Дальше вы можете выкинуть из рассмотрения первый элемент. Сфокусируйтесь на группе с заданным известным первым элементом. Какой номер искомая перестановка имеет среди этих (n-1)!? Надо из k вычесть количество перестановок c меньшими первыми элементами (их (a[0]-1)*(n-1)!. Потом задача сводится к преведущей - сгенерировать k-ую перестановку среди оставшихся n-1 элементов.

Если использовать какое-нибудь дерево отрезков, чтобы быстро искать j-ый пока не занятый элемент, то все решение будет за O(n log n). Если делать совсем просто - двумя циклами - то будет O(n^2). Гораздо быстрее вашего O(n!).

Надо только аккуратно обработать случаи, когда (n-1)! слишком большое. Фактически, вам надо найти максимальный факториал, который меньше k. Пока не спуститесь до этого момента нужно сразу брать первый незанятый элемент и не считать факториал вообще.

Решения два.
1) Использовать потоки
2) Не "прибавлять", и нагружать код постоянно. А лишь во время вызова, просчитывать на сколько увеличилась переменная простым алгоритмом.
(time.time() - Время последнего обновления данных) // 20 * 8 . Обновив при этом время последнего "апдейта"

Смотрите, у вас есть игрок и инструмент Топор, и вам нужно сделать что когда топор прикасался к дереву (с помощью анимации), то у дерева отнимались жизни и оно ломалось и давало ресурсы. Так понятно?

Окей, вот реальные системные требования:
процессор x86 с поддержкой асм-инструкций "длинющщий список инструкций", видеокарта с шейдерными конвейерами такой то реализации с такими то спеками (еще страница мелкого шрифта) и т.д.

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