Василий Банников

Это разруливается не через DNS, а через балансировщик.
У тебя будет, получается, три узла: Основной, Резервный, и Балансер.
В DNS ты прописываешь балансер (через A/AAA или CNAME - не важно).
Все запросы от клиентов идут на Балансер и он их пересылает на основной.
В случае сбоя, Балансер каким-то образом выясняет состояние основного узла (может прямо запрашивать периодически какой-нибудь GET /health или смотреть на ответы, которые он даёт клиентам), и перераспределяет запросы на Резервный в случае, когда был выявлен сбой, и наоборот - в случае сбоя Резервного можно попробовать перенаправить запросы снова на Основной (тут уже как настроишь).

Попытаться обойтись без балансера можно, но тогда ты столкнёшся с той ситуацией, с которой ты столкнулся:

При коннекте к www.site1.ru провайдеры через раз подключаются к правильному айпи, то к основному, то к резервному.
Соответственно где то на сайт заходит, где то нет так как конектится ко 2 айпи который в текущий момент сервер не использует.

И уйти от этого не получиться, тк это не баг, а фича - DNS сервер провайдера будет кэшировть информацию о записях в твоём домене, чтобы не нагружать твой сервер лишними запросами и быстрее отдавать ответ своим абонентам, при этом при кэшировании может учитываться тот TTL, который ты сам указал.
+ Кэширование может, и скорее всего будет в том числе и на стороне конечного клиента.

Либо кабель некачественный, либо материнская плата/процессор не поддерживают 144гц в выбранном тобой разрешении

Процессор устарел - обновляйся.
Видимо Siemens NX нужны AVX-инструкции, которых нет в твоём атлоне.
"Пропатчить" невозможно.

Ну и встречный вопрос - зачем тебе Siemens NX?

1. 152 ФЗ распространяется только на операторов ПД.

2. Большинство требований 152 ФЗ идут не от использования какого-то "кошерного" ПО, а от введения различных регламентов и процедур на предприятии. Ведение различных журналов доступа к ПД, ограничение круга лиц, которые имеют к ПД доступ, введение ответственных за сохранность ПД, итд.

3. Есть куча провайдеров, которые предоставляют IaaS, сертифицированный по 152-ФЗ, но просто перенести свои сервера в него, это:
3.1. Дорого
3.2. Не достаточно
3.3. Не является безальтернативным вариантом - ты точно также можешь, в принципе, расположить в кладовке своего офиса стойку с сервером, и таким образом соблюсти требования ФЗ.

4. Не всегда нужно покупать за 200к лицензию на сертифицированный постгрес - до определённых уровней защиты это можно компенсировать процедурами и регламентами.

Если бы такая функция была, то что она должна была бы вернуть, если пользователь сидит одновременно с десктопа и с мобильного клиента?

Не меняется оно у тебя из-за того что поле объявлено как readonly:

private readonly Brick _controllableBrick;

Убери readonly и всё будет работать.

PS: Подобный код в тестах сильно снижает читабельность:

Brick controlledBrick = new(Vector3Int.up * 5, BrickPatterns.LBlock);

Убери сетап и пиши сразу так:

var controlledBrick = new Brick(new Vector3Int(0,5,0), BrickPatterns.LBlock);
var brickSpace = new(controlledBrick);
brickSpace.LowerControllableBrick();
Assert.AreEqual(new Vector3Int(0, 4, 0), _brickSpace.ControllableBlockPosition);

В сообщении об ошибке всегда указывается строка, на которой она возникла и подробное описание.

https://docs.python.org/3/tutorial/modules.html

rsync?

То что ты описываешь называется "языковая модель" - тема достаточно большая и очень сложная, если хочется получать что-то осмысленное.

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

Советую также почитать про IBM Chef Watson:
https://www.bonappetit.com/entertaining-style/tren...
Там вообще нет по сути никакого машинного обучения.

+ Ещё учитывай, что просто взять текст произвольной книги и использовать для обучения нейросети - это преступление

Слева - только Visual Studio
Справа - ещё и подписка на Azure Devops

Особенно там, где был использован язык Си или С++

(если исключить memory safety и fearless concurrency)
1. Хороших плюсовиков найти всё сложнее, ибо молодые разработчики часто хотят что-то более современное/простое/приятное.
2. Переход с какого-нибудь более высокоуровнего языка на Rust гораздо легче, чем на C++
3. DX у Rust на порядо лучше.
4. Код на Rust на порядок более выразительный, чем код на Си

За счёт этого поддержка кодовой базы на Rust заметно дешевле выходит

Например вот что Тинькофф пишет:

Наш Процессинговый Центр занимается разработкой финансовых систем, критичных к даунтайму и времени обработки. Изначально мы делали все свои продукты либо на чистом Си, либо на плюсах (C++14), однако пару лет назад мы переписали большой кусок нашего бэкенда на Rust, и нам настолько понравилось, что теперь все наши новые процессинговые сервисы пишутся на нём.

Мне бы хотелось видеть какое-то сравнение, что вот так стало сильно лучше и безопаснее, а вот было так написано изначально на оригинальном языке

Это можно будет определить только если ведётся статистика по багам и они классифицируются по причинам возникновения, но такую статистику ведут не все.
В среднем статистика показывает, что багов связанных с неправильной работой с памятью в проектах на Rust на порядки меньше, чем в проектах на C++.

ну тут все-равно unsafe

В проектах на Rust он явный и от него можно избавиться, завернув в безопасную обёртку, которая будет гарантировать корректную работу с памятью и ffi.
В проектах на C++ у тебя по факту всё является unsafe.

ну, нам еще нужен подсчет ссылок

В плюсах тоже активно пользуются подсчётом ссылок и всякими умными указателями, если по коду не очевидно, когда можно будет освободить память

Thunderbird + SMTP

и функционала фильтрации я там не видел,

Через SQL-запросы всё можно отфильтровать)

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

1. Заводишь какую-нибудь табличку для бан-листа, в которую записываешь идентификаторы каждого клиента, которые забанены. (Предварительно тебе бы следовало как-нибудь запомнить, что клиент с таким-то идентификатором от некоторого oidc-провайдера является таким-то пользователем в твоей системе.)

2. Вносишь его токен в чёрный список до тех пор, пока у токена не истечёт время жизни. (для списка таких токенов тоже следует завести табличку)

3. Естественно, во всех местах ты должен проверять, что токен не внесён в чёрный список, не отозван, и что сам пользователь не забанен. В случае провала такой проверки - кидай 403 код ошибки, а на фронте при получении такого кода - выводи какое-нибудь сообщение.

Напиши в саппорт и опиши свою ситуацию, что уже опробовал и убедился в применимости.