Типы криптографии
(описание в следующем посте)

Типы криптографии
(продолжение предыдущего поста)

В зависимости от устойчивости к квантовым вычислениям криптография делится на два основных класса:
1. Quantum-breakable (уязвимые для квантовых атак).
2. Quantum-secure (устойчивые к квантовым атакам).

#### 1. Quantum-breakable (уязвимые для квантовых атак)

Эти методы могут быть взломаны с помощью квантовых компьютеров. К ним относятся:

- RSA encryption (шифрование RSA):
- Сообщение шифруется с помощью публичного ключа получателя.
- Расшифровывается с помощью приватного ключа.
- Безопасность основана на сложности разложения на простые множители (вычисления приватного ключа из публичного).

- Diffie-Hellman key exchange (обмен ключами Диффи-Хеллмана):
- Два участника совместно создают общий секретный ключ по незащищённому каналу.
- Этот ключ используется для зашифрованной коммуникации.
- Безопасность основана на сложности задачи дискретного логарифма.

- Elliptic curve cryptography (криптография на эллиптических кривых):
- Используются математические свойства эллиптических кривых для генерации публичных и приватных ключей.
- Сложность восстановления приватного ключа из публичного связана с задачей дискретного логарифма на эллиптических кривых.

#### 2. Quantum-secure (устойчивые к квантовым атакам)

Эти методы разработаны для защиты от потенциальных квантовых атак. К ним относятся:

- Lattice-based cryptography (решётчатая криптография):
- Безопасность основана на сложности нахождения ближайшей точки в решётке с сотнями пространственных измерений.
- Приватный ключ ассоциируется с точкой решётки, а публичный — с произвольной точкой в пространстве.

- Code-based cryptography (криптография на основе кодов):
- Приватный ключ связан с кодом, исправляющим ошибки.
- Публичный ключ — это искажённая и ошибочная версия этого кода.
- Безопасность основана на сложности декодирования общего линейного кода.

- Multivariate cryptography (многомерная криптография):
- Основана на сложности решения систем многомерных полиномиальных уравнений.
- Использует сложные математические конструкции для обеспечения безопасности.

Резюме:
- Quantum-breakable методы эффективны сейчас, но уязвимы для будущих квантовых компьютеров.
- Quantum-secure методы разрабатываются для защиты данных в эпоху квантовых вычислений.

Полная шпаргалка по командам Docker
(продолжение предыдущего поста)

#### 1. Установка (Installation)
- Установка Docker Engine (только для Linux): [https://docs.docker.com/engine/install/](https://docs.docker.com/engine/install/).
- Установка Docker Desktop (Linux, macOS, Windows): [https://docs.docker.com/desktop/](https://docs.docker.com/desktop/).

#### 2. Команды для работы с контейнерами (Container commands)
- `docker run <image>` — создаёт и запускает новый контейнер.
- `docker run -p 8080:80 <image>` — публикует порт контейнера (80) на порт хоста (8080).
- `docker run -d <image>` — запускает контейнер в фоновом режиме (detached mode).
- `docker run -v <host>:<container> <image>` — монтирует директорию хоста в контейнер.
- `docker ps` — выводит список запущенных контейнеров.
- `docker ps --all` — выводит список всех контейнеров (запущенных и остановленных).
- `docker logs <container_name>` — получает логи контейнера.
- `docker logs -f <container_name>` — получает логи и следит за их обновлением в реальном времени (follow).
- `docker stop <container_name>` — останавливает запущенный контейнер.
- `docker start <container_name>` — запускает остановленный контейнер.
- `docker rm <container_name>` — удаляет контейнер.

#### 3. Выполнение команд внутри контейнера (Executing commands in a container)
- `docker exec <container_name> <command>` — выполняет команду внутри запущенного контейнера.
- `docker exec -it <container_name> bash` — открывает оболочку (shell) внутри запущенного контейнера для интерактивного взаимодействия.

#### 4. Команды для работы с образами (Image commands)
- `docker build -t <image> .` — создаёт новый образ из Dockerfile в текущей директории и присваивает ему тег (tag).
- `docker images` — выводит список локальных образов.
- `docker rmi <image>` — удаляет образ.

#### 5. Команды для работы с реестром контейнеров (Container registry commands)
- `docker login` — авторизуется в Docker Hub.
- `docker login <server>` — авторизуется в другом реестре контейнеров.
- `docker logout` — выходит из Docker Hub.
- `docker logout <server>` — выходит из другого реестра контейнеров.
- `docker push <image>` — загружает образ в реестр.
- `docker pull <image>` — скачивает образ из реестра.
- `docker search <image>` — ищет образы в Docker Hub.

#### 6. Системные команды (System commands)
- `docker system df` — показывает использование дискового пространства Docker.
- `docker system prune` — удаляет неиспользуемые данные (например, остановленные контейнеры, несуществующие образы).
- `docker system prune -a` — удаляет все неиспользуемые данные (включая остановленные контейнеры и образы).

#### 7. Команды Docker Compose
- `docker compose up` — создаёт и запускает контейнеры.
- `docker compose up -d` — создаёт и запускает контейнеры в фоновом режиме.
- `docker compose up --build` — пересобирает образы перед запуском контейнеров.
- `docker compose stop` — останавливает сервисы.
- `docker compose down` — останавливает и удаляет контейнеры и сети.
- `docker compose ps` — выводит список запущенных контейнеров.
- `docker compose logs` — показывает логи всех контейнеров.
- `docker compose logs <service>` — показывает логи конкретного сервиса.
- `docker compose logs -f` — показывает логи и следит за их обновлением.
- `docker compose pull` — скачивает последние образы.
- `docker compose build` — собирает или пересобирает сервисы.
- `docker compose build --pull` — скачивает последние образы перед сборкой.

Гендиректор Microsoft призвал пользователей перестать называть «шлаком» ИИ‑контент

Генеральный директор Microsoft Сатья Наделла опубликовал пост в LinkedIn, в котором подвел итоги 2025 года. В нём Наделла заявил о необходимости найти новый баланс во взаимодействии человека и ИИ вместо ставшего привычным разделения ИИ на «слоп» и «высокие технологии».

По мнению управленца, подобное разделение следует считать слишком упрощённым. Наделла отметил, что ИИ следует рассматривать как когнитивный инструмент, который усиливает возможности людей, а не побочный продукт, раскрывает человеческий потенциал.

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

https://snscratchpad.com/posts/looking-ahead-2026/

РИА Новости: сильнее всего зарплаты в России за год выросли у издателей ПО

Наиболее сильно за последний год зарплаты в России выросли у издателей программного обеспечения – сразу на 137 тысяч рублей на конец октября, следует из расчетов РИА Новости по данным статистики.

Средняя зарплата в России увеличилась за 12 последних месяцев на 13,1 тысячи рублей и составила в октябре 99,7 тысячи рублей. При этом среди отраслей рост был зафиксирован у сотрудников 258 сфер деятельности, а спад – у семи.

Еще на 69 тысяч они увеличились у рыболовов, а на 55,5 тысячи – у сотрудников холдинговых компаний. В пятерку по темпам роста также вошли занятые в сфере аренды интеллектуальной собственности – на 50,7 тысячи рублей, а также разработчики строительных проектов – на 46,3 тысячи рублей.

https://ria.ru/20260104/zarplaty-2066310216.html

Что такое взаимоблокировка (deadlock)
(продолжение в следующем посте)

Что такое взаимоблокировка (deadlock)
(продолжение предыдущего поста)

Рассмотрим взаимоблокировки: условия возникновения, способы предотвращения и стратегии восстановления.

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

Условия Коффмана

Условия Коффмана (названы в честь Эдварда Г. Коффмана‑младшего, который впервые сформулировал их в 1971 году) описывают четыре необходимых условия, которые должны присутствовать одновременно для возникновения взаимоблокировки:
* взаимное исключение (Mutual Exclusion);
* удерживание и ожидание (Hold and Wait);
* отсутствие принудительного изъятия (No Preemption);
* циклическое ожидание (Circular Wait).

Предотвращение взаимоблокировок

* Упорядочивание ресурсов: установить полный порядок для всех типов ресурсов и требовать, чтобы каждый процесс запрашивал ресурсы в строго возрастающем порядке.
* Таймауты: процесс, который удерживает ресурсы слишком долго, может быть откатан назад (выполнен откат).
* Алгоритм банкира (Banker’s Algorithm): алгоритм предотвращения взаимоблокировок, который имитирует распределение ресурсов между процессами и помогает определить, безопасно ли удовлетворять запрос на ресурс, исходя из будущего наличия ресурсов. Это позволяет избегать небезопасных состояний.

Восстановление после взаимоблокировки

* Выбор «жертвы»: большинство современных систем управления базами данных (СУБД) и операционных систем реализуют сложные алгоритмы для обнаружения взаимоблокировок и выбора «жертв». Часто допускается настройка критериев выбора «жертвы» через параметры конфигурации. Выбор может основываться на использовании ресурсов, приоритете транзакции, стоимости отката и т. д.
* Откат (Rollback): база данных может выполнить откат всей транзакции или только её части — достаточной для снятия взаимоблокировки. Откаченные транзакции могут быть автоматически перезапущены системой управления базами данных.

C# - язык года по версии TIOBE

Рейтинг TIOBE второй раз за 3 года назвал C# языком программирования года (2025 года). В комментарии от TIOBE отмечается, что "C# заслужил это звание, показав наибольший годовой рост в рейтинге. За эти годы язык претерпел фундаментальные изменения. С точки зрения проектирования языка, C# часто был одним из первых, кто перенимал новые тенденции среди основных языков. В то же время он успешно совершил два крупных парадигмальных сдвига: от языка, предназначенного только для Windows, к кроссплатформенному, и от языка, принадлежащего Microsoft, к языку с открытым исходным кодом. C# постоянно развивался в нужный момент."

Среди других победителей - Perl, который, поднялся с 32-й позиции на 11-ю и вновь вошел в топ-20, и R - вернулся в топ-10 во многом благодаря продолжающемуся росту в области науки о данных и стат. вычислений.
Среди проигравших - Go - окончательно потерял место в топ-10 в 2025 г, и Ruby, который выпал из топ-20.

https://www.tiobe.com/tiobe-index/

Базы данных NoSQL
(продолжение в следующем посте)

Базы данных NoSQL
(продолжение предыдущего поста)

Когда говорят о NoSQL, то естественно имеют ввиду базы данных, которые не используют SQL для выполнения запросов к БД. Однако в реальности мир NoSQL очень многогранен, и каждая NoSQL-БД оптимизирована под конкретные задачи. Рассмотрим основные типы БД NoSQL.

1. MongoDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- использует формат BSON (Binary JSON);
- схема не фиксирована (schema-less);
- горизонтальное масштабирование (sharding);
- репликация для высокой доступности.
- Сценарии использования:
- системы управления контентом (CMS);
- управление каталогами.

2. Cassandra (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- столбцы могут варьироваться в разных строках (wide-column);
- распределённая архитектура;
- язык запросов CQL (SQL-подобный для NoSQL);
- оптимизирована для аналитических запросов.
- Сценарии использования:
- управление временными рядами данных;
- рекомендательные системы.

3. Redis (Key-Value Store)
- Тип: Хранилище «ключ-значение».
- Особенности:
- работает в оперативной памяти (in-memory store);
- поддерживает сложные структуры данных;
- механизмы персистентности (RDB, AOF);
- репликация (primary-replica).
- Сценарии использования:
- кэширование данных;
- управление сессиями;
- таблицы лидеров в играх (gaming leaderboard).

4. Couchbase (Document Store with Key-Value Capabilities)
- Тип: Гибридная БД (документоориентированная + хранилище «ключ-значение»).
- Особенности:
- работает в режиме памяти (memory first);
- репликация между центрами обработки данных (XDCR);
- сочетает операции с документами и хранилищем «ключ-значение».
- Сценарии использования:
- системы управления контентом (CMS);
- платформы электронной коммерции.

5. Neo4j (Graph DB)
- Тип: Графовая БД.
- Особенности:
- поддерживает ACID-транзакции;
- использует язык запросов Cypher;
- индексация без дополнительных таблиц (index-free adjacency);
- кластеризация (HA cluster).
- Сценарии использования:
- социальные сети;
- системы обнаружения мошенничества (fraud detection).

6. Amazon DynamoDB (Key-Value and Document Store)
- Тип: Хранилище «ключ-значение» с поддержкой документов.
- Особенности:
- автоматическое масштабирование;
- управление через AWS;
- распределение данных между узлами;
- поддержка DynamoDB Streams.
- Сценарии использования:
- бессерверные приложения (serverless applications);
- IoT-приложения.

7. Apache HBase (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- основана на Google Bigtable;
- интеграция с Hadoop;
- автоматическое шардирование (auto-sharding);
- сильная согласованность (strong consistency).
- Сценарии использования:
- хранилища данных (data warehouse);
- крупномасштабная обработка данных (large-scale data processing).

8. Elasticsearch (Search Engine)
- Тип: Поисковая система на основе документов.
- Особенности:
- построена на Apache Lucene;
- ориентирована на документы;
- шардирование и репликация;
- RESTful API.
- Сценарии использования:
- полнотекстовый поиск (full-text search);
- анализ логов и событий (log and event data analysis).

9. CouchDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- обеспечивает согласованность данных без блокировок;
- использует RESTful API;
- модель согласованности «в конечном счёте» (eventual consistency).
- Сценарии использования:
- мобильные приложения;
- системы управления контентом (CMS).

В итоге каждая NoSQL БД оптимизирована под конкретные задачи:
- документоориентированные (MongoDB, CouchDB) — для веб-приложений и CMS;
- колоночные (Cassandra, HBase) — для аналитических запросов и временных рядов;
- хранилища «ключ-значение» (Redis, DynamoDB) — для кэширования и сессий;
- графовые (Neo4j) — для моделирования сложных связей (социальные сети, рекомендации);
- поисковые (Elasticsearch) — для полнотекстового поиска и анализа логов.

Lenovo представила первый в мире складной игровой ноутбук - Legion Pro Rollable
Его главная особенность - уникальный сворачиваемый OLED-экран. Дисплей диагональю 16 дюймов может плавно расширяться с двух сторон до 21,5 или даже 24 дюймов.
Правда, с учетом начинки (высокопроизводительная начинка от Intel и видеокарта NVIDIA GeForce RTX 5090 и т.д.) цена, наверное, будет космическая

https://hi-tech.mail.ru/news/140485-lenovo-predstavila-pervyj-v-mire-skladnoj-igrovoj-noutbuk-i-portativnuyu-konsol-na-steamos

Ограничение скорости по API (rate limiting)
(продолжение в следующем посте)

Ограничение скорости по API (rate limiting)
(продолжение предыдущего поста)

Ограничение скорости по API (rate limiting) — это механизм контроля числа запросов к API, который защищает сервер от перегрузки и злоупотреблений. На изображении показаны основные методы ограничения скорости, каждый из которых работает по-своему:

1. Time Windows (временные окна):
* устанавливает фиксированные интервалы времени, в течение которых ограничивается количество запросов;
* если лимит запросов в заданный интервал превышен, система возвращает ошибку «RATE LIMIT EXCEEDED!»;
* подходит для контроля частоты обращений к API.

2. Quota-Based (квотирование):
* задаёт общее количество запросов, разрешённых за определённый период времени (например, в день или месяц);
* как только квота исчерпана, дальнейшие запросы блокируются с сообщением «REQUEST LIMIT REACHED!»;
* позволяет равномерно распределить нагрузку на API в течение заданного периода.

3. Token Bucket (алгоритм «ведра с токенами»):
* использует систему токенов для контроля потока запросов: клиент может отправлять запросы только при наличии токенов;
* токены накапливаются с фиксированной скоростью, что обеспечивает равномерный доступ к API;
* если токенов нет, запросы задерживаются до их появления;
* эффективно сглаживает пики нагрузки.

4. IP-Based Rate (ограничение по IP-адресу):
* ограничивает количество запросов, исходящих с одного IP-адреса;
* помогает предотвратить злоупотребления со стороны отдельных клиентов или ботов;
* система анализирует IP-адрес источника запроса и блокирует дальнейшие обращения, если лимит превышен.

5. API Key-Based (ограничение по ключу API):
* связывает лимиты с конкретным API-ключом, выданным клиенту;
* позволяет настраивать индивидуальные квоты и интервалы для разных пользователей или приложений;
* обеспечивает гибкое управление доступом — например, премиум-клиентам можно выделить больше запросов;
* защищает от несанкционированного использования API.

6. Exponential Backoff (экспоненциальное замедление):
* механизм, который заставляет клиента увеличивать интервал между повторными запросами в случае ошибок или превышения лимитов;
* интервал ожидания растёт экспоненциально с каждой неудачной попыткой;
* снижает нагрузку на сервер при массовых ошибках или перегрузках.

Эти методы могут использоваться по отдельности или в комбинации для создания гибкой и надёжной системы ограничения скорости API. Они защищают сервер, обеспечивают справедливое распределение ресурсов и улучшают стабильность работы API для всех пользователей.

Анализ исправления ошибок в ядре Linux - в среднем ошибки замечают через 2 года

В результате анализа исправления 125 тысяч ошибок, помеченных в Git-репозитории тегом "Fixes:", оказалось, что среднее время обнаружения ошибок в ядре Linux составило 2.1 года. Если рассматривать только ошибки, исправленные в 2025 году, данный показатель составил 2.8 года.

30% ошибок были исправлены теми же разработчиками, что и внесли ошибки. 56.9% ошибок устраняют в течение года. 13.5% ошибок оставались незамеченными более 5 лет (если рассматривать только ошибки, исправленные в 2025 году - 19.4%). Из-за неравномерности распределения медианное время существования ошибки в коде ядра составило 8 месяцев для выборки с 2005 года и 1 год для ошибок, исправленных в 2025 году. Наиболее долго сохранявшейся в коде ошибкой стало переполнение буфера в ethtool, устранённое спустя 20.7 лет.

Cреднее время обнаружения ошибок, связанных с состояниями гонки, составило 5.1 лет, целочисленным переполнением - 3.9, обращением после освобождения памяти - 3.2, переполнением буфера и утечкой памяти - 3.1, подсчётом ссылок - 2.8, разыменованием нулевого указателя и взаимными блокировками - 2.2 года.

https://pebblebed.com/blog/kernel-bugs

Google добавил Gemini 3 в Gmail - теперь ИИ будет копаться в переписке за пользователей

Google запустил в Gmail новую модель Gemini 3, превратив почтовый клиент в "персонального проактивного ассистента" для 3 миллиардов пользователей.

Главное нововведение — AI Overviews. Теперь почте можно задавать вопросы на естественном языке, и Gemini найдет нужные письма и выдаст готовый ответ, а не список из десятков сообщений, которые пришлось бы перечитывать вручную. При открытии длинных веток переписки система автоматически генерирует резюме с ключевыми моментами.

Функция Help Me Write, которая помогает писать письма с нуля или редактировать черновики, теперь доступна всем бесплатно. Suggested Replies (обновленная версия Smart Reply) анализирует контекст переписки и предлагает ответы в стиле пользователя. Proofread проверяет грамматику, тон и стиль перед отправкой — но эта функция только для подписчиков Google AI Pro и Ultra.

Добавлен AI Inbox - своего рода персональный фильтр, который отсеивает шум и выделяет важное (пока доступен только тестировщикам, широкий запуск обещают в ближайшие месяцы).

Новые функции начали обкатывать в США на английском языке. Часть возможностей бесплатна, расширенные — для подписчиков Google AI Pro и Ultra. Другие регионы и языки — позже.

https://blog.google/products-and-platforms/products/gmail/gmail-is-entering-the-gemini-era/

PS. Интересно, как скоро все эти данные можно будет увидеть в ответах Gemini или в открытом поиске...

Архитектура микросервисов
(продолжение в следующем посте)

Архитектура микросервисов
(продолжение предыдущего поста)

Архитектура микросервисов состоит из ряда звеньев/уровней. Рассмотрим типичную архитектуру микросервисов.

1. Уровень клиента (Client)
На верхнем уровне находятся клиентские приложения, которые взаимодействуют с системой:
* Web (веб-браузер);
* Mobile (мобильное приложение);
* PC (десктопное приложение).

Клиенты отправляют запросы в систему, которые затем проходят через промежуточные компоненты.

2. Промежуточный уровень (инфраструктура доставки контента и балансировки нагрузки)
* CDN (Content Delivery Network) — распределённая сеть доставки статического контента (изображений, CSS, JS-файлов), ускоряет загрузку за счёт кэширования данных ближе к пользователю.
* Static Content — хранилище статических ресурсов, обслуживаемых через CDN.
* Load Balancer (балансировщик нагрузки) — распределяет входящие запросы между микросервисами для оптимизации производительности и обеспечения отказоустойчивости.

3. API Gateway (шлюз API)
* Единая точка входа для клиентских запросов.
* Выполняет маршрутизацию запросов к соответствующим микросервисам.
* Агрегирует ответы от микросервисов.
* Обеспечивает сквозные функции: аутентификацию, авторизацию, мониторинг, логирование.
* Взаимодействует с Identity Provider (поставщиком идентификации) для управления доступом пользователей.

4. Уровень микросервисов (Microservices)
* Система разбита на домены (Domain 1, Domain 2) — логически связанные группы сервисов, отвечающие за отдельные бизнес-задачи.
* Внутри доменов работают микросервисы (Service A, Service B, Service C):
* каждый сервис — независимый модуль с собственной логикой и базой данных;
* сервисы взаимодействуют друг с другом через API или брокер сообщений;
* могут разрабатываться, развёртываться и масштабироваться независимо.

5. Сервисная регистрация и обнаружение (Service Registry and Discovery)
* Хранит информацию о всех запущенных микросервисах (IP-адреса, порты, статусы).
* Позволяет сервисам динамически находить друг друга без жёсткой привязки к адресам.
* Ключевой компонент для обеспечения гибкости и масштабируемости системы.

6. Координация сервисов (Service Coordination, Zookeeper)
* Обеспечивает согласованность работы микросервисов.
* Управляет распределёнными блокировками, конфигурациями и состоянием сервисов.
* Использует Apache Zookeeper или аналогичные инструменты.

7. Брокер сообщений (Message Broker)
* Обеспечивает асинхронную коммуникацию между сервисами.
* Примеры: RabbitMQ, Kafka, ActiveMQ.
* Позволяет сервисам обмениваться событиями и сообщениями без прямого соединения.
* Повышает устойчивость системы к временным сбоям.

8. Уровень хранения данных (Databases)
* Каждый домен или сервис может использовать собственную базу данных (Database A, Database B):
* обеспечивает изоляцию данных и независимость развёртывания;
* позволяет выбирать оптимальные СУБД для каждой задачи (например, MongoDB для документов, PostgreSQL для реляционных данных).

9. Дополнительные компоненты
* Identity Provider — управляет учётными записями пользователей, аутентификацией и авторизацией.
* API Gateway, Load Balancer и CDN работают совместно для обеспечения высокой доступности и безопасности системы.

В итоге микросервисная архитектура, представленная на схеме, обеспечивает:
* модульность (каждый сервис независим);
* масштабируемость (можно масштабировать отдельные сервисы);
* устойчивость (сбои в одном сервисе не влияют на работу других);
* гибкость (можно использовать разные технологии для разных сервисов);
* эффективное распределение нагрузки (благодаря балансировщику и CDN);
* безопасный доступ (через API Gateway и Identity Provider).