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

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

Жалобы на сбой при доступе к сайту РКН начали появляться после 10:00 мск на профильных ресурсах, а сообщения о неполадках в работе сайта РКН поступают от пользователей из разных регионов страны.

https://www.kommersant.ru/doc/8476250

Хакеры атаковали ресурсы РКН и Минобороны

Как ранее сообщалось, сайт Роскомнадзора оказался недоступен. Оказалось, что информационные ресурсы Роскомнадзора и Минобороны России подверглись DDoS-атаке. Атакующие серверы расположены преимущественно в России, а также в Китае, США, Нидерландах и Великобритании, сообщила пресс-служба РКН.

В РКН сообщили, что DDoS-атака началась 27 февраля в 09:11 мск. Помимо ресурсов Минобороны и РКН, хакеры атаковали инфраструктуру Главного радиочастотного центра (ФГУП «ГРЧЦ»). Скорость атаки достигает 36,9 млн пакетов в секунду, а мощность — 33 Гбит/с.

«Осуществляется сложная мультивекторная атака на разных сетевых уровнях, в том числе с имитацией действий пользователей»,— сообщили в ведомстве

Специалисты центра мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) отделили вредоносный трафик и направили на серверы очистки. Они пытаются локализовать источники атаки и места расположения ботнетов.

https://www.kommersant.ru/doc/8476580

Как работает бекап с шардингом базы данных и без шардинга

Ученые: мозг «портится» из-за коротких видео. Нейросети также влияют на работу мозга негативно.

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

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

Эксперты дали несколько советов, как улучшить ситуацию. Так, не стоит использовать любые устройства с экранами в спальне. Кроме того, можно включать различные ограничения для приложений с бесконечной прокрутки ленты по типу TikTok. Также не рекомендуется постоянно пользоваться чат-ботами, потому что слишком большая легкость вредна для мозга. «Нам нужно немного трения, усилий, вызова. Это часть обучения», — подчеркнули специалисты.

https://www.washingtonpost.com/wellness/2026/02/20/brain-rot-social-media/

Google выпустил вторую бета-версию ОС Android 17. В Android 17 Beta 2 появились новые функции, направленные на улучшение многозадачности, безопасности, удобства разработки и взаимодействия между устройствами. Некоторые из ключевых нововведений:

1. Режим многозадачности Bubbles. Позволяет свернуть приложение в небольшое плавающее окно, которое можно перемещать по экрану. Чтобы активировать функцию, нужно долго нажимать на иконку приложения на рабочем столе. На устройствах с большим экраном (планшетах, складных смартфонах) появилась специальная панель Bubbles Bar в панели задач, где можно упорядочивать и управлять этими окнами. Пока неясно, будет ли функция доступна на обычных смартфонах с небольшим экраном.

2. Новый системный инструмент выбора контактов. При запросе доступа к контактам приложение теперь получает только те данные, которые пользователь явно выбрал (например, только email или номер телефона), и только в рамках одного сеанса. Это снижает потребность в широком разрешении READ_CONTACTS и поддерживает как личный, так и рабочий профиль.

3. API-интерфейс EyeDropper. Инструмент для разработчиков, который позволяет запрашивать цвет любого пикселя на экране без необходимости получать разрешения на захват экрана. Пользователь сам выбирает область для определения цвета через управляемый платформой интерфейс с «пипеткой», что обеспечивает безопасность.

4. API Handoff. Позволяет передать состояние приложения на находящееся поблизости другое Android-устройство (например, планшет) и продолжить работу там.

5. Новые API для навигации в помещениях:
* UWB DL-TDOA — определение позиции устройства внутри здания с помощью Wi-Fi для навигации в помещениях.
* Proximity Detection — обнаружение находящихся поблизости устройств через Wi-Fi.

6. Разрешение ACCESS_LOCAL_NETWORK. Ограничивает доступ приложений к локальной сети. Теперь для сканирования устройств в локальной сети (например, элементов умного дома) потребуется отдельное разрешение. Это защищает от скрытого отслеживания пользователей вредоносными программами.

7. Улучшенная обработка жестов тачпада в играх. Ранее тачпады передавали точные координаты касания пальцев, что вызывало проблемы в играх от первого лица. В Android 17 Beta 2 система по умолчанию распознаёт движения и прокрутку аналогично классической мыши. При этом прежний режим сохраняется, а для получения старых данных о точном положении пальцев разработчики могут явно запросить захват в «абсолютном» режиме.

8. Задержка доступа к SMS с OTP. Для сообщений с одноразовыми паролями (OTP) без форматов WebOTP или SMS Retriever доступ для большинства приложений задерживается на три часа. Исключение сделано для стандартных клиентов SMS, голосовых помощников и программ-компаньонов для подключённых устройств.

9. Объединение разделов настроек. Разделы «Аккаунты» и «Резервное копирование» объединены в единый пункт «Аккаунты и резервное копирование».

10. Визуальные изменения в шторке быстрых настроек. Индикаторы использования местоположения, камеры, микрофона, а также кнопка спутниковой связи стали более заметными.

Кроме того, в Android 17 Beta 2 были исправлены ошибки, обнаруженные в предыдущей тестовой сборке. Например, устранены проблемы с случайным перезапуском приложений, зависаниями интерфейса, ошибками в отображении списка запущенных приложений и другие.

https://android-developers.googleblog.com/2026/02/the-second-beta-of-android-17.html

Эволюция мобильных телефонов с 1991 по 2020-е года

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

Как работает SSH
(продолжение предыдущего поста)

SSH (Secure Shell) обеспечивает безопасное удалённое управление операционной системой с использованием шифрования, обеспечивая защищённый обмен данными между клиентом и сервером благодаря:

- согласованию версий и алгоритмов;
- обмену ключами и расчёту общего сеансового ключа;
- аутентификации с использованием пар публичных и приватных ключей;
- шифрованию всех передаваемых данных с помощью сеансового ключа.

Процесс работы SSH можно разделить на несколько этапов, как показано на схеме:

1. Установление соединения (Connection Establishment)
- SSH-сервер слушает запросы на подключение (шаг 1: «Listens to connection requests»).
- SSH-клиент отправляет запрос на соединение (шаг 2: «Sends a connection request»).
- Устанавливается TCP-соединение между клиентом и сервером (шаг 3: «Establishes a TCP connection»).

2. Согласование версии (Version Negotiation)
- Сервер отправляет список поддерживаемых версий протокола SSH (шаг 4: «Sends the supported versions»).
- Клиент отвечает, указывая версию, которую будет использовать (шаг 5: «Responds with the version to be used»).
- Сервер проверяет, успешна ли negotiation версии (шаг 6: «Checks whether the version negotiation is successful»).

3. Согласование алгоритмов (Algorithm Negotiation)
- Клиент отправляет информацию о поддерживаемых алгоритмах шифрования (шаг 7: «Sends information about the supported algorithms»).
- Клиент и сервер согласовывают алгоритмы, которые будут использоваться для шифрования и аутентификации (шаг 8: «Negotiates various algorithms in sequence»).

4. Обмен ключами (Key Exchange)
- Сервер отправляет клиенту простые числа (G, P) и свой публичный ключ (y) (шаг 10: «Sends prime numbers G, P, and server public key y»).
- Клиент отправляет свой публичный ключ (x) (шаг 11: «Sends client public key x»).

5. Расчёт сеансового ключа (Session Key Calculation)
- Клиент вычисляет сеансовый ключ (K), используя:
- публичный ключ сервера (y);
- свой приватный ключ (a) (отмечено как шаг 12: «Calculates the session key K based on the server public key y and the client private key a»).
- Сервер вычисляет тот же сеансовый ключ (K), используя:
- публичный ключ клиента (x);
- свой приватный ключ (b) (отмечено как шаг 12: «Calculates the session key K based on the client public x and the server private key b»).

6. Аутентификация пользователя (User Authentication / Key Authentication)
- Клиент использует свой приватный ключ для подписи сообщений (шаг 13: «Uses the client private key for signature»).
- Клиент отправляет подписанные сообщения на сервер (шаг 14: «Sends signed messages»).
- Сервер использует публичный ключ клиента для проверки подписи (шаг 15: «Uses the client public key for signature verification»).

7. Запрос сеанса (Session Request)
- После успешной аутентификации клиент отправляет запрос на начало сеанса (шаг 16: «Sends a session request»).
- Сервер отвечает на запрос, подтверждая начало сеанса (шаг 17: «Responds to the session request»).

8. Взаимодействие в сеансе (Session Interaction)
- Клиент отправляет зашифрованный запрос команды на сервер (шаг 18: «Sends an encrypted command request»).
- Сервер расшифровывает запрос с помощью сеансового ключа (шаг 19: «Decrypts the command request using the session key»), выполняет команду и отправляет зашифрованный результат обратно клиенту (шаг 20: «Sends the encrypted execution result»).
- Клиент расшифровывает результат с помощью сеансового ключа и отображает его в терминале (шаг 21: «Uses the session key to decrypt the execution result and displays it on the terminal»).

В Калифорнии принят закон об интеграции в ОС API для проверки возраста

Сенат штата Калифорния одобрил и губернатор затем подписал закон, который предписывает добавbnm в операционные системы возможности для указания возраста пользователя на этапе регистрации учётной записи и предоставления приложениям программного интерфейса для определения возраста текущего пользователя.
Законопроект вступит в силу 1 января 2027 года и, судя по всему, касается в том числе Windows, MacOS и Linux. Аналогичный законопроект находится на рассмотрении в штате Колорадо.

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

Загруженные и запущенные приложения должны иметь возможность получать от операционной системы информацию о возрасте в 4 градациях: младше 13 лет, от 13 до 16 лет, от 16 до 18 лет, 18 лет и старше.
Разработчик приложения должен использовать полученную информацию о возрасте для соблюдения законодательства о защите детей в интернете.

https://news.ycombinator.com/item?id=47181208

Некоторые программисты настолько суровы, что даже конструкцию if считают плохой практикой

Стратегии масштабирования распределённых систем
(продолжение в следующем посте)

Стратегии масштабирования распределённых систем
(продолжение предыдущего поста)

1. Stateless Services (сервисы без хранения состояния)
* суть: сервисы не сохраняют состояние между запросами — каждый запрос обрабатывается независимо;
* преимущества: лёгкость горизонтального масштабирования, так как экземпляры сервисов можно добавлять без влияния на работу других;
* реализация: размещение нескольких экземпляров сервисов в разных зонах доступности (AZ — Availability Zone), с сохранением состояния в отдельной базе данных;
* пример: микросервисы, обрабатывающие HTTP-запросы без сохранения сессии.

2. Horizontal Scaling (горизонтальное масштабирование)
* суть: добавление дополнительных серверов/инстансов для распределения нагрузки;
* механизм: использование группы автоматического масштабирования (Auto Scaling Group), которая добавляет/удаляет инстансы в зависимости от нагрузки;
* параметры:
* Desired Capacity (желаемая ёмкость) — целевое количество инстансов;
* Maximum Capacity (максимальная ёмкость) — лимит на количество инстансов;
* Scale out as needed (расширение по мере необходимости) — автоматическое добавление инстансов при росте нагрузки;
* примеры: веб-серверы, микросервисы в Kubernetes.

3. Load Balancing (балансировка нагрузки)
* суть: распределение входящих запросов между несколькими серверами для равномерной загрузки;
* задачи:
* предотвращение перегрузки отдельных серверов;
* повышение отказоустойчивости (при выходе из строя одного сервера нагрузка перераспределяется);
* сокращение времени отклика;
* компоненты: балансировщик нагрузки (Load Balancer), который направляет запросы на доступные серверы;
* примеры: NGINX, AWS ELB (Elastic Load Balancer), HAProxy.

4. Caching (кэширование)
* суть: хранение часто используемых данных в быстрой памяти (кэше) для ускорения доступа;
* этапы:
1. Read from Cache (чтение из кэша) — сначала система проверяет наличие данных в кэше;
2. Read from Database (чтение из базы данных) — если данных нет в кэше, они загружаются из БД;
3. Update Cache (обновление кэша) — полученные данные сохраняются в кэше для последующих запросов;
* технологии: Redis, Memcached, кэширование на уровне приложения;
* преимущества: снижение нагрузки на БД, ускорение работы приложения.

5. Database Replication (репликация базы данных)
* суть: создание копий (реплик) базы данных для распределения нагрузки и повышения доступности;
* архитектура:
* Primary (основная БД) — принимает записи (writes) и синхронизирует изменения с репликами;
* Replica (реплики) — копируют данные из Primary, обрабатывают чтения (reads);
* преимущества:
* повышение доступности (при сбое Primary запросы перенаправляются на реплики);
* распределение нагрузки (чтения распределяются между репликами);
* резервное копирование данных.
* примеры: MySQL Replication, PostgreSQL Streaming Replication.

6. Database Sharding (шардирование базы данных)
* суть: разделение базы данных на части (шарды) и размещение их на разных серверах для горизонтального масштабирования;
* механизм: данные распределяются по ключу (например, ID пользователя), чтобы запросы обрабатывались на соответствующем шарде;
* преимущества:
* масштабирование write-операций (записи распределяются по шардам);
* ускорение запросов за счёт параллельной обработки;
* управление объёмом данных (каждый шард обрабатывается отдельным сервером).
* недостатки: усложнение логики запросов (особенно для операций, затрагивающих несколько шардов).
* примеры: MongoDB Sharding, Cassandra.

7. Async Processing (асинхронная обработка)
* суть: отделение обработки задач от основного потока выполнения для повышения производительности и масштабируемости;
* архитектура:
* Server (сервер) — принимает запросы и помещает задачи в очередь;
* Workers (воркеры) — отдельные процессы/контейнеры, которые обрабатывают задачи из очереди;
* компоненты:
* очередь задач (Task Queue) — промежуточное хранилище для задач (например, RabbitMQ, Kafka);
* воркеры — обрабатывают задачи параллельно;
* преимущества:
* снижение нагрузки на основной сервер;
* возможность масштабирования обработки (добавление воркеров при росте нагрузки);
* устойчивость к пикам нагрузки (задачи накапливаются в очереди и обрабатываются постепенно).
* примеры: обработка платежей, отправка уведомлений, ETL-процессы.

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

Алгоритмическая сложность различных типов сортировок массива

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

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

1. Client-Server Architecture (Клиент-серверная архитектура)
- Суть: задачи распределены между клиентами и серверами. Клиенты отправляют запросы, серверы обрабатывают их и возвращают результаты.
- Компоненты:
- Клиент (Client) — инициирует запросы (например, веб-браузер, мобильное приложение).
- Интернет (Internet) — канал передачи данных.
- Load Balancer (балансировщик нагрузки) — распределяет запросы между серверами для оптимизации производительности.
- Сервис (Service) — обрабатывает запросы и взаимодействует с базой данных.
- CDN (Content Delivery Network) — ускоряет доставку статического контента, снижая нагрузку на сервер.
- Преимущества: масштабируемость, централизованное управление, надёжность.
- Недостатки: зависимость от сервера, затраты на инфраструктуру, необходимость постоянного подключения к сети.
- Примеры: веб-сайты, электронная почта, онлайн-игры

2. Async Task Execution with Queues (Асинхронное выполнение задач с очередями)
- Суть: задачи выполняются асинхронно через очереди, что позволяет контролировать параллелизм и порядок выполнения.
- Компоненты:
- Presentation Layer (уровень представления) — взаимодействует с пользователем.
- Business Logic Layer (уровень бизнес-логики) — обрабатывает логику приложения.
- Data Access Layer (уровень доступа к данным) — работает с базой данных.
- Очереди — хранят задачи для асинхронной обработки.
- Преимущества: предотвращение перегрузки системы, управление ресурсами, последовательное выполнение задач (например, финансовые транзакции).
- Примеры использования: обработка больших объёмов запросов, фоновые задачи (отправка писем, обработка изображений)

3. Serverless Architecture (Бессерверная архитектура)
- Суть: разработчики не управляют серверами, а фокусируются на написании функций, которые запускаются по требованию облачным провайдером.
- Компоненты:
- Lambda Function — основная функция, обрабатывающая события.
- Lambda Worker — исполнители задач, запускаемые по мере необходимости.
- Особенности: модель Functions as a Service (FaaS) — код загружается в облако, провайдер управляет ресурсами.
- Преимущества: масштабируемость, снижение затрат, ускорение разработки, автоматическое управление инфраструктурой.
- Недостатки: ограниченный контроль над средой выполнения, сложности с отладкой, потенциальные проблемы с безопасностью.
- Примеры: AWS Lambda, Google Cloud Functions

4. Pipes and Filters (Каналы и фильтры)
- Суть: процесс обработки данных разбивается на шаги, каждый из которых выполняется отдельным обработчиком (фильтром). Данные передаются через каналы.
- Компоненты:
- Data Source (источник данных) — начальная точка потока данных.
- Filters (Filter 1, Filter 2, Filter 3) — обрабатывают данные, трансформируя их.
- Data Sink (потребитель данных) — конечная точка потока.
- Преимущества: модульность, возможность параллельной обработки, лёгкость замены и перестановки фильтров.
- Недостатки: фильтры могут тратить больше времени на преобразование данных, чем на их обработку.
- Примеры: оболочка UNIX Shell, архитектура компилятора (лексер, парсер, семантический анализатор, генератор кода)

5. Event-Driven Architecture (Событийно-ориентированная архитектура)
- Суть: компоненты системы реагируют на события (изменения состояния кода, действия пользователя). Взаимодействие асинхронное.
- Компоненты:
- Producer (производитель) — генерирует события.
- Consumers (потребители) — обрабатывают события.
- Особенности: события передаются по каналам (TCP/IP, файлы JSON/XML), брокеры обеспечивают сохранность событий при сбоях.
- Преимущества: высокая масштабируемость, гибкость, бесшовная интеграция, быстрая реакция на события.
- Недостатки: сложность проектирования, обеспечение согласованности событий в распределённых системах.
- Примеры: обработка заказов в интернет-магазинах, системы IoT, платформы Uber, Netflix

6. Microservices Architecture (Микросервисная архитектура)
- Суть: приложение разбивается на небольшие независимые сервисы, которые взаимодействуют через API.
- Компоненты:
- Service — отдельный микросервис, выполняющий конкретную функцию.
- Базы данных — каждая служба может иметь свою базу данных.
- Преимущества: лёгкость масштабирования, независимость развёртывания, возможность использования разных технологий для разных сервисов.
- Недостатки: сложность тестирования, накладные расходы на обмен данными между сервисами, необходимость синхронизации.
- Примеры: крупные веб-приложения, системы с высокой нагрузкой (например, Amazon, Netflix)

7. Monolithic Architecture (Монолитная архитектура)
- Суть: все компоненты приложения объединены в единую кодовую базу и развёртываются как единое целое.
- Компоненты:
- Web Layer (веб-слой) — взаимодействует с пользователем.
- Components (Component A, B, C) — модули приложения, выполняющие различные функции.
- Shared DB (общая база данных) — хранит данные для всех компонентов.
- Преимущества: простота разработки и развёртывания, низкая сложность взаимодействия между компонентами.
- Недостатки: сложность масштабирования, зависимость компонентов друг от друга, трудности с внедрением новых технологий.
- Примеры: традиционные корпоративные приложения, небольшие веб-сайты

Как внедрение нейросетей выходит бизнесу боком

Предприниматели по всему миру с энтузиазмом внедряют ИИ, хотя помощь компьютера далеко не всегда идет им на пользу.

Владелец небольшого онлайн-магазина из Великобритании завел чат-бота, чтобы тот отвечал на вопросы клиентов с 18:00 до 9:00, когда бизнесмен отдыхает. Полгода все шло отлично, пока в начале февраля не попался хитрый покупатель. Вместо того чтобы расспрашивать помощника о товарах, он принялся выпрашивать скидку. Сначала ИИ согласился скинуть 25%, а через час дошел и до 80%.

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

В ноябре прошлого года руководство одной фирмы доверило ИИ анализировать весь ее бизнес. Искусственный разум покорил начальство, мгновенно выдавая подробные отчеты, снабженные красивыми графиками. Более 2 месяцев на основе этих данных принимались важнейшие решения вроде расширения географии продаж, а также готовились финансовые презентации для совета директоров и инвесторов. Судя по отчетам, бизнес компании стремительно шел в гору – пока кто-то не попросил перепроверить одну из цифр, упомянутых ИИ. Однако этого показателя нигде не нашлось. Инцидент стал поводом для масштабного аудита, который выявил множество расхождений отчетов нейросети с реальностью.
ИИ путал данные про разные продукты и придумывал нужные цифры, лишь бы отчет получался красивым. Теперь компания пересматривает все решения за IV квартал, принятые на основе сгенерированной ИИ информации.

В декабре 2025 г. у облачного сервиса Amazon Web Services произошел сбой, на устранение которого ушло около 13 часов. Как узнала Financial Times, инженеры разрешили ИИ-инструменту Kiro внести изменения в систему. Алгоритм решил, что проще всего будет стереть весь код и переписать его заново. В самой компании отрицают причастность ИИ к проблеме. К ошибке привели некорректные действия одного из пользователей. Сбой затронул только один сервис в одном из двух регионов материкового Китая, уверяют там.

https://www.vedomosti.ru/technology/articles/2026/02/28/1179513-iskusstvennaya-pomosch

Cокеты и вообще сетевые возможности .NET на Linux получат прирост производительности – они перерабатываются для использования API io_uring (io_uring – это интерфейс системного вызова для Linux, он нужен для асинхронных операций ввода-вывода)

Один из разработчиков .NET - Бен Адамс (Ben Adams) подтвердил существенное улучшение производительности сокетов Linux .NET благодаря переходу на API io_uring.
По его словам, обновление снизит нагрузку на центральный процессор на 15-40% при каждом запросе HTTP/1.1. Пропускная способность на одно соединение HTTP/2 улучшится на 5-15%. Кроме того, обновление снизит нагрузку на оперативную память для неактивных соединений на 30-50%; снизит задержки на 10-20% на запрос для кратковременных соединений при исходящих запросах HttpClient (между микросервисами), уменьшит задержки на 5-15% на каждый запрос при работе с драйверами баз данных (Npgsql, MySQL Connector, Redis)

https://www.neowin.net/news/linux-about-to-get-big-performance-boost-from-a-native-feature-windows-11-already-borrowed/

Эффект стратегий масштабирования
(продолжение в следующем посте)