d-stream

Kiosk mode хватит?

Скорее всего малинка начнёт захлёбываться на работе с дисками. По крайней мере если будет сверх хранения версий ещё и ci/cd.
Ну а скармливать логи и артефакты сборки на быстрое хранилище S3 - а чего бы тогда не подсадить туда и сам gitlab? )

Из моей практики на x86 - 4..8vCPU и 7..8Гб ОЗУ и в силу специфики (огромные артефакты) - быстрые диски.

Ну и да - "диски" - это надёжная дисковая полка + регулярные бэкапы. Ибо система контроля версий - это сердце разработки.

Возможно это вначале покажется чутка избыточным, но по размышлению - нет:

master == прод
dev == ветка стабильной разработки, где живут более-менее целостные фичи
feature_xx == опять же целостная, самостоятельная фича, привносящая осмысленный функционал и состоящая возможно из множества задач

фичи отращиваются и возвращаются в ветку dev и их можно даже на уровне ветки протестировать
в какой-то момент от ветки dev отращивается ветка release (по-сути релиз-кандидат) и потом по выпуску (релизу) вливается в master и dev
go to 1

при таком подходе в dev живёт достаточно стабильное решение, а ветках feature - конкретные фичи, которые к моменту влития в dev - в общем-то тоже стабильны и функциональны.

ну и собственно релизный цикл получает некую "асинхронность" относительно цикла разработки:
- захотел релиз-менеджер к юбилею фирмы выпустить релиз - пожалуйста - в dev есть пачка фич
- накопилось осмысленное кол-во фич - вперёд в релиз
- оттестирована конкретная ожидаемая фича - в релиз (ну и попутно менее значимые)

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

С юзерскими правами (не админа) запись попадает а HKU, если запустить программу с правами администратора - она скорее всего сможет записать в HKLM

Шаг1 - магии нет. Переменная не может что-то делать. Так что потребуется класс с методами установки и чтения значения свойства. Вот в методе установки - можно выполнить и ещё что-то (вызвать функцию).
Шаг2 - более изящный вариант передавать классу того самого делегата которого надо дёрнуть, тем самым не помещая логику функции внутрь класcа, отвечающего за enum.

Организационные меры + что-нибудь типа sentinel hasp - в принципе наиболее сбалансированный комплект защиты.
Притом первая часть - немаловажная: клиент должен иметь существенные плюшки в виде поддержки и удовлетворения его хотелок, а вторая часть в виде допбонуса от пионеров.

абстрактно: HPE MSA 2062 с 16Gb FC или 25GbE фабриками и их фирменный MSA-DP+ RAID (сам умеет релоцировать холодное-горячее-тёплое)
но сейчас это окажется дорогим и неудобным в плане поддержки

Целый класс систем отчётов. Со всякими умениями переноса группировок, подбивок итого, среднего и т.п.
И естественно удобным юзерским интерфейсом.

В качестве привета травокуру: format x: /c /fs:ntfs /norepairlogs

по-секрету: у команды format есть волшебный ключик /?

Может банально jmeter?

Увы, но просто это не лечится. И даже сертификата окажется мало. На следующем этапе будет блочиться сама инсталляция.

Из практики:
- подписание софта
- подписание инсталлятора
- заливка "на проверку" к известным антивирусам - они в свои базы прописывают кс в вайтлисты

p.s. в своё время атол с драйверами страдал, даже заливая свои сигнатуры в ms - проверка, выкатка баз дефендера была медленнее чем изменения в законодательстве 54ФЗ и выпуск новых версий атоллом))

Концептуально: свой источник образов. Например проверенный безопасностью.
А хранить - есть разные варианты: Artifactory, Portus, Harbor, Docker Registry, Sonatype Nexus Repository Manager, Atomic Registry, Quay.io
Половина из них - умеет быть в том числе и проксёй

Можно сказать подавляющее большинство докеров работают на виртуалках.
Ну не практикуют сейчас bare metal варианты в общем случае.
То бишь стоит сервер с каким-нибудь гипервизором, а в гипервизоре крутится множество виртуалок, в каждой из которых докер...
Ну и да - на win10/11 вполне для поиграться поднимается не только docker desktop, но и в нём k3s, rancher и т.п. - этакий вариант пощупать кубера дома. Либо подходящая виртуализация - и там пускать linux в котором уже docker и далее.

Идеологически пакет - это сущность с конкретикой + список зависимостей.
А пакетный менеджер (nuget) - умеет добывать всю цепочку транзитивных зависимостей.
Главное чтобы они были в одном из доступных репозиториев.

А тех самых транзитивных зависимостей может быть немало. Да ещё каждая со спецификой делёжки на разные среды (netstandard, net.framework, dotnet и т.п.). То бишь в общем случае задача "создать пакет со всеми зависимостями" - сродни задаче "скачать весь интернет".

можно заглянуть в движки популярных форумов типа invision powerboard, phpbb и т.п.
там давно уже выстроилась "косоплечая" конструкция хранения html с тэгами bbcode в комментариях - чтобы при редактировании сообщения вернуть назад bbcode, а не чистый html

прям по любому мануалу nginx про балансировку
правда я невполне осилил изложение вопроса - видимо поэтому он помечен как "сложный"

можно тот же вопрос картинкой?