4X_Pro

Я придерживаюсь мнения, что один из признаков технически хорошо сделанного сайта — неотличимость снаружи от сайта на статике (даже если на самом деле всё работает на супернавороченной CMS). Поэтому на этапе создания страницы смотрим, будут ли у неё дочерние элементы. Если нет, то делаем с расширением .htm или .html, если могут, то с / на конце.
Пожалуй, самая большая разница, которую нужно учитывать — это формирование относительных ссылок. В случае, если на странице с URL /razdel/tema мы сделаем относительную ссылку second-page, то она будет вести на /razdel/second-page (что нелогично, так как это шаг на уровень выше), а если на странице, у которой URL -- /razdel/tema/, то на /razdel/tema/second-page.
Исключение — это идентификаторы GUID во всяких REST API, которые пользователь никогда в адресной строке не увидит, и где данные отдаются в JSON или XML, там лучше обойтись без / просто ради экономии траффика.

Я так понимаю, дело под Windows происходит? Попробуйте перед запуском из командной строки сначала выполнить set NODE_OPTIONS=--openssl-legacy-provider. Это включит поддержку устаревших хеш-функций, из-за отсутствия которых, по всей видимости, проект и не работает.

Скорее всего, дело в приоритетах правил CSS. Нужно зайти в DevTools, выбрать нужный элемент и посмотреть на вкладке «Стили» справа (по крайней мере, в Chrome она справа), какие CSS-правила оказываются более приоритетными (они будут выше в списке). Ну и если CSS во внешнем файле, то проверить, что подгружается новая версия, а не берётся из кеша старая.

Второе ядро даст незначительный прирост в плане параллельного выполнения потоков ядра операционой системы и других процессов (коих даже на «голом» Linuxе висит несколько десятков), от третьего и последующих в описанных условиях толку никакого не будет.
В остальном же всё зависит от нагрузки. Если она небольшая (1-2 обращений в секунду и нет сложных вычислений типа нейронных сетей), то одного ядра хватит спокойно. Например, у меня два бота висят на одноядерном VDS, и на нём же крутится MySQL с базой для одного из них, и всё вполне нормально работает, причём один из ботов постоянно устанавливает исходящие запросы (выполняет мониторинг сайтов). Правда, боты написаны на PHP+Go, а не Python. Но к этим ботам всего всего несколько тысяч обращений в сутки.

Да, всё верно, это происходит, если добавлять стили через JavaScript с помощью конструкций вида

var sheet = window.document.styleSheets[0];
sheet.insertRule('.container { width: 100%; margin: 8px auto }', sheet.cssRules.length);

Подробнее — см. в MDN: https://developer.mozilla.org/en-US/docs/Web/API/C...

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

Судя по всему, проблема в том, что MySQL начинает не успевать перестраивать индексы.
Сразу возникает вопрос: status, type, provider — это ENUMы или VARCHARы? Если второе, то можно ли заменить их на ENUM? Если нет, то можно попробовать делать индекс не по полному полю, а по его ограниченной длине, например, Task ( status(4), type(8), provider(4), cat ). В этом случае индексы будут перестраиваться быстрее.
Другой вариант вариант — сделать дополнительное численное поле, которое будет хешем от строкового значения, и делать выборку по нему. Можно использовать даже самую обычную CRC32 и сравнивать так WHERE status_crc=CRC32('active') AND type_crc=CRC32('follow_profile'). Соответственно, индексы делать не по status и type, а по status_crc и type_crc (по численным полям индексы строятся быстрее, чем по строковым).
Ещё вариант — сделать в своём коде возможность буферизовать и накапливать накапливать какое-то количество INSERTов, после чего делать DISABLE KEYS, выполнять накопившиеся INSERT, затем ENABLE KEYS.

Если для работы сервера нужно пробросить один-два порта, то да, такое вполне возможно с помощью SSH-туннелирования (ssh tunneling).

Это называется «угадайте, plugin для чего имел в виду автор».
По существу — без всяких plugins помогут HTML-атрибуты pattern и required. В pattern нужно прописать регулярное выражение для проверки. А чтобы менять класс формы, нужно навесить на inputы обработчики события invalid. То есть получится что-то вроде:

<input class="g-input modal-form__input" data-validate-field="tel" type="tel" name="Телефон" placeholder="Ваш телефон" inputmode="text" required pattern="+[0-9]{10,12}" oninvalid="this.form.classList.add('error-class')">

Обычные сайты-конструкторы — нет. В англоязычном Интернете есть несколько проектов, предоставляющих на платной основе платформы с функционалом для соцсетей. (В Рунете ничего подобного не видел.) Но это — плохой вариант, который уместен только в том случае, если запустить сеть нужно очень срочно и с обычным функционалом, без добавления чего-то своего.
Если же делать нормально, то AlexVWill правильно посоветовал использовать готовый open source-движок. Его нужно поставить на обычный хостинг или VDS, и дальше дорабатывать для своих нужд. В частности, если вам нужен аналог ВКонтакте, то есть такой проект OpenVK.

Всё верно: в UDP нет соединений, там идёт обмен данными независимыми пакетами. Все эти пакеты приходят в один сокет, даже если отправители разные. Считывание из этого сокета идёт последовательно в порядке прихода пакетов. Также нужно иметь в виду, что если пакетов идёт очень много, а обрабатываются они медленно, возможна ситуация, когда у операционной системы не хватит буферов для приёма новых пакетов, и они начнут терятся.
Чтобы понять, от кого пакет, и что с ним делать, нужно либо в самих данных передавать какой-нибудь идентификатор отправителя, либо вместо recv использовать функцию recvfrom. Она получает не только сам пакет, но и IP-адрес отправителя.

Если дело происходит под Linux, то написать соответствующий unit для systemd:

[Unit]
Description=Your Daemon
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service

[Service]
Restart=on-failure
RestartSec=10s

ExecStart=/usr/bin/python3  /path/to/script

Под Windows тоже можно прописать скрипт как службу с возможностью рестарта в случае падения.

Ну и как совершенно правильно выше заметил Saboteur, чтобы скрипт не падал от ошибок, нужно использовать try/except.

Сервер должен выдавать заголовок Access-Control-Allow-Origin, где указывать, с каких сайтов к нему можно обращаться с помощью fetch. У тестовых API, скорее всего, выдаётся Access-Control-Allow-Origin: *, поэтому на них всё и работает.

Сам X Server — да. А вот некоторые оконные менеджеры или desktop environments могут и не запуститься.

VirtualBox можно попробовать, он бесплатный, но с поддержкой аппаратной вирутализации и драйверами для гостевых систем, начиная с Windows 2k (для 9X — не помню, есть драйвера или нет, для Windows 3.11 и ниже это не особо актуально).
Оффтоп: интересно, зачем в наше время может потребоваться Windows 1.x или 2.x?

Такие notices выдаются при обращении к необъявленным переменным. Например, $count_questions определяется только в том случае, если $_GET['test'] не пустая и удалось найти сам тест. Чтобы этого не было, нужно где-то в начале определять начальное значение, например, $count_questions = 0 перед проверкой if (!isset($_GET['test'])). То же самое и с остальными переменными: либо всё время проверять на isset, либо задавать начальные значения.

Я деплоил так: монтировал удалённую систему по sshfs и далее делал rsync. Но если проблема в том, что ssh падает, то такой вариант, наверное, тоже не подойдёт (хотя можно ещё попробовать поменять настройки таймаутов у sshd).
Также можно попробовать доступ по NFS настроить, там вроде шифрования нет, поэтому к таймаутам из-за плохого Интернета будет более устойчива.

Вообще, более правильным является такой вариант:

<link type="text/css" rel="preload" as="style" href="home.css" onload="this.rel='stylesheet'"/>
<script>
// Firefox не грузит стили с preload автоматически, 
// поэтому в конец HTML-кода нужно добавить такое (один раз):
if (navigator.userAgent.indexOf("Firefox")>=0){
var elms = document.querySelectorAll('link[rel=preload][as=style]');
for (i=0; i<elms.length; i++){
elms[i].rel="stylesheet";}}
</script>

Стоит ли разделять стили — сложно ответить однозначно. Когда файлов много, и часть стилей дублируется, сложнее вносить изменения (приходится дублировать их в каждый файл), зато меньше траффика для пользователя и лучше скорость загрузки. Соответственно, тут нужно смотреть, насколько у раздельных файлов размер меньше, чем у общего. Если в 2—3 раза, а сайт требуется модифицировать редко, то можно разделить. Если на сайте то и дело что-то доделывается, то лучше обойтись одним app.css.
И ещё: те стили, которые описаны в теге