rPman

Не путай размер дистрибутива и размер установленной системы на диске

Дистрибутив на установочном livecd/liveusb диске это минимально рабочий (или специально подобранный для типового пользователя) набор пакетов, чтобы минимизировать запросы к серверам репозитариев мейнтейнера, а вот их размер почти у любого дистрибутива - десятки гигабайт.

Например одно время ubuntu server альтернативно можно было установить, загрузившись в примерно 100-200мб iso образ, с установщиком, который с удобным текстовым интерфейсом устанавливал абсолютно все пакеты по сети из репозитария..

Место, занимаемое установленной ОС зависит не от выбора мейнтейнера, а от выбора софта, который тебе нужен. Что бы ты не выбрал, пример - если тебе нужно ставить пакеты для разработки нейронных сетей (tensorflow) на nvidia gpu, то качать тебе минимум 5 гигабайт всего что с этим связано (а то и больше).

Единственный известный мне дистрибутив (с большим комунити), дающий наибольший контроль над устанавливаемыми компонентами - это gentoo. Он не спроста компилирует каждый пакет под пользовательские настройки, в нем с помощью тех же USE флагов определяются не только возможности но и зависимости, которые потянут за собой устанавливаемые пакеты.

К сожалению, юзерфрендли его не назовешь, так как поддержка обновлений своего конфига это достаточно тяжелый труд (хоть и предоставлена куча удобных инструментов), который если запустить на год другой, может сильно усложнить дальнейшее обновление системы, вплоть до ее полной переустановки (по крайней мере так было с 5-10 лет назад). Придется изучать и разбираться почти во всем, что ты используешь. С gentoo именно ты являешься мейнтейнером своего дистрибутива.

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

Вроде бы openvino может работать без tensorflow (и скорее всего умеет работать с intel ускорителями), вот пример их модели распознавания эмоций

Все зависит от плеера, у каждого свои механизмы

Например у mpv (потомка mplayer) есть возможность управлять им, симулируя нажатия на кнопки (как я помню через stdin пайпом от своего приложения) и используя плейлист через пайп или тот же stdin, формируя его на лету своим приложением

по нормальному mpv поддерживает скриптовые плагины на lua, есть плагин mpv-network-commands так что любое поведение можно запрограммировать

Попробуй переименовать файл
git mv -f hello.cs Hello.cs
если он не будет давать это сделать на твоем текущем репозитарии, переименуй файл сначала обычными средствами файловой системы в hello.cs а потом с помощью git-mv

Не воспринимайте мой ответ как верный, но как повод задуматься.

Так как современный общий искусственный интеллект на основе LLM - это хороший слепок человеческого сознания, притом коллективного и в какой то степени бессознательного, вполне возможно что очень важными областями знаний для работы с этим ИИ (использование, оптимизация, исправление) могут оказаться такие очень не IT-шные знания как человеческая психология и внезапно лингвистика, литература, философия...

При создании современного ИИ так же используются знания из огромного количества областей, и технические знания становятся все более незначительными (но само собой обязательными). Как минимум команда разметчиков данных (тот же RLHF) должны быть сильно эрудированными и достаточно интеллектуальными, чтобы повлиять на создаваемый интеллект наиболее качественно (из того что публиковали команда OpenAI, речь идет об очень сложных вопросах, касающихся любых областей знаний, в ответах на которые нужно искать ошибки и выдавать верные ответы)

Слетает файловая система - почти наверняка извлечение из usb происходит без предварительного выбора пункта меню в трее - безопасное извлечение накопителя. Так же можно в свойствах диска найти в вкладку устройства и отключить стратегию кеширования записи, это замедлит работу с мелкими файлами но даст гарантию, что если приложение закончило писать файл, то флешку можно извлекать безопасно (точнее меньше шансов получить нарушение файловой системы).

usb flash самый ненадежный носитель данных, из-за того что в него вставляют не очень умный контроллер, у нее хуже охлаждение и в ней скорее всего используют дешевую память. У меня есть пример несколько флешек (от дешевых и старых до midend usb3) которые от лежания в ящике стола чуть больше года перестали работать (а одна теперь работает только в usb2 разъемах)

Cледующий по ненадежности накопитель - ssd, это та же флешка но с умным контроллером, с немного лучшим охлаждением и можно найти на рынке чуть повыше надежность (обычно дорогие модели) где производитель об этом задумался. Их так же рекомендуется периодически подключать к компьютеру чтобы контроллер оптимизировал размещение данных и они так же боятся жары (оставить флешку на солнце почти гарантированная ее смерть).

Самый наименее ненадежный накопитель - hdd с низкими скоростями вращения шпинделя и не самыми современными техпроцессами (низкая емкость), настоятельно рекомендую не брать диски больше 1Тб для такой задачи, по крайней мере после преодоления 1Тб накопители стали чаще выходить из строя (возможно это проблема не технологии а сноса крыши у производителей, которым никто не запрещает по максимуму эксплуатировать запланированное устаревание)

Напоминаю, вероятность выхода из строя hdd диска среднего ценового диапазона гуляет вокруг 1.5% за первые 5 лет, и максимум выпадает на первый год работы. Какая-нибудь дешевая 3Тб тошиба будет выходить из строя с вероятностью в 7% (личное наблюдение). Вероятность выхода из строя диска, который постоянно включают и выключают - значительно выше (в разы).

Всякие экзотические средства типа компакт диски или магнитные вообще самые ненадежные или создающие иные проблемы. Кто то тут вспомнит про перфокарты или лучше печать qr-кода в т.ч. в металле, да это надежно но не подходит для 99% целей хранения. Если бы технологию записи данных в кварцевом стекле делали бы не майкрософт, была бы на них надежда что они будут доступны потребителю, но увы.

Хранить данные в одной копии - лучший способ их потерять. Настоятельно рекомендую делать резервную копию.

Ввести как константу в исходниках? самое простое base64 encoding
base64.b64decode('твоя base64 строка')

а сам исходный файл кодируй либо какой либо утилитой либо онлайн либо напиши программу на python в 3 строчки
-------------

есть утилита xxd, она преобразует файл в набор 16-ричных цифр, добавить к ним \x и заключить в ковычки b'\x...' получишь свою строку

-----------

chatgpt сгенерировал такую программу, чтобы сделать это самому да еще и печатные символы в код не преобразовывать, выглядит вроде верным кодом

import string

# Откройте файл в режиме чтения байтов и прочитайте его содержимое
with open('your_file', 'rb') as f:
    byte_content = f.read()

# Преобразуйте байты в строку байтов
byte_string = ''
for b in byte_content:
    if chr(b) in string.printable and b not in (0x0a, 0x0d):  # Проверка, является ли символ печатным и не является ли он символом новой строки или возврата каретки
        byte_string += chr(b)
    else:
        byte_string += '\\x{:02x}'.format(b)

# Выведите строку байтов
print(byte_string)

проверять работоспособность бакапов

p.s. интервал времени между бакапами так же нужно согласовать с веяниями бизнеса, так как это определит, как много информации ты потеряешь при ее восстановлении, и вдруг сутки это слишком больно и нужно делать чаще

p.p.s. мегаоперативный бакап это репликация (не заменяет обычный так как не защищает например от ошибки пользователя сделавшего delete * from data) с рабочими скриптами превращения резервной ноды в оперативную, тогда смерть базы от аппаратных проблем (например пожар или кража) не остановят бизнес

tesseract может это распознать (шрифт ему знаком) но у него проблемы с таблицами, он все сливает в один сплошной текст (да корявый)

если можешь в своем коде разобрать кадр на строки то можно на питоне быстренько написать приложение которое будет эти кусочки отправлять на распознавание, но или вот первая попавшаяся статья с примерами