rPman

Смотрим исходники (как же там неудобно искать, проще было склонировать и найти в файлах)

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

Описание аргументов ,... это variadic т.е. можно несколько аргументов писать в вызове макроса, они все передадутся как есть (есть разные способы их развертывания)

Вот к примеру твой пример развернется в

static vnet_feature_arc_registration_t vnet_feat_arc_ip4_unicast;
static void __vnet_add_feature_arc_registration_ip4_unicast (void)
  __attribute__((__constructor__)) ;
static void __vnet_add_feature_arc_registration_ip4_unicast (void)
{
  vnet_feature_main_t * fm = &feature_main;
  vnet_feat_arc_ip4_unicast.next = fm->next_arc;
  fm->next_arc = & vnet_feat_arc_ip4_unicast;
}
static void __vnet_rm_feature_arc_registration_ip4_unicast (void)
  __attribute__((__destructor__)) ;
static void __vnet_rm_feature_arc_registration_ip4_unicast (void)
{
  vnet_feature_main_t * fm = &feature_main;
  vnet_feature_arc_registration_t *r = &vnet_feat_arc_ip4_unicast;
  VLIB_REMOVE_FROM_LINKED_LIST (fm->next_arc, r, next);
}
static vnet_feature_arc_registration_t vnet_feat_arc_ip4_unicast

Заметь что последняя строчка не завершена, нет ";", значит если после вызова этого макроса поставить = ... то пойдет определение значения переменной vnet_feat_arc_ip4_unicast
а запись через { .имя_поля=значение,...} это удобный способ инициализировать структуры

docker это linux. Для запуска на windows используется виртуальная машина, в случае с wsl она просто скрыта от пользователя, но она есть (используется майкрософтовский hyperv), в подавляющем большинстве случаев лучше установить полноценный linux в виртуалке и уже внутри настраивать docker (инструкции уже для linux выбранной версии будут).

Без поддержки аппаратной виртуализации будет очень медленно работать (примерно в 10 раз медленнее нативного).

VirtualBox умеет работать без аппаратной виртуализации, если загрузить ExpansionPack с офф сайта (бесплатно для личного использования)
kvm/qemu точно так же (собственно как я понимаю virtualbox его использует под капотом для этого)

Если машина не умеет виртуализацию, то либо она не включена в биосе (99% случаев, еще есть редкий случая, на машине стоит руткит вирус, лечить только загрузкой с usb/cdrom антивирус) либо машина ну очень древняя, и в добавок еще и не умеет 64bit (скорее всего).

p.s. Если windows 32-битный, то есть возможность запустить colinux, проект песочница (это user mode linux портированный под windows) который по факту не является виртуализацией, и в каких то задачах (там где меньше системных вызовов) будет работать быстрее софтварной и даже аппаратной виртуализации. Недостаток - проект не портирован для x64 архитектур и заброшен в 2015 году, я точно помню где то в 2019 я ставил в него ubuntu какую то lts, смотри последнюю, что поддерживала 32-бита, так же как я понял он утилизирует только одно ядро cpu плюс все лимиты 32-битности с памятью

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

upd. https://cdimage.ubuntu.com/ubuntu-mate/releases/18...
последняя официально поддерживала i386

сервера обновлений попробуй яндексовые mirror, типа так /etc/apt/sources.list

Лучше хуже - вопрос личного восприятия.

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

Забудем что принципиально хранить пароли - плохая практика, но так как задача уже такова что хранение вынужденное то:
1. шифровать логины и пароли (весь набор данных, не имеющих смысл друг без друга, лучше хранить сериализованными в одном поле, особенно когда от задачи к задачи поля меняются, т.е. логин пароль почта api key, gpg ключи шифрования и т.п. пусть это будет свободная json строчка, за ее анализ отвечает клиентская часть приложения)
2. ключом/паролем, который не хранится в базе данных (он должен являться частью бакэнда, т.е. в том месте где на бакэнде хранятся настройки подключения к внутренним сервисам либо отдельное место хранения) - при разделении работ между людьми (обслуживать базы могут другие люди, чем те кто имеет доступ к бакэнду) чувствительные данные не утекут легко.
3. логируй все, т.е. показал пароль - сохрани в специальном логе (в базе или файлах уже вопрос организации работ) - кто, когда, с какой машины, что получил
4. когда показываешь пароль на клиентской машине, повторно запрашивай авторизацию (чтобы не использовалась автосохраненная), важный момент, это исключит кражу данных уже на стороне клиента, очень мало кто правильно организует рабочее место (это просто неудобно и дорого).

POST это http?
Тебе нужен свой http сервер, реализующий нужную логику. Инструментов миллион, попробуй swoole
.
Если его реализовать без многопоточности и асинхоронщины, то пока он будет обрабатывать один запрос, никакой другой не будет получен, другие будут ждать в очереди сетевого стека и отваливаться с ошибкой по таймауту.

Интересно что встроенный отладочный http сервер php -S xxx:port какраз однопоточный, и хотя его не рекомендуют для продакшн, можешь попробовать.