ReactLover

хватит спамить тостер. вы уже задавали этот вопрос и вам ответили на этот вопрос - любой приличный гипервизор может спокойно запускать виртуальные машины при запуске системы. например линукс с qemu + kvm , интерфейсов разных сколько угодно если не нравится стандартный virt-manager. Чтобы запустить macos придется помучаться, иногда невозможно , зависит от железа.

Пусть родительский компонент контроллирует, чтобы этот проп менялся раз в N секунд + дочерний компонент обернуть в React.memo

Веб-разработчиком могут называть и бэкендера, и фуллстака, и фронта.
А фронтендер - это фронтендер.

Статически типизированая Java внушает больше доверия

Мне больше внушает доверия программист, а не инструмент. Если вы хорошо умеете в Джаву, берите её, Node.js не уступает Джаве.

По порядку:

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

С неправильным управлением памятью связано очень много ошибок. Например в хроме вроде около половины CVE с этим связано. Ещё можно вспомнить HeartBleed в OpenSSL, который тоже связан с неправильным управлением памятью.

(Дальше какое-то ужасно длинное предложение, которое я разбил на части)

Новый язык программирования Раст, как заявляют, лишен этого недостатка

Да

разве общее число ошибок не перераспределяется на другие недостатки

1. Самые сложные в исправлении ошибки - кривое управление памятью и многопоточность, обе их Rust Решает
2. Нет, ошибки не перераспределяются, это же не тараканы.

являются ли ошибки с памятью ошибками программиста

Если управление памятью ручное, то это ошибки, которые допустил разработчик.
Если управление памятью автоматическое (хоть через GC, хоть через Borrow checker), то это ошибка компилятора/рантайма/языка.

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

Не обязательно.

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

OpenVPN - других слов нет, и не будет.

-----
Давайте я немного разверну свой ответ. Каждый раз при очередной надобности в VPN, я пробую разные решения, начиная от PPTP и заканчивая WireGuard, не считая частнофирменных сисоц и всяких решений исключительног под всем известную операционную систему..
И так на протяжении лет 20-и.
За эти года построил сотни сетей и решений от простых на 10-20 клиентов, до серверов доступа на несколько тысяч.
У OpenVPN есть куча недостатков, у него нет нативных клиентов, но есть три очень больших преимущества:
1) Относительно высокая скорость работы
2) Очень быстрое поднятие, установка и отладка
3) Он работает везде, на любой платформе (да, я его поднимал даже очень экзотических системах типа OS-9), с любым MTU, на любых типах сетей, проходит все мыслимые и немыслимые NAT.
Итого: увы, на мой взгляд, лучшей альтернативы ему пока нет.

Нужно чтобы родительский элемент у карточек имел display:flex, это сделает карточки одной высоты. Для .product__wrap и .product__content указать display:flex; flex-direction: column; И для .product__content и .product__description добавить flex-grow: 1

Такой подход используется чаще всего:

1. components – большие компоненты, такие как карточки, фильтры и т.д., которые крайне редко переиспользуются
   
2. elements – мелкие компоненты, такие как Button, Input или обертки бутстрапов/UI библиотек, чтобы в дальнейшем их переиспользовать
   
3. pages – сами страницы
   
4. store – место для редьюсеров, экшенов и саг
   
5. utils – место для переиспользуемых фукнций, констант, своих эффектов и т.д
   

У меня один домен на свинке (ссылка не реферальная), жалоб нет, цены норм...

Вне контекста никак.

Вася сидел до́ма.
Вокруг стояли дома́.

Он же явно говорит, какой должен быть тип