webhead

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

Изучать будет трудно. Линукс не прощает грубых ошибок. Если проводить аналогии то Windows - это электродрель где всё в резиновых ручках безопасно и красиво и удобно лежит в руке. С такой дрелью вам ничего не грозит. И можно сделать дырочки в стенах безопасно. А Линукс в этом сравнении - это строительный бур, которым вы можете снести стену, но и легко пробурить себе ногу. Тоесть когда вы начнёте эксперименты (особенно на привилегиях root) то думайте что по ту сторону нет вообще никаких защит. Удалить корень файловой системы одним жестом очень просто, как уже отметили выше.

Но для домашнего варианта можно придумать нечто вроде : создать свою мини-сеть с DNS, файрволом, прокси, и медиасервером для фильмов. Вот с этого можно начинать. Можно поднять игровые серверы Майнкрафта, фермы майнинга или генерации радужных таблиц. По поводу Mint - всё в принципе хорошо. Вообще важен не дистрибутив а скорость трабл-шутинга. И надо не боятся работать с консолью. Не надейтесь что если вы подняли Smb через UI - то это достижение. Нужно поймать траблу. Зайти в консоль и ее пофиксить. Я гарантирую что через UI большинство траблов не фиксятся. В этом есть особая философия. Поэтому и устанавливайте и конфигурите софт через консоль.

AOS

Что такое "тип вёрстки" — затрудняюсь.. Тут верстальщик хотел сверстать лендинг, но случайно нашёл плагин scrollmagic.io... И не смог остановиться )

Если интересно как сделать подобное, смотрите примеры: scrollmagic.io/examples/index.html, читайте доку.

Но пользуйтесь в меру. Не как в приведённых вами шаблонах.

Про inertia почти ничего не скажу. Про livewire - Для mvp, низкобюджетных стартапов, инди-проектов, того что по умолчанию для ограниченной аудитории и не должно быть слишком нагруженным, админок каких-то... вполне себе вариант.
Для более серьёзных вещей и с расчетом на перспективу - я бы оставалась на проверенных технологиях.
Из подводных камней - с технологической стороны - дикое смешение ответственностей. С практической - каждый чих изменения в интерфейсе - та же кнопочка счетчика, смена таба, или еще чего, реализованного без православных скриптов - это запросы на сервер. И еще - серьёзный локинг на этих технологиях, их апдейтах.
А конкретно tailwind мне таки зашёл, если его с умом готовить и выносить наборы в scss. В компании с purgecss на выходе можно получить очень лёгкий css файлик. Но он обязательно в компании с компонентами - блейд, или js -фреймворков (И это, разумеется с позиции бекендера. Если на проекте есть заведующий фронтом - то ему и править балом).
В любом случае я бы посоветовала не полагаться только на мнение других, а покрутить и пощупать всё самому. Как минимум - они на хайпе, и значит есть вероятность что все равно с ними столкнётесь рано или поздно

Вы пытаетесь на JS писать в PHP
Правильно так

<?php
// Если устройства не iPhone|iPad|iPod
if( !preg_match('/iPhone|iPad|iPod/i', $_SERVER ['HTTP_USER_AGENT']) ) {
	echo '<script src="/js/myscript.js"></script>';
}
?>

Удобно эндпойнты в апи делать

[GET]    /order/{id}  получить информацию о заказе
[POST]   /order/{id}  создать новый заказ
[PUT]    /order/{id}  обновить данные в заказе
[DELETE] /order/{id}  удалить заказ

Вместо

[GET]  /order/{id}
[POST] /order/{id}/create
[POST] /order/{id}/update
[POST] /order/{id}/delete

будет ли нормальная поддержка этих методов в том же php и формах html?

https://caniuse.com/mdn-http_methods_put
https://caniuse.com/mdn-http_methods_delete

А что вы имеете ввиду под нормальностью в php? Определить метод запроса можно, прочитав $_SERVER['REQUEST_METHOD'], получить данные из php://input

UPD

Нашел вопрос аналогичный. Ответы краткие но емкие и по делу.
https://stackoverflow.com/questions/27941207/http-...

grant file on *.* to user@localhost identified by 'password';

Обычно код такого качества проще переписать. Есть и дополнительные плюсы:
- вы в деталях поймёте, как работает проект и что делает;
- вы, вероятно, найдёте и исправите какие-то баги по дороге.

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