#

Рабочий ли вариант если просто через rsync передать всю папку /var/lib/mysql?

Просто перенос файлов рабочей БД окончится тем, что файлы есть, а базы нет, потому что неоткуда взяться метаданным в системной базе данных. Вернее, всё ещё забавнее - базы вроде бы и нет (USE приводит к ошибке "БД не существует"), но её нельзя создать, потому что она есть. И то же самое с таблицами (SELECT/DROP/прочее нельзя, потому что таблицы нет, CREATE нельзя, потому что она есть).

Метод сработает, если переносить все БД сразу, включая служебные. Но требуется точное соответствие исходной и конечной конфигураций - начиная с версии и сборки MySQL и кончая именами каталогов и именами/паролями учётных записей в операционной системе. Плюс перегенерация и переподключение сертификатов.

Еще вариант с репликацией, но насколько я понял всё равно базу нужно блокировать на момент дампа, а это тоже какое-то время

Решений без блокирования практически не существует. Нет, можно наколхозить реальное решение, которое обойдётся вообще без остановки, я даже представляю как именно (FEDERATED ENGINE + triggers), но подробно рассказывать не буду - для её реализации нужны достаточная квалификация и опыт, на одних советах шанс на удачу невелик, скорее всё поломается.

Есть вполне себе документированные способы: Copying MySQL Databases to Another Machine. Особенно последний из описанных. Он предполагает минимальное время простоя при использовании штатных средств.

С минимальным простоем - да, репликация. Выключаете на старом месте, включаете на новом. Блокировать ничего не нужно.

В настройках сетевой карты есть галочка "извещать о состоянии", или что-то похожее по смыслу. Вот её надо отключить.

ну 100мб это "загрузчик", грубо говоря
последние 690мб - типо раздел восстановления теоретически, но он обычно меньше...
тут некуда диск С увеличивать, не двигая разделы

В порядке эксперимента, не используя Visual Studio вообще, создал форк проекта soleiledit на GitHub, и при помощи добавленного сценария GitHub Actions смог собрать выпуск v1.0.0 для древней версии проекта, использующей .NET 2.0, собрал под .NET 4.0. И всё это, используя лишь веб-браузер, аккаунт GitHub, ИИ ассистента и скудные знания о разработке на .NET восьмилетней давности.
Как это работает:
при создании нового выпуска запускается сценарий на серверах GitHub, который скачивает код с репозитория, собирает код (с MSBuild) на сервере Windows Server 2019 (установлена нужная версия .NET) и затем создаётся выпуск версии, затем упаковывается ZIP и прикрепляется к выпуску.

Любой желающий сможет зайти, скачать ZIP и запустить у себя на компьютере, при наличии необходимой установленной версии .NET .
Было ли это просто? Наверное, нет. Но не было ничего сложного. Надо было поставить серию экспериментов для достижения результата.

Аналогичным образом можно собрать проекты:
1. на C++ необходимо проверить какая используется сборочная система. Часто используется Autoconf (присутствует файл configure.ac). В сочетании со сборочной системой CMake (присутствует файл CMakeLists.txt). Вообще, в Readme обычно можно найти инструкции по сборке. А, порой - в разделе Wiki проекта. На примере проекта Tesseract: страница https://tesseract-ocr.github.io/tessdoc/Compiling.html содержит инструкции по самостоятельной сборке или на странице https://tesseract-ocr.github.io/tessdoc/Installati... можно скачать скомпилированный набор файлов.
2. на Python (нужной версии) обычно выполняется установка зависимостей с pip install -r requirements.txt, затем сама установка с python setup.py build.

Если пойти дальше, то такие средства, как Chocolatey, которые снимают нагрузку по разрешению задач, связанных с установкой разного ПО и имеют список ПО, которое можно установить одной командой. Пример: https://community.chocolatey.org/packages/tesseract

Скобки в делителе в переменной numerator пропустили.
Еще, у вас имена переменных кривые. Зачем-то назвали два множителя "числитель" и "делитель". Причем дробь целиком считается в первой.

Репозиторий проекта - это не что-то стандартное. Авторы вольны применять любые процессы и скрипты для сборки. Может когда-то какой-нибудь ЧатЖПТ и сможет "прочитать" ридми ЛЮБОГО проекта и проделать всё необходимое для его сборки, но пока что такой инструмент мало реалистичен. Если разработчик сам не настроил CI/CD в проекте, то никак без него это сейчас не сделать.

Клик сюда


Далее сюда


Подключаете .proto файл. После этого делает Rebuild вашего solution'а. Потом даблклик по проекту, в этом .csproj файле ищите секцию ItemGroup в которой будут ваши Protobuf. К ним додаёте аттрибут ProtoRoot, который (Для удобной работы) должен быть таким же как и пусть в аттрибуте Include без указания названия файла .proto

UPD:
Так же стоит отметить, чтобы импортировать в .proto ваш другой .proto, они должны быть хотя бы на одном уровне. Другими словами, вы можете импортировать только файлы, который находятся по архитектуре на том же уровне или ниже, потому что в import запрещено использования символа точки и запятой. Это значит, что вы не сможете выйти на уровень выше

Ну, это совсем просто. Чтобы держать биполярный ключ открытым, надо ему в базу загонять ток, всё время. Т.е. непрерывно тратить энергию, поскольку там есть замкнутая цепь для электрического тока (открытый эмиттерно-базовый PN-переход).
С полевым ключом принципиально не так. Управляющая цепь затвора - не замкнутая, поскольку между затвором и каналом есть изолирующая прослойка. Поэтому там ток не течёт, для открытия ключа достаточно подать напряжение, для закрытия - снять его. Электроэнергия на это практически не тратится (если не считать первый момент, когда заряжается затворная ёмкость). Вот и первое преимущество - экономичность в управлении.
Второе преимущество полевика - малое проходное сопротивление (единицы миллиом, много меньше, чем у биполярного, и в некоторых случаях даже меньше, чем у замкнутых контактов). Причём чем больше управляющее напряжение на затворе, тем проходное сопротивление меньше, соответственно и меньше нагрев полевика проходящим током. Однако не надо впадать в фанатизм на этом пути - если Uупр превысит значение 15 вольт, то изоляция затвора может быть пробита, и полевой ключ (такой удобный и простой в применении) превратится в тыкву.
Есть и другие отличия, которые проявляются только на высоких частотах.

- string _value = installPath.OpenSubKey(@"SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Death Stranding Directors Cut_is1").GetValue("InstallLocation")?.ToString() ?? "default";
+ string _value = installPath
+  .OpenSubKey(@"SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Death Stranding Directors Cut_is1")
+  ?.GetValue("InstallLocation")
+  ?.ToString()
+  ?? "default";

И ещё, вы уверены, что указали путь, вложенный в installPath? Выглядит как полный путь от корня реестра.