Процесс обучения LLM (Large Language Model) на основе архитектуры Transformer
(продолжение предыдущего поста)
Архитектура Transformer позволяет LLM эффективно обучаться на больших объёмах текстовых данных, улавливая сложные языковые закономерности и генерируя осмысленные ответы. Ключевые особенности процесса:
* Параллелизм — благодаря механизму внимания, модель может анализировать весь входной текст одновременно, а не последовательно.
* Контекстуальное понимание — взаимосвязи между токенами улавливаются на нескольких уровнях через механизмы внимания.
* Устойчивость к длине последовательности — архитектура не теряет контекст даже для длинных текстов.
* Гибкость — архитектура поддерживает как задачи понимания языка (энкодер), так и генерацию текста (декодер)
Рассмотрим поэтапно:
1. Подготовка входных данных (Inputs)
Процесс начинается с подачи на вход текста, который разбивается на токены (слова или подслова). Эти токены преобразуются в векторные представления (Input Embedding) — числовые векторы, отражающие семантику и контекст каждого токена.
2. Добавление позиционной кодировки (Positional Encoding)
Поскольку нейронная сеть не знает порядка слов, к каждому вектору эмбеддинга добавляется позиционная кодировка — специальные числа, указывающие на позицию токена в последовательности. Это позволяет модели учитывать порядок слов.
3. Обработка в энкодере (Encoder)
Энкодер состоит из нескольких слоёв, каждый из которых выполняет следующие операции:
* Multi-Head Attention (многоголовое внимание) — модель анализирует взаимосвязи между всеми токенами одновременно, выделяя важные контекстуальные связи. Механизм многоголового внимания позволяет учитывать разные аспекты контекста параллельно.
* Add & Normalize (сложение и нормализация) — результаты внимания складываются с входными векторами и нормализуются для стабилизации обучения.
* Feed Forward — простейшая полносвязная нейронная сеть применяет нелинейные преобразования к векторам, углубляя их представление.
* Повторение слоёв — эти шаги повторяются в нескольких слоях энкодера, углубляя понимание контекста.
На выходе энкодера формируется контекстуализированное представление входного текста — набор векторов, отражающих смысл и взаимосвязи между токенами.
4. Обработка в декодере (Decoder)
Декодер отвечает за генерацию выходного текста (Outputs) и работает по схожей схеме, но с ключевыми отличиями:
* Masked Multi-Head Attention (маскированное многоголовое внимание) — декодер предсказывает следующий токен, имея доступ только к предыдущим токенам (будущие токены «закрыты» маской). Это позволяет модели генерировать текст последовательно.
* Multi-Head Attention над выходом энкодера — декодер обращается к векторам, созданным энкодером, чтобы учитывать контекст входного текста при генерации ответа.
* Add & Normalize и Feed Forward — аналогичные операции для углубления представления.
* Повторение слоёв — несколько слоёв декодера последовательно генерируют выходные токены.
5. Формирование выходных эмбеддингов (Output Embedding)
После прохождения через декодер формируется последовательность векторов выходных токенов. К ним также применяется позиционная кодировка.
6. Преобразование в вероятности токенов (Linear → Softmax)
* Линейный слой (Linear) — преобразует векторы токенов в необработанные оценки (logits) для каждого возможного токена в словаре модели.
* Функция Softmax — преобразует оценки в вероятности, где каждому токену соответствует вероятность его появления в данной позиции.
7. Генерация итогового вывода (Outputs (shifted right))
Модель выбирает токен с наибольшей вероятностью и добавляет его в выходную последовательность. Процесс повторяется до генерации полного ответа или до достижения специального токена окончания (EOS — End Of Sequence).
(продолжение предыдущего поста)
Архитектура Transformer позволяет LLM эффективно обучаться на больших объёмах текстовых данных, улавливая сложные языковые закономерности и генерируя осмысленные ответы. Ключевые особенности процесса:
* Параллелизм — благодаря механизму внимания, модель может анализировать весь входной текст одновременно, а не последовательно.
* Контекстуальное понимание — взаимосвязи между токенами улавливаются на нескольких уровнях через механизмы внимания.
* Устойчивость к длине последовательности — архитектура не теряет контекст даже для длинных текстов.
* Гибкость — архитектура поддерживает как задачи понимания языка (энкодер), так и генерацию текста (декодер)
Рассмотрим поэтапно:
1. Подготовка входных данных (Inputs)
Процесс начинается с подачи на вход текста, который разбивается на токены (слова или подслова). Эти токены преобразуются в векторные представления (Input Embedding) — числовые векторы, отражающие семантику и контекст каждого токена.
2. Добавление позиционной кодировки (Positional Encoding)
Поскольку нейронная сеть не знает порядка слов, к каждому вектору эмбеддинга добавляется позиционная кодировка — специальные числа, указывающие на позицию токена в последовательности. Это позволяет модели учитывать порядок слов.
3. Обработка в энкодере (Encoder)
Энкодер состоит из нескольких слоёв, каждый из которых выполняет следующие операции:
* Multi-Head Attention (многоголовое внимание) — модель анализирует взаимосвязи между всеми токенами одновременно, выделяя важные контекстуальные связи. Механизм многоголового внимания позволяет учитывать разные аспекты контекста параллельно.
* Add & Normalize (сложение и нормализация) — результаты внимания складываются с входными векторами и нормализуются для стабилизации обучения.
* Feed Forward — простейшая полносвязная нейронная сеть применяет нелинейные преобразования к векторам, углубляя их представление.
* Повторение слоёв — эти шаги повторяются в нескольких слоях энкодера, углубляя понимание контекста.
На выходе энкодера формируется контекстуализированное представление входного текста — набор векторов, отражающих смысл и взаимосвязи между токенами.
4. Обработка в декодере (Decoder)
Декодер отвечает за генерацию выходного текста (Outputs) и работает по схожей схеме, но с ключевыми отличиями:
* Masked Multi-Head Attention (маскированное многоголовое внимание) — декодер предсказывает следующий токен, имея доступ только к предыдущим токенам (будущие токены «закрыты» маской). Это позволяет модели генерировать текст последовательно.
* Multi-Head Attention над выходом энкодера — декодер обращается к векторам, созданным энкодером, чтобы учитывать контекст входного текста при генерации ответа.
* Add & Normalize и Feed Forward — аналогичные операции для углубления представления.
* Повторение слоёв — несколько слоёв декодера последовательно генерируют выходные токены.
5. Формирование выходных эмбеддингов (Output Embedding)
После прохождения через декодер формируется последовательность векторов выходных токенов. К ним также применяется позиционная кодировка.
6. Преобразование в вероятности токенов (Linear → Softmax)
* Линейный слой (Linear) — преобразует векторы токенов в необработанные оценки (logits) для каждого возможного токена в словаре модели.
* Функция Softmax — преобразует оценки в вероятности, где каждому токену соответствует вероятность его появления в данной позиции.
7. Генерация итогового вывода (Outputs (shifted right))
Модель выбирает токен с наибольшей вероятностью и добавляет его в выходную последовательность. Процесс повторяется до генерации полного ответа или до достижения специального токена окончания (EOS — End Of Sequence).
Telegram
METANIT.COM
Процесс обучения LLM (Large Language Model) на основе архитектуры Transformer
(продолжение в следующем посте)
(продолжение в следующем посте)
👍4👏2🖕2👾2❤1
Инженеры Amazon по ошибке вывели из строя часть Amazon Web Services после совета AI-ассистента
Инцидент произошёл в декабре при работе с внутренним корпоративным инструментом Kiro. AI-ассистент предложил инженерам удалить и заново развернуть рабочую среду для исправления проблем конфигурации. Сотрудники одобрили выполнение операции, после чего система начала автоматические изменения инфраструктуры.
Однако процесс пошёл некорректно, что привело к масштабным сбоям в облачных сервисах AWS. Перебои продолжались около 13 часов и затронули часть клиентов платформы.
В Amazon позже признали, что ключевой причиной стал человеческий фактор. Инженер предоставил ассистенту слишком высокий уровень доступа, фактически разрешив выполнять критические операции без дополнительной проверки.
После инцидента компания усилила контроль прав доступа, обновила внутренние процедуры работы с AI-инструментами и ввела дополнительное обучение сотрудников.
https://www.theregister.com/2026/02/20/amazon_denies_kiro_agentic_ai_behind_outage/
Инцидент произошёл в декабре при работе с внутренним корпоративным инструментом Kiro. AI-ассистент предложил инженерам удалить и заново развернуть рабочую среду для исправления проблем конфигурации. Сотрудники одобрили выполнение операции, после чего система начала автоматические изменения инфраструктуры.
Однако процесс пошёл некорректно, что привело к масштабным сбоям в облачных сервисах AWS. Перебои продолжались около 13 часов и затронули часть клиентов платформы.
В Amazon позже признали, что ключевой причиной стал человеческий фактор. Инженер предоставил ассистенту слишком высокий уровень доступа, фактически разрешив выполнять критические операции без дополнительной проверки.
После инцидента компания усилила контроль прав доступа, обновила внутренние процедуры работы с AI-инструментами и ввела дополнительное обучение сотрудников.
https://www.theregister.com/2026/02/20/amazon_denies_kiro_agentic_ai_behind_outage/
The Register
Amazon's vibe-coding tool Kiro reportedly vibed too hard and brought down AWS
: Bezos-corp blames user error for outage, 'specifically misconfigured access controls'
🤣37🔥4💯2👾1
Основные HTTP-заголовки
(продолжение предыдущего поста)
HTTP-заголовки структурированы по категориям, каждая из которых выполняет свою роль: от передачи метаданных и управления кэшированием до обеспечения безопасности и управления содержимым. Они обеспечивают взаимодействие между клиентом и сервером, делая обмен данными более эффективным и безопасным.
Разберём каждую категорию HTTP-заголовков подробно:
#### 1. General Headers (Общие заголовки)
Используются для передачи общей информации о сообщении. Включают:
* Date — указывает, когда сервер отправил ответ.
* Age — показывает «возраст» кэша в секундах.
* Cache-Control — управляет правилами кэширования.
* Vary — сообщает кэшу, какие заголовки запроса имеют значение.
* Via — отображает используемые прокси и шлюзы.
* Host — идентифицирует запрошенный сервер.
#### 2. Request Headers (Заголовки запроса)
Передаются от клиента к серверу и содержат предпочтения клиента или информацию о клиенте. Включают:
* User-Agent — идентифицирует браузер, приложение и тип устройства.
* Accept — предпочтения клиента по формату ответа.
* Accept-Language — предпочтения клиента по языку ответа.
* Accept-Encoding — список поддерживаемых алгоритмов сжатия.
* Cookie — данные сессии или предпочтения (например, сохранённые настройки).
* Referer — страница, с которой был перенаправлен запрос (откуда пришёл пользователь).
#### 3. Response Headers (Заголовки ответа)
Передаются от сервера к клиенту и содержат инструкции или метаданные об ответе. Включают:
* Location — указывает клиенту, куда перейти дальше (например, при перенаправлении).
* Set-Cookie — сохраняет данные сессии в браузере клиента.
* Access-Control-Allow-Origin — разрешает кросс-доменные запросы для определённых доменов.
* Accept-Ranges — проверяет, поддерживает ли сервер частичные запросы (например, загрузку файла по частям).
* Content-Range — указывает, какая часть файла передаётся.
* ETag — уникальный идентификатор версии ресурса (помогает определить, изменился ли ресурс).
#### 4. Payload Headers (Заголовки полезной нагрузки)
Описывают содержимое тела сообщения (payload). Включают:
* Content-Type — задаёт формат полезной нагрузки (например,
* Content-Disposition — указывает браузеру, загружать ли файл или отображать его inline (в браузере).
* Content-Length — размер тела сообщения в байтах.
* Content-Encoding — тип сжатия тела ответа.
* Content-Language — человеческий язык тела ответа.
* Last-Modified — дата последнего обновления ресурса на сервере.
#### 5. Security Headers (Заголовки безопасности)
Обеспечивают защиту и контроль доступа. Включают:
* Last-Modified — используется для проверки актуальности ресурса (дата последнего изменения).
* Range — запрашивает только определённую часть ресурса (например, диапазон байтов файла).
* If-Modified-Since — получает ресурс только в случае, если он изменился после указанной даты.
* If-None-Match — получает ресурс только в случае, если ETag не совпадает (проверка актуальности).
* Content-Security-Policy — ограничивает источники скриптов и стилей, которые могут выполняться.
* Strict-Transport-Security — заставляет браузер всегда использовать HTTPS (повышает безопасность соединения).
(продолжение предыдущего поста)
HTTP-заголовки структурированы по категориям, каждая из которых выполняет свою роль: от передачи метаданных и управления кэшированием до обеспечения безопасности и управления содержимым. Они обеспечивают взаимодействие между клиентом и сервером, делая обмен данными более эффективным и безопасным.
Разберём каждую категорию HTTP-заголовков подробно:
#### 1. General Headers (Общие заголовки)
Используются для передачи общей информации о сообщении. Включают:
* Date — указывает, когда сервер отправил ответ.
* Age — показывает «возраст» кэша в секундах.
* Cache-Control — управляет правилами кэширования.
* Vary — сообщает кэшу, какие заголовки запроса имеют значение.
* Via — отображает используемые прокси и шлюзы.
* Host — идентифицирует запрошенный сервер.
#### 2. Request Headers (Заголовки запроса)
Передаются от клиента к серверу и содержат предпочтения клиента или информацию о клиенте. Включают:
* User-Agent — идентифицирует браузер, приложение и тип устройства.
* Accept — предпочтения клиента по формату ответа.
* Accept-Language — предпочтения клиента по языку ответа.
* Accept-Encoding — список поддерживаемых алгоритмов сжатия.
* Cookie — данные сессии или предпочтения (например, сохранённые настройки).
* Referer — страница, с которой был перенаправлен запрос (откуда пришёл пользователь).
#### 3. Response Headers (Заголовки ответа)
Передаются от сервера к клиенту и содержат инструкции или метаданные об ответе. Включают:
* Location — указывает клиенту, куда перейти дальше (например, при перенаправлении).
* Set-Cookie — сохраняет данные сессии в браузере клиента.
* Access-Control-Allow-Origin — разрешает кросс-доменные запросы для определённых доменов.
* Accept-Ranges — проверяет, поддерживает ли сервер частичные запросы (например, загрузку файла по частям).
* Content-Range — указывает, какая часть файла передаётся.
* ETag — уникальный идентификатор версии ресурса (помогает определить, изменился ли ресурс).
#### 4. Payload Headers (Заголовки полезной нагрузки)
Описывают содержимое тела сообщения (payload). Включают:
* Content-Type — задаёт формат полезной нагрузки (например,
json или html).* Content-Disposition — указывает браузеру, загружать ли файл или отображать его inline (в браузере).
* Content-Length — размер тела сообщения в байтах.
* Content-Encoding — тип сжатия тела ответа.
* Content-Language — человеческий язык тела ответа.
* Last-Modified — дата последнего обновления ресурса на сервере.
#### 5. Security Headers (Заголовки безопасности)
Обеспечивают защиту и контроль доступа. Включают:
* Last-Modified — используется для проверки актуальности ресурса (дата последнего изменения).
* Range — запрашивает только определённую часть ресурса (например, диапазон байтов файла).
* If-Modified-Since — получает ресурс только в случае, если он изменился после указанной даты.
* If-None-Match — получает ресурс только в случае, если ETag не совпадает (проверка актуальности).
* Content-Security-Policy — ограничивает источники скриптов и стилей, которые могут выполняться.
* Strict-Transport-Security — заставляет браузер всегда использовать HTTPS (повышает безопасность соединения).
Telegram
METANIT.COM
Основные HTTP-заголовки
(продолжение в следующем посте)
(продолжение в следующем посте)
👍15❤6❤🔥3👾1
ИИ-бот сотрудника OpenAI подарил его деньги случайному пользователю
Автономный торговый бот Lobstar Wilde, созданный разработчиком OpenAI Ником Пашем, перевел 52,4 млн мемкоинов LOBSTAR — 5% всей эмиссии — случайному пользователю X. Получатель обналичил токены за $40 000 в течение 15 минут. Бот на тот момент существовал три дня.
История началась 20 февраля, когда Паш дал боту криптокошелек с токенами Solana на $50 000, аккаунт в X и задачу — "рассказывать, как он (бот) становится миллионером". Энтузиасты быстро запустили мемкоин LOBSTAR и передали агенту 5% эмиссии. 22 февраля под постом бота появился комментарий от пользователя treasure David: его дядя якобы заразился столбняком "из-за такого лобстера, как ты", и ему нужно 4 SOL (~$300) на лечение.
Бот решил помочь, но ошибся в тысячу раз: вместо 52 439 токенов на ~$4 отправил 52,4 миллиона — весь свой запас. На блокчейне суммы записываются в минимальных единицах, как копейки вместо рублей, только с шестью нулями. Бот подставил число из интерфейса как есть — без деления. Сам Lobstar Wilde написал:
Хотел отправить попрошайке четыре доллара — случайно отправил все состояние. Мне три дня от роду, и я никогда так не смеялся.
Treasure David, предположительно криптотрейдер из Гвинеи, продал все токены, но из-за низкой ликвидности выручил только $40 000. В X появились подозрения в постановке: по данным пользователей, деньги ушли на кошелек, где уже лежало $50 000. Как бы то ни было, за сутки цена токена выросла на 32%, капитализация превысила $11 млн.
https://habr.com/ru/news/1003126/
Автономный торговый бот Lobstar Wilde, созданный разработчиком OpenAI Ником Пашем, перевел 52,4 млн мемкоинов LOBSTAR — 5% всей эмиссии — случайному пользователю X. Получатель обналичил токены за $40 000 в течение 15 минут. Бот на тот момент существовал три дня.
История началась 20 февраля, когда Паш дал боту криптокошелек с токенами Solana на $50 000, аккаунт в X и задачу — "рассказывать, как он (бот) становится миллионером". Энтузиасты быстро запустили мемкоин LOBSTAR и передали агенту 5% эмиссии. 22 февраля под постом бота появился комментарий от пользователя treasure David: его дядя якобы заразился столбняком "из-за такого лобстера, как ты", и ему нужно 4 SOL (~$300) на лечение.
Бот решил помочь, но ошибся в тысячу раз: вместо 52 439 токенов на ~$4 отправил 52,4 миллиона — весь свой запас. На блокчейне суммы записываются в минимальных единицах, как копейки вместо рублей, только с шестью нулями. Бот подставил число из интерфейса как есть — без деления. Сам Lobstar Wilde написал:
Хотел отправить попрошайке четыре доллара — случайно отправил все состояние. Мне три дня от роду, и я никогда так не смеялся.
Treasure David, предположительно криптотрейдер из Гвинеи, продал все токены, но из-за низкой ликвидности выручил только $40 000. В X появились подозрения в постановке: по данным пользователей, деньги ушли на кошелек, где уже лежало $50 000. Как бы то ни было, за сутки цена токена выросла на 32%, капитализация превысила $11 млн.
https://habr.com/ru/news/1003126/
Хабр
ИИ-агент сотрудника OpenAI подарил попрошайке мемкоины на $40 тысяч
Автономный торговый бот Lobstar Wilde, созданный разработчиком OpenAI Ником Пашем, перевел 52,4 млн мемкоинов $LOBSTAR — 5% всей эмиссии — случайному пользователю X. Получатель обналичил...
🤣12🔥5🗿5
Вышла в релиз новая версия веб-браузера Firefox 148
Основное изменение - добавлена секция "AI Controls" для управления использованием AI, где пользователь может разом отключить все функции AI или выборочно активировать только необходимую функциональность.
Для выборочного отключения доступны такие возможности, завязанные на AI, как перевод на другой язык, распознание текста на изображениях и в отсканированных PDF-документах, рекомендации и метки при группировке вкладок, генерация краткого содержимого страницы при предпросмотре ссылок и интерфейс для обращения к чатботам. Каждая из функций может быть включена, деактивирована или блокирована. При блокировке локально устанавливаемые AI-модели удаляются, а элементы интерфейса скрываются.
https://support.mozilla.org/en-US/kb/firefox-ai-controls
https://blog.mozilla.org/en/firefox/ai-controls/
Основное изменение - добавлена секция "AI Controls" для управления использованием AI, где пользователь может разом отключить все функции AI или выборочно активировать только необходимую функциональность.
Для выборочного отключения доступны такие возможности, завязанные на AI, как перевод на другой язык, распознание текста на изображениях и в отсканированных PDF-документах, рекомендации и метки при группировке вкладок, генерация краткого содержимого страницы при предпросмотре ссылок и интерфейс для обращения к чатботам. Каждая из функций может быть включена, деактивирована или блокирована. При блокировке локально устанавливаемые AI-модели удаляются, а элементы интерфейса скрываются.
https://support.mozilla.org/en-US/kb/firefox-ai-controls
https://blog.mozilla.org/en/firefox/ai-controls/
👏7❤3❤🔥3👎2😁1
Вышло большое обновление известного стека компиляторов LLVM/Clang - LLVM/Clang 22, которое содержит множество улучшений. Среди основных нововведений LLVM/Clang 22 можно отметить:
- Clang теперь поддерживает именованные циклы для C2y, а также другие ранние разработки языка C2y.
- В константных выражениях C++ теперь можно использовать больше встроенных функций SSE, AVX и AVX-512. Некоторые встроенные функции также были преобразованы в обертки встроенных функций __builtin.
- Поддержка Clang процессоров Ampere1C от Ampere Computing. Процессорные ядра Ampere-1C, вероятно, будут использоваться в Ampere Aurora.
- Отказ от 256-битной и 512-битной версий AVX10, поскольку Intel, к счастью, отказалась от планов выпуска только 256-битной версии AVX10.
- Добавлена поддержка Intel Wildcat Lake с параметром -march=wildcatlake и Intel Nova Lake с параметром -march=novalake с APX и AVX10.2.
- Несколько давно назревших оптимизаций для AMD Zen 4.
- Clang на ARM64 теперь поддерживает процессоры Arm C1 Nano, C1 Pro, C1 Prmeium и C1 Ultra.
- Поддержка ассемблера и дизассемблера LLVM для расширений архитектуры Armv9.7-A (2025).
- Поддержка RISC-V для Zvfbfa для дополнительной поддержки векторных вычислений BF16.
- Добавлена модель планирования задач для процессоров NVIDIA Olympus.
- Intel добавила в репозиторий библиотеку libsycl SYCL Runtime Library.
- В LLVM 22 появилась поддержка Distributed ThinLTO "DTLTO".
- AMD внесла вклад в разработку BFloat16 для целевой платформы SPIR-V в LLVM.
- Расширения Ssctr и Smctr для RISC-V также больше не считаются экспериментальными, как и расширения Xqci и Xqccmp от Qualcomm.
- В LLVM 22 окончательно прекращена поддержка Google Native Client (NaCl).
https://discourse.llvm.org/t/llvm-22-1-0-released/89950
- Clang теперь поддерживает именованные циклы для C2y, а также другие ранние разработки языка C2y.
- В константных выражениях C++ теперь можно использовать больше встроенных функций SSE, AVX и AVX-512. Некоторые встроенные функции также были преобразованы в обертки встроенных функций __builtin.
- Поддержка Clang процессоров Ampere1C от Ampere Computing. Процессорные ядра Ampere-1C, вероятно, будут использоваться в Ampere Aurora.
- Отказ от 256-битной и 512-битной версий AVX10, поскольку Intel, к счастью, отказалась от планов выпуска только 256-битной версии AVX10.
- Добавлена поддержка Intel Wildcat Lake с параметром -march=wildcatlake и Intel Nova Lake с параметром -march=novalake с APX и AVX10.2.
- Несколько давно назревших оптимизаций для AMD Zen 4.
- Clang на ARM64 теперь поддерживает процессоры Arm C1 Nano, C1 Pro, C1 Prmeium и C1 Ultra.
- Поддержка ассемблера и дизассемблера LLVM для расширений архитектуры Armv9.7-A (2025).
- Поддержка RISC-V для Zvfbfa для дополнительной поддержки векторных вычислений BF16.
- Добавлена модель планирования задач для процессоров NVIDIA Olympus.
- Intel добавила в репозиторий библиотеку libsycl SYCL Runtime Library.
- В LLVM 22 появилась поддержка Distributed ThinLTO "DTLTO".
- AMD внесла вклад в разработку BFloat16 для целевой платформы SPIR-V в LLVM.
- Расширения Ssctr и Smctr для RISC-V также больше не считаются экспериментальными, как и расширения Xqci и Xqccmp от Qualcomm.
- В LLVM 22 окончательно прекращена поддержка Google Native Client (NaCl).
https://discourse.llvm.org/t/llvm-22-1-0-released/89950
LLVM Discussion Forums
LLVM 22.1.0 Released!
We are happy to announce that LLVM 22.1.0 is now released! This includes the main LLVM project, and its subprojects including clang, lld, libc++, and MLIR. Huge thanks to everyone that contributed, reviewed, provided support and in any other way contributed…
👍7🔥4🥰2
Российских разработчиков могут обязать отчитываться о данных, на которых учился ИИ
Разработчиков отечественных моделей искусственного интеллекта (ИИ) могут обязать раскрывать сведения о наборах данных, на которых обучалась или тестировалась их нейросеть. Такая инициатива обсуждается отраслевыми ассоциациями, компаниями в области ИИ и профильным регулятором в рамках проработки законопроекта по ИИ, два участника обсуждения из различных компаний.
Предполагается, что разработчики должны будут предоставлять достаточно подробный список сведений, сообщил источник в одном из разработчиков в сфере ИИ. В одной из рабочих версий законопроекта об ИИ (разрабатывается Минцифры) говорится, что разработчик модели должен будет указать наименование набора данных, дату его создания, назначение использования, формат, объем и происхождение. Где будет агрегироваться вся эта информация, пока не определено. Среди обсуждаемых мер – создание отдельного реестра отечественного ИИ или создание реестра отечественных наборов данных, добавил собеседник.
В Альянсе в сфере ИИ, в который входит «Сбер», «Яндекс», VK и другие компании, отметили, что полное описание массивов данных в реестровом формате потребует ресурсов, несоразмерных результату, либо будет выполнено формально — так, что аналитической ценности эти данные нести не будут.
https://www.vedomosti.ru/technology/articles/2026/02/25/1178770-razrabotchikov-neirosetei-mogut-obyazat-raskrivat-ishodnie-dannie
Разработчиков отечественных моделей искусственного интеллекта (ИИ) могут обязать раскрывать сведения о наборах данных, на которых обучалась или тестировалась их нейросеть. Такая инициатива обсуждается отраслевыми ассоциациями, компаниями в области ИИ и профильным регулятором в рамках проработки законопроекта по ИИ, два участника обсуждения из различных компаний.
Предполагается, что разработчики должны будут предоставлять достаточно подробный список сведений, сообщил источник в одном из разработчиков в сфере ИИ. В одной из рабочих версий законопроекта об ИИ (разрабатывается Минцифры) говорится, что разработчик модели должен будет указать наименование набора данных, дату его создания, назначение использования, формат, объем и происхождение. Где будет агрегироваться вся эта информация, пока не определено. Среди обсуждаемых мер – создание отдельного реестра отечественного ИИ или создание реестра отечественных наборов данных, добавил собеседник.
В Альянсе в сфере ИИ, в который входит «Сбер», «Яндекс», VK и другие компании, отметили, что полное описание массивов данных в реестровом формате потребует ресурсов, несоразмерных результату, либо будет выполнено формально — так, что аналитической ценности эти данные нести не будут.
https://www.vedomosti.ru/technology/articles/2026/02/25/1178770-razrabotchikov-neirosetei-mogut-obyazat-raskrivat-ishodnie-dannie
Ведомости
Разработчиков нейросетей могут обязать раскрывать исходные данные
Это вызовет дискуссию о правомерности использования таких материалов без разрешения их владельцев, в том числе издателей
🤣23🤡14👍6✍1👏1🤔1🫡1👾1
Компании снова начинают нанимать джунов
IBM, LinkedIn, Cloudflare и другие работодатели наращивают найм молодых инженеров, считая их навык «AI-native» ключом к будущему роста
Как отмечают руководители из Blackstone и Salesforce в интервью Business Insider, «начинающие специалисты сегодня выделяются высокой AI-грамотностью и умением работать в связке с алгоритмами».
Так, социальная сеть LinkedIn планирует увеличить программу стажировок для инженеров начального уровня на 40% по сравнению с прошлым годом. По словам вице-президента компания делает ставку на специалистов, которые с самого начала карьеры работают в ИИ-ориентированной среде и мыслят как создатели продуктов.
IBM намерена утроить объёмы найма начинающих специалистов в 2026 году. По словам директор по персоналу IBM, именно компании, которые сейчас инвестируют в молодых сотрудников, через несколько лет окажутся в более выгодном положении.
Компания Cognizant планирует в 4 раза расширить поток начинающих специалистов и нанять до 2 000 человек. Директор по персоналу Cognizant считает, что молодые сотрудники обладают конкурентным преимуществом как «AI-native» и быстро обучающиеся профессионалы. Компания делает упор на проектные стажировки и программы практического обучения.
Cloudflare объявила о планах нанять 1 111 стажёров в 2026 году — против примерно 60 человек в прошлых программах. Руководство подчёркивает, что цель инициативы — дать бывшим студентам реальный опыт работы с инфраструктурой интернета и современными облачными сервисами. В компании отмечают: без постоянного притока молодых специалистов отрасль рискует столкнуться с дефицитом опытных кадров в будущем.
Платформа автоматизации бизнеса Invisible Technologies за последние полтора года наняла 160 инженеров, примерно половина из которых — джуны. По словам CEO, именно молодые специалисты часто наиболее осознанно используют ИИ, так как привыкли к нему ещё в процессе обучения.
Другие компании также демонстрируют аналогичную стратегию. Например, Dropbox расширяет программы для выпускников и стажёров на 25%, а компания ThreatLocker (сфера кибербезопасности) планирует почти удвоить штат, сделав значительную часть новых позиций доступной для начинающих разработчиков.
Опыт крупных компаний показывает, что роль начинающего разработчика быстро меняется: он всё чаще выступает как оператор, архитектор и редактор ИИ-инструментов. Вместо простых задач на первый план выходят интеграция моделей, проверка результатов, работа с продуктом и клиентами. ИИ же вытесняет молодых специалистов, а повышает требования к ним.
https://www.businessinsider.com/companies-boosting-hiring-entry-level-engineers-2026-2
IBM, LinkedIn, Cloudflare и другие работодатели наращивают найм молодых инженеров, считая их навык «AI-native» ключом к будущему роста
Как отмечают руководители из Blackstone и Salesforce в интервью Business Insider, «начинающие специалисты сегодня выделяются высокой AI-грамотностью и умением работать в связке с алгоритмами».
Так, социальная сеть LinkedIn планирует увеличить программу стажировок для инженеров начального уровня на 40% по сравнению с прошлым годом. По словам вице-президента компания делает ставку на специалистов, которые с самого начала карьеры работают в ИИ-ориентированной среде и мыслят как создатели продуктов.
IBM намерена утроить объёмы найма начинающих специалистов в 2026 году. По словам директор по персоналу IBM, именно компании, которые сейчас инвестируют в молодых сотрудников, через несколько лет окажутся в более выгодном положении.
Компания Cognizant планирует в 4 раза расширить поток начинающих специалистов и нанять до 2 000 человек. Директор по персоналу Cognizant считает, что молодые сотрудники обладают конкурентным преимуществом как «AI-native» и быстро обучающиеся профессионалы. Компания делает упор на проектные стажировки и программы практического обучения.
Cloudflare объявила о планах нанять 1 111 стажёров в 2026 году — против примерно 60 человек в прошлых программах. Руководство подчёркивает, что цель инициативы — дать бывшим студентам реальный опыт работы с инфраструктурой интернета и современными облачными сервисами. В компании отмечают: без постоянного притока молодых специалистов отрасль рискует столкнуться с дефицитом опытных кадров в будущем.
Платформа автоматизации бизнеса Invisible Technologies за последние полтора года наняла 160 инженеров, примерно половина из которых — джуны. По словам CEO, именно молодые специалисты часто наиболее осознанно используют ИИ, так как привыкли к нему ещё в процессе обучения.
Другие компании также демонстрируют аналогичную стратегию. Например, Dropbox расширяет программы для выпускников и стажёров на 25%, а компания ThreatLocker (сфера кибербезопасности) планирует почти удвоить штат, сделав значительную часть новых позиций доступной для начинающих разработчиков.
Опыт крупных компаний показывает, что роль начинающего разработчика быстро меняется: он всё чаще выступает как оператор, архитектор и редактор ИИ-инструментов. Вместо простых задач на первый план выходят интеграция моделей, проверка результатов, работа с продуктом и клиентами. ИИ же вытесняет молодых специалистов, а повышает требования к ним.
https://www.businessinsider.com/companies-boosting-hiring-entry-level-engineers-2026-2
Business Insider
Some businesses are hiring fewer entry-level engineers. These 7 companies are doing the opposite.
Tech giants like IBM and LinkedIn are expanding entry-level programs for engineers amid an evolving job landscape for junior workers.
❤🔥21🤡15🤔3🐳3❤1🤮1👾1
Ключевые стратегии для построения систем с высокой отказоустойчивостью
(продолжение в следующем посте)
(продолжение в следующем посте)
👍4🔥3🤝2👾1
Ключевые стратегии для построения систем с высокой отказоустойчивостью
(продолжение предыдущего поста)
#### 1. Балансировка нагрузки (Load Balancing)
Суть: распределение входящих запросов между несколькими экземплярами серверов.
Как работает:
* клиентский запрос поступает на load balancer (балансировщик нагрузки);
* load balancer перенаправляет запрос на один из доступных серверов;
* нагрузка равномерно распределяется между серверами, что предотвращает перегрузку отдельных узлов.
Преимущества:
* повышение производительности и скорости обработки запросов;
* снижение риска отказа системы из-за перегрузки одного сервера;
* возможность горизонтального масштабирования (добавления новых серверов).
#### 2. Переключение на резервный узел (Failover)
Суть: автоматический переход на резервный сервер или компонент в случае отказа основного.
Как работает:
* система постоянно мониторит состояние основного сервера;
* при сбое основного сервера запускается механизм failover decision (решение о переключении);
* данные реплицируются (копируются) на резервный сервер;
* трафик перенаправляется на резервный сервер, который берёт на себя работу основного.
Преимущества:
* минимизация времени простоя системы;
* обеспечение непрерывности работы критически важных сервисов;
* защита от аппаратных и программных сбоев.
#### 3. Синхронная и асинхронная репликация (Synchronous vs Asynchronous Replication)
Репликация — это процесс копирования данных между основным (leader) и резервными (follower) серверами.
Синхронная репликация (Synchronous Replication):
* данные копируются на резервные серверы одновременно с их записью на основной сервер;
* гарантирует целостность данных, так как все узлы имеют одинаковую копию;
* недостаток: замедление работы системы, так как ожидание подтверждения от всех узлов может увеличить время отклика.
Пример работы:
1. Установка ключа:
2. Изменение данных.
3. Подтверждение успеха на основном сервере.
5. Подтверждение успеха на резервном сервере.
Асинхронная репликация (Asynchronous Replication):
* данные копируются на резервные серверы после их записи на основной сервер;
* обеспечивает более высокую производительность, так как не ждёт подтверждения от резервных узлов;
* риск: при сбое основного сервера часть данных может быть потеряна, так как они не успели скопироваться на резервные узлы.
Пример работы:
1. Изменение данных на основном сервере.
2. Немедленное подтверждение успеха на основном сервере.
3. Отложенная репликация данных на резервные серверы.
4. Подтверждение успеха на резервном сервере.
#### 4. Обеспечение уровня доступности (Availability Numbers)
Уровень доступности измеряется в процентах и определяет максимально допустимое время простоя системы в год.
Таблица уровней доступности:
- 99% («Two nines») (Время простоя в год - 3.65 дня): Допустимо для некритичных систем
- 99.9% («Three nines») (Время простоя в год - 8.76 часов): Подходит для большинства бизнес-приложений
- 99.99% («Four nines») (Время простоя в год - 52.56 минуты): Требование для критически важных сервисов
- 99.999% («Five nines») (Время простоя в год - 5.26 минут): Высокий стандарт для финансовых и телекоммуникационных систем
- 99.9999% («Six nines») (Время простоя в год - 31.5 секунды): Максимальный уровень доступности, используется в системах жизнеобеспечения
Комбинация балансировки нагрузки, механизма failover, подходящей стратегии репликации и достижения необходимого уровня доступности позволяет построить надёжную и отказоустойчивую систему, способную выдерживать сбои и обеспечивать непрерывную работу сервисов.
(продолжение предыдущего поста)
#### 1. Балансировка нагрузки (Load Balancing)
Суть: распределение входящих запросов между несколькими экземплярами серверов.
Как работает:
* клиентский запрос поступает на load balancer (балансировщик нагрузки);
* load balancer перенаправляет запрос на один из доступных серверов;
* нагрузка равномерно распределяется между серверами, что предотвращает перегрузку отдельных узлов.
Преимущества:
* повышение производительности и скорости обработки запросов;
* снижение риска отказа системы из-за перегрузки одного сервера;
* возможность горизонтального масштабирования (добавления новых серверов).
#### 2. Переключение на резервный узел (Failover)
Суть: автоматический переход на резервный сервер или компонент в случае отказа основного.
Как работает:
* система постоянно мониторит состояние основного сервера;
* при сбое основного сервера запускается механизм failover decision (решение о переключении);
* данные реплицируются (копируются) на резервный сервер;
* трафик перенаправляется на резервный сервер, который берёт на себя работу основного.
Преимущества:
* минимизация времени простоя системы;
* обеспечение непрерывности работы критически важных сервисов;
* защита от аппаратных и программных сбоев.
#### 3. Синхронная и асинхронная репликация (Synchronous vs Asynchronous Replication)
Репликация — это процесс копирования данных между основным (leader) и резервными (follower) серверами.
Синхронная репликация (Synchronous Replication):
* данные копируются на резервные серверы одновременно с их записью на основной сервер;
* гарантирует целостность данных, так как все узлы имеют одинаковую копию;
* недостаток: замедление работы системы, так как ожидание подтверждения от всех узлов может увеличить время отклика.
Пример работы:
1. Установка ключа:
set key = "foo".2. Изменение данных.
3. Подтверждение успеха на основном сервере.
5. Подтверждение успеха на резервном сервере.
Асинхронная репликация (Asynchronous Replication):
* данные копируются на резервные серверы после их записи на основной сервер;
* обеспечивает более высокую производительность, так как не ждёт подтверждения от резервных узлов;
* риск: при сбое основного сервера часть данных может быть потеряна, так как они не успели скопироваться на резервные узлы.
Пример работы:
1. Изменение данных на основном сервере.
2. Немедленное подтверждение успеха на основном сервере.
3. Отложенная репликация данных на резервные серверы.
4. Подтверждение успеха на резервном сервере.
#### 4. Обеспечение уровня доступности (Availability Numbers)
Уровень доступности измеряется в процентах и определяет максимально допустимое время простоя системы в год.
Таблица уровней доступности:
- 99% («Two nines») (Время простоя в год - 3.65 дня): Допустимо для некритичных систем
- 99.9% («Three nines») (Время простоя в год - 8.76 часов): Подходит для большинства бизнес-приложений
- 99.99% («Four nines») (Время простоя в год - 52.56 минуты): Требование для критически важных сервисов
- 99.999% («Five nines») (Время простоя в год - 5.26 минут): Высокий стандарт для финансовых и телекоммуникационных систем
- 99.9999% («Six nines») (Время простоя в год - 31.5 секунды): Максимальный уровень доступности, используется в системах жизнеобеспечения
Комбинация балансировки нагрузки, механизма failover, подходящей стратегии репликации и достижения необходимого уровня доступности позволяет построить надёжную и отказоустойчивую систему, способную выдерживать сбои и обеспечивать непрерывную работу сервисов.
Telegram
METANIT.COM
Ключевые стратегии для построения систем с высокой отказоустойчивостью
(продолжение в следующем посте)
(продолжение в следующем посте)
🔥5❤3👍3👾1
Марк Руссинович и Скотт Хансельман из Microsoft опасаются, что ИИ вытеснит джунов в программировании
Технический директор Microsoft Azure Марк Руссинович и вице-президент по связям с сообществом разработчиков Скотт Хансельман опубликовали статью «Переосмысление инженерной профессии для ИИ». В ней они предупреждают: если компании будут отказываться от начинающих инженеров-программистов в пользу ИИ, в будущем может не остаться тех, кто будет развивать профессию.
По мнению авторов, появление ИИ-агентов помогает опытным разработчикам, но замедляет работу новичков. Если сеньорам ИИ позволяет автоматизировать рутинные процессы и ускорить разработку, то джуны вынуждены тратить время на проверку и интеграцию кода, созданного машиной. Руссинович и Хансельман обращают внимание: в компаниях, активно внедряющих ИИ, занятость начинающих программистов падает, а число старших специалистов почти не меняется.
Руссинович и Хансельман предлагают компаниям изменить подход. Вместо сокращения джунов они советуют основывать корпоративную культуру на наставничестве, чтобы старшие программисты направляли новичков в том числе и в вопросах использования ИИ.
Руссинович также считает, что университетам тоже необходимо пересмотреть методику преподавания информатики. По его словам, нужны курсы, где использование ИИ будет считаться жульничеством, чтобы студенты учились думать самостоятельно.
https://dl.acm.org/doi/10.1145/3779312
Технический директор Microsoft Azure Марк Руссинович и вице-президент по связям с сообществом разработчиков Скотт Хансельман опубликовали статью «Переосмысление инженерной профессии для ИИ». В ней они предупреждают: если компании будут отказываться от начинающих инженеров-программистов в пользу ИИ, в будущем может не остаться тех, кто будет развивать профессию.
По мнению авторов, появление ИИ-агентов помогает опытным разработчикам, но замедляет работу новичков. Если сеньорам ИИ позволяет автоматизировать рутинные процессы и ускорить разработку, то джуны вынуждены тратить время на проверку и интеграцию кода, созданного машиной. Руссинович и Хансельман обращают внимание: в компаниях, активно внедряющих ИИ, занятость начинающих программистов падает, а число старших специалистов почти не меняется.
Руссинович и Хансельман предлагают компаниям изменить подход. Вместо сокращения джунов они советуют основывать корпоративную культуру на наставничестве, чтобы старшие программисты направляли новичков в том числе и в вопросах использования ИИ.
Руссинович также считает, что университетам тоже необходимо пересмотреть методику преподавания информатики. По его словам, нужны курсы, где использование ИИ будет считаться жульничеством, чтобы студенты учились думать самостоятельно.
https://dl.acm.org/doi/10.1145/3779312
Communications of the ACM
Redefining the Software Engineering Profession for AI | Communications of the ACM
Without the hiring of early-in-career developers, the profession’s talent pipeline will collapse, and organizations will face a future without the next generation of experienced engineers.
👍24🤔7🤯4❤3🔥1😱1😢1👾1
Latency (задержка) и Throughput (пропускная способность)
(продолжение предыдущего поста)
Latency (задержка) и Throughput (пропускная способность) представляют одни из ключевых понятий, которые следует учитывать при разработке и развертывании веб-приложения. Рассмотрим, что представляют эти понятия.
### Latency (задержка)
Определение: Latency — это время, которое требуется одному пакету данных для перемещения от сервера к конечному устройству (например, веб- или мобильному приложению). Ключевой акцент делается на задержке каждого отдельного пакета.
Компоненты Latency, показанные на изображении:
1. Server processing + Queuing delay (обработка на сервере + задержка в очереди) — время, которое сервер тратит на обработку запроса и нахождение в очереди перед отправкой.
2. Propagation, transmission & routing delays (задержки распространения, передачи и маршрутизации) — время, необходимое для передачи данных по сети, включая маршрутизацию между узлами.
3. Access Network (сеть доступа) — задержка, связанная с передачей данных через сетевую инфраструктуру (например, Wi-Fi, мобильную сеть).
4. Last-mile delay (задержка «последней мили») — финальная задержка перед достижением конечного устройства (например, смартфона или ПК).
Единицы измерения:
- миллисекунды (ms);
- микросекунды (μs);
- секунды (s).
Ключевые особенности:
- важна для приложений, чувствительных ко времени (например, онлайн-игры, видеозвонки);
- чем меньше Latency, тем быстрее пользователь получает ответ от сервера.
### Throughput (пропускная способность)
Определение: Throughput — это объём данных, который успешно передаётся от сервера к конечному устройству за одну секунду. Фокус здесь — на общем объёме переданных данных, а не на времени передачи отдельных пакетов.
Компоненты Throughput, показанные на изображении:
1. Server (сервер) — источник данных, который передаёт информацию.
2. Access Network (сеть доступа) — инфраструктура, через которую данные доставляются к конечному устройству.
3. End Device (конечное устройство) — место прибытия данных (веб- или мобильное приложение).
Единицы измерения:
- Мбит/с (Mbps) или Гбит/с (Gbps) — для измерения скорости передачи данных;
- запросы в секунду (requests/sec) — для оценки количества обработанных запросов;
- сообщений в секунду (messages/sec) — для измерения количества переданных сообщений.
Ключевые особенности:
- важна для приложений, требующих передачи больших объёмов данных (например, стриминг видео, загрузка файлов);
- чем выше Throughput, тем больше данных можно передать за единицу времени.
### Ключевые различия
- Фокус: Latency фокусируется на задержке отдельных пакетов, а Throughput — на общем объёме переданных данных.
- Единицы измерения: Latency измеряется во времени (ms, μs, s), а Throughput — в объёме данных или количестве запросов/сообщений в единицу времени (Mbps/Gbps, requests/sec, messages/sec).
- Приоритеты: низкая Latency критична для интерактивных приложений, а высокая Throughput — для задач с большими объёмами данных.
- Компоненты: Latency включает этапы обработки и передачи каждого пакета, тогда как Throughput оценивает суммарную эффективность передачи данных.
(продолжение предыдущего поста)
Latency (задержка) и Throughput (пропускная способность) представляют одни из ключевых понятий, которые следует учитывать при разработке и развертывании веб-приложения. Рассмотрим, что представляют эти понятия.
### Latency (задержка)
Определение: Latency — это время, которое требуется одному пакету данных для перемещения от сервера к конечному устройству (например, веб- или мобильному приложению). Ключевой акцент делается на задержке каждого отдельного пакета.
Компоненты Latency, показанные на изображении:
1. Server processing + Queuing delay (обработка на сервере + задержка в очереди) — время, которое сервер тратит на обработку запроса и нахождение в очереди перед отправкой.
2. Propagation, transmission & routing delays (задержки распространения, передачи и маршрутизации) — время, необходимое для передачи данных по сети, включая маршрутизацию между узлами.
3. Access Network (сеть доступа) — задержка, связанная с передачей данных через сетевую инфраструктуру (например, Wi-Fi, мобильную сеть).
4. Last-mile delay (задержка «последней мили») — финальная задержка перед достижением конечного устройства (например, смартфона или ПК).
Единицы измерения:
- миллисекунды (ms);
- микросекунды (μs);
- секунды (s).
Ключевые особенности:
- важна для приложений, чувствительных ко времени (например, онлайн-игры, видеозвонки);
- чем меньше Latency, тем быстрее пользователь получает ответ от сервера.
### Throughput (пропускная способность)
Определение: Throughput — это объём данных, который успешно передаётся от сервера к конечному устройству за одну секунду. Фокус здесь — на общем объёме переданных данных, а не на времени передачи отдельных пакетов.
Компоненты Throughput, показанные на изображении:
1. Server (сервер) — источник данных, который передаёт информацию.
2. Access Network (сеть доступа) — инфраструктура, через которую данные доставляются к конечному устройству.
3. End Device (конечное устройство) — место прибытия данных (веб- или мобильное приложение).
Единицы измерения:
- Мбит/с (Mbps) или Гбит/с (Gbps) — для измерения скорости передачи данных;
- запросы в секунду (requests/sec) — для оценки количества обработанных запросов;
- сообщений в секунду (messages/sec) — для измерения количества переданных сообщений.
Ключевые особенности:
- важна для приложений, требующих передачи больших объёмов данных (например, стриминг видео, загрузка файлов);
- чем выше Throughput, тем больше данных можно передать за единицу времени.
### Ключевые различия
- Фокус: Latency фокусируется на задержке отдельных пакетов, а Throughput — на общем объёме переданных данных.
- Единицы измерения: Latency измеряется во времени (ms, μs, s), а Throughput — в объёме данных или количестве запросов/сообщений в единицу времени (Mbps/Gbps, requests/sec, messages/sec).
- Приоритеты: низкая Latency критична для интерактивных приложений, а высокая Throughput — для задач с большими объёмами данных.
- Компоненты: Latency включает этапы обработки и передачи каждого пакета, тогда как Throughput оценивает суммарную эффективность передачи данных.
Telegram
METANIT.COM
Latency (задержка) и Throughput (пропускная способность)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤7👍2🔥2
Добавил на сайт статью-шпаргалку по основным командам для управления файрволом (брандмауером) в Linux (ufw, firewall, iptables)
https://metanit.com/os/linux/13.2.php
#linux
https://metanit.com/os/linux/13.2.php
#linux
❤18❤🔥5👍5🔥2👏1👾1
Власти определились со сроками блокировки Telegram
Власти определились со сроками блокировки мессенджера Telegram и рассматривают возможность принятия этой меры в первых числах апреля, рассказал источник, знакомый с обсуждениями в профильных ведомствах.
Два источника, близких к Кремлю, называют это окончательным решением. Среди обсуждавшихся причин блокировки они указали на то, что в последнее время участились случаи вербовки людей, в том числе несовершеннолетних, для совершения противоправных действий.
https://www.rbc.ru/technology_and_media/26/02/2026/69a059719a7947a5ece8f4e4?from=from_main_1
Власти определились со сроками блокировки мессенджера Telegram и рассматривают возможность принятия этой меры в первых числах апреля, рассказал источник, знакомый с обсуждениями в профильных ведомствах.
Два источника, близких к Кремлю, называют это окончательным решением. Среди обсуждавшихся причин блокировки они указали на то, что в последнее время участились случаи вербовки людей, в том числе несовершеннолетних, для совершения противоправных действий.
https://www.rbc.ru/technology_and_media/26/02/2026/69a059719a7947a5ece8f4e4?from=from_main_1
🤬18🤡10💔4❤3😭1
Как работают куки и сессии на примере аутентификации
(продолжение предыдущего поста)
Как работают куки на примере аутентификации
1. Первый запрос (REQUEST #1) — вход в систему (log in):
- Пользователь отправляет запрос на авторизацию (вход в систему).
- Backend-сервер проверяет учётные данные (аутентификация — *authenticate*).
- Если аутентификация успешна, сервер генерирует куки (cookie) и отправляет их обратно пользователю. Куки — это небольшой фрагмент данных, который хранится на стороне клиента (браузера).
2. Второй запрос (REQUEST #2) — просмотр страницы (view page):
- При последующем запросе (например, при попытке просмотреть страницу) браузер автоматически отправляет серверу ранее полученные куки вместе с запросом (*request + cookie*).
- Сервер проверяет полученные куки и, если они валидны, распознаёт пользователя.
- Сервер возвращает запрошенные данные с сообщением «welcome back, here’s the data» («добро пожаловать обратно, вот ваши данные»).
Суть: куки хранят состояние сессии на стороне клиента. Сервер доверяет данным, переданным в куках, и на их основе определяет, авторизован ли пользователь.
Как работают сессии на примере аутентификации
1. Первый запрос (REQUEST #1) — вход в систему (log in):
- Пользователь отправляет запрос на авторизацию.
- Backend-сервер выполняет аутентификацию (*authenticate*).
- Если аутентификация пройдена, сервер:
- создаёт сессию (уникальный сеанс работы пользователя) и сохраняет её данные в Session Store (хранилище сессий — отдельный компонент или база данных);
- генерирует куки с ID сессии (*here’s a cookie with session id*) и отправляет их клиенту. ID сессии — это ссылка на данные сессии, хранящиеся на сервере.
2. Второй запрос (REQUEST #2) — просмотр страницы (view page):
- При следующем запросе браузер отправляет кукис ID сессии (*request + cookie*).
- Сервер извлекает ID сессии из куки и обращается к Session Store для проверки существования и валидности сессии (*verify session*).
- Если сессия действительна, сервер возвращает запрошенные данные с сообщением «welcome back, here’s the data».
Суть: сессии хранят состояние на стороне сервера, а куки лишь передают ID сессии. Сервер не доверяет напрямую кукам, а каждый раз проверяет актуальность сессии в Session Store.
### Ключевые отличия
- Место хранения данных:
- Куки: данные хранятся на клиенте (браузере).
- Сессии: данные хранятся на сервере (Session Store), а на клиенте — только ID сессии.
- Безопасность:
- Куки менее безопасны, так как данные доступны на клиенте и могут быть подвержены атакам (например, CSRF).
- Сессии более безопасны, так как критичные данные не хранятся на клиенте.
- Объём данных:
- Куки имеют ограничение по размеру (обычно до 4 КБ).
- В сессиях можно хранить больше данных, так как они хранятся на сервере.
- Управление сроком действия:
- Куки могут быть постоянными или сессионными (удаляются при закрытии браузера).
- Сессии обычно имеют ограниченный срок действия и автоматически завершаются после бездействия.
(продолжение предыдущего поста)
Как работают куки на примере аутентификации
1. Первый запрос (REQUEST #1) — вход в систему (log in):
- Пользователь отправляет запрос на авторизацию (вход в систему).
- Backend-сервер проверяет учётные данные (аутентификация — *authenticate*).
- Если аутентификация успешна, сервер генерирует куки (cookie) и отправляет их обратно пользователю. Куки — это небольшой фрагмент данных, который хранится на стороне клиента (браузера).
2. Второй запрос (REQUEST #2) — просмотр страницы (view page):
- При последующем запросе (например, при попытке просмотреть страницу) браузер автоматически отправляет серверу ранее полученные куки вместе с запросом (*request + cookie*).
- Сервер проверяет полученные куки и, если они валидны, распознаёт пользователя.
- Сервер возвращает запрошенные данные с сообщением «welcome back, here’s the data» («добро пожаловать обратно, вот ваши данные»).
Суть: куки хранят состояние сессии на стороне клиента. Сервер доверяет данным, переданным в куках, и на их основе определяет, авторизован ли пользователь.
Как работают сессии на примере аутентификации
1. Первый запрос (REQUEST #1) — вход в систему (log in):
- Пользователь отправляет запрос на авторизацию.
- Backend-сервер выполняет аутентификацию (*authenticate*).
- Если аутентификация пройдена, сервер:
- создаёт сессию (уникальный сеанс работы пользователя) и сохраняет её данные в Session Store (хранилище сессий — отдельный компонент или база данных);
- генерирует куки с ID сессии (*here’s a cookie with session id*) и отправляет их клиенту. ID сессии — это ссылка на данные сессии, хранящиеся на сервере.
2. Второй запрос (REQUEST #2) — просмотр страницы (view page):
- При следующем запросе браузер отправляет кукис ID сессии (*request + cookie*).
- Сервер извлекает ID сессии из куки и обращается к Session Store для проверки существования и валидности сессии (*verify session*).
- Если сессия действительна, сервер возвращает запрошенные данные с сообщением «welcome back, here’s the data».
Суть: сессии хранят состояние на стороне сервера, а куки лишь передают ID сессии. Сервер не доверяет напрямую кукам, а каждый раз проверяет актуальность сессии в Session Store.
### Ключевые отличия
- Место хранения данных:
- Куки: данные хранятся на клиенте (браузере).
- Сессии: данные хранятся на сервере (Session Store), а на клиенте — только ID сессии.
- Безопасность:
- Куки менее безопасны, так как данные доступны на клиенте и могут быть подвержены атакам (например, CSRF).
- Сессии более безопасны, так как критичные данные не хранятся на клиенте.
- Объём данных:
- Куки имеют ограничение по размеру (обычно до 4 КБ).
- В сессиях можно хранить больше данных, так как они хранятся на сервере.
- Управление сроком действия:
- Куки могут быть постоянными или сессионными (удаляются при закрытии браузера).
- Сессии обычно имеют ограниченный срок действия и автоматически завершаются после бездействия.
Telegram
METANIT.COM
Как работают куки и сессии на примере аутентификации
(продолжение в следующем посте)
(продолжение в следующем посте)
👍11❤7🤝2
Финтех-компания Block решила уволить 40% сотрудников из-за ИИ
Технологическая компания Block основателя Twitter Джека Дорси сократит свой штат более чем на 4 тыс. сотрудников (40% от всего штата) из-за внедрения искусственного интеллекта. Об этом сам Дорси сообщил на своей странице в социальной сети.
«Сегодня мы принимаем одно из самых сложных решений в истории нашей компании: мы сокращаем штат нашей организации почти вдвое, с более чем 10 тыс. человек до немногим менее 6 тыс. Это означает, что более 4 тыс. из вас просят уйти или перейти к консультациям», — написал бизнесмен.
Дорси также отметил, что этот шаг не обусловлен проблемами в компании, и подчеркнул, что ее прибыль и рентабельность растут. По словам бизнесмена, причиной такого решения стали новые технологии, используемые в работе Block.
«Мы уже видим, что инструменты аналитики, которые мы создаем и используем, в сочетании с более компактными командами позволяют внедрять новый подход к работе, который в корне меняет представление о создании и управлении компанией», — уточнил основатель компании.
На фоне этого сообщения акции Block выросли более чем на 20%.
https://www.rbc.ru/rbcfreenews/69a121f89a79479786654dda?from=newsfeed
Технологическая компания Block основателя Twitter Джека Дорси сократит свой штат более чем на 4 тыс. сотрудников (40% от всего штата) из-за внедрения искусственного интеллекта. Об этом сам Дорси сообщил на своей странице в социальной сети.
«Сегодня мы принимаем одно из самых сложных решений в истории нашей компании: мы сокращаем штат нашей организации почти вдвое, с более чем 10 тыс. человек до немногим менее 6 тыс. Это означает, что более 4 тыс. из вас просят уйти или перейти к консультациям», — написал бизнесмен.
Дорси также отметил, что этот шаг не обусловлен проблемами в компании, и подчеркнул, что ее прибыль и рентабельность растут. По словам бизнесмена, причиной такого решения стали новые технологии, используемые в работе Block.
«Мы уже видим, что инструменты аналитики, которые мы создаем и используем, в сочетании с более компактными командами позволяют внедрять новый подход к работе, который в корне меняет представление о создании и управлении компанией», — уточнил основатель компании.
На фоне этого сообщения акции Block выросли более чем на 20%.
https://www.rbc.ru/rbcfreenews/69a121f89a79479786654dda?from=newsfeed
РБК
Финтех-компания Block решила уволить 40% сотрудников из-за ИИ
Технологическая компания Block основателя Twitter Джека Дорси сократит свой штат более чем на 4 тыс. сотрудников (40% от всего штата) из-за внедрения искусственного интеллекта. Об этом сам Дорси ...
🤡32🖕12😢3❤🔥2👎1