Dmitry Bay

Легче чем ты думаешь.
1. На время, когда доступа к компу не должно быть - ставишь на юзера свой пароль
На время когда доступ быть должен - ставишь тот пароль, который знает пользователь.
Скрипт можно в планировщике прописать.
2. То же самое с командой shutdown - даже если пользователь включит комп после выключения, то войти уже не сможет до указанного времени.
3. И разумеется, у пользователя не должно быть админских прав для доступа к скриптам.

Впрочем, даже без смены пароля можно установить для юзера разрешённое время входа.

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

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

Штатный генератор картинок ИИ не является, это простой (по сравнению с gpt) транслятор смысла, в котором галлюцинации - его основная деятельность.

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

а настройки php?

upload_max_filesize = 100M
post_max_size = 100M
memory_limit = 256M

каким кодом файл принимаете?

Клиенту не нужен дизайнер. Клиенту нужен ВП-разработчик и может быть (но не факт) веб-дизайнер.
А на тему (в разрезе "под которую будет делаться дизайн") вообще плевать.

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

Пока есть возможность - заложите в каждую комнату по минимум 2 кабеля максимальной категории, причем с соблюдением всех правил прокладки. Оконцуйте розетками над плинтусом. Никогда не знаешь, где они впоследствии понадобятся, пусть лежат.
Пару кабелей приведите к точке входа кабеля провайдера в квартиру. Там оконцуйте розетками и в одну из них вставьте кабель провайдера или патчкорд от оборудования провайдера.

Вероятно вам захочется организовать домашний NAS или даже сервачок свой. Прикиньте, где его разместить (лучше не в шкафу по ряду причин). Например, на застекленной лоджии. Туда тоже проложите минимум два кабеля. И питание.

Все кабели с комнат сведите в одну точку, там повесьте небольшой шкаф на 5-6 юнитов. Заведите все кабели в него, там разместите патч-панель, ИБП, полку для роутера, возможно свитч на нужное количество портов, дин-рейку с розетками и автоматом.



Важный момент - дверцу берите глухую, иначе мигание светодиодов ночью достанет.

Приобретите 2-3 точки доступа Wi-Fi mesh. В идеале найти поддерживающие стандарт EasyMesh.
Все точки доступа Wi-Fi собрать в mesh на 5ггц, одну из точек как главную настроить в режиме моста (bridge) и включить в общую сеть.

Маршрутизатор я бы рекомендовал отдельный, без Wi-Fi, по ряду причин. К примеру, что-то из серии Ubiquiti Edge Router. Или тот же Keenetic помощнее, отключив в нем Wi-Fi и спрятав в шкаф на полочку.

Можно. Ставите php8.4, cтавите «Ларавель», интегрируете аутентификацию, чтобы она была сквозной. Делаете лейаут из старого сайта. Делаете модели под таблицы. Новые модули делаете уже в «Ларавеле», постепенно переносите в него старые.

Проблемы, которые точно придется решать:

1. Всё время придется поддерживать два шаблона для сайта.
2. Если старый сайт использует одну точку входа index.php, а там уже определение роутинга, то придется слегка помучиться. Тогда сперва запрос должен принимать «Ларавель», искать подходящий роут, а потом, если нет совпадения, то проксировать его в старую систему (разумеется, с передачей всех данных).
3. Бардак в структуре проекта.
4. Настроить работу одновременно с двумя php (5-ой и 8-ой версии). Скорее всего придется делать два внутренних домена и перед ними ставить nginx как прокси. Можно на него попробовать и возложить проблему распределения роутов между старым и новым кодом.

Ну и по ходу наверняка еще будет много подводных камней.

В общем задача сложная, но очень интересная :)

С MySQL на PostgreSQL переходить не обязательно. Подробно об этом выше ThunderCat написал. Полностью согласен с ним.

разработчики все время советуют перейти на новые технологии а если точнее на Laravel и с MySQL на PostgreSQL чтоб сайт не только стал современным но и работал шустрее.

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

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

Обычно заявы по типу "мускуль гуано, надо менять на постгрес" без конкретных аргументов признак поклонников карго культа, а не профи. Так что я бы послушал аргументы для начала, а то потом окажется что там индексы только первичные на таблицах, про explain никто никогда не слышал, а выборки идут по тысяче в циклах, но виновата, конечно же, тормознутая бд.

Сначала дай определение мошенническому сайту.

Предположим, что мошеннический сайт - это такой сайт, который использует мошенник в своих мошеннических действиях.

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

Для случаев, когда мошеннический сайт выдаёт себя за настоящий - достаточно просто глаз и внимательного прочтения адресной строки.

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

Обычно такой подход не используется - все изменения в БД приходят частичными обновлениями и изменением версии БД, например с использованием Liquibase.
Если вам нужно переливать БД из одной в другую - то действительно проще добавить в CI\CD bash скрипт, можно вообще сделать отдельный пустой репозиторий с gitlab-ci и одной кнопкой.