Павел

https://down.dipol.com.pl/IP_Cctv/K17412/K17412_Da...

На poe макс энергопотребление 6.5w×камер (8)= 52w на все камеры +10% потерь если далеко тянуть будет итого =~60w

Ябадубаду

Короткий ответ (с учетом указанного ТЗ) - WP.

Длинный ответ:

публиковать страницы, создавать иерархию страниц, чпу url, какой то слайдер с картинками

Учитывая типовое ТЗ, ответ - WP (все это уже реализовано, преимущественно бесплатно и в большом количестве).

небольшое количество услуги в регионе

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

Нашли компанию, предлагает разработку сайта на WP или на Python+Django (дороже и дольше)

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

Что обычно я использую (от начального проекта к финальному):
1. WP в стоке + сборка фронта (webpack) с оптимизацией + кэширование.
2. Докупка железа и горизонтальное масштабирование п1 балансировщиком.
3. Профилирование и переписывание определенных запросов под конкретные задачи в самом WP, обычно добавляет производительности в 2-3 раза (от wp там мало что остается, но ценник и сроки еще не такие, как в п4).
4. Python + Django + кэширование (если нужно быстрее любого WP и более специфический функционал).
5. П4 + FastAPI (если прям совсем прижало по производительности).

"explorer.compactFolders": false

для неопытного пользователя никаких вариантов кроме debian based дистрибутивов типа xubuntu или лучше mint, вопрос даже не философии, а тупо больше пользовательская база и инструкции в интернете рассчитаны именно на ubuntu

браузер firefox, он немного быстрее работает на слабых машинах (это хорошо что у тебя 4гб ram) чем chromium браузеры (но чистый chromium тоже неплохо бы поставить)

для просмотра видео используй mpv, он умеет youtube и другие облачные видеохостинги (но навигация вручную в браузере), так же можно скачивать видео каким-нибудь yt-dlp (он тоже не только youtube)

А никак. Только виртуалка - parallels, utmapp или бета VirtualBox. Кстати, ваш спец софт-то существует в виде сборки под арм? Если нет, то учитывайте, что потеря производительности будет примерно 90% на виртуализацию x86.

На M1 и M2 от буткампа по очевидным причинам отказались.

А специфичный софт скорее всего работает только на x86 и не станет работать с Windows ARM.
+ драйверов на графику от Apple под Windows ARM нет

Это не "ваш композер запрашивает", это сам Композер хочет такую версию, она у него прописана в vendor/composer/platform_check.php - просто он под такую написан.
Добавьте в свой конфиг отключение этой проверки, чтобы он ей не маялся, и все.

{
    "config": {
        "platform-check": false
    }
}

Мультиязычность (контента) обычно реализуется двумя методами
1. Отдельные колонки под языки в каждой таблице.
2. Отдельные таблицы одноименных моделей под каждый язык.
Для реализации обоих способов есть уже несколько готовых пакетов.
https://yandex.ru/search/?text=laravel+multilangua...

А уж какую адресацию вы сделаете, особой роли не играет. Это могут быть и поддомены (en.site.ru), и поддиректории (site.ru/en).

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

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.