Станислав Макаров

Нужно компилировать под DOS, а ты скомпилировал под Windows.
Каждая программа на Windows содержит в себе маленькую программу для DOS, которая выводит такое сообщение.

Скорее всего - тебе понадобится компилятор и среда разработки примерно из тех же годов, что и DOS

Модуль B использует данные из Модуля A

Что за данные?

смаке оперирует целями и зависимостями, а не данными.
Зависимости можно указать с помощью add_dependencies, подключить библиотеку с помощью target_link_libraries.
Если у вас в каком-то из модулей генерируются какие-то данные, то, видимо, там есть custom_target - укажите его в зависимостях вышележащего уровня.

И вообще, стоит ли так слепо следовать правилам из приведённой в начале статьи?

Разумеется не стоит. Делайте как того требует задача. Формат ошибок придумывать не надо. Мы например пришли к тому, что используем problemJson для ошибок.

Когда тебе понадобится зайти на белый IP из этой подсети, ты на него не попадешь, т.к. он будет искаться в первую очередь у тебя в локалке

.htaccess - это часть сервера, сфера ответственности команды эксплуатации
Обычно его создает/правит админ или бек-разработчик
Работает этот файл только с веб-сервером apache/httpd, к nginx отношения не имеет
Фронтенд-разработчики по идее никак с этим не связаны, это и близко не их сфера ответственности. Могут столкнуться, только если сами настраивают свое рабочее окружение и каким-то образом им помешал дефолтный .htaccess
Управление кешем с серверной стороны точно не относится к фронтенд-разработке

Тут подходит любая реляционная SQL БД потому что нет противопоказаний. Реляционку мы выбираем
уже более 30 лет как default вариант и почти не ошибаемся.

Когда задача имеет признаки ярко выраженной high-load системы - мы делаем ей частичную денормализацию
и раскладываем ее в NoSQL Key-Value решение. Но это не про улучшение а это про неизбежность. У нас нет выхода просто.
Иначе мы клиенту не сможем быстро отдать какой-то резуальтат.

Когда задача имеет ярко выраженную документную природу (нет спецификации на values) - мы берем MongoDb/CouchDb.

Когда задача хранит граф и ищет в графе и вообще требует графовых алгоритмов - то мы берем Neo4j или ей подобные.

Когда задача хранит данные измерений (телеметрия) - то предпочтительно взять InfluxDb или ей подобные. Здесь-же мы предполагаем что у нас - не будет joins а будет только измерения в диапазоне времени.

Но в данном ТЗ и на картинке обычная SQL БД (MySQL/Postgres) вполне себе нормально справляется.

Ну, на основной вопрос уже ответили, а я освещу отдельную проблему, которая очень часто волнует умы юных падаванов.

когда лучше реляционную и нереляционную использовать?

Ответ на этот вопрос очень простой.
Нереляционная БД - это НЕ база данных.
А узкоспециализированное хранилище, которое может выполнять какую-то одну определенную функцию лучше, чем база данных. Это может быть кэширующий демон, или поисковый движок, или решение для аналитики, или какое-то подсобное хранилище для всякого мусора.

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

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

Google: "lua ffi"

Это не про GIT/Gitlab. Это про программирование.

Процесс ресольва конфликтов - это абсолютно ручной процесс. Его нельзя автоматизировать. Просто береться
2 разработчика которые создали конфликт. Садятся рядышком и вместе обсуждает чьи изменения нужно
затянуть.

Что там сотворил GitLab - непонятно. Я не готов ничего сказать. Надо смотреть консоль команд которая форсируется самим приложением GitLab. Возможно они были неправильные. Или вы не так описываете
ситуацию.

Я ни разу не работал с git в команде и в крупных проектах, поэтому не знаю, что нужно делать.

Тебе и не нужно это знать. И мы не сможем перечислить все роли и задачи участников на проекте и все их возможные комбинации поэтому заранее рассказывать об этом бесполезно.

Git - это просто инструмент. Но как делается review или кто его делает. Или голосуют. Или мержат или ребейзят.
Или создают теги или бранчи. Или сколько делают осей разработки master/trunk, dev/stg/prod - это все частные договоренности. GitFlow, GitLabFlow. Интеграция Atlassian. С Gerrit. Это все-все частные случаи управления версиями кода на частных проектах. Нету общих рекомендаций.

Узнать их можно на проекте. Пришел. Прочитал Developers process guide. И начал работать.

А управление процессами разработки с помощью Git это большая и частная тема.

Поэтому оставь в покое крупные проекты. И лучше задай просто про git. Про команды git например.

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.