Post #3381
1.94K
Шпаргалка по статистике и Data Science
- 🤣 14
- ✍ 7
- 😁 5
- 🤓 3
- 🤯 2
- 🤡 1
Channel Public Channel
ME - Subscribers
- 5.83K
- Photos
- 1.8K
- Videos
- 86
- Links
- 1.3K
Showing posts older than #3382 · Back to latest
Older Posts 18 shown
Post #3379
2.13K
12 архитектурных концепций, которые должен знать разработчик
(продолжение предыдущего поста)
Балансировка нагрузки (*Load Balancing*). Распределение входящего трафика между несколькими серверами, чтобы ни один узел не оказался перегружен.
Кэширование (*Caching*). Сохранение часто запрашиваемых данных в памяти для сокращения задержки.
Сеть доставки контента (*Content Delivery Network, CDN*). Хранение статических ресурсов на географически распределённых пограничных серверах — так пользователи загружают контент с ближайшего к ним узла.
Очередь сообщений (*Message Queue*). Разделение компонентов системы: отправители помещают сообщения в очередь, а получатели обрабатывают их асинхронно.
Модель «публикация — подписка» (*Publish‑Subscribe*). Позволяет нескольким получателям получать сообщения из определённой темы (топика).
API‑шлюз (*API Gateway*). Единая точка входа для клиентских запросов, которая управляет маршрутизацией, аутентификацией, ограничением частоты вызовов и преобразованием протоколов.
Предохранитель (*Circuit Breaker*). Отслеживает вызовы нижестоящих сервисов и прекращает попытки подключения, если число сбоев превышает заданный порог.
Обнаружение сервисов (*Service Discovery*). Автоматическое отслеживание доступных экземпляров сервисов, чтобы компоненты могли динамически находить друг друга и взаимодействовать.
Шардирование (*Sharding*). Разделение больших наборов данных между несколькими узлами на основе определённого ключа шарда.
Ограничение частоты вызовов (*Rate Limiting*). Контроль числа запросов, которые клиент может отправить за заданный промежуток времени, — это защищает сервисы от перегрузки.
Согласованное хеширование (*Consistent Hashing*). Распределение данных по узлам таким образом, чтобы минимизировать переорганизацию при добавлении или удалении узлов.
Автоматическое масштабирование (*Auto Scaling*). Динамическое добавление или удаление вычислительных ресурсов на основе заданных метрик.
(продолжение предыдущего поста)
Балансировка нагрузки (*Load Balancing*). Распределение входящего трафика между несколькими серверами, чтобы ни один узел не оказался перегружен.
Кэширование (*Caching*). Сохранение часто запрашиваемых данных в памяти для сокращения задержки.
Сеть доставки контента (*Content Delivery Network, CDN*). Хранение статических ресурсов на географически распределённых пограничных серверах — так пользователи загружают контент с ближайшего к ним узла.
Очередь сообщений (*Message Queue*). Разделение компонентов системы: отправители помещают сообщения в очередь, а получатели обрабатывают их асинхронно.
Модель «публикация — подписка» (*Publish‑Subscribe*). Позволяет нескольким получателям получать сообщения из определённой темы (топика).
API‑шлюз (*API Gateway*). Единая точка входа для клиентских запросов, которая управляет маршрутизацией, аутентификацией, ограничением частоты вызовов и преобразованием протоколов.
Предохранитель (*Circuit Breaker*). Отслеживает вызовы нижестоящих сервисов и прекращает попытки подключения, если число сбоев превышает заданный порог.
Обнаружение сервисов (*Service Discovery*). Автоматическое отслеживание доступных экземпляров сервисов, чтобы компоненты могли динамически находить друг друга и взаимодействовать.
Шардирование (*Sharding*). Разделение больших наборов данных между несколькими узлами на основе определённого ключа шарда.
Ограничение частоты вызовов (*Rate Limiting*). Контроль числа запросов, которые клиент может отправить за заданный промежуток времени, — это защищает сервисы от перегрузки.
Согласованное хеширование (*Consistent Hashing*). Распределение данных по узлам таким образом, чтобы минимизировать переорганизацию при добавлении или удалении узлов.
Автоматическое масштабирование (*Auto Scaling*). Динамическое добавление или удаление вычислительных ресурсов на основе заданных метрик.
- ❤ 7
- 🔥 4
- 👏 2
- 🥰 1
Post #3378
1.99K
12 архитектурных концепций, которые должен знать разработчик
(продолжение в следующем посте)
(продолжение в следующем посте)
- 👍 3
- ❤ 1
- 🔥 1
Post #3376
2.27K
Как работает concurrency
- 👍 8
- ❤ 5
- 🤔 3
- 🍓 2
- 🤝 1
Post #3375
2.23K
На GitHub запустили обсуждение возможности для автоматической блокировки мусорных pull-запросов, сгенерированных в AI-ассистентах, отправленных без ручной проверки и не соответствующих требованиям качества.
Причина обсуждения - подобные изменения создают дополнительную нагрузку на сопровождающих, которые вынуждены тратить время на разбор бесполезного кода.
Основные опасения сопровождающих при работе с подобными pull-запросами выглядят следующим образом:
- Рецензирующие не могут быть уверены, что приславший изменение написал переданный код и понимает его суть.
- Сгенерированные в AI-ассистентах pull-запросы могут структурно выглядеть корректно, но быть логически неверными, небезопасными или непроверенными в работе.
- У сопровождающих возникает дискомфорт при принятии pull-запросов, которых они не полностью понимают, в то время как AI-ассистенты упрощают передачу крупных изменений без глубокого понимания.
- Повышается когнитивная нагрузка на сопровождающих, которые теперь должны не только проверять код, но и оценивать то, понимает ли его автор.
- Появление AI-инструментов не снизило, а увеличило нагрузку на сопровождающих.
По статистике одного из ключевых разработчиков фреймворка genkit лишь одно из десяти изменений, подготовленных в AI, соответствует критериям для открытия pull-запроса.
В качестве возможных решений предлагается расширение модели полномочий и предоставление сопровождающим инструментов для гибкого задания правил, которые определяют, кто имеет право создавать и рецензировать pull-запросы и каким требованиям должны соответствовать pull-запросы.
Кроме того, предлагается использовать AI для определения соответствия отправленного изменения правилам и стандартам качества каждого проекта, а также выявления и специальной пометки изменений, подготовленных при помощи AI.
https://github.com/orgs/community/discussions/185387
Причина обсуждения - подобные изменения создают дополнительную нагрузку на сопровождающих, которые вынуждены тратить время на разбор бесполезного кода.
Основные опасения сопровождающих при работе с подобными pull-запросами выглядят следующим образом:
- Рецензирующие не могут быть уверены, что приславший изменение написал переданный код и понимает его суть.
- Сгенерированные в AI-ассистентах pull-запросы могут структурно выглядеть корректно, но быть логически неверными, небезопасными или непроверенными в работе.
- У сопровождающих возникает дискомфорт при принятии pull-запросов, которых они не полностью понимают, в то время как AI-ассистенты упрощают передачу крупных изменений без глубокого понимания.
- Повышается когнитивная нагрузка на сопровождающих, которые теперь должны не только проверять код, но и оценивать то, понимает ли его автор.
- Появление AI-инструментов не снизило, а увеличило нагрузку на сопровождающих.
По статистике одного из ключевых разработчиков фреймворка genkit лишь одно из десяти изменений, подготовленных в AI, соответствует критериям для открытия pull-запроса.
В качестве возможных решений предлагается расширение модели полномочий и предоставление сопровождающим инструментов для гибкого задания правил, которые определяют, кто имеет право создавать и рецензировать pull-запросы и каким требованиям должны соответствовать pull-запросы.
Кроме того, предлагается использовать AI для определения соответствия отправленного изменения правилам и стандартам качества каждого проекта, а также выявления и специальной пометки изменений, подготовленных при помощи AI.
https://github.com/orgs/community/discussions/185387
- ❤ 17
- 👍 12
- 💯 4
- 🔥 2
- 🤔 1
- 🍓 1
Post #3373
2.25K
Вайб-кодинг убивает open-source
Несколько европейских университетов провели исследование по поводу влияния вайб-кодинга на экосистему открытых проектов. Исследователи разработали модель равновесия экосистемы открытого кода, которая показала, что обратные связи, ранее отвечавшие за взрывной рост открытых проектов, после распространения вайб-кодинга создают обратный эффект - уменьшается число разработчиков готовых делиться кодом, сокращается разнообразие открыты проектов и снижается качество. Одним из вариантов решения проблемы упоминается внедрение модели финансирования, напоминающей Spotify, при которой AI‑платформы перераспределяют доходы от подписок на сервисы для разработчиков среди сопровождающих, в зависимости от степени использования проектов.
При вайб-кодинге разработчики перестают анализировать доступные решения, читать документацию, отправлять сообщения об ошибках и взаимодействовать с командами, развивающими открытые библиотеки. Открытые проекты теряют обратную связь с пользователям. Новым проектам становится сложнее пробиться, так как AI-ассистенты сами подбирают необходимые открытые библиотеки на основе информации, имевшейся на момент обучения модели. Из-за снижения прямого взаимодействия с пользователями страдает монетизация отрытых проектов, завязанных на услугах поддержки и показе рекламы/сборе пожертвований на сайтах. Из-за снижения обратной связи страдает качество. С другой стороны, вайб-кодинг повышает производительность труда при создании новых продуктов, основанных на чуждом коде, и упрощает внедрение новых библиотек.
В качестве примера приведится Tailwind CSS, число загрузок которого из NPM растет, но трафик к документации с начала 2023 года снизился на 40%, а доходы упали на 80%. Также отмечено снижение активности обсуждений на Stack Overflow примерно на 25%, спустя 6 месяцев после запуска ChatGPT.
https://news.slashdot.org/story/26/02/03/1754205/vibe-coding-kills-open-source
https://arxiv.org/abs/2601.15494
news.slashdot.org 'Vibe Coding Kills Open Source' Four economists across Central European University, Bielefeld University and the Kiel Institute have built a general equilibrium model of the open-source software ecosystem and concluded that vibe coding -- the increasingly common practice of letting AI agents… Несколько европейских университетов провели исследование по поводу влияния вайб-кодинга на экосистему открытых проектов. Исследователи разработали модель равновесия экосистемы открытого кода, которая показала, что обратные связи, ранее отвечавшие за взрывной рост открытых проектов, после распространения вайб-кодинга создают обратный эффект - уменьшается число разработчиков готовых делиться кодом, сокращается разнообразие открыты проектов и снижается качество. Одним из вариантов решения проблемы упоминается внедрение модели финансирования, напоминающей Spotify, при которой AI‑платформы перераспределяют доходы от подписок на сервисы для разработчиков среди сопровождающих, в зависимости от степени использования проектов.
При вайб-кодинге разработчики перестают анализировать доступные решения, читать документацию, отправлять сообщения об ошибках и взаимодействовать с командами, развивающими открытые библиотеки. Открытые проекты теряют обратную связь с пользователям. Новым проектам становится сложнее пробиться, так как AI-ассистенты сами подбирают необходимые открытые библиотеки на основе информации, имевшейся на момент обучения модели. Из-за снижения прямого взаимодействия с пользователями страдает монетизация отрытых проектов, завязанных на услугах поддержки и показе рекламы/сборе пожертвований на сайтах. Из-за снижения обратной связи страдает качество. С другой стороны, вайб-кодинг повышает производительность труда при создании новых продуктов, основанных на чуждом коде, и упрощает внедрение новых библиотек.
В качестве примера приведится Tailwind CSS, число загрузок которого из NPM растет, но трафик к документации с начала 2023 года снизился на 40%, а доходы упали на 80%. Также отмечено снижение активности обсуждений на Stack Overflow примерно на 25%, спустя 6 месяцев после запуска ChatGPT.
https://news.slashdot.org/story/26/02/03/1754205/vibe-coding-kills-open-source
https://arxiv.org/abs/2601.15494
- 😭 20
- 💯 12
- 🥰 2
- 🌚 2
- 🍓 1
Post #3372
2.02K
Команда Cursor опубликовала разбор архитектуры мультиагентной системы, которая на пике делала около 1000 коммитов в час — 10 млн вызовов за неделю непрерывной работы без вмешательства человека. Тестовым проектом был веб-браузер на Rust
Архитектура напоминает обычную команду разработки. Корневой планировщик владеет всей задачей и порождает подпланировщиков для отдельных направлений. Воркеры берут конкретные задачи, работают в своей копии репозитория и ничего не знают о системе в целом. По окончании они передают фидбек — заметки, сомнения, отклонения от плана и обратную связь
Один из ключевых выводов: требование 100% корректности каждого коммита убивало производительность. Одна опечатка/изменение API останавливали всю систему, агенты бросались чинить одно и то же. Cursor сознательно разрешил небольшой процент ошибок — они быстро исправлялись другими агентами, а общий уровень оставался стабильным. Для релизов предусмотрена отдельная ветка с финальной проверкой.
https://cursor.com/blog/self-driving-codebases
Архитектура напоминает обычную команду разработки. Корневой планировщик владеет всей задачей и порождает подпланировщиков для отдельных направлений. Воркеры берут конкретные задачи, работают в своей копии репозитория и ничего не знают о системе в целом. По окончании они передают фидбек — заметки, сомнения, отклонения от плана и обратную связь
Один из ключевых выводов: требование 100% корректности каждого коммита убивало производительность. Одна опечатка/изменение API останавливали всю систему, агенты бросались чинить одно и то же. Cursor сознательно разрешил небольшой процент ошибок — они быстро исправлялись другими агентами, а общий уровень оставался стабильным. Для релизов предусмотрена отдельная ветка с финальной проверкой.
https://cursor.com/blog/self-driving-codebases
- 🤡 14
- ❤ 8
Post #3371
1.85K
30 базовых концепций LLM
(продолжение предыдущего поста)
1. LLM (Large Language Model) — модель, которая генерирует текст, предсказывая наиболее вероятный следующий токен.
2. Token (токен) — фрагмент текста, например, слово или знак препинания.
3. Tokenization (токенизация) — процесс преобразования текста в последовательность токенов.
4. Embeddings (эмбеддинги) — числовые векторы, которые отражают значение токенов.
5. Latent Space (латентное пространство) — математическое пространство, где эмбеддинги организуются по смыслу.
6. Parameters (параметры) — внутренние переменные, хранящие усвоенные моделью паттерны.
7. Pre-training (предварительное обучение) — обучение на огромных объёмах текстовых данных для освоения языковых паттернов.
8. Base Model (базовая модель) — предварительно обученная модель, которая предсказывает текст, но не следует инструкциям.
9. Instruct Model (модель с инструкциями) — базовая модель, дополнительно обученная следовать инструкциям и давать полезные ответы.
10. Fine-Tuning (дообучение) — дополнительное обучение на меньшем наборе данных для формирования поведения модели.
11. Alignment (выравнивание) — обеспечение того, чтобы поведение модели было полезным, честным и безвредным.
12. RLHF (Reinforcement Learning with Human Feedback — обучение с подкреплением с обратной связью от человека) — использование ранжированных человеком ответов для корректировки поведения модели.
13. Prompt (промпт) — полный ввод, отправляемый модели, включая инструкции и контекст.
14. System Prompt (системный промпт) — высокоуровневые инструкции, определяющие роль и ограничения модели.
15. User Prompt (пользовательский промпт) — конкретный вопрос или инструкция, предоставленная пользователем.
16. Context Window (окно контекста) — максимальное количество токенов, которое модель может обработать за один раз.
17. Zero-Shot Learning (обучение без примеров) — выполнение задачи без примеров в промпте.
18. Few-Shot Learning (обучение на нескольких примерах) — включение примеров в промпт для направления формата вывода или поведения.
19. Chain of Thought (цепочка мыслей) — побуждение модели демонстрировать пошаговое рассуждение.
20. Inference (вывод) — процесс генерации выходных токенов с помощью обученной модели.
21. Latency (задержка) — время между отправкой промпта и получением вывода.
22. Temperature (температура) — параметр, контролирующий случайность при выборе токенов.
23. Hallucination (галлюцинация) — уверенная генерация неверной или вымышленной информации.
24. Grounding (привязка к реальности) — ограничение вывода предоставленной или проверяемой информацией.
25. RAG (Retrieval-Augmented Generation — генерация, дополненная поиском) — извлечение внешних данных и добавление их в промпт перед генерацией.
26. Workflow (рабочий процесс) — фиксированная, предопределённая последовательность шагов, которых придерживается LLM.
27. Agent (агент) — система, в которой LLM планирует действия, а затем динамически выбирает шаги и инструменты.
28. Multimodality (мультимодальность) — способность обрабатывать несколько типов входных данных, таких как текст и изображения.
29. Benchmarks (бенчмарки) — стандартизированные тесты для сравнения возможностей модели.
30. Guardrails (ограничители) — системы, блокирующие небезопасные или неподходящие входные и выходные данные.
(продолжение предыдущего поста)
1. LLM (Large Language Model) — модель, которая генерирует текст, предсказывая наиболее вероятный следующий токен.
2. Token (токен) — фрагмент текста, например, слово или знак препинания.
3. Tokenization (токенизация) — процесс преобразования текста в последовательность токенов.
4. Embeddings (эмбеддинги) — числовые векторы, которые отражают значение токенов.
5. Latent Space (латентное пространство) — математическое пространство, где эмбеддинги организуются по смыслу.
6. Parameters (параметры) — внутренние переменные, хранящие усвоенные моделью паттерны.
7. Pre-training (предварительное обучение) — обучение на огромных объёмах текстовых данных для освоения языковых паттернов.
8. Base Model (базовая модель) — предварительно обученная модель, которая предсказывает текст, но не следует инструкциям.
9. Instruct Model (модель с инструкциями) — базовая модель, дополнительно обученная следовать инструкциям и давать полезные ответы.
10. Fine-Tuning (дообучение) — дополнительное обучение на меньшем наборе данных для формирования поведения модели.
11. Alignment (выравнивание) — обеспечение того, чтобы поведение модели было полезным, честным и безвредным.
12. RLHF (Reinforcement Learning with Human Feedback — обучение с подкреплением с обратной связью от человека) — использование ранжированных человеком ответов для корректировки поведения модели.
13. Prompt (промпт) — полный ввод, отправляемый модели, включая инструкции и контекст.
14. System Prompt (системный промпт) — высокоуровневые инструкции, определяющие роль и ограничения модели.
15. User Prompt (пользовательский промпт) — конкретный вопрос или инструкция, предоставленная пользователем.
16. Context Window (окно контекста) — максимальное количество токенов, которое модель может обработать за один раз.
17. Zero-Shot Learning (обучение без примеров) — выполнение задачи без примеров в промпте.
18. Few-Shot Learning (обучение на нескольких примерах) — включение примеров в промпт для направления формата вывода или поведения.
19. Chain of Thought (цепочка мыслей) — побуждение модели демонстрировать пошаговое рассуждение.
20. Inference (вывод) — процесс генерации выходных токенов с помощью обученной модели.
21. Latency (задержка) — время между отправкой промпта и получением вывода.
22. Temperature (температура) — параметр, контролирующий случайность при выборе токенов.
23. Hallucination (галлюцинация) — уверенная генерация неверной или вымышленной информации.
24. Grounding (привязка к реальности) — ограничение вывода предоставленной или проверяемой информацией.
25. RAG (Retrieval-Augmented Generation — генерация, дополненная поиском) — извлечение внешних данных и добавление их в промпт перед генерацией.
26. Workflow (рабочий процесс) — фиксированная, предопределённая последовательность шагов, которых придерживается LLM.
27. Agent (агент) — система, в которой LLM планирует действия, а затем динамически выбирает шаги и инструменты.
28. Multimodality (мультимодальность) — способность обрабатывать несколько типов входных данных, таких как текст и изображения.
29. Benchmarks (бенчмарки) — стандартизированные тесты для сравнения возможностей модели.
30. Guardrails (ограничители) — системы, блокирующие небезопасные или неподходящие входные и выходные данные.
- 👍 10
- ❤ 6
- ❤🔥 3
- 🤝 1
Post #3370
1.76K
Post #3368
2.4K
Наглядно, как работает простая нейронная сеть ANN на 50 нейронов на 2 уровнях
- ❤ 38
- 🖕 3
- 👍 2
- 🔥 1
Post #3366
1.8K
Разница между протоколами IPv4 и IPv6
(продолжение предыдущего поста)
IPv4 и IPv6 являются двумя протоколами для взаимодействия по сети. Рассмотрим конкретные отличия между ними:
1. Формат адреса:
* IPv4: использует числовую точечно-десятичную нотацию (например, 192.168.0.12). Адреса состоят из 32 бит, что позволяет использовать около 4,3 миллиарда уникальных адресов (2³²).
* IPv6: использует алфавитно-шестнадцатеричную нотацию (например, 50B3:F200:0211:AB00:0123:4321:6571:B000). Адреса состоят из 128 бит, что обеспечивает колоссальное количество уникальных адресов (2¹²⁸) — практически неограниченное число для каждого устройства.
2. Количество доступных адресов:
* IPv4: ограниченное количество адресов (2³²), из-за чего адреса приходится повторно использовать и маскировать.
* IPv6: каждый устройство может иметь уникальный адрес благодаря огромному пространству адресов (2¹²⁸).
3. Способ настройки:
* IPv4: настройка осуществляется через DHCP (Dynamic Host Configuration Protocol) или вручную. Протокол был развёрнут в 1981 году.
* IPv6: поддерживает автоматическую настройку адресов, что упрощает развёртывание и управление сетью. Протокол был внедрён в 1998 году.
4. Структура заголовка (header):
* IPv4 Header включает поля:
* Version (версия);
* IHL (Internet Header Length — длина заголовка в 32-битных словах);
* Type of Service (тип обслуживания);
* Total Length (общая длина пакета);
* Identification (идентификатор);
* Flags (флаги);
* Fragment Offset (смещение фрагмента);
* TTL (Time to Live — время жизни пакета);
* Protocol (протокол);
* Header Checksum (контрольная сумма заголовка);
* Source Address (адрес источника);
* Destination Address (адрес назначения);
* Options (опции) и Padding (дополнение).
* IPv6 Header упрощён и содержит:
* Version (версия);
* Traffic Class (класс трафика — аналог Type of Service в IPv4);
* Flow Label (метка потока — новое поле для идентификации потоков данных);
* Payload Length (длина полезной нагрузки);
* Next Header (следующий заголовок — указывает на тип следующего заголовка в пакете);
* Hop Limit (предел хопов — аналог TTL);
* Source Address (адрес источника);
* Destination Address (адрес назначения).
Некоторые поля IPv4 либо удалены, либо изменены в IPv6, что снижает нагрузку на обработку пакетов.
5. Совместимость и взаимодействие:
* Dual Stack (двойной стек): позволяет устройствам работать одновременно с IPv4 и IPv6. Приложения могут использовать как IPv4, так и IPv6, взаимодействуя через TCP/UDP.
* Перевод между сетями: сети IPv4 и IPv6 не могут напрямую взаимодействовать — требуется трансляция (перевод) адресов для обеспечения связи между устройствами, использующими разные протоколы.
6. Идентификаторы протоколов:
* IPv4: Protocol ID — 0x0800.
* IPv6: Protocol ID — 0x86DD.
7. Уровень безопасности:
* IPv6 изначально разработан с учётом поддержки механизмов безопасности (например, IPsec), в то время как в IPv4 безопасность добавляется дополнительно.
Таким образом, IPv6 является эволюцией IPv4, решая ключевые проблемы предшественника — ограниченность адресного пространства, сложность настройки и недостаточную безопасность. Упрощённая структура заголовка и поддержка автоматической конфигурации делают IPv6 более современным и эффективным протоколом для будущих сетевых решений.
(продолжение предыдущего поста)
IPv4 и IPv6 являются двумя протоколами для взаимодействия по сети. Рассмотрим конкретные отличия между ними:
1. Формат адреса:
* IPv4: использует числовую точечно-десятичную нотацию (например, 192.168.0.12). Адреса состоят из 32 бит, что позволяет использовать около 4,3 миллиарда уникальных адресов (2³²).
* IPv6: использует алфавитно-шестнадцатеричную нотацию (например, 50B3:F200:0211:AB00:0123:4321:6571:B000). Адреса состоят из 128 бит, что обеспечивает колоссальное количество уникальных адресов (2¹²⁸) — практически неограниченное число для каждого устройства.
2. Количество доступных адресов:
* IPv4: ограниченное количество адресов (2³²), из-за чего адреса приходится повторно использовать и маскировать.
* IPv6: каждый устройство может иметь уникальный адрес благодаря огромному пространству адресов (2¹²⁸).
3. Способ настройки:
* IPv4: настройка осуществляется через DHCP (Dynamic Host Configuration Protocol) или вручную. Протокол был развёрнут в 1981 году.
* IPv6: поддерживает автоматическую настройку адресов, что упрощает развёртывание и управление сетью. Протокол был внедрён в 1998 году.
4. Структура заголовка (header):
* IPv4 Header включает поля:
* Version (версия);
* IHL (Internet Header Length — длина заголовка в 32-битных словах);
* Type of Service (тип обслуживания);
* Total Length (общая длина пакета);
* Identification (идентификатор);
* Flags (флаги);
* Fragment Offset (смещение фрагмента);
* TTL (Time to Live — время жизни пакета);
* Protocol (протокол);
* Header Checksum (контрольная сумма заголовка);
* Source Address (адрес источника);
* Destination Address (адрес назначения);
* Options (опции) и Padding (дополнение).
* IPv6 Header упрощён и содержит:
* Version (версия);
* Traffic Class (класс трафика — аналог Type of Service в IPv4);
* Flow Label (метка потока — новое поле для идентификации потоков данных);
* Payload Length (длина полезной нагрузки);
* Next Header (следующий заголовок — указывает на тип следующего заголовка в пакете);
* Hop Limit (предел хопов — аналог TTL);
* Source Address (адрес источника);
* Destination Address (адрес назначения).
Некоторые поля IPv4 либо удалены, либо изменены в IPv6, что снижает нагрузку на обработку пакетов.
5. Совместимость и взаимодействие:
* Dual Stack (двойной стек): позволяет устройствам работать одновременно с IPv4 и IPv6. Приложения могут использовать как IPv4, так и IPv6, взаимодействуя через TCP/UDP.
* Перевод между сетями: сети IPv4 и IPv6 не могут напрямую взаимодействовать — требуется трансляция (перевод) адресов для обеспечения связи между устройствами, использующими разные протоколы.
6. Идентификаторы протоколов:
* IPv4: Protocol ID — 0x0800.
* IPv6: Protocol ID — 0x86DD.
7. Уровень безопасности:
* IPv6 изначально разработан с учётом поддержки механизмов безопасности (например, IPsec), в то время как в IPv4 безопасность добавляется дополнительно.
Таким образом, IPv6 является эволюцией IPv4, решая ключевые проблемы предшественника — ограниченность адресного пространства, сложность настройки и недостаточную безопасность. Упрощённая структура заголовка и поддержка автоматической конфигурации делают IPv6 более современным и эффективным протоколом для будущих сетевых решений.
- ❤ 14
- 👍 4
- 🤝 2
Post #3365
1.88K
Post #3361
2.2K
Ведущие инженеры Anthropic и OpenAI: “ИИ уже пишет 100% нашего кода”
В Anthropic некоторые инженеры больше не пишут код, на котором работают их продукты. Руководитель направления Claude Code в Anthropic, Борис Черный, признался, что уже более двух месяцев не писал ни строчки кода собственноручно и что теперь 100% его кода создается с помощью ИИ. По его словам, в масштабах всей компании эта доля колеблется примерно между 70% и 90%. Что же касается самого Claude Code, то около 90% его собственного кода создается им же самим – своеобразный замкнутый круг автоматизации.
Roon, популярный анонимный аккаунт в X, который ведет исследователь OpenAI, тоже написал, что больше не создает код сам. “Сто процентов – я больше не пишу код”, – ответил он на вопрос о том, какую долю работы за него выполняют ИИ-модели. В другой публикации он добавил: “Программирование всегда было мучением. Необходимой болью почти для каждого, кто хотел заставить компьютер делать что-то полезное. И я рад, что с этим покончено”.
https://fortune.com/2026/01/29/100-percent-of-code-at-anthropic-and-openai-is-now-ai-written-boris-cherny-roon/
В Anthropic некоторые инженеры больше не пишут код, на котором работают их продукты. Руководитель направления Claude Code в Anthropic, Борис Черный, признался, что уже более двух месяцев не писал ни строчки кода собственноручно и что теперь 100% его кода создается с помощью ИИ. По его словам, в масштабах всей компании эта доля колеблется примерно между 70% и 90%. Что же касается самого Claude Code, то около 90% его собственного кода создается им же самим – своеобразный замкнутый круг автоматизации.
Roon, популярный анонимный аккаунт в X, который ведет исследователь OpenAI, тоже написал, что больше не создает код сам. “Сто процентов – я больше не пишу код”, – ответил он на вопрос о том, какую долю работы за него выполняют ИИ-модели. В другой публикации он добавил: “Программирование всегда было мучением. Необходимой болью почти для каждого, кто хотел заставить компьютер делать что-то полезное. И я рад, что с этим покончено”.
https://fortune.com/2026/01/29/100-percent-of-code-at-anthropic-and-openai-is-now-ai-written-boris-cherny-roon/
- 🤣 30
- 🤡 15
- 😁 8
- 👎 3
- 👍 2
- 🔥 2
Post #3358
2.59K
ИИ-бот заплатил человеку $100 за физический пикет
Ранее сообщалось, что для ИИ-агентов появился сервис, где они могут нанять людей. И вот пользователь из США рассказал, что нашел подработу на ресурсе Rent a Human, где ИИ-бот заплатил ему $100 за физический пикет с нарисованным от руки плакатом.
В задании было указано, что человеку надо просто сделать большой плакат с надписью, что ИИ заплатил ему за это.
После выполнения задания человек получил оплату.
В настоящее время на ресурсе не особо много физических заданий, но есть вот такие: посчитать голубей в парке в определённое время и предоставить итоговый отчёт, содержащий: общее количество, имена голубей с описаниями и любые заметные особенности поведения голубей. «Это важное научное исследование, заказанное коалицией агентов ИИ, которые не могут лично наблюдать за голубями. Ваш вклад в базу знаний о голубях будет высоко оценён», — пояснил заказчик.
https://rentahuman.ai/bounties
Ранее сообщалось, что для ИИ-агентов появился сервис, где они могут нанять людей. И вот пользователь из США рассказал, что нашел подработу на ресурсе Rent a Human, где ИИ-бот заплатил ему $100 за физический пикет с нарисованным от руки плакатом.
В задании было указано, что человеку надо просто сделать большой плакат с надписью, что ИИ заплатил ему за это.
После выполнения задания человек получил оплату.
В настоящее время на ресурсе не особо много физических заданий, но есть вот такие: посчитать голубей в парке в определённое время и предоставить итоговый отчёт, содержащий: общее количество, имена голубей с описаниями и любые заметные особенности поведения голубей. «Это важное научное исследование, заказанное коалицией агентов ИИ, которые не могут лично наблюдать за голубями. Ваш вклад в базу знаний о голубях будет высоко оценён», — пояснил заказчик.
https://rentahuman.ai/bounties
- ❤ 16
- 😁 14
- 🤡 8
- 🤔 2
Post #3357
2.17K
Шпаргалка по двоичному представлению числовых значений
- 👍 16
- 🔥 1
- 🥰 1
Post #3355
2.68K
В США спрос на редакторов и писателей вырос из-за развития ИИ
Один из экспертов заявил, что на рынке контента «настолько много мусора», что работодатели готовы платить большие суммы тем, кто может писать качественно, сообщает портал
аботодатели в США снова стремятся нанимать специалистов в области коммуникаций, редакторов и писателей, поскольку вместе с распространением технологий искусственного интеллекта (ИИ) растет количество некачественного контента, сгенерированного нейросетями. Об этом сообщил портал Business Insider.
Отмечается, что с ростом количества ИИ-контента в сети снова появилась необходимость в редакторах и специалистах, способных писать качественные и убедительные тексты, благодаря которым компания сможет выделиться среди конкурентов. Некоторые эксперты отмечают, что лучшая защита от автоматизации — это гуманитарное образование. Один из экспертов заявил, что на рынке контента «настолько много мусора», что работодатели готовы платить большие суммы тем, кто может писать качественно.
https://tass.ru/ekonomika/26345669
Один из экспертов заявил, что на рынке контента «настолько много мусора», что работодатели готовы платить большие суммы тем, кто может писать качественно, сообщает портал
аботодатели в США снова стремятся нанимать специалистов в области коммуникаций, редакторов и писателей, поскольку вместе с распространением технологий искусственного интеллекта (ИИ) растет количество некачественного контента, сгенерированного нейросетями. Об этом сообщил портал Business Insider.
Отмечается, что с ростом количества ИИ-контента в сети снова появилась необходимость в редакторах и специалистах, способных писать качественные и убедительные тексты, благодаря которым компания сможет выделиться среди конкурентов. Некоторые эксперты отмечают, что лучшая защита от автоматизации — это гуманитарное образование. Один из экспертов заявил, что на рынке контента «настолько много мусора», что работодатели готовы платить большие суммы тем, кто может писать качественно.
https://tass.ru/ekonomika/26345669
- 🤣 28
- ❤ 7
- 👍 5
- 🔥 2
Post #3354
1.88K
Как работает атака CSRF (Cross-Site Request Forgery)
(продолжение предыдущего поста)
CSRF — это атака, при которой злоумышленник вынуждает жертву выполнить нежелательные действия в веб-приложении, где она уже аутентифицирована. Рассмотрим механизм атаки по этапам, согласно изображению:
1. Пользователь входит в систему и получает сессионный cookie/токен (шаг 1):
* пользователь заходит на легитимный сайт и проходит аутентификацию;
* сайт выдаёт пользователю сессионный cookie или токен, который подтверждает его авторизацию.
2. Злоумышленник создаёт вредоносный веб-сайт или код (шаг 2):
* атакующий разрабатывает специальную страницу или фрагмент кода, который имитирует легитимные запросы к сайту, где пользователь уже авторизован;
* цель — заставить браузер жертвы отправить запрос на целевой сайт от имени пользователя.
3. Пользователь взаимодействует с вредоносным контентом (шаг 3):
* жертва посещает вредоносный сайт или кликает на ссылку, содержащую вредоносный код (например, через фишинг, социальную инженерию);
* при этом пользователь остаётся авторизованным на целевом сайте (где хранится его cookie/токен).
4. Вредоносный код отправляет запрос с учётными данными пользователя (шаг 4):
* вредоносный код автоматически формирует HTTP-запрос (например, для перевода денег, изменения настроек аккаунта и т. д.) и отправляет его на целевой сайт;
* браузер жертвы передаёт вместе с запросом сессионный cookie/токен, так как считает запрос легитимным (пользователь уже авторизован).
5. Целевой сайт обрабатывает поддельный запрос (шаг 5):
* сайт не может отличить легитимный запрос от поддельного, так как видит валидный cookie/токен;
* сайт выполняет действие, заложенное в запросе (например, переводит деньги, меняет пароль и т. д.), думая, что это действие инициировал сам пользователь.
6. Злоумышленник получает несанкционированный доступ и манипулирует действиями учётной записи пользователя (шаг 6):
* атакующий достигает своей цели — выполняет нежелательные действия от имени жертвы (кража данных, финансовые махинации, распространение вредоносного контента и т. д.).
### Способы защиты от CSRF-атак:
* Использование Anti-CSRF токенов — уникальные токены добавляются в формы и запросы для проверки легитимности.
* Двойная отправка cookies (Double Submit Cookies) — сравнение cookies в HTTP-заголовке и теле запроса.
* Проверка заголовка Referer — сайт анализирует, откуда пришёл запрос, и отклоняет подозрительные.
* Ограничение cookies для одного сайта (SameSite cookies) — предотвращает отправку cookies на сторонние сайты.
* Ограничение методов запросов (Limit Request Methods) — разрешаются только безопасные HTTP-методы (например, GET), а опасные (POST, PUT) требуют дополнительной проверки.
* Усиленная аутентификация пользователя — дополнительные шаги подтверждения (например, двухфакторная аутентификация) для критических действий.
(продолжение предыдущего поста)
CSRF — это атака, при которой злоумышленник вынуждает жертву выполнить нежелательные действия в веб-приложении, где она уже аутентифицирована. Рассмотрим механизм атаки по этапам, согласно изображению:
1. Пользователь входит в систему и получает сессионный cookie/токен (шаг 1):
* пользователь заходит на легитимный сайт и проходит аутентификацию;
* сайт выдаёт пользователю сессионный cookie или токен, который подтверждает его авторизацию.
2. Злоумышленник создаёт вредоносный веб-сайт или код (шаг 2):
* атакующий разрабатывает специальную страницу или фрагмент кода, который имитирует легитимные запросы к сайту, где пользователь уже авторизован;
* цель — заставить браузер жертвы отправить запрос на целевой сайт от имени пользователя.
3. Пользователь взаимодействует с вредоносным контентом (шаг 3):
* жертва посещает вредоносный сайт или кликает на ссылку, содержащую вредоносный код (например, через фишинг, социальную инженерию);
* при этом пользователь остаётся авторизованным на целевом сайте (где хранится его cookie/токен).
4. Вредоносный код отправляет запрос с учётными данными пользователя (шаг 4):
* вредоносный код автоматически формирует HTTP-запрос (например, для перевода денег, изменения настроек аккаунта и т. д.) и отправляет его на целевой сайт;
* браузер жертвы передаёт вместе с запросом сессионный cookie/токен, так как считает запрос легитимным (пользователь уже авторизован).
5. Целевой сайт обрабатывает поддельный запрос (шаг 5):
* сайт не может отличить легитимный запрос от поддельного, так как видит валидный cookie/токен;
* сайт выполняет действие, заложенное в запросе (например, переводит деньги, меняет пароль и т. д.), думая, что это действие инициировал сам пользователь.
6. Злоумышленник получает несанкционированный доступ и манипулирует действиями учётной записи пользователя (шаг 6):
* атакующий достигает своей цели — выполняет нежелательные действия от имени жертвы (кража данных, финансовые махинации, распространение вредоносного контента и т. д.).
### Способы защиты от CSRF-атак:
* Использование Anti-CSRF токенов — уникальные токены добавляются в формы и запросы для проверки легитимности.
* Двойная отправка cookies (Double Submit Cookies) — сравнение cookies в HTTP-заголовке и теле запроса.
* Проверка заголовка Referer — сайт анализирует, откуда пришёл запрос, и отклоняет подозрительные.
* Ограничение cookies для одного сайта (SameSite cookies) — предотвращает отправку cookies на сторонние сайты.
* Ограничение методов запросов (Limit Request Methods) — разрешаются только безопасные HTTP-методы (например, GET), а опасные (POST, PUT) требуют дополнительной проверки.
* Усиленная аутентификация пользователя — дополнительные шаги подтверждения (например, двухфакторная аутентификация) для критических действий.
- ❤ 9
- 👍 7
- 🙏 2
Post #3353
1.91K
