Microsoft предложит до 60 тысячам сотрудников добровольно уйти с компенсацией.

Программа охватит подходящих под условия сотрудников в США, Великобритании, Канаде и Индии, сообщает The Verge.

Среди участвующих направлений – Copilot, CoreAI, Windows + Devices, Xbox, финансы и HR. Некоторые подразделения участвуют частично, а маркетинг, коммерческий бизнес и безопасность исключены.

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

60 тысяч – число сотрудников, которым доступно предложение, а не объявленное количество увольнений. Сколько человек его примут, пока неизвестно.

Программа появилась спустя несколько месяцев после сокращения 4800 рабочих мест.

https://www.theverge.com/tech/1018666/microsoft-expands-buyouts-60000-employees-eligible

Один CVE - три уязвимости: раскрыты детали взлома Oracle PeopleSoft, которым пользовалась ShinyHunters.

Исследователи ZDI выяснили, что за CVE-2026-35273 с оценкой CVSS 9.8 скрываются три ошибки в двух компонентах PeopleSoft.

Начало цепочки – SSRF: атакующий заставляет сервер отправить запрос к собственному внутреннему интерфейсу управления.

Этот интерфейс по умолчанию доверяет обращениям с 127.0.0.1. Поэтому внешний запрос, перенаправленный самим сервером, проходит проверку как локальный.

Полученный доступ открывает два пути к выполнению кода без авторизации: через произвольную запись файлов или небезопасную обработку XML.

Oracle закрыла все три проблемы 10 июня, объединив их под одним CVE. ShinyHunters эксплуатировала цепочку ещё до выхода исправления, первоначально атакуя преимущественно университеты.

Затронуты PeopleTools 8.61 и 8.62. Блокировка отдельных URL на WAF не заменяет патч. Если сервер уже взломан, обновления также недостаточно – нужны проверка компрометации и смена доступных ему учётных данных.

https://thehackernews.com/2026/10/shinyhunters-exploited-oracle.html

SQL-ловушка: этот UPDATE может незаметно испортить данные в продакшене

Код корректный, PostgreSQL не выдаст ошибку. Но результат не так очевиден.

Есть таблица товаров:

CREATE TABLE products (
    id INT PRIMARY KEY,
    price INT
);

INSERT INTO products VALUES (1, 100);

Применяем скидки:

WITH discounts(id, amount) AS (
    VALUES (1, 10), (1, 20)
)
UPDATE products p
SET price = p.price - d.amount
FROM discounts d
WHERE p.id = d.id;

SELECT price FROM products;

Что вернёт последний SELECT?

А) 90
Б) 80
В) 70
Г) 80 или 90, результат не гарантирован

Один запрос, две скидки на один товар. Как PostgreSQL обработает такой UPDATE?

Подвох связан с поведением UPDATE ... FROM, о котором легко забыть даже при работе с реальными базами.

ORM превратила один SQL-запрос в 51. Разработчик даже не заметил

Знакомая ситуация: код выглядит чисто, никаких SQL-запросов вручную, всё через ORM.

Например, в Django:

posts = Post.objects.all()[:50]

for post in posts:
    print(post.author.name)

Кажется, что мы просто получаем 50 постов с авторами. Но на практике это может вызвать 51 запрос к базе данных.

Один запрос загружает посты, а ещё 50 отдельно получают авторов.

Это классическая проблема N+1 queries. Причём чем больше записей, тем больше обращений к БД.

Исправляется одной строкой:

posts = Post.objects.select_related("author")[:50]

Теперь Django использует JOIN и получает посты вместе с авторами одним запросом.

ORM избавляет от написания SQL, но не от необходимости понимать, какой SQL выполняется.

Именно поэтому при оптимизации API полезнее сначала посмотреть на количество запросов, чем переписывать Python-код ради нескольких миллисекунд.

SQL-задача с подвохом: найдите пользователей, которые вернулись после 30 дней молчания

Представьте, что вы анализируете активность пользователей сервиса. Нужно найти тех, кто вернулся после длительного перерыва.

Есть таблица PostgreSQL:

CREATE TABLE events (
    user_id INT,
    event_time TIMESTAMP
);

INSERT INTO events VALUES
(1, '2026-10-01 10:00'),
(1, '2026-10-01 12:00'),
(1, '2026-11-01 09:00'),
(1, '2026-11-02 14:00'),
(2, '2026-10-01 10:00'),
(2, '2026-10-31 10:00'),
(3, '2026-09-01 10:00'),
(3, '2026-11-05 10:00'),
(3, '2026-11-05 11:00');

Задача: для каждого пользователя найти все даты возвращения после 30 полных календарных дней без активности.

Ожидаемый результат:

| user_id | return_date |
|---|---|
| 1 | 2026-11-01 |
| 3 | 2026-11-05 |

Условия: несколько событий в один день считаются одной активностью. День последней активности и день возвращения в период молчания не входят. Например, между 1 октября и 31 октября только 29 полных дней без активности, а между 1 октября и 1 ноября уже 30.

Ограничение: решите задачу одним SQL-запросом, без процедур, временных таблиц и циклов.

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

Как бы вы решили эту задачу на PostgreSQL?

RAG без векторной базы: PageIndex набрал 40 тысяч звёзд на GitHub

PageIndex предлагает другой подход к поиску информации в документах. Вместо embeddings, разбиения текста на чанки и векторного поиска используется иерархический индекс и рассуждения LLM.

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

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

Результаты разработчиков:

98,7% точности на FinanceBench.

До 97% экономии токенов при ответах на вопросы по документам с использованием Page Search API.

В 16,6 раза дешевле, чем передавать модели целый PDF на 420 страниц при каждом запросе, в одном из сравнительных тестов.

Это результаты собственных бенчмарков проекта, поэтому для конкретной RAG-системы их стоит перепроверять.

Есть Python SDK, локальная индексация PDF и интеграции с ИИ-агентами. Лицензия MIT.

pip install -U pageindex

PageIndex особенно интересно попробовать там, где обычный vector RAG теряет контекст между разделами длинного документа.

GitHub: https://github.com/VectifyAI/PageIndex

PostgreSQL: от SQL до внутреннего устройства

Практический курс на русском для разработчиков, аналитиков и инженеров, которым важно понимать не только синтаксис запросов, но и поведение базы под нагрузкой. Вы построите учебный сервис заказов, исследуете планы запросов, воспроизведёте блокировки и разберёте MVCC, WAL и vacuum.

https://github.com/justxor/postgresql-deep-dive-ru

NVIDIA выпустила Auto Ontology: теперь ИИ-агенты могут понимать корпоративные базы данных и самостоятельно писать SQL

NVIDIA открыла исходный код Auto Ontology - Python-платформы, которая создаёт семантический слой поверх баз данных и помогает ИИ-агентам работать с корпоративной информацией.

Как это работает:

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

Поддерживаются 10 источников данных: PostgreSQL, MySQL, Snowflake, Databricks, ClickHouse, Trino, DuckDB, SQLite и другие.

Отдельно интересна интеграция с MCP: подключить онтологию к Claude Desktop, Cursor и другим агентам можно через MCP-сервер.

В стеке Python, FastAPI, PostgreSQL, pgvector и Next.js. Есть Docker Compose и Helm для Kubernetes.

Лицензия Apache 2.0.

GitHub: https://github.com/NVIDIA/auto-ontology