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).

Сервис по поиску работы LinkedIn опубликовал список из 25 профессий, на которые за последние три года спрос в США вырос сильнее всего. Лидерами рейтинга оказались ИИ‑инженеры.

Весь топ-5:
1. Artificial Intelligence Engineers (ИИ‑инженеры)
2. AI Consultants and Strategists (ИИ‑консультанты и стратеги)
3. New Home Sales Specialists (специалисты по продаже недвижимости)
4. Data Annotators (специалисты по разметке данных для обучения ИИ)
5. AI/Machine Learning Researchers (исследователи ИИ и машинного обучения)

Таким образом, в топ-5 есть лишь одна специальность, не связанная с ИИ.

В целом опубликованный LinkedIn список показывает, что связанные с ИИ‑профессии стали наиболее востребованными на рынке в последние годы.

Из специальностей, связанных с ИТ, в 25 также Data center technicians (технические специалисты дата‑центров), что опять же связано с ИИ.

Другие данные LinkedIn выявили проблемы на рынке труда для многих людей: количество соискателей на одну открытую вакансию в среднем увеличилось более чем вдвое с весны 2022 года, в то время как объем найма по состоянию на ноябрь был на 23% ниже допандемического уровня.


https://www.linkedin.com/pulse/linkedin-jobs-rise-2026-25-fastest-growing-roles-us-linkedin-news-dlb1c/
https://www.businessinsider.com/fastest-growing-jobs-in-the-us-linkedin-2026-1

Сервис DB-Engines обновил рейтинг популярности систем баз данных, который отслеживает популярность 428 различных СУБД.
Методика расчета рейтинга учитывает популярность запросов в поисковых системах, число результатов в поисковой выдаче, объем обсуждений на популярных дискуссионных площадках и социальных сетях, число вакансий в агентствах по найму персонала и упоминаний в профилях пользователей.

Первые 5 мест продолжают занимать Oracle, MySQL, Microsoft SQL Server, PostgreSQL и MongoDB. По сравнению с январем 2025 года в десятке лидеров произошли две перестановки: Elasticsearch спустился с 8 на 10 место, а Databricks поднялся с 13 на 8 место. Остальные лидеры сохранили свои позиции в рейтинге, но снижение популярности наблюдается для MySQL (-130 баллов), MS SQL Server (-92), Elasticsearch (-27), MongoDB (-25), Oracle (-21) и Redis (-9). Рост популярности фиксируется для Snowflake (+53), Databricks (+53) и PostgreSQL (+3).

https://db-engines.com/en/ranking

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

Рассмотрим четыре основных типа архитектуры баз данных:

1. Single Node architecture (одноузловая архитектура):
* состоит из одного узла (Primary Node), который включает компоненты: compute1 (вычисления), cache (кэш) и data1 (хранилище данных);
* все операции (от обработки запросов до хранения данных) выполняются на одном узле;
* проста в реализации, но имеет ограничения по масштабируемости и отказоустойчивости — если узел выходит из строя, вся система становится недоступной;
* подходит для небольших проектов с низкой нагрузкой.

2. Shared Nothing Architecture (архитектура без общего доступа):
* включает несколько независимых узлов (Node 1, Node 2, Node 3), каждый из которых имеет собственные компоненты: compute (вычисления), cache (кэш) и data (локальное хранилище данных);
* запросы от клиента распределяются с помощью Load Balancer (балансировщика нагрузки) между узлами;
* узлы не делят ресурсы — каждый работает автономно, что обеспечивает высокую масштабируемость и отказоустойчивость (выход из строя одного узла не влияет на работу остальных);
* используется в системах с высокой нагрузкой, где требуется распределение нагрузки и независимость узлов (например, в распределённых СУБД).

3. (Decoupled) Shared Nothing Architecture (развязанная архитектура без общего доступа):
* похожа на классическую Shared Nothing, но имеет разделение на вычислительные узлы (с компонентами compute и cache) и узлы хранения (Storage Nodes с компонентами data);
* вычислительные узлы взаимодействуют с узлами хранения через сеть;
* такая декомпозиция позволяет ещё лучше масштабировать систему — можно независимо наращивать вычислительные мощности и объём хранилища;
* подходит для сложных распределённых систем, где требуется чёткое разделение между обработкой и хранением данных (например, в Big Data решениях).

4. Shared Storage Architecture (архитектура с общим хранилищем):
* состоит из нескольких вычислительных узлов (Node 1, Node 2, Node 3 с компонентами compute и cache), которые обращаются к единому централизованному хранилищу данных — Object Store (например, AWS S3);
* балансировщик нагрузки (Load Balancer) распределяет запросы между вычислительными узлами;
* все узлы имеют доступ к одним и тем же данным, что упрощает синхронизацию, но создаёт «бутылочное горлышко» на уровне хранилища при высокой нагрузке;
* преимущества: простота управления данными, централизованное хранение;
* недостатки: потенциальная точка отказа (если хранилище становится недоступным), ограничения по пропускной способности хранилища;
* применяется в системах, где важна централизованность данных, но не требуется экстремальная масштабируемость (например, в корпоративных системах с умеренной нагрузкой).

Ключевые отличия между архитектурами:
* Single Node — минимализм, простота, низкая отказоустойчивость;
* Shared Nothing — независимость узлов, высокая масштабируемость, но сложность синхронизации данных;
* (Decoupled) Shared Nothing — чёткое разделение ролей (вычисления/хранение), максимальная гибкость масштабирования;
* Shared Storage — централизованное управление данными, простота, но потенциальные проблемы с производительностью и отказоустойчивостью.

ПО итогам голосования на канале на звание языка 2025 года победил C#, с чем мы его поздравляем.
Я лично голосовал за Python и Rust, хотя ни один из них не является моим любимым языком. За Python голосовал в основном из-за ML/Deep Learning/AI/Data Science и за то, что Python все чаще рассматривается в качестве стартового
За Rust голосовал из-за его внедрения в Windows, Linux, Android, плюс этот язык все чаще применяется как базовый для приложений, где требуется высокая производительность, которые иначе разрабатывались бы на C/C++. Да здесь есть немало хайпа. Тем не менее экосистема Rust развивалась в прошлом году очень активно
Мог бы проголосовать еще за Go - тоже очень активно внедряется, особенно активно откусывает долю PHP в корпорат. секторе. Но это развитие было менее выраженным
В конечном счете, голосовал за Python и Rust только из-за развития экосистемы. С точки зрения же непосредственно развития самого языка ни один язык из списка голосования, по моему мнению, ничего экстраординарного не показал

Распределние памяти: Paging (страничное распределение) и Segmentation (сегментное распределение)
(продолжение в следующем посте)

Распределние памяти: Paging (страничное распределение) и Segmentation (сегментное распределение)
(продолжение предыдущего поста)

1. Принцип разделения памяти

- Paging (страничное распределение):
- Логическое адресное пространство процесса делится на блоки фиксированного размера, называемые страницами (pages).
- Физическая память делится на блоки фиксированного размера, называемые фреймами (frames).
- На изображении видно, что логический адрес состоит из номера страницы (Page Number, 3 бита) и смещения (Offset, 10 бит), а физический адрес — из номера фрейма (Frame Number, 2 бита) и смещения (Offset, 10 бит).
- Используется таблица страниц (Page Table) для сопоставления номеров страниц с номерами фреймов.

- Segmentation (сегментное распределение):
- Память делится на сегменты переменного размера, которые соответствуют логическим частям программы (функции, объекты, массивы данных).
- На изображении логический адрес состоит из номера сегмента (Segment Number) и смещения (Offset).
- Используется таблица сегментов (Segment Table), где для каждого сегмента указаны базовый адрес (Base Address) и предел (Limit) — максимальный размер сегмента.
- Перед обращением к памяти проверяется условие Offset < Limit (если нет — генерируется прерывание Trap).

2. Структура адреса

- В Paging: адрес состоит из двух частей — номер страницы и смещение. Преобразование логического адреса в физический происходит через таблицу страниц.
- В Segmentation: адрес также состоит из двух частей — номер сегмента и смещение, но преобразование учитывает базовый адрес сегмента и его предел.

3. Преимущества

- Paging:
- Устраняет внешнюю фрагментацию (fragmentation) за счёт использования фиксированных блоков.
- Упрощает распределение памяти.
- Поддерживает эффективное перемещение (своппинг) и использование виртуальной памяти.
- Segmentation:
- Обеспечивает логическое разделение частей программы, что упрощает управление кодом и данными.
- Позволяет защищать и совместно использовать сегменты между процессами.
- Упрощает управление растущими структурами данных (например, динамическими массивами).

4. Недостатки

- Paging:
- Требует поддержания таблицы страниц, что влечёт дополнительные накладные расходы.
- Возможны задержки из-за частых обращений к таблице страниц.
- Segmentation:
- Переменные размеры сегментов могут приводить к внешней фрагментации.
- Управление таблицей сегментов может быть сложнее, особенно при большом количестве сегментов.

5. Применение

- Paging чаще используется в системах, где важны простота и производительность, а память управляется через унифицированные размеры страниц.
- Segmentation предпочтительна в средах, где структура программы и шаблоны использования памяти динамичны и разнообразны.

В качестве резюме: Paging ориентирован на эффективность и простоту за счёт фиксированных блоков, а Segmentation — на гибкость и соответствие логической структуре программы за счёт переменных сегментов.

Из-за внедрения ИИ сотрудники начали чаще уставать и быть менее продуктивными

Генеральный директор стартапа в сфере программного обеспечения Convictional Роджер Киркнесс рассказал, что после внедрения инструментов искусственного интеллекта для сортировки электронной почты, ведения протоколов совещаний и составления отчётов о расходах наблюдался прирост производительности на 20%. При этом в стартапе обнаружили, что сотрудники столкнулись с выгоранием от высокого темпа высокоуровневой когнитивной работы.

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

Основная проблема, по словам экономиста и социолога из Бостонского колледжа Джульет Шор, заключается в том, что предприятия, как правило, просто перераспределяют время, сэкономленное ИИ. От работников, которые раньше умственно снижали концентрацию внимания при таких задачах, как ввод данных, теперь ожидается поддержание высокой концентрации на протяжении более длительных периодов. «Если вы просто заставляете людей работать в высоком темпе без перерывов, вы рискуете подавить творчество», — говорит Шор.

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

https://www.msn.com/en-us/technology/artificial-intelligence/the-downside-to-using-ai-for-all-those-boring-tasks-at-work/ar-AA1TMuha

Линус Торвальдс признался, что не умеет писать на Python. И использовал ИИ

Линус Торвальдс выложил на GitHub новый хобби-проект AudioNoise — набор цифровых эффектов для гитары. В README Торвальдс честно написал, что Python-визуализатор сделан с помощью вайб-кодинга через Google Antigravity. Причина проста: в Python он разбирается даже хуже, чем в аналоговых фильтрах. Основной код проекта написан на C вручную, ИИ использовался только для визуализации аудиосэмплов.

Торвальдс описал эволюцию своего подхода: раньше он гуглил примеры и копировал код в стиле "обезьянка видит — обезьянка делает" ("google and do the monkey-see-monkey-do"), а теперь "убрал посредника — себя". AudioNoise продолжает его увлечение самодельными гитарными педалями — в анонсе Linux 6.13 он назвал это хобби "LEGO для взрослых с паяльником". Новый проект эмулирует аналоговые эффекты (фейзер, фленжер, эхо) через цифровые IIR-фильтры, работающие без задержек по принципу "один сэмпл на входе — один на выходе".

Сам проект Торвальдса - https://github.com/torvalds/AudioNoise