Аппаратная (hardware virtualization) то бишь гипервизор (VMware, KVM, Hyper-V) — управляет железом напрямую и делит ресурсы между виртуалками.

Паравиртуализация — это когда ОС "знает", что она в виртуалке, и взаимодействует с гипервизором (допустим Xen).

OS-level (контейнеры) — изоляция процессов в рамках одной ОС (Docker, LXC).

Ты ставишь VirtualBox, создаёшь виртуалку с Ubuntu — вот это и есть виртуальная машина.

А сам VirtualBox использует виртуализацию (аппаратную или программную) для того, чтобы всё это работало.

1. Хранение файлов в одном месте.

2. Бэкапы и безопасность.

3. Совместная работа.

4. Мультимедиа-сервер.

5. Свой облачный сервис.

6. Гибкость.

Стоимость: хороший NAS + диски обойдутся дороже подписки на облако.

Нужно уметь хотя бы немного настраивать сеть.

Если сломался NAS (а такое бывает), придётся разбираться с восстановлением данных.

1. Условные переходы (ветвления if/else или их аналоги).

2. Циклы или рекурсия (возможность перейти к метке как, допустим, go to).

3. Работа с памятью (хранить и изменять данные).

Python, Java, C, C++ — конечно, Тьюринг-полные.

SQL (чистый) — спорный случай. Но многие его реализации с процедурами и циклами становятся Тьюринг-полными.
Даже экзотика вроде Brainfuck или Minecraft Redstone (механизмов на основе функциональных блоков) при определённых условиях считаются Тьюринг-полными.

оно помогает понять границы того, что вообще возможно в вычислениях;

показывает, что ограничение чаще не в языке, а в разработчике (или его железа).

Мы создали компьютеры чтобы они служили нам, а не наоборот.

1. Симметричное шифрование (AES, DES, ChaCha20)

2. Асимметричное шифрование (RSA, ECC)

3. Хэш-функции (SHA-2, SHA-3, BLAKE2)

разрабатываются постквантовые алгоритмы (NIST сейчас как раз выбирает финалистов);

часть из них основана на решении задач, которые сложны даже для квантов (например, на решётках).

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

RSA доживает последние годы как стандарт.

ECC будет в ходу, но с горизонтом «до квантов».

Хэшиотносительно безопасны, но постепенно будут меняться на новые стандарты.

{ "id": 1, "name": "Alex" }

тебе нужен простой API без лишней логики;

клиенты разные — от браузеров до мобильных приложений, а также curl;

важна стабильность и совместимость.

для получения связанных данных (например, user + его посты) приходится делать несколько запросов;

из-за JSON и HTTP-заголовков передаётся много «воздуха»;

строгой схемы нет — всё можно поломать случайно.

message User {
  int32 id = 1;
  string name = 2;
}

очень быстрый, особенно на больших потоках данных;

поддерживает стриминг — сервер и клиент могут обмениваться сообщениями в реальном времени;

строгая типизация, меньше ошибок.

сложнее тестировать и смотреть ответы потому что вся информация находится в двоичном виде;

полноценно gRPC в браузере не работает, поэтому вротендерам нужен прокси;

требует внимательности при версионировании схем.

{
  user(id: 1) {
    name
    email
  }
}

меньше запросов — можно собрать все данные за один;

гибкость на стороне клиента;

хорошая документация и автогенерация схем.

сложнее кэшировать;

если запросы составлены неаккуратно, то серверу может стать ОЧЕНЬ плохо;

требует продуманной архитектуры.

REST: публичные API, простые интеграции JSON / HTTP.

gRPC: микросервисы, внутренние системы Binary (ProtoBuf).

GraphQL: клиентские приложения (веб, мобильные) JSON / HTTP.

– отказ от бесплатных обновлений безопасности;
– платные «Extended Security Updates» (ESU) для бизнеса;
– предложение купить новое железо ради Windows 11.