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

Делать внешние ключи обязательно.
И уникальные индексы проставлять. Ещё бы check constraint ставить, да у вас глупый mysql в тегах, он такое не умеет.
Это всё ваши помощники. Они помогают искать ошибки и отлично мешают делать глупости.
И выбирать подходящие типы данных. Ну и раз у вас mysql - то всенепременно проверить sql_mode и выставить его максимально агрессивным. В 5.7 стало гораздо лучше, до этого из коробки уж слишком много позволял делать глупостей.

Дорастёте до террабайтной базы как авито - тогда можете начинать думать, а сколько денег нам стоит целостность внешних ключей или дешевле будет периодически проверять целостность скриптами и озадачивать разработчиков. О, кстати, вот запись доклада с pgday15, на 27 минуте как раз начинается обсуждение вопроса из зала "ребята, а вы в своём уме отключать FK?"

SELECT count(*), radio FROM likes GROUP BY radio

a в чем собственно проблема?
они никак друг с другом не взаимодействуют и не мешают один другому (кроме потребления ресурсов).

Мозг работает так, как он привык работать.

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

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

P.S. С детства такие вещи тренируются. Чем взрослее тем сложнее, и даже факт того что ты осознаешь конкретный недостаток не облегчает того, что избавиться от него тяжело.

https://en.wikipedia.org/wiki/C%2B%2B17

С++ 17 ревизии еще не утвержден окончательно, в марте он только в черновики ушел.
После утверждения ждите еще пару лет, пока кто-то напишет книжку, подготовит, вычитает и выпустит в печать.
Потом кто-то возьмется ее перевести, переведет, подготовит, вычитывает, выпустит в печать.

Ну или просто английский подучите и читайте онлан спецификацию на английском.

в исходном коде конкретного компилятора :) ключевые слова "напрямую" преобразуются в "бинарный" код.
в системе разбора исходного текста в дерево работы/алгоритмов компилируемой функции.
википедия к примеру
аналог болт и гайка, их структура не описывается в чертеже, считая их фундаментальными объектом.

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

Ответ на ваш вопрос будет таков:
Просто "открыть" можно через 7-zip
Незащищенные .exe дизассемблируются через IDA Pro
Запакованные или защищенные .exe нужно предварительно распаковать (в самом тупом случае - через UPX, в сложных - дизасмить распаковщик и динамически отлаживать)

С чего это вы решили?

У меня половина серверов на FreeBSD (ради нативного ZFS прежде всего)
У моего основного хостера - примерно 30% на FreeBSD

На Solaris тоже сервера встречаются (не веб-сервера, а скажем внутрибанковские).

Linux довольно распространен в web - и только.

Есть еще сервера внутри предприятий (автоматизация),
есть еще магистральные роутеры,
есть SAN-сервера
и пр. и пр.

Просто они не публично доступные, поэтому у вас не перед глазами - тем не менее через них проходит много и лично ваших данных.

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

Как я понял: речь про баланс: контроль игрового мира <-> объём передаваемых данных по сети.
Вопрос хороший.
Не всегда нужно делать всё на сервере, иначе объём трафика - возрастёт дико во время игры. Но также, нельзя доверять клиентским данным.
Поэтому, всегда делается аппроксимация: промежуточная визуализация - вычисляется на клиенте, а пришедшие на сервер данные - всегда тщательно проверяются сервером в рамках логики(модели) работы игрового мира. И если отклонения слишком велики - фиксируется "читерство", иначе - по получению новых позиций объектов, клиент плавно, но с ускорением ("параболически") устраняет расхождения с серверным игровым миром: синхронизирует актуальное состояние мира сервера с отображаемым пользователю.
Это происходит в 99% случаев незаметно для глаз игрока за монитором.

На сервере и на клиенте - лучше всего дублировать логику механики и синхронизировать каждые N-кадров или принудительно по каким-либо важным игровым событиям.