alexalexes

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

Под Rx570 - не менее 600 Вт в независимости от остальной комплектухи.
Расчетные 500...550 вам дадут запустить систему, но питание будет тухнуть через полчаса в 3D нагрузках.

Чтобы любую таблицу обложить историей изменения, нужно создать следующую обвязку:
1. Создать таблицу <название исходной таблицы>__history
Поля таблицы:
Первичный ключ - history_id,
Копируем названия полей исходной таблицы как есть (всем полям даете возможность быть null).
Делаем внешние ключи таблицы истории к исходной таблице (обычно id- исходной таблицы нужно привязать) и к другим таблицам, такие же как в исходной таблице, но опускаем ограничение уникальности ключей. Не используем каскадное обновление значение ключей.
Добавляете поле - вид операции над строкой исходной таблицы (вставка, обновление, удаление).
И самое главное, в таблице истории должно быть поле next_history_id - делаете по нему связанный список истории изменения одного поля. Как это поле работает? - см. пункт 2.
2. Создаете триггер/ы на события вставки, изменения, удаления для исходной таблицы в ней пишите тело со следующими действиями:
Читаете id тронутой событием записи из исходной таблицы.
Определяете history_id по данной id, где next_history_id is null - запоминаете в локальной переменной как before_history_id.
Если действие не удаление, то создаете запись в таблице истории из new-полей, которые пришли в insert/update для исходной таблицы, добавляете значение поля вида действия, next_history_id делаете null, получаете history_id этой вставленной записи - записываете в переменную new_history_id.
Если действие - удаление, то new поля вычитывать не нужно, нужно записать значение поля вида действия, next_history_id делаете null, получаете history_id этой вставленной записи - записываете в переменную new_history_id.
Делаете обновление поля next_history_id = new_history_id у записи истории со значением ключа before_history_id.
Тело триггера готово.
На любое действие в исходной таблице будет создаваться запись в истории, с указанием действия, а также будет формироваться цепочка изменений конкретной записи через атрибут next_history_id.
Чтобы вычитать последнее изменение по строчке исходной таблицы, нужно обратиться в таблицу истории по id от исходной таблицы и next_history_id is null.

Копию файлов всегда полезно делать в любой непонятной ситуации - вы это и сделайте.
А вот с восстановлением телефона лучше обратитесь к специалистам.

WITH RECURSIVE
-- Тестовая выборка. Если есть "живая" таблица, то эту выборку можно убрать  
 t as (select 10.000 value union
           select 10.001 union
           select 10.002 union
           select 10.003 union
           select 10.005 union
           select 10.009 -- специально добавил контр. пример
          ),
-- Таблица-генератор последовательности чисел от min(t.value) до max(t.value) с шагом 0.001 с помощью CTE (есть ограничение по глубине рекурсии!)
num_series AS (
  SELECT (select min(value) from t)  AS num
  UNION ALL
  SELECT num + 0.001 FROM num_series
   WHERE num < (select max(value) from t)
)
-- Запрос, в котором сопоставляем таблицу генератор и исходную таблицу, чтобы найти недостающие кванты
SELECT * 
  FROM num_series
 where not exists(select t.value from t where t.value = num_series.num)
     and num_series.num >= 10.000

PS: Нужен MySQL 8 версии и выше, postgres, или СУБД из интерпрайзного сегмента.

Да, до 4 Гбайт/с можно выжать из разъема M.2 этой материнки. Вы ограничены только возможностями данного SSD.

Также как если вы бы решали задачу на любом процедурном языке, имея в распоряжении только массивы или списки.
SQL вам просто дает удобный интерфейс для извлечения из хранилища смежных узлов или хорд, но алгоритмы обхода графа вы уже сами пишите процедурно.
CTE вам поможет, если обход предельно простой и залезет по объему памяти или времени выполнения.
Если нужен какой-то специфичный обход, то лучше это делать процедурно.
Если хотите писать не отходя от Posgres, то вам дорога в хранимые функции и процедуры.

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

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

Нет, ручками.
Копируете в тестовый каталог сервера картинки.
Копируете таблицу базы данных в тестовую таблицу.
В таблице создаете колонку любого типа, где будете ставить пометку, что запись обработали (картинка перемещена).
Берете ваш любимый PHP/Python/NodeJS.
Читаете по одной строчке табличку, где стоит атрибут, что картинка не обработана.
Копируете средствами скрипта файл из одного места в другое (не забываете, что по ходу углубления путей нужно прописать команды на создание подкаталогов).
Если копирование прошло успешно, то делаете update этой строчки - вставляете новое значение пути, и помечаете, что строчку обработали.
Пишите в файл лог обработки - какие строки обработали удачно, или пишите текст ошибки, если что-то пошло не так.
Когда потренируетесь на кошках, делайте тоже самое на боевых таблицах. Естественно, сделайте копию ресурсов всего сайта, даже если ваши действия не затрагивают их, на всякий случай.

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

-- Тестовая выборка
with t as (select to_date('2024-09-17 11:52:17', 'yyyy-mm-dd hh24:mi:ss') begin_date, to_date('2024-12-17 11:52:17', 'yyyy-mm-dd hh24:mi:ss') end_date, 3 Cnt from dual union
select to_date('2024-06-10 14:52:19', 'yyyy-mm-dd hh24:mi:ss') begin_date, to_date('2024-07-10 14:52:19', 'yyyy-mm-dd hh24:mi:ss') end_date, 1 Cnt from dual)
-- Иерархический запрос
select distinct T.*,
       add_Months(T.Begin_Date, Level - 1) as Current_Date, -- отсчет месяцев
       Level as Current_Val  -- текущее значение отсчета
  from T
  CONNECT BY add_Months(T.Begin_Date, Level) <= T.End_Date
order siblings by T.Begin_Date desc

В общем случае - только комбинаторикой. Играть с каждым словом в змейку и замораживать его в произвольной позиции. Если филворд не складывается, то изменять форму изгиба предыдущего слова. Перебрать все формы изгиба и начальной точки этого слова. Не получилось собрать филворд? Вернуться на предыдущее за предыдущим словом - покрутить его форму и начальную точку, покрутить следующее слово. Опять не получилось? Вернуться на 2 слова назад, опять тоже самое, но поменять следующие за ним слова местами.
Можно оптимизировать алгоритм, чтобы змейка не стремилась расти в область пустых клеток, а чаще старалась огибать уже существующие контуры, тогда вероятнее собрать филворд в кратчайшие сроки, но слова будут меньше перемешаны, это будет заметно на больших площадях доски.

suno.com
Загружаете свою минутную запись (upload audio).
На загруженной записи нажимаете extend, промт форма перейдет в режим custom.
Задаете текст песни и желаемый стиль музыки.
Готово, можно создавать трек.

Если повезет, то нейронка снабдит вашу композицию аккомпанементом из пары инструментов, добавит импровизации между куплетами, может даже посторонние шумы, типа аплодисментов зрительного зала.

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

Если в какой-то части выходного трека вам не понравилось как оно сгенерировалось, то можете сгенерировать еще попытку. Нейронка не повторяет результат по одним и тем же входным данным.
Если нужно похожий результат получить, то трек нужно загнать в extend и выставить время, где заканчивается куплет или припев, чтобы не сбить ритмический рисунок.

1) Создать таблицу cst_stat.
id
cst_id -- внешний ключ к cst
p_key -- значение ключа в JSON
p_value -- значение по ключу в JSON
2) Создать скрипт, который вычитает данные из таблицы, сдекодит JSON и запишет в cst_stat распарсенный JSON.
3) Создать уже привычный запрос с использованием таблиц cst и cst_stat.

select *
from cst

where exists( select *
                           from cst_stat
                               where cst.id = cst_stat.cst_id
                               and cst_stat.p_key = 5 and cst_stat.p_value = 1.5
) -- вариант поиска в JSON значения 5: 1.5

4) Переписать систему сбора статистики, чтобы записывался данные в нормализованном виде, без JSON.

Док-станция - вряд ли, а сетевые хранилища - пожалуйста.
Гуглите:
NAS <кол-во> дисков.