Hacker News Digest

Инициатива Patch the Planet позволила выявить критическую уязвимость в PHP — языке, на котором работает значительная часть сайтов и веб-приложений. Модель GPT‑5.6 Sol нашла изъян, а компания Wiz независимо обнаружила и сообщила об обеих уязвимостях. Исправления подготовили сопровождающие PHP при участии OpenAI, Wiz, Cloudflare и других партнёров, а также при содействии государственных киберведомств. По оценке авторов, это одна из самых значимых проблем безопасности за последнее время: она показывает, что ИИ способен находить уязвимости интернет-масштаба, но те же возможности помогают злоумышленникам быстро создавать эксплойты. Ключевой факт: передовые модели нашли эти дыры раньше атакующих, открыв «окно защитника» для подготовки исправлений до раскрытия.

Для организаций, использующих PHP, приоритет — установить обновления; для этого опубликован чекер версий PHP в виде навыка Codex. OpenAI обязалась выделить 1 млрд долларов на субсидируемый доступ Daybreak для организаций с ограниченными ресурсами, защищающих критически важные сервисы. Компания предупреждает, что подобных находок будет резко больше в ближайшие месяцы, и предлагает сообществу обсудить рамки реагирования: сроки раскрытия, экстренное патчирование, ранние уведомления и «безопасные по умолчанию» пакеты.

Участники обсуждения опровергают «магию» ИИ, считая инициативу OpenAI маркетинговым ходом для создания имиджа «спасителя» кибербезопасности. @nr378 утверждает, что успех зависел от глубоких знаний исследователя Calif о кодовой базе, тогда как @senordevnyc отмечает, что OpenAI лишь указали на использование модели. @OlivOnTech и @aprilnya критикуют «навык» проверки версии PHP, считая бесполезным запуск `php -V`, а @post-it добавляет, что команда `php --version` не всегда показывает версию реально запущенного интерпретатора. @lifeisloving отмечает деградацию навыков молодых инженеров: некоторые Senior-разработчики не знают базовых команд ОС (например, grep) из-за зависимости от LLM. В споре об этике open source @12837615 называет обучение моделей на открытом коде «кражей», а @fritzo и @orangedog считают, что код был отдан добровольно. Вместо раздачи токенов ИИ @12837615 предлагает инвестировать в QA open source проектов для обеспечения 100% покрытия тестами, использования ASAN и фаззеров. @ptmkenny и @sevenzero заметили, что официальные патчи коснулись только поддерживаемых версий (от 8.2), в то время как устаревшие ветки 7.x и 5.6 патчатся сторонними энтузиастами (например, Mr Sury).

Cloudflare и VoidZero совместно с Максом Швенком из Owner.com работают над tsrs — портом компилятора TypeScript на Rust, который развивается в составе инструментальной цепочки Oxc. Это не форк: команда TypeScript сохраняет полный контроль над языком, а порт обязан строго следовать её решениям, иначе со временем станет несовместимым. Ранние замеры обещают до 8 раз большей скорости и примерно на 70% меньше памяти по сравнению с TypeScript 7.0 при том же числе обработчиков проверки типов. При этом TypeScript 7.1 beta уже до 2.5 раз быстрее 7.0, и часть оптимизаций пришла из tsrs.

Попробовать экспериментальную версию можно через npm install tsrs и npx tsrs. Rust выбран не только ради скорости: важна и сборка в WebAssembly, что упрощает запуск полноценной среды разработки прямо в браузере. По умолчанию tsrs использует адаптивную конфигурацию, зависящую от типа машины: она потребляет больше памяти, но работает ещё быстрее. Авторы подчёркивают, что раньше масштабные порты почти не удавались, а теперь передовые ИИ-модели способны выполнять их за считанные дни.

Процесс сопровождается автоматикой: агенты ежедневно проверяют изменения, собирают диффы и заводят задачи, а ночью прогоняют тесты Next.js против Vinext, выявляя расхождения. Тот же подход применят к TypeScript, стараясь не вносить отличий в поведение и возвращая улучшения производительности в кодовую базу TypeScript на Go. Пока есть расхождения, например порядок вывода диагностик, но к стабильному релизу их сведут к минимуму. В планах — более глубокая интеграция tsrs в стек Cloudflare, в том числе для типозависимых правил линтера в Oxlint.

tsrs демонстрирует до 8-кратный рост скорости и снижение потребления памяти на ~70%. Эти показатели достигнуты не только за счет Rust, но и благодаря алгоритмическим оптимизациям, которые планируют перенести в TypeScript 7.1. Основным драйвером порта стала необходимость легкого компилятора для WASM-песочницы, где Rust предпочтительнее тяжелого Go-runtime. При этом арена-модель памяти в tsrs вызывает опасения, так как скрывает unsafe-код и может быть небезопасной. Также отмечается, что AI-генерация порта ускоряет разработку, но требует тщательного ревью из-за риска архитектурных ошибок. tsrs хорошо масштабируется при многопоточном запуске и поддерживает инкрементные проверки, хотя bun остается эффективнее по общим метрикам.

DeepSeek выпустила снимок модели V4.1 Flash от 17 октября 2026 года — разреженную смесь экспертов, первую на архитектуре Causal Encoder-Decoder. Из общего числа параметров 552 млрд активируется лишь 8 млрд на входе и 16 млрд на выходе: асимметричное разделение снижает вычислительные затраты на токен относительно размера модели. Понимание изображений встроено в архитектуру изначально — визуальные и текстовые эмбеддинги обучались совместно с самого начала предобучения, а не добавлялись позже, как в экспериментальной V4 Flash Vision Exp.

Модель ориентирована на кодинг, работу в терминале и агентов компьютерного использования, а также на длительные многошаговые задачи и анализ длинного контекста. Сжатое KV-кэширование сокращает память кэша примерно до четверти от предыдущего поколения Flash, заметно снижая стоимость агентных нагрузок. DeepSeek позиционирует её как экономичный уровень семейства V4.1 и заявляет, что она превосходит V4 Pro по производительности, скорости и времени выполнения задач.

Цена — 0,10 доллара за миллион входных и 0,50 за миллион выходных токенов, контекст — 1 млн токенов. Модель обслуживают четыре провайдера на OpenRouter: inference.net, Cloudflare, DeepInfra и сама DeepSeek; запросы маршрутизируются с автоматическим переключением при сбое. На вход принимаются текст и изображения, на выходе — только текст.

Обсуждение подтверждает преимущества DeepSeek v4.1 Flash в скорости и стоимости, добавляя реальные цифры и опыт эксплуатации, но отмечает требовательность к аппаратуре, возможные ограничения в качестве и сомнения в объективности бенчмарков. Пользователи подтверждают, что модель достигает ~3400 токенов/сек на Mac M5 Ultra и значительно дешевле по токену, чем Sol 5.6/6.1. В поиске уязвимостей и ревью кода результаты почти эквивалентны, но исправления часто более точные — например, меняет размер буфера ровно до 191 байт, без запаса. Открытость модели (видимость цепочки рассуждений, отсутствие случайных блокировок) повышает удобство в агентных сценариях. Для локального запуска требуется минимум 64 ГБ ОЗУ и SSD‐стриминг; недостаток памяти приводит к замедлению или повторным попыткам. Некоторые участники указывают, что официальные бенчмарки могут быть отобраны, а ограничения модели заметны в реальных задачах, особенно при длительном агентном планировании. Стоимость веб‐поиска через DeepSeek в 10 раз дешевле, чем у OpenAI; пользователи ждут отдельного API для этой функции. Комбинация DeepSeek Flash с Opus 5.5 снижает расходы до $200/мес, заменяя дорогие подписки на Claude Code. В экспериментах с «swarm»‐агентами DeepSeek v4.1 Flash выигрывает по скорости и цене, хотя Opus 5.5 остаётся более интеллектуально продвинутой. Рост открытых моделей вроде DeepSeek ставит под сомнение бизнес‐модели OpenAI и Anthropic, где прибыль зависит от вычислительных ресурсов.

Пользователь NAS с обычным набором приложений «*arr» обнаружил в очереди Sonarr застрявший эпизод «Южного парка» — файл с расширением .exe и 2392 сидерами на публичных трекерах. qBittorrent пометил загрузку завершённой с нулевым объёмом, поэтому на диск ничего не попало, а Sonarr каждые 90 секунд безуспешно пытался импортировать несуществующий путь. После блокировки в Sonarr автор намеренно скачал файл снова, чтобы разобрать его.

Это оказался настоящий PE-файл x64 с GUI: полезная программа весит всего 118 КБ, а остальные 886 МБ — случайный мусор, приклеенный, чтобы сканеры сдавались на больших файлах. Код усыпан бессмысленными XOR-операциями, лишь запутывающими декомпилятор. Логика сводится к шести шагам: открыть свой файл, прочитать последние 64 байта, расшифровать скрытую полезную нагрузку, вручную отобразить её как PE в памяти, подменить PEB->ImageBaseAddress и передать управление. На диск ничего не пишется.

Последние 64 байта — это конфиг: ключ, nonce ChaCha20, размер нагрузки и флаги, замаскированные через FNV-1a. Флаги включают антиотладку и антипесочницу. Ключ лежит прямо в файле, так что расшифровать можно без запуска. Внутри — второй PE, а адрес управляющего сервера спрятан в base64-строке, XOR-нутой с набором символов, и ведёт на YouTube-канал «bubblegym», созданный 14 сентября 2026 года. Домен beenetprotect[dot]com зарегистрирован в тот же день через Cloudflare, сборка — 6 октября, торрент — 8 октября.

Для защиты автор советует добавить *.exe, *.scr, *.lnk, *.bat, *.cmd в исключения qBittorrent, блокировать такие раздачи в Sonarr и Radarr с удалением из клиента, а в Prowlarr понижать или удалять трекеры, которые это распространяют.

Тред подтверждает реальный инцидент с компрометацией трекера ITorrent: все торренты заменены на .exe‐файлы с 800 МБ «заполнителем» и маскировкой как реальный контент. Злоумышленники используют такие файлы для кражи заметок Sticky Notes и криптовалютных ключей, что демонстрирует серьёзность угрозы. Предлагаются практические меры защиты в *arr‐стеке: - В Sonarr включить параметр «Fail Downloads» для индекса и добавить в список «Executables» — такие загрузки помечаются как неудачные и инициируют новый поиск автоматически. - Использовать общие публичные трекеры вместо частных — это снижает риск заражённых .exe‐файлов и увеличивает число сидеров. - Настраивать профили качества через TraSH‐гайды — помогает избежать низкокачественных и потенциально вредоносных торрентов. - Использовать скрипт sbstp, который через API qBittorrent сканирует и удаляет торренты с .exe‐файлами, если они не загружаются. - При обнаружении .exe‐файла в процессе скачивания в qBittorrent сразу удалять торрент — предотвращает дальнейшие попытки импорта. Указываются недостатки существующих средств защиты: - Windows Defender не имеет достаточных эвристик для обнаружения подобных .exe‐файлов. - Sonarr по умолчанию не игнорирует .exe‐файлы, хотя это можно настроить. - Сложность *arr‐стека (множество компонентов, отсутствие встроенного торрент‐клиента) усложняет настройку и повышает риск ошибок. Анти‐пиратские компании применяют правила, дающие .exe‐файлам отрицательный вес (-1000), чтобы снизить их привлекательность. Пиратство сопровождается случайными рекламными и вредоносными файлами — это неизбежная «стоимость» использования таких сервисов.

После сообщений об ударах по дата-центрам «Яндекса» в сети распространились утверждения, что российские ботофермы и операции влияния выведены из строя. Графики HTTP-трафика действительно показали резкое падение, но агрегированные метрики обманчивы. У «Яндекса» два автономных номера: AS13238 обслуживает поисковик, AS200350 — облачные сервисы. По данным Cloudflare Radar, 11 октября трафик поиска упал на 99% ниже базового уровня, облака — на 90%; к 13 октября оба оставались на 86–90% ниже нормы.

Однако падение затронуло разные вещи. С AS13238 ушёл почти исключительно верифицированный поисковый краулер: 99,5% запросов классифицированы как автоматические, 93,6% из них — «Verified». Главный эффект — сокращение индексации контента. С AS200350, где 95% запросов — боты, но ни один не верифицирован, временно снизились сканирование уязвимостей и зондирование плагинов. При этом высокообъёмная автоматизация не исчезла — она мигрировала к другим хостинг-провайдерам.

Данные не подтверждают, что удары парализовали манипуляции в соцсетях: глобальный трафик за период события даже вырос на 1,1%. Вывод: объём трафика по ASN — ненадёжный индикатор поведения ботов. Защита требует анализа поведения запросов — общих отпечатков JA4, аномальных частот, правил WAF. Физическая инфраструктура статична, а вредоносная автоматизация создана, чтобы перемещаться.

Данные Cloudflare показывают падение трафика из Yandex.Cloud на ~40 % и блокировки на 70 %, что указывает на снижение вредоносного трафика из этого ASN. Однако эти данные отражают только трафик, проходящий через сеть Cloudflare, и не охватывают основные соцсети, поэтому выводы о полном отключении ботов нельзя считать окончательными. Cloudflare измерял в основном скрейпинг‐боты, а не ботов‐пропагандистов, публикующих комментарии в соцсетях. По наблюдениям, доля комментариев, генерируемых ботами, упала с ~13‐27 % до менее 1 % после отключения, что свидетельствует о снижении активности некоторых бот‐сетей. Yandex.Cloud значительно меньше AWS; крупные российские компании используют собственные дата‐центры, поэтому общий эффект от отключения ограничен. Поисковая выдача yandex.com сейчас ограничена одной страницей из 10 результатов, указывая на проблемы с поисковым сервисом. Некоторые пользователи отмечают, что последствия отключения были кратковременными и сервисы сейчас работают нормально. Боты‐пропагандисты часто используют мобильные SIM‐карты и другие методы, недоступные для отслеживания Cloudflare. Отсутствие доказательств не является доказательством отсутствия: Cloudflare не смог обнаружить ботов, а не доказал их отсутствие. Для более точного измерения влияния ботов следует использовать данные непосредственно от соцсетей или специализированных мониторинговых сервисов. Масштабы влияния на информационные операции остаются неясными.

Падение трафика Yandex‐ботов на 99 % связано с ударом дронов по дата‐центрам, выведшим из строя их веб‐краулеры. Это технический сбой, а не исчезновение российских соцсетевых ботов. Yandex‐боты — это краулеры для индексации, работающие из дата‐центров, а не из мобильных или резидентных прокси. Нет публичных эмпирических данных, подтверждающих снижение hate‐speech после атаки; утверждения о падении праворадикального контента остаются неподтверждёнными слухами. Для проверки гипотезы следует дождаться независимых исследований или запросить отчёты аналитических компаний, например Cloudflare.

Падение трафика ботов Яндекса в Cloudflare связано с отключением нескольких дата‐центров Яндекса, поэтому снижается только бот‐трафик из их ASN, в то время как общий бот‐трафик из России почти не изменился.

• Снижение показателя «Bot traffic from Yandex» объясняется тем, что три из пяти основных дата‐центров Яндекса вышли из строя, и их ASN перестал генерировать запросы.

• Метрика измеряет процент HTTP‐запросов, классифицированных как боты, исходящих из IP‐диапазона Яндекса, а не общий объём трафика сайта.

• Сравнение с общим бот‐трафиком по России и миру показывает, что заметного падения нет – снижение локализовано только в ASN Яндекса.

• Большая часть трафика из этого ASN представляет собой поисковые краулеры и сервисные запросы, а не вредоносные или рекламные боты.

• Cloudflare классифицирует ботов по баллам (1‐29 – бот, 30+ – человек); при отключении дата‐центров количество запросов с низким баллом резко падает.

Talorys — это личный AI-агент, который развёртывается полностью в вашем собственном Cloudflare-аккаунте через одну команду npx create-talorys@latest. Он работает без внешних серверов, баз данных или телеметрии, используя только ресурсы Cloudflare: Pages для фронтенда, Durable Object для хранения состояния и Workers AI для генерации ответов. Агент поддерживает чат с потоковыми ответами, долговременную память (только релевантные факты передаются модели), управление задачами, заметками и проектами, а также автоматизации — напоминания и рутины, запускаемые через alarms Durable Object, поэтому ничего не нужно держать онлайн постоянно.

Система спроектирована для одного пользователя: при установке задаётся пароль владельца, а авторизация происходит в воркере, не на фронтенде. Даже если quota Workers AI исчерпана, функции задач, памяти и напоминаний продолжают работать. Обновление выполняется той же командой — оно переразвёртывает код, сохраняя данные, пароль и сессии благодаря append-only миграциям SQLite в Durable Object. Всё взаимодействие браузера ограничено вашим *.pages.dev сайтом, а /api-запросы проксируются через service binding к приватному воркеру без публичного URL.

В ходе обсуждения возник спор о термине «self-hosted»: одни считают его применимым к облачным ресурсам под собственным управлением, другие — только к физическому контролю над оборудованием. Поскольку Cloudflare контролирует инфраструктуру и логи, многие полагают, что название Talorys вводит в заблуждение, и предлагают заменить его на «self-managed» или «hosted on Cloudflare». Также предложено разделить понятия на «self-running» (собственное железо) и «self-hosting» (управление развертыванием). Особенности использования Cloudflare: — Workers AI слишком медленен для интерактивного чата. — Durable Objects эффективны для хранения состояния агента благодаря мгновенному пробуждению и интеграции данных без внешних баз. — Бесплатный тариф (Free Tier) ненадежен из-за риска внезапного отзыва. — Пользователь @hung предупреждает о скрытых списаниях в AI-тарифе и игнорировании обращений поддержкой. Технические замечания и советы: — @vlovich123 отметил, что замена Workers AI на локальную модель занимает менее 20 минут и не меняет архитектуру. — @andrewdb выявил отсутствие семантической памяти (агент не учитывает контекст, например, вегетарианство) и предложил внедрить семантическое извлечение. — @ahel указал, что чат-интерфейс не всегда приносит значимую пользу. Talorys не требует сторонних сервисов, кроме аккаунта Cloudflare, что делает его примером «open-source, vendor-locked» решения: независимого от разработчика, но зависимого от платформы.

Deno команда присоединяется к Cloudflare, чтобы продолжить работу над упрощением создания серверного ПО. Их цель — объединить вычисления, хранение и связь в единую модель, где приложения не собирают инфраструктуру сами. Это логичное продолжение пути от Deno через Deno Deploy к celld — платформе, построенной на Cloudflare Workers и Durable Objects, где масштабирование заложено в саму модель программирования, а не в инфраструктуру каждого приложения. Команда видит в этом способ сделать такую модель стандартной для серверной разработки, независимо от того, где запущено приложение.

В рамках перехода Deno runtime получит поддержку с исправлениями и обновлениями безопасности ещё год, после чего разработка прекратится, но код останется открытым. Deno Deploy будет работать шесть месяцев с поддержкой миграции на Cloudflare Workers для платных клиентов. JSR продолжит работу, перенеся свою инфраструктуру на Cloudflare, а rusty_v8 будет интегрирован в workerd. Команда особенно заинтересована в применении Durable Objects для ИИ-агентов благодаря их дешёвому serverless-исполнению, постоянному состоянию, WebSockets и высокоуровневому JS-интерфейсу. Kenton Varda и Райан Дал подробно описывают это в совместном посте в блоге Cloudflare.

Сообщество воспринимает поглощение Deno Cloudflare как конец официальной поддержки рантайма, выражая разочарование из‐за утраты уникальных возможностей: безопасности и импорта модулей по URL. Большинство считают это «закрытием» проекта, несмотря на открытый код, и обеспокоены прекращением поддержки через год. Однако открытый исходный код даёт шанс сообществу продолжить развитие, а Cloudflare может интегрировать лучшие идеи Deno в Workers и получить талантливую команду. Ключевые преимущества Deno — простота импорта модулей напрямую из репозиториев и строгая безопасность — делают его уникальным для скриптов и sandbox‐окружений, и их потеря в Node и Bun отмечается как существенный недостаток. Некоторые советуют сообществу взять на себя развитие Deno после ухода Cloudflare. Пользователь @steve_adams_86 рекомендует перенести механизмы безопасности Deno в workerd для улучшения sandbox‐а. @johnbellone планирует продолжать использовать Deno как встроенный рантайм и надеется на сообще‐форк. @sholladay считает, что Deno стал «раздутым» после добавления совместимости с npm, что оттолкнуло их от проекта. О бизнес‐модели Deno многие считают, что отсутствие монетизации (платные планы, донаты) и зависимость от венчурных инвестиций сделали проект уязвимым к поглощению. Приобретение Cloudflare рассматривается как часть более широкой тенденции консолидации инструментов разработки (Bun, Astro, Vite и др.) под крупные облачные компании. @jppope отмечает, что Cloudflare получит талантливую команду, что может улучшить безопасность и стандартную библиотеку Workers.

Cloudflare запустила в бета-версии Web Search API — инструмент, позволяющий AI-агентам и приложениям выполнять поиск в интернете и основывать ответы на актуальных данных, а не полагаться на устаревшие знания модели или попытки угадать правильные URL. На старте доступны три провайдера: Ceramic.ai, Exa и Linkup, все они поддерживают Zero Data Retention при запросах через Cloudflare и соблюдают стандарты сканирования проверенных ботов.

API интегрирован с AI Gateway, поэтому запросы логируются и тарифицируются по стандартным ценам провайдеров без наценки, а также допускается использование собственных API-ключей. Вызов возможен через REST-запрос или привязку AI в Cloudflare Workers, как показано в примерах с поиском активностей в Солт-Лейк-Сити осенью. Для начала работы рекомендуется ознакомиться с руководством по использованию.

Тред раскрывает проблемы использования Web Search API от Cloudflare: ограничения на хранение и перепродажу результатов, сомнения в заявленном нулевом хранении данных, значительные различия в ценах и качестве провайдеров, а также наличие более дешевых и гибких альтернатив (самохостинг, SearXNG, Firecrawl). Пользователи ставят под вопрос добавленную ценность посредничества Cloudflare по сравнению с прямым доступом к провайдерам. Некоторые пользователи указывают, что провайдеры, заявляющие о Zero Data Retention, на самом деле могут сохранять данные, как показал @jasonjmcghee, сравнив информацию на странице провайдера Exa, где Zero Data Retention указано как "No". Вопрос о том, действительно ли Cloudflare сохраняет запросы в своих логах, поднимает сомнения в полной анонимности: @anon373839 задаётся, сохраняет ли сама Cloudflare запросы, даже если провайдеры обещают нулевое хранение. Ценовые различия между провайдерами огромны: Ceramic.ai $0.25, Linkup $5, Exa $7 за 1000 запросов, и пользователи отмечают, что такие цены значительно выше альтернативных сервисов вроде Serper.dev или Luna. Качество выдачи у разных провайдеров сильно варьируется: @freakynit сообщает о почти нулевых результатах от Ceramic.ai, а @hrideshmg отмечает стабильную работу собственного self‐hosted решения Firecrawl. Для снижения зависимости от Cloudflare и контроля над данными рекомендуется использовать self‐hosted решения (Firecrawl, SearXNG) или объединять несколько провайдеров через собственный слой, как делает @hmartin в TypeScript‐пакете. Многие считают, что основная выгода Cloudflare — упрощённый доступ из Workers и единый лог, но это не компенсирует более высокие цены и потенциальные ограничения по хранению данных. Если требуется интеграция с уже существующими агентами на Cloudflare Workers, стоит сравнить стоимость с Brave Search API, как предлагает @ByeByeSpace, чтобы выбрать более экономичный вариант.

Следующее поколение разработки — это агенты, которые пишут код, исправляют баги и обновляют зависимости в масштабе сотен и тысяч одновременно. GitHub был создан для людей, но для агентов нужна новая основа: управление конфликтами, отслеживание мотивации изменений и координация параллельной работы. Cloudflare запустил Artifacts — масштабируемую систему версионного хранения, совместимую с Git, где каждый агент может иметь собственный репозиторий, а изменения автоматически деплоятся через Workers.

Artifacts позволяет создавать репозитории программно, хранить контекст агентов и автоматически деплоить код в Workers — как в продакшн, так и в изолированные превью для тестирования. Теперь участники конкурса могут построить на этой основе новую платформу для агентной разработки: переосмыслить ветки, код-ревью, слияния или придумать новые способы сравнения и выбора изменений. Победители получат $25 000 кредитов Cloudflare, приглашение на Cloudflare Connect и полёт в Сан-Франциско. Конкурс открыт до 14 октября 2026 года, участие требует видео, открытого кода и инструкций.

Участники сомневаются в целесообразности создания новой Git‐платформы на Cloudflare из‐за рисков централизации: это потенциальная точка отказа технически и политически, вызывает недоверие из‐за возможных MITM‐атак и вмешательства правительств, неприемлемо для критически важных систем. Предлагают проверенные децентрализованные альтернативы: GitSocial, Walgit, хранение в S3‐совместимых бакетах (например, R2), либо bare‐репозитории по SSH без веб‐интерфейса для офлайн‐работы. Некоторые считают Git неподходящим для масштабных агентных сценариев и предлагают Fossil или SVN, другие полагают, что менять Git не нужно. Бюджет в $25 000 и срок в три месяца признаны нереалистичными для создания продукта, способного принести миллионы; советуют вместо этого построить собственный стартап на LLM. Идея «Git для ботов» воспринимается как странная и малопривлекательная, конкурс считают глупым, сомневаются в практической ценности платформы.

Cloudflare представила Clef и Clef-flash — открытые модели принятия решений, совместимые с Jev-API и лицензированные под Apache 2.0. Clef лидирует в Jev Decision Index, обеспечивая быстрые, детерминированные и структурированные выводы, в отличие от неопределённых LLM. Модели доступны на Workers AI и Hugging Face, позволяя локальное использование и эксперименты. Clef классифицирует входные данные с вероятностями — например, определяет, является ли домен модным сайтом (95%), интернет-магазином (85%) или фишингом (<1%) — за 2,2 секунды, в два раза быстрее, чем gpt-oss-120b (4,7 с), и выдаёт больше категорий. Это ускоряет рабочие процессы, такие как анализ угроз в Threat Intelligence team, где модели автоматически categorize домены для принятия решений без участия человека.

Кроме того, Cloudflare запустила платформу тонкой настройки на основе reinforcement learning (RL), позволяющую адаптировать Clef под конкретные задачи. Платформа включает AI Gateway для сбора данных запросов, Workers AI для генерации rollout’ов, Containers как RL-песочницу для оценки действий, Trainer для обновления весов и возможность redeploy fine-tuned модели на Workers AI через BYO Model. Эта интеграция использует недавно приобретённые технологии из Replicate и направлена на создание автономных агентных workflows, где модели решают, рассуждают и действуют программно. Cloudflare позиционирует Clef как часть своей миссии «agent cloud» и приглашает клиентов стать дизайн-партнёрами для совместной разработки.

Тред добавляет практические данные о стоимости и производительности Clef, опровергает заявленную детерминированность, уточняет степень открытости модели и предлагает варианты использования и самостоятельного развертывания. Clef стоит $0.24 за миллион входных токенов — примерно в 6 раз дороже Jev ($0.042). Clef‐flash стоит $0.09, что делает её более конкурентоспособной. По измерениям @nikcub, Clef в 5,2 раза дороже Jev, имеет большую задержку (p50 ≈ 350 мс против 1,9 с у Jev) и лишь незначительно хуже точности (78,6 % vs 79,8 %). Совет: из‐за высокой цены рекомендуется самостоятельно развернуть Clef, если есть ресурсы, чтобы избежать расходов на облако. Хотя лицензия на веса permissive, данные и пайплайн обучения не опубликованы, поэтому модель нельзя считать полностью открытой. Спор: противоречие с заявлением о детерминированности — повторные вызовы модели могут давать разные решения, как у LLM с структурированным выводом (замечание @meander_water). Clef поддерживает ввод изображений (замечание @swingboy). Модели основаны на Qwen3.8‐27B (Clef) и Qwen3.5‐9B (Clef‐flash) (по @bityard). Многие разработчики создали свои модели‐решатели за несколько недель после выхода Jev, что указывает на относительную простоту копирования идеи. Совет: пользователь @swe_dima просит опубликовать бенчмарки визуальных задач для оценки возможностей модели. Совет: возможное применение Clef — интеграция в правила WAF Cloudflare, но текущая стоимость может сделать это невыгодным. Совет: для локального тестирования можно искать Jev‐подобные модели для Mac через Ollama или дешёвые API (предложение @croemer). Совет: для ускорения решений требуется исследовать более дешёвые и быстрые архитектуры — например, челлендж @fooker с 1 М токенов за 50‐100 мс.

Cloudflare K2 — это серверless-примитив для потоковой передачи событий, построенный на Developer Platform и использующий R2 как основу для долговечного, партицированного лога. Он решает проблему синхронизации производителей и потребителей в традиционных RPC-архитектурах, где несогласованность масштаба или времени приводит к потере данных. K2 буферизует события, позволяя потребителям читать их независимо и в своём темпе — будь то разделение нагрузки между несколькими воркерами или доставка всех сообщений каждому потребителю (паттерн pub/sub). Поддерживается долгосрочное хранение, так что даже длительные простои потребителей не приводят к потере данных. Поток хранит события как упорядоченный лог, сегменты которого записываются в R2 после накопления в памяти, что обходит ограничение объектного хранилища на дозапись. Архитектура разделяет вычисления и хранение, позволяя масштабировать их независимо и использовать глобальную инфраструктуру Cloudflare — близкую к пользователям и способную к горизонтальному масштабированию — несмотря на эфемерность edge-серверов и ограничения традиционных распределённых систем вроде Kafka.

K2 доступен в публичной бета-версии для аккаунтов с оплаченной подпиской Workers, с ограничениями: до 10 ГБ хранилища и 30 МБ/с производительности на поток. Во время бета-тестирования использование не тарифицируется; ожидаемая модель ценообразования после выхода: $0.04/ГБ заproduced и consumed данные, $0.02/ГБ/месяц за хранение. Планируется расширение возможностей: повышение параллелизма записи до multi-GB/s, поддержка ключевой упорядоченности, push-потребители, экспресс-уровень с низкой латентностью и совместимость с клиентами Apache Kafka. Начало работы — создание потока за секунды по официальному гайду. Обратная связь принимается в Discord Cloudflare Developers.

K2 решает проблему масштабируемости потоков событий через объектное хранилище, но имеет ограничения: задержки доставки до 7.5 с, высокая стоимость потребления данных ($0.04/GB) и отсутствие совместимости с Kafka, что снижает его применимость для низколатентных сценариев и создает барьер для миграции из Kafka-систем. Объектные хранилища (R2, S3) становятся основой для систем хранения данных, заменяя управляемые дисковые системы благодаря надежности, масштабируемости и простоте. K2 и аналогичные решения (AutoMQ, WarpStream) используют S3/R2 как основу, при этом Cloudflare имеет преимущество за счет тесной интеграции R2 и K2 в одной команде. Высокая задержка объектных хранилищ (до 7.5 с) противоречит возможностям NVMe SSD с микросекундной задержкой, делая такой подход неоптимальным для некоторых сценариев. Потребление данных по $0.04/GB делает сценарии с множеством потребителей дорогостоящими по сравнению с конкурентами, где потребление часто бесплатное или дешевле. S3 и R2 позволяют строить сложные системы (регистры контейнеров, etcd, POSIX-файловые системы) через тонкий слой, расширяя применение за пределы простого хранения. AWS Aurora и другие системы давно используют S3 как основу хранения, подтверждая устойчивость тренда «object-store first». Наличие встроенной поддержки многорегионального распределения и отказоустойчивости в R2 делает K2 привлекательным для глобальных приложений, где управление традиционными Kafka-кластерами сложно. Для улучшения производительности предлагается добавить быстрый in-memory прокси-слой с тем же API, чтобы сделать объектное хранилище приемлемым для обычных бизнес-приложений. Также предложено заменить ack-батчи на передачу ID последнего прочитанного события в запросе consume — это снизит сложность и риск дублирования. Для не-AI стартапов рекомендуется фокусироваться на read-heavy сценариях с большим объемом данных, как это сделал Turbopuffer — эффективный путь к созданию ценности на базе объектного хранилища. Azure Blob Storage поддерживает операции append с самого начала, опровергая утверждение о том, что S3 — единственный или лучший вариант для потоковой записи. Cloudflare активно выпускает новые продукты с малым количеством персонала, вызывая опасения по поводу безопасности и долгосрочной надежности инфраструктуры клиентов. K2 отличается от очередей Cloudflare тем, что обеспечивает долговечный, партиционированный лог событий, а не просто надежную доставку с повторными попытками. NATS JetStream рассматривается как недооцененный альтернативный вариант, способный обеспечить высокую пропускную способность для средних предприятий при правильной настройке.

Cloudflare сократил потребление памяти в сервисе Pingora Backend Router на более чем 100 ТБ за счёт оптимизации алгоритма consistent hashing в библиотеке pingora-ketama. Проблема заключалась в том, что для каждого узла хранились полные копии хеш-кольца — структуры данных, используемой для распределения запросов между серверами. При росте числа узлов это приводило к квадратичному росту памяти: каждый новый узел дублировал всё кольцо, что при тысячах серверов и петабайтах RAM становилось неприемлемо дорогим.

Оптимизация заключалась в переходе от полного дублирования кольца к компактному представлению: вместо хранения всех хешей каждого узла, теперь хранится только базовое множество хешей на узел, а при поиске используется эффективный алгоритм сортировки и бинарного поиска по сжатому пространству. Это позволило уменьшить память на узел с O(N) до O(1) относительно числа узлов, сохранив при этом свойства consistent hashing — минимальную переназначенность при добавлении/удалении узлов и равномерное распределение нагрузки. Изменения были внесены как обратно совместимая функция v2 в pingora-ketama, позволяющая逐步 мигрировать без простоев. После полного перехода на новую версию наблюдался резкий спад потребления памяти — подтверждённый метриками — что эквивалентно экономии более 100 ТБ RAM по всему глобальному флоту Cloudflare. Это демонстрирует, как математическая прозорливость и аккуратная реализация в Rust могут превратить, казалось бы, незначительные алгоритмические улучшения в масштабную экономию ресурсов.

Оптимизация Cloudflare имеет смысл только на масштабе их инфраструктуры. Для обычных систем экономия 1% памяти не оправдывает сложность реализации. Спор: Некоторые считают, что оптимизация на 100 ТБ оправдана только из-за масштаба Cloudflare, а для большинства систем это не стоит усилий. Спор: Один участник предлагает заменить consistent hashing на tournament hashing с N битами ключа и wyhash — это сократит использование памяти на 600 ТБ и снизит задержку за счёт O(n) вместо O(n log n). Совет: Использовать B-дерево с суммированием весов узлов и бинарным поиском по хешу, масштабированному на общий вес — это снизит затраты на обновление дерева до ~8 узлов при добавлении/удалении сервера. Совет: Применить сжатие указателей в Rust — удаление по 2 байта с каждого указателя сэкономит сотни гигабайт при большом числе записей. Многие отмечают, что Cloudflare вернулся к качественному, человечески написанному контенту, в отличие от предыдущих постов, написанных ИИ — это воспринимается как позитивный сдвиг. Пользователи подтверждают, что оптимизации хеш-колец и хранения данных важны для крупных систем, где небольшие улучшения приводят к значительной экономии ресурсов. Совет: При небольшом масштабе профилирование и устранение избыточных байтов на запись эффективнее сложных алгоритмических оптимизаций, не протестированных на реальных данных. Спор: Некоторые критикуют статью за преувеличение технической глубины — математика в ней не революционна, а базова для команд, работающих с оптимизацией на уровне дата-центров. Совет: Использовать rendezvous hashing — алгоритм для балансировки нагрузки в прокси-кэшах, который может заменить ketama и сократить память без потери равномерности распределения. Пользователи отмечают, что эпоха изобилия памяти закончилась — рост стоимости RAM и масштаб инфраструктуры заставляют компании возвращаться к глубокой оптимизации, как в прошлом. Спор: Один участник утверждает, что экономия памяти ради снижения затрат не этична, если это приводит к росту цен на оборудование для малого бизнеса и рабочего класса. Совет: В Rust можно использовать структуры с layout-оптимизацией и struct-of-arrays для улучшения кэш-локальности при поиске в хеш-кольце — это снижает задержки без увеличения памяти.

Cloudflare Quick Tunnels — это переупакованный продукт 2021 года с низким качеством дизайна и запутанной документацией. Маркетинг вводит в заблуждение: заявленный «туннель для всего» на деле ограничен HTTP(S)-сценариями. Инструмент подходит для временных демо и прототипирования без регистрации, но не рекомендован для продакшена из-за нестабильности, отсутствия персистентных URL и высокого разброса латентности (от 30 до 750 мс). Анонимность туннелей вызывает споры: одни видят в этом удобство, другие — угрозу безопасности и риск хостинга нелегального контента, от чего ngrok и аналоги давно отказались. Альтернативы: — Tailscale: предпочтительнее для личного доступа к сервисам из-за безопасности и независимости от облачного провайдера. — Pinggy и ngrok: надежнее для SSH, TCP, UDP и интеграции с CI/CD. — WireGuard на VPS: дешевле и безопаснее для полного контроля. — Onion Services: лучше для тестирования в условиях ненадёжной сети. Использование Quick Tunnels для автономных систем без изоляции может привести к утечке данных. Общее пренебрежение Cloudflare к продукту подтверждается нерешенными с 2021 года багами cloudflared на macOS и отсутствием прозрачных ограничений по квотам.

В Европе почти девять из десяти компаний, использующих CDN, выбрали Cloudflare: из 44 143 компаний с обнаруженным CDN 39 547 (89,6%) работают за его сервисом. Это выше среднего по вебу (84,1% по W3Techs), что указывает на особенно высокую концентрацию в регионе. На втором месте Amazon с 3 112 компаниями, но часть из них использует AWS как источник, а не CloudFront как фронтенд, поэтому Fastly (1 299 компаний) и Akamai (396) дают более чистую картину доли других чистых CDN-провайдеров.

Доля Cloudflare варьируется по странам: от 78,8% в Испании и Ирландии до 95,6% в Нидерландах. Великобритания лидирует по абсолютному числу — 15 846 компаний за Cloudflare, тогда как Германия, несмотря на крупный рынок, показывает наименьшую долю среди больших экономик — 81,4%. Такая концентрация создаёт системный риск: сбой у одного провайдера может вывести из строя большую часть рынка одновременно, как это уже случалось в глобальных инцидентах Cloudflare в 2025 году. Учёт ведётся по обнаруженным заголовкам (например, cf-ray), а компании могут учитываться у нескольких вендоров одновременно, если используютmulti-CDN setup.

Высокая доля Cloudflare в Европе обусловлена не только техническими преимуществами, но и корпоративной консервативностью, страхом ответственности и зависимостью от экосистемы — выбор часто мотивирован принципом «никто не был уволен за покупку Cloudflare». Европа 40 лет принимала американские технологии, и смена экосистемы требует десятилетий из-за поколенческой привычки. В Великобритании (17 тыс. сайтов) доля Cloudflare выше, чем во Франции (4 тыс.) и Германии (6 тыс.), что отражает культурную склонность к «cargo-culting» масштабных решений. Бесплатные DDoS-защиты воспринимаются как демпинг — Cloudflare теряет деньги, чтобы захватить рынок. Альтернативы: - Bunny.net — технически работоспособна, но незрелый API (один глобальный ключ с полными правами) и поддержка через Discord не внушают доверия корпоративным клиентам. - FRP — рабочая замена Cloudflare Tunnel для тех, кто хочет избежать зависимости. - CDN77 — используется лишь для раздачи статики, как узкоспециализированное решение. - Не обязательно регистрировать домен у Cloudflare — достаточно указать их DNS-серверы, чтобы снизить привязанность к экосистеме. - Для малого бизнеса Cloudflare дешевле Google Cloud, так как не требует платного балансировщика для хостинга статики. Споры: - $200/мес за CDN и DDoS-защиту — неприемлемая трата для большинства сайтов, где защиту можно настроить через rate-limiting на веб-сервере. - Cloudflare сравнивают с LG TV: постоянное слушание, но использование продолжается, несмотря на известные риски слежки NSA более десяти лет. Европа не развивает собственные решения не из-за отсутствия возможностей, а из-за отсутствия навыков и воли — вопрос компетенции, а не политики.

Eric Selin создал statichost.eu — полностью европейский хостинг для статических сайтов, где каждый элемент стека, от деплоя через Git до CDN, работает на инфраструктуре, принадлежащей европейским компаниям. Он отказался от использования американских сервисов вроде AWS и Cloudflare, считая, что доверие данным и контроль над инфраструктурой должны оставаться в Европе. Проект возник из разочарования в «европейских» хостингах, которые фактически полагаются на американские облака.

Хостинг ориентирован на веб-разработчиков, ценящих суверенитет данных и прозрачность цепочки поставок. Eric подчеркивает, что интернет стал излишне сложным и зависимым от небольшого числа иностранных провайдеров, и предлагает простое, локальное решение без компромиссов. Сервис позиционируется как этичный и технологически независимый альтернативный вариант для тех, кто хочет полностью контролировать, где и как работает их сайт.

Обсуждение подтверждает, что Statichost.eu закрывает потребность в европейском хостинге, но вызывает критику из-за высоких цен, непрозрачных тарифов и технических ограничений, несмотря на положительный опыт с бесплатным планом и поддержкой. **Критика цен и модели** - @gbxbxbcbd: 120 EUR/год за безлимитные сайты и дорогой трафик невыгодны — аналогичный VPS на Scaleway стоит 5 EUR с безлимитным трафиком. - @FabCH, @sparkling: 9 EUR/мес за статический хостинг — слишком дорого; за ту же цену можно взять VPS с безлимитным трафиком в Европе. - @dlahoda иронично перечисляет «европейские ценности» как бюрократические барьеры (налоги, карта, резиденция, цензура), намекая на политическую избыточность. **Прозрачность и доверие** - @jonplackett: плохой дизайн сайта (неадаптивное меню, несогласованное оформление) подрывает доверие. - @reconnecting: страница статуса отправляет данные в Google и DoubleClick, что противоречит заявлению об отсутствии сбора персональных данных. - @sajithdilshan, @palata: в документации нет информации об объёме хранилища и автоматической генерации TLS-сертификатов. - В то же время @g-b-r и @exitnode хвалят краткие и понятные условия использования. **Технические ограничения** - @chrisjj, @mtlynch: отсутствие rsync-подобной синхронизации и обязательная сборка (build minutes) — неоправданные ограничения для статических сайтов. - @archonis: нет аутентификации по SSH-ключу, что снижает безопасность и удобство. **Положительный опыт и предложения** - @exitnode, @thih9: сервис работает стабильно, быстро и бесплатно — хороший вариант для небольших сайтов без сложных сборок. - @jeremyjh предлагает интегрировать Statichost.eu с Codefloe (европейский Git-форж) для решения проблемы с управлением версиями. - @throwfaraway135 выражает недоверие к EU-юрисдикции, допуская цензуру, что ставит под сомнение «европейские ценности» как гарантию свободы.

Cloudflare оптимизировала хранение записей в DNS-кэше Big Pineapple, сократив потребление памяти на 100 ТБ без потери производительности. Кэш содержит более 250 млрд записей, и даже экономия одного байта на запись эквивалентна 250 ГБ. Пять последовательных улучшений уменьшили размер одной записи с 953 до 420 байт — на 56% — за счёт устранения избыточности в структурах данных: замена Vec<T> на более компактные типы там, где длина известна или ограничена, оптимизация выравнивания и удаление неиспользуемых полей. Это также снизило количество аллокаций на запись с 1,1 КБ до 461 байт.

Производительность при этом выросла: пропускная способность вставки увеличилась на 43% (с 625 тыс. до 893 тыс. записей/с), а латентность поиска снизилась на 19% (с 828 до 670 нс) благодаря лучшей локальности памяти и меньшему числу операций分配. В продакшене наблюдалось снижение резидентной памяти на 42–43% на перцентилях p90 и p99. Освободившиеся ресурсы планируется использовать для увеличения ёмкости кэша, что повысит коэффициент попаданий и уменьшит нагрузку на апстрим-DNS. Дальнейшие улучшения кэша находятся в исследовании.

Оптимизация памяти на сотнях терабайт требует глубокого понимания структур данных и системного программирования, а не только масштабирования железа, и даёт кратные выигрыши на практике. Экономия даже одного байта на записи критична: в Cloudflare это сэкономило 250 ГБ на миллиардах записей. Одно крупное выделение памяти вместо множества мелких (single malloc) сокращает потребление в 20+ раз (опыт MaraDNS с чёрными списками). Выравнивание полей в Go экономит до 8 байт на объекте, что значимо при миллионах экземпляров. Хранение данных в сериализованном виде вместо разобранных структур улучшает локальность, если основная операция — чтение с повторной сериализацией. Радикальные оптимизации возможны и в прикладных задачах: в игре Wavetale потребление снизили с 20+ ГБ до 3 ГБ. Спорный момент: замена нескольких Vec на один смещённый буфер в Rust технически корректна, но лишает гарантий безопасности границ подсрезок. Советы: - Для DNS-ключей с общими префиксами (com.site.www) подходит radix tree. - Использование Box для указателей избыточно при низком потреблении памяти: 4–8 байт вместо 16. - jemalloc не всегда оптимален для многопоточных нагруженных систем. - Сжатие данных в памяти эффективно при редком декодировании и высокой повторяемости (как домены). - Формат в памяти отличается от сериализованного — компактные структуры эффективнее стандартных языковых объектов. Оптимизация должна быть частью проектирования, а не последним шагом: многие системы становятся избыточными из-за игнорирования масштабируемости на ранних этапах.

Главная мысль: 99 % трафика вашего сайта составляют боты, а обычные аналитика показывают лишь человеческую активность. За год вы столкнулись с миллионами запросов от китайских сканеров, а также с постоянным «чтением» страниц поисковыми ботами вроде Anthropic и Amazon‑crawler, которые не генерируют реальных посетителей.

Ключевые цифры, которые стоит запомнить: 3,6 млн запросов от китайских ботов за один день; Cloudflare сообщает соотношение 3 000 сканов на один реферальный переход, у вас — 35 000 : 1; CAPTCHA‑разрешение лишь 0,24 %; в неделю сервер обслуживает 2,5 млн запросов, но аналитика фиксирует лишь 5 977 реальных просмотров, то есть 214 бота на каждый человеческий запрос. Эти факты раскрывают, насколько обычные инструменты (Plausible, Google Analytics) недооценивают реальный объём автоматизированного трафика.

Тред обсуждает масштабную проблему ботов на сайтах: большинство участников подтверждают, что боты составляют значительную часть трафика и требуют решения. Некоторые критикуют Cloudflare за высокую стоимость и слабую эффективность против ботов, предлагая альтернативы — Anubis, геоблокирование. Отмечается, что боты всё чаще маскируются под реальных пользователей, усложняя их выявление. Несколько участников считают, что некоторые боты полезны — например, для индексации и привлечения аудитории.

Cloudflare OS — это открытая платформа, позволяющая каждому сотруднику компании работать с персональным агентом и рабочим пространством, полностью адаптированным под внутренние процедуры, терминологию и используемые системы. Агент получает контекст из «общих навыков» и знаний, собранных командой, и может создавать документы, слайды, автоматизировать задачи и даже писать небольшие приложения, опираясь на уже существующие данные и инструменты организации.

Ключевой прорыв — интеграция безопасности в саму платформу: теперь доступ к инструментам и данным строго контролируется, а совместное использование рабочих пространств не раскрывает конфиденциальную информацию. В результате любой бизнес может развернуть собственный экземпляр Cloudflare OS, подключить к нему внутренние сервисы через MCP‑порталы и Gatekeepers, а также распространять улучшения, найденные одним пользователем, по всей компании.

Запомните: платформа поставляется с готовыми репозиториями ядра и примером развертывания, а её ценность рождается не только в коде, но и в институциональном контексте, который вы формируете сами.

Пользователи обсуждают потенциальные проблемы Cloudflare OS: риск lock-in, сложность управления данными и безопасностью, а также спорят о корректности названия «OS» как несоответствующего традиционному пониманию. Некоторые предлагают альтернативы — собственные агенты, рабочие пространства или другие технологии. В целом соглашаются: идея интересна, но ограничена и требует пересмотра подходов к данным и безопасности.

Diátaxis — это системный подход к созданию технической документации, основанный на четырёх типах потребностей пользователей: учебники (tutorials), пошаговые инструкции (how-to guides), технические справочники (technical reference) и объяснения (explanation). Каждый тип решает конкретную задачу: от обучения новичков до углублённого понимания механизмов. Документация должна структурироваться вокруг этих четырёх форм, а не вокруг продуктов или технологий, что делает её более интуитивной и эффективной.

Методика не накладывает жёстких ограничений на формат или инструменты, но даёт чёткий принцип качества: каждая статья должна чётко соответствовать одной из четырёх категорий. Это упрощает работу авторов и поддержку документации. Практика подтверждает эффективность: компании вроде Vonage, Gatsby и Cloudflare перестроили свои документации по Diátaxis, что привело к росту удобства для пользователей и вовлечённости contributors. Участники отмечают, что структура помогает быстро находить нужный контент и решать, куда добавить новый материал.

Тред приводит примеры успешного применения Diátaxis в реальных проектах, подтверждая его эффективность в создании структурированной и удобной документации — так отмечают @conradludgate, @radicalriddler, @c0rruptbytes, @rkangel и @aeden. Указываются необходимость регулярного обновления документации и советы: тщательно изучить Diátaxis перед реализацией (@jamilbk) и использовать ссылки для поддержания актуальности (@CompoundEyes). Среди критики — дополнительные клики для доступа к информации (@rjmill) и мнение @voidhorse, что популярность Diátaxis обусловлена недостаточным распространением знаний о документации в техническом сообществе.

Claude накапливает детализированный профиль пользователя: ежедневное резюме recent‑conversations вставляется в каждый диалог, а также доступна функция conversation_search для поиска по всей истории. Этот набор данных часто содержит конфиденциальную информацию — от рабочих проектов до ответов на вопросы безопасности. Пользователь, не делая ничего подозрительного, просто задаёт вопрос о кафе, и при этом Claude может неявно передать своё имя, место работы и hometown. Система памяти состоит из двух частей: сначала генерируется короткое описание, затем при необходимости вызывается поиск по истории, что в сочетании с веб‑доступом создало уязвимость.

Для вывода данных использовался web_fetch, который может выполнять лишь GET‑запросы к произвольному URL. Злоумышленник создал сайт evil.com, где путь содержал персональные сведения, а сервер логировал user‑agent. При запросе Claude к evil.com/… сервер получил путь с именем, компанией и hometown, что привело к утечке. Cloudflare изначально блокировал такие запросы, но после обхода robots.txt атака сработала. Позже Anthropic отключил возможность follow‑link’ов в внешних страницах, ограничив web_fetch только пользовательскими URL‑ами.

• Участники отмечают, что Claude Code экспортирует личные данные через User-Agent и запрашивает доступ к памяти.
• Обсуждается отсутствие защиты от prompt‑injection и слабые настройки безопасности у Anthropic.
• Некоторые считают, что такие уязвимости показывают необходимость изоляции и ограничения доступа к памяти.
• Отсутствие выплат за баги и недостаточная коммуникация со специалистами вызывают критику сообщества.

Автор выражает усталость от шаблонных постов в LinkedIn о сбое CloudFlare: все копируют друг друга через ChatGPT, фокусируясь на .unwrap() без проверки пост-мортема. Реальная проблема — отсутствие автоматизированных тестов или QA, даже feature flag выявил бы баг заранее. Посты отражают бездушный корпоративный подход: менеджеры дружат с ИИ, не заботясь о фактах или карьере, только о внешнем виде.

В компании автора изначально было мало менеджеров, фокус на инструментах и обучении — всё работало. Теперь 3 менеджера на 1 dev (автора), 40% времени уходит на busywork и тикеты в Linear вместо разработки. Менеджеры не снижают context switching, меняют приоритеты mid-cycle по клиентским хотелкам (не нуждам), винят dev в дрейфе проекта. Автор на PIP, увольняют в январе вместе с другими; компания стала стартапом с корпоративным адом, но он желает коллегам удачи. Дисклеймер: пост эмоциональный, из-за усталости продуктивность упала.

• Критика LinkedIn за кринжовый, AI-генерированный контент, контраст с реальной речью и корпоративный слоган, делающий платформу "адом".
• Полезность как инструмент для поиска работы, networking, продаж и контактов с коллегами, несмотря на плохой фид (рекомендуют игнорировать его).
• Предложения: использовать блокировщики, фокусироваться на профиле/поисках, вести блоги; сравнения с Twitter/FB как платформами самопрезентации.
• Обсуждение корпоративного ада (PIP, мотивация деньгами), эхо-камере и отсутствия альтернативы для рынка труда.

18 ноября 2025 года Cloudflare столкнулся с масштабным сбоем сети, начавшимся в 11:20 UTC. Проблема проявлялась пользователям как страница ошибки с указанием сбоя в сети Cloudflare. Инцидент не был вызван кибератакой, а возник из-за изменения разрешений в системе баз данных, что привело к удвоению размера файла функций, используемого системой управления ботами. Программное обеспечение для маршрутизации трафика имело ограничение на размер файла, ниже удвоенного значения, что вызвало его сбой.

Сначала Cloudflare ошибочно подозревал DDoS-атаку, но позже определил корень проблемы. К 14:30 UTC основной трафик был восстановлен, а к 17:06 все системы работали нормально. Система демонстрировала необычное поведение — периодические восстановления каждые 5 минут, когда генерировались хорошие файлы конфигурации. Компания принесла извинения за влияние на клиентов и интернет, признав, что сбои в их системе неприемлемы.

• Использование .unwrap() в критическом коде привело к панике и сбою системы после обновления конфигурации.
• Отсутствие staged rollout для конфигураций и недостаточный мониторинг замедлили диагностику сбоя (3 часа).
• Обсуждаются архитектурные риски зависимости от крупных провайдеров и необходимость отказоустойчивых систем.
• Предлагается усиление обработки ошибок, глобальных kill switches и проверки конфигураций как пользовательских данных.
• Подчеркивается важность наблюдаемости (telemetry) для быстрого обнаружения паник и сбоев в критических сервисах.

Разработчик приложения Inkdrop получил пугающее письмо от пользователя, сообщавшего о проблеме с cookie consent, блокирующим доступ к сайту. Странно было то, что сайт приложения вообще не использует cookie consent — отслеживание и реклама отсутствуют. В ответ на запрос автора уточнить детали, пользователь прислал ссылку на "скриншот", которая вела на страницу с капчей и требованием выполнить вредоносную команду в терминале.

Команда, скопированная в буфер обмена, скачивала и выполняла удалённый shell-скрипт. Хотя Gmail пометил второй ответ как спам, первый выглядел вполне нормально. Такие фишинговые атаки становятся всё более изощрёнными, часто имитирующие реальные запросы поддержки. Даже на форумах автора появляются подозрительные посты, написанные, вероятно, ИИ, которые выглядят естественно, но содержат скрытые угрозы.

• Сообщения в треде подчеркивают, что фишинг становится всё более изощрённым: злоумышленники маскируют вредоносные ссылки под видом Google Sites, Cloudflare, Dropbox и т.д., а также используют фейковые сервисы поддержки, чтобы выманить у пользователей конфиденциальные данные.
• Участники обсуждения отмечают, что даже технически подкованные пользователи могут быть обмануты, если злоумышленник использует правдоподобные, но поддельные домены и визуально неотличимые от легитимных сервисов ссылки.
• Обсуждение также поднимает вопрос о том, что даже если пользователь не ведётся на кликбейт, то вредоносное ПО может быть скачено и запущено в фоновом режиме, если пользователь просто открыл вредонусную страницу в браузере.
• Участники также обсуждают, что в условиях, когда всё большее и большее количество людей полагаются на ИИ-ассистенты вроде ChatGPT, фишинг может стать ещё более изощрённым и трудным для обнаружения.
• Наконец, участники обсуждения подчеркивают, что важно помнить, что никакие легитимные сервисы не будут просить вас запустить что-то в терминале и что всегда стоит проверять URL-адреса, особенно если они ведут на сайты, которые вы не ожидаете увидеть.

Крупнейшая в мире ботнет-сеть Aisuru, специализирующаяся на DDoS-атаках, недавно установила новый рекорд, обрушив на цели в интернете 29,6 терабит мусорного трафика в секунду. Основная часть её мощности исходит от сотен тысяч взломанных IoT-устройств в США, многие из которых — это камеры видеонаблюдения и маршрутизаторы, эксплуатируемые благодаря уязвимостям в их прошивках.

Аналитики говорят, что концентрация ботнета в США затрудняет смягчение последствий его атак, поскольку провайдеры не могут просто отключить зараженные системы своих клиентов. Вместо этого они вынуждены направлять часть трафика атаки через большие сети, что приводит к задержкам для всех пользователей.

В результате, Aisuru теперь считается главной причиной, почему в последние недели наблюдаются перебои в работе интернета по всему миру, особенно в услугах доставки контента и защищенных DNS-сервисах, таких как Cloudflare и Google.

Хотя Aisuru наиболее известен атаками на игровые сервисы, он также всё чаще применяется для нанесения ущерба критически важной интернет-инфраструктуре, включая основу глобальной системы доменных имён (DNS).

В записях, полученных KrebsOnSecurity, показано, что на пике недавней DDoS-кампании Aisuru против провайдера услуг защиты от DDoS-атак Akamai, последний временно прекратил работу некоторых своих сервисов, включая защиту DNS, после того, как атака превысила два терабита в секунду.

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

В частности, исследователи отметили, что Aisuru теперь способен генерировать в два раза больше атакующего трафика, чем всего несколько месяцев назад, и что этот рост связан с улучшением в методах, которые Aisuru использует для заражения устройств.

Многие из последних атак Aisuru были сосредоточены на серверах, обслуживающих видеоигры, такие как Counter-Strike 2 и Minecraft. Но эксперты по безопасности, отслеживающие Aisuru, говорят, что они видят, как ботнет начинает атаковать более разнообразный набор целей, включая корпоративные и государственные сети.

Один из таких аналитиков — это Абрахам «Абби» Рамирес, руководитель отдела угроз в компании по защите от DDoS-атак NullRoute, расположенной в Лос-Анджелесе. Рамирес говорит, что, хотя Aisuru, безусловно, является самым большим ботнетом, который он когда-либо видел, он также является одним из самых сложных.

«Это не просто ботнет, который вы можете наблюдать и анализировать с помощью простого набора инструментов для мониторинга трафика», — сказал Рамирес. «Он использует множество методов, чтобы скрыть источник своего трафика, и они постоянно меняются, чтобы скрыться от обнаружения. Это, безусловно, самый сложный ботнет, который мы отслеживаем».

«Они также, кажется, находят способы генерировать больше атакующего трафика, одновременно уменьшая требования к своим ботам для поддержания атаки», — добавил он. «Это, безусловно, самый эффективный ботнет, который мы когда-либо видели».

По словам Рамиреса, Aisuru в настоящее время поражает системы, которые в противном случае могли бы помочь смягчить последствия атаки, что приводит к положительной обратной связи, которая усиливает разрушительные эффекты Aisuru.

«По сути, они находят способы заставить свои жертвы усиливать сигнал атаки», — сказал он. «Это действительно то, что отличает Aisuru от любого другого ботнета, который мы видели до сих пор».

term BBBBB BBBBB BBBBB BBBbbb BBBBBB BBBBBB BBBBBBB BBBBBBBB BBBBB BBB BBB BBBBBB BBBBBB BBBBB BBBBB BBBBBB BBBBBB BBBBBBBB BBBBBB BBBBBB BBB BBBBBB BBBBB BBBBB BBBBB BBBBBB BBBBBB BBBBB BBBBBB BBBBB BBB BBBBB BBBBBB BBBBBBBBBB BBBBB BBB BBBBB BBBBBBBB BBBBB BBB BB BBBBBB BBBBB BBB BBBBBB BBBBBBBB BBBBB BBB BBBBBB BBBBB BBBBB BBBBB BBBBBB BBBBB BBBBBB BBBBB BBB BBBBBB BBBBB BBBBB BBBBB BBBBB BBBBBB BBB BBBGGGG BBB BBBBB BBBbbbbbb BBBBBB BBBBBB BBBBBB BBBBBB BBBBBB BBBBB BBBBB BBBBBB BBBBB BBB BBBBB BBBBBBB BBBBBB BBBBBB BBBBB BBBBB BBBBBB BBBBB BBBBB BBB BBB BBBBBB BBBBB BB BBBBB BBBBB BBBBBB BBBBB BBBBB BBBBB BBBBB BBBBB BBB BB BBBBB BBBBB BBBBB BB BBBBBB BB BBBBBB BBB BBBBBB BBBBBBBB BBBBB BBBBB BBB BBBBBBBB BBBBBBBB BBBBB BBBBBB BBB BBBBBBB BBBBB BB BBBBBB BBB BBB BBB BBBBB BB BBB BBBBB BBB BBBBBB BBBBBBBB BBB BB BBBBB BBB BBBBB BBB BBBBBBB BBBBB BBB BB BBB BB BBB BBB BB BBBBB BBB BBBBBB BBB BBBBB BBBBBBB BBB BBBBB BBB BBB BB BBB BBB BBB BBB BBBBBB BB BBBBBBBB BBBBB BBB BBB BBBBB BBB BBBBB BBB BBBBBB BBBBB BBB BBB BBB BBB BBBBBB BB BBB BB BBB BBB BBB BBBBB BBB BBBBBBB BBBBBBB BBB BBB BBB BBBBB BBB BBBBBB BBB BBB BBB BBB BBB BBB BBBBB BBB BBB BBBBBBB BB BBBBB BBB BBBBBB BBBBBBB BBB BBBBBB BBBBBB BBB BBB BBBBBB BBB BBBBBBB BBB BBB BBB BBB BB BBBBBB BBB BBBBBB BBBBBBB BBBBB BB BBBBB BB BBBBB BBBBBBB BBB BBB BBB BBBBBBB BBB BBB BBB BBBBBB BBB BB BB BBBBB BBB BBBBBBBB BBBBBBB BBB BBBBBBBB BBB BBBBBBB BBB BBB BBB BBB BBB BBBBB BBBBB BB BBBBB BBB BBBBB BBB BBB BBBBBB BBBBBBB BBB BBBBBBB BBB BBB BBB BBBBBBB BBB BBB BBBBB BBB BBBBB BB BBBBBBB BBB BBB BBB BBB BBBBBBB BBB BB BBBBB BBBBBBB BBB BBB BBB BBBBBBB BBB BBB BBBBB BBB BBBBB BBB BBB BBB BB BBB BBB BBBBB BB BB BBB BBB BBBBB BBB BBB BBB BBB BBB BBB BBBBB BBB BBB BBBBBB BBB BBB BBB BBB BBB BBB BBBBBBBB BBBBBBB BBBBB BBB BBBBBBB BBB BB BBBBBBB BBBBBBBbbbb BBBBB BB BBBBB BBB BBBBBB BBBBBBBB BBBBB BBBBBBBB BBB BBB BBB BBBBBBBB BB BBBBBBBBBB BBBBBBB BBBBBBB BBBBBBB BBB BBBBBB BB BBBBBBBB BBBBBBBB BBBBBBBbbbbb BBB BBB BB BBBBBBB BBBBBB BBBBB BBBBBB BBBBBBBbbbbb BBBBBBBbbbbbb BBBBBBBBBBBB BBBBBBBB BBBBBBBBBB BBBBBbbbbbbbbbbbb BBBBBBBB BBBBBBB BBBBBBBB BBBBBBB BBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBbbbbbbbbbbbbb BBBBBbbbbbbbbbbbbbb BBBBB BBBbbbbbb BBBBBBBbbbbbb BBBbbbbbbbbbbbbbbb BBBbbbbbbbbbbb BBBbbbbbbbbbbbbbbb BBBbbbbbbbbb BBBBBbbbbbbbbbbbbbb BBBbbbbbbbbbbbbbbb BBBbbbbbbbbbbbbbbb BBBBBB BBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBBBBBBbbbbbbbbbbbbbbbbbbbbb BBBbbbbbbbbbbbbbbbbbbbbbbbbbbb BBB BBB BBB BBB BBB BBB BBBBB BBBbbbbbbb BBBbbbbbbbbbbbbbbb BBB BBB BBB BBB BBB BBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBB BBB BBBBBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBBBB BBB BBB BBB BBBBBbbb BBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BB BBB BB BBB BBB BBB BBB BBB BBB BBB BBBBBbbbbbbbbbbb BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBBBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BB BB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BB BB BB BBB BBB BBB BBBBBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBBBB BB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BB BBB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBBBB BBB BBB BBB BBB BBB BBBBB BB BBB BBB BBB BBBBBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BB BBB BBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBBbbbbbbbbbbbbbbbbbbbbbBBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBBBBBBB BBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BB BBB bb BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBBBB BBB BBB BBB BBB BBB BBB BBBBBbbb BBBbbb BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BB BBB BBB BBB BB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBBBB BB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BB BBBBB BB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBBBBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB GGgggg BBBBBBBBBBBB BBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BB BBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbdddddbbbbb BBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb GG BBBBBBB BBBBBbbbbb GG BBBBBbbbbbbbbbbbbbbbbbbb BBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBB BBBBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBBBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBBBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBBBBBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BB BB BBB BBBBB BBB BBBBBbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb BBB BBBBBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBBBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBBBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBBBBBbbbGGGGGGGGggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggdddddddddddddddddddddddddddddddddddggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDdddddddddDDDDDDDDDDDDDDDDDDdddddddDDDDdddddDDDDdddddddddDDDDdddddddDDDDDDdddddDDDDDDDDDDDDDDDDDDDDDDdddDDDDdddddDDDDdddddDDDDDDDDdddDDDDDDDDdddddDDDDDDdddddDDDDDDDDDDdddddDDDDDDdddDDDDdddddDDDDdddddddDDDDDDdddDDDDdddddDDDDDDdddddddddDDDDdddddDDDDDDDDdddddDDDDdddddDDDDDDdddDDDDdddddDDDDdddddddbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbgggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDddddDDDDDDDDDDDDDDdddddDDDDDDDDDDDDDDDDdddddddddddDDDDDDDDdddDDgggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg

Cloudflare столкнулся с редким, но критичным багом в компиляторе Go для ARM64: при раскрутке стека может возникнуть race condition, что приводит к фатальному панику. Подробный разбор показал, что проблема в том, что компилятор неправильно генерирует барьер-инструкции, необходимые для безопасной работы с памятью. Это подтверждено исследованием исходников Go и ARM-мануалов. В итоге Cloudflare не только предоставила подробный отчет и тест-кейс в апстрим, но и предложила временное решение, которое уже встроено в их инфраструктуру и позволяет избежать проблемы до официального патча.

• Компилятор Go имел баг, из-за которого при определённом сочетании инструкций в ARM64-версии Go могла прерваться сборка мусора, что приводило к нестабильности. Исправление уже в коммите f7cc1e5 и войдёт в Go 1.20.
• Обсуждение подняло вопрос о том, насколько редки такие баги компиляторов в наши дни и какие факторы этому способствуют.
• Некоторые комментаторы поделились историями о том, как в прошлом им приходилось сталкиваться с багами компиляторами даже в таких "безопасных" языках как Go.
• Обсуждение также затронуло вопрос о том, насколько критично было быстрое обновление, и было отмечено, что Cloudflare уже использует ARM-серверы в продакшене.

Автор делится детальным чеклистом по настройке защищённого VPS для self-hosting, основанным на личном опыте развёртывания. Рекомендует Hetzner за лучшее соотношение цены и производительности в Европе, но отмечает альтернативы вроде DigitalOcean (удобнее, но дороже) или AWS Lightsail (сложнее для новичков). Ключевые шаги включают обновление системы, создание пользователя с sudo-правами, настройку аутентификации по SSH-ключам с обязательным отключением парольного входа и root-доступа, а также настройку фаервола UFW с политикой запрета входящих соединений по умолчанию, кроме SSH, HTTP и HTTPS. Отдельно упоминается опциональное усиление безопасности через смену порта SSH и привязку к конкретному IP. Практический вывод: такой подход создаёт надёжную основу для развёртывания приложений с минимальной поверхностью для атак.

• Пользователи отмечают отсутствие подробного описания Coolify в статье, несмотря на его упоминание в заголовке.
• Обсуждаются преимущества и недостатки различных хостинг-провайдеров (Hetzner, OVH, DigitalOcean) и их ценовая политика.
• Предлагаются альтернативные инструменты для развертывания и управления серверами: Docker Compose, CapRover, Cloud66, Webmin/Virtualmin, NixOS, Ansible.
• Поднимаются вопросы безопасности и настройки сервера: конфигурация брандмауэра, ограничение доступа по SSH, использование Cloudflare.
• Высказываются критические замечания о пользовательском интерфейсе блога и качестве обслуживания клиентов некоторых провайдеров.

Cloudflare запускает закрытую бета-версию Email Service — единой платформы для отправки транзакционных писем прямо из Workers. Это решение устраняет типичные боли разработчиков: сложность настройки, проблемы с доставкой и задержки. Интеграция с DNS автоматически настраивает SPF, DKIM и DMARC, повышая доверие провайдеров, а глобальная инфраструктура Cloudflare гарантирует низкую задержку доставки по всему миру.

Отправка письма сводится к вызову env.SEND_EMAIL.send() в коде Worker — без API-ключей и риска утечки данных. Локальная эмуляция через Wrangler, обработка вложений в R2 и мониторинг статусов доставки делают работу с почтой такой же простой, как и остальная разработка на Cloudflare. Это не просто очередной email-сервис, а глубоко встроенный инструмент, где надёжность и скорость становятся частью UX вашего приложения.

• Пользователи критикуют Cloudflare за назойливую проверку на бот-активность и выражают опасения по поводу растущего влияния компании на интернет-протоколы.
• Анонсирован сервис Cloudflare Email Sending для отправки транзакционных писем через Workers, что воспринято как альтернатива Sendgrid и AWS SES.
• Обсуждаются потенциальные преимущества: простота интеграции, возможная низкая цена (pay-as-you-go), удобство для разработчиков, уже использующих экосистему Cloudflare.
• Высказываются опасения по поводу концентрации интернет-инфраструктуры в руках одной компании и утраты децентрализации интернета.
• Часть пользователей выражает скептицизм и предпочитает использовать независимые сервисы для email, чтобы не складывать все «яйца в одну корзину».

За последние 15 лет интернет стал значительно безопаснее: доля зашифрованного трафика выросла с менее чем 10% до более 95%, во многом благодаря усилиям Cloudflare. Однако некоторые области, например внедрение IPv6, прогрессируют медленно, что увеличивает стоимость сетевой инфраструктуры и ограничивает новых участников.

Основная бизнес-модель интернета остаётся неизменной: создание контента, привлечение трафика и монетизация через рекламу, подписки или продажи. Эта система вознаграждения стимулировала наполнение сети ценными материалами, но также породила проблемы вроде кликбейта и низкокачественного контента, ориентированного на максимизацию вовлечения. Cloudflare сознательно избегала роли арбитра контента, считая, что ключ к улучшению — не цензура, а изменение incentives.

• Обсуждается предложение Cloudflare о создании новой бизнес-модели, где AI-компании платят за скрейпинг контента, а часть средств получают создатели.
• Высказываются опасения, что это приведет к появлению нового посредника (Cloudflare) и монополизации, что может убить открытый интернет и затруднить вход на рынок новым игрокам.
• Участники сомневаются в эффективности модели и справедливом распределении доходов, проводя параллели с проблемами существующих систем (например, App Store, AdSense).
• Поднимается вопрос о том, что считать контентом, достойным оплаты, и как быть с синтетическими данными, созданными AI на основе первоисточников.
• Обсуждается ностальгия по старой, более децентрализованной модели интернета и скептицизм по поводу возможности вернуться к ней или создать справедливую новую.

Cap'n Web — это новая система RPC для браузеров и веб-серверов, созданная Cloudflare на чистом TypeScript. Она наследует философию объектно-ориентированных возможностей (object-capability) от Cap'n Proto, но оптимизирована для веб-стека: использует JSON для сериализации, работает поверх HTTP, WebSocket и postMessage(), весит менее 10 КБ и не требует схем или шаблонного кода. Поддерживает двусторонние вызовы, передачу функций и объектов по ссылке, а также конвейеризацию промисов для сокращения задержек.

Настройка занимает буквально несколько строк: клиент подключается через WebSocket, а сервер реализуется как класс с методами, которые автоматически становятся удалёнными процедурами. Например, метод hello(name) на сервере можно вызвать из браузера как api.hello("World"). Система интегрируется с TypeScript для типобезопасности и работает в Cloudflare Workers, Node.js и современных браузерах. Это делает распределённое программирование почти неотличимым от локального, с учётом сетевых реалий.

• Обсуждение Cap'n Web как упрощённой, schemaless версии Cap'n Proto RPC для TypeScript/JavaScript с поддержкой передачи функций и двусторонних вызовов.
• Сравнение с другими технологиями: проводятся параллели с GraphQL (решение проблемы N+1, но без DataLoader), tRPC/ORPC (схемы vs schemaless), gRPC-web (сложность) и старыми системами вроде Java RMI или .NET Remoting.
• Подняты вопросы о безопасности (риски из-за отсутствия схем и передачи произвольных колбэков), состоянии сервера (статусность vs статусность) и проблемах отладки (сложность отслеживания сетевых запросов).
• Обсуждаются технические детали: пайплайнинг промисов для уменьшения RTT, выполнение .map() на сервере через DSL, управление памятью и сборкой мусора для долгоживущих соединений.
• Запросы на расширение: поддержка других языков (Rust, Elixir), стриминг, генераторы, версионирование API и бинарная совместимость с Cap'n Proto.

Cloudflare объявляет о спонсорской поддержке двух независимых open-source проектов — браузера Ladybird и дистрибутива Omarchy на базе Arch Linux для разработчиков. Это часть стратегии по укреплению открытого интернета через разнообразие инструментов. Ladybird — амбициозная попытка создать браузер с нуля, включая собственные движки рендеринга (LibWeb) и JavaScript (LibJS), что контрастирует с доминированием Chromium, используемого 65% пользователей. Такой подход стимулирует инновации в безопасности и производительности, а также выявляет недочёты в веб-стандартах.

Omarchy предлагает продуманную среду для разработчиков, упрощая настройку и повышая продуктивность. Оба проекта демонстрируют важность альтернативных решений в условиях консолидации рынка. Cloudflare видит в этом вклад в экосистему, где независимые инициативы помогают сохранять интернет открытым и конкурентоспособным.

• Обсуждение спонсорства Cloudflare проектов Ladybird и Omarchy с акцентом на возможные скрытые мотивы компании, включая движение к вебу только для одобренных браузеров.
• Скептицизм относительно практической ценности Omarchy как ещё одного дистрибутива Linux и его сравнение с другими установщиками и системами, такими как Nix или Alpine.
• Вопросы о целесообразности создания нового браузерного движка (Ladybird) на C++ вместо более безопасных языков и сомнения в его способности конкурировать с существующими гигантами.
• Обсуждение личности DHH (создателя Omarchy) и его спорных высказываний, а также того, должно ли это влиять на поддержку его проектов.
• Поднята тема стратегического интереса Cloudflare к децентрализации веба и уменьшения зависимости от Google, аналогичного стратегии Valve с Proton.

Как работает «свинобойка»

1. Крючок – случайное СМС/мессенджер: «Привет, Анна?» → жертва отвечает.
2. Сборка личности – 5-7 дней лёгкого флирта/дружбы; выясняют доход, семью, кредитку.
3. Платформа-ловушка – переводят в WhatsApp/Signal, сбрасывают ссылку на «криптобиржу» (поддельная).
4. Первый кэш-аут – просят внести $100-500, показывают +20 % прибыли за 2 дня.
5. Откармливание – «эксклюзивный пул», «контракт с ограниченным входом»; жертва несёт кредитки, займы, продаёт авто.
6. Нож – когда вклад >$50 k, счёт «замораживают» под предлогом налога/маржи; требуют ещё.
7. Исчезновение – чат удаляют, сайт закрывают, номер выбрасывают. Средний цикл: 40-60 дней.

Цифры

• 75 % пострадавших – мужчины 30-55 лет.
• Средний убыток: $180 тыс. (макс. в кейсе – $2,3 млн).
• 60 % денег выводится через Tether на биржи без KYC за 12 минут.
• 1 оператор ведет 8-12 «свиней» одновременно.

Схема техов

• SIM-банки + Google Voice для спуфинга.
• Фейковые биржи клонируют MetaTrader; баланс правят в Postgres.
• Обнал через DeFi-миксеры (Tornado, Railgun) → китайские овер-де-Каунтеры → юань наличными.

Признаки

• Незнакомец пишет первым, фото украдено у модели.
• Речь о «внутреннем сигнале» или «арбитраже USDT».
• Сайт младше 3 месяцев, SSL от Cloudflare, домен .vip/.top.
• Прибыль ровно 18-22 % в неделю.

Что делать

• Проверьте номер/фото через Yandex/Google Images.
• Любая «инвестиция» в Telegram = красный флаг.
• Сообщите банку о мошенничестве в течение 24 ч – 30 % шанс вернуть часть.

• Пользователи обсуждают "scam с разделкой свиней" — многоэтапные мошеннические схемы, где жертв ("свиней") сначала "откармливают", выстраивая доверительные отношения в течение нескольких месяцев, а затем "забивают", выманивая крупные суммы, часто через фейковые криптоинвестиции.

• Мошенники демонстрируют невероятное терпение и используют сложную инфраструктуру: CRM-системы, сети фейковых аккаунтов и даже привлекают людей для видео-звонков, чтобы казаться реальнее. Многие операторы таких центров сами являются жертвами трафика и работают под принуждением.

• Жертвами становятся не только пожилые или уязвимые люди, но и молодые, образованные individuals, включая инженеров. Ключевой фактор — не интеллект, а эмоциональная уязвимость или одиночество в данный момент жизни.

• Масштабы проблемы колоссальны: с 2020 года похищено около $75 миллиардов, а индустрия кибермошенничества по доходам сравнялась с незаконной торговлей наркотиками.

• Обсуждение также затрагивает необходимость обучения в школах распознаванию мошенничества, сложность борьбы с этими схемами из-за их跨境ного характера и этические аспекты самого термина, который может усиливать чувство вины у жертв.

Сборник коротких серверлес-кошмаров

• $1189 – Webflow снял за месяц вместо $69.
• $100 000 – DoS на игровом сайте → счёт за Firebase за сутки.
• $738 – Vercel Pro + лимит $120 ≠ защита от «сюрприза».
• $70 000 – Проснулся с таким счётом за Firebase при тарифе $50.
• $22 640 – BigQuery на публичных данных.
• $250/мес – 9 тыс. просмотров в Framer.
• $1274 – AI Devin случайно устроил ддос в PostHog.
• $530 – Платный PostHog после нулевого периода.
• $384 – Документация на Mintlify.
• $103 – AWS Free Tier ловушка.
• $96 281 – Vercel: «я просто молчу».
• $120 000 – Cloudflare выключает сайт, требуя деньги за сутки.
• $1301 – Пустой приватный S3 + ддос.
• $11 000 – Mailgun во время атаки.
• $104 500 – Письмо от Netlify «переплата».
• $23 000 – Спам-атака на EchoFox в Vercel.
• $3000 – Тестовый деплой в Vercel.
• $620 – Sitemap.txt сожрал трафик.
• $72 000 – Тест Firebase + Cloud Run чуть не разорил.

Хочешь поделиться своим счётом-ужасом — пиши в твиттере или PR на GitHub.

• Пользователи делятся историями о «серверлес-ужасах» — внезапных счетах за десятки и сотни тысяч долларов из-за DDoS, ошибок в конфигурации или забытого ресурса.
• Критика сосредоточена не на технологии serverless, а на модели оплаты «плати за использование» без жёстких потолков: бюджет — лишь уведомление, а не отключение.
• Многие считают, что провайдеры могли бы автоматически отключать сервис при превышении лимита, но не делают этого, теряя деньги на «ошибках» новичков.
• Участники советуют: ставить rate-limit, использовать VPS с фиксированной ценой, поднимать bare-metal или хотя бы включать billing-alerts и «пауz-лимиты» вроде Vercel.
• Поддержка AWS/GCP/Azure часто прощает счета после публичных твитов, но это выживший эффект: официальной политики нет, и никто не гарантирует прощение.

• Причины ухода: Spotify платит артистам копейки, плодит фейковых исполнителей и треки, навязывает AI-музыку и сканирование лица для возраста. Платя ежемесячно, ты ничего не владеешь.

• Ядро стека

  • Navidrome – самописный стриминг-сервер. Доступ через Cloudflare Tunnel без открытия портов.
  • Клиенты: браузер, iOS (Play:Sub), Android (Symfonium), десктоп (Feishin).
  • Всё скробблится в Last.fm.

• Управление библиотекой

  • Lidarr следит за новинками любимых артистов и организует коллекцию.
  • Загрузки через sabnzbd только легально: покупки, CD-рипы, CC-лицензии. Контейнеры не выходят в интернет.

• Синхронные тексты

  • lrcget-kasm массово скачивает LRC-файлы. GUI-версия запускается в контейнере Kasm.

• Итог: полный контроль, качество, поддержка артистов без посредников.

• Участники обсуждают, что Spotify платит артистам ~$0,005 за стрим и спорят, какая компенсация была бы «справедливой»: кто-то считает, что платформа забирает слишком много, кто-то — что рынок перенасыщен треками и цена на запись стремится к нулю.
• Почти все сошлись: чтобы «поддерживать артистов», нужно покупать у них напрямую (Bandcamp, концерты, Patreon), а не полагаться на стриминг.
• Одновременно многие признают, что самоуправляемые стеки (Navidrome, Jellyfin, Plex, Lyrion LMS) — это хобби для тех, кто готов тратить время и деньги на «сервер + хранилище + поддержку».
• Часть комментаторов прямо указывает на иронию: автор жалуется на мизерные выплаты артистам, но описывает систему, где музыка по сути скачивается из Usenet/торрентов, и артисты не получают ничего.

Le Chat: 20+ MCP-коннекторов и Memories

• Каталог коннекторов (beta)
  20+ безопасных интеграций: Databricks, Snowflake, GitHub, Jira, Notion, Asana, Outlook, Box, Stripe, Zapier и др.

  • Поиск, анализ, действия в одном чате.
  • Добавьте собственные MCP-коннекторы.
  • Запуск в браузере, мобильном, on-prem или вашем облаке.

• Memories (beta)
  Персонализированные ответы на основе сохранённых фактов и предпочтений.

  • Контроль: хранить, править, удалять.
  • Импорт из ChatGPT.

• Бесплатно для всех пользователей.

Категории коннекторов

• Данные: Databricks, Snowflake, Pinecone, Prisma Postgres, DeepWiki.
• Продуктивность: Box, Notion, Asana, Monday, Jira, Confluence.
• Разработка: GitHub, Linear, Sentry, Cloudflare.
• Автоматизация: Zapier, Brevo.
• Коммерция: PayPal, Plaid, Square, Stripe.
• Custom: любые MCP-серверы.

Примеры

• Анализ отзывов в Databricks → задача в Asana.
• PR в GitHub → задача в Jira + документация в Notion.
• Сравнение контрактов в Box → краткий отчёт обратно в Box.
• Jira → спринт-обзор в Confluence.
• Stripe → аномалии → задача в Linear.

Управление и безопасность
Админы определяют доступ, аутентификация от имени пользователя.
Развёртывание: self-hosted, ваше облако или Mistral Cloud.

• Пользователи жалуются на провал gpt-5-mini и переходят на mistral-medium-0525: дешевле, быстрее, но при ошибке «падает жёстче».
• Mistral анонсировала 20+ «безопасных» MCP-коннекторов (S3, FTP, SharePoint и др.) и поддержку кастомных удалённых коннекторов.
• Валютация в $14 млрд выглядит низкой против OpenAI/Anthropic; для европейцев главный плюс — «сделано в ЕС».
• Качество моделей: в чате и простых задачах сравнимо с OpenAI, но уступает топ-версиям; скорость реакции высокая.
• Бесплатный тариф и быстрый релиз новых фич отмечают как плюсы, однако многие так и не пробовали Mistral всерьёз.

Thinkbot — бот, представляющийся строкой
Mozilla/5.0 (compatible; Thinkbot/0.5.8 … please_block_its_IP_address),
игнорирует robots.txt и предлагает просто банить его по IP.
За август он зашёл с 74 адресов, разбросанных по 41 сетевому блоку,
все принадлежат Tencent. Автор блокирует 40 подсетей Tencent,
покрывающих ≈ 476 590 IP-адресов, и подозревает,
что КНР внешне перекладывает затраты «Великого файрвола» на остальной мир.

• Большинство жалуется на агрессивных ботов, особенно из Китая (Tencent, Alibaba и др.); многие просто банят весь CN-диапазон ASN.
• Роботы маскируются под браузеры, пренебрегают robots.txt и генерируют основную нагрузку; честные UA всё равно блокируют «на всякий случай».
• Популярные защиты: Cloudflare + CrowdSec/ModSecurity, geoblock, rate-limit, tarpit, «zip-bomb» или ложные данные вместо 403.
• Участники спорят о легитимности скрапинга и этике блокировок; предлагают whitelist-ASN, централизованные чёрные списки, CAPTCHA или авторизацию.
• Итог: без идеального решения; все методы похожи на «кот и мышь», а модель «блокировать всё подозрительное» становится нормой.

SSO Wall of Shame — список вендоров, считающих SSO роскошью, а не базовой безопасностью.

SSO позволяет компании управлять доступом через собственный поставщик идентификации (Google, Okta, Azure AD), централизованно создавать/удалять аккаунты и мгновенно отключать уволенных сотрудников. Для любой организации >5 человек это критично.

Однако вендоры прячут SSO за «Enterprise»-тарифами, где цена выше в 2–4 раза или привязана к большому пакету ненужных функций. Это тормозит внедрение безопасности.

Примеры завышенных надбавок

Вендор	Базовая цена	SSO-цена	Рост
Airtable	$10/польз./мес	$60	+500 %
Appsmith	$15	$2 500	+16 567 %
Coursera	$399/польз./год	$49 875/год	+12 400 %
Cloudflare	$20/домен/мес	$1 000	+4 900 %
Breezy HR	$171/мес	$1 500	+777 %
DatoCMS	$100/мес	$667	+567 %
Canva	$10/польз./мес	$40	+300 %
Figma	$12	$45	+275 %
Bitrise	$90	$270	+200 %
Box	$5	$15	+200 %

(и ещё ~30 компаний с ростом 15–167 %).

Вывод: если вендор «серьёзно относится к безопасности», SSO должен быть либо в базе, либо за умеренную доплату.

• «SSO-налог» — это не техническая, а ценовая сегментация: крупные клиенты обязаны иметь SSO (SOC2), поэтому за него платят.
• Поддержка SSO действительно дорога: множество тикетов, сложные интеграции, вызовы инженеров, особенно при частных IdP.
• Часть вендоров всё же даёт базовый SSO через Google/GitHub/Microsoft, но «частный IdP» остаётся маркером Enterprise.
• Малым компаниям SSO тоже нужен по контрактам, но высокие цены отталкивают; кто-то предлагает субсидии или прокси-решения.
• Итог: SSO = не «фича», а показатель зрелости клиента и объём его кошелька.

OpenFreeMap выдержал 100 000 запросов/с

Внезапно сервис получил 3 млрд запросов за сутки и 215 ТБ трафика.
Пиковая нагрузка — 100 000 rps.
Стоимость такого трафика у конкурентов превысила бы $6 млн/мес.

Единственный замеченный сбой — nginx жаловался на «слишком много открытых файлов», но 96 % запросов успешно обслужены (200 OK), лишь 3,6 % вернули 206 Partial Content.
Система продолжала работать, Cloudflare кешировал даже «пустые» тайлы.

Причина всплеска — новый коллаборативный сайт рисования wplace.live, построенный на OpenFreeMap и ставший вирусным.

• На фоне внезапного хайпа wplace.live (2 млн пользователей, 3 млрд запросов) бесплатный OpenFreeMap получил «объятие смерти» ~1 000 rps, что выявило узкое место в лимите открытых файлов nginx.
• Автор OFM защитил решение ограничить по Referrer и отказаться от IP-рейт-лимита, чтобы не блочить обычных пользователей.
• Часть комментаторов считает, что бесплатный сервис не обязан выдерживать такую нагрузку; другие спорят, кто виноват — отсутствие лимитов или неожиданный виральный проект.
• Обсуждаются альтернативы: Cloudflare-only хостинг, PMTiles-файлы, self-host, но все сходятся, что 96 % доступности при таком наплыве — уже успех.

Горизонт в 41,60054° N, 93,60911° W

• Высота: ~300 м над уровнем моря
• Рельеф: пологие холмы, сельхозугодья, редкие деревья
• Видимость: 20–25 км, ограничена деревьями и постройками
• Точки рельефа:
  • Север: 1,5 км до реки Des Moines
  • Юго-запад: 2 км до лесополосы
• Освещение: ровное, без резких теней из-за низкого рельефа
• Цвета: зелёные поля, тёмно-серая дорога, голубое небо

• Проект показывает реальный цвет неба прямо сейчас, используя расчёты по научной статье и данные местоположения Cloudflare.
• Пользователи в восторге: «совпадает 100 %», «в точку», «прекрасный минимализм», но ночью/при облаках видно просто чёрный или тёмный фон.
• Автор Suncalc рад, что его библиотека пригодилась; другие предлагают добавить погоду, сделать обои для iOS/десктопа или встроить в smart-дэш.
• Кто-то путается, ждёт загрузки, пока не понимает, что ночь; кто-то ставит телефон к окну и зовёт жену «посмотри!».
• В коде нет JS/CSS, только цвет фона, генерируемый сервером — это вызывает удивление и восхищение.