mayton2019

Мне не нравится сама идея тестирования базы.

Тестируют обычно бизнес логику. Слой Services, Processors e.t.c.

Если ваш язык программирования бизнес-логики это PL/SQL, T/SQL e.t.c. то я вам сочувствую.
Наверное в этом и есть главная причина ваших трудностей. Эти языки неудобно тестировать
и практики тестирования наподобие *Unit, *Property e.t.c. тестов там исторически не прижились.

Создание тестовой БД в таком случае - да. Это компромисс. Вот и двигайте в этом направлении.
Поднимайте все в контейнере типа docker.

Скорее всего эти режимы имеют большое значение для задач где есть CPU нагрузка.
Рендеринг. Майнинг. Какие-то вычислительные задачи с математикой. Поэтому
вы разницы и не замечаете. Вам надо нагрузить ноут.
И нагрузка должна быть длительной во времени.

Скорее всего эти режимы (Performance Mode (PM)) вступают в жесткое противостояние с технологиями
энергосбережения ноутбука. Как известно, ноутбук живет и существует от батареи только
благодаря тому что он что-то ограничивает и троттлит на длинных дистанциях. И если
вы соглашаетесь и с использованием PM то будьте готовы что батарея умрет раньше срока.

Да. Нормальная. Для сервисов.

Но если речь идет о микро-сервисах то считается что у них не должно быть единой точки
отказа. Тоесть они в некотором роде - независимы друг от друга. И если у них есть зависимость
в виде централизованной БД то тогда они все являются как-бы кусочками монолита. И тогда
идея микро-сервисности как-бы теряется.

Можно поднять порты мониторинга на всех приложениях и после деплоя просто проверять их доступность.
Если это база MySQL/PG - то к ней надо проверить коннект. И если это например SpringBoot application то там тоже
есть /healthcheck ендпоинт. Вот на него можно зайти и проверить.

Можно удвоить размеры листа и просто продублировать фотографию. Тогда и рамки не будет.
И печатать обычными средствами как раньше.

Можно попробовать все кадры видео проиндексировать. Как PHash.
И потом по этому индексу искать как текстовый поиск повторения.
Но это задача на разработку. Не на готовый софт.

Кажется можно решить через оконные функции. Посмотри как тут https://dev.mysql.com/doc/refman/8.0/en/window-fun...

Пригодится RANK или LEAD.

Может быть там 100500 мелких файлов и драйвер ФС перегружен транзакциями.
Попробуй поменять destination folder.

У меня был такой эффект когда я распаковывал mercurial репозиторий мозиллы на HDD/ZFS
диск. Был прогноз на много часов. Я поменял локацию на SDD/EXT4. Репо клонировался за 15 минут.

Intel vdt, Intel ppt, от Microsoft, Device Guard
Microsoft, Device Guard
Natural File Guard

Невозможно в рамках одного ответа ответить на все это сразу. Эти все технологии слишком разные
и слишком сложные по use-case.

Я соглашусь что скорее всего для домашнего пользователя они не нужны. Можете спокойно выключать.
По поводу Intel VD-t - это кажется опция виртуализации (улучшение работы Virtual Box)

Более полный список опций безопасности по Интел находится здесь
https://www.intel.com/content/www/us/en/security/h...

почитайте для общего развития. Я думаю что они в целом интересны безопасникам
в крупных организациях.

Если размерности известны. Например 120 на 30 на 200 на 40 то такой гипер-кубик
можно упаковать в обычный линейный массив. И он будет по длине равен 28800000 элементов.
Таким образом любой многомерный массив укладывается в одномерный.
Формула доступа будет достаточно простая. Почти тоже что и для матрицы.

Тоесть задача хранения - решена.

Это очень сложный вопрос и на него нет единого ответа.

Если ты ноут покупаешь например для игр - то иди в магазин и требуй тестов этой игры прям на ноуте.
Смотри визуально. Если - для серфинга в веб - то тоже самое.

Найти сочетание железок при которым и дешево и хорошо - практически невозможно.

Устанавливай Visual Studio Code + Azure Database Extension

Посмотри еще в Apache Thrift. Это не совсем RPC. Это скорее стандарт на универсальный
обмен информацией между разными языками и платформами. Но у него в качестве
примеров есть клиент-сервер на сокетах.

На нем также описан стандарт файлового формата Parquet для bigdata.

https://thrift.apache.org/

Обычно счет хранится в строго одной валюте. Если пользователь хочет оперировать разными
валютами то он заводит разные счета.

Здесь медленным является скорее всего вычисление функции S.

int S(int p, int q) {
    if (p == q) {
        return F(p);
    } else {
        return F(p) + S(p + 1, q);
    }
}

Вот для входных параметров p = 0 и q = 0xFFFF_FFFF например нам придется
вращать пустой цикл 4 миллиарда раз (или 4 млр раз проваливаться в рекурсию)
и все просто для того чтобы посчитать сумму

F(p) + F(q)

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

Я помню что в умных статьях, которые сравнивают алгоритмы сжатия типа JPEG/J2k/Lurawave
часто приводили параметр PSNR (Peak signal-to-noise ratio) и на базе него пытались
построить какие-то выводы. Период этих революций сжатия приходился примерно на 2000-е годы.

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

В случае когда картинок много и мы не можем определить где оригинал то я-бы предложил
смотреть спектры высоких частот. Где их больше - там и предположительно оригинал.
Если с изображением работали (scale, фильтры) то обычно метрика высоких частот будет
слабее выражена.

Вобщем сравнивать вам придется не по 1 параметру а по вектору. Увы-увы... в наше современное
время маш-обучения сравнение векторов это нормально. Так и должно быть.

Для некоторых задач разработки или работы с BigData можно использовать WSL
https://learn.microsoft.com/en-us/windows/wsl/install

Ситуация когда WSL с чем то у меня не справлялся - это обычно нехватка памяти или ядер CPU.
А так... пока изучаешь есть весь тулсет, компилляторы gcc/clang и языки Python/Perl/Ruby.

Еще из недостатков - некоторое усложнение маппинга файловой системы. Windows файлы
будут видны через виртуальный путь типа /mnt/c/....

Если формула твоего ГПСЧ будет простая (типа последовательности) и если злоумышленник
сможет отправлять свои открытые тексты то он выявит этот xor очень быстро.

Вообще Керхгофс писал о том что секретность должна быть на 100% перенесена в тело ключа а не
алгоритма. В этом - главный принцип криптографии. Мы исходим из предположения что злоумышленник
знает код. Он его видел. Он - бывший ваш сотрудник. И если он увольняется то он уходит со всеми
секретами в голове. И чтобы этого не было Керхгофс говорит - "окей мы не можем защитить код. Код - утекает
в пространство известной информации. Но мы можем сделать замену кода (КЛЮЧА!) настолько быстрой
и легкой что увольнение сотрудника не будет нам стоить очень дорого"

Уволился сотрудник который имел доступ к секретам - перегенерируй все секерты заново и спи спокойно.

Вернам - это бесконечно большой блокнот. Это не шифр, а скорее некая теоретическая концепция.
Под капотом Вернам может использовать xor или подстановки (что в принципе взаимозаменяемо
для известного алфавита).

С практической точки зрения (https/ssl/tls) удобнее использовать блочные шифры с временным
ключом который живет короткое время и потом генерируется заново.