mayton2019

Refactoring.

Подходит любая БД. Вопрос в том чем вы готовы пожертвовать ради скорости. Например вы можете хранить данные в backend (hashtable) и сбрасывать их в БД периодически. Эта схема идеально работает. Вам только надо с самим собой и с бизнесом поговорить о гарантиях. Что вы хотите? Чтоб любой вектор {id, data, user_date} сохранялся в ту-же микросекунду или вы можете эти изменения отложить на потом и применить их в БД через 15 минут например в виде
batch-update.

Поэтому вопрос оптимизации БД - это вопрос не только технически но и организационный. А запись в Postgress в через длинный сетевой стек да еще и с фиксацией транзакции это такое яростное безкомпромиссное решение
которое не всегда и нужно.

Договаривайтесь с ценностью бизнес-информацией и с компромиссами.

Тебе проще новую базу создавать каждый раз. Я так делал. А старая пускай лежит как бекап.
Создаешь db1, db2, db3.... Потом удаляешь которые уже не нужны.

Или в докере разворачиваешь если пустая нужна.

Тут ничего нельзя сказать пока не будет известно что это за устройство и каким образом ОС его видит.

Попробуй поищи его через

$ lsusb

$ lspci

$ lshw

Я знаю два сильных пути оптимизации в БД.

1) Минимизация IOps. Тоесть уменшить число дисковых чтений. Для таблиц это достигается через
partitions by date. Вычисляешь экспериментально оптимальный размер partition (например 1 неделя).
И твои запросы по диапазону должны попадать в 1-2 partitions. Это исключает full-table-scan.
Ну и индекс попробуй построить по предикатам фильтров.

2) Материализация ответов. Для данных которые уже не будут изменяться ты строишь где-то такую
табличку (матрицу по сути) где хранишь уже заранее расчитанные данные. Эта технология по разному
может называться. Materialized View. OLAP cubes. Витрины данных. Но суть одна.

start_date    end_date     result 
01-02-2023    03-02-2023   { "1":"65", "2":"45" }

И индекс по двум датам.

Сделай генерацию из двух частей. Подложку пускай сделает Midjourney.

А надпись сделай сам программно. Более простой и более контролируемый способ.

Когда говорят о таких высоко-технологичных отраслях то язык разработки обычно не имеет значения.
Лучше найди вообще доступные в open-source augment reallity libs и посмотри какой у них API.

Дописать до них вызовы API из Python это уже не science а обычная работа инженера. И тут главное - поставить
правильно цель. А идти от языка - это неправильная цель.

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

API позволяет взять ключ по имени.

Каждый хостинг-провайдер или платформа предоставляет такой сейф как услугу. Например для Microsoft
Azure Cloud это Key Vault. Для облака Амазон это AWS Secrets Manager.

Обычно корневая папка защищена от любого пользователя. Делай сначала каталог и давай права.

$ sudo mkdir /Test1
$ sudo chown endless:endless /Test1

И потом уже копируй или клонируй.

Есть два подхода.

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

Если изменение будет попадать в журналы - то они автоматом исправятся при старте. Насколько я помню ext4 хранит копии журналов в разных частях диска. Если изменения попадают внутрь тела файла то это мы не исправим никак. С точки зрения структуры ФС - все выглядит валидно. Структура - цела. Значит чекинг ничего не заметит.

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

UPD: Тут надо смотреть как собраны программные зеркала этой системы. Возможно исправить все таки можно но там будут куча условий. Целое дерево условие если это то это и так далее. Короче квест.

Вообще очень сильно зависит от цели задачи. И от чего мы пытаемся защититься. Если ты меняешь первый блок файловой.

Тоесть эксперимент похож на слепую стрельбу из пистолета в живого человека. Смотря куда попал. Если в башку - то смерть. Если там в мясо - то можно подлечить как-то.

Второй подход. Рассматривать обычный API файловой системы. Здесь можно просто проверить что будет когда inodes закончились. Ивестно что каждый файл (не hard-link) создает ровно 1 inode в таблице нодов. И эта таблица ограничена в ext3/ext4 кажется. Можно создавать миллионы файлов имеющих нулевой размер и мы постепенно заполним эту таблицу и получим какую-то ошибку. Эта ошибка технически имеет онлайн решение для XFS (там можно на ходу растягивать ФС и таблицы). Для ext3 нужно отмонтировать и что-то сделать в оффлайне.

Про коррапченые файлы мы уже говорили. Если это вопрос файловой системы - то она не видит ничего скорее всего. Рандомное изменение тела файла - это легальная операция файлового API. Увидит только софт который будет этот файл открывать. Например word документ не откроется. JPEG картинка может открыться наполовину. Будем видеть мозаику из поврежденных блоков начиная от места повреждения. Почти все файлы архивы перестануть распаковываться с места повреждения и до конца. Тоесть им
скорее всего смерть. Тестовые файлы - откроются но будем видеть "мусор" в месте повреждения.

А что здесь думать? Ты же не реализовываешь алгоритмы умножения и деления.
Ты - пользователь Питона. Вот и дели на Питоне и округляй.

Вот если бы ты реализовал 1/3 + 2/3 и получил бы точно единицу вот это было бы
интересно и познавательно.

Программирование в ООП предполагает что мир состоит из "объектов".
Например твоя программ (процесс) калькулятор это уже объект. Даже не имея декларации
она уже является объектом с точки зрения ОС.

Но если твой преподаватель - такой душный, то сделай

class Calculator {
   ...
}

Можно сделать объектом число и операцию над ним (унарная или бинарная) но это уже немотивированное
(или слабо мотивированное) действие. Теоретики ООП всегда пишут что введение объекта должно иметь смысл. Иначе так можно
дойти до абсурда и объявлять объектом любую чепуху, что только усложнит написание кода
и создаст бюрократию на пустом месте.

Поясни это преподавателю если он будет сильно настаивать на том что мало объектов.

Вот тут есть десяток проектов релевантных к Эфирам и Питону
https://ethereum.org/ru/developers/docs/programmin...

В классических языках программирования происходит обнуление переменных int, long.
Тоесть ошибки не будет но счетчик пойдет снова с нуля. Чтоб детектировать - надо
делать проверку условия на максимум.

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

В реальных приложениях такого лучше не допускать. Лучше не жадничать и вводить long счетчики.
Их хватит на тысячи лет как-бы вы там интенсивно не делали инкременты. В базах данных типа Oracle
NUMBER тип хранит 38 десятичных знаков числа. Надолго хватает. И я не слыхал чтоб у кого-то в обычном
режиме бизнес-транзакций эти счетчики переполнялись.

У Постгреса была проблема с 32 битными счетчиками XID. Не знаю как они ее порешали. Кажется
как-то они сбрасывают их для всей таблицы. Толи в вакууме толи еще как-то я не помню. Пускай
постгресщики скажут точнее.

Чтобы уйти от мелких счетчиков попробуйте использовать SnowflakeId (64bit) или GUID(128bit). Их надолго
хватает и никто не жаловался. Git использует 160-bit идентификаторы коммитов в графе коммитов
и тоже пока никто не жаловался.

С помощью реверс-инжинеринга наверное можно найти в бинарниках некие признаки того что
код был заимствован. Но это точно не задача для поисковой системы. Это если тебе только целенаправленно
в руки бинарь попал. А так... нельзя увидеть снаружи никак.

Если буквально переводить ошибку

In included file: unknown type name 'c_image'clang(unknown_typename)
window.hpp(24, 25): Error occurred here

То будет - во включаемом файле неизвестное имя типа c_image
и ошибка находится здесь window.hpp(24, 25)

Я устанавливал в таком порядке. Сначала windows а потом Linux. В этом случае у тебя есть возможность маневра. Если ставить наоборот то Windows убивал все что есть. Это было лет 10 назад. Как щас - не знаю. Может лучше.

Если тебе от ubuntu нужны только несколько утилит то попробуй под Windows использовать
WSL (Windows Substem for Linux). Обычно разработчикам и дата-инженерам этого достаточно
чтоб запускать какие-то утилиты или клиенты (azure(az), amazon(aws), gcp, databricks,
tools, converters, sql-clients e.t.c.)

Неопытный любитель может испортить технику разными способами. Пинцетом гнуть тоже надо умеючи.
Это опыт. И его с первого раза не получишь. Технику можно сжечь мощным паяльником или даже
статическим электричеством.

Ничего не делай. Отнеси в ремонт пускай там сделают. Когда речь касается чего-то стоящего - лучше
не экспериментировать.