Rate Limit (Ограничение частоты запросов к API)
(продолжение предыдущего поста)
Ограничение частоты запросов к API — это метод контроля количества запросов, которые клиент может отправить в определённый промежуток времени. Это защищает серверную часть от злоупотребления, обеспечивает справедливое использование сервиса среди клиентов и поддерживает стабильную производительность даже при высокой нагрузке.
Почему важно ограничивать частоту запросов к API
* Предотвращает перегрузку сервера.
* Блокирует вредоносные боты и попытки подбора методом перебора.
* Обеспечивает справедливое распределение ресурсов.
* Повышает надёжность и время безотказной работы API.
* Помогает контролировать расходы на API и использование инфраструктуры.
Основные методы ограничения частоты запросов
1. Ограничение по фиксированному окну (Fixed Window Rate Limiting)
* Запросы учитываются в рамках фиксированного промежутка времени (например, 100 запросов в минуту).
* Простота реализации.
* Может приводить к всплескам запросов на границах окон.
2. Журнал скользящего окна (Sliding Window Log)
* Фиксирует время каждого запроса в журнале.
* Более точное сглаживание трафика.
* Повышенное потребление памяти.
3. Счётчик скользящего окна (Sliding Window Counter)
* Объединяет методы фиксированного окна и журнала.
* Обеспечивает сглаженные ограничения без значительного объёма хранения данных.
* Снижает проблемы, связанные со «всплесками» запросов.
4. Алгоритм Token Bucket
* Клиенты накапливают «токены» с фиксированной скоростью.
* Каждый запрос использует один токен.
* Позволяет контролируемые всплески запросов при соблюдении ограничений.
5. Алгоритм Leaky Bucket
* Обрабатывает запросы с постоянной фиксированной скоростью.
* Очередь хранит избыточные запросы.
* Помогает сгладить колебания трафика.
Где применяется ограничение частоты запросов
* API‑шлюзы (Kong, NGINX, AWS API Gateway).
* Обратные прокси‑серверы.
* Уровень серверного приложения.
* Узлы CDN (Cloudflare, Akamai).
* Уровень взаимодействия микросервисов.
Типичные HTTP‑ответы при ограничении частоты запросов
* 429 Too Many Requests — клиент превысил лимит.
* Заголовок Retry‑After — указывает клиенту, сколько времени нужно подождать.
Лучшие практики
* Устанавливайте лимиты в зависимости от ролей пользователей (бесплатный тариф против премиум).
* Предоставляйте чёткие сообщения об ошибках с инструкциями по повторной попытке.
* Используйте системы кэширования, такие как Redis, для счётчиков.
* Регистрируйте все нарушения лимитов для анализа.
* Избегайте чрезмерно строгих ограничений, которые затрудняют использование сервиса.
* Применяйте адаптивные лимиты для различных нагрузок.
(продолжение предыдущего поста)
Ограничение частоты запросов к API — это метод контроля количества запросов, которые клиент может отправить в определённый промежуток времени. Это защищает серверную часть от злоупотребления, обеспечивает справедливое использование сервиса среди клиентов и поддерживает стабильную производительность даже при высокой нагрузке.
Почему важно ограничивать частоту запросов к API
* Предотвращает перегрузку сервера.
* Блокирует вредоносные боты и попытки подбора методом перебора.
* Обеспечивает справедливое распределение ресурсов.
* Повышает надёжность и время безотказной работы API.
* Помогает контролировать расходы на API и использование инфраструктуры.
Основные методы ограничения частоты запросов
1. Ограничение по фиксированному окну (Fixed Window Rate Limiting)
* Запросы учитываются в рамках фиксированного промежутка времени (например, 100 запросов в минуту).
* Простота реализации.
* Может приводить к всплескам запросов на границах окон.
2. Журнал скользящего окна (Sliding Window Log)
* Фиксирует время каждого запроса в журнале.
* Более точное сглаживание трафика.
* Повышенное потребление памяти.
3. Счётчик скользящего окна (Sliding Window Counter)
* Объединяет методы фиксированного окна и журнала.
* Обеспечивает сглаженные ограничения без значительного объёма хранения данных.
* Снижает проблемы, связанные со «всплесками» запросов.
4. Алгоритм Token Bucket
* Клиенты накапливают «токены» с фиксированной скоростью.
* Каждый запрос использует один токен.
* Позволяет контролируемые всплески запросов при соблюдении ограничений.
5. Алгоритм Leaky Bucket
* Обрабатывает запросы с постоянной фиксированной скоростью.
* Очередь хранит избыточные запросы.
* Помогает сгладить колебания трафика.
Где применяется ограничение частоты запросов
* API‑шлюзы (Kong, NGINX, AWS API Gateway).
* Обратные прокси‑серверы.
* Уровень серверного приложения.
* Узлы CDN (Cloudflare, Akamai).
* Уровень взаимодействия микросервисов.
Типичные HTTP‑ответы при ограничении частоты запросов
* 429 Too Many Requests — клиент превысил лимит.
* Заголовок Retry‑After — указывает клиенту, сколько времени нужно подождать.
Лучшие практики
* Устанавливайте лимиты в зависимости от ролей пользователей (бесплатный тариф против премиум).
* Предоставляйте чёткие сообщения об ошибках с инструкциями по повторной попытке.
* Используйте системы кэширования, такие как Redis, для счётчиков.
* Регистрируйте все нарушения лимитов для анализа.
* Избегайте чрезмерно строгих ограничений, которые затрудняют использование сервиса.
* Применяйте адаптивные лимиты для различных нагрузок.
Telegram
METANIT.COM
Rate Limit (Ограничение частоты запросов к API)
(продолжение в следующем посте)
(продолжение в следующем посте)
👍9🔥4🥰2
Энтузиасты разработали сверхкомпактный дистрибутив Linux под названием Tiny Core Linux, который после установки занимает всего лишь 23 МБ. Это примерно в 1100 раз меньше объема, занимаемого только что установленной Windows 11. Схожий объем имеют фотографии, снятые на современные флагманские Android-смартфоны в высоком разрешении и без экономии качества
При этом система полноценна – у нее есть функциональный оконный интерфейс, напоминающий одновременно и Windows благодаря острым углам окон, и macOS за счет небольшой док-панели внизу экрана. Tiny Core Linux располагает даже собственным установщиком программ – он подключается к серверу и открывает доступ к десяткам приложений
Что еще более примечательно, ISO-образ Tiny Core Linux «весит» больше, нежели полностью установленная система – 25,1 МБ.
http://www.tinycorelinux.net/welcome.html
https://www.tomshardware.com/software/linux/tiny-core-linux-16-2-still-fits-a-proper-linux-desktop-into-a-23mb-download-but-it-has-grown-1mb-since-the-last-time-we-looked-at-it
При этом система полноценна – у нее есть функциональный оконный интерфейс, напоминающий одновременно и Windows благодаря острым углам окон, и macOS за счет небольшой док-панели внизу экрана. Tiny Core Linux располагает даже собственным установщиком программ – он подключается к серверу и открывает доступ к десяткам приложений
Что еще более примечательно, ISO-образ Tiny Core Linux «весит» больше, нежели полностью установленная система – 25,1 МБ.
http://www.tinycorelinux.net/welcome.html
https://www.tomshardware.com/software/linux/tiny-core-linux-16-2-still-fits-a-proper-linux-desktop-into-a-23mb-download-but-it-has-grown-1mb-since-the-last-time-we-looked-at-it
👍23❤8🆒8👀4
Биты, P‑биты (вероятностные биты) и кубиты
(продолжение предыдущего поста)
### 1. Физическая природа и состояние
- Бит (классический):
- Дискретная единица информации в классических компьютерах.
- Может находиться только в одном из двух состояний: $0$ или $1$.
- Состояние строго определено (например, напряжение на транзисторе: есть — 1, нет — 0).
- Нет промежуточных значений.
- P‑bit (probabilistic bit, вероятностный бит):
- Может случайным образом переключаться между 0 и 1 под действием тепловых шумов.
- Состояние описывается вероятностью: например, P(0) = 0,7, P(1) = 0,3.
- Работает при комнатной температуре.
- Реализуется на наномагнитных элементах (stochastic magnetic tunnel junctions, sMTJ).
- Кубит (quantum bit, квантовый бит):
- Квантовый объект (электрон, фотон, ион и т. п.).
- Может находиться в суперпозиции состояний: α∣0⟩+β∣1⟩, где α и β — комплексные амплитуды (∣α∣^2 + ∣β∣^2 = 1).
- При измерении «коллапсирует» в 0 или 1 с вероятностями ∣α∣^2 и ∣β∣^2
- Требует крайне низких температур (близки к абсолютному нулю) для сохранения когерентности.
### 2. Принципы работы
- Бит:
- Логические операции (И, ИЛИ, НЕ) выполняются детерминированно.
- Вычисления — последовательные или параллельно-конвейерные.
- P‑bit:
- Использует естественную случайность физических элементов для вероятностных вычислений.
- Хорошо подходит для задач оптимизации, статистического вывода, генеративных моделей.
- Позволяет массовый параллелизм при низком энергопотреблении.
- Кубит:
- Оперирует квантовыми состояниями (суперпозиция, запутанность).
- Квантовые алгоритмы (Шора, Гровера и др.) дают экспоненциальное ускорение для некоторых задач.
- Требует коррекции ошибок из-за декогеренции.
### 3. Области применения
- Бит:
- Общие вычисления, логика, хранение данных.
- P‑бит:
- Оптимизация (например, задачи коммивояжёра).
- Генеративные модели ИИ (энергоэффективно).
- Статистический вывод.
- Кубит:
- Факторизация больших чисел (криптоанализ).
- Моделирование квантовых систем (химия, материалы).
- Поиск в неструктурированных базах данных.
- Квантовое машинное обучение.
### 4. Резюме
- **Бит** — основа классических вычислений: детерминирован, масштабируем, универсален.
- **P‑bit** — вероятностный элемент: использует случайность для энергоэффективных оптимизационных задач при комнатной температуре.
- **Кубит** — квантовый элемент: даёт суперпозицию и запутанность, но требует экстремального охлаждения и коррекции ошибок.
(продолжение предыдущего поста)
### 1. Физическая природа и состояние
- Бит (классический):
- Дискретная единица информации в классических компьютерах.
- Может находиться только в одном из двух состояний: $0$ или $1$.
- Состояние строго определено (например, напряжение на транзисторе: есть — 1, нет — 0).
- Нет промежуточных значений.
- P‑bit (probabilistic bit, вероятностный бит):
- Может случайным образом переключаться между 0 и 1 под действием тепловых шумов.
- Состояние описывается вероятностью: например, P(0) = 0,7, P(1) = 0,3.
- Работает при комнатной температуре.
- Реализуется на наномагнитных элементах (stochastic magnetic tunnel junctions, sMTJ).
- Кубит (quantum bit, квантовый бит):
- Квантовый объект (электрон, фотон, ион и т. п.).
- Может находиться в суперпозиции состояний: α∣0⟩+β∣1⟩, где α и β — комплексные амплитуды (∣α∣^2 + ∣β∣^2 = 1).
- При измерении «коллапсирует» в 0 или 1 с вероятностями ∣α∣^2 и ∣β∣^2
- Требует крайне низких температур (близки к абсолютному нулю) для сохранения когерентности.
### 2. Принципы работы
- Бит:
- Логические операции (И, ИЛИ, НЕ) выполняются детерминированно.
- Вычисления — последовательные или параллельно-конвейерные.
- P‑bit:
- Использует естественную случайность физических элементов для вероятностных вычислений.
- Хорошо подходит для задач оптимизации, статистического вывода, генеративных моделей.
- Позволяет массовый параллелизм при низком энергопотреблении.
- Кубит:
- Оперирует квантовыми состояниями (суперпозиция, запутанность).
- Квантовые алгоритмы (Шора, Гровера и др.) дают экспоненциальное ускорение для некоторых задач.
- Требует коррекции ошибок из-за декогеренции.
### 3. Области применения
- Бит:
- Общие вычисления, логика, хранение данных.
- P‑бит:
- Оптимизация (например, задачи коммивояжёра).
- Генеративные модели ИИ (энергоэффективно).
- Статистический вывод.
- Кубит:
- Факторизация больших чисел (криптоанализ).
- Моделирование квантовых систем (химия, материалы).
- Поиск в неструктурированных базах данных.
- Квантовое машинное обучение.
### 4. Резюме
- **Бит** — основа классических вычислений: детерминирован, масштабируем, универсален.
- **P‑bit** — вероятностный элемент: использует случайность для энергоэффективных оптимизационных задач при комнатной температуре.
- **Кубит** — квантовый элемент: даёт суперпозицию и запутанность, но требует экстремального охлаждения и коррекции ошибок.
Telegram
METANIT.COM
Стратегии индексирования баз данных в бэкенде
(продолжение в следующем посте)
(продолжение в следующем посте)
🤔9✍5🔥3🤣3💯1
Сервис TIOBE опубликовал декабрьский рейтинг языков программирования. Неожиданностью стало попадание языка R в первую десятку. Ну а язык C#, судя по всему, станет языком 2025 года по версии TIOBE
Понятно, что рейтинг TIOBE - это рейтинг, высосанный из пальца, но тем не менее.
https://www.tiobe.com/tiobe-index/
Понятно, что рейтинг TIOBE - это рейтинг, высосанный из пальца, но тем не менее.
https://www.tiobe.com/tiobe-index/
👍19🤮9🤣6🤡4🔥3🤝2
Стратегии индексирования баз данных в бэкенде
(продолжение в следующем посте)
(продолжение в следующем посте)
❤5👍2💯2
Стратегии индексирования баз данных в бэкенде
(продолжение предыдущего поста)
→ Индексирование — один из самых эффективных способов ускорить выполнение запросов к базам данных в бэкенд‑системах.
→ Грамотное индексирование сокращает время поиска, улучшает операции соединения (joins) и повышает общую производительность — без изменения логики приложения.
✓ 1. Первичные индексы
→ Автоматически создаются для первичных ключей.
→ Обеспечивают быстрый поиск по уникальным идентификаторам.
→ Всегда индексируйте поля первичного ключа для эффективного извлечения записей.
✓ 2. Вторичные индексы
→ Создаются для неключевых столбцов, часто используемых в поисках.
→ Идеальны для таких полей, как email, имя пользователя или статус.
→ Позволяют быстро фильтровать запросы без сканирования всей таблицы.
✓ 3. Составные индексы
→ Индексы, охватывающие несколько столбцов.
→ Оптимальны, когда запросы фильтруют или сортируют данные по нескольким полям.
→ Порядок имеет значение: индекс по
✓ 4. Уникальные индексы
→ Гарантируют отсутствие повторяющихся значений.
→ Полезны для email, имён пользователей или любых полей, требующих уникальности.
→ Также повышают производительность, поскольку СУБД оптимизирует проверку уникальности.
✓ 5. Полнотекстовые индексы
→ Оптимизированы для поиска фраз и ключевых слов.
→ Полезны для блогов, поиска товаров, мессенджеров.
→ Поддерживают запросы на естественном языке вроде «найти посты о проектировании бэкенда».
✓ 6. Частичные (фильтрованные) индексы
→ Индексируют лишь часть таблицы (например, активных пользователей).
→ Уменьшают размер индекса и повышают скорость, если данные имеют предсказуемые шаблоны.
✓ 7. Покрывающие индексы
→ Включают все необходимые столбцы для запроса.
→ Позволяют СУБД ответить на запрос, используя только индекс — без сканирования таблицы.
→ Идеальны для нагрузок с частыми операциями
✓ 8. Индексирование для операций соединения (joins)
→ Всегда индексируйте внешние ключи.
→ Убедитесь, что обе стороны условий соединения проиндексированы.
→ Значительно улучшают запросы с объединением нескольких таблиц.
✓ 9. Избегайте избыточного индексирования
→ Каждый индекс увеличивает объём хранимых данных.
→ Замедляет операции записи (вставка/обновление/удаление).
→ Создавайте индексы только для реальных, регулярно повторяющихся шаблонов запросов.
✓ 10. Мониторинг производительности индексов
→ Используйте команды
→ Удаляйте неиспользуемые индексы, чтобы снизить накладные расходы.
→ Постоянно корректируйте индексирование по мере эволюции данных и запросов.
(продолжение предыдущего поста)
→ Индексирование — один из самых эффективных способов ускорить выполнение запросов к базам данных в бэкенд‑системах.
→ Грамотное индексирование сокращает время поиска, улучшает операции соединения (joins) и повышает общую производительность — без изменения логики приложения.
✓ 1. Первичные индексы
→ Автоматически создаются для первичных ключей.
→ Обеспечивают быстрый поиск по уникальным идентификаторам.
→ Всегда индексируйте поля первичного ключа для эффективного извлечения записей.
✓ 2. Вторичные индексы
→ Создаются для неключевых столбцов, часто используемых в поисках.
→ Идеальны для таких полей, как email, имя пользователя или статус.
→ Позволяют быстро фильтровать запросы без сканирования всей таблицы.
✓ 3. Составные индексы
→ Индексы, охватывающие несколько столбцов.
→ Оптимальны, когда запросы фильтруют или сортируют данные по нескольким полям.
→ Порядок имеет значение: индекс по
(страна, город) поможет запросу с фильтрацией по обоим параметрам, но не по городу в одиночку.✓ 4. Уникальные индексы
→ Гарантируют отсутствие повторяющихся значений.
→ Полезны для email, имён пользователей или любых полей, требующих уникальности.
→ Также повышают производительность, поскольку СУБД оптимизирует проверку уникальности.
✓ 5. Полнотекстовые индексы
→ Оптимизированы для поиска фраз и ключевых слов.
→ Полезны для блогов, поиска товаров, мессенджеров.
→ Поддерживают запросы на естественном языке вроде «найти посты о проектировании бэкенда».
✓ 6. Частичные (фильтрованные) индексы
→ Индексируют лишь часть таблицы (например, активных пользователей).
→ Уменьшают размер индекса и повышают скорость, если данные имеют предсказуемые шаблоны.
✓ 7. Покрывающие индексы
→ Включают все необходимые столбцы для запроса.
→ Позволяют СУБД ответить на запрос, используя только индекс — без сканирования таблицы.
→ Идеальны для нагрузок с частыми операциями
SELECT.✓ 8. Индексирование для операций соединения (joins)
→ Всегда индексируйте внешние ключи.
→ Убедитесь, что обе стороны условий соединения проиндексированы.
→ Значительно улучшают запросы с объединением нескольких таблиц.
✓ 9. Избегайте избыточного индексирования
→ Каждый индекс увеличивает объём хранимых данных.
→ Замедляет операции записи (вставка/обновление/удаление).
→ Создавайте индексы только для реальных, регулярно повторяющихся шаблонов запросов.
✓ 10. Мониторинг производительности индексов
→ Используйте команды
EXPLAIN или ANALYZE для проверки использования индексов. → Удаляйте неиспользуемые индексы, чтобы снизить накладные расходы.
→ Постоянно корректируйте индексирование по мере эволюции данных и запросов.
Telegram
METANIT.COM
Стратегии индексирования баз данных в бэкенде
(продолжение в следующем посте)
(продолжение в следующем посте)
❤8👍4💯2
This media is not supported in your browser
VIEW IN TELEGRAM
Линус Тольвальдс об ИИ:
- «Искусственный интеллект — это, безусловно, мыльный пузырь, но он изменит то, как выполняется большинство квалифицированных работ».
- «Программирование с помощью ИИ отлично подходит для начала изучения программирования, но поддерживать такой код — ужасная задача».
- «Я большой сторонник ИИ. Но я не большой сторонник всего, что связано с ИИ. Я считаю, что рынок и маркетинг в этой сфере находятся в плачевном состоянии. Неизбежен обвал».
- «Искусственный интеллект — это, безусловно, мыльный пузырь, но он изменит то, как выполняется большинство квалифицированных работ».
- «Программирование с помощью ИИ отлично подходит для начала изучения программирования, но поддерживать такой код — ужасная задача».
- «Я большой сторонник ИИ. Но я не большой сторонник всего, что связано с ИИ. Я считаю, что рынок и маркетинг в этой сфере находятся в плачевном состоянии. Неизбежен обвал».
🔥26💯16🤝9🖕1
Компания Amazon поделилась историей перехода на Rust с Kotlin и Go
На конференции AWS re:Invent 2025 компания AWS (Amazon) объявила, что Rust стал языком программирования по умолчанию для всех проектов в области data plane (обработка данных), подчеркивая его превосходство в производительности по сравнению с другими языками. AWS уже использует Rust в своих микро-виртуальных машинах, таких как Bottlerocket и Firecracker.
Компания сделала акцент на преимуществах Rust, прежде всего на отсутствии накладных расходов на сборку мусора, которые сильно влияют на языки вроде Kotlin и Go в крупных распределенных приложениях.
CTO AWS Вернер Фогелс отметил, что база данных Aurora DSQL (распределенная PostgreSQL-совместимая СУБД) была переписана с Kotlin на Go для решения проблем с производительностью, но Rust показал еще лучшие результаты: «Код на [Rust] был в 10 раз быстрее нашей тщательно настроенной реализации на Kotlin — несмотря на отсутствие попыток его оптимизации».
В качестве примера успешной интеграции приводится пример с агента мониторига Datadog - изначально написанный на Go и запущенный как расширение на AWS Lambda, имел время холодного старта 700–800 мс, что считалось «огромной нагрузкой» для serverless-observability. Переход на Rust сократил это до 80 мс.
Кроме того, Rust обрабатывал в разы больше точек данных в секунду (PPS), а в целом код на Rust был почти в 3 раза быстрее. Стайвенберг объяснил, что Go тратил 30% времени на сборку мусора из-за частых мелких аллокаций памяти для данных observability. Хотя оптимизация Go с использованием off-heap памяти возможна, она приводит к неудобоуправляемому коду. В итоге: «Идиоматичный код на Rust дает производительность тщательно оптимизированного кода на Go».
https://devclass.com/2025/12/08/aws-shows-rust-love-at-reinvent-10-times-faster-than-kotlin-one-tenth-the-latency-of-go/
На конференции AWS re:Invent 2025 компания AWS (Amazon) объявила, что Rust стал языком программирования по умолчанию для всех проектов в области data plane (обработка данных), подчеркивая его превосходство в производительности по сравнению с другими языками. AWS уже использует Rust в своих микро-виртуальных машинах, таких как Bottlerocket и Firecracker.
Компания сделала акцент на преимуществах Rust, прежде всего на отсутствии накладных расходов на сборку мусора, которые сильно влияют на языки вроде Kotlin и Go в крупных распределенных приложениях.
CTO AWS Вернер Фогелс отметил, что база данных Aurora DSQL (распределенная PostgreSQL-совместимая СУБД) была переписана с Kotlin на Go для решения проблем с производительностью, но Rust показал еще лучшие результаты: «Код на [Rust] был в 10 раз быстрее нашей тщательно настроенной реализации на Kotlin — несмотря на отсутствие попыток его оптимизации».
В качестве примера успешной интеграции приводится пример с агента мониторига Datadog - изначально написанный на Go и запущенный как расширение на AWS Lambda, имел время холодного старта 700–800 мс, что считалось «огромной нагрузкой» для serverless-observability. Переход на Rust сократил это до 80 мс.
Кроме того, Rust обрабатывал в разы больше точек данных в секунду (PPS), а в целом код на Rust был почти в 3 раза быстрее. Стайвенберг объяснил, что Go тратил 30% времени на сборку мусора из-за частых мелких аллокаций памяти для данных observability. Хотя оптимизация Go с использованием off-heap памяти возможна, она приводит к неудобоуправляемому коду. В итоге: «Идиоматичный код на Rust дает производительность тщательно оптимизированного кода на Go».
https://devclass.com/2025/12/08/aws-shows-rust-love-at-reinvent-10-times-faster-than-kotlin-one-tenth-the-latency-of-go/
devclass
AWS shows Rust love at re:Invent: 10 times faster than Kotlin, one tenth the latency of Go
At its re:Invent conference in Las Vegas last week, AWS described how it now uses Rust by default […]
🤡14❤12🤔6👍4😱1🤮1
Владимир Путин предупредил о риске потерять «все, что дорого», из-за ИИ
Президент считает, что существует угроза раскола общества — на элиту, которая «действительно думает», и тех, кто умеет только «нажимать кнопку»
«Не использовать эти инструменты — значит проиграть все, что нам дорого. Просто все проиграть, если не использовать эти возможности больших данных и все, что с этим связано. Но в то же время, если использовать это бездумно, то это тоже может привести к утрате как раз всего того, что нам дорого».
«Нам ни в коем случае нельзя потерять поколение совсем молодых наших граждан, которые вместо того, чтобы думать, будут просто нажимать кнопочку, и все. И сами не будут в состоянии решать элементарные задачи по математике, физике, химии. Да и историю знать, как следует, не будут. Вот это сложная задача. Чтобы у нас не возникла элита из двух десятых человек, которые действительно думают, которые что-то генерят, и основной массы людей, которые будут только уметь кнопку нажимать, и все», — сказал глава государства.
https://www.rbc.ru/technology_and_media/09/12/2025/6938392a9a794741ee23fbdf?from=from_main_9
Президент считает, что существует угроза раскола общества — на элиту, которая «действительно думает», и тех, кто умеет только «нажимать кнопку»
«Не использовать эти инструменты — значит проиграть все, что нам дорого. Просто все проиграть, если не использовать эти возможности больших данных и все, что с этим связано. Но в то же время, если использовать это бездумно, то это тоже может привести к утрате как раз всего того, что нам дорого».
«Нам ни в коем случае нельзя потерять поколение совсем молодых наших граждан, которые вместо того, чтобы думать, будут просто нажимать кнопочку, и все. И сами не будут в состоянии решать элементарные задачи по математике, физике, химии. Да и историю знать, как следует, не будут. Вот это сложная задача. Чтобы у нас не возникла элита из двух десятых человек, которые действительно думают, которые что-то генерят, и основной массы людей, которые будут только уметь кнопку нажимать, и все», — сказал глава государства.
https://www.rbc.ru/technology_and_media/09/12/2025/6938392a9a794741ee23fbdf?from=from_main_9
РБК
Путин предупредил о риске потерять «все, что дорого», из-за ИИ
Президент считает, что существует угроза раскола общества — на элиту, которая «действительно думает», и тех, кто умеет только «нажимать кнопку»
👍43🤡12🤣12💩7🤔5👀3❤2💯1🙊1
В руководство по сетевому программированию на Python добавлены материалы про Создание локального HTTP/HTTPS-сервера
https://metanit.com/python/network/2.1.php
#python
https://metanit.com/python/network/2.1.php
#python
🔥21👍6❤3🤮1