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

В общем, чтобы не издеваться над девушкой, объясним на пальцах.

Во-первых, заголовок у вопроса чудовищно некорректный. Это все равно что спросить, "что быстрее - пылесос или стиральная машина?"
Во-вторых, ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там" совершенно очевиден: обработку данных следует производить в общем случае только в БД. Она для этого и придумана. Чтобы обрабатывать значительные объемы данных.

Да, js тоже "может" обрабатывать большие объемы данных.
Но чтобы значительный объем данных обработать, его сначала надо передать, полностью забив канал между сайтом и базой
Чтобы значительный объем данных обработать, его надо сначала проиндексировать. Причем делать это каждый раз, а не использовать уже имеющийся набор индексов
Чтобы значительный объем данных обработать, надо иметь значительный объем памяти или упасть из-за её недостатка
Чтобы значительный объем данных обработать в многопоточном режиме (а сайт как раз является многопоточной системой), все вышеперечисленное надо умножить на количество посетителей сайта - при каждом запросе перегонять весь массив данных, выделять память, индексировать, считать. Если же вы оставляете все данные в памяти приложения, то их тогда надо как-то синхронизировать с БД. То есть вы себе собираете кучу проблем на пустом месте.

Несомненно, из любого правила есть исключения. И бывают ситуации, когда приходится считать в приложении.
Но на вопрос в общем виде ответ будет совершенно однозначный. Не "может так, может сяк", а только в БД.

Из всего изученного стало понятно, что процессы - это некие "контейнеры", содержащие id, статус, instruction pointer, значение регистров, открытые файлы и другие данные контекста.

Вот уже по этому предложению видно, что понятно не стало. instruction pointer и значения регистров -- свои у каждого потока.

какую роль в планировании играют процессы?

Никакой.

Для чего они нужны?

Для учёта ресурсов и создания изолированных адресных пространств.

Как планировщик ОС работает с процессами?

Никак.

Моя единственная догадка в том, что планировщик как бы "заглядывает" в каждый процесс и уже там работает с потоками.

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

Я думаю можно. Поищи такие компилляторы как Watcom C, Borland C.
Они умеют генерить код для DOS. На ваткоме кажется была написана
игра Doom for DOS.

UPD +Линка www.openwatcom.org

Нужно компилировать под 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 например.