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

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 код ошибки, а на фронте при получении такого кода - выводи какое-нибудь сообщение.

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

Выглядит как ответ от какой-то CRM, в которой хотели запустить какую-то процедуру, но произошла ошибка.

Немного смущает наличие слов tcrm и имени m.ruchkin.

1. у тебя обращение к стримам завёрнуто в using - они могут быть уничтожены до того как копирование завершится.
Убери using var и сохраняй стримы вместе с таской. Диспозь уже после завершения таски
2. Кажется, тебе может быть интересен Parallel Linq.

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

Статья 1057 ГК РФ.

1. Лицо, объявившее публично о выплате денежного вознаграждения или выдаче иной награды (о выплате награды) за лучшее выполнение работы или достижение иных результатов (публичный конкурс), должно выплатить (выдать) обусловленную награду тому, кто в соответствии с условиями проведения конкурса признан его победителем.
   
2. Публичный конкурс должен быть направлен на достижение каких-либо общественно полезных целей.
   
3. Публичный конкурс может быть открытым, когда предложение организатора конкурса принять в нем участие обращено ко всем желающим путем объявления в печати или иных средствах массовой информации, либо закрытым, когда предложение принять участие в конкурсе направляется определенному кругу лиц по выбору организатора конкурса.
   
4. Открытый конкурс может быть обусловлен предварительной квалификацией его участников, когда организатором конкурса проводится предварительный отбор лиц, пожелавших принять в нем участие.
   
5. Объявление о публичном конкурсе должно содержать по крайней мере условия, предусматривающие существо задания, критерии и порядок оценки результатов работы или иных достижений, место, срок и порядок их представления, размер и форму награды, а также порядок и сроки объявления результатов конкурса.
   
6. К публичному конкурсу, содержащему обязательство заключить с победителем конкурса договор, правила, предусмотренные настоящей главой, применяются постольку, поскольку статьями 447 - 449 настоящего Кодекса не предусмотрено иное.