Nikita

Разница в производительности не столь важна, как момент возможности апгрейда до актуальной версии macOS. Для второго максимальная версия high sierra, а на late 2014 можно установить последнюю Catalina. Заменить в первом HDD на SSD, добавить памяти - будет прекрасная машинка.

Бонусом идёт то, что Windows не просто проставляет значение в соответствии с ОЗУ, а, через некоторое время, оптимизирует этот размер.

Хороший линукс-дистрибутив

чтоб ощутить линь полностью

после установки дебиана, он не запускается

ну так уже же ощутил, на этом можешь остановиться и бежать на виндувс

Где у Вас потери-то? tracert всего лишь показал, что какие-то узлы не отвечают на ping. Они могут прекрасно работать, и маршрутизировать трафик, но не отвечать на пинг.
Делайте pathping до yandex.ru, например, или другого более-менее быстрого узла.
Это всё во-первых.
Во-вторых - читайте договор. Или оферту на их сайте (если есть). Как правило, нигде ни один провайдер не указывает такие параметры, как процент потерь, гарантированную доставку, и гарантированную скорость. Указывают только максимальную скорость - ДО хххМбит/с. Т.е. скорость, например, МОЖЕТ быть 100 мбит, но это никто не гарантирует.
Тем более, Ваш конечный адрес принадлежит Valve Corporation, и начинается уже на 7 хопе.
https://bgp.he.net/ip/155.133.252.35
До 6 хопа всё это ТТК, и у них прямой пиринг с Valve, так что, по-идее, должно всё быстро работать, но, судя по пингу - сервер, к которому Вы подключались, далековато, скорее всего не в России.
Мало того, это могут быть перегруженные сервера, на которых работает игра (видимо, CSGO), или даже специально так настроено, чтобы сбалансировать задержки от разных игроков или снизить нагрузку или предотвратить возможные DDoS'ы. Предполагать можно что угодно. Хотите быстрее - переезжайте в другой город/страну, поближе к серверу, чтобы быть с ним (почти) в одной локалке. Вот тогда и пинг будет 1-3мс. Физику не обманешь, скорость света в оптике около 0,6 скорости света в вакууме, и на больших расстояниях эти задержки + задержки сетевого оборудования + задержки сервера и конечно, Вашего компа и маршрутизатора тоже - вот и получите 30-40мс.
Так что либо делайте нормальное тестирование, изучите на https://bgp.he.net/ к каким сетям и провайдерам относятся узлы в трассировке, и тогда уже делайте выводы - где проблема, а где её нет.
GLHF!

Мое решение (работеает уже давно). Работает на всем, что шевелится - Андроиды, Windows, Макинтоши.
SSH тоннель с ключами, защищенными пасскодами.

-ставим сервер с выходом в инет на белом IP
-отрубаем вход под рутом
-отрубаем шелл
-вешаем ssh на рандомный порт
-всем юзерам делаем персональные учетки, генерим ключи

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

plink -P ПОРТ -l ЛОГИН -i КЛЮЧ_ЗАКРЫТЫЙ.PPH  -N -L 23389:МАШИНА_КЛИЕНТА_В_ОФИСЕ:3389 АДРЕС_ШЛЮЗА_В_ИНЕТЕ
pause

Клиент у себя врубает батник, вводит пасскод от ключа и подключается на адрес типа 127.0.0.1:23389, а SSH его уже туннелит куда надо.

Есть процедуры, позволяющие сгенерить ключи без визита сотрудников в офис.

У этой формы скорее всего есть класс или id-шник, вот по нему можно с помощью js легко удалить:

setTimeout (() => {
  document.querySelector('.elemenClass').remove();
}, 5000)

Я считаю это хорошей практикой. Исключительная ситуация - это та, при которой программа выполняется не так, как ожидалось. Но, позвольте, я ожидаю, что заказ пройдет валидацию. Я ожидаю, что заказ завершится успехом. Поэтому OrderValidationException, OrderException - исключительные ситуации. Исключительной ситуацией не является, например, отмена пользователем заказа - глупо выбрасывать исключение по клику на Cancel.

Исключения гораздо глубже, чем просто "исключительная ситуация". Они помогают развести обработку ошибок по разным уровням абстракции, а использование разных типов исключений позволяет обрабатывать конкретные ошибки там, где их нужно обработать (на нужном слое). Исключения очень помогают в локализации ошибки в дальнейшем, они позволяют избавиться от простыни If .. else, проверок на null, false и прочей ереси. Они, чаще всего, делают код чище.

Но пользоваться ими стоит аккуратно, все-таки стоит разделять исключительную ситуацию и вполне нормальную, штатную ветку исполнения. Так, если заказов нет - это НЕ исключение, тут можно вернуть null - допустимо (хотя некоторые и тут выбрасывают исключение, потому что очень соблазнительно привязать код исключения к HTTP кодам). А если у вас аплоад документов, и юзер пытается загрузить файл слишком большой, то это уже исключение.

Проблема состоит в том, что владельцы этого канала телеграмм оказались мошенниками

ахахах. а вы думали там честные люди сидят?))

Вот я и думаю теперь, если обратиться в полицию с данными владельца карты

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

p.s. как в 2020м вы до сих ведётесь на это?)

Главный спорный вопрос который вам стоит решить: где хранить статичный первод (надписи, что не меняются или меняются редко, например название кнопки - Отправить/Submit, те все то, что мы обычно не храним в БД и редко меняем).
Варианта два:
1. Использовать только реакт для этого, тогда берете пакет react-localization, там достаточно простые и понятные принципы, сложностей нет.
Преимущества: фронт полностью отдельно живёт и не зависит от бэкенда, нет дополнительных прослоек, нет привязки к определенному бэекенду и тп

2. Использовать возможности локализации Laravel. Но тут все таки все методы той или иной степени костыльности, либо как минимум добавляющий жесткую привязку фронтенд приложения к текущему стеку бэкенда
Преимущества: можно использовать разные пакеты для интеграции средств редактивования статической локализации в бэкенде.

Лично я всё же склоняюсь к первому варианту, так как люблю писать максимально (желательно полностью) назависимые фронтенд приложения.

Теперь вторая часть вопроса. Уже касаемо динамических переводов (это контент, комментарии, и тп, условно говоря всё что мы храним в бд, или храними информацию о них в бд).
Здесь я советую положится на Laravel, берёте пакет от spatie laravel-translatable, он позволяет быстро строить удобные интерфейсы редактирования/чтения переводов в БД, пишете простое API и ри инициализации react приложения получаете данные нужные вам локализации, либо даже отправляете все сразу (они хранятся в json поле mysql/ваше БД, даже доп преобразований особо не потребуется).
Но вариант с отправкой только нужной мне нравится больше, смена локали событие редкое, а вот экономия на размере переданных данных будет существенная.

Ну, а далее уже вешаешь всякие кеширования тп, чтобы всё летало и готово.

Нет верного ответа, как и вопрос крайне относительный. У каждого разное понимание "маленького" проекта. Также не стоит забывать, что реакт - библиотека с компонентным подходом. К примеру возьмем главную страницу Гугла. Там могли бы быть такие "большие" компоненты как "шапка" и "main" которые в свою очередь состоят из множества других компонентов, как: кнопка/поле/форма/ссылка и все это можно сколько угодно разбивать на более мелкие компоненты, пока не достигнете уровня компонент == тег(html).
В таком случае вопрос уже в том, насколько это целесообразно в рамках конкретного проекта. Насколько они должны быть мелкими зависит от того, насколько реюзабельными они должны быть

З.ы. прошу прощения, если вода/тавтология

Да без разницы, если честно. Она запустится единожды и дальше про нее можно забыть навсегда.

Конфликты маловероятны, ни разу не стыкался.

AddTargetTypeColumnToOptionsTable
AddSomeSetOfFieldsToSomeTable
MakeOptionFieldsNullable
CreateSomeTable
RenameSomeFieldInSomeTable
RenamePackageTables

Главное, что бы вам было удобно ее искать до того, как она закомичена. Остальное значения не имеет.