rPman

на английском
метавселенная это (маркетинговая) философия, ее создают, используя голову и человеческие языки

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

то что в 'эту игру' (я про навешай потребителю лапши побольше) хотят играть другие ничего не меняет, просто смени место приложение вопросов на другую компанию

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

тут несколько подходов, я трогал каждый из них и все они имеют право на существования
1. оставь как есть, я рекомендую, пусть будет 100500 таблиц справочников (если проблем с именами нет ну и отлично), fk-индексы все это свяжут а инструменты анализа базы данных помогут с этим работать (автоматические query builder с мышевозекательным интерфейсом) и база будет сама следить за тем что идентификаторы справочников не противоречивы
недостатков я не могу придумать, кроме может быть сильно разросшейся структуры, когда то давно я слышал что некоторые базы данных при увеличении количества таблиц начинают хуже работать но как я понимаю это если их будет десятки тысяч а не десятки и сотни.. может быть резервное копирование такой базы или ее репликация будет проходить чуть медленнее или еще хуже, организационно репликация может быть настроена на не рассылку ddl модификаций, в этом случае создание нового справочника будет задавать работу еще и админам, что нежелательно.

2. противоположный, использование одной таблицы key-value для нескольких разнородных справочников (id, value, table_name), в 99% случаев можно использовать один сиквенс (одну последовательность идентификаторов), вам же не обязательно чтобы разные справочники начинали счет своих строк с одного и того же числа 1.
Недостаток - база данных теперь не сможет контролировать что вы используете непротиворечивый идентификатор (можно в запись одного справочника указать номер из другого), хотя несуществующий так же нельзя будет указать (и будут работать delete cascade), так же удобной автогенерации sql не будет. Структура будет проще, так же интерфейс редактирования таких справочников может быть один вместо кучи форм и добавлять новые справочники будет сильно проще (хотя с точки зрения разработки нет особой разницы, один insert ты написал или create table перед этим)

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

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

при использовании библиотек как есть без модификации (с помощью динамической линковки!), ты можешь использовать qt как угодно, но с упоминанием что используешь их,
https://www.qt.io/licensing/open-source-lgpl-oblig...

In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

вообще lgpl оставляет лазейку, если ты проведешь модификации кода их библиотеки, тебе достаточно предоставить исходные коды этих модификаций, а вот основное приложения так же оставить проприетарным, при условии динамической линковки уже этой модифицированной библиотеки

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

если препятствия произвольный угол имеют то... формулы можешь посмотреть тут

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

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

Если по простому считать, при использовании только половины емкости диска, должно кратно (формально не в два раза, так как для переноса 1 единицы информации записей будет произведено две) увеличить срок годности диска (с точки зрения ресурса записи ячеек)

Но если операционная система (и настройки bios, а именно включенный режим контроллера - ahci) поддерживает команду TRIM (сообщает что сектор освободился), то не важно, в какой части диска находится неиспользуемые сектора. И в этом случае диск можно разметить весь но самостоятельно следить за наличием свободного места, результат должен получиться аналогичным. Кстати если изредка, кратковременно, количество свободного места на диске будет уменьшаться, даже в ноль, это не должно заметно повлиять на описываемое повышение срока годности, ведь значение имеет только операции записи и возможность их размазать по диску

Поэтому повторюсь, нет нужды ограничивать себя в размерах доступного пространства такими способами, размечай весь диск и проследи чтобы в BIOS и ОС была включена поддержка TRIM.

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

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

Еще момент, некоторые файловые системы, например btrfs/zfs, умеют на лету! добавлять (и удалять) диски к пулу, и не обязательно это должен быть raid, возможно простое объединение пространств дисков, даже без чередования. Собственно btrfs я бы и рекомендовал использовать, даже не смотря на его нестабильный статус (так как все его проблемы касаются вещей, которые можно не использовать, например raid56)

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

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