Дмитрий

1) отделять логику от представления, в файлах отображения не должно быть запросов к бд
2) Естественно вывод представлений должен буфферизироваться, и по итогу рендериться целиком.
3) Не заниматься фигней с самописными костылями, взять что-то готовое, хотя бы тот же fat-free, если уж не охота учить что-то типа лары.

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

Windows тут не виновато.

Очевидно что проблема железная, если linux тоже не может записать на диск что-либо, именно так умирают флешки, контроллер переводит диск в read only режим и игнорирует любые записи.

Просто используйте LIKE оператор

delete from news where description like 'Мы печем лучший % хлеб в стране.';

SQL LIKE online

исходя из вышеизложенного, какой бы стек технологий вы бы выбрали как разработчик чтобы решить вышеописанную задачу?

Для начала немного контекста - 2 важных примечания:
1) Описанная задача решается на любом упомянутом стеке, + еще десяток возможных вариантов (Java/Spring, питон, нода, дотнет, голанг и т.д.).
2) Быстродействие системы зависит от ее самой медленной части, и в 95% случаев самая медленная часть - БД, просто в силу специфики работы: много данных со сложными связями, выборки с сортировкой и фильтрацией из большого массива и вот это все, в то время как язык бэкенда в основном выполняет достаточно простые манипуляции с уже готовыми наборами данных (за редчайшими исключениями, которых в вашем кейсе нет, или они не описаны в вопросе).

В вашем случае:
- база можно сказать совсем небольшая, до 1 миллиона записей условный мускуль ворочает весьма шустро, если железо соответствует.
- задача сбора метрик достаточно тривиальная, особого ума в сохранении действий пользователя не надо, бОльшая часть работы - вывод в красивые графики и написание быстрых запросов с хитрыми выборками/агрегациями, немного пошаманить с формулами, возможно делать какие-то сводные выборки с денормализованными результатами для отчетов и прочие мелочи. Работа не сложная, но нудная, и ее много.

Насчет стоимости и условий:

полный самопис 150к+ (я это не тяну) или же сайт на Laravel +MySQL а дальше варьируется.

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

По цене - на сегодняшний день, если я не ошибаюсь, 150к деревянных это +- 1000уе. Цена приемлемая за нормальную работу, если найдете дешевле "на Laravel" - думаю будет вообще ок. Опять же, цены штука такая, кто-то за копейки сделает хорошо, кто-то за дорого каку сляпает. Влияет так же регион, понятно что в Мск цена будет серьезно больше чем в условном Челябинске...

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

UPD:

проект планируется на 100 к+ посетителей в месяц...
предупреждают что если аудитория достигнет условных 100 тысяч в месяц Лара начнет потихонечку задыхаться от нагрузки,

ок, пусть будет 200к для наглядности.
В среднем, если это маркетплейс, то постоянных посетителей будет не много, думаю около 10%, так что ими можно пренебречь. Условно - 200к / 30 дней = 6600 в сутки, при активных 10-12 часах посещения это ~600 в час. Пусть на 1 посетителя будет 5 запросов страниц, это 600*5=3000 в час = 50 в минуту или менее 1 запроса в секунду.
Даже если умножить это на 30 (допустим такая пиковая нагрузка), 30rps вообще "ниачем". Не знаю кто там вам считал то это проблема, любое современное железо среднего уровня вытягивает без напряга.

1. Не ясно зачем использовал старый .net framework
2. Зачем у Score публичные геттеры-сеттеры, если по идее класс иммутабельный и у него даже конструктор с обязательными параметрами есть?
3. Везде есть привязка к русскому языку, что не очень хорошо, но и не смертельно.
4. Есть небольшая проблема с именованием методов, но не критично
5. Стандартная бинарная сериализация - зло почти всегда.
6. Пароли в открытом виде, и даже нет никакой абстракции над форматом хранения данных (если бы была абстракция, то уже не так критично было бы)
7. Относительные пути (нашёл в Manager.cs). Сами по себе относительные пути - это не плохо, но тут аж в родительскую папку стучится.
8. Не понятно, почему есть всего три захардкоженных вида викторин. Разницу между ними по коду я не увидел.
9. Главное меню в процедурном стиле с совершенно неговорящими именами методов и константами - ну это совсем уже ни в какие ворота.
10. Нравится, что сразу есть разделение на два bounded context - прохождение викторин и создание. В принципе не сложно будет зарефакторить.

Дальше не буду проверять. Кажется, что автор просто не достаточно проработал предметную область и не проработал архитектуру приложения, на основе этого.

Советую почитать книги:
"Чистая архитектура" Роберта Мартина
"Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем" Эрика Эванса

Не обязательно прямо целиком книги - можно просто почитать статьи и посмотреть доклады про то как следует строить архитектуру приложений.
Вкратце:
1. Старайся не смешивать модель предметной области и детали реализации
2. Если делаешь обогащённые модели (с методами, которые отражают суть предметной области), то используй их повсеместно.
3. Если делаешь анемичные модели - делай их повсеместно. Не стоит в рамках одного контекста смешивать оба подхода
4. Код в идеале должен выглядеть так, чтобы было сразу понятно, что происходит и почему. Также должно быть очевидно, где и что нужно искать.
5. В идеальном мире, код должен быть такой, что если бы тебе дали задачу "перенести это всё в веб", тебе бы вообще не пришлось никак менять код ядра (в данном случае проект QuizModel), и при этом не пришлось бы дублировать код из QuizCreator и QuizApp

-a
--all
Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.

В коммит автоматически добавятся изменённые файлы - не надо предварительно выполнять git add <file>

диск непонятно чем заполняется( было 4, а сейчас 6 занято.

Уверен, что проблема именно в ОС, а не в приложениях?
Искал, что именно столько места занимает? Очень возможно, что это просто логи или какие-то временные файлы.
А может ты просто устанавливал какой-то софт, и он подтянул столько зависимостей.

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

По моему опыту:
1. Выбор между Ubuntu и Debian - это вопрос религии.
2. Debian/Ubuntu в LTS редакции пригодны для 99% задач

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

как правило интегрированная видеокарта слабее по производительности чем дискретная и потребляет оперативную память, в то время как дискретная имеет собственную память и более производительна, однако это имеет свою цену - дискретная видеокарта потребляет больше электроэнергии, а значит при работе от батареи автономность будет страдать, при работе в нетребовательных приложениях - например офис или веб-браузер. В то время как для тяжелых приложений типа игр, 3D моделирования лучше использовать дискретную ВК для офисной работы лучше использовать интегрированную ВК. Переключение и принцип работы настраивается в драйверах на дискретную ВК.

И в чём будет минус, если я поставлю работу только от видоекарты?

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

Циклы в РНР никак не связаны. Как и в любом другом языке.
И второй всегда начинается без свякой связи с первым.
Если же речь идет о переменных, которые участвуют в цикле, то программист должен позаботиться САМ, о том чтобы перед началом любого цикла они имели нужные значения.

вариант с установкой SSD в коробочку с интерфейсом передачи данных USB - скорость обмена данными ПК с SSD будет ограничена пропускной способностью USB.

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

единая точка входа и настройки сервера (mod_rewrite или для нжинкс там другие немного директивы), + роутинг.