В сети представлен скрипт PowerShell для удаления функций ИИ из Windows.

Скрипт доступен в репозитории на gtihub:
https://github.com/zoicware/RemoveWindowsAI?tab=readme-ov-file

Как сказано в преамбуле проекта, цель скрипта — удалить ВСЕ ИИ функции для улучшения пользовательского опыта, конфиденциальности и безопасности, так как текущая сборка Windows 11 25H2 и будущие сборки будут включать в себя всё больше функций и компонентов ИИ.

Среди функций скрипта, в частности:

Отключение Copilot
Отключение Recall
Отключение Input Insights и сбора данных о наборе текста
Copilot в Edge
Image Creator в Paint
Удаление службы AI Fabric
Отключение действий ИИ
Отключение ИИ в Paint
Отключение голосового доступа
Отключение голосовых эффектов ИИ
Отключение ИИ в поиске по настройкам

ИТ-шники из Индии уже в России. Но есть нюансы...

"«В основном я работал в компаниях вроде Microsoft и использовал новые инструменты — ИИ, чат-боты, чат GPT и тому подобные, по сути я разработчик», — улыбаясь рассказывает журналистам смуглый мужчина в шапке и рабочей форме. С корреспондентами он говорит на английском.

Индийского IT-шника отвлекли от подметания улицы в Санкт-Петербурге. Вместе с другими 16 трудовыми мигрантами он приехал из Индии в северную столицу еще осенью прошлого года. Их устроило к себе ​​АО «Коломяжское», которое занимается уборкой и очисткой территории...."

https://www.gazeta.ru/social/2026/01/14/22334203.shtml

5 базовых концепций для высокой доступности приложения
(продолжение в следующем посте)

5 базовых концепций для высокой доступности приложения
(продолжение предыдущего поста)

Постоянная доступность приложения, особенно высоконагруженного, является одной из распространенных проблем при разработке и поддержке приложения. Рассмотрим 5 базовых концепций для высокой доступности на основе схемы:

1. Распределение нагрузки (Load Balancing)
- Суть: распределение входящих задач или запросов между несколькими экземплярами системы.
- Как реализовано на схеме: центральный элемент — Load Balancer — принимает запросы от клиентов (например, с ноутбуков или мобильных устройств) и направляет их на доступные экземпляры сервисов (Payments API, Orders API).
- Цель: предотвратить перегрузку отдельных компонентов, равномерно распределить нагрузку, повысить общую производительность и доступность системы.
- Дополнительно: Load Balancer выполняет проверки работоспособности (health checks) и перенаправляет трафик, если один из экземпляров выходит из строя.

2. Микросервисная архитектура (независимые сервисы)
- Суть: разбиение системы на небольшие независимые сервисы, которые работают автономно.
- Как реализовано на схеме: показаны отдельные сервисы — Payments API (с собственной базой данных — Payments Database) и Orders API.
- Цель: изоляция сбоев — если один сервис выходит из строя, это не влияет на работу других. Это повышает устойчивость системы (resilience).
- Пример: сбой в Orders API не затронет Payments API, и платежи продолжат обрабатываться.

3. Избыточность экземпляров (Multiple Instances)
- Суть: запуск нескольких копий (экземпляров) ключевых компонентов системы, готовых заменить основные в случае сбоя.
- Как реализовано на схеме: подразумевается, что для каждого сервиса (например, Payments API, Orders API) работают несколько экземпляров.
- Цель: гарантировать непрерывную работу системы — если основной экземпляр падает, его заменяет резервный.
- Преимущества: минимизация простоев, быстрое восстановление после сбоев.

4. Репликация данных (Data Replication)
- Суть: автоматическое копирование данных из основной базы данных (Primary Database) в резервную (Secondary Database).
- Как реализовано на схеме: стрелка с подписью «Replication» между Primary Database и Secondary Database показывает процесс синхронизации данных.
- Цель: защита данных от потери при сбое основной базы. Если Primary Database становится недоступной, система переключается на Secondary Database.
- Особенности: репликация может быть синхронной (данные копируются в реальном времени) или асинхронной (с небольшой задержкой).

5. Аварийное переключение (Failover)
- Суть: автоматический переход на резервный компонент (сервис, база данных) при сбое основного.
- Как реализовано на схеме: если основной компонент (например, Primary Database) выходит из строя, система переключается на Secondary Database (указано: «If a main component fails, you switch to a backup»).
- Цель: обеспечить непрерывность работы системы при отказах ключевых компонентов.
- Ключевые элементы:
- мониторинг состояния компонентов;
- автоматизация процесса переключения;
- минимизация времени простоя (RTO — Recovery Time Objective).

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

Представлен проект Just the Browser для чистки браузеров от излишней функциональности, напрямую не связанной с навигацией в Web (прежде всего для чистки функциональности, связанной с AI).

Проект предоставляет скрипты для изменения конфигурации Google Chrome, Microsoft Edge и Mozilla Firefox, и отключения в них сопутствующих возможностей, часто раздражающих пользователей, таких как работа с AI-сервисами, интеграция со сторонними продуктами, отправка телеметрии и показ рекомендованного контента на странице открытия новой вкладки.

Для Windows инструмент представляет скрипт PowerShell, а для Mac/Linux код написан на Shell. Код доступен на github, и там же инструкции по использованию - https://github.com/corbindavenport/just-the-browser

Что такое HTTP Header?
(продолжение в следующем посте)

Что такое HTTP Header?
(продолжение предыдущего поста)

HTTP Header — это метаданные, которые сопровождают HTTP-запросы и ответы, предоставляя дополнительный контекст о коммуникации между клиентом (браузером) и сервером. Они состоят из пар «ключ-значение» и определяют типы контента, учётные данные для аутентификации, поведение кэширования и политики безопасности.

На изображении показаны два типа заголовков: HTTP Request Header (отправляется от клиента к серверу) и HTTP Response Header (отправляется от сервера к клиенту). Разберём их подробнее.

#### 1. HTTP Request Header (заголовки запроса)

Эти заголовки отправляются от клиента (браузера) к серверу и содержат информацию о запросе, возможностях клиента и ожиданиях от ответа. На изображении представлены следующие заголовки:

- Accept: image/webp — указывает типы контента, которые клиент может обработать (в данном случае — изображения в формате WebP).
- Accept-Encoding: gzip — сообщает серверу, какие алгоритмы сжатия поддерживает клиент (здесь — gzip).
- Cookie: name=maxtext — передаёт на сервер сохранённые ранее cookies, чтобы связать запрос с конкретной сессией пользователя.
- Cache-Control: max-age=604800 — задаёт время кэширования ответа (в секундах). Значение 604800 соответствует одной неделе.
- Content-Type: text/html — определяет тип контента в теле запроса (здесь — HTML-документ).
- Content-Length: 30 — указывает размер тела запроса в байтах.
- Referer: https://name.com — показывает URL страницы, с которой был отправлен запрос (помогает серверу понять источник трафика).
- User-Agent: Mozilla/5.0 — идентифицирует браузер или клиентское приложение, отправившее запрос. Сервер может адаптировать ответ под возможности клиента.

#### 2. HTTP Response Header (заголовки ответа)

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

- Access-Control-Allow-Origin: \*** — определяет, какие источники (домены) могут обращаться к ресурсу. Звёздочка (*) означает, что доступ разрешён всем.
- **Alt-Svc: h2=":433"; ma=604800 — сообщает клиенту о поддержке альтернативных протоколов (например, HTTP/2 на порту 433) и сроке их действия (ma — max-age, в секундах).
- Cache-Control: max-age=604800 — аналогично запросу, задаёт время кэширования ответа на клиенте.
- Content-Type: image/webp — указывает тип контента в ответе (здесь — изображение в формате WebP).
- Content-Length: 30 — размер тела ответа в байтах.
- Date: Mon, 29 May 2023 17:15:36 GMT — дата и время создания ответа (в формате GMT).
- Set-Cookie: name=alex — сервер отправляет клиенту cookie для сохранения состояния сессии.
- Server: gws — сообщает о программном обеспечении сервера (здесь — Google Web Server, GWS).

#### Итог

- Заголовки запроса помогают серверу понять, что ожидает клиент, какие форматы данных он поддерживает и как обрабатывать запрос.
- Заголовки ответа дают клиенту инструкции по обработке данных (кэширование, тип контента, отправка cookies и т. д.) и содержат метаинформацию о сервере и ответе.

Приложения, созданные с помощью Vibe-кодирования, полны ошибок безопасности

Приложения, созданные с использованием Vibe-кодирования, когда разработчик предоставляет агенту полную свободу действий, скорее всего, будут небезопасными, а популярные агенты, такие как Claude Code, содержат элементарные логические ошибки.
Об этом заявил Ори Дэвид, исследователь из стартап-компании Tenzai, занимающейся вопросами безопасности, который создал три разных приложения, используя одни и те же подробные подсказки с пятью агентами кодирования, используя их стандартные LLM. Исследователь обнаружил примерно одинаковое количество уязвимостей в каждой реализации,


Согласно исследованию, агенты хорошо себя вели в отношении некоторых известных классов ошибок, таких как SQL-инъекции и межсайтовый скриптинг, но плохо справлялись с логикой авторизации и бизнес-логикой.
Примером последнего является то, что большинство агентов позволяли пользователям заказывать отрицательное количество товаров в приложении электронной коммерции и отрицательные цены при создании товаров продавцами.

Среди других распространенных недостатков — уязвимость к подделке запросов на стороне сервера (SSRF) и отсутствие лучших практик в области безопасности, таких как заголовки безопасности.

Агенты программирования не гарантируют безопасность сгенерированного кода, и тот факт, что приложения, созданные с помощью vibe-кодирования, имеют уязвимости в безопасности, не является ни удивительным, ни недостатком самих агентов. Проблема в том, что vibe-кодирование позволяет разрабатывать приложения неквалифицированным разработчикам или тем, кто обладает навыками работы с подсказками ИИ, а не навыками программирования. Если эти простые приложения содержат существенные недостатки, более сложные проекты, вероятно, будут еще менее безопасными.

https://devclass.com/2026/01/15/vibe-coded-applications-full-of-security-blunders/

Авторы Ubuntu протестировали ИИ на своей документации. Главный вывод оказался неожиданным: сэкономленное время съедается проверкой результатов.

Тестировались Claude Sonnet 4.5, Claude Haiku 4.5, GPT-5, GPT-5-mini и Gemini 3 Pro. Первая задача — перевести документацию с британского английского на американский. Claude Sonnet справился на 7 из 10, GPT-5 получил ноль баллов — просто отказался выполнять задачу без объяснения причин. Gemini работал медленно, а потом начал менять слова в обратную сторону. Когда автор указала на ошибку, модель сначала согласилась, затем "поговорила сама с собой" и заявила, что жалоба "необоснована".

На других задачах ИИ показал себя лучше. Claude написал метаописания для 250 страниц, сэкономив команде одну-две недели работы. Оптимизация линкчекера сократила время проверки с 10 минут до полутора — на 85%. Рабочий скрипт для автообновления редиректов тоже получился с первой попытки.

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

https://discourse.ubuntu.com/t/ubuntu-server-gazette-issue-11-ai-bots-shall-eat-my-docs/75029

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

Уровни дизайна системы
(продолжение предыдущего поста)

1. Level 0: Основы
На этом базовом уровне закладываются фундаментальные элементы системы:
* HTTP Methods (Методы HTTP) — основа взаимодействия между клиентом и сервером (GET, POST, PUT, DELETE и др.).
* REST APIs (REST API) — стандартизированный способ построения API для обмена данными.
* Basic Database Operations (Базовые операции с БД) — работа с базами данных (создание, чтение, обновление, удаление данных — CRUD-операции).

Этот уровень формирует «скелет» системы, без которого невозможно дальнейшее развитие архитектуры.

2. Level 1: Освоение базовых блоков
Здесь система усложняется за счёт внедрения инфраструктурных компонентов:
* Load Balancers (Балансировщики нагрузки) — распределяют нагрузку между серверами для повышения производительности и надёжности.
* Caching Strategies (Стратегии кэширования) — ускоряют доступ к данным за счёт временного хранения результатов запросов (например, Redis, Memcached).
* Message Queues (Очереди сообщений) — обеспечивают асинхронную обработку задач (например, RabbitMQ, Kafka), снижают нагрузку на систему и повышают её устойчивость.

Эти компоненты позволяют системе эффективно работать под нагрузкой и справляться с пиками запросов.

3. Level 2: Взаимосвязанные компоненты
На этом уровне система проектируется с учётом сложных сценариев:
* API (API-интерфейсы) — формализуют взаимодействие между компонентами системы.
* CQRS (Command Query Responsibility Segregation) — разделяет команды (изменение данных) и запросы (чтение данных), что упрощает архитектуру и повышает производительность.
* Use circuit breakers, retries and timeouts (Использование схем прерывания, повторных попыток и таймаутов) — защищает систему от каскадных сбоев: если один сервис недоступен, система не падает, а обрабатывает ошибку.
* Add rate limiting and backpressure (Ограничение скорости и обратная связь по нагрузке) — предотвращает перегрузку системы за счёт контроля числа запросов.
* Design idempotent endpoints (Проектирование идемпотентных конечных точек) — гарантирует, что повторные идентичные запросы не изменят состояние системы.
* Separate read and write paths (Разделение путей чтения и записи) — оптимизирует работу с данными: чтение выполняется быстрее, запись — надёжнее.

Этот уровень делает систему устойчивой к ошибкам и способной работать в сложных условиях.

4. Level 3: Надёжность и мониторинг
Здесь акцент делается на мониторинге и диагностике:
* Monitoring (Мониторинг) — сбор метрик (время отклика, загрузка ЦП, память) для отслеживания состояния системы.
* Logging (Логирование) — запись событий и ошибок для последующего анализа.
* Alerting Systems (Системы оповещения) — автоматическое уведомление о критических событиях (сбои, превышение лимитов).

Эти инструменты позволяют оперативно реагировать на проблемы и поддерживать стабильную работу системы.

5. Level 4: Масштабирование и развитие
Финальный уровень посвящён масштабируемости и гибкости:
* Scalability (Масштабируемость) — способность системы справляться с ростом нагрузки (горизонтальное и вертикальное масштабирование).
* High Availability (Высокая доступность) — минимизация простоев за счёт резервирования компонентов (например, кластеризация баз данных).
* Distributed Systems (Распределённые системы) — разделение системы на независимые узлы, работающие совместно (например, микросервисы).
* Microservices (Микросервисы) — разбиение монолита на небольшие независимые сервисы, упрощающие разработку и развёртывание.
* Event Driven Architecture (Архитектура, управляемая событиями) — система реагирует на события (например, сообщения в очереди), что повышает её гибкость.
* Handle partial failures in distributed systems (Обработка частичных сбоев в распределённых системах) — система продолжает работать, даже если некоторые узлы недоступны (например, с помощью паттернов retry, circuit breaker).

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

Таким образом, уровни дизайна системы выстраиваются от базовых принципов (Level 0) до сложной архитектуры, способной масштабироваться и эволюционировать (Level 4). Каждый уровень дополняет предыдущий, формируя надёжную, производительную и гибкую систему.

СМИ: Роскомнадзор ввел новые ограничения против Telegram

Роскомнадзор ввел новые ограничения в отношении мессенджера Telegram. Об этом сообщает телеканал «Москва 24» со ссылкой на источник на телеком-рынке.

В СМИ отметили, что пользователи активно жалуются на медленную загрузку видео. По информации источника, «это новые ограничения со стороны РКН».

Тем временем Роскомнадзор опроверг блокировку Telegram в России. «По отношению к Telegram в настоящее время новых мер ограничений не применяется», – сообщили в ведомстве.

https://t.me/infomoscow24/104004

Когда оперативка бесконечная

Жизненный цикл образа Docker
(продолжение в следующем посте)

Жизненный цикл образа Docker
(продолжение предыдущего поста)

Жизненный цикл образа Docker включает несколько ключевых этапов, которые отображены на схеме:

1. Создание Dockerfile
Разработчику необходимо создать файл конфигурации Dockerfile, в котором задаются инструкции для настройки окружения приложения. В Dockerfile указываются базовый образ (директива FROM), рабочая директория (WORKDIR), копирование файлов (COPY), выполнение команд (RUN) и другие настройки.

2. Сборка образа (Build process)
С помощью команды docker build -t my-node-app . запускается процесс сборки образа на основе Dockerfile. Docker последовательно применяет инструкции из файла, формируя слои образа. Параметр -t задаёт тег (имя) для образа — в данном случае my-node-app.

3. Теггирование образа (Tagging)
После сборки образу присваивается тег (уникальное имя), например, my-node-app. Теггирование упрощает дальнейшую работу с образом — его легче идентифицировать и использовать.

4. Хранение образа локально
Собранный образ сохраняется на локальной машине пользователя. Список локальных образов можно вывести с помощью команды docker images.

5. Удаление локального образа (при необходимости)
Если образ больше не нужен, его можно удалить с помощью команды docker rmi my-node-app. Это освобождает место на диске.

6. Аутентификация для работы с Docker Hub
Чтобы загрузить образ в публичный реестр Docker Hub, требуется аутентификация. Выполняется команда docker login, где пользователь вводит свои учётные данные Docker Hub.

7. Перетегирование для Docker Hub
Перед загрузкой в Docker Hub образ необходимо перетеггировать, добавив имя пользователя:
docker tag my-node-app username/my-node-app.
Здесь username — это логин пользователя в Docker Hub. Это обязательное условие для публикации образа.

8. Загрузка образа в Docker Hub (Push)
Выполняется команда docker push username/my-node-app, которая отправляет образ в публичный реестр Docker Hub. После этого образ становится доступным для скачивания другим пользователям.

9. Скачивание образа (Pull)
Любой пользователь может скачать опубликованный образ с Docker Hub с помощью команды docker pull username/my-node-app. Скачанный образ сохраняется локально на машине пользователя.

10. Использование образа для создания контейнеров
После скачивания образ используется для запуска контейнеров — изолированных экземпляров приложения. Контейнеры работают на основе образа и могут быть запущены с помощью команды docker run.

Таким образом, жизненный цикл Docker-образа включает создание конфигурации (Dockerfile), сборку и теггирование локального образа, его загрузку в публичный реестр (Docker Hub) и последующее скачивание и использование другими пользователями для развёртывания приложений. Каждый этап управляется специальными командами Docker CLI и обеспечивает гибкость и безопасность при работе с образами.

SSD стали дороже золота, если сравнивать цену за грамм

Портал Tom’s Hardware проанализировал рынок SSD и пришёл к выводу, что твердотельные накопители SSD большой ёмкости стали дороже золота, если сравнивать цену за грамм. Это утверждение верно для NVMe-накопителей на 8 ТБ, также к этому показателю стремительно приближаются модели с 4 ТБ. Ситуация связана с дефицитом металлов на рынке ОЗУ и SSD из-за высокого спроса со стороны компаний в сфере искусственного интеллекта.

Tom’s Hardware использовал цены на SSD в Newegg, Microcenter, Best Buy и Walmart, получив более ста вариантов. Требования были такими: NVMe SSD с интерфейсом PCIe 4.0 или 5.0 ёмкостью 4 ТБ, продаваемые магазином и имеющиеся в наличии. В анализ не стали включать накопители корпоративного класса.

Оценка среднего веса этого сегмента SSD даёт в среднем 8,2 г для моделей на 8 ТБ или 8 г в случае вариантов на 4 ТБ. Рассматривались только версии без радиаторов.
В настоящее время золото стоит $148 за грамм. Даже если брать нижний предел веса накопителя в 8 г, средняя стоимость золота составит около $1148. В то же время средняя цена потребительского накопителя на 8 ТБ достигает примерно $1476, а высокопроизводительная модель будет стоить значительно больше.

Стоимость некоторых моделей накопителей ёмкостью 4 ТБ также приближается к эквивалентной цене золота. Существует явный разрыв между более дорогими моделями. За некоторым исключением, большая часть сегмента до $800 приходится на SSD для хранения данных. Это означает, что если пользователю нужна и высокая производительность, то придётся заплатить больше.

https://www.tomshardware.com/pc-components/storage/high-capacity-nvme-ssds-are-quickly-becoming-as-expensive-as-gold-by-weight-we-ran-the-figures-heres-what-we-found

Сравнение цены золота и SSD наглядно на графике

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

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

Сеть доставки контента (CDN) — это географически распределённые серверы (также называемые пограничными серверами - edge servers), которые обеспечивают быструю доставку статического и динамического контента. Давайте разберём, как это работает.

Предположим, Боб, который живёт в Нью‑Йорке, хочет зайти на сайт электронной коммерции, размещённый в Лондоне. Если запрос отправится на серверы, расположенные в Лондоне, ответ будет довольно медленным. Поэтому мы размещаем CDN‑серверы поближе к тому месту, где живёт Боб, — и контент будет загружаться с ближайшего CDN‑сервера.

Приведённая выше схема иллюстрирует этот процесс:

1. Боб вводит в браузере www.myshop.com. Браузер ищет доменное имя в локальном кэше DNS.

2. Если доменное имя отсутствует в локальном кэше DNS, браузер обращается к DNS‑резолверу для разрешения имени. DNS‑резолвер обычно находится у провайдера интернет‑услуг (ISP).

3. DNS‑резолвер рекурсивно разрешает доменное имя (подробности см. в моём предыдущем посте). В конце концов он обращается к авторитетному серверу имён для разрешения доменного имени.

4. Если мы не используем CDN, авторитетный сервер имён возвращает IP‑адрес для www.myshop.com. Но при использовании CDN у авторитетного сервера имён есть псевдоним, указывающий на www.myshop.cdn.com (доменное имя CDN‑сервера).

5. DNS‑резолвер запрашивает у авторитетного сервера имён разрешение для www.myshop.cdn.com.

6. Авторитетный сервер имён возвращает доменное имя для балансировщика нагрузки CDN — www.myshop.lb.com.

7. DNS‑резолвер обращается к балансировщику нагрузки CDN для разрешения www.myshop.lb.com. Балансировщик выбирает оптимальный пограничный CDN‑сервер на основе IP‑адреса пользователя, провайдера пользователя, запрашиваемого контента и нагрузки на сервер.

8. Балансировщик нагрузки CDN возвращает IP‑адрес пограничного CDN‑сервера для www.myshop.lb.com.

9. Теперь мы наконец получаем фактический IP‑адрес, к которому нужно обратиться. DNS‑резолвер передаёт IP‑адрес браузеру.

10. Браузер обращается к пограничному CDN‑серверу (edge server) для загрузки контента.

На CDN‑серверах кэшируются два типа контента: статический и динамический. Первый включает статические страницы, изображения, видео; второй — результаты краевых вычислений.

Если в кэше пограничного CDN‑сервера (edge CDN server) нет нужного контента, запрос направляется на региональный CDN‑сервер. Если контент по‑прежнему не найден, запрос идёт на центральный CDN‑сервер или даже на исходный сервер — веб‑сервер в Лондоне. Это называется CDN‑распределительной сетью, где серверы развёрнуты с учётом географического расположения.

Советы по работе с PATH
(продолжение в следующем посте)