dim5x, я не знаю что это за "пример кода" и что там за "железо" и как рисуются эти "графики". Но так делать всё равно НЕЛЬЗЯ. Потому что в другой раз эта ошибка дорого обойдётся. Потому что именно семантически бесконечный цикл без полезных действий в любом случае целиком исполняется процессором. В любом языке. Это надо сразу же знать и никогда не делать.
Кстати, и первичную задачу лучще было бы сделать thread.join() на любом из запущенных тредов. Если они всё равно бесконечны - он никогда не завершится.
dim5x, бесконечный цикл безо всяких действий полностью исполняется процессором и считается в user time, все миллионы и миллиарды итераций. А sleep приводит к системному вызову и стоит около нуля user time - штучное количество тактов процессора в секунду. Фактически это возврат управления операционной системе.
Это реально так и работает. Я не раз видел, как люди допускали подобную ошибку. Например, делали "ничего не делающий" цикл в bash, который по факту всё же "что-то делал" и выжирал одно процессорное ядро подчистую.
Конечно, может зависеть от операционной системы и конкретной реализации. В DOS, например, даже sleep всегда является циклом, потому что процессор полностью в распоряжении программы, операционная система включается лишь по запросу или в результате аппаратных прерываний. Но мы же говорим о полноценных современных многозадачных операционных системах.
Bearer Auth по определению имеет такой формат. Тут скорее всего нужно кастомный класс написать. С fastapi только какую-то простую мелочь писал, но вот для requests пару раз делал нестандартные авторизации - там нужно класс с нужным интерфейсом сделать и его передавать вместо умолчального.
lisi4ka, ещё замечание: при SELECT не надо делать COMMIT, ведь изменений нет. Ну кроме случаев, когда в SELECT вызывается функция, которая что-то изменяет в базе.
Тем более на каждой итерации даже при изменении данных COMMIT смысла не надо делать, обычно делают весь цикл изменений или всю серию или часть изменений и затем COMMIT скопом. Как пример, когда делается массовая вставка в таблицу, то можно каждые 10000 записей делать COMMIT, но не на каждую запись - это лишь замедлит операцию.
ter56, так как приложение само записывает звук, то вряд ли. Скорее можно записать звук другим приложением, обработать его и отправить как файл. Но это уже не будет голосовуха.
Tech, добавлю, что для исключения раскрытия данных при наличии физического доступа надо все ключи закрывать пассфразами и использовать агенты (ssh-agent, gpg-agent). Если всё правильно сделать, ключи будут использоваться только на той машине, с которой залогинен, а дальше прокидываться по ssh. И секретный ключ можно держать на железном носителе типа yubikey (самый известный, есть и другие варианты). Да, это придётся поразбираться и повозиться. Да, yubikey стоит некоторых денег и его может быть сложнее купить в условиях санкций.
Лучше вынести секреты в отдельный файл, а его шифровать или gnupg, или ansible-vault. Приватный ключ для gnupg в любом случае не надо класть в git, а доставлять отдельным механизмом.
Для управления шифрованными файлами в целом можно использовать pass https://wiki.archlinux.org/title/Pass, который комбинирует gnupg и git для хранения шифрованных файлов с неплохим cli-интерфейсом.
Ну а вообще я бы посмотрел на готовые dotfiles-менеджеры типа yadm.
Из самого простого что-нибудь типа https://osmo.mobi
Даже в бесплатном варианте можно мониторить некоторое количество объектов, клиент osmodroid для смартфонов или iosmo для огрызков.
Также есть в разном другом софте возможность настроить и дёрнуть координаты по URL, например, в osmand.
В UNIX тоже обычно расшаривают через samba, так как nfs немного для другого предназначен, работает поверх rpcbind в локальной сети безо всякой авторизации (ну, kerberos можно навертеть, но это задача с десятком звёздочек) и работать будет только на UNIX-системах. На телефонах, например не годится.
Я у себя шарю через самбу и одновременно через nextcloud (как external storage: local). В итоге можно или через тот же vlc на телефонах смотреть/слушать видео/аудио, или прям в мобильном клиенте nextcloud даже не только в локалке, но с авторизацией.
system_sudo, подход django состоит в том, что только в отладочном режиме django обслуживает файлы (это накладно и блокирует django при запуске в runserver, который по определению однопоточный). Статику полагается перекладывать в отдельнй каталог из всех django-приложений (коих может быть много в большом проекте) с помощью manage.py collectstatic, а этот каталог нужно явно раздавать через веб-сервер мимо django. Для медиафайлов всё почти так же, только медиафайлы сразу же кладутся туда, где их будет забирать веб-сервер всё так же мимо django.
Код python без отступов - не код. В нём вообще ничё понять нельзя. Для оформления кода на панели есть предпоследняя кнопка, используй её, иначе никто даже вникать в вопрос не будет.
nedland, эта ссылка скорее всего на m3u-лист, и его не так надо качать, а достав из него список ссылок и склеив эти файлы в mpeg-ts, который потом лучше правильно обработать. И то, m3u поддерживает криптографию, при которой видеофайлы шифруются и всё это становится не так просто.
Всё это умеет youtube-dl, но его надо правильно готовить. Придётся сидеть и вникать. Я в своё время ломал anidub и некоторые другие сайты и таки справился.
1. Индекс, в котором хранится offset начала каждого диапазона записей для префикса ключа (диапазона ключей).
2. Индекс можно сделать в виде дерева, где иерархически ключ разделен на части. Например, ключ длины 4, 8, 12 адресует смещение и длину блока с записями с префиксом ключа такой длины.
3. Можно использовать хеширование ключа, но скорее всего не получится быстрее для отсортированных данных, ведь индексироваться будет каждая запись отдельно.
А дальше научиться как базы выбирать, когда эффективнее full scan файла, а когда - хождение по ключу.
Пример (на базах данных, для понимания):
Пусть у нас есть таблица с записями о платёжных операциях, в котором есть поле bank (текст, bank_id - неважно, просто есть). Тогда если выбирать из таблицы маленький банк (какой-нить Мухосранский Народный Банк), то поиск по индексу эффективнее: мы сходим в индекс (который меньше самой таблицы), получим немного смещений в основной таблице и вычитаем немного блоков с диска с данными. Если же выбрать Сбербанк, который упоминается в более чем 80% записей, то хождение по индексу будет означать, что мы всё равно вычитаем всю или почти всю таблицу, и обращения к индексу увеличат наши расходы больше, чем мы сэкономим. Поэтому у зрелых баз данных есть разные сложные оценки запросов, включая всяческую эвристику и накопленную по предыдущим запросам статистику.
Ну так вот, плясать с файлом в 10 Гб надо от того, какие именно действия с ним производятся. Если, например, нужно всё равно перебирать все записи - то всё равно придётся перебирать все, и ничего мудрить тут вообще не надо. Дисковый кэш в ОС всё сделает за нас, если читать мы будем последовательно хоть по байту, хоть по мегабайту.
Если же профиль конкретный действий сильно разный (иногда читаем всё, иногда одну запись), то может оказаться эффективным реализовать два разных алгоритма, один из которых будет использовать индексирование, а другой нет.
В целом записи по 20 байт слишком маленькие, чтобы индексировать каждую запись. Но так как данные отсортированы, то индексировать диапазон может быть приемлемо - особенно если грамотно выбрать длину диапазона.
Наконец, я бы попробовал рассмотреть вариант просто загрузить этот файл в полноценную базу данных и отдал бы всю мороку по оптимизации доступа ей. Возможно, это будет быстрее наколеночных решений.
Кстати, и первичную задачу лучще было бы сделать thread.join() на любом из запущенных тредов. Если они всё равно бесконечны - он никогда не завершится.