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 или в открытом поиске...
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 или в открытом поиске...
Google
Gmail is entering the Gemini era
Learn more about the next era of Gmail, now using Gemini 3 and Personal Intelligence.
💩15❤8😁6🤔3🤬2🔥1🤯1😢1
Архитектура микросервисов
(продолжение предыдущего поста)
Архитектура микросервисов состоит из ряда звеньев/уровней. Рассмотрим типичную архитектуру микросервисов.
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).
(продолжение предыдущего поста)
Архитектура микросервисов состоит из ряда звеньев/уровней. Рассмотрим типичную архитектуру микросервисов.
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).
Telegram
METANIT.COM
Архитектура микросервисов
(продолжение в следующем посте)
(продолжение в следующем посте)
❤8👍2👏1
Сервис по поиску работы 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
Весь топ-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
Linkedin
LinkedIn Jobs on the Rise 2026: The 25 fastest-growing roles in the U.S.
See the most in-demand jobs of 2026, in LinkedIn's data-backed ranking of the 25 top growing roles in the U.S.
❤4🤔4🔥2😱1🤬1😢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
Методика расчета рейтинга учитывает популярность запросов в поисковых системах, число результатов в поисковой выдаче, объем обсуждений на популярных дискуссионных площадках и социальных сетях, число вакансий в агентствах по найму персонала и упоминаний в профилях пользователей.
Первые 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
👍3❤2🔥2
Типы архитектуры базы данных
(продолжение предыдущего поста)
Рассмотрим четыре основных типа архитектуры баз данных:
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 — централизованное управление данными, простота, но потенциальные проблемы с производительностью и отказоустойчивостью.
(продолжение предыдущего поста)
Рассмотрим четыре основных типа архитектуры баз данных:
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 — централизованное управление данными, простота, но потенциальные проблемы с производительностью и отказоустойчивостью.
Telegram
METANIT.COM
Типы архитектуры базы данных
(продолжение в следующем посте)
(продолжение в следующем посте)
👍4❤2🔥2
ПО итогам голосования на канале на звание языка 2025 года победил C#, с чем мы его поздравляем.
Я лично голосовал за Python и Rust, хотя ни один из них не является моим любимым языком. За Python голосовал в основном из-за ML/Deep Learning/AI/Data Science и за то, что Python все чаще рассматривается в качестве стартового
За Rust голосовал из-за его внедрения в Windows, Linux, Android, плюс этот язык все чаще применяется как базовый для приложений, где требуется высокая производительность, которые иначе разрабатывались бы на C/C++. Да здесь есть немало хайпа. Тем не менее экосистема Rust развивалась в прошлом году очень активно
Мог бы проголосовать еще за Go - тоже очень активно внедряется, особенно активно откусывает долю PHP в корпорат. секторе. Но это развитие было менее выраженным
В конечном счете, голосовал за Python и Rust только из-за развития экосистемы. С точки зрения же непосредственно развития самого языка ни один язык из списка голосования, по моему мнению, ничего экстраординарного не показал
Я лично голосовал за Python и Rust, хотя ни один из них не является моим любимым языком. За Python голосовал в основном из-за ML/Deep Learning/AI/Data Science и за то, что Python все чаще рассматривается в качестве стартового
За Rust голосовал из-за его внедрения в Windows, Linux, Android, плюс этот язык все чаще применяется как базовый для приложений, где требуется высокая производительность, которые иначе разрабатывались бы на C/C++. Да здесь есть немало хайпа. Тем не менее экосистема Rust развивалась в прошлом году очень активно
Мог бы проголосовать еще за Go - тоже очень активно внедряется, особенно активно откусывает долю PHP в корпорат. секторе. Но это развитие было менее выраженным
В конечном счете, голосовал за Python и Rust только из-за развития экосистемы. С точки зрения же непосредственно развития самого языка ни один язык из списка голосования, по моему мнению, ничего экстраординарного не показал
❤34🔥10🤡8👏5❤🔥3🖕2
Распределние памяти: Paging (страничное распределение) и Segmentation (сегментное распределение)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤3👍3🔥2
Распределние памяти: 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 — на гибкость и соответствие логической структуре программы за счёт переменных сегментов.
(продолжение предыдущего поста)
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 — на гибкость и соответствие логической структуре программы за счёт переменных сегментов.
Telegram
METANIT.COM
Распределние памяти: Paging (страничное распределение) и Segmentation (сегментное распределение)
(продолжение в следующем посте)
(продолжение в следующем посте)
👍5❤4🔥2
Из-за внедрения ИИ сотрудники начали чаще уставать и быть менее продуктивными
Генеральный директор стартапа в сфере программного обеспечения 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
Генеральный директор стартапа в сфере программного обеспечения 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
MSN
The downside to using AI for all those boring tasks at work
Some managers make space in the workday for repetitive, low-intensity tasks where creative sparks can fly.
💯18🤯9👍6😢3🔥1🤬1🤨1
Линус Торвальдс признался, что не умеет писать на 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
Линус Торвальдс выложил на 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
GitHub
GitHub - torvalds/AudioNoise: Random digital audio effects
Random digital audio effects. Contribute to torvalds/AudioNoise development by creating an account on GitHub.
❤23🔥10👀7🤮3😁2🤔2🤝2
Сервис по поиску работы HH выпустил статистику по состоянию рынка труда на декабрь, и для ИТ тут стабильность - все стабильно плохо
Предлагаемые зарплаты по сравнению с ноябрем даже снизились - с 94 915 до 93 410. Если смотреть на годовую динамику, то в зп, конечно, рост - почти на 10% (по крайней мере выше оф. инфляции в 6%)
hh-индекс - показатель соотношения количества активных резюме к количеству активных вакансий снова ухудшился - рост до 20,7 (с 19,4 в ноябре). То есть в ИТ крайне мегасупервысокий уровень конкуренции соискателей за рабочие места
Хотя по сранению с ноябрем количество вакансий уменьшилось только на 8%, но год к году снижение составило аж 39%.
С другой стороны, количество резюме по сравнению с ноябрем снизилось на 3% (возможно, сказались праздники), но год к году выросло на 29%
https://stats.hh.ru/?countrySalaryDynamicChartProfArea=information_technology&hhIndexProfArea=information_technology&vacanciesProfArea=information_technology&vacanciesPeriod=month
Предлагаемые зарплаты по сравнению с ноябрем даже снизились - с 94 915 до 93 410. Если смотреть на годовую динамику, то в зп, конечно, рост - почти на 10% (по крайней мере выше оф. инфляции в 6%)
hh-индекс - показатель соотношения количества активных резюме к количеству активных вакансий снова ухудшился - рост до 20,7 (с 19,4 в ноябре). То есть в ИТ крайне мегасупервысокий уровень конкуренции соискателей за рабочие места
Хотя по сранению с ноябрем количество вакансий уменьшилось только на 8%, но год к году снижение составило аж 39%.
С другой стороны, количество резюме по сравнению с ноябрем снизилось на 3% (возможно, сказались праздники), но год к году выросло на 29%
https://stats.hh.ru/?countrySalaryDynamicChartProfArea=information_technology&hhIndexProfArea=information_technology&vacanciesProfArea=information_technology&vacanciesPeriod=month
💔15🤡6😁5😢2🎅2🔥1